Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
To:     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>
References: <20210122104342.12451-1-stf_xl@wp.pl> <YAq9bt6q9dfk4F+F@kroah.com>
From:   Andreas Hartmann <andihartmann@freenet.de>
Subject: Re: [PATCH] usb, xhci, rt2800usb: do not perform Soft Retry
Message-ID: <b0025964-490d-d8a0-f9af-f916d44e4f52@maya.org>
Date:   Fri, 22 Jan 2021 14:17:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <YAq9bt6q9dfk4F+F@kroah.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk


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!

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.


Thanks
Andreas