Re: [RFC PATCH 1/1] usb: ehci: Remove erroneous return of EPROTO upon detection of stall

[Greg KH]

On Mon, Aug 31, 2020 at 10:08:43AM -0600, Khalid Aziz wrote:
> With the USB 3.0/3.1 controller on MSI B450-A Pro Max motherboard,
> full speed and low speed devices see constant resets making
> keyboards and mouse unreliable and unusable. These resets are caused
> by detection of stall in qtd_copy_status() and returning EPROTO
> which in turn results in TT buffers in hub being cleared. Hubs do
> not seem to repsond well to this and seem to hang which causes
> further USB transactions to time out. A reset finally clears the
> issue until we repeat the cycle all over again.
> 
> Signed-off-by: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
> Cc: Khalid Aziz <khalid@xxxxxxxxxxxxxx>
> ---
>  drivers/usb/host/ehci-q.c | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
> index 8a5c9b3ebe1e..7d4b2bc4633c 100644
> --- a/drivers/usb/host/ehci-q.c
> +++ b/drivers/usb/host/ehci-q.c
> @@ -214,10 +214,6 @@ static int qtd_copy_status (
>  		 * When MMF is active and PID Code is IN, queue is halted.
>  		 * EHCI Specification, Table 4-13.
>  		 */
> -		} else if ((token & QTD_STS_MMF) &&
> -					(QTD_PID(token) == PID_CODE_IN)) {
> -			status = -EPROTO;
> -		/* CERR nonzero + halt --> stall */
>  		} else if (QTD_CERR(token)) {
>  			status = -EPIPE;
>  

Removing this check is not a good idea, any chance you can come up with
some other test instead for this broken hardware?

What about getting a USB hub that works?  :)

thanks,

greg k-h