linux-kernel - Re: [PATCH] usb: gadget: lpc32xx_udc: Port to new start/stop interface

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:	Fri, 17 Aug 2012 13:52:33 +0300
From:	Felipe Balbi <balbi@...com>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	Roland Stigge <stigge@...com.de>, balbi@...com,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	gregkh@...uxfoundation.org, arnd@...db.de, aletes.xgr@...il.com,
	kevin.wells@....com, srinivas.bakki@....com
Subject: Re: [PATCH] usb: gadget: lpc32xx_udc: Port to new start/stop
 interface

On Fri, Aug 17, 2012 at 11:42:15AM +0200, Sebastian Andrzej Siewior wrote:
> On 08/17/2012 11:10 AM, Roland Stigge wrote:
> >Also, since this device is a single controller in the LPC32xx SoC, I
> >would keep it until some other silicon uses several of this IP core
> >(which I doubt), at which point we would probably still keep the (global
> >static) controller and memcpy it to a dynamically allocated struct.
> >
> >Sounds reasonable?
> 
> Yes it does.
> 
> Some minor things:
> - please use to_udc() in start then
> - would it make sense to use platform_get_drvdata() in
>   lpc32xx_udc_shutdown() ?
> - could you please remove struct usb_endpoint_descriptor from struct
>   lpc32xx_ep? It has been removed a while back from other drivers.
> 
> Your proc_udc_show() makes me sad. Felipe, didn't we want something
> like this in udc-core?

Yes we do, though not a single file with a bunch of values. We want one
value per file as it should be.

-- 
balbi

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