From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>
Cc: "linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Subject: Re: [PATCH 3.6-rc1] canfd: remove redundant CAN FD flag
Date: Tue, 07 Aug 2012 10:16:55 +0200 [thread overview]
Message-ID: <5020CEF7.9080809@pengutronix.de> (raw)
In-Reply-To: <501FEA95.3060906@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]
On 08/06/2012 06:02 PM, Oliver Hartkopp wrote:
> The first idea of the CAN FD implementation started with a new struct
> canfd_frame to be used for both CAN FD frames and legacy CAN frames.
> The now mainlined implementation supports both CAN frame types simultaneously
> and distinguishes them only by their required sizes: CAN_MTU and CANFD_MTU.
>
> Only the struct canfd_frame contains a flags element which is needed for the
> additional CAN FD information. As CAN FD implicitly means that the 'Extened
> Data Length' mode is enabled the formerly defined CANFD_EDL bit became
> redundant and also confusing as an unset bit would be an error and would
> always need to be tested.
>
> This patch removes the obsolete CANFD_EDL bit and clarifies the documentation
> for the use of struct canfd_frame and the CAN FD relevant flags.
>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>
> ---
>
> Hello Marc,
>
> when thinking about the extension of the can-utils to support the handling of
> CAN FD specific flags in logfiles and console output i stumbled upon an
> implementation artifact i would like to fix before 3.6 is released.
>
> The former flags definition turned out to be hard to use and is redundant in
> the case of the CANFD_EDL flag.
>
> Do you want to take that patch in your linux-can tree to be pulled for 3.6-rc2
> or should i send it to Dave/netdev-ML directly?
> The patch is based on Linus' 3.6-rc1 tree.
I'll take the patch. As I'm the single point of contact, David will
probably refuse to take it directly from you. I hope no one will blame
us hard for modifying the ABI of the kernel for canfd frames. However I
think it's okay as there are probably no users of the canfd frame out there.
BTW: warning: 1 line adds whitespace errors.
I've fixed this.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2012-08-07 8:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-06 16:02 [PATCH 3.6-rc1] canfd: remove redundant CAN FD flag Oliver Hartkopp
2012-08-07 8:16 ` Marc Kleine-Budde [this message]
2012-08-07 8:33 ` Oliver Hartkopp
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=5020CEF7.9080809@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=linux-can@vger.kernel.org \
--cc=socketcan@hartkopp.net \
/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.