linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Eli Billauer <eli.billauer@gmail.com>,
	Mathias Nyman <mathias.nyman@intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: xhci-ring: "needs XHCI_TRUST_TX_LENGTH quirk" in kernel log
Date: Tue, 12 Nov 2019 11:36:43 +0200	[thread overview]
Message-ID: <553d3af1-dcd6-0db2-094d-64e7aa749e23@linux.intel.com> (raw)
In-Reply-To: <5DCA343A.4000304@gmail.com>

On 12.11.2019 6.25, Eli Billauer wrote:
> Hello,
> 
> Connecting a custom designed (on FPGA) USB 3.0 device to a Renesas uPD720202 (1912:0015) and kernel v5.3.0, I get a lot of messages in the kernel log, while transmitting data at a high bandwidth through a BULK IN endpoint:
> 
> handle_tx_event: 36590 callbacks suppressed
> xhci_hcd 0000:03:00.0: WARN Successful completion on short TX for slot 1 ep 18: needs XHCI_TRUST_TX_LENGTH quirk?
> (last message repeated several times)
> 
> The driver in charge, as reported by lspci, is xhci_hcd.
> 
> Probably relevant details:
> 
> * The buffer size of the USB transactions is 32 kiB and up (with libusb). With e.g. 16 kiB buffers these log messages don't appear.
> * The device produces short packets occasionally. When only full-length packets are sent, these log messages don't appear.
> * Other than these log messages, everything works fine. In particular, there are no errors in the data exchange in either situation.
> * This problem doesn't happen when running the same test on an Intel B150 chipset’s USB 3.0 xHCI controller (8086:a12f).
> 
> I don't really know what this warning means, but this whole thing kind-of reminds the "WARN Event TRB for slot x ep y with no TDs queued" issue that was solved recently. Just a wild guess.
> 

It just means that we got an event from the xHC host saying the transfer was
completed with completion code "Success" even if we didn't get as many bytes as was requested.
Driver is expecting a completion code of Short Packet.

> Any idea how this can be fixed?
> 

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 1e0236e90687..687182afc59b 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -228,6 +228,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
         }
         if (pdev->vendor == PCI_VENDOR_ID_RENESAS &&
             pdev->device == 0x0015) {
+               xhci->quirks |= XHCI_TRUST_TX_LENGTH;
                 xhci->quirks |= XHCI_RESET_ON_RESUME;
                 xhci->quirks |= XHCI_ZERO_64B_REGS;
         }

You could give it a try and see if everything works normally.

But this quirk is now quite common.
Could make sense to get rid of it completely and just handle this case as default driver behavior.

-Mathias

  reply	other threads:[~2019-11-12  9:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12  4:25 xhci-ring: "needs XHCI_TRUST_TX_LENGTH quirk" in kernel log Eli Billauer
2019-11-12  9:36 ` Mathias Nyman [this message]
2019-11-12 12:03   ` Eli Billauer
2019-11-12 14:33     ` Mathias Nyman
2019-11-13 13:07       ` Eli Billauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=553d3af1-dcd6-0db2-094d-64e7aa749e23@linux.intel.com \
    --to=mathias.nyman@linux.intel.com \
    --cc=eli.billauer@gmail.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).