linux-can.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: Marc Kleine-Budde <mkl@pengutronix.de>,
	"linux-can@vger.kernel.org" <linux-can@vger.kernel.org>
Subject: Re: [PATCH 1/6] canfd: add new data structures and constants
Date: Tue, 19 Jun 2012 09:11:32 +0200	[thread overview]
Message-ID: <4FE02624.2010606@hartkopp.net> (raw)
In-Reply-To: <4FE02008.6030405@grandegger.com>

On 19.06.2012 08:45, Wolfgang Grandegger wrote:

> Hi Oliver,
> 
> On 06/18/2012 07:39 PM, Oliver Hartkopp wrote:
>> - add new struct canfd_frame
>> - check identical element offsets in struct can_frame and struct canfd_frame
>> - new ETH_P_CANFD definition to tag CAN FD skbs correctly
>> - add CAN_MTU and CANFD_MTU definitions for easy frame and mode detection
>> - add CAN[FD]_MAX_[DLC|DLEN] helper constants to remove hard coded values
>>
>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>> ---
>>  include/linux/can.h      |   55 ++++++++++++++++++++++++++++++++++++++++++----
>>  include/linux/if_ether.h |    3 ++-
>>  net/can/af_can.c         |    7 ++++++
>>  3 files changed, 60 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/can.h b/include/linux/can.h
>> index 17334c0..25265e7 100644
>> --- a/include/linux/can.h
>> +++ b/include/linux/can.h
>> @@ -46,18 +46,65 @@ typedef __u32 canid_t;
>>   */
>>  typedef __u32 can_err_mask_t;
>>  +#define CAN_MAX_DLC 8
>> +#define CAN_MAX_DLEN 8
>> +
>> +#define CANFD_MAX_DLC 15
>> +#define CANFD_MAX_DLEN 64
>> +

(..)

>>  struct can_frame {
>>  	canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
>> -	__u8    can_dlc; /* data length code: 0 .. 8 */
>> +	__u8    can_dlc; /* frame payload length in byte (0 .. 8) */
>>  	__u8    data[8] __attribute__((aligned(8)));
>>  };


(..)

>> + * @data:   CAN FD frame payload (up to 64 byte)
>> + */
>> +struct canfd_frame {
>> +	canid_t can_id;  /* 32 bit CAN_ID + EFF/RTR/ERR flags */
>> +	__u8    len;     /* frame payload length in byte (0 .. 64) */
>> +	__u8    flags;   /* additional flags for CAN FD */
>> +	__u8    __res0;  /* reserved / padding */
>> +	__u8    __res1;  /* reserved / padding */
>> +	__u8    data[64] __attribute__((aligned(8)));
> 
> Shouldn't we use "CANFD_MAX_DLEN" here (... and maybe above as well)?.
> IIRC, CANFD_MAX_DLEN might be even 128 in the finalized standard.
> 


Yes. Good point.

(..)

>> -#define ETH_P_CAN	0x000C		/* Controller Area Network      */
>> +#define ETH_P_CAN	0x000C		/* Controller Area Network (CAN)*/
>> +#define ETH_P_CANFD	0x000D		/* CAN FD 64 byte payload frames*/
> 
> Then hardcoding 64 here is also not be nice.


Yes. Will change that too.
Even if there's a little chance to have more than 64 bytes it's not the right
place for this kind of information anyway.

I would wait until this evening if there are more of these remarks and send a
v2 then. A review of the documentation would be nice - if everything seems
clear to you.

Thanks,
Oliver


  reply	other threads:[~2012-06-19  7:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-18 17:39 [PATCH 1/6] canfd: add new data structures and constants Oliver Hartkopp
2012-06-18 17:51 ` Oliver Hartkopp
2012-06-18 19:12   ` Marc Kleine-Budde
2012-06-18 19:13 ` Marc Kleine-Budde
2012-06-18 19:19   ` Oliver Hartkopp
2012-06-18 19:48     ` Marc Kleine-Budde
2012-06-18 19:55       ` Marc Kleine-Budde
2012-06-18 20:03         ` Oliver Hartkopp
2012-06-18 20:20           ` Marc Kleine-Budde
2012-06-19  6:45 ` Wolfgang Grandegger
2012-06-19  7:11   ` Oliver Hartkopp [this message]
2012-06-19  7:28     ` Wolfgang Grandegger
2012-06-19  7:39       ` Oliver Hartkopp
2012-06-19  9:30     ` 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=4FE02624.2010606@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=linux-can@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=wg@grandegger.com \
    /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;
as well as URLs for NNTP newsgroup(s).