public inbox for linux-can@vger.kernel.org
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Marc Kleine-Budde <mkl@pengutronix.de>,
	Kurt Van Dijck <kurt.van.dijck@eia.be>
Cc: dev@sebastianhaas.info, linux-can@vger.kernel.org
Subject: Re: [RFC] can: Introducing CANFD for af_can & can-raw
Date: Wed, 21 Mar 2012 14:21:22 +0100	[thread overview]
Message-ID: <4F69D5D2.5080003@hartkopp.net> (raw)
In-Reply-To: <4F69CA74.3020607@pengutronix.de>

Hi all,

of course i also thought about some concepts to support CAN FD ;-)

But then it melted down to the question what a potential CAN FD controller
would support:

1. Will it support sending of CAN frames & CAN FD frames with one config?
2. Is a CAN FD frame with DLC=8 different to a CAN2.0 frame with DLC=8 ?
   (as we know CAN ID 0x123 (EFF) and CAN ID 0x123 (SFF) are different)
3. Will these differences be visible in the CAN registers? Is this relevant?

What i got from the iCC was that when you have a partly migrated network and
you want to run e.g. a fast firmware upload between two CAN FD capable nodes,
the other (standard CAN 2.0b) nodes have to be in listen only mode to not jam
the bus with error frames.

After the firmware upload all the CAN nodes switch back to CAN2.0b mode (which
has to be done by root netlink access).

IMO we need to introduce a new struct canfd_frame

struct canfd_frame {
        canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
        __u8    can_dlc; /* data length code: 0 .. F */
        __u8    data[64] __attribute__((aligned(8)));
};

which can become the mayor internal data structure.

It should be no problem to move to canfd_frame inside the kernel but if we
come to the point that we get to the userspace ABI there should be no tricky
way to check lengths or flags or return values are are not needed to be
checked with the current ABI now.

When there's a defined socket API that makes use of struct can_frame (like
can_raw, can_bcm, can_gw - but not isotp! \o/ ) we need to

- duplicate the socket API - like CAN_RAWFD (ugly)
- switch the frame size (e.g. via sockopt)
- a third unknown idea ...

E.g. when having a CAN FD aware candump/cansend application, it can try to
switch the socket to CAN FD. If it works -> use CAN FD, if not we're probably
on an older kernel that does not support CAN FD ...

I think it's much more tricky to find a proper solution here.

Regards,
Oliver

  parent reply	other threads:[~2012-03-21 13:21 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-21  9:10 [RFC] can: Introducing CANFD for af_can & can-raw Kurt Van Dijck
     [not found] ` <E1SAIM4-0007a6-Sf@smtprelay03.ispgateway.de>
2012-03-21 11:05   ` Kurt Van Dijck
2012-03-21 11:43     ` Marc Kleine-Budde
2012-03-21 12:08       ` Kurt Van Dijck
2012-03-21 12:32         ` Marc Kleine-Budde
2012-03-21 12:51           ` Kurt Van Dijck
2012-03-21 13:19             ` Marc Kleine-Budde
2012-03-21 13:21           ` Oliver Hartkopp [this message]
2012-03-21 13:53             ` Kurt Van Dijck
2012-03-21 14:49               ` Oliver Hartkopp
2012-03-21 15:26                 ` Oliver Hartkopp
2012-03-22  9:03                 ` Kurt Van Dijck
2012-03-21 14:56               ` Wolfgang Grandegger
2012-03-21 15:05                 ` Oliver Hartkopp
2012-03-22  9:24                   ` Kurt Van Dijck
2012-03-22  9:32                     ` Marc Kleine-Budde
2012-03-22  9:38                     ` Wolfgang Grandegger
2012-03-22 10:13                       ` Kurt Van Dijck
2012-03-23 11:01                         ` Wolfgang Grandegger
2012-03-22  9:57                   ` Kurt Van Dijck
2012-03-22 10:06                     ` Wolfgang Grandegger
2012-03-22 10:35                       ` Kurt Van Dijck
2012-03-22 11:00                         ` Wolfgang Grandegger
2012-03-22 12:25                           ` Oliver Hartkopp
2012-03-22 12:47                             ` Kurt Van Dijck
2012-03-21 13:29           ` Alexander Stein
2012-03-21 13:34             ` Kurt Van Dijck
2012-03-21 13:51             ` Marc Kleine-Budde
2012-03-21 15:47               ` Alexander Stein

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=4F69D5D2.5080003@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=dev@sebastianhaas.info \
    --cc=kurt.van.dijck@eia.be \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox