On 29.07.2021 14:02:34, Thomas Wagner wrote: > Hello Marc, > > On 2021-07-29 12:55, Marc Kleine-Budde wrote: > > On 29.07.2021 12:03:56, thomas@xxxxxxxxxxxxx wrote: > >> Shouldn't the error only be returned if the > >> canfd_frame I pass has more than 8 bytes when the interface is not in > >> FD-mode? > > > > A CAN-2.0 frame with 8 bytes is something different than a CAN-FD frame > > with 8 bytes. The kernel uses the length of the frame to decide if it is > > a CAN-2.0 or CAN-FD frame. If your CAN controller has switched CAN-FD > > off, it cannot send CAN-FD frames, thus you get an error. > > > > Does that make sense? > > Sure! > > I see how a CAN-2.0 frame with 8 bytes differs from a CAN-FD frame with > 8-bytes, but when I receive into a canfd_frame I can't differentiate like that > anymore. In userspace an 8B CAN-2.0 frame and an 8B CAN-FD frame look just > the same, no matter the interface running with FD on or off. > > ... which is wrong as I just noticed. Paying attention to the actual bytes read > by the socket I can see the 16 vs. 72B that make up a can_frame vs. a > canfd_frame respectively. Even when always writing into a canfd_frame. With the C language the type information of your read buffer doesn't leave the scope of your function (write() uses a void * for the buffer). The length information is checked in the kernel, but only if it's large enough: https://elixir.bootlin.com/linux/v5.13/source/net/can/raw.c#L850 > The same differentiation I must make when sending... ACK - If you an idea how to improve the documentation, let me know! regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature
