drivers: can: rcar: inconsistent behavior when calling can_stop() with pending transmissions

[henrikbrixandersen]

Describe the bug
The Renesas R-Car CAN controller drivers likely exhibits inconsistent behavior when calling can_stop() with pending CAN frame transmissions similar as to what was reported in #50545. I have not been able to find the behavior of the Renesas R-Car CAN driver as I do not have access to the hardware.

To check
Steps to reproduce the behavior:

1. Disconnect the CAN controller from the CAN bus.
2. Using the CAN shell, call can start <device>.
3. Using the CAN shell, call can send <device> 010.
4. Using the CAN shell, call can stop <device>.
5. Connect the CAN controller to a CAN bus with at least one other node for ACK'ing frames and monitor any received frames on that node (e.g. use candump on GNU/Linux).
6. Using the CAN shell, call can start <device>.
7. Observe the different behavior across the Zephyr CAN drivers as described above.

Expected behavior
The behavior should be the same across the Zephyr CAN drivers. Since some CAN controllers automatically abort any pending transmissions, the common behavior should be to abort any pending transmissions and notify the senders of this.

Impact
Unknown.

Environment (please complete the following information):

• Commit SHA: 7e6e457

Additional context
The can_stop() API was introduced in #50102.

[henrikbrixandersen]

@aaillet Ping

[github-actions]

This issue 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 issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions]

This issue 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 issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[aaillet]

Hi @henrikbrixandersen,

Sorry for this big delay...

I just verified can_stop() behavior on a random late Feb 2023 sha (dca33a1) on H3ULCB board and got these results:

#Board not plugged to CAN bus
uart:~$ can start can@e6c30000
starting can@e6c30000
uart:~$ can send can@e6c30000 01 DE AD BE EF
enqueuing CAN frame #0 with standard (11-bit) CAN ID 0x001, RTR 0, CAN-FD 0, BRS 0, DLC 4
uart:~$ can stop can@e6c30000 
stopping can@e6c30000
#Pluging board to CAN bus
uart:~$ can start can@e6c30000
starting can@e6c30000
CAN frame #0 successfully sent

I can confirm that the frame has successfully been received by the other CAN device (a computer using CAN USB adapter) as soon as can start() has been called.
I think that this is the behavior we are waiting for but I just wanted you to validate that !

Thank you in advance !

[henrikbrixandersen]

I can confirm that the frame has successfully been received by the other CAN device (a computer using CAN USB adapter) as soon as can start() has been called. I think that this is the behavior we are waiting for but I just wanted you to validate that !

Unfortunately, that is the opposite of the desired behaviour. Calling can_stop() should abort any pending TX frames.

[aaillet]

Unfortunately, that is the opposite of the desired behaviour. Calling can_stop() should abort any pending TX frames.

Oh ok, so we want the controller to empty FIFOs and clear everything that has to be cleared !
I'll work on fixing that, thanks for the answer !