On Sat, Nov 23, 2024 at 12:25:35AM +0100, Michał Pecio wrote:
> On Fri, 22 Nov 2024 14:28:58 -0500, Alan Stern wrote:
> > > > Note that some class drivers treat -EPROTO as a fatal error. That
> > > > is, they don't retry and their completion-resubmission loop breaks
> > > > down.
> > >
> > > Well, that's on EHCI.
> >
> > No, it's the behavior of the class driver and is independent of the
> > type of host controller.
>
> xHCI has been doing things differently for over a decade as far as I
> see, and it seems to implement the usb_unlink_urb() rules absolutely
> literally (restart when everything is given back), except for the BH
> delay problem added later.
>
> Maybe it was a common "idiom" before xHCI, but it seems to rely on
> undocumented behavior, and other undocumented behaviors exist today
> that sloppy drivers might depend on.
I think you're misunderstanding what I wrote. I meant that several
class drivers have completion handlers that look like this:
urb_complete(struct usb_urb *urb, int status)
{
switch (status) {
...
case -EPROTO:
dev_warn(dev, "USB communication error\n");
return;
...
}
/* Process data from the URB */
...
usb_fill_bulk_urb(urb, ....);
usb_submit_urb(urb);
}
The driver works by resubmitting a single URB over and over again. But
when there's a -EPROTO error, it doesn't resubmit and the loop stops.
The driver doesn't do anything more after that; it becomes useless.
This behavior has nothing to do with EHCI or xHCI or any other type of
host controller. And overall it works, because -EPROTO errors hardly
ever occur except when a device is unplugged.
> So I don't know, it seems risky either way.
This approach is only a little risky, in the sense that the driver
might die in a situation where it didn't really need to -- but that
outcome is most unlikely. There is no risk of further communication
errors or data corruption.
Alan Stern
