On Mon, 13 Sep 2004, Ian Abbott wrote:
> FWIW, the ftdi_sio change looks okay by me, assuming you've tested
> it. (I haven't tested it myself yet and don't know much about
> usb_kill_urb, but if that's the way to go, then so be it!)
Here's a quick explanation of usb_kill_urb for anyone who's interested.
It's a new routine used for synchronous unlinking. From now on
usb_unlink_urb should only be used for asynchronous unlinking. If you
call usb_unlink_urb and your URB doesn't have the URB_ASYNC_UNLINK flag
set, you'll get a warning message in the system log and usb_kill_urb will
be called for you. At some point we'll get rid of that flag completely.
There are a few differences between the way usb_kill_urb works and
(synchronous) usb_unlink_urb used to work, all meant to improve its
usefulness for drivers:
usb_kill_urb returns void, and it cannot fail (unless something
is deeply wrong with usbcore or the HCD). By contrast,
usb_unlink_urb would fail if the URB happened to be in some
intermediate state, such as running in a completion handler.
While usb_kill_urb is running, the URB cannot be resubmitted.
If a completion handler tries to resubmit, it will receive a
-EPERM error. (Some handlers may need to be changed to cope
with such an error.)
When usb_kill_urb returns, the URB is guaranteed to be totally
idle. It's not in flight, it's not in some intermediate state,
and no completion handlers are running.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
