[lkml]   [2003]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-usb-devel] Re: [OOPS, usbcore, releaseintf] 2.6.0-test10-mm1
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

Alan Stern

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:59    [W:0.082 / U:14.484 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site