On 17/05/18 14:29, Greg KH wrote: > On Thu, May 17, 2018 at 01:58:36PM +0100, Marc Zyngier wrote: >> This reverts commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7. >> >> Now that we can properly reset the uPD72020x without a hard PCI reset, >> let's get rid of the existing quirks. >> >> Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> >> --- >> drivers/usb/host/pci-quirks.c | 20 -------------------- >> drivers/usb/host/pci-quirks.h | 1 - >> drivers/usb/host/xhci-pci.c | 7 ------- >> drivers/usb/host/xhci.c | 21 ++++++++++++--------- >> drivers/usb/host/xhci.h | 2 +- >> 5 files changed, 13 insertions(+), 38 deletions(-) >> >> diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c >> index 67ad4bb6919a..3625a5c1a41b 100644 >> --- a/drivers/usb/host/pci-quirks.c >> +++ b/drivers/usb/host/pci-quirks.c >> @@ -1268,23 +1268,3 @@ static void quirk_usb_early_handoff(struct pci_dev >> *pdev) >> } >> DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID, >> PCI_CLASS_SERIAL_USB, 8, quirk_usb_early_handoff); >> - >> -bool usb_xhci_needs_pci_reset(struct pci_dev *pdev) >> -{ >> - /* >> - * Our dear uPD72020{1,2} friend only partially resets when >> - * asked to via the XHCI interface, and may end up doing DMA >> - * at the wrong addresses, as it keeps the top 32bit of some >> - * addresses from its previous programming under obscure >> - * circumstances. >> - * Give it a good wack at probe time. Unfortunately, this >> - * needs to happen before we've had a chance to discover any >> - * quirk, or the system will be in a rather bad state. >> - */ >> - if (pdev->vendor == PCI_VENDOR_ID_RENESAS && >> - (pdev->device == 0x0014 || pdev->device == 0x0015)) >> - return true; >> - >> - return false; >> -} >> -EXPORT_SYMBOL_GPL(usb_xhci_needs_pci_reset); >> diff --git a/drivers/usb/host/pci-quirks.h b/drivers/usb/host/pci-quirks.h >> index 4ca0d9b7e463..63c633077d9e 100644 >> --- a/drivers/usb/host/pci-quirks.h >> +++ b/drivers/usb/host/pci-quirks.h >> @@ -16,7 +16,6 @@ void usb_asmedia_modifyflowcontrol(struct pci_dev *pdev); >> void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev); >> void usb_disable_xhci_ports(struct pci_dev *xhci_pdev); >> void sb800_prefetch(struct device *dev, int on); >> -bool usb_xhci_needs_pci_reset(struct pci_dev *pdev); >> bool usb_amd_pt_check_port(struct device *device, int port); >> #else >> struct pci_dev; >> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c >> index e0a0a12871e2..6372edf339d9 100644 >> --- a/drivers/usb/host/xhci-pci.c >> +++ b/drivers/usb/host/xhci-pci.c >> @@ -288,13 +288,6 @@ static int xhci_pci_probe(struct pci_dev *dev, const >> struct pci_device_id *id) >> >> driver = (struct hc_driver *)id->driver_data; >> >> - /* For some HW implementation, a XHCI reset is just not enough... */ >> - if (usb_xhci_needs_pci_reset(dev)) { >> - dev_info(&dev->dev, "Resetting\n"); >> - if (pci_reset_function_locked(dev)) >> - dev_warn(&dev->dev, "Reset failed"); >> - } >> - >> /* Prevent runtime suspending between USB-2 and USB-3 initialization */ >> pm_runtime_get_noresume(&dev->dev); >> >> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c >> index cd6b48c43007..07272d1ce32a 100644 >> --- a/drivers/usb/host/xhci.c >> +++ b/drivers/usb/host/xhci.c >> @@ -4923,16 +4923,19 @@ int xhci_gen_setup(struct usb_hcd *hcd, >> xhci_get_quirks_t get_quirks) >> >> /* >> * Some Renesas controllers get into a weird state if they are >> - * reset while programmed with 64bit addresses (they will >> - * preserve the top half of the address in internal, non >> - * visible registers). You end up with half the address coming >> - * from the kernel, and the other half coming from the >> - * firmware. Also, changing the programming leads to extra >> - * accesses even if the controller is supposed to be >> - * halted. The controller ends up with a fatal fault, and is >> - * then ripe for being properly reset. >> + * reset while programmed with 64bit addresses (they will preserve >> + * the top half of the address in internal, non visible >> + * registers). You end up with half the address coming from the >> + * kernel, and the other half coming from the firmware. Also, >> + * changing the programming leads to extra accesses even if the >> + * controller is supposed to be halted. The controller ends up with >> + * a fatal fault, and is then ripe for being properly reset. >> + * >> + * Special care is taken to only apply this if the device is behind >> + * an iommu. Doing anything when there is no iommu is definitely >> + * unsafe... >> */ >> - if (xhci->quirks & XHCI_ZERO_64B_REGS) { >> + if ((xhci->quirks & XHCI_ZERO_64B_REGS) && dev->iommu_group) { >> u64 val; >> int i; >> >> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h >> index 5ea0b52b49cc..758864767fd4 100644 >> --- a/drivers/usb/host/xhci.h >> +++ b/drivers/usb/host/xhci.h >> @@ -1831,7 +1831,7 @@ struct xhci_hcd { >> #define XHCI_HW_LPM_DISABLE (1 << 29) >> #define XHCI_SUSPEND_DELAY (1 << 30) >> #define XHCI_INTEL_USB_ROLE_SW (1 << 31) >> -#define XHCI_ZERO_64B_REGS (1 << 32) >> +#define XHCI_ZERO_64B_REGS (1ULL << 32) > > Why change this now? Didn't you just add it in the previous patch?
Because I'm a moron, applied the fixup to the wrong patch, and didn't do any further check... > And BIT_ULL() is what you want here, right? Works for me. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html