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 11:10:19 +0200
From:	Roland Stigge <stigge@...com.de>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC:	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	balbi@...com, 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

Hi,

On 08/16/2012 06:16 PM, Roland Stigge wrote:
> On 08/16/2012 06:05 PM, Sebastian Andrzej Siewior wrote:
>>> --- linux-2.6.orig/drivers/usb/gadget/lpc32xx_udc.c
>>> +++ linux-2.6/drivers/usb/gadget/lpc32xx_udc.c
>>> @@ -2987,14 +2986,14 @@ static irqreturn_t lpc32xx_usb_vbus_irq(
>>>       return IRQ_HANDLED;
>>>   }
>>>
>>> -static int lpc32xx_start(struct usb_gadget_driver *driver,
>>> -             int (*bind)(struct usb_gadget *))
>>> +static int lpc32xx_start(struct usb_gadget *gadget,
>>> +             struct usb_gadget_driver *driver)
>>>   {
>>> -    struct lpc32xx_udc *udc =&controller;
>>
>> I assume controller is a global var created at probe time and could be
>> removed now, right?
> 
> Yes!

Well ;-) looking more closely into it, I'd like to keep it for now: It
is a more complex statically pre-initialized struct, finally being used
in probe() for more dynamic initialization, and it ends up being used by
many other functions, including lpc32xx_start() where accessing it now
via container_of() is just a bit more elegant than a direct &controller
of the global variable.

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?

Thanks,

Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