can: introduce CANFD_FDF flag for mixed content in struct canfd_frame

The struct can_frame and struct canfd_frame intentionaly share the same layout to be able to write CAN frame content into a CAN FD frame structure. When this is done the former differentiation via CAN_MTU / CANFD_MTU gets lost. CANFD_FDF allows programmers to mark CAN FD frames in the case of using struct canfd_frame for mixed CAN / CAN FD content (dual use). N.B. the Kernel APIs do NOT provide mixed CAN / CAN FD content inside of struct canfd_frame therefore the CANFD_FDF flag is disregarded by Linux.

---
 include/uapi/linux/can.h | 9 +++++++++
 1 file changed, 9 insertions(+)

index c48d93a28d1a..02f64221fb52 100644
@@ -124,9 +124,18 @@ struct can_frame {
  * controller only the CANFD_BRS bit is relevant for real CAN controllers when
  * building a CAN FD frame for transmission. Setting the CANFD_ESI bit can make
  * sense for virtual CAN interfaces to test applications with echoed frames.
+ *
+ * The struct can_frame and struct canfd_frame intentionaly share the same
+ * layout to be able to write CAN frame content into a CAN FD frame structure.
+ * When this is done the former differentiation via CAN_MTU / CANFD_MTU gets
+ * lost. CANFD_FDF allows programmers to mark CAN FD frames in the case of
+ * using struct canfd_frame for mixed CAN / CAN FD content (dual use).
+ * N.B. the Kernel APIs do NOT provide mixed CAN / CAN FD content inside of
+ * struct canfd_frame therefore the CANFD_FDF flag is disregarded by Linux.
  */
 #define CANFD_BRS 0x01 /* bit rate switch (second bitrate for payload data) */
 #define CANFD_ESI 0x02 /* error state indicator of the transmitting node */
+#define CANFD_FDF 0x04 /* mark CAN FD for dual use of struct canfd_frame */
 
 /**
  * struct canfd_frame - CAN flexible data rate frame structure

2.11.0

Sorry, I don't get the usecase. Who will evaluate this bit? The userspace, when using vcan? What does it mean, when this bit is set? That we have a CAN frame within a struct canfd_frame?

Marc

Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

The latter - but the other way around.

I did a SocketCAN presentation at AGL last week

https://wiki.automotivelinux.org/agl-distro/apr2017-f2f

See slides 51 - 55 from this PDF at

https://wiki.automotivelinux.org/_media/agl-distro/agl2017-socketcan-print.pdf

The point is on the last of the five slides

struct canfd_frame cframe;
int s = socket(PF_CAN, SOCK_DGRAM, CAN_RAW); setsockopt(s, SOL_CAN_RAW, CAN_RAW_FD_FRAMES, ...); (..)
nbytes = read(s, &cframe, sizeof(struct canfd_frame));

You can get CAN frames and CAN FD frames here.

The distinction is represented in the value of nbytes which can be CAN_MTU (16) or CANFD_MTU (72).

The problem is that from this moment you have to take the nbytes value *along* with the struct canfd_frame to know what it contains.

E.g. in candump.c a variable maxdlen is used

https://github.com/linux-can/can-utils/blob/master/candump.c#L661

which then has to be passed to all following function calls e.g.

https://github.com/linux-can/can-utils/blob/master/lib.h#L149

Imagine how you can simplify the handling of mixed content stored into struct canfd_frame with this new bit.

Of course every CAN(FD) application programmer could define this bit in a private way - but you don't know whether the crazy kernel hackers use this bit position in a different way some day.

So this is more or less a reservation to help CAN application programmers to be able to carry the CANFD format information within the struct canfd_frame.

Regards,
Oliver