Multiple SocketCAN instance support.

[sumitbatra-nxp]

Adding support for multiple socketCAN interfaces by
making use of instances of DT_DRV_COMPAT for
network devices instead of a single network interface
Each socketCAN instance has a corresponding
DT Node named net_canbus<0>,<1>.

The net_canbus DT Node needs to be a child of the CAN DT Node.
The CAN and socketCAN devices can be accessed
by applications by parent child DT macros.
SocketCAN applications can access socketCAN node and
hence the network interface with its node id.

Tested on RDDRONE board.

Signed-off-by: Benjamin Perseghetti bperseghetti@rudislabs.com
Co-authored-by: Sumit Batra sumit.batra@nxp.com

[igalloway]

@sumitbatra-nxp @bperseghetti
What is the summary here?
I'm trying to follow the thread, do we need to propose a change to the zephyr-specific-chosen-nodes
https://docs.zephyrproject.org/latest/build/dts/api/api.html#zephyr-specific-chosen-nodes

in order to have multiple CAN interfaces running simultaneously (likely with differing protocols)
(See MR-CANHUBK344 board as an example hardware. There are six CAN busses)

[henrikbrixandersen]

do we need to propose a change to the zephyr-specific-chosen-nodes

No. I am working on a different approach.

[igalloway]

Thanks @henrikbrixandersen
Just in case it is relevant, note that on a board like MR-CANHUBK344 there are also different types of PHY interfaces and they could have some differing control signals. I don't think this would have an impact at this level. But i just wanted to mention it in case it impacts the software architecture.

[henrikbrixandersen]

Thanks @henrikbrixandersen

Just in case it is relevant, note that on a board like MR-CANHUBK344 there are also different types of PHY interfaces and they could have some differing control signals. I don't think this would have an impact at this level. But i just wanted to mention it in case it impacts the software architecture.

Thanks. That does not impact the solution here, as GPIO-controlled CAN transceivers are already supported.

[bperseghetti]

do we need to propose a change to the zephyr-specific-chosen-nodes

No. I am working on a different approach.

@henrikbrixandersen Is there a WIP branch/PR for your approach/work that you could potentially reference in the comments of this PR?

[henrikbrixandersen]

@henrikbrixandersen Is there a WIP branch/PR for your approach/work that you could potentially reference in the comments of this PR?

Unfortunately, the work is not yet ready for consumption/review. I have done a few refactoring PRs in the last month, which lead up to adding this. The basic idea is to have CAN_DEVICE_DT_DEFINE() automatically register the CAN controller device as a network interface based on whether SocketCAN is enabled in Kconfig or not (inspired by the ieee 802.15.4 drivers).

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

Removing my review atm.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[jukkar]

@henrikbrixandersen should we just close this instead of removing the stale label, it does not look like this is progressing in over two years?

[henrikbrixandersen]

@henrikbrixandersen should we just close this instead of removing the stale label, it does not look like this is progressing in over two years?

We could, but I still plan to address it. The solution is pending another change in the CAN driver subsystem, which I am currently working on formalizing as an RFC.

We can move this issue to just be labeled CAN, if that helps.

[jukkar]

No worries at all and no need to remove the net label, just wondering what the plan was.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.