linux-stable.git/drivers/pci, branch v4.9.7

PCI: Enumerate switches below PCI-to-PCIe bridges

2017-01-26T07:24:38+00:00

commit 51ebfc92b72b4f7dac1ab45683bf56741e454b8c upstream.

A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary
interface and a PCI Express secondary interface.  The PCIe interface is a
Downstream Port that originates a Link.  See the "PCI Express to PCI/PCI-X
Bridge Specification", rev 1.0, sections 1.2 and A.6.

The bug report below involves a PCI-to-PCIe bridge and a PCIe switch below
the bridge:

  00:1e.0 Intel 82801 PCI Bridge to [bus 01-0a]
  01:00.0 Pericom PI7C9X111SL PCIe-to-PCI Reversible Bridge to [bus 02-0a]
  02:00.0 Pericom Device 8608 [PCIe Upstream Port] to [bus 03-0a]
  03:01.0 Pericom Device 8608 [PCIe Downstream Port] to [bus 0a]

01:00.0 is configured as a PCI-to-PCIe bridge (despite the name printed by
lspci).  As we traverse a PCIe hierarchy, device connections alternate
between PCIe Links and internal Switch logic.  Previously we did not
recognize that 01:00.0 had a secondary link, so we thought the 02:00.0
Upstream Port *did* have a secondary link.  In fact, it's the other way
around: 01:00.0 has a secondary link, and 02:00.0 has internal Switch logic
on its secondary side.

When we thought 02:00.0 had a secondary link, the pci_scan_slot() ->
only_one_child() path assumed 02:00.0 could have only one child, so 03:00.0
was the only possible downstream device.  But 03:00.0 doesn't exist, so we
didn't look for any other devices on bus 03.

Booting with "pci=pcie_scan_all" is a workaround, but we don't want users
to have to do that.

Recognize that PCI-to-PCIe bridges originate links on their secondary
interfaces.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=189361
Fixes: d0751b98dfa3 ("PCI: Add dev->has_secondary_link to track downstream PCIe links")
Tested-by: Blake Moore 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI: designware: Check for iATU unroll only on platforms that use ATU

2017-01-26T07:24:38+00:00

commit a782b5f986c3fa1cfa7f2b57941200c6a5809242 upstream.

Previously we checked for iATU unroll support by reading PCIE_ATU_VIEWPORT
even on platforms, e.g., Keystone, that do not have ATU ports.  This can
cause bad behavior such as asynchronous external aborts:

  OF: PCI:   MEM 0x60000000..0x6fffffff -> 0x60000000
  Unhandled fault: asynchronous external abort (0x1211) at 0x00000000
  pgd = c0003000
  [00000000] *pgd=80000800004003, *pmd=00000000
  Internal error: : 1211 [#1] PREEMPT SMP ARM
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-00009-g6ff59d2-dirty #7
  Hardware name: Keystone
  task: eb878000 task.stack: eb866000
  PC is at dw_pcie_setup_rc+0x24/0x380
  LR is at ks_pcie_host_init+0x10/0x170

Move the dw_pcie_iatu_unroll_enabled() check so we only call it on
platforms that do not use the ATU.  These platforms supply their own
->rd_other_conf() and ->wr_other_conf() methods.

[bhelgaas: changelog]
Fixes: a0601a470537 ("PCI: designware: Add iATU Unroll feature")
Fixes: 416379f9ebde ("PCI: designware: Check for iATU unroll support after initializing host")
Tested-by: Kishon Vijay Abraham I 
Signed-off-by: Murali Karicheri 
Signed-off-by: Bjorn Helgaas 
Acked-By: Joao Pinto 
Signed-off-by: Greg Kroah-Hartman

powerpc/pci/rpadlpar: Fix device reference leaks

2017-01-12T10:39:37+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: Greg Kroah-Hartman

PCI: Enable access to non-standard VPD for Chelsio devices (cxgb3)

2017-01-12T10:39:37+00:00

commit 1c7de2b4ff886a45fbd2f4c3d4627e0f37a9dd77 upstream.

There is at least one Chelsio 10Gb card which uses VPD area to store some
non-standard blocks (example below).  However pci_vpd_size() returns the
length of the first block only assuming that there can be only one VPD "End
Tag".

Since 4e1a635552d3 ("vfio/pci: Use kernel VPD access functions"), VFIO
blocks access beyond that offset, which prevents the guest "cxgb3" driver
from probing the device.  The host system does not have this problem as its
driver accesses the config space directly without pci_read_vpd().

Add a quirk to override the VPD size to a bigger value.  The maximum size
is taken from EEPROMSIZE in drivers/net/ethernet/chelsio/cxgb3/common.h.
We do not read the tag as the cxgb3 driver does as the driver supports
writing to EEPROM/VPD and when it writes, it only checks for 8192 bytes
boundary.  The quirk is registered for all devices supported by the cxgb3
driver.

This adds a quirk to the PCI layer (not to the cxgb3 driver) as the cxgb3
driver itself accesses VPD directly and the problem only exists with the
vfio-pci driver (when cxgb3 is not running on the host and may not be even
loaded) which blocks accesses beyond the first block of VPD data.  However
vfio-pci itself does not have quirks mechanism so we add it to PCI.

This is the controller:
Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030]

