On Tue, 3 Dec 2002, David Brownell wrote:
> >>>I think you're right here; there are (at least) 3 things that need to
> >>>be done when disconnecting a driver from a device (interface):
> >>>
> >>>1. The driver must stop using the interface.
> >>>2. All pending URBs must be aborted.
> >>>3. The device (or interface) should be placed into a stable/reset state.
> >>>
> >>>...
> >>
> >>#2 is currently the driver's responsibility, as part of #1;
> >>it's not really separarable, since if there were a pending URB
> >>that's not aborted, #1 wouldn't have been achieved.
> >
> >
> > a driver is supposed to abort URBs after a device is disconnected?
>
> It's supposed to do that in disconnect(), yes, for any
> urbs that haven't yet completed. In what way would it
> be possible to achieve #1 without #2 ??
As a variation on a theme, consider what the usb-storage driver does when
its disconnect() routine is called. It does not abort the outstanding
urbs, at least not directly. Instead, the disconnect() routine waits on a
semaphore (which is held whenever the device is busy). Eventually,
either:
(1). The current transaction will complete, all the urbs will be
finished, the semaphore will be released, and disconnect() can go about
its job -- it clears a flag to indicate the device is no longer connected
and then returns.
or
(2). If the device has physically disconnected, the ongoing
transaction would never complete normally. So in the fullness of time,
the SCSI layer will decide that the transaction is taking too long and
will ask the usb-storage driver to abort the transaction. At that point
the urbs are unlinked and the transaction completes with an error. Then
the semaphore is released and disconnect() is free to continue.
The net result is that the urbs do either complete or get cancelled, but
the driver itself doesn't really take responsibility for making sure this
happens. It's up to the SCSI layer to force an abort, if one is needed.
This can take some time, but it's guaranteed that disconnect() won't
return until things have settled down.
Admittedly, this may not be a very good general sort of model for most USB
device drivers.
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
