From: Shuah Khan <skhan@linuxfoundation.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: valentina.manea.m@gmail.com, shuah@kernel.org,
mailhol.vincent@wanadoo.fr, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org,
Hongren Zenithal Zheng <i@zenithal.me>,
Alan Stern <stern@rowland.harvard.edu>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] usbip: add USBIP_URB_* URB transfer flags
Date: Fri, 19 Aug 2022 11:09:50 -0600 [thread overview]
Message-ID: <f2cf1fad-143f-f09b-0874-7e68c675697c@linuxfoundation.org> (raw)
In-Reply-To: <Yv9J2d1bVe7Xntxu@kroah.com>
On 8/19/22 2:29 AM, Greg KH wrote:
>
> Overall, nice work, thanks for adding this, minor comments below:
>
> On Tue, Aug 16, 2022 at 03:57:11PM -0600, Shuah Khan wrote:
>> USBIP driver packs URB transfer flags in PDUs that are exchanged
>
> What is a "PDU"?
Protocol Data Unit - I will expand or reword to drop it.
[snip]
>> +-----------+--------+---------------------------------------------------+
>> | 0x14 | 4 | transfer_flags: possible values depend on the |
>> | | | URB transfer_flags (refer to URB doc in |
>
> You can drop the second "URB" here, as it's an USBIP document being
> referred to, right?
This refers to USB URB document. I can rephrase it to USBIP_URB transfer flags
as it is the API now.
>>
>> + /* Unpack the pdu to an urb (map USBIP_URB_* to URB_* flags) */
>
> No need to mention the mapping everywhere in these comments as the
> function handles that.
>
These comments were primarily added for making sure right mapping is done.
Will remove them.
>> + }
>> + pr_debug("%s: flag = %u map_flags = %u\n", __func__,
>> + flags, map_flags);
>
> When using pr_debug (or dev_dbg()), you already have access to the
> __func__ in the output automatically, so there's never a need to add it
> again, it would just show up twice.
>
Good point.
> Also, this should be dev_dbg(), as it's a driver, and you have access to
> the device being handled (well, it needs to be passed to the
> function...)
>
I am going to delete these - debug message isn't really needed.
>> +
>> + return map_flags;
>> +}
>> +
>> +static unsigned int usbip_to_urb(unsigned int flags)
>> +{
>> + unsigned int map_flags = 0;
>> + int loop;
>> +
>> + for (loop = 0; loop < NUM_USBIP_FLAGS; loop++) {
>> + if (flags & flag_map[loop].usbip_flag)
>> + map_flags |= flag_map[loop].urb_flag;
>> + }
>> + pr_debug("%s: flag = %u map_flags = %u\n", __func__,
>> + flags, map_flags);
>
> Same debug comment as above.
Same as above. I will just delete the message.
>
>> + * As a result of coying the transfer flags, they now have become part
>
> "coying"? :)
Thanks for catching this :)
>
>> + * of the API. Any changes to kernel flags now impact the USBIP user-space.
>> + * In addition, it will be compatibility problem between server and client.
>> + * These defines aren't directly referenced and it is an obscure usage
>> + * hidden away in the packets.
>
> No need to mention the history here, just say "here are the flags for
> the transfer types"
>
Will do.
>
>> + *
>> + * Add code to translate the values between the numbers used in userspace
>> + * and the numbers used in the kernel. This will help with any future
>> + * changes to kernel flags breaking the API.
>
> There's no code being added in this uapi file, so you might want to
> reword all of this. Possibly by removing most of it, as the history
> here might not be necessary to document.
>
Will do.
thanks for the review. Will send v2.
thanks,
-- Shuah
prev parent reply other threads:[~2022-08-19 17:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-16 21:57 [PATCH] usbip: add USBIP_URB_* URB transfer flags Shuah Khan
2022-08-19 8:29 ` Greg KH
2022-08-19 17:09 ` Shuah Khan [this message]
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=f2cf1fad-143f-f09b-0874-7e68c675697c@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=i@zenithal.me \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mailhol.vincent@wanadoo.fr \
--cc=shuah@kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=valentina.manea.m@gmail.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 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.