On Thu, 20 Dec 2018 at 16:16, Stanislaw Gruszka <[email protected]> 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 <[email protected]>
> Signed-off-by: Stanislaw Gruszka <[email protected]>
> 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".
Kind regards,
jer
