At Wed, 17 Feb 2010 19:29:34 -0800 (PST), you wrote >On Wed, 17 Feb 2010 mikedunn@xxxxxxxxxxx wrote: > >> Hi all, >> >> Does the usb subsystem impose any restrictions on mixing asynchronous >> (usb_submit_urb()) and synchronous (usb_bulk_msg(), et. al.) calls? For >>example, do the callbacks for asynchronously submitted urbs have to complete >>before a synchronous call is made? Or must locking be implemented to prevent >> a synchronous call from coinciding with an asynchronous call? I suspect at >>least the latter because usb_bulk_msg() started sometimes returning ETIMEDOUT >> when I stared calling usb_submit_urb() from a tasklet. > >The USB subsystem doesn't impose any restrictions of this sort. In >fact, at the core level there is no difference between synchronous and >asynchronous URBs. > >However, as Greg pointed out, if two different sets of URBs get >intermingled then it's quite likely they won't do what you want. The >USB subsystem will send them to the device just fine, but the device >will get confused. Should I interpret "intermingled" to mean "out-of-order"? From my understanding of the USB standard, I thought a transfer performed by the hardware can be considered atomic, assuming no race conditions in the controlling software. But I'm starting to think I'm mistaken about that. The device does seem confused, but I don't think the ordering of the messages would cause it. I should review the USB standard again, and maybe the xHCI standards as well. And look at a usb dump. Anyway, my question about the usbcore code is answered. Many thanks Alan and Greg! Mike ---- -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
