Re: [RFC/PATCH] USB reset on atomic context

On Thursday 14 August 2008, Alan Stern wrote:
> On Wed, 13 Aug 2008, Inaky Perez-Gonzalez wrote:
> 
> > 
> > b) if (cancel_work_sync(&udev->reset_ws))
> >             __usb_queue_reset_device(&udev->reset_ws)
> > 
> > In both cases, if there was a pending reset, it is executed before we
> > finish disconnecting the driver from the interface.
> 
> You've got the right idea, but doing it correctly will be more
> difficult owing to the locking.  The basic point is that when a driver
> unbinds, we should either wait for its queued reset to complete or
> cancel the queued reset.  IMO the most sensible action is to wait until
> the disconnect method returns and then cancel any queued reset.

Well, in this case the locking becomes moot -- it has been decided that
a reset scheduled from a .disconnect() should be killed, then the
"barrier" just kills it.

> > [note: I really want to avoid binding to the interface -- it becomes
> > messier]
> 
> See, now that's a completely different matter.  If you're not bound to 
> an interface then you're acting on behalf of the device as a whole -- 
> in which case this discussion is moot.

I guess v3 is going to be interface-based, as you guys seem to like
it way more.
 
> > Do you guys see any other places where that "barrier" should be done?
> 
> It is needed in usb_unbind_interface and in the "not registered" path 
> of usb_driver_release_interface.

ack

-- 
Inaky

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html