This is what I parsed from its VPD:
===
b'\x82*\x0010 Gigabit Ethernet-SR PCI Express Adapter\x90J\x00EC\x07D76809 FN\x0746K'
 0000 Large item 42 bytes; name 0x2 Identifier String
	b'10 Gigabit Ethernet-SR PCI Express Adapter'
 002d Large item 74 bytes; name 0x10
	#00 [EC] len=7: b'D76809 '
	#0a [FN] len=7: b'46K7897'
	#14 [PN] len=7: b'46K7897'
	#1e [MN] len=4: b'1037'
	#25 [FC] len=4: b'5769'
	#2c [SN] len=12: b'YL102035603V'
	#3b [NA] len=12: b'00145E992ED1'
 007a Small item 1 bytes; name 0xf End Tag

 0c00 Large item 16 bytes; name 0x2 Identifier String
	b'S310E-SR-X      '
 0c13 Large item 234 bytes; name 0x10
	#00 [PN] len=16: b'TBD             '
	#13 [EC] len=16: b'110107730D2     '
	#26 [SN] len=16: b'97YL102035603V  '
	#39 [NA] len=12: b'00145E992ED1'
	#48 [V0] len=6: b'175000'
	#51 [V1] len=6: b'266666'
	#5a [V2] len=6: b'266666'
	#63 [V3] len=6: b'2000  '
	#6c [V4] len=2: b'1 '
	#71 [V5] len=6: b'c2    '
	#7a [V6] len=6: b'0     '
	#83 [V7] len=2: b'1 '
	#88 [V8] len=2: b'0 '
	#8d [V9] len=2: b'0 '
	#92 [VA] len=2: b'0 '
	#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
 0d00 Large item 252 bytes; name 0x11
	#00 [VC] len=16: b'122310_1222 dp  '
	#13 [VD] len=16: b'610-0001-00 H1\x00\x00'
	#26 [VE] len=16: b'122310_1353 fp  '
	#39 [VF] len=16: b'610-0001-00 H1\x00\x00'
	#4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
 0dff Small item 0 bytes; name 0xf End Tag

10f3 Large item 13315 bytes; name 0x62
!!! unknown item name 98: b'\xd0\x03\x00@`\x0c\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00'
===

Signed-off-by: Alexey Kardashevskiy 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI: Support INTx masking on ConnectX-4 with firmware x.14.1100+

2017-01-12T10:39:36+00:00

commit 1600f62534b7b3da7978b43b52231a54c24df287 upstream.

Mellanox devices were marked as having INTx masking ability broken.  As a
result, the VFIO driver fails to start when more than one device function
is passed-through to a VM if both have the same INTx pin.

