Hi Mathias, I would be grateful if you could take a look at patch 2/2 and tell if there is anything obviously wrong with this approach. As far as I see, it should be OK to just call those invalidation and giveback functions directly from xhci_urb_dequeue(), and it works for me in practice. Regarding the probem with xhci_invalidate_cancelled_tds() being called while Set TR Dequeue is already pending, I found that it is much easier to handle it by looking at SET_DEQ_PENDING and simply setting all TDs to TD_CLEARING_CACHE_DEFERRED if that's the case. So this is solved. However, these patches still don't solve the issue of infinite retries completely. There is one more annoying case caused by halts. It is very poorly defined what happens when a halted EP is hard-reset. Usually Set TR Dequeue executes afterwards and it restarts the EP when done. But if it doesn't, the EP stays stopped until a new URB is submitted, if ever. There is the EP_HARD_CLEAR_TOGGLE flag which is set until the class driver calls usb_clear_halt(), but it's neither the case that the EP is guaranteed to be stopped until usb_clear_halt() is called nor that it is guaranteed to restart afterwards. Actually, I think it might be a bug? What if Set TR Dequeue restarts an EP before the class driver clears the device side of the halt? I'm starting to think that it may not be realistic to quickly solve all those (and possibly other not known yet) problems now. Maybe just slap a 100ms timeout on those retries, add quirks for ASMedia/Intel and call it a day for now? Regards, Michal
