On Mon, Jan 07, 2019 at 01:47:19PM +0100, Jeroen Roovers wrote:
> On Thu, 20 Dec 2018 at 16:16, Stanislaw Gruszka <sgruszka@xxxxxxxxxx> wrote:
> >
> > Some USB host devices/drivers on some conditions can always return
> > EPROTO error on submitted URBs. That can cause infinity loop in the
> > rt2x00 driver.
> >
> > Since we can have single EPROTO errors we can not mark as device as
> > removed to avoid infinity loop. However we can count consecutive
> > EPROTO errors and mark device as removed if get lot of it.
> > I choose number 10 as threshold.
> >
> > Reported-and-tested-by: Randy Oostdyk <linux-kernel@xxxxxxxxxxx>
> > Signed-off-by: Stanislaw Gruszka <sgruszka@xxxxxxxxxx>
>
> > diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> > index 086aad22743d..60b8bccab83d 100644
> > --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> > +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
> > @@ -31,6 +31,22 @@
> > #include "rt2x00.h"
> > #include "rt2x00usb.h"
> >
> > +static bool rt2x00usb_check_usb_error(struct rt2x00_dev *rt2x00dev, int status)
> > +{
> > + if (status == -ENODEV || status == -ENOENT)
>
> I am not sure about this, but it looks to me like you would never see
> ENOENT, but ETIMEDOUT:
>
> https://github.com/torvalds/linux/blob/master/drivers/usb/core/message.c#L64
>
> In usb_start_wait_urb ETIMEDOUT is returned instead of ENOENT and
> passed up the chain.
>
> retval = (ctx.status == -ENOENT ? -ETIMEDOUT : ctx.status);
>
>
> Maybe I am wrong about this, but then again I have neither ever seen
> the driver respond to an ENOENT like this when an RT5592
> "disappeared".
According to Documentation/driver-api/usb/error-codes.rst
ENOENT is valid error code when interface does not exist or
when URB was unlinked.
Regards
Stanislaw
