[PATCH] can: Documentation: Sending with canfd_frame on a CAN 2.0 interface

[Thomas Wagner <thomas@the-wagner.de>]

In response to my uncertainty described here
https://lore.kernel.org/linux-can/20210729121417.kysljj4636hmhem2@pengutronix.de/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@the-wagner.de>
---
 Documentation/networking/can.rst | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/networking/can.rst b/Documentation/networking/can.rst
index f34cb0e4460e..af94ece79d5e 100644
--- a/Documentation/networking/can.rst
+++ b/Documentation/networking/can.rst
@@ -675,6 +675,20 @@ 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:
+- 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 frame
+
+Building your application using always the canfd_frame, setting the  this enables it to run on devices with and
+without CAN FD hardware. It also handles the possibility of interfaces that
+are configured as CAN 2.0 or CAN FD on CAN FD hardware.
 
 RAW socket option CAN_RAW_JOIN_FILTERS
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
2.25.1