Am Freitag, 4. Mai 2007 17:35 schrieb Alan Stern:
> On Fri, 4 May 2007, Oliver Neukum wrote:
> This isn't as bad as you think. usbcore makes no guarantees about the
> order of delivery of URBs for differing endpoints. Neither does the USB
> spec.
OK.
> All that matters is the order of URBs within each endpoint's queue. There
> you probably do want to kill them in reverse order of submission. Right
> now usb_hcd_endpoint_disable does it in the forward direction, but it
> would be easy to change -- replace list_for_each_entry() with
> list_for_each_entry_reverse().
Doable, but it doesn't help for ep0.
> When you unlink an URB, it's possible that some of the data might already
> have been transmitted. (The actual_length field will reflect this.) So
> you can't simply restart it when you want to resume.
This is news to me. :-( Bad news at that.
> A better approach would be to have a routine which would block until all
> URBs on an anchor have completed. With a timeout, so that they can be
> killed if they take too long.
I can't follow your logic here. The partial completion case has to be
handled anyway, so what is gained waiting?
Regards
Oliver
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
