On Tue, 23 Jul 2013, Felipe Balbi wrote:
> Here's a newer version:
>
> commit 766ed104b6f420dc7587a63dc1679f78176d082e
> Author: Felipe Balbi
> Date: Wed Jul 17 11:09:49 2013 +0300
>
> usb: gadget: udc-core: move sysfs_notify() to a workqueue
>
> usb_gadget_set_state() will call
Hi,
On Mon, Jul 22, 2013 at 10:53:50AM -0400, Alan Stern wrote:
> On Mon, 22 Jul 2013, Felipe Balbi wrote:
>
> > indeed. Added a flush_work() call to usb_del_gadget_udc()
> >
> > > Also, what happens if two state transitions occur before the work queue
> > > gets around to executing the work ro
On Mon, 22 Jul 2013, Felipe Balbi wrote:
> indeed. Added a flush_work() call to usb_del_gadget_udc()
>
> > Also, what happens if two state transitions occur before the work queue
> > gets around to executing the work routine?
>
> do we need to care about that at all ? It's a queue anyway, trans
Hi,
On Thu, Jul 18, 2013 at 09:53:22AM -0400, Alan Stern wrote:
> On Thu, 18 Jul 2013, Felipe Balbi wrote:
>
> > usb_gadget_set_state() will call sysfs_notify()
> > which might sleep. Some users might want to call
> > usb_gadget_set_state() from the very IRQ handler
> > which actually changes the
On Thu, 18 Jul 2013, Felipe Balbi wrote:
> usb_gadget_set_state() will call sysfs_notify()
> which might sleep. Some users might want to call
> usb_gadget_set_state() from the very IRQ handler
> which actually changes the gadget state.
>
> Instead of having every UDC driver add their own
> workqu
usb_gadget_set_state() will call sysfs_notify()
which might sleep. Some users might want to call
usb_gadget_set_state() from the very IRQ handler
which actually changes the gadget state.
Instead of having every UDC driver add their own
workqueue for such a simple notification, we're
adding it gene
