From: Marc Zyngier <marc.zyngier@arm.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH 0/2] Workaround for uPD72020x USB3 chips
Date: Mon, 10 Jul 2017 16:52:28 +0100 [thread overview]
Message-ID: <20170710155230.8622-1-marc.zyngier@arm.com> (raw)
Ard and myself have just spent quite some time lately trying to pin
down an issue in the DMA code which was taking the form of a PCIe USB3
controller issuing a DMA access at some bizarre address, and being
caught red-handed by the IOMMU.
After much head scratching and most of a week-end spent on tracing the
damn thing, I'm now convinced that the DMA code is fine, the XHCI
driver is correct, but that the HW (a Renesas uPD720202 chip) is a
nasty piece of work.
The issue is as follow:
- EFI initializes the controller using physical addresses above the
4GB limit (this is on an arm64 box where the memory starts at
0x80_00000000...).
- The kernel takes over, sends a XHCI reset to the controller, and
because we have an IOMMU sitting between the controller and memory,
provides *virtual* addresses. Trying to make things a bit faster for
our controller, it issues IOVAs in the low 4GB range).
- Low and behold, the controller is now issuing transactions with a
0x80 prefix in front of our IOVA. Yes, the same prefix that was
programmed during the EFI configuration. IOMMU fault, not happy.
If the kernel is hacked to only generate IOVAs that are more than
32bit wide, the HW behaves correctly. The only way I can explain this
behaviour is that the HW latches the top 32bit of the ERST (it is
always the ERST IOVA that appears in my traces) in some internal
register, and that the XHCI reset fails to clear it. Writing zero in
the top bits is not enough to clear it either.
So far, the only solution we have for this lovely piece of kit is to
force a PCI reset at probe time, which puts it right. The patches are
pretty ugly, but that's the best I could come up with so far.
Tested on a pair of AMD Opteron 1100 boxes with Renesas uPD720201 and
uPD720202 controllers.
Marc Zyngier (2):
PCI: Implement pci_reset_function_locked
usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB
controller
drivers/pci/pci.c | 35 +++++++++++++++++++++++++++++++++++
drivers/usb/host/pci-quirks.c | 20 ++++++++++++++++++++
drivers/usb/host/pci-quirks.h | 1 +
drivers/usb/host/xhci-pci.c | 7 +++++++
include/linux/pci.h | 1 +
5 files changed, 64 insertions(+)
--
2.11.0
next reply other threads:[~2017-07-10 15:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 15:52 Marc Zyngier [this message]
2017-07-10 15:52 ` [PATCH 1/2] PCI: Implement pci_reset_function_locked Marc Zyngier
2017-07-10 15:52 ` [PATCH 2/2] usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB controller Marc Zyngier
2017-07-17 12:02 ` Mathias Nyman
2017-07-10 17:21 ` [PATCH 0/2] Workaround for uPD72020x USB3 chips Ard Biesheuvel
2017-07-12 19:04 ` Ard Biesheuvel
2017-07-13 3:12 ` Bjorn Helgaas
2017-07-13 6:48 ` Ard Biesheuvel
2017-07-13 7:46 ` Marc Zyngier
2017-07-13 11:36 ` Bjorn Helgaas
2017-07-13 12:18 ` Marc Zyngier
2017-07-13 8:26 ` Greg Kroah-Hartman
2017-07-13 11:37 ` Bjorn Helgaas
2017-08-01 21:44 ` Bjorn Helgaas
2017-08-01 21:53 ` Ard Biesheuvel
2017-08-02 1:12 ` Bjorn Helgaas
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=20170710155230.8622-1-marc.zyngier@arm.com \
--to=marc.zyngier@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--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
all inboxes | Powered by JetHome®