Alan Stern wrote:
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 ...

or

	(2).  If the device has physically disconnected, the ongoing
transaction would never complete normally.  ...
I'd expect usb-storage should always hit case (1), given that case (2)
is the "unlink urbs" case (excluding completions due to hardware faults).


Admittedly, this may not be a very good general sort of model for most USB
device drivers.
In particular, drivers that do much in the way of recovering from
hardware faults in their completion routines will need to get
kicked from disconnect() ... since physical disconnect errors
look like hardware faults (and sometimes like halted endpoints),
except there's no way to recover from them.

- 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

Reply via email to