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

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

[Thomas Wagner]

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

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

[Thomas Wagner]

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 | 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

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

[Oliver Hartkopp]

On 02.08.21 12:40, Thomas Wagner wrote:
> 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 | 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