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

PCI: mvebu: split PCIe BARs into multiple MBus windows when needed

2017-03-03T10:44:50+00:00

commit 398f5d5e10b6b917cd9d35ef21d545b0afbada22 upstream.

MBus windows are used on Marvell platforms to map certain peripherals
in the physical address space. In the PCIe context, MBus windows are
needed to map PCIe I/O and memory regions in the physical address.

However, those MBus windows can only have power of two sizes, while
PCIe BAR do not necessarily guarantee this. For this reason, the
current pci-mvebu breaks on platforms where PCIe devices have BARs
that don't sum up to a power of two size at the emulated bridge level.

This commit fixes this by allowing the pci-mvebu driver to create
multiple contiguous MBus windows (each having a power of two size) to
cover a given PCIe BAR.

To achieve this, two functions are added: mvebu_pcie_add_windows() and
mvebu_pcie_del_windows() to respectively add and remove all the MBus
windows that are needed to map the provided PCIe region base and
size. The emulated PCI bridge code now calls those functions, instead
of directly calling the mvebu-mbus driver functions.

Fixes: 45361a4fe446 ('pci: PCIe driver for Marvell Armada 370/XP systems')
Signed-off-by: Thomas Petazzoni 
Link: https://lkml.kernel.org/r/1397823593-1932-8-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: Use max_t() instead of max(resource_size_t,)

2017-03-03T10:44:50+00:00

commit 06489002a175680e18b4c0dd0beb6aff2a6d3781 upstream.

Use max_t() instead of max(resource_size_t,) in order to fix
the following checkpatch warning.

  WARNING: max() should probably be max_t(resource_size_t, SZ_64K, size)
  WARNING: max() should probably be max_t(resource_size_t, SZ_1M, size)

Signed-off-by: Jingoo Han 
Signed-off-by: Bjorn Helgaas 
Acked-by: Jason Cooper 
Signed-off-by: Jiri Slaby

powerpc/pci/rpadlpar: Fix device reference leaks

2017-01-26T16:40:19+00:00

commit 99e5cde5eae78bef95bfe7c16ccda87fb070149b upstream.

Make sure to drop any device reference taken by vio_find_node() when
adding and removing virtual I/O slots.

Fixes: 5eeb8c63a38f ("[PATCH] PCI Hotplug: rpaphp: Move VIO registration")
Signed-off-by: Johan Hovold 
Signed-off-by: Michael Ellerman 
Signed-off-by: Jiri Slaby

PCI: Check for PME in targeted sleep state

2017-01-26T16:39:10+00:00

commit 6496ebd7edf446fccf8266a1a70ffcb64252593e upstream.

One some systems, the firmware does not allow certain PCI devices to be put
in deep D-states.  This can cause problems for wakeup signalling, if the
device does not support PME# in the deepest allowed suspend state.  For
example, Pierre reports that on his system, ACPI does not permit his xHCI
host controller to go into D3 during runtime suspend -- but D3 is the only
state in which the controller can generate PME# signals.  As a result, the
controller goes into runtime suspend but never wakes up, so it doesn't work
properly.  USB devices plugged into the controller are never detected.

If the device relies on PME# for wakeup signals but is not capable of
generating PME# in the target state, the PCI core should accurately report
that it cannot do wakeup from runtime suspend.  This patch modifies the
pci_dev_run_wake() routine to add this check.

Reported-by: Pierre de Villemereuil 
Tested-by: Pierre de Villemereuil 
Signed-off-by: Alan Stern 
Signed-off-by: Bjorn Helgaas 
Acked-by: Rafael J. Wysocki 
CC: Lukas Wunner 
Signed-off-by: Jiri Slaby

PCI: Export pcie_find_root_port

2016-12-12T14:25:46+00:00

commit e784930bd645e7df78c66e7872fec282b0620075 upstream.

Export pcie_find_root_port() so we can use it outside of PCIe-AER error
injection.

Signed-off-by: Johannes Thumshirn 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Jiri Slaby

