netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Hartkopp <socketcan@hartkopp.net>
To: Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Cc: linux-can <linux-can@vger.kernel.org>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH v4 4/7] can: replace can_dlc as variable/element for payload length
Date: Mon, 9 Nov 2020 16:38:21 +0100	[thread overview]
Message-ID: <b33f7cc7-6bf3-363b-e328-a405ec4a2575@hartkopp.net> (raw)
In-Reply-To: <CAMZ6RqJz+G-R6LF=jU22kcYPBwTCOB7XmcY+GTNLmfm+-9rvUw@mail.gmail.com>

Hi Vincent,

On 09.11.20 13:59, Vincent MAILHOL wrote:
> On Mon. 9 Nov 2020 at 19:26, Oliver Hartkopp wrote:
>> diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
>> index b2e8df8e4cb0..72671184a7a2 100644
>> --- a/include/linux/can/dev.h
>> +++ b/include/linux/can/dev.h
>> @@ -183,12 +183,12 @@ static inline void can_set_static_ctrlmode(struct net_device *dev,
>>          /* override MTU which was set by default in can_setup()? */
>>          if (static_mode & CAN_CTRLMODE_FD)
>>                  dev->mtu = CANFD_MTU;
>>   }
>>
>> -/* get data length from can_dlc with sanitized can_dlc */
>> -u8 can_dlc2len(u8 can_dlc);
>> +/* get data length from raw data length code (DLC) */
> 
> /*
>   * convert a given data length code (dlc) of an FD CAN frame into a
>   * valid data length of max. 64 bytes.
>   */
> 
> I missed this point during my previous review: the can_dlc2len() function
> is only valid for CAN FD frames. Comments should reflect this fact.
> 
>> +u8 can_dlc2len(u8 dlc);
> 
> Concerning the name:
>   * can_get_cc_len() converts a Classical CAN frame DLC into a data
>     length.
>   * can_dlc2len() converts an FD CAN frame DLC into a data length.
> 
> Just realized that both macro/function do similar things so we could
> think of a similar naming as well.
>   * Example 1: can_get_cc_len() and can_get_fd_len()
>   * Example 2: can_cc_dlc2len() and can_fd_dlc2len()

I like!

Patch set v5 is out now.

Thanks,
Oliver

> 
> Or we could simply leave things as they are, this is not a big issue
> as long as the comments clearly state which one is for classical
> frames and which one is for FD frames.
> 
>>
>>   /* map the sanitized data length to an appropriate data length code */
>>   u8 can_len2dlc(u8 len);
> 
> can_len2dlc() might be renamed (e.g. can_get_fd_dlc()) if Example 1
> solution is chosen.
> 
>>   struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max,
> 
> Yours sincerely,
> Vincent Mailhol
> 

  reply	other threads:[~2020-11-09 15:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 10:26 [PATCH v4 0/7] Introduce optional DLC element for Classic CAN Oliver Hartkopp
2020-11-09 10:26 ` [PATCH v4 1/7] can: add optional DLC element to Classical CAN frame structure Oliver Hartkopp
2020-11-09 10:26 ` [PATCH v4 2/7] can: rename get_can_dlc() macro with can_get_cc_len() Oliver Hartkopp
2020-11-09 10:26 ` [PATCH v4 3/7] can: remove obsolete get_canfd_dlc() macro Oliver Hartkopp
2020-11-09 10:26 ` [PATCH v4 4/7] can: replace can_dlc as variable/element for payload length Oliver Hartkopp
2020-11-09 12:59   ` Vincent MAILHOL
2020-11-09 15:38     ` Oliver Hartkopp [this message]
2020-11-09 10:26 ` [PATCH v4 5/7] can: update documentation for DLC usage in Classical CAN Oliver Hartkopp
2020-11-09 14:50   ` Vincent MAILHOL
2020-11-09 15:51     ` Oliver Hartkopp
2020-11-09 10:26 ` [PATCH v4 6/7] can-dev: introduce helpers to access Classical CAN DLC values Oliver Hartkopp
2020-11-09 10:26 ` [PATCH v4 7/7] can-dev: add len8_dlc support for various CAN USB adapters Oliver Hartkopp
2020-11-09 11:51 ` [PATCH v4 0/7] Introduce optional DLC element for Classic CAN 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=b33f7cc7-6bf3-363b-e328-a405ec4a2575@hartkopp.net \
    --to=socketcan@hartkopp.net \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=mkl@pengutronix.de \
    --cc=netdev@vger.kernel.org \
    /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).