netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Kleine-Budde <mkl@pengutronix.de>
To: Oliver Hartkopp <socketcan@hartkopp.net>,
	linux-can@vger.kernel.org, mailhol.vincent@wanadoo.fr
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH v5 8/8] can-dev: add len8_dlc support for various CAN USB adapters
Date: Tue, 10 Nov 2020 08:46:32 +0100	[thread overview]
Message-ID: <d563bbf7-da72-83ce-a3c1-ebec828e0d5b@pengutronix.de> (raw)
In-Reply-To: <68005955-4bf3-cdef-f85d-a841eb336921@hartkopp.net>


[-- Attachment #1.1: Type: text/plain, Size: 2231 bytes --]

On 11/10/20 7:55 AM, Oliver Hartkopp wrote:
>>> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c
>>> index 940589667a7f..cc0c30a33335 100644
>>> --- a/drivers/net/can/usb/gs_usb.c
>>> +++ b/drivers/net/can/usb/gs_usb.c
>>> @@ -330,10 +330,13 @@ static void gs_usb_receive_bulk_callback(struct urb *urb)
>>>   			return;
>>>   
>>>   		cf->can_id = hf->can_id;
>>>   
>>>   		cf->len = can_cc_dlc2len(hf->len);
>>> +		cf->len8_dlc = can_get_len8_dlc(dev->can.ctrlmode, cf->len,
>>> +						hf->len);
>>
>> What about introducing a function that sets len and len8_dlc at the same time:
>>
>> void can_frame_set_length(const struct can_priv *can, struct can_frame *cfd, u8
>> dlc);
> 
> Good idea.
> 
> I would suggest something like
> 
> u8 can_get_cc_len(const u32 ctrlmode, struct can_frame *cf, u8 dlc)
> 
> that still returns the 'len' element, so that we can replace 
> can_cc_dlc2len() with can_get_cc_len() for CAN drivers that add support 
> for len8_dlc.

The regex to replace can_cc_dlc2len() with can_get_cc_len() might be simpler,
but passing the cf by reference _and_ assigning the return value to a member of
cf looks strange.

> The assignment cf->len = can_get_cc_len() fits better into the code 
> which assigns cf->can_id too.
> 
> And I would stay on 'u32 ctrlmode' as ctrlmode is the parameter which is 
> namely needed here. A pointer to can_priv can mean anything.

OK
>> And maybe a function that takes a canfd_frame, so that we don't need to cast....
> 
> No. The len8_dlc element is from struct can_frame. When people use the 
> struct canfd_frame in their driver this might have some benefits for them.
> But when it comes to access the len8_dlc element this has to be casted IMO.
> 
> But with the suggested can_get_cc_len() function a needed cast could be 
> put into the parameter list without adding extra code somewhere else in 
> the driver.

OK

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: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-11-10  7:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 15:36 [PATCH v5 0/8] Introduce optional DLC element for Classic CAN Oliver Hartkopp
2020-11-09 15:36 ` [PATCH v5 1/8] can: add optional DLC element to Classical CAN frame structure Oliver Hartkopp
2020-11-09 15:36 ` [PATCH v5 2/8] can: rename get_can_dlc() macro with can_cc_dlc2len() Oliver Hartkopp
2020-11-09 15:36 ` [PATCH v5 3/8] can: remove obsolete get_canfd_dlc() macro Oliver Hartkopp
2020-11-09 15:36 ` [PATCH v5 4/8] can: replace can_dlc as variable/element for payload length Oliver Hartkopp
2020-11-09 15:36 ` [PATCH v5 5/8] can: rename CAN FD related can_len2dlc and can_dlc2len helpers Oliver Hartkopp
2020-11-09 15:36 ` [PATCH v5 6/8] can: update documentation for DLC usage in Classical CAN Oliver Hartkopp
2020-11-09 15:36 ` [PATCH v5 7/8] can-dev: introduce helpers to access Classical CAN DLC values Oliver Hartkopp
2020-11-09 15:36 ` [PATCH v5 8/8] can-dev: add len8_dlc support for various CAN USB adapters Oliver Hartkopp
2020-11-09 20:12   ` Marc Kleine-Budde
2020-11-10  6:55     ` Oliver Hartkopp
2020-11-10  7:46       ` Marc Kleine-Budde [this message]
2020-11-10 10:18         ` 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=d563bbf7-da72-83ce-a3c1-ebec828e0d5b@pengutronix.de \
    --to=mkl@pengutronix.de \
    --cc=linux-can@vger.kernel.org \
    --cc=mailhol.vincent@wanadoo.fr \
    --cc=netdev@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 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).