Re: correctly handling EPROTO

[Oliver Neukum <oneukum@suse.com>]

On 17.03.26 15:31, Alan Stern wrote:
> On Mon, Mar 16, 2026 at 08:32:59PM +0100, Oliver Neukum wrote:

> If this happens, it's a bug in the host controller driver.  All bulk and
> interrupt endpoint queues are supposed to stop when a transaction error
> occurs.  This is mentioned explicitly in the kerneldoc.

Good.
  
> Think about what needs to happen from the driver's point of view.  An
> URB completes with a -EPROTO (or similar) error.  We need to unlink all
> URBs queued to the same endpoint, wait for them to complete, and then
> try to recover from the error.  How should a core library routine handle
> this?

I am not sure.

> Luckily the core manages an URB queue for each endpoint (see
> usb_hcd_link_urb_to_ep()), so the routine will know what URBs need to be
> unlinked.  How will the driver's completion handler know to ignore these
> URBs when they complete?
> 
> Following the clear-halt, the URBs need to be resubmitted.  Should this
> be done by the driver or by the library routine?

My preference would be by the driver, because it is not clear whether
simply repeating the IO is the action the driver wants to take. The IO
may have become obsolete for example.
Yet the endpoint must be made usable again.

> When the library finishes its work, it needs to tell the driver either
> to start running again or to give up.  Presumably by means of some
> callback.

Yes, but we cannot assume that a full device reset is always the next
stage. Nor, and that really hurts, can we assume that only a single driver
of the device is involved.
  
> How will the library keep track of recent error recovery attempts?  It
> needs to know when to stop doing clear-halts & retries and instead issue
> a reset.  How will this reset interact with the driver's recovery
> mechanism?

In principle we know how a reset is handled, don't we?
Again, we cannot know whether a driver is the first, let alone only, driver
to request error handling.
If we decide to reset there is no point in clearing a halt and resubmitting
URBs would be wrong.

> It's a good deal of reasonably complex code, which should not be copied
> to every other USB driver.  While the approach is sound, the problem is
> finding a reasonable way to implement it.

How else would you handle errors of this kind. It seems to me that we
need to make the delays and number of retries tunable, but other than that
what can you do generically?

	Regards
		Oliver