There's no "simulating" involved: the driver is really getting disconnected from the device. Drivers that don't stop using the device at that point ("quiescing") are seriously (oopsably) buggy -- always have been. You're wrong here.Nope. If it's physically gone, you kill all urbs and in terms of USB you are done. Doing anything else with a device that is gone is indeed a bug.
Doing anything else on disconnect() is ALWAYS a bug.
The state of that interface doesn't matter until after aBut a physical disconnect is not the same thing as disconnecting the driver from the device. You do that to use the device afterwards. To do so it must be in a useable, known state. Simply calling the disconnect handler will _not_ ensure that. In fact as the disconnect handler must assume a physical disconnect, it cannot put the device into a known, useable state, as that would require communication with the device.
driver (later) binds to it, using probe() ... curiously
enough, probe() is where the code to put devices into a
usable state should already live. It's allowed to talk
to the device, and is expected to do things like assigning
the right altsetting for the interface (resetting endpoints
and other state).
In short: disconnect() kicks drivers off interfaces,
and probe() is there to do the converse. The scenario
you seem concerned about does not exist.
- Dave
-------------------------------------------------------
This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
