Re: correctly handling EPROTO

[Oliver Neukum <oneukum@suse.com>]

On 17.03.26 19:03, Alan Stern wrote:
> On Tue, Mar 17, 2026 at 05:20:37PM +0100, Oliver Neukum wrote:

> You know, with a USB-2 host controller, transaction errors don't make an
> endpoint unusable, and clear-halt isn't necessary.  I wonder if xhci-hcd
> couldn't be adjusted to behave the same way (issuing its own clear-halt
> internally, if that is needed).  That would make things simpler.

It could be. But do you want a HCD to generate requests to endpoint 0
on its own without coordination with usbcore or drivers bound to interfaces
of the device?

It would be an elegant solution, but I think it would bite us into our
posterior. E.g. what do we do if a reset is requested or somebody
wants to suspend the device or change the configuration or a setting?

> Another possibility is to change usbcore to automatically unlink all
> the endpoint's pending URBs as soon as a transaction error occurs.  Then
> drivers wouldn't have to worry about it.  But even then, drivers would
> need to know how to react when it happened.

Yes. That looks more plausible.

> Reset isn't always the next step.  In some cases the driver should just
> give up.  For instance, if the device has been unplugged.

Then we do not care. Signalling and detecting an unplug is not a driver's
task. A driver should leave enough time for that detection to happen, but
if usbcore does not eventually tell us that a device is gone, we need
to treat errors as genuine.

>> 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.
> 
> In practice, does resetting ever help?  With usb-storage and uas, yes,
> occasionally.  But those are unusual drivers; what about all the other
> ones?

They don't even try. UAS, storage and usbhid are the only drivers with
a full error handling. usbnet has vestiges. That is about it. Others
may try to clear a spurious halt and that's it.

Generically speaking, short of giving up, what is the generic alternative?
As far as other examples are concerned, isn't this scheme quite close
to what SCSI does in terms of algorithm?

>> 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?
> 
> You're right that those are the only things to be done.  The question is
> whether they can be done in a way that will be easy for all drivers to
> adopt.

Provide defaults, again best be copied from usbhid.

> Consider that while error recovery is in progress, the rest of the
> driver has to remain essentially dormant because the endpoint cannot be
> used.  I don't think many drivers are written to support such an
> operating mode.

Isn't that exactly what you have to do after pre_reset() and suspend()?
Nor do you have to use this facility, do you?

	Regards
		Oliver