Prior to Connect-IB, Mellanox devices exposed to the operating system one
PCI function per all ports.  Starting from Connect-IB, the devices are
function-per-port.  When passing the second function to a VM, VFIO will
fail to start.

Exclude ConnectX-4, ConnectX4-Lx and Connect-IB from the list of Mellanox
devices marked as having broken INTx masking:

- ConnectX-4 and ConnectX4-LX firmware version is checked. If INTx
  masking is supported, we unmark the broken INTx masking.
- Connect-IB does not support INTx currently so will not cause any
  problem.

[bhelgaas: call pci_disable_device() always, after iounmap()]
Fixes: 11e42532ada3 ("PCI: Assume all Mellanox devices have broken INTx masking")
Signed-off-by: Noa Osherovich 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Or Gerlitz 
Reviewed-by: Gavin Shan 
Signed-off-by: Greg Kroah-Hartman

PCI: Convert Mellanox broken INTx quirks to be for listed devices only

2017-01-12T10:39:36+00:00

commit d76d2fe05fd93673d184af77255bbbc63780f4ea upstream.

Change Mellanox's broken_intx_masking() quirk from an "all Mellanox
devices" to a quirk for listed devices only.

[bhelgaas: remove #defines, reorder to keep other quirks together]
Signed-off-by: Noa Osherovich 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Or Gerlitz 
Reviewed-by: Gavin Shan 
Signed-off-by: Greg Kroah-Hartman

PCI: Convert broken INTx masking quirks from HEADER to FINAL

2017-01-12T10:39:36+00:00

commit b88214ce4d7064992452765028bd50702414f15f upstream.

Convert all quirk_broken_intx_masking() quirks from HEADER to FINAL.

The quirk sets dev->broken_intx_masking, which is only used by
pci_intx_mask_supported(), which is not needed until after FINAL
quirks have been run.

[bhelgaas: changelog]
Signed-off-by: Noa Osherovich 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Gavin Shan 
Signed-off-by: Greg Kroah-Hartman

PCI: rockchip: Correct the use of FTS mask

2017-01-12T10:39:36+00:00

commit a45e2611b9bbd81288d97d02ce7e74a60a698d43 upstream.

We're trying to mask out bits[23:8] while retaining [32:24, 7:0], but we're
doing the inverse.  That doesn't have too much effect, since we're setting
all the [23:8] bits to 1, and the other bits are only relevant for modes
we're currently not using.  But we should get this right.

Fixes: ca1989084054 ("PCI: rockchip: Fix wrong transmitted FTS count")
Signed-off-by: Brian Norris 
Signed-off-by: Bjorn Helgaas 
Acked-by: Shawn Lin 
Signed-off-by: Greg Kroah-Hartman

PCI: rockchip: Fix negotiated lanes calculation

2017-01-12T10:39:35+00:00

commit 45e9320f3a4ef9588ee50a2eb1891c4bfdbb07df upstream.

The calculation of negotiated lanes is wrong: it should be shifted by
PCIE_CORE_PL_CONF_LANE_SHIFT, but it is shifted by
PCIE_CORE_PL_CONF_LANE_MASK instead.  Let's fix it.

Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support")
Signed-off-by: Shawn Lin 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI/MSI: Check for NULL affinity mask in pci_irq_get_affinity()

2017-01-12T10:39:30+00:00

commit d1d111e073840b8dbc1ae90ba3fc274736451bdc upstream.

If msi_setup_entry() fails to allocate an affinity mask, it logs a message
but continues on and allocates an MSI entry with entry->affinity == NULL.

Check for this case in pci_irq_get_affinity() so we don't try to
dereference a NULL pointer.

[bhelgaas: changelog]
Fixes: ee8d41e53efe "pci/msi: Retrieve affinity for a vector"
Signed-off-by: Jan Beulich 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Christoph Hellwig 
CC: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman