Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"

This reverts commit 8466489ef5.

Now that we can properly reset the uPD72020x without a hard PCI reset,
let's get rid of the existing quirks.

Tested-by: Domenico Andreoli <domenico.andreoli@linux.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Tested-by: Faiz Abbas <faiz_abbas@ti.com>
Tested-by: Domenico Andreoli <domenico.andreoli@linux.com>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Marc Zyngier
2018-05-23 18:41:38 +01:00
committed by Greg Kroah-Hartman
parent 12de0a35c9
commit c2ef60fea2
3 changed files with 0 additions and 28 deletions

View File

@@ -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);