linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Write canfd_frame to can interface
@ 2021-07-29 10:03 thomas
  2021-07-29 10:55 ` Marc Kleine-Budde
  0 siblings, 1 reply; 4+ messages in thread
From: thomas @ 2021-07-29 10:03 UTC (permalink / raw)
  To: linux-can

Hi there!

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

Regards,
Thomas


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-07-29 12:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-29 10:03 Write canfd_frame to can interface thomas
2021-07-29 10:55 ` Marc Kleine-Budde
2021-07-29 12:02   ` Thomas Wagner
2021-07-29 12:14     ` Marc Kleine-Budde

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).