Hi, I have been wondering about it after seeing how it's done in xhci_hcd, which looks wrong to me. USB 2.0 spec 5.7.5/5.8.5 states that halt condition due to either STALL handshake or "transmission error" should cause both the device and host endpoints to be reset. I presume "transmission error" means any error detected by the HC which causes it to halt, various examples exist. USB 3.0 just refers to USB 2.0. Linux appears to ignore this part and only reset on STALL handshake, as advised in Documentation/driver-api/usb/error-codes.rst and practiced by drivers - they don't seem to bother with usb_clear_halt() on -EPROTO. This wouldn't necessarily be bad in itself, but: On the HCD side, xHCI will: - give back the current URB with -EPROTO/-EPIPE status - reset the host side endpoint, clearing its toggle state - point the HC at the next URB if one exist - restart the endpoint without waiting for hcd->endpoint_reset() - ignore one subsequent call to hcd->endpoint_reset() For STALL, I think it's a little awkward, but acceptable. The ultimate result appears to be that all pending URBs are given back with -EPIPE and things start moving again after usb_clear_halt(). But if the device isn't stalled, the next URB may execute right away if the failure was transient. This makes it impossible to ensure in-order delivery on bulk OUT pipes, because one URB is skipped and the driver has no reliable way to retry it before some later ones may get executed. This behavior also creates an opportunity for toggle mismatch, and as far as I understand, the hardware will resolve it by silently dropping one packet. Another could be dropped if usb_clear_halt() were called. Either I'm missing something, or it seems quite broken? I wonder what other HCDs are doing in this case, and what's the idea behind it all? Regards, Michal
