Back around the 4.13 timeframe, we tried to address a rather bad issue
with the Renesas uPD72020x USB3 controller family. They have trouble
with the programming of the base addresses which tend to stick on XHCI
reset. This makes transitionning from 64bit to 32bit addresses
completely unsafe. This was observed on a fairly popular arm64
platform (AMD Opteron 1100, which has all of its memory above 4GB).
The fix was to perform a PCI reset of the device, but we have had
multiple reports that this generated regressions (the controller not
being usable after the patch was applied).
This series reverts the problematic patch, and tries to address it in
a more constrained way. If the controller is behind an IOMMU (and only
in that case), we zero its base addresses before reseting it. In the
affected configuration, this has the effect of putting the device in a
state where the XHCI reset will be effective.
It must be noted that in the absence of an IOMMU (and maybe even in
its presence), this device is completely unsafe, and may silently
corrupt memory.
* From v1:
- Fixed stupid hunk misplacement, now properly moved back to patch 2
- Converted all quirks to BIT_ULL()
* From v2:
- Moved zeroing code to its own function
- Also perform the zeroing on hibernate
Marc Zyngier (3):
xhci: Allow more than 32 quirks
xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers
Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA
issue"
drivers/usb/host/pci-quirks.c | 20 ------------
drivers/usb/host/pci-quirks.h | 1 -
drivers/usb/host/xhci-pci.c | 15 ++++-----
drivers/usb/host/xhci.c | 71 +++++++++++++++++++++++++++++++++++++++++--
drivers/usb/host/xhci.h | 67 ++++++++++++++++++++--------------------
5 files changed, 108 insertions(+), 66 deletions(-)
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
