On Wed, 4 Dec 2002 [EMAIL PROTECTED] wrote: > On Tue, 3 Dec 2002, David Brownell wrote: > > > Yes, any new driver's probe() normally handles #3. For > > usbfs it's necessarily factored a bit differently, since > > there's no probe(), but it's still the responsibility of > > that driver. > > Provided that it can do so from every state. This is a very huge > assumption. Imagine a disconnect() during firmware download. > You'll have no problems finding devices you can hang this way. > We have eg. storage devices known buggy if control messages > arrive at an imopportune moment and HID devices which need > specific sequences of control messages.
Indeed. And should the user unplug the USB cable at just such a moment, there's very little that can be done when the device gets plugged back in. No device driver can handle a scenario like this, but it is reasonable to require that a logical disconnect (caused e.g. by rmmod, as opposed to a physical disconnect) be handled with a little more grace. Alan Stern ------------------------------------------------------- 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
