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 ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
