linux-stable.git/drivers/pci, branch v5.0.4 Linux kernel stable tree PCI: pci-bridge-emul: Extend pci_bridge_emul_init() with flags 2019-03-23T19:11:27+00:00 Thomas Petazzoni thomas.petazzoni@bootlin.com 2019-02-20T09:48:41+00:00 2b9ef0bedaac2acc648a03bb519e4609661da6dc commit 33776d059630e5045ea9ccf756c74de8f9cc86de upstream. Depending on the capabilities of the PCI controller/platform, the PCI-to-PCI bridge emulation behavior might need to be different. For example, on platforms that use the pci-mvebu code, we currently don't support prefetchable memory BARs, so the corresponding fields in the PCI-to-PCI bridge configuration space should be read-only. To implement this, extend pci_bridge_emul_init() to take a "flags" argument, with currently one flag supported: PCI_BRIDGE_EMUL_NO_PREFETCHABLE_BAR that will make the prefetchable memory base and limit registers read-only. The pci-mvebu and pci-aardvark drivers are updated accordingly. Fixes: 1f08673eef123 ("PCI: mvebu: Convert to PCI emulated bridge config space") Reported-by: Luís Mendes <luis.p.mendes@gmail.com> Reported-by: Leigh Brown <leigh@solinno.co.uk> Tested-by: Leigh Brown <leigh@solinno.co.uk> Tested-by: Luis Mendes <luis.p.mendes@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Cc: Luís Mendes <luis.p.mendes@gmail.com> Cc: Leigh Brown <leigh@solinno.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 33776d059630e5045ea9ccf756c74de8f9cc86de upstream.

Depending on the capabilities of the PCI controller/platform, the
PCI-to-PCI bridge emulation behavior might need to be different. For
example, on platforms that use the pci-mvebu code, we currently don't
support prefetchable memory BARs, so the corresponding fields in the
PCI-to-PCI bridge configuration space should be read-only.

To implement this, extend pci_bridge_emul_init() to take a "flags"
argument, with currently one flag supported:

PCI_BRIDGE_EMUL_NO_PREFETCHABLE_BAR

that will make the prefetchable memory base and limit registers
read-only.

The pci-mvebu and pci-aardvark drivers are updated accordingly.

Fixes: 1f08673eef123 ("PCI: mvebu: Convert to PCI emulated bridge config space")
Reported-by: Luís Mendes <luis.p.mendes@gmail.com>
Reported-by: Leigh Brown <leigh@solinno.co.uk>
Tested-by: Leigh Brown <leigh@solinno.co.uk>
Tested-by: Luis Mendes <luis.p.mendes@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org
Cc: Luís Mendes <luis.p.mendes@gmail.com>
Cc: Leigh Brown <leigh@solinno.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PCI: pci-bridge-emul: Create per-bridge copy of register behavior 2019-03-23T19:11:27+00:00 Thomas Petazzoni thomas.petazzoni@bootlin.com 2019-02-20T09:48:40+00:00 d011c7871d16e81168faaccce9a977499f8a5f97 commit 59f81c35e0df840f7112cb296dde48df84a67c79 upstream. The behavior of the different registers of the PCI-to-PCI bridge is currently encoded in two global arrays, shared by all instances of PCI-to-PCI bridge emulation. However, we will need to tweak the behavior on a per-bridge basis, to accommodate for different capabilities of the platforms where this code is used. In preparation for this, create a per-bridge copy of the register behavior arrays, so that they can later be tweaked on a per-bridge basis. Fixes: 1f08673eef123 ("PCI: mvebu: Convert to PCI emulated bridge config space") Reported-by: Luís Mendes <luis.p.mendes@gmail.com> Reported-by: Leigh Brown <leigh@solinno.co.uk> Tested-by: Leigh Brown <leigh@solinno.co.uk> Tested-by: Luis Mendes <luis.p.mendes@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Cc: Luís Mendes <luis.p.mendes@gmail.com> Cc: Leigh Brown <leigh@solinno.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 59f81c35e0df840f7112cb296dde48df84a67c79 upstream.

The behavior of the different registers of the PCI-to-PCI bridge is
currently encoded in two global arrays, shared by all instances of
PCI-to-PCI bridge emulation.

However, we will need to tweak the behavior on a per-bridge basis, to
accommodate for different capabilities of the platforms where this
code is used. In preparation for this, create a per-bridge copy of the
register behavior arrays, so that they can later be tweaked on a
per-bridge basis.

Fixes: 1f08673eef123 ("PCI: mvebu: Convert to PCI emulated bridge config space")
Reported-by: Luís Mendes <luis.p.mendes@gmail.com>
Reported-by: Leigh Brown <leigh@solinno.co.uk>
Tested-by: Leigh Brown <leigh@solinno.co.uk>
Tested-by: Luis Mendes <luis.p.mendes@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: stable@vger.kernel.org
Cc: Luís Mendes <luis.p.mendes@gmail.com>
Cc: Leigh Brown <leigh@solinno.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PCI: pciehp: Disable Data Link Layer State Changed event on suspend 2019-03-23T19:11:27+00:00 Mika Westerberg mika.westerberg@linux.intel.com 2019-01-31T17:07:46+00:00 ee0bf8d6e7fca46dd8e53a7b97683cb57bb4c3fd commit bbe54ea5330d828cc396d451c0e1e5c3f9764c1e upstream. Commit 0e157e528604 ("PCI/PME: Implement runtime PM callbacks") tried to solve an issue where the hierarchy immediately wakes up when it is transitioned into D3cold. However, it turns out to prevent PME propagation on some systems that do not support D3cold. I looked more closely at what might cause the immediate wakeup. It happens when the ACPI power resource of the root port is turned off. The AML code associated with the _OFF() method of the ACPI power resource starts a PCIe L2/L3 Ready transition and waits for it to complete. Right after the L2/L3 Ready transition is started the root port receives a PME from the downstream port. The simplest hierarchy where this happens looks like this: 00:1d.0 PCIe Root Port ^ | v 05:00.0 PCIe switch #1 upstream port 06:01.0 PCIe switch #1 downstream hotplug port ^ | v 08:00.0 PCIe switch #2 upstream port It seems that the PCIe link between the two switches, before PME_Turn_Off/PME_TO_Ack is complete for the whole hierarchy, goes inactive and triggers PME towards the root port bringing it back to D0. The L2/L3 Ready sequence is described in PCIe r4.0 spec sections 5.2 and 5.3.3 but unfortunately they do not state what happens if DLLSCE is enabled during the sequence. Disabling Data Link Layer State Changed event (DLLSCE) seems to prevent the issue and still allows the downstream hotplug port to notice when a device is plugged/unplugged. Link: https://bugzilla.kernel.org/show_bug.cgi?id=202593 Fixes: 0e157e528604 ("PCI/PME: Implement runtime PM callbacks") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v4.20+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit bbe54ea5330d828cc396d451c0e1e5c3f9764c1e upstream.

Commit 0e157e528604 ("PCI/PME: Implement runtime PM callbacks") tried to
solve an issue where the hierarchy immediately wakes up when it is
transitioned into D3cold.  However, it turns out to prevent PME
propagation on some systems that do not support D3cold.

I looked more closely at what might cause the immediate wakeup.  It happens
when the ACPI power resource of the root port is turned off.  The AML code
associated with the _OFF() method of the ACPI power resource starts a PCIe
L2/L3 Ready transition and waits for it to complete.  Right after the L2/L3
Ready transition is started the root port receives a PME from the
downstream port.

The simplest hierarchy where this happens looks like this:

  00:1d.0 PCIe Root Port
    ^
    |
    v
    05:00.0 PCIe switch #1 upstream port
      06:01.0 PCIe switch #1 downstream hotplug port
        ^
        |
        v
        08:00.0 PCIe switch #2 upstream port

It seems that the PCIe link between the two switches, before
PME_Turn_Off/PME_TO_Ack is complete for the whole hierarchy, goes
inactive and triggers PME towards the root port bringing it back to D0.
The L2/L3 Ready sequence is described in PCIe r4.0 spec sections 5.2 and
5.3.3 but unfortunately they do not state what happens if DLLSCE is
enabled during the sequence.

Disabling Data Link Layer State Changed event (DLLSCE) seems to prevent
the issue and still allows the downstream hotplug port to notice when a
device is plugged/unplugged.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=202593
Fixes: 0e157e528604 ("PCI/PME: Implement runtime PM callbacks")
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org	# v4.20+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PCI: dwc: skip MSI init if MSIs have been explicitly disabled 2019-03-23T19:11:27+00:00 Lucas Stach l.stach@pengutronix.de 2019-02-27T16:52:19+00:00 0d5bc50f524afb84a882cb5f507c4aeeab08aa8a commit 3afc8299f39a27b60e1519a28e18878ce878e7dd upstream. Since 7c5925afbc58 (PCI: dwc: Move MSI IRQs allocation to IRQ domains hierarchical API) the MSI init claims one of the controller IRQs as a chained IRQ line for the MSI controller. On some designs, like the i.MX6, this line is shared with a PCIe legacy IRQ. When the line is claimed for the MSI domain, any device trying to use this legacy IRQs will fail to request this IRQ line. As MSI and legacy IRQs are already mutually exclusive on the DWC core, as the core won't forward any legacy IRQs once any MSI has been enabled, users wishing to use legacy IRQs already need to explictly disable MSI support (usually via the pci=nomsi kernel commandline option). To avoid any issues with MSI conflicting with legacy IRQs, just skip all of the DWC MSI initalization, including the IRQ line claim, when MSI is disabled. Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains hierarchical API") Tested-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3afc8299f39a27b60e1519a28e18878ce878e7dd upstream.

Since 7c5925afbc58 (PCI: dwc: Move MSI IRQs allocation to IRQ domains
hierarchical API) the MSI init claims one of the controller IRQs as a
chained IRQ line for the MSI controller. On some designs, like the i.MX6,
this line is shared with a PCIe legacy IRQ. When the line is claimed for
the MSI domain, any device trying to use this legacy IRQs will fail to
request this IRQ line.

As MSI and legacy IRQs are already mutually exclusive on the DWC core,
as the core won't forward any legacy IRQs once any MSI has been enabled,
users wishing to use legacy IRQs already need to explictly disable MSI
support (usually via the pci=nomsi kernel commandline option). To avoid
any issues with MSI conflicting with legacy IRQs, just skip all of the
DWC MSI initalization, including the IRQ line claim, when MSI is disabled.

Fixes: 7c5925afbc58 ("PCI: dwc: Move MSI IRQs allocation to IRQ domains hierarchical API")
Tested-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PCI: qcom: Don't deassert reset GPIO during probe 2019-03-23T19:11:27+00:00 Bjorn Andersson bjorn.andersson@linaro.org 2019-01-25T23:26:16+00:00 63a9e7ce6624ef0385a1c65bdae0708d3abb7f47 commit 02b485e31d98265189b91f3e69c43df2ed50610c upstream. Acquiring the reset GPIO low means that reset is being deasserted, this is followed almost immediately with qcom_pcie_host_init() asserting it, initializing it and then finally deasserting it again, for the link to come up. Some PCIe devices requires a minimum time between the initial deassert and subsequent reset cycles. In a platform that boots with the reset GPIO asserted this requirement is being violated by this deassert/assert pulse. Acquire the reset GPIO high to prevent this situation by matching the state to the subsequent asserted state. Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver") Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> [lorenzo.pieralisi@arm.com: updated commit log] Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 02b485e31d98265189b91f3e69c43df2ed50610c upstream.

Acquiring the reset GPIO low means that reset is being deasserted, this
is followed almost immediately with qcom_pcie_host_init() asserting it,
initializing it and then finally deasserting it again, for the link to
come up.

Some PCIe devices requires a minimum time between the initial deassert
and subsequent reset cycles. In a platform that boots with the reset
GPIO asserted this requirement is being violated by this deassert/assert
pulse.

Acquire the reset GPIO high to prevent this situation by matching the
state to the subsequent asserted state.

Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PCI/DPC: Fix print AER status in DPC event handling 2019-03-23T19:11:27+00:00 Dongdong Liu liudongdong3@huawei.com 2019-02-11T07:02:59+00:00 eafa704de27bbb428f83d282aabcb5087256aa77 commit 9f08a5d896ce43380314c34ed3f264c8e6075b80 upstream. Previously dpc_handler() called aer_get_device_error_info() without initializing info->severity, so aer_get_device_error_info() relied on uninitialized data. Add dpc_get_aer_uncorrect_severity() to read the port's AER status, mask, and severity registers and set info->severity. Also, clear the port's AER fatal error status bits. Fixes: 8aefa9b0d910 ("PCI/DPC: Print AER status in DPC event handling") Signed-off-by: Dongdong Liu <liudongdong3@huawei.com> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Keith Busch <keith.busch@intel.com> Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 9f08a5d896ce43380314c34ed3f264c8e6075b80 upstream.

Previously dpc_handler() called aer_get_device_error_info() without
initializing info->severity, so aer_get_device_error_info() relied on
uninitialized data.

Add dpc_get_aer_uncorrect_severity() to read the port's AER status, mask,
and severity registers and set info->severity.

Also, clear the port's AER fatal error status bits.

Fixes: 8aefa9b0d910 ("PCI/DPC: Print AER status in DPC event handling")
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Keith Busch <keith.busch@intel.com>
Cc: stable@vger.kernel.org	# v4.19+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PCI/ASPM: Use LTR if already enabled by platform 2019-03-23T19:11:27+00:00 Bjorn Helgaas bhelgaas@google.com 2019-01-04T23:59:07+00:00 bae1cf68370d3938f864da041e37cc96c3d7ba2b commit 10ecc818ea7319b5d0d2b4e1aa6a77323e776f76 upstream. RussianNeuroMancer reported that the Intel 7265 wifi on a Dell Venue 11 Pro 7140 table stopped working after wakeup from suspend and bisected the problem to 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR"). David Ward reported the same problem on a Dell Latitude 7350. After af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it"), we don't enable LTR unless the platform has granted LTR control to us. In addition, we don't notice if the platform had already enabled LTR itself. After 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR"), we avoid using LTR if we don't think the path to the device has LTR enabled. The combination means that if the platform itself enables LTR but declines to give the OS control over LTR, we unnecessarily avoided using ASPM L1.2. Link: https://bugzilla.kernel.org/show_bug.cgi?id=201469 Fixes: 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR") Fixes: af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it") Reported-by: RussianNeuroMancer <russianneuromancer@ya.ru> Reported-by: David Ward <david.ward@ll.mit.edu> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v4.18+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 10ecc818ea7319b5d0d2b4e1aa6a77323e776f76 upstream.

RussianNeuroMancer reported that the Intel 7265 wifi on a Dell Venue 11 Pro
7140 table stopped working after wakeup from suspend and bisected the
problem to 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't
have LTR").  David Ward reported the same problem on a Dell Latitude 7350.

After af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before
using it"), we don't enable LTR unless the platform has granted LTR control
to us.  In addition, we don't notice if the platform had already enabled
LTR itself.

After 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have
LTR"), we avoid using LTR if we don't think the path to the device has LTR
enabled.

The combination means that if the platform itself enables LTR but declines
to give the OS control over LTR, we unnecessarily avoided using ASPM L1.2.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=201469
Fixes: 9ab105deb60f ("PCI/ASPM: Disable ASPM L1.2 Substate if we don't have LTR")
Fixes: af8bb9f89838 ("PCI/ACPI: Request LTR control from platform before using it")
Reported-by: RussianNeuroMancer <russianneuromancer@ya.ru>
Reported-by: David Ward <david.ward@ll.mit.edu>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v4.18+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "PCI/PME: Implement runtime PM callbacks" 2019-03-13T21:01:31+00:00 Mika Westerberg mika.westerberg@linux.intel.com 2019-01-31T17:07:45+00:00 5b31a61305cd2ff9049f051a993796527b0ef7b5 commit c528f7bd362b097eeeafa6fbbeccd9750b79c7ba upstream. This reverts commit 0e157e52860441cb26051f131dd0b5ae3187a07b. Heiner reported that the commit in question prevents his network adapter from triggering PME and waking up when network cable is plugged. The commit tried to prevent root port waking up from D3cold immediately but looks like disabing root port PME interrupt is not the right way to fix that issue so revert it now. The patch following proposes an alternative solution to that issue. Link: https://bugzilla.kernel.org/show_bug.cgi?id=202103 Fixes: 0e157e528604 ("PCI/PME: Implement runtime PM callbacks") Reported-by: Heiner Kallweit <hkallweit1@gmail.com> Tested-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v4.20+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit c528f7bd362b097eeeafa6fbbeccd9750b79c7ba upstream.

