Add Infineon XMC4xxx CAN driver

[talih0]

XMC4xxx has multiple CAN nodes. The nodes share a common clock and
a message object pool.

The CAN nodes do not have a loopback mode. Instead there is an
internal bus which can be used to exchange messages between
nodes on the SoC. For this reason tests/samples which rely on the
loopback feature have been disabled.

For testing I have also modified the tests/drivers/api and samples/can/counter
to have a separate transmit and receive node, instead of relying on loopback
from one node. I have not included these changes in the PR, but they can be found in this branch:
https://github.com/talih0/zephyr/tree/xmc4xxx_can

[henrikbrixandersen]

@talih0 Thank you for submitting this. I am currently reviewing.

[henrikbrixandersen]

I'd like to postpone this until #67128 has been merged, since this driver will need reworking to work with the new RTR rejecting scheme.

[talih0]

I'd like to postpone this until #67128 has been merged, since this driver will need reworking to work with the new RTR rejecting scheme.

sounds good.

[talih0]

In my branch with modified tests:
https://github.com/talih0/zephyr/tree/xmc4xxx_can

$ west build -p -b xmc47_relax_kit tests/drivers/can/api && west flash

SUITE PASS - 100.00% [can_classic]: pass = 32, fail = 0, skip = 3, total = 35 duration = 0.517 seconds

• SKIP - [can_classic.test_recover] duration = 0.001 seconds
• SKIP - [can_classic.test_send_receive_ext_id_rtr] duration = 0.001 seconds
• SKIP - [can_classic.test_send_receive_std_id_rtr] duration = 0.001 seconds

SUITE PASS - 100.00% [can_stats]: pass = 1, fail = 0, skip = 0, total = 1 duration = 0.001 seconds

SUITE PASS - 100.00% [can_utilities]: pass = 3, fail = 0, skip = 0, total = 3 duration = 0.003 seconds

SUITE SKIP - 0.00% [canfd]: pass = 0, fail = 0, skip = 8, total = 8 duration = 0.000 seconds

------ TESTSUITE SUMMARY END ------

west build -p -b xmc47_relax_kit tests/drivers/can/api -- -DCONFIG_CAN_ACCEPT_RTR=y && west flash;

SUITE PASS - 100.00% [can_classic]: pass = 32, fail = 0, skip = 3, total = 35 duration = 0.336 seconds

• SKIP - [can_classic.test_recover] duration = 0.001 seconds
• SKIP - [can_classic.test_reject_ext_id_rtr] duration = 0.001 seconds
• SKIP - [can_classic.test_reject_std_id_rtr] duration = 0.001 seconds

SUITE PASS - 100.00% [can_stats]: pass = 1, fail = 0, skip = 0, total = 1 duration = 0.001 seconds

SUITE PASS - 100.00% [can_utilities]: pass = 3, fail = 0, skip = 0, total = 3 duration = 0.003 seconds

SUITE SKIP - 0.00% [canfd]: pass = 0, fail = 0, skip = 8, total = 8 duration = 0.000 seconds

[talih0]

Rebased to take into account recent api changes for struct can_driver_data/config common, and removal of get_max_bitrate().

[talih0]

rebased to take into can_transeive_enable() api change

[talih0]

Rebased to origin/main to fix CI

[henrikbrixandersen]

It would be nice to see support for CAN statistics in a later PR. A couple of minor suggestions/comments:

[henrikbrixandersen]

Couldn't this be used when automatic bus recovery is turned off as well?

[talih0]

thanks, yes, that's true, I'll work on this tomorrow.

[talih0]

@henrikbrixandersen, my original comment was misleading here, sorry.

It's not possible to stop the bus auto-recovery process on the XMC4xxx.
This call to XMC_CAN_NODE_ResetInitBit() is needed to automatically re-enable the node after the bus-recovery completes.

Initially, I thought that we could move this XMC_CAN_NODE_ResetInitBit() call to the driver can_xmc4xxx_recover() function, but it looks tricky to implement because once the internal auto bus recovery completes, it will trigger the can_xmc4xxx_state_change_handler() to indicate that the bus is no longer in a bus-off state. This will then issue a callback to the user about the state change, perhaps, even before they call the recover function.

[henrikbrixandersen]

No problem, we can leave the implementation as is for now. I plan on redesigning the auto-recovery/manual recovery functionality soon, effectively turning it into a can_mode_t setting. This will allow for drivers to signal whether they support manual recovery at all, which quite a few CAN IPs do not.

[talih0]

It would be nice to see support for CAN statistics in a later PR. A couple of minor suggestions/comments:

thanks, yes, I'll add the statistics in a separate PR. I also need to add them for the mcp251xfd driver.