Re: [PATCH v2] USB: serial: generic: recover from a stalled bulk-in endpoint

[Alan Stern <stern@rowland.harvard.edu>]

On Wed, Sep 02, 2026 at 06:42:04AM +0200, Michal Pecio wrote:
> What you are probably seeing is USB 2.0 hub(s) returning STALL
> handshake when a transaction attempt with downstream low/full-speed
> device fails three times. See USB 2.0 section 11.17.1 page 364.
> 
> If that's the case, the device endpoint isn't actually halted and you
> would see the traffic resume if you simply ignored the error and kept
> resubmitting until communication is restored.
> 
> That being said, calling usb_clear_halt() is indeed the only recovery
> supported by USB specs, both for -EPIPE and -EPROTO or similar. Linux
> has traditionally ignored this and things are quite broken sometimes,
> particularly with xhci-hcd, even if you call usb_clear_halt().
> 
> I suppose you can try this and see how it works, and if you run into
> xhci-hcd bugs we could try to fix them too. The -EPIPE case is easier
> because drivers don't rely on out of spec behavior of the USB stack.
> 
> Related discussion: (gonna need *a lot* of popcorn for that one)
> https://lore.kernel.org/linux-usb/261996a8-7ad4-4df2-a469-f6602da71255@suse.com/
> 
> Alan Stern tried to come up with some solution in USB core, but not sure
> how far that got.

For what it's worth, I did get started on that project and made some 
good progress.  But it started becoming rather complicated, particularly 
when taking into account that the core would need to stop trying to send 
Clear-Halt requests when it's about to do a Set-Interface or 
Set-Configuration, or handle a disconnection.  Then I got distracted 
with other things and never finished that part of the patch.

Maybe I can find time to go back and work on it some more.  It's likely 
to take a while...

Alan Stern