This reverts commit 0e157e52860441cb26051f131dd0b5ae3187a07b.

Heiner reported that the commit in question prevents his network adapter
from triggering PME and waking up when network cable is plugged.

The commit tried to prevent root port waking up from D3cold immediately but
looks like disabing root port PME interrupt is not the right way to fix
that issue so revert it now.  The patch following proposes an alternative
solution to that issue.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=202103
Fixes: 0e157e528604 ("PCI/PME: Implement runtime PM callbacks")
Reported-by: Heiner Kallweit <hkallweit1@gmail.com>
Tested-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org	# v4.20+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'pci-v5.0-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci 2019-02-08T23:32:10+00:00 Linus Torvalds torvalds@linux-foundation.org 2019-02-08T23:32:10+00:00 70be9ac2b64c0d0db4f0e3004b764df33b1098e2 Pull PCI fix from Bjorn Helgaas: "Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX) that breaks PCIe on I.MX SoCs (Thinh Nguyen)" * tag 'pci-v5.0-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX) 
Pull PCI fix from Bjorn Helgaas:
 "Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX) that
  breaks PCIe on I.MX SoCs (Thinh Nguyen)"

* tag 'pci-v5.0-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI: Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX)
PCI: Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX) 2019-02-06T23:17:27+00:00 Thinh Nguyen thinh.nguyen@synopsys.com 2019-02-06T23:17:27+00:00 f57a98e1b71357713e44c57268a53d9c803f0626 There are at least four different parts with the same Vendor and Device ID ([16c3:abcd]): 1) Synopsys HAPS USB3 controller 2) Synopsys PCIe Root Port in Freescale/NXP i.MX6Q (reported by Lucas) 3) Synopsys PCIe Root Port in Freescale/NXP i.MX6QP (reported by Lukas) 4) Synopsys PCIe Root Port in Freescale/NXP i.MX7D (reported by Trent) The HAPS USB3 controller has a Class Code of PCI_CLASS_SERIAL_USB_XHCI, which means the XHCI driver would normally claim it. Previously, quirk_synopsys_haps() changed the Class Code of all [16c3:abcd] devices, including the Root Ports, to PCI_CLASS_SERIAL_USB_DEVICE to prevent the XHCI driver from claiming them so dwc3-haps can claim them instead. Changing the Class Code of the Root Ports prevents the PCI core from handling them as bridges, so devices below them don't work. Restrict the quirk so it only changes the Class Code for devices that start with the PCI_CLASS_SERIAL_USB_XHCI Class Code, leaving the Root Ports alone. Fixes: 03e6742584af ("PCI: Override Synopsys USB 3.x HAPS device class") Reported-by: Lukas F. Hartmann <lukas@mntmn.com> Reported-by: Trent Piepho <tpiepho@impinj.com> Reported-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> [bhelgaas: changelog] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> 
There are at least four different parts with the same Vendor and Device
ID ([16c3:abcd]):

  1) Synopsys HAPS USB3 controller
  2) Synopsys PCIe Root Port in Freescale/NXP i.MX6Q (reported by Lucas)
  3) Synopsys PCIe Root Port in Freescale/NXP i.MX6QP (reported by Lukas)
  4) Synopsys PCIe Root Port in Freescale/NXP i.MX7D (reported by Trent)

The HAPS USB3 controller has a Class Code of PCI_CLASS_SERIAL_USB_XHCI,
which means the XHCI driver would normally claim it.  Previously,
quirk_synopsys_haps() changed the Class Code of all [16c3:abcd] devices,
including the Root Ports, to PCI_CLASS_SERIAL_USB_DEVICE to prevent the
XHCI driver from claiming them so dwc3-haps can claim them instead.

Changing the Class Code of the Root Ports prevents the PCI core from
handling them as bridges, so devices below them don't work.

Restrict the quirk so it only changes the Class Code for devices that start
with the PCI_CLASS_SERIAL_USB_XHCI Class Code, leaving the Root Ports
alone.

Fixes: 03e6742584af ("PCI: Override Synopsys USB 3.x HAPS device class")
Reported-by: Lukas F. Hartmann <lukas@mntmn.com>
Reported-by: Trent Piepho <tpiepho@impinj.com>
Reported-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>