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] [day] [month] [year] [list]
Date:   Tue, 30 Aug 2016 17:13:16 +0100
From:   Felipe Ferreri Tonello <eu@...ipetonello.com>
To:     Felipe Balbi <balbi@...nel.org>, 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()



On 29/08/16 08:55, Felipe Balbi wrote:
> 
> 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.

I see. :)

> 
>> 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.

Ok, I did it on my last patchset I sent, I think you already applied to
your tree.

-- 
Felipe

Download attachment "0x92698E6A.asc" of type "application/pgp-keys" (7178 bytes)

Powered by blists - more mailing lists