linux-stable.git/drivers/pci/host, branch linux-3.16.y

PCI: tegra: Enable Relaxed Ordering only for Tegra20 & Tegra30

2019-11-22T15:57:30+00:00

commit 7be142caabc4780b13a522c485abc806de5c4114 upstream.

The PCI Tegra controller conversion to a device tree configurable
driver in commit d1523b52bff3 ("PCI: tegra: Move PCIe driver
to drivers/pci/host") implied that code for the driver can be
compiled in for a kernel supporting multiple platforms.

Unfortunately, a blind move of the code did not check that some of the
quirks that were applied in arch/arm (eg enabling Relaxed Ordering on
all PCI devices - since the quirk hook erroneously matches PCI_ANY_ID
for both Vendor-ID and Device-ID) are now applied in all kernels that
compile the PCI Tegra controlled driver, DT and ACPI alike.

This is completely wrong, in that enablement of Relaxed Ordering is only
required by default in Tegra20 platforms as described in the Tegra20
Technical Reference Manual (available at
https://developer.nvidia.com/embedded/downloads#?search=tegra%202 in
Section 34.1, where it is mentioned that Relaxed Ordering bit needs to
be enabled in its root ports to avoid deadlock in hardware) and in the
Tegra30 platforms for the same reasons (unfortunately not documented
in the TRM).

There is no other strict requirement on PCI devices Relaxed Ordering
enablement on any other Tegra platforms or PCI host bridge driver.

Fix this quite upsetting situation by limiting the vendor and device IDs
to which the Relaxed Ordering quirk applies to the root ports in
question, reported above.

Signed-off-by: Vidya Sagar 
[lorenzo.pieralisi@arm.com: completely rewrote the commit log/fixes tag]
Signed-off-by: Lorenzo Pieralisi 
Acked-by: Thierry Reding 
Signed-off-by: Ben Hutchings

PCI: mvebu: Fix I/O space end address calculation

2018-12-16T22:08:40+00:00

commit dfd0309fd7b30a5baffaf47b2fccb88b46d64d69 upstream.

pcie->realio.end should be the address of last byte of the area,
therefore using resource_size() of another resource is not correct, we
must substract 1 to get the address of the last byte.

Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout")
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Lorenzo Pieralisi 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

PCI: dwc: Fix uninitialized variable in dw_handle_msi_irq()

2017-08-26T01:14:28+00:00

commit 1b497e6493c49bbb55c89f53562f7f853495e90d upstream.

The bug is that "val" is unsigned long but we only initialize 32 bits of
it.  Then we test "if (val)" and that might be true not because we set the
bits but because some were never initialized.

Fixes: f342d940ee0e ("PCI: exynos: Add support for MSI")
Signed-off-by: Dan Carpenter 
Signed-off-by: Bjorn Helgaas 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

PCI: dwc: Unindent dw_handle_msi_irq() loop

2017-08-26T01:14:27+00:00

commit dbe4a09e8bbcf88809a8394d6a359d8cebd22a86 upstream.

Use "continue" to skip rest of the loop when possible to save an indent
level.  No functional change intended.

Suggested-by: walter harms 
Signed-off-by: Bjorn Helgaas 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

PCI: imx6: Move link up check into imx6_pcie_wait_for_link()

2016-04-30T22:05:44+00:00

commit 4d107d3b5a686b5834e533a00b73bf7b1cf59df7 upstream.

imx6_pcie_link_up() previously used usleep_range() to wait for the link to
come up.  Since it may be called while holding the config spinlock, the
sleep causes a "BUG: scheduling while atomic" error.

Instead of waiting for the link to come up in imx6_pcie_link_up(), do the
waiting in imx6_pcie_wait_for_link(), where we're not holding a lock and
sleeping is allowed.

[bhelgaas: changelog, references to bugzilla and f95d3ae77191]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100031
Fixes: f95d3ae77191 ("PCI: imx6: Wait for retraining")
Signed-off-by: Lucas Stach 
Signed-off-by: Bjorn Helgaas 
[bwh: Backported to 3.16: also update the retry loop in
 imx6_pcie_wait_for_link() as done upstream in commit 6cbb247e85eb
 ("PCI: designware: Wait for link to come up with consistent style")]
Signed-off-by: Ben Hutchings

PCI: imx6: Remove broken Gen2 workaround

2016-04-30T22:05:44+00:00

commit a77c5422d7586003643377afdb9915e76d07d21c upstream.

Remove the remnants of the workaround for erratum ERR005184 which was never
completely implemented.  The checks alone don't carry any value as we don't
act properly on the result.

A workaround should be added to the lane speed change in establish_link
later.

Signed-off-by: Lucas Stach 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Ben Hutchings

PCI: imx6: Move PHY reset into imx6_pcie_establish_link()

2016-04-30T22:05:44+00:00

commit 54a47a83421a3b7ee0e0fab7f65d04179bdf59b6 upstream.

This adds the PHY reset into a common error path of
imx6_pcie_establish_link(), deduplicating some of the debug prints.  Also
reduce the severity of the "no-link" message in the one place where it is
expected to be hit when no peripheral is attached.

Signed-off-by: Lucas Stach 
Signed-off-by: Bjorn Helgaas 
[bwh: Backported to 3.16:
 - Error paths were different in imx6_pcie_start_link()
 - Adjust context]
Signed-off-by: Ben Hutchings

PCI: imx6: Move imx6_pcie_reset_phy() near other PHY handling functions

2016-04-30T22:05:44+00:00

commit 53eeb48b49410a47a0309bbc0516534ad71c1350 upstream.

Move imx6_pcie_reset_phy() near the other PHY related functions in the
file.  This is a cosmetic change, but also allows to do the following
changes without introducing needless forward declarations.

Signed-off-by: Lucas Stach 
Signed-off-by: Bjorn Helgaas 
[bwh: Prerequisite for commit 4d107d3b5a68 ("PCI: imx6: Move link up check into
 imx6_pcie_wait_for_link()").
 Backported to 3.16: apply the relevant changes from commit 1c7fae18a1fb
 ("PCI: imx6: Use "u32", not "uint32_t"")]
Signed-off-by: Ben Hutchings

PCI: host: Mark PCIe/PCI (MSI) IRQ cascade handlers as IRQF_NO_THREAD

2016-02-02T19:09:18+00:00

commit 8ff0ef996ca00028519c70e8d51d32bd37eb51dc upstream.

On -RT and if kernel is booting with "threadirqs" cmd line parameter,
PCIe/PCI (MSI) IRQ cascade handlers (like dra7xx_pcie_msi_irq_handler())
will be forced threaded and, as result, will generate warnings like this:

  WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 handle_irq_event_percpu+0x14c/0x174()
  irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts
  Backtrace:
   (warn_slowpath_common) from (warn_slowpath_fmt+0x38/0x40)
   (warn_slowpath_fmt) from (handle_irq_event_percpu+0x14c/0x174)
   (handle_irq_event_percpu) from (handle_irq_event+0x84/0xb8)
   (handle_irq_event) from (handle_simple_irq+0x90/0x118)
   (handle_simple_irq) from (generic_handle_irq+0x30/0x44)
   (generic_handle_irq) from (dra7xx_pcie_msi_irq_handler+0x7c/0x8c)
   (dra7xx_pcie_msi_irq_handler) from (irq_forced_thread_fn+0x28/0x5c)
   (irq_forced_thread_fn) from (irq_thread+0x128/0x204)

This happens because all of them invoke generic_handle_irq() from the
requested handler.  generic_handle_irq() grabs raw_locks and thus needs to
run in raw-IRQ context.

This issue was originally reproduced on TI dra7-evem, but, as was
identified during discussion [1], other hosts can also suffer from this
issue.  Fix all them at once by marking PCIe/PCI (MSI) IRQ cascade handlers
IRQF_NO_THREAD explicitly.

[1] http://lkml.kernel.org/r/1448027966-21610-1-git-send-email-grygorii.strashko@ti.com

[bhelgaas: add stable tag, fix typos]
Signed-off-by: Grygorii Strashko 
Signed-off-by: Bjorn Helgaas 
Acked-by: Lucas Stach  (for imx6)
CC: Kishon Vijay Abraham I 
CC: Jingoo Han 
CC: Kukjin Kim 
CC: Krzysztof Kozlowski 
CC: Richard Zhu 
CC: Thierry Reding 
CC: Stephen Warren 
CC: Alexandre Courbot 
CC: Simon Horman 
CC: Pratyush Anand 
CC: Michal Simek 
CC: "Sören Brinkmann" 
CC: Sebastian Andrzej Siewior 
[ luis: backported to 3.16:
  - dropped changes to pci-dra7xx.c, pcie-spear13xx.c, pcie-xilinx.c
  - adjusted context ]
Signed-off-by: Luis Henriques

PCI: mvebu: Fix uninitialized variable in mvebu_get_tgt_attr()

2014-10-30T16:40:15+00:00

commit 56fab6e189441d714a2bfc8a64f3df9c0749dff7 upstream.

Geert Uytterhoeven reported a warning when building pci-mvebu:

  drivers/pci/host/pci-mvebu.c: In function 'mvebu_get_tgt_attr':
  drivers/pci/host/pci-mvebu.c:887:39: warning: 'rtype' may be used uninitialized in this function [-Wmaybe-uninitialized]
     if (slot == PCI_SLOT(devfn) && type == rtype) {
					 ^

And indeed, the code of mvebu_get_tgt_attr() may lead to the usage of rtype
when being uninitialized, even though it would only happen if we had
entries other than I/O space and 32 bits memory space.

This commit fixes that by simply skipping the current DT range being
considered, if it doesn't match the resource type we're looking for.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman