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

On Wednesday 13 August 2008, Alan Stern wrote:
> On Wed, 13 Aug 2008, Oliver Neukum wrote:
> 
> > I don't like that for a facility that's not strictly needed
> > and could be implemented in an alternative way.
> > There are simply too many drivers (considering usbfs a driver) that have
> > trouble implementing pre/post_reset

Well, it's not strictly needed because before it was almost impossible to
do reset from an atomic context -- from previous conversations had in the
mailing lists , one of the resons suggested for the lack of final error
handling in many drivers was that.

What is the alternative way you were thinking of?

> The reset-device workqueue entry could be per-interface instead of
> per-device (stored in the usb_interface structure rather than the
> usb_device structure).  The locking would become a little more
> complicated but it would do what you want.

I don't see we are gaining anything from this--it was my first implementation
try though. However, resets are device-wide. It doesn't matter who is resetting
the device, an interface driver or a device-wide driver, the whole thing is 
going down. This is how it is now when you call usb_reset_device().

So if an interface driver calls usb_*_reset_device(), the rest of the intefaces
will have to suck it up, because they are going to be reset. We can't do anything
about it (other than hooking up the pre calls). 

But then, this call doesn't change any of that; this call just allows that same API 
function to be called from an atomic context in a safe way. I guess this is why I
I don't understand the controversy.

OTOH, there are a couple of little bugs I found I need to address...more on the
other subthread.

Thanks,

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