| Message ID | 20191127153015.58171-1-ardb@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | xhci: enable XHCI_TRUST_TX_LENGTH quirk for ThunderX2 builtin hosts | expand |
On 27.11.2019 17.30, Ard Biesheuvel wrote: > When using a USB webcam on a ThunderX2 workstation, the kernel log > gets flooded with messages like > > xhci_hcd 0000:00:0f.0: > WARN Successful completion on short TX for slot 7 ep 2: needs XHCI_TRUST_TX_LENGTH quirk? > > Enabling the quirk manually makes the issue go away, so let's enable > it unconditionally for this hardware. > This issue starts to be common for many vendors, many report successful completions after a initial short transfer in a TD Does the patch below help in your case? It worked for a Renesas controller with similar issues. It's a more generic solution. diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 9ebaa8e132a9..d23f7408c81f 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2381,7 +2381,8 @@ static int handle_tx_event(struct xhci_hcd *xhci, case COMP_SUCCESS: if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) break; - if (xhci->quirks & XHCI_TRUST_TX_LENGTH) + if (xhci->quirks & XHCI_TRUST_TX_LENGTH || + ep_ring->last_td_was_short) trb_comp_code = COMP_SHORT_PACKET; else xhci_warn_ratelimited(xhci,
On Wed, 27 Nov 2019 at 16:56, Mathias Nyman <mathias.nyman@linux.intel.com> wrote: > > On 27.11.2019 17.30, Ard Biesheuvel wrote: > > When using a USB webcam on a ThunderX2 workstation, the kernel log > > gets flooded with messages like > > > > xhci_hcd 0000:00:0f.0: > > WARN Successful completion on short TX for slot 7 ep 2: needs XHCI_TRUST_TX_LENGTH quirk? > > > > Enabling the quirk manually makes the issue go away, so let's enable > > it unconditionally for this hardware. > > > > This issue starts to be common for many vendors, many report successful > completions after a initial short transfer in a TD > > Does the patch below help in your case? It worked for a Renesas controller > with similar issues. It's a more generic solution. > > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c > index 9ebaa8e132a9..d23f7408c81f 100644 > --- a/drivers/usb/host/xhci-ring.c > +++ b/drivers/usb/host/xhci-ring.c > @@ -2381,7 +2381,8 @@ static int handle_tx_event(struct xhci_hcd *xhci, > case COMP_SUCCESS: > if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) > break; > - if (xhci->quirks & XHCI_TRUST_TX_LENGTH) > + if (xhci->quirks & XHCI_TRUST_TX_LENGTH || > + ep_ring->last_td_was_short) > trb_comp_code = COMP_SHORT_PACKET; > else > xhci_warn_ratelimited(xhci, Yes, that works too. If you roll that into a patch Tested-by: Ard Biesheuvel <ardb@kernel.org> and please consider cc'ing stable as well.
On 27.11.2019 18.16, Ard Biesheuvel wrote: > On Wed, 27 Nov 2019 at 16:56, Mathias Nyman > <mathias.nyman@linux.intel.com> wrote: >> >> On 27.11.2019 17.30, Ard Biesheuvel wrote: >>> When using a USB webcam on a ThunderX2 workstation, the kernel log >>> gets flooded with messages like >>> >>> xhci_hcd 0000:00:0f.0: >>> WARN Successful completion on short TX for slot 7 ep 2: needs XHCI_TRUST_TX_LENGTH quirk? >>> >>> Enabling the quirk manually makes the issue go away, so let's enable >>> it unconditionally for this hardware. >>> >> >> This issue starts to be common for many vendors, many report successful >> completions after a initial short transfer in a TD >> >> Does the patch below help in your case? It worked for a Renesas controller >> with similar issues. It's a more generic solution. >> >> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c >> index 9ebaa8e132a9..d23f7408c81f 100644 >> --- a/drivers/usb/host/xhci-ring.c >> +++ b/drivers/usb/host/xhci-ring.c >> @@ -2381,7 +2381,8 @@ static int handle_tx_event(struct xhci_hcd *xhci, >> case COMP_SUCCESS: >> if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) >> break; >> - if (xhci->quirks & XHCI_TRUST_TX_LENGTH) >> + if (xhci->quirks & XHCI_TRUST_TX_LENGTH || >> + ep_ring->last_td_was_short) >> trb_comp_code = COMP_SHORT_PACKET; >> else >> xhci_warn_ratelimited(xhci, > > Yes, that works too. If you roll that into a patch > > Tested-by: Ard Biesheuvel <ardb@kernel.org> > > and please consider cc'ing stable as well. > Will do, thanks -Mathias
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 1e0236e90687..331b5900dd72 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -256,7 +256,8 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci) if ((pdev->vendor == PCI_VENDOR_ID_BROADCOM || pdev->vendor == PCI_VENDOR_ID_CAVIUM) && pdev->device == 0x9026) - xhci->quirks |= XHCI_RESET_PLL_ON_DISCONNECT; + xhci->quirks |= XHCI_RESET_PLL_ON_DISCONNECT | + XHCI_TRUST_TX_LENGTH; if (xhci->quirks & XHCI_RESET_ON_RESUME) xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
When using a USB webcam on a ThunderX2 workstation, the kernel log gets flooded with messages like xhci_hcd 0000:00:0f.0: WARN Successful completion on short TX for slot 7 ep 2: needs XHCI_TRUST_TX_LENGTH quirk? Enabling the quirk manually makes the issue go away, so let's enable it unconditionally for this hardware. Cc: <stable@vger.kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- drivers/usb/host/xhci-pci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)