On Thu, 25 Jun 2009, Sarah Sharp wrote: > What is the current behavior of EHCI, UHCI, and OHCI when an endpoint > stalls and there is more than one URB submitted to the hardware for that > endpoint? If one URB for the endpoint fails with an error status > because the endpoint stalled, do the rest of the URBs queued for that > endpoint get completed with the same status? Or do they just sit on the > hardware schedule until the driver clears the halt condition? This is all documented; see the kerneldoc for usb_unlink_urb(). Briefly, the other URBs just sit on the hardware schedule. > In xHCI, when an endpoint stalls, the queue of transfers for that > endpoint is removed from the hardware schedule, and I will get a stalled > completion for the first transfer on that queue. I have one of two > choices for what to do with the remaining transfers on the endpoint > queue: > > 1. I can complete those transfers with the same stalled status and let > the driver resubmit them later. This is wrong. > 2. I can leave the transfers on the queue, and allow the upper layer to > clear the halt condition. The xHCI HCD endpoint_reset function will > restart the ring, and the host will process those previously submitted > transfers. Host controller drivers could cancel the transfers before > clearing the halt condition, or after. This is right. > Both these options seem valid to me, but I want to emulate the behavior > of older host controllers so that USB 2.0 device drivers will run > smoothly under an xHCI host. Which option achieves that goal? Alan Stern -- 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
