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

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: Check for PME in targeted sleep state

2017-01-13T22:59:59+00:00

[ Upstream commit 6496ebd7edf446fccf8266a1a70ffcb64252593e ]

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: stable@vger.kernel.org
CC: Lukas Wunner 
Signed-off-by: Sasha Levin

PCI: Limit config space size for Netronome NFP4000

2016-09-03T03:42:11+00:00

[ Upstream commit c2e771b02792d222cbcd9617fe71482a64f52647 ]

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: Sasha Levin

PCI: Limit config space size for Netronome NFP6000 family

2016-09-03T03:42:11+00:00

[ Upstream commit 9f33a2ae59f24452c1076749deb615bccd435ca9 ]

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: Sasha Levin

PCI: Support PCIe devices with short cfg_size

2016-09-03T03:42:11+00:00

[ Upstream commit c20aecf6963d1273d8f6d61c042b4845441ca592 ]

If a device quirk modifies the pci_dev->cfg_size to be less than
PCI_CFG_SPACE_EXP_SIZE (4096), but greater than PCI_CFG_SPACE_SIZE (256),
the PCI sysfs interface truncates the readable size to PCI_CFG_SPACE_SIZE.

Allow sysfs access to config space up to cfg_size, even if the device
doesn't support the entire 4096-byte PCIe config space.

Note that pci_read_config() and pci_write_config() limit access to
dev->cfg_size even though pcie_config_attr contains 4096 (the maximum
size).

Signed-off-by: Jason S. McMullan 
[simon: edited changelog]
Signed-off-by: Simon Horman 
[bhelgaas: more changelog edits]
Signed-off-by: Bjorn Helgaas 

Signed-off-by: Sasha Levin

PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset

2016-08-22T16:22:58+00:00

[ Upstream commit 9ac0108c2bac3f1d0255f64fb89fc27e71131b24 ]

Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have
the same quirk for the Bus Reset.

Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
Signed-off-by: Chris Blake 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org  # v3.14+
Signed-off-by: Sasha Levin

PCI: Allow a NULL "parent" pointer in pci_bus_assign_domain_nr()

2016-07-12T12:47:19+00:00

[ Upstream commit 54c6e2dd00c313d0add58e5befe62fe6f286d03b ]

pci_create_root_bus() passes a "parent" pointer to
pci_bus_assign_domain_nr().  When CONFIG_PCI_DOMAINS_GENERIC is defined,
pci_bus_assign_domain_nr() dereferences that pointer.  Many callers of
pci_create_root_bus() supply a NULL "parent" pointer, which leads to a NULL
pointer dereference error.

7c674700098c ("PCI: Move domain assignment from arm64 to generic code")
moved the "parent" dereference from arm64 to generic code.  Only arm64 used
that code (because only arm64 defined CONFIG_PCI_DOMAINS_GENERIC), and it
always supplied a valid "parent" pointer.  Other arches supplied NULL
"parent" pointers but didn't defined CONFIG_PCI_DOMAINS_GENERIC, so they
used a no-op version of pci_bus_assign_domain_nr().

8c7d14746abc ("ARM/PCI: Move to generic PCI domains") defined
CONFIG_PCI_DOMAINS_GENERIC on ARM, and many ARM platforms use
pci_common_init(), which supplies a NULL "parent" pointer.
These platforms (cns3xxx, dove, footbridge, iop13xx, etc.) crash
with a NULL pointer dereference like this while probing PCI:

  Unable to handle kernel NULL pointer dereference at virtual address 000000a4
  PC is at pci_bus_assign_domain_nr+0x10/0x84
  LR is at pci_create_root_bus+0x48/0x2e4
  Kernel panic - not syncing: Attempted to kill init!

[bhelgaas: changelog, add "Reported:" and "Fixes:" tags]
Reported: http://forum.doozan.com/read.php?2,17868,22070,quote=1
Fixes: 8c7d14746abc ("ARM/PCI: Move to generic PCI domains")
Fixes: 7c674700098c ("PCI: Move domain assignment from arm64 to generic code")
Signed-off-by: Krzysztof Hałasa 
Signed-off-by: Bjorn Helgaas 
Acked-by: Lorenzo Pieralisi 
CC: stable@vger.kernel.org	# v4.0+

Signed-off-by: Sasha Levin

PCI: Move domain assignment from arm64 to generic code

2016-07-12T12:47:19+00:00

[ Upstream commit 7c674700098c87b305b99652e3c694c4ef195866 ]

The current logic in arm64 pci_bus_assign_domain_nr() is flawed in that
depending on the host controller configuration for a platform and the
initialization sequence, core code may end up allocating PCI domain numbers
from both DT and the generic domain counter, which would result in PCI
domain allocation aliases/errors.

Fix the logic behind the PCI domain number assignment and move the
resulting code to the PCI core so the same domain allocation logic is used
on all platforms that select CONFIG_PCI_DOMAINS_GENERIC.

[bhelgaas: tidy changelog]
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Acked-by: Liviu Dudau 
Acked-by: Arnd Bergmann 
CC: Rob Herring 
CC: Catalin Marinas 

Signed-off-by: Sasha Levin

PCI: Disable all BAR sizing for devices with non-compliant BARs

2016-06-06T23:11:05+00:00

[ Upstream commit ad67b437f187ea818b2860524d10f878fadfdd99 ]

b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant
BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with
the PCI spec.  But it didn't do anything for expansion ROM BARs, so we
still try to size them, resulting in warnings like this on Broadwell-EP:

  pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref]

Move the non-compliant BAR check from __pci_read_base() up to
pci_read_bases() so it applies to the expansion ROM BAR as well as
to BARs 0-5.

Note that direct callers of __pci_read_base(), like sriov_init(), will now
bypass this check.  We haven't had reports of devices with broken SR-IOV
BARs yet.

[bhelgaas: changelog]
Fixes: b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs")
Signed-off-by: Prarit Bhargava 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org
CC: Thomas Gleixner 
CC: Ingo Molnar 
CC: "H. Peter Anvin" 
CC: Andi Kleen 

Signed-off-by: Sasha Levin

PCI: Disable IO/MEM decoding for devices with non-compliant BARs

2016-04-18T12:49:19+00:00

[ Upstream commit b84106b4e2290c081cdab521fa832596cdfea246 ]

The PCI config header (first 64 bytes of each device's config space) is
defined by the PCI spec so generic software can identify the device and
manage its usage of I/O, memory, and IRQ resources.

Some non-spec-compliant devices put registers other than BARs where the
BARs should be.  When the PCI core sizes these "BARs", the reads and writes
it does may have unwanted side effects, and the "BAR" may appear to
describe non-sensical address space.

Add a flag bit to mark non-compliant devices so we don't touch their BARs.
Turn off IO/MEM decoding to prevent the devices from consuming address
space, since we can't read the BARs to find out what that address space
would be.

Signed-off-by: Bjorn Helgaas 
Tested-by: Andi Kleen 
CC: stable@vger.kernel.org
Signed-off-by: Sasha Levin