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

[Oliver Neukum]

On 02.09.26 06:42, Michal Pecio wrote:
> On Wed,  2 Sep 2026 11:13:53 +1200, Julian Oes wrote:
> > On Tue, Sep 01, 2026 at 10:28:08AM +0200, Oliver Neukum 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.

Nasty.

> 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 think our record is better with -EPIPE.
The question is what we have to lose. Frankly, compared to the
status quo, nothing.
 
[..]

I don't have popcorn, but I do have cooled, sugar-free beverages ready.

> It seems there is only one risk of usb_clear_halt() in such cases:
> - you send a packet to an OUT endpoint
> - and the device accepts it but you never receive the ACK
> - even after re-sending three times
> - you call usb_clear_halt() and queue the same packet again
> - the device may accept the packet twice

I am afraid this is the time to be pedantic, because I don't
see the connection to usb_clear_halt().
The fundamental disagreement is on whether a packet has arrived
or not, isn't it? So the fundamental issue is whether IO should
be retried, not whether you clear a halt in between.

If you guess wrong you either transmit data twice or not at all.
And there is no generic mechanism to remedy that. Do you have
a proposal how one would look like?

However, eventually new data will need to be transmitted
or the device queried for newly received data. If that is to work,
we'll need to, well, do IO.
Our choices are whether

a) we retry IO before we do so
b) whether we try to clear a halt before that

Technically these decisions are independent of one another.
However, the spec says that we should clear a halt.
So I need to ask: Is there a situation in which we would
make matters worse by clearing the halt?
 

> One note about rate limiting: it would perhaps make sense to perform
> the first attempt ASAP and only slow down for retries. But arguably
> anything at all is better than just giving up like now.

And again, you make me ask whether a helper for that should
go into usbcore.

	Regards
		Oliver