Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Jens Glathe" <jens.glathe@oldschoolsolutions.biz>
To:     "Mathias Nyman" <mathias.nyman@linux.intel.com>,
        mathias.nyman@intel.com
Subject: Re[2]: [PATCH] fix: add XHCI_SPURIOUS_SUCCESS to ASM1042 despite being a V0.96
 controller
Cc:     gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
        linux-kernel@vger.kernel.org
Date:   Mon, 26 Sep 2022 12:25:49 +0000
Message-Id: <emdf9049cf-39a6-4c77-9c88-c1f08f179fc1@bea64cbc.com>
In-Reply-To: <c1857a88-2303-43d7-5539-37afd2401a12@linux.intel.com>
References: <20220925172236.2288-1-jens.glathe@oldschoolsolutions.biz>
 <c1857a88-2303-43d7-5539-37afd2401a12@linux.intel.com>
Reply-To: "Jens Glathe" <jens.glathe@oldschoolsolutions.biz>
User-Agent: eM_Client/9.1.2109.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
Precedence: bulk

Hi there,

thank you for the hint, I'll amend the commit text. For practical 
purposes you won't need to check for ASM1042/0x96, however according to 
documentation it *should* be a V1.0 XHCI controller. So, the defensive 
approach would be to check for it (so its a quirk only in this case), 
the outcome without checking would be the same. I can take it out, 
adding the quirk for ASM1042 would be sufficient.

with best regards

Jens

------ Originalnachricht ------
Von "Mathias Nyman" <mathias.nyman@linux.intel.com>
An "Jens Glathe" <jens.glathe@oldschoolsolutions.biz>; 
mathias.nyman@intel.com
Cc gregkh@linuxfoundation.org; linux-usb@vger.kernel.org; 
linux-kernel@vger.kernel.org
Datum 26.09.2022 13:31:42
Betreff Re: [PATCH] fix: add XHCI_SPURIOUS_SUCCESS to ASM1042 despite 
being a V0.96 controller

>Hi
>
>Thanks for the patch, some small changes still needed:
>
>Include subsystem in subject line, something like
>usb: xhci: Add XHCI_SPURIOUS...
>
>On 25.9.2022 20.22, Jens Glathe wrote:
>>only if it reports as a V0.96 XHCI controller. Appears to fix the errors
>>"xhci_hcd <address>; ERROR Transfer event TRB DMA ptr not part of
>>current TD ep_index 2 comp_code 13" that appear spuriously (or pretty
>>often) when using a r8152 USB3 ethernet adapter with integrated hub.
>>
>>Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
>>---
>>   drivers/usb/host/xhci-pci.c | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>>diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>index dce6c0ec8d34..d1b8e7148dd1 100644
>>--- a/drivers/usb/host/xhci-pci.c
>>+++ b/drivers/usb/host/xhci-pci.c
>>@@ -306,8 +306,12 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
>>   	}
>>     	if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
>>-		pdev->device == PCI_DEVICE_ID_ASMEDIA_1042_XHCI)
>>+		pdev->device == PCI_DEVICE_ID_ASMEDIA_1042_XHCI) {
>>+		/* try to tame the ASMedia 1042 controller which is 0.96 */
>>+		if (xhci->hci_version == 0x96)
>
>Do we need this 0x96 check? It's anyway set for 1.0 and newer controllers
>
>>+			xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
>
>This reminds me that I should get rid of this quirk.
>
>If we get a short transfers event for a TRB mid TD, then xhci hosts version 1.0 and later
>should send a second event for the last TRB in the TD
>
>so this is default behavior for modern xHCI, not a spurious event.
>
>But your patch is anyways needed for stable kernels.
>
>Thanks
>-Mathias