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

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

2018-09-26T06:33:51+00:00

[ Upstream commit dfd0309fd7b30a5baffaf47b2fccb88b46d64d69 ]

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 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: keystone: Fix interrupt-controller-node lookup

2018-02-28T09:16:17+00:00

commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.

Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.

To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.

Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable      # 3.18
Acked-by: Murali Karicheri 
Signed-off-by: Johan Hovold 
[lorenzo.pieralisi@arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi 
[johan: backport to 4.4]
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

PCI: xilinx: Fix harmless format string warning

2017-05-08T05:44:10+00:00

commit abc596b9a2f3d24b8b0d637bdb071aae7f09801d upstream.

The xilinx PCIe driver prints a register value whose type is propagated to
the type returned by the GENMASK() macro.  Unfortunately, that type has
recently changed as the result of a bug fix, so now we get a warning about
the type:

  drivers/pci/host/pcie-xilinx.c: In function 'xilinx_pcie_clear_err_interrupts':
  drivers/pci/host/pcie-xilinx.c:154:3: warning: format '%d' expects argument of type 'int', but argument 4 has type 'long unsigned int' [-Wformat=]

Change the code so we always print the number as an 'unsigned long' type to
avoid the warning.  The original code was fine on 32-bit architectures but
not on 64-bit.  Now it works as expected on both.

Fixes: 00b4d9a1412 ("bitops: Fix shift overflow in GENMASK macros")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Bjorn Helgaas 
Acked-by: Maxime Coquelin 
Signed-off-by: Greg Kroah-Hartman

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

2016-02-10T03:56:22+00:00

[ Upstream commit 8ff0ef996ca00028519c70e8d51d32bd37eb51dc ]

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: stable@vger.kernel.org
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 

Signed-off-by: Sasha Levin

PCI: imx6: Use tabs for indentation

2016-02-10T03:56:22+00:00

[ Upstream commit d88a7ef99e4c15985e0d726d4a4e4c1f0e4f0ad5 ]

This patch fixes the following checkpatch error:

  ERROR: code indent should use tabs where possible

Signed-off-by: Jingoo Han 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin

PCI: spear: Drop __initdata from spear13xx_pcie_driver

2015-04-23T03:31:01+00:00

[ Upstream commit a43f32d647273023edddb0dc8f91c4c6378b252b ]

Struct spear13xx_pcie_driver was in initdata, but we passed a pointer to it
to platform_driver_register(), which can use the pointer at arbitrary times
in the future, even after the initdata is freed.  That leads to crashes.

Move spear13xx_pcie_driver and things referenced by it
(spear13xx_pcie_probe() and dw_pcie_host_init()) out of initdata.

[bhelgaas: changelog]
Fixes: 6675ef212dac ("PCI: spear: Fix Section mismatch compilation warning for probe()")
Signed-off-by: Matwey V. Kornilov 
Signed-off-by: Bjorn Helgaas 
Acked-by: Viresh Kumar 
CC: stable@vger.kernel.org	# v3.17+

Signed-off-by: Sasha Levin

PCI: designware: Reject MSI-X IRQs

2015-02-11T07:00:50+00:00

commit 19c5392eb1c1e81188e898400c0e8258827eb160 upstream.

The DesignWare PCIe MSI hardware does not support MSI-X IRQs.  Setting
those up failed as a side effect of a bug which was fixed by 91f8ae823f2b
("PCI: designware: Setup and clear exactly one MSI at a time").

Now that this bug is fixed, MSI-X IRQs need to be rejected explicitly;
otherwise devices trying to use them may end up with incorrectly working
interrupts.

Fixes: 91f8ae823f2b ("PCI: designware: Setup and clear exactly one MSI at a time")
Signed-off-by: Lucas Stach 
Signed-off-by: Bjorn Helgaas 
Acked-by: Jingoo Han 
Signed-off-by: Greg Kroah-Hartman

PCI: tegra: Use physical range for I/O mapping

2014-12-01T23:55:43+00:00

Commit 0b0b0893d49b ("of/pci: Fix the conversion of IO ranges into IO
resources") changed how I/O resources are parsed from DT.  Rather than
containing the physical address of the I/O region, the addresses will now
be in I/O address space.

On Tegra the union of all ranges is used to expose a top-level memory-
mapped resource for the PCI host bridge.  This helps to make /proc/iomem
more readable.

Combining both of the above, the union would now include the I/O space
region.  This causes a regression on Tegra20, where the physical base
address of the PCIe controller (and therefore of the union) is located at
physical address 0x80000000.  Since I/O space starts at 0, the union will
now include all of system RAM which starts at 0x00000000.

This commit fixes this by keeping two copies of the I/O range: one that
represents the range in the CPU's physical address space, the other for the
range in the I/O address space.  This allows the translation setup within
the driver to reuse the physical addresses.  The code registering the I/O
region with the PCI core uses both ranges to establish the mapping.

Fixes: 0b0b0893d49b ("of/pci: Fix the conversion of IO ranges into IO resources")
Reported-by: Marc Zyngier 
Tested-by: Marc Zyngier 
Suggested-by: Arnd Bergmann 
Signed-off-by: Thierry Reding 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Arnd Bergmann

PCI: xgene: Assign resources to bus before adding new devices

2014-11-13T16:53:30+00:00

The X-Gene PCIe driver assumes pci_scan_root_bus() assigns resources as
proposed in [1].  But we dropped patch [1] because it would break some
architectures, which means the X-Gene PCIe driver is currently broken.

Add calls to scan the bus, assign resources, and add devices in the X-Gene
driver to fix this.

[bhelgaas: changelog]
[1] http://lkml.kernel.org/r/1412000971-9242-11-git-send-email-Liviu.Dudau@arm.com
Signed-off-by: Duc Dang 
Signed-off-by: Tanmay Inamdar 
Signed-off-by: Bjorn Helgaas

PCI: imx6: Wait for clocks to stabilize after ref_en

2014-10-29T16:11:54+00:00

For boards without a reset GPIO we skip the delay between enabling the
pcie_ref_clk and touching the RC registers for configuration.  This hangs
the system if there isn't a proper delay to ensure the clocks are settled
in the DW PCIe core.

Also iMX6Q always needs an additional 10us delay to make sure the reset is
propagated through the core, as we don't have an explicitly controlled
reset input on this SoC.

This fixes a problem with 3fce0e882f61 ("PCI: imx6: Delay enabling
reference clock for SS until it stabilizes"): the kernel doesn't boot on
systems that don't pass the PCI GPIO reset in the DTB.  This regression
affects mx6 nitrogen boards.

[bhelgaas: add regression info in changelog]
Fixes: 3fce0e882f61 ("PCI: imx6: Delay enabling reference clock for SS until it stabilizes")
Reported-by: Fabio Estevam 
Tested-by: Fabio Estevam 
Signed-off-by: Richard Zhu 
Signed-off-by: Bjorn Helgaas 
Acked-by: Lucas Stach