PCI: Use function 0 VPD for identical functions, regular VPD for others

2016-11-28T21:22:54+00:00

commit da2d03ea27f6ed9d2005a67b20dd021ddacf1e4d upstream.

932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0")
added PCI_DEV_FLAGS_VPD_REF_F0.  Previously, we set the flag on every
non-zero function of quirked devices.  If a function turned out to be
different from function 0, i.e., it had a different class, vendor ID, or
device ID, the flag remained set but we didn't make VPD accessible at all.

Flip this around so we only set PCI_DEV_FLAGS_VPD_REF_F0 for functions that
are identical to function 0, and allow regular VPD access for any other
functions.

[bhelgaas: changelog, stable tag]
Fixes: 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0")
Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
Acked-by: Myron Stowe 
Acked-by: Mark Rustad 
Signed-off-by: Jiri Slaby

PCI: Fix devfn for VPD access through function 0

2016-11-28T21:22:54+00:00

commit 9d9240756e63dd87d6cbf5da8b98ceb8f8192b55 upstream.

Commit 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function
0") passes PCI_SLOT(devfn) for the devfn parameter of pci_get_slot().
Generally this works because we're fairly well guaranteed that a PCIe
device is at slot address 0, but for the general case, including
conventional PCI, it's incorrect.  We need to get the slot and then convert
it back into a devfn.

Fixes: 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0")
Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
Acked-by: Myron Stowe 
Acked-by: Mark Rustad 
Signed-off-by: Jiri Slaby

PCI: Handle read-only BARs on AMD CS553x devices

2016-11-28T21:22:51+00:00

commit 06cf35f903aa6da0cc8d9f81e9bcd1f7e1b534bb upstream.

Some AMD CS553x devices have read-only BARs because of a firmware or
hardware defect.  There's a workaround in quirk_cs5536_vsa(), but it no
longer works after 36e8164882ca ("PCI: Restore detection of read-only
BARs").  Prior to 36e8164882ca, we filled in res->start; afterwards we
leave it zeroed out.  The quirk only updated the size, so the driver tried
to use a region starting at zero, which didn't work.

Expand quirk_cs5536_vsa() to read the base addresses from the BARs and
hard-code the sizes.

On Nix's system BAR 2's read-only value is 0x6200.  Prior to 36e8164882ca,
we interpret that as a 512-byte BAR based on the lowest-order bit set.  Per
datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to
avoid clearing any address bits if a platform uses only 64-byte alignment.

[js] pcibios_bus_to_resource takes pdev, not bus in 3.12

[bhelgaas: changelog, reduce BAR 2 size to 64]
Fixes: 36e8164882ca ("PCI: Restore detection of read-only BARs")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4
Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf
Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf
Reported-and-tested-by: Nix 
Signed-off-by: Myron Stowe 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Jiri Slaby

PCI: Limit config space size for Netronome NFP4000

2016-09-21T11:40:08+00:00

commit c2e771b02792d222cbcd9617fe71482a64f52647 upstream.

Like the NFP6000, the NFP4000 as an erratum where reading/writing to PCI
config space addresses above 0x600 can cause the NFP to generate PCIe
completion timeouts.

Limit the NFP4000's PF's config space size to 0x600 bytes as is already
done for the NFP6000.

The NFP4000's VF is 0x6004 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same
device ID as the NFP6000's VF.  Thus, its config space is already limited
by the existing use of quirk_nfp6000().

Signed-off-by: Simon Horman 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Jiri Slaby

PCI: Limit config space size for Netronome NFP6000 family

2016-09-21T11:40:07+00:00

commit 9f33a2ae59f24452c1076749deb615bccd435ca9 upstream.

The NFP6000 has an erratum where reading/writing to PCI config space
addresses above 0x600 can cause the NFP to generate PCIe completion
timeouts.

Limit the NFP6000's config space size to 0x600 bytes.

Signed-off-by: Jason S. McMullan 
[simon: edited changelog]
Signed-off-by: Simon Horman 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Jiri Slaby