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

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

xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted.

2016-03-08T02:15:19+00:00

[ Upstream commit 4d8c8bd6f2062c9988817183a91fe2e623c8aa5e ]

Occasionaly PV guests would crash with:

pciback 0000:00:00.1: Xen PCI mapped GSI0 to IRQ16
BUG: unable to handle kernel paging request at 0000000d1a8c0be0
.. snip..
  ] find_next_bit+0xb/0x10
  [] cpumask_next_and+0x22/0x40
  [] pci_device_probe+0xb8/0x120
  [] ? driver_sysfs_add+0x77/0xa0
  [] driver_probe_device+0x1a4/0x2d0
  [] ? pci_match_device+0xdd/0x110
  [] __device_attach_driver+0xa7/0xb0
  [] ? __driver_attach+0xa0/0xa0
  [] bus_for_each_drv+0x62/0x90
  [] __device_attach+0xbd/0x110
  [] device_attach+0xb/0x10
  [] pci_bus_add_device+0x3c/0x70
  [] pci_bus_add_devices+0x38/0x80
  [] pcifront_scan_root+0x13e/0x1a0
  [] pcifront_backend_changed+0x262/0x60b
  [] ? xenbus_gather+0xd6/0x160
  [] ? put_object+0x2f/0x50
  [] xenbus_otherend_changed+0x9d/0xa0
  [] backend_changed+0xe/0x10
  [] xenwatch_thread+0xc8/0x190
  [] ? woken_wake_function+0x10/0x10

which was the result of two things:

When we call pci_scan_root_bus we would pass in 'sd' (sysdata)
pointer which was an 'pcifront_sd' structure. However in the
pci_device_add it expects that the 'sd' is 'struct sysdata' and
sets the dev->node to what is in sd->node (offset 4):

set_dev_node(&dev->dev, pcibus_to_node(bus));

 __pcibus_to_node(const struct pci_bus *bus)
{
        const struct pci_sysdata *sd = bus->sysdata;

        return sd->node;
}

However our structure was pcifront_sd which had nothing at that
offset:

struct pcifront_sd {
        int                        domain;    /*     0     4 */
        /* XXX 4 bytes hole, try to pack */
        struct pcifront_device *   pdev;      /*     8     8 */
}

That is an hole - filled with garbage as we used kmalloc instead of
kzalloc (the second problem).

This patch fixes the issue by:
 1) Use kzalloc to initialize to a well known state.
 2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That
    way access to the 'node' will access the right offset.

Signed-off-by: Konrad Rzeszutek Wilk 
Cc: 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: David Vrabel 
Signed-off-by: Sasha Levin