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? 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. 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. 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? Sarah Sharp -- 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
