presume ack/self test mode support

[henzef]

Does this firmware support the presume-ack feature of socketcan (see [1] and [2])? If not, is this due to hardware limitations or could something like this be implemented?

[1] https://patchwork.ozlabs.org/project/netdev/patch/[email protected]/
[2] https://lists.openwall.net/netdev/2014/12/05/73

[fenugrec]

Hi,
No, firmware doesn't support it and as far as I can tell the hardware can't really do this unless maybe by polling the error codes, detecting ACK errors and manually aborting transmission before it gets transmitted again automatically – ugly at best.
I thought maybe some test mode could provide similar behavior but there's no way of looping back the ACK signal yet still receiving frames from the bus.
I'll leave this open for a while in case someone has a better idea but I doubt it will be possible on this platform.

[brian-brt]

I took a look at the reference manual. I basically concur that it's impossible, but I noticed something else: I think CAN_CTRLMODE_LISTENONLY is interpreted as CAN_CTRLMODE_LISTENONLY | CAN_CTRLMODE_PRESUME_ACK. @henzef maybe that behavior is close enough for what you want?

I don't think plain CAN_CTRLMODE_LISTENONLY should receive messages with no ACK on the bus, but the "silent mode" of this hardware will. The reference manual says:

If the bxCAN has to send a dominant bit (ACK bit, overload flag, active error flag), the bit is rerouted internally so that the CAN Core monitors this dominant bit, although the CAN bus may remain in recessive state

I tested it too, and it definitely does receive non-ACKed frames. I'm not 100% certain on the "correct" correct semantics for plain CAN_CTRLMODE_LISTENONLY though.

I think the gs_usb driver with this firmware should at a minimum accept CAN_CTRLMODE_LISTENONLY | CAN_CTRLMODE_PRESUME_ACK to give the current behavior. Refusing to come up with plain CAN_CTRLMODE_LISTENONLY might be "more correct", but it's also a backwards incompatible change. I'm not sure if making that change purely in gs_usb or bringing it all the way to the microcontroller would make more sense.

In the end, I concur that looping back the ACK signal while doing normal transmits and receives on the bus is impossible with the test modes. You can do it along with normal transmits or receives on the bus though...