linux-kernel - Re: [PATCH v4 08/10] usb: gadget: remove useless parameter in alloc_ep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 29 Aug 2016 10:55:57 +0300
From:   Felipe Balbi <balbi@...nel.org>
To:     Felipe Ferreri Tonello <eu@...ipetonello.com>,
        linux-usb@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, Michal Nazarewicz <mina86@...a86.com>
Subject: Re: [PATCH v4 08/10] usb: gadget: remove useless parameter in alloc_ep_req()


Hi,

Felipe Ferreri Tonello <eu@...ipetonello.com> writes:
>> Felipe Ferreri Tonello <eu@...ipetonello.com> writes:
>>>> "Felipe F. Tonello" <eu@...ipetonello.com> writes:
>>>>> The default_length parameter of alloc_ep_req was not really necessary
>>>>> and gadget drivers would almost always create an inline function to pass
>>>>> the same value to len and default_len.
>>>>>
>>>>> So this patch also removes duplicate code from few drivers.
>>>>>
>>>>> Signed-off-by: Felipe F. Tonello <eu@...ipetonello.com>
>>>>> ---
>>>>>  drivers/usb/gadget/function/f_hid.c        | 10 ++--------
>>>>>  drivers/usb/gadget/function/f_loopback.c   |  9 +--------
>>>>>  drivers/usb/gadget/function/f_midi.c       | 10 ++--------
>>>>>  drivers/usb/gadget/function/f_sourcesink.c | 11 ++---------
>>>>>  drivers/usb/gadget/u_f.c                   |  7 +++----
>>>>>  drivers/usb/gadget/u_f.h                   |  3 +--
>>>>>  6 files changed, 11 insertions(+), 39 deletions(-)
>>>>>
>>>>> diff --git a/drivers/usb/gadget/function/f_hid.c b/drivers/usb/gadget/function/f_hid.c
>>>>> index 51980c50546d..e82a7468252e 100644
>>>>> --- a/drivers/usb/gadget/function/f_hid.c
>>>>> +++ b/drivers/usb/gadget/function/f_hid.c
>>>>> @@ -362,12 +362,6 @@ static int f_hidg_open(struct inode *inode, struct file *fd)
>>>>>  /*-------------------------------------------------------------------------*/
>>>>>  /*                                usb_function                             */
>>>>>  
>>>>> -static inline struct usb_request *hidg_alloc_ep_req(struct usb_ep *ep,
>>>>> -						    unsigned length)
>>>>> -{
>>>>> -	return alloc_ep_req(ep, length, length);
>>>>> -}
>>>>
>>>> actually, I prefer to keep these little helpers. I was recently playing
>>>> with adding SG list support to g_zero (I should have patches soon) and
>>>> it was actually very nice to have the sourcesink helper as I could just
>>>> ditch alloc_ep_req(). The change to the driver was local to
>>>> ss_alloc_ep_req() and nothing else changed :-)
>>>>
>>>
>>> Right, but then it is worth to have the helper function. In this
>>> particular case, I am removing a useless helper functions, especially
>>> that the previous patch removes the need for the optional parameter in
>>> alloc_ep_req.
>> 
>> it's a static inline :-) It won't do any bad to keep it. And, as I said,
>> if we want to ditch aloc_ep_req() eventually, then we have just one
>> place to patch ;-)
>
> Yes, sure. But why drop alloc_ep_req()?

because we can't find a generic way of allocating sglist with enough
entries :-) Some drivers (like f_fs.c) could actually have zero-copy
sglist by just pinning user pages with get_user_pages_fast() and
following with sg_alloc_from_pages().

g_zero, however, would just "emulate" sglist by just allocating a
statically sized sg table and initializing chunks of the linear req->buf
to each sg entry.

> So should I keep all these helper functions? If so, I actually still
> need to fix them to use the newer alloc_ep_req() API.

yeah, keeping the helper functions would be nice. IMHO, alloc_ep_req()
doesn't have a long life, but it's pretty good for the time being.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (801 bytes)