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

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

PCI: Add dev->has_secondary_link to track downstream PCIe links

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

[ Upstream commit d0751b98dfa391f862e02dc36a233a54615e3f1d ]

A PCIe Port is an interface to a Link.  A Root Port is a PCI-PCI bridge in
a Root Complex and has a Link on its secondary (downstream) side.  For
other Ports, the Link may be on either the upstream (closer to the Root
Complex) or downstream side of the Port.

The usual topology has a Root Port connected to an Upstream Port.  We
previously assumed this was the only possible topology, and that a
Downstream Port's Link was always on its downstream side, like this:

                  +---------------------+
  +------+        |          Downstream |
  | Root |        | Upstream       Port +--Link--
  | Port +--Link--+ Port                |
  +------+        |          Downstream |
                  |                Port +--Link--
                  +---------------------+

But systems do exist (see URL below) where the Root Port is connected to a
Downstream Port.  In this case, a Downstream Port's Link may be on either
the upstream or downstream side:

                  +---------------------+
  +------+        |            Upstream |
  | Root |        | Downstream     Port +--Link--
  | Port +--Link--+ Port                |
  +------+        |          Downstream |
                  |                Port +--Link--
                  +---------------------+

We can't use the Port type to determine which side the Link is on, so add a
bit in struct pci_dev to keep track.

A Root Port's Link is always on the Port's secondary side.  A component
(Endpoint or Port) on the other end of the Link obviously has the Link on
its upstream side.  If that component is a Port, it is part of a Switch or
a Bridge.  A Bridge has a PCI or PCI-X bus on its secondary side, not a
Link.  The internal bus of a Switch connects the Port to another Port whose
Link is on the downstream side.

[bhelgaas: changelog, comment, cache "type", use if/else]
Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
Suggested-by: Bjorn Helgaas 
Signed-off-by: Yijing Wang 
Signed-off-by: Bjorn Helgaas 

Signed-off-by: Sasha Levin