Oliver Neukum wrote:
No, but a _synchronous_ one might need to wait_ms(1) for the relevantHi,regarding this piece of code: spin_lock_irqsave (&ehci->lock, flags); ... Does this mean that any call to usb_unlink_urb() for an URB on EHCI with a spinlock held will fail?
hardware resource to become available, and that wouldn't be a good
thing with a spinlock held. (That was the line after your quote.)
Which of course is part of the definition of a synchronous unlink:
it blocks, ergo you're not allowed to make those calls when you
hold a spinlock.
In general I'd rather not have that wait_ms(), since HCDs shouldn't
block. Better to push the wait-till-ready loop up a level.
- Dave
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
