++Alan Hi, On Thu, Nov 21, 2024, Michał Pecio wrote: > 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. The class driver will know of this error, and the retry/recovery should be done at the class driver base on this error and not from the HCD. > > 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 > This long discussion may be relevant to your query: https://lore.kernel.org/linux-usb/ba06679f-93d2-4cb4-9218-9e288065bdfb@xxxxxxxxxxxxxxxxxxx/#t The concensus is that these error recovery should be handled by the class drivers. How they should be handled may be different between different OSes. If you follow the thread discussion, it may not necessarily a good idea to use usb_clear_halt() to recover. BR, Thinh
