On 29.07.2021 12:03:56, thomas@xxxxxxxxxxxxx wrote: > I have been working on getting my device compatible with both, CAN and > CAN FD. > > For receiving this is working straight forward. My physical interface > is CAN FD capable and no matter whether I set it up as > ip link set can0 type can bitrate 500000 fd off > or > ip link set can0 type can bitrate 500000 fd dbitrate 2000000 off > in code I can always just use the canfd_frame struct and set the > CAN_RAW_FD_FRAMES option. Doing this I can receive CAN and CAN FD > frames in both modes without having to fall back to the can_frame > struct (as explained in the docs). > > For sending I expected a similar behavior. I set the CAN_RAW_FD_FRAMES > option and always sent using the canfd_frame struct. Sadly, this fails > while writing on the interface when it is not in FD-mode with an > Invalid Argument error. To make this work without falling back to the > can_frame struct I just do > write(sock, &canfdf, sizeof(struct can_frame)); > where canfdf is a canfd_frame. Not setting CAN_RAW_FD_FRAMES when the > interface is in CAN mode but sending using the full canfd_frame won't > work too. > > Is this expected behavior? Yes. > 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? 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
