lkml.org 
[lkml]   [2003]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
done.

Alan Stern

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

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