On Mon, 2 Dec 2002, David Brownell wrote:
> Oliver Neukum wrote:
> > Am Samstag, 30. November 2002 22:48 schrieb David Brownell:
> >
> >>In short, you're saying that request does exactly what
> >>it's intended to do.
> >
> >
> > Upon further thought, it doesn't. You see, simulating
> > a disconnect will not ensure that the device is in a usable
> > state. In fact, in a disconnect handler trying to quieten
> > a device would be wrong, but strictly speaking it's needed
> > here.
>
> 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.
I should have been more specific. Calling disconnect()
will disconnect the driver from the interface. But the
device will not be in the state it was before the driver
bound to the device, it will be in the state the driver
had put it before disconnect() was called plus the result
of some timeouts which probably have never been properly
tested.
It usually works because most drivers sit idle most of
the time.
But usually working is not good enough for a regular API.
Supporting unbinding a device from a driver needs support
from the driver itself.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
