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

Am Mittwoch 13 August 2008 21:54:09 schrieb Alan Stern:
> On Wed, 13 Aug 2008, Inaky Perez-Gonzalez wrote:
> 
> > > 	What happens if a driver requests a reset and then is unbound
> > > 	before the reset happens?
> > 
> > The reset is still pending until it happens -- the way I see it is: the
> > intention of the driver was to reset the device. The fact that it is 
> > delayed because it decided that from an atomic context is a mere artifact.
> > 
> > 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.

The basic idea is good and will lead to better error handling but it belongs
on the interface level.

	Regards
		Oliver


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