All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: thomas@the-wagner.de
Cc: linux-can@vger.kernel.org
Subject: Re: Write canfd_frame to can interface
Date: Thu, 29 Jul 2021 12:55:39 +0200	[thread overview]
Message-ID: <20210729105539.ppi7rm6uglwbpyov@pengutronix.de> (raw)
In-Reply-To: <006401d78461$0b868b60$2293a220$@the-wagner.de>

[-- 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 --]

  reply	other threads:[~2021-07-29 10:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-29 10:03 Write canfd_frame to can interface thomas
2021-07-29 10:55 ` Marc Kleine-Budde [this message]
2021-07-29 12:02   ` Thomas Wagner
2021-07-29 12:14     ` Marc Kleine-Budde

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210729105539.ppi7rm6uglwbpyov@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=thomas@the-wagner.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.