linux-stable.git/drivers/pci, branch v3.12.22

PCI: shpchp: Check bridge's secondary (not primary) bus speed

2014-06-09T13:53:43+00:00

commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc upstream.

When a new device is added below a hotplug bridge, the bridge's secondary
bus speed and the device's bus speed must match.  The shpchp driver
previously checked the bridge's *primary* bus speed, not the secondary bus
speed.

This caused hot-add errors like:

  shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch

Check the secondary bus speed instead.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251
Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core")
Signed-off-by: Marcel Apfelbaum 
Signed-off-by: Bjorn Helgaas 
Acked-by: Michael S. Tsirkin 
Signed-off-by: Jiri Slaby

PCI: mvebu: fix off-by-one in the computed size of the mbus windows

2014-06-09T13:53:38+00:00

commit b6d07e0273d3296cfbdc88145b8a00ddbefb310a upstream.

mvebu_pcie_handle_membase_change() and
mvebu_pcie_handle_iobase_change() do not correctly compute the window
size. PCI uses an inclusive start/end address pair, which requires a
+1 when converting to size.

This only worked because a bug in the mbus driver allowed it to
silently accept and round up bogus sizes.

Fix this by adding one to the computed size.

Fixes: 45361a4fe446 ('PCIe driver for Marvell Armada 370/XP systems')
Signed-off-by: Willy Tarreau 
Reviewed-By: Jason Gunthorpe 
Signed-off-by: Thomas Petazzoni 
Link: https://lkml.kernel.org/r/1397823593-1932-5-git-send-email-thomas.petazzoni@free-electrons.com
Tested-by: Neil Greatorex 
Acked-by: Bjorn Helgaas 
Signed-off-by: Jason Cooper 
Signed-off-by: Jiri Slaby

PCI: mvebu: Fix potential issue in range parsing

2014-05-15T07:55:03+00:00

commit 4f4bde1df33bde076f53325bdf2c6430cf85e1bb upstream.

The second parameter of of_read_number() is not the index, but a size.  As
it happens, in this case it may work just fine because of the conversion to
u32 and the favorable endianness on this architecture.

Fixes: 11be65472a427 ("PCI: mvebu: Adapt to the new device tree layout")
Tested-by: Thomas Petazzoni 
Signed-off-by: Jean-Jacques Hiblot 
Signed-off-by: Bjorn Helgaas 
Acked-by: Thomas Petazzoni 
Acked-by: Jason Cooper 
Signed-off-by: Jiri Slaby

PCI: designware: Fix iATU programming for cfg1, io and mem viewport

2014-05-05T12:24:35+00:00

commit 017fcdc30cdae18c0946eef1ece1f14b4c7897ba upstream.

This patch corrects iATU programming for cfg1, io and mem viewport.  Enable
ATU only after configuring it.

Signed-off-by: Mohit Kumar 
Signed-off-by: Ajay Khandelwal 
Signed-off-by: Bjorn Helgaas 
Acked-by: Jingoo Han 
Signed-off-by: Jiri Slaby

PCI: designware: Fix RC BAR to be single 64-bit non-prefetchable memory BAR

2014-05-05T12:24:35+00:00

commit dbffdd6862e67d60703f2df66c558bf448f81d6e upstream.

The Synopsys PCIe core provides one pair of 32-bit BARs (BAR 0 and BAR 1).
The BARs can be configured as follows:

  - One 64-bit BAR: BARs 0 and 1 are combined to form a single 64-bit BAR
  - Two 32-bit BARs: BARs 0 and 1 are two independent 32-bit BARs

This patch corrects 64-bit, non-prefetchable memory BAR configuration
implemented in dw driver.

Signed-off-by: Mohit Kumar 
Signed-off-by: Bjorn Helgaas 
Cc: Pratyush Anand 
Cc: Jingoo Han 
Cc: Arnd Bergmann 
Signed-off-by: Jiri Slaby

PCI: mvebu: move clock enable before register access

2014-04-13T14:33:22+00:00

commit b42285f66f871a9898a0e79e2d74bc7e7a101995 upstream.

The clock passed to PCI controller found on MVEBU SoCs may come from a
clock gate. This requires the clock to be enabled before any registers
are accessed. Therefore, move the clock enable before register iomap to
ensure it is enabled.

Signed-off-by: Sebastian Hesselbarth 
Signed-off-by: Jason Cooper 
Signed-off-by: Jiri Slaby

PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled

2014-03-24T08:44:57+00:00

commit 3cdeb713dc66057b50682048c151eae07b186c42 upstream.

Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left
them disabled"), pciehp surprise removal stopped working.

This happens because pci_reenable_device() on the hotplug bridge (used in
the pciehp_configure_device() path) clears the Interrupt Disable bit, which
apparently breaks the bridge's MSI hotplug event reporting.

Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
which is used by both pci_enable_device() and pci_reenable_device().  But
we use pci_reenable_device() after the driver may have enabled MSI or
MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.

This patch clears Interrupt Disable only when MSI/MSI-X has not been
enabled.

Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled
Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691
Reported-and-tested-by: Andreas Noever 
Signed-off-by: Bjorn Helgaas 
CC: Sarah Sharp 
Signed-off-by: Jiri Slaby

PCI: Drop warning about drivers that don't use pci_set_master()

2014-03-12T12:25:35+00:00

commit fbeeb822f6f45cadf154d7b7cff1c13537cd799d upstream.

f41f064cf4 ("PCI: Workaround missing pci_set_master in pci drivers") made
pci_enable_bridge() turn on bus mastering if the driver hadn't done so
already.  It also added a warning in this case.  But there's no reason to
warn about it unless it's actually a problem to enable bus mastering here.

This patch drops the warning because I'm not aware of any such problem.

Signed-off-by: Bjorn Helgaas 
CC: Paul Bolle 

Signed-off-by: Jiri Slaby

PCI: Enable INTx if BIOS left them disabled

2014-03-05T16:13:47+00:00

commit 1f42db786b14a31bf807fc41ee5583a00c08fcb1 upstream.

Some firmware leaves the Interrupt Disable bit set even if the device uses
INTx interrupts.  Clear Interrupt Disable so we get those interrupts.

Based on the report mentioned below, if the user selects the "EHCI only"
option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS
with the PCI_COMMAND_INTX_DISABLE bit set.

Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601
Reported-by: Chris Cheng 
Reported-and-tested-by: Jamie Chen 
Signed-off-by: Bjorn Helgaas 
CC: Sarah Sharp 
Signed-off-by: Jiri Slaby

PCI: mvebu: Use Device ID and revision from underlying endpoint

2014-03-05T16:13:47+00:00

commit 322a8e91844f4ae2093e0d3d8a318d0ef2596756 upstream.

Marvell SoCs place the SoC number into the PCIe endpoint device ID.  The
SoC stepping is placed into the PCIe revision. The old plat-orion PCIe
driver allowed this information to be seen in user space with a simple
lspci command.

The new driver places a virtual PCI-PCI bridge on top of these endpoints.
It has its own hard coded PCI device ID. Thus it is no longer possible to
see what the SoC is using lspci.

When initializing the PCI-PCI bridge, set its device ID and revision from
the underlying endpoint, thus restoring this functionality.  Debian would
like to use this in order to aid installing the correct DTB file.

Fixes: 45361a4fe4464 ("pci: PCIe driver for Marvell Armada 370/XP systems")
Signed-off-by: Andrew Lunn 
Signed-off-by: Bjorn Helgaas 
Acked-by: Thomas Petazzoni 
Acked-by: Jason Cooper 
Signed-off-by: Jiri Slaby