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@xxxxxxxxxxxxxxx>
An "Jens Glathe" <jens.glathe@xxxxxxxxxxxxxxxxxxxxxx>;
mathias.nyman@xxxxxxxxx
Cc gregkh@xxxxxxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx;
linux-kernel@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxx>
---
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
