In response to my uncertainty described here https://lore.kernel.org/linux-can/20210729121417.kysljj4636hmhem2@xxxxxxxxxxxxxx/T/#t. This patch clarifies sending CAN 2.0 frames on CAN FD capable hardware when the interface is configured as CAN 2.0. Signed-off-by: Thomas Wagner <thomas@xxxxxxxxxxxxx> --- Documentation/networking/can.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/Documentation/networking/can.rst b/Documentation/networking/can.rst index f34cb0e4460e..ac3fe948c888 100644 --- a/Documentation/networking/can.rst +++ b/Documentation/networking/can.rst @@ -675,6 +675,17 @@ When sending to CAN devices make sure that the device is capable to handle CAN FD frames by checking if the device maximum transfer unit is CANFD_MTU. The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall. +You should also check the MTU in an environment, where the device is CAN +FD capable, but the interface might be configured for just CAN 2.0. In +this case the canfd_frame struct can still be used, but when writing to +the socket write CAN_MTU bytes at most to send a CAN 2.0 frame. + +In conclusion, to handle devices with and without CAN FD and with +interfaces configured as CAN 2.0 or CAN FD: +- Set the CAN_RAW_FD_FRAMES flag and ignore the error on older kernels +- Send and receive using the canfd_frame struct +- Check the bytes received to know, whether you got an CAN 2.0 or FD frame +- Check the devices MTU to know, whether you can send CAN 2.0 or FD frames RAW socket option CAN_RAW_JOIN_FILTERS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 2.25.1
