linux-kernel - Re[2]: [PATCH] fix: add XHCI_SPURIOUS_SUCCESS to ASM1042 despite being a V0.96 controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 26 Sep 2022 12:25:49 +0000
From:   "Jens Glathe" <jens.glathe@...schoolsolutions.biz>
To:     "Mathias Nyman" <mathias.nyman@...ux.intel.com>,
        mathias.nyman@...el.com
Cc:     gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re[2]: [PATCH] fix: add XHCI_SPURIOUS_SUCCESS to ASM1042 despite being a V0.96
 controller

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@...ux.intel.com>
An "Jens Glathe" <jens.glathe@...schoolsolutions.biz>; 
mathias.nyman@...el.com
Cc gregkh@...uxfoundation.org; linux-usb@...r.kernel.org; 
linux-kernel@...r.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@...schoolsolutions.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