Re: [PATCH] usb, xhci, rt2800usb: do not perform Soft Retry

From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Andreas Hartmann <andihartmann@freenet.de>,
	Greg KH <greg@kroah.com>,
	stf_xl@wp.pl
Cc: linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org,
	Mathias Nyman <mathias.nyman@intel.com>,
	Bernhard <bernhard.gebetsberger@gmx.at>
Subject: Re: [PATCH] usb, xhci, rt2800usb: do not perform Soft Retry
Date: Fri, 22 Jan 2021 17:22:01 +0200	[thread overview]
Message-ID: <4690235c-9676-7985-12a1-b8bcfd195a43@linux.intel.com> (raw)
In-Reply-To: <b0025964-490d-d8a0-f9af-f916d44e4f52@maya.org>

On 22.1.2021 15.17, Andreas Hartmann wrote:
> 
> On 22.01.21 at 12:56 Greg KH wrote:
>> On Fri, Jan 22, 2021 at 11:43:42AM +0100, stf_xl@wp.pl wrote:
>>> From: Stanislaw Gruszka <stf_xl@wp.pl>
>>>
>>> Since f8f80be501aa ("xhci: Use soft retry to recover faster from transaction
>>> errors") on some systems rt2800usb devices are unable to operate. Looks
>>> that due to firmware or hardware limitations of those devices, they
>>> require full recovery from USB Transaction Errors.
>>>
>>> To avoid the problem add URB transfer flag, that restore pre f8f80be501aa
>>> xhci behaviour when the flag is set. For now only add it only to rt2800usb
>>> driver.
>>
>> This feels like a really heavy hammer, to add a xhci flag for a single
>> broken device.
>>
>> Are you sure this is really needed?  What does this device do on other
>> operating systems, do they have such a quirk for their host controller
>> driver?
>>
>> Or is this due to the specific host controller device hardware?  Should
>> this be a xhci quirk for a specific pci device instead?
> 
> Well, rt2800usb USB implementation does have a lot of potential for
> optimization since the very beginning (current throughput comparison
> 2 MiB/s vs 13 MiB/s with the original driver e.g.). That's why I'm
> using until today a self patched version (it's bound to cfg80211
> meanwhile) of the original driver (rt5572sta), which doesn't have those
> problems at all. From my point of view, the goal should be to solve the
> real reason for the problem. The original driver works much better
> (leastwise here) and doesn't show this problem at all!

Ok, so it could be a rt2800 driver issue, or it just hitting some
unlucky sequence that triggers this.

>
> But anyway, there is from my point of view a basic problem with xhci_hcd,
> which just seems not to be completely backward compatible to existing USB 2
> drivers (see https://marc.info/?l=linux-usb&m=161130327411612&w=2) if the
> device is plugged to an USB 3.x interface.

This looks like a different issue, lets keep it in its own thread.

The xHCI usb host controller handles both USB 2 and USB 3 speeds.
If the USB port is connected to a xHC controller then the xhci driver will
be used. If the port is connected to a EHCI then the ehci driever is used.
EHCI does not support USB3 speeds.

It's very possible that something that worked behind a EHCI host has issues
when connected to a xHCI host.

-Mathias