On 02.08.21 12:40, Thomas Wagner wrote:
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.
IMO this is still confusing. The point is that the struct can_frame and
canfd_frame have a compatible layout (up to the length of struct
can_frame) - and therefore you can use struct canfd_frame up to this
length for most use-cases. But not for all! E.g. the handling of raw DLC
values for Classical CAN.
+
+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
This is done in candump.c to be able to *receive* any kind of CAN(FD)
traffic.
IMO this is generally not a good advise to ignore the result in any
case. Please take a look into cansend.c how it is handled there.
+- Send and receive using the canfd_frame struct
IMO when you know what you are doing and you are handling CAN *and*
CANFD frames you get behind this simplification on your own.
There are still good reasons to work with the struct can_frame, e.g.
when you want to work with raw CAN dlc values.
+- Check the bytes received to know, whether you got an CAN 2.0 or FD frame
... once you set the CAN_RAW_FD_FRAMES flag.
+- Check the devices MTU to know, whether you can send CAN 2.0 or FD frames
Yes. An example for that is in cansend.c
But I wonder if such a use-case is relevant to a normal CAN application.
The programmer usually knows whether he wants to work with CAN or CAN FD
frames. And when sending a CAN FD frame results into an error you can
just drop an error message about "sending the CAN FD frame not possible".
Best regards,
Oliver
