Re: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1

[Alan Stern]

On Sat, 13 Dec 2003, Oliver Neukum wrote:

> > Hoever the consequent changes to the device structure (i.e., everything
> > needed to reflect the fact that it is disconnected) could be done in
> > another thread.
> 
> Please clarify. You have to disconnect() before you do the physical reset.

No you don't.  In fact, that would defeat one of the purposes of
usb_reset_device, which is to re-initialize the device while leaving an 
existing driver bound to it (so far as I know that feature is only used by 
usb-storage).  It's a last-ditch form of error recovery.

The API has an admitted weak spot when more than one driver is bound to 
the device.  No one has settled on a definite policy for how to handle 
that situation.

> IMHO you should do the code paths for late errors and the device morphed
> case in another thread, but what's the benefit for success?

In the success case there are no errors, the device hasn't morphed, and 
there's no need to do anything in another thread.  The existing driver(s) 
can remain bound, usb_reset_device returns 0, and nothing more has to be 
done.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/