On Wed, 12 Nov 2014, Felipe Balbi wrote: > If class driver wants to SetFeature(ENDPOINT_HALT) and > later tries to talk to the stalled endpoint, xhci will > move endpoint to EP_STATE_STALL and subsequent usb_submit_urb() > will not cause a USB token to be shifted into the data lines. > > Because of that, peripheral will never have any means of > STALLing a follow up token. > > This is a known error at least with g_zero + testusb -t 13 > and can be easily reproduced. Can you elaborate this description a bit more? I don't understand what the problem is. For instance, if an endpoint is halted then there's no reason for the controller to shift any USB tokens for it onto the data lines. Doing so would just be a waste of bandwidth, since the response is bound to be another STALL. And it doesn't matter that the peripheral has no means to STALL any follow-up tokens, since the host controller already knows the endpoint is halted. Of course, control endpoints behave differently from other ones. But that's not what you're talking about here, since test 13 is for bulk or interrupt endpoints. The comment in the patch talks about moving the dequeue pointer past the STALLed TD and then clearing the halt condition. Moving the dequeue pointer is fine -- there's no other way to take control of the TD back from the hardware -- but why would you want to clear the halt? The HCD isn't supposed to do that; the class driver is. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html