On 30.6.2020 16.08, Rik van Riel wrote: > I misread the code, it's not a bitfield, so state 1 means an endpoint marked > with running state. The next urb is never getting a response, though. > > However, the xhci spec says an endpoint is halted upon a babble error.
I was looking at the same, so according to specs this state shouldn't be possible. > > The code right above the babble handling case adds halted into the endpoint > state itself. Does the code handling the babble error need to do something > similar to trigger cleanup elsewhere? It's a flag to prevent ringing the doorbell for a halted endpoint. Anyway, reset endpoint is meant to recover an endpoint in a halted state. Resetting non-halted endpoints will just lead to a context state error, and besides, isoc endpoints shouldn't halt. Anyways, I haven't got any better idea at the moment. You can try and see what a forced reset does with: diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 2c255d0620b0..d79aca0df6d4 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1900,8 +1900,7 @@ static int xhci_requires_manual_halt_cleanup(struct xhci_hcd *xhci, * endpoint anyway. Check if a babble halted the * endpoint. */ - if (GET_EP_CTX_STATE(ep_ctx) == EP_STATE_HALTED) - return 1; + return 1; return 0; } Traces also showed thet endpoint doorbell was rang after th babble error, so we know that didn't help restarting the endpoint. -Mathias