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

On Thursday 14 August 2008, Oliver Neukum wrote:
> Am Mittwoch 13 August 2008 21:54:09 schrieb Alan Stern:
> > On Wed, 13 Aug 2008, Inaky Perez-Gonzalez wrote:
> > > ...
> > > If the driver decided to reset the device, is because the device has to 
> > > be reset to bring it to a known state, so it should be completed.
> 
> That's an assumption. You code infrastructure. There's no basis to be sure
> that it'll be used only for error handling.
> 
> > I tend to agree.  Oliver is more concerned about this.
> 
> Two related reasons:
> 
> 1. Consistency
> A driver directly resetting a device after returning from disconnect()
> is buggy.
> 2. Guarantee to user space
> Now we guarantee to user space collectively that once all drivers are
> kicked off the device the device is user space's. User space can confidently
> do things like flashing the device's rom subject to proper locking
> in user space without fear of a reset initiated in the kernel.

Okay, so as it seems there is consensus that a delayed reset shouldn't
happen after disconnect returns, I'll bend to that. More on it on the other
thread.

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