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

* Re: Write canfd_frame to can interface
  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
  0 siblings, 1 reply; 4+ messages in thread
From: Marc Kleine-Budde @ 2021-07-29 10:55 UTC (permalink / raw)
  To: thomas; +Cc: linux-can

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On 29.07.2021 12:03:56, thomas@the-wagner.de 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

* RE: Write canfd_frame to can interface
  2021-07-29 10:55 ` Marc Kleine-Budde
@ 2021-07-29 12:02   ` Thomas Wagner
  2021-07-29 12:14     ` Marc Kleine-Budde
  0 siblings, 1 reply; 4+ messages in thread
From: Thomas Wagner @ 2021-07-29 12:02 UTC (permalink / raw)
  To: 'Marc Kleine-Budde'; +Cc: linux-can

Hello Marc,

On 2021-07-29 12:55, Marc Kleine-Budde wrote:
> On 29.07.2021 12:03:56, thomas@the-wagner.de 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.
The same differentiation I must make when sending...

Thanks for the quick reply!

Best regards
Thomas Wagner




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

* Re: Write canfd_frame to can interface
  2021-07-29 12:02   ` Thomas Wagner
@ 2021-07-29 12:14     ` Marc Kleine-Budde
  0 siblings, 0 replies; 4+ messages in thread
From: Marc Kleine-Budde @ 2021-07-29 12:14 UTC (permalink / raw)
  To: Thomas Wagner; +Cc: linux-can

[-- Attachment #1: Type: text/plain, Size: 1906 bytes --]

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@the-wagner.de 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ 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).