On Tue, 13 Aug 2013, Sarah Sharp wrote: > Hi Alan, > > Do you know if there's a chance that any USB drivers (or userspace) > would try to clear an endpoint halt when there are active URBs that have > not completed on for the endpoint? They might, but they shouldn't. It would be a bug. > I ask because in order to handle the case where userspace wants to reset > the toggles with a clear halt control transfer, but the endpoint is not > actually halted, the xHCI driver needs to wipe out the contents of the > endpoint ring and reset the dequeue pointer. (The dequeue pointer > alignment for the Configure Endpoint command forces us to set the > pointer the top of the ring, or every fourth TRB.) Re-initializing the > ring would be bad to do if there were pending URBs that hadn't been > canceled before the driver tried to clear the halt. > > I think it's pretty unlikely for this corner case to occur, but I could > potentially see a driver queueing multiple URBs to an endpoint, and > clearing the halt that occurred on the first URB, and then expecting the > other URB to complete successfully. What would happen under EHCI in > this case? There's a WARN_ONCE for this case, and the endpoint_reset call generated by the clear-halt is otherwise ignored. > Would it be OK to simply return the second URB with a -EPROTO in this > case? Or should we save the URBs, re-init the endpoint ring, requeue the > URB to the ring, and ring the endpoint doorbell? Pretty much anything you do will be okay. I recommend copying what ehci-hcd does. 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
