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

PCI: Add function 1 DMA alias quirk for Highpoint RocketRAID 644L

2018-03-28T16:39:19+00:00

commit 1903be8222b7c278ca897c129ce477c1dd6403a8 upstream.

The Highpoint RocketRAID 644L uses a Marvel 88SE9235 controller, as with
other Marvel controllers this needs a function 1 DMA alias quirk.

Note the RocketRAID 642L uses the same Marvel 88SE9235 controller and
already is listed with a function 1 DMA alias quirk.

Cc: stable@vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106
Signed-off-by: Hans de Goede 
Acked-by: Bjorn Helgaas 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

PCI: Apply Cavium ACS quirk only to CN81xx/CN83xx/CN88xx devices

2018-03-22T08:17:45+00:00

[ Upstream commit b77d537d00d08fcf0bf641cd3491dd7df0ad1475 ]

Only apply the Cavium ACS quirk to devices with ID in the range
0xa000-0xa0ff.  These are the on-chip PCI devices for CN81xx/CN83xx/CN88xx.

Fixes: b404bcfbf035 ("PCI: Add ACS quirk for all Cavium devices")
Reported-by: Alex Williamson 
Signed-off-by: Manish Jaggi 
Acked-by: David Daney 
Acked-by: Alex Williamson 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: hv: Lock PCI bus on device eject

2018-03-22T08:17:42+00:00

[ Upstream commit 414428c5da1c71986727c2fa5cdf1ed071e398d7 ]

A PCI_EJECT message can arrive at the same time we are calling
pci_scan_child_bus() in the workqueue for the previous PCI_BUS_RELATIONS
message or in create_root_hv_pci_bus().  In this case we could potentially
modify the bus from multiple places.

Properly lock the bus access.

Thanks Dexuan Cui  for pointing out the race condition
in create_root_hv_pci_bus().

Reported-by: Xiaofeng Wang 
Signed-off-by: Long Li 
Signed-off-by: Bjorn Helgaas 
Acked-by: K. Y. Srinivasan 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: hv: Properly handle PCI bus remove

2018-03-22T08:17:42+00:00

[ Upstream commit d3a78d8bf759d8848339dcc367c4c1678b57a08b ]

hv_pci_devices_present() is called in hv_pci_remove() when we remove a PCI
device from the host, e.g., by disabling SR-IOV on a device.  In
hv_pci_remove(), the bus is already removed before the call, so we don't
need to rescan the bus in the workqueue scheduled from
hv_pci_devices_present().

By introducing bus state hv_pcibus_removed, we can avoid this situation.

Reported-by: Xiaofeng Wang 
Signed-off-by: Long Li 
Signed-off-by: Bjorn Helgaas 
Acked-by: K. Y. Srinivasan 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()

2018-03-22T08:17:38+00:00

[ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ]

The pci_bus_type .shutdown method, pci_device_shutdown(), is called from
device_shutdown() in the kernel restart and shutdown paths.

Previously, pci_device_shutdown() called pci_msi_shutdown() and
pci_msix_shutdown().  This disables MSI and MSI-X, which causes the device
to fall back to raising interrupts via INTx.  But the driver is still bound
to the device, it doesn't know about this change, and it likely doesn't
have an INTx handler, so these INTx interrupts cause "nobody cared"
warnings like this:

  irq 16: nobody cared (try booting with the "irqpoll" option)
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.2-1.el7_UNSUPPORTED.x86_64 #1
  Hardware name: Hewlett-Packard HP Z820 Workstation/158B, BIOS J63 v03.90 06/
  ...

The MSI disabling code was added by d52877c7b1af ("pci/irq: let
pci_device_shutdown to call pci_msi_shutdown v2") because a driver left MSI
enabled and kdump failed because the kexeced kernel wasn't prepared to
receive the MSI interrupts.

Subsequent commits 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even
if kernel doesn't support MSI") and  e80e7edc55ba ("PCI/MSI: Initialize MSI
capability for all architectures") changed the kexeced kernel to disable
all MSIs itself so it no longer depends on the crashed kernel to clean up
after itself.

Stop disabling MSI/MSI-X in pci_device_shutdown().  This resolves the
"nobody cared" unhandled IRQ issue above.  It also allows PCI serial
devices, which may rely on the MSI interrupts, to continue outputting
messages during reboot/shutdown.

[bhelgaas: changelog, drop pci_msi_shutdown() and pci_msix_shutdown() calls
altogether]
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=187351
Signed-off-by: Prarit Bhargava 
Signed-off-by: Bjorn Helgaas 
CC: Alex Williamson 
CC: David Arcari 
CC: Myron Stowe 
CC: Lukas Wunner 
CC: Keith Busch 
CC: Mika Westerberg 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: dwc: Fix enumeration end when reaching root subordinate

2018-03-18T10:18:56+00:00

commit fc110ebdd014dd1368c98e7685b47789c31fab42 upstream.

The subordinate value indicates the highest bus number which can be
reached downstream though a certain device.

Commit a20c7f36bd3d ("PCI: Do not allocate more buses than available in
parent") ensures that downstream devices cannot assign busnumbers higher
than the upstream device subordinate number, which was indeed illogical.

By default, dw_pcie_setup_rc() inits the Root Complex subordinate to a
value of 0x01.

Due to this combined with above commit, enumeration stops digging deeper
downstream as soon as bus num 0x01 has been assigned, which is always the
case for a bridge device.

This results in all devices behind a bridge bus remaining undetected, as
these would be connected to bus 0x02 or higher.

Fix this by initializing the RC to a subordinate value of 0xff, which is
not altering hardware behaviour in any way, but informs probing function
pci_scan_bridge() later on which reads this value back from register.

The following nasty errors during boot are also fixed by this:

  pci_bus 0000:02: busn_res: can not insert [bus 02-ff] under [bus 01] (conflicts with (null) [bus 01])
  ...
  pci_bus 0000:03: [bus 03] partially hidden behind bridge 0000:01 [bus 01]
  ...
  pci_bus 0000:04: [bus 04] partially hidden behind bridge 0000:01 [bus 01]
  ...
  pci_bus 0000:05: [bus 05] partially hidden behind bridge 0000:01 [bus 01]
  pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 05
  pci_bus 0000:02: busn_res: can not insert [bus 02-05] under [bus 01] (conflicts with (null) [bus 01])
  pci_bus 0000:02: [bus 02-05] partially hidden behind bridge 0000:01 [bus 01]

Fixes: a20c7f36bd3d ("PCI: Do not allocate more buses than available in
parent")
Tested-by: Niklas Cassel 
Tested-by: Fabio Estevam 
Tested-by: Sebastian Reichel 
Signed-off-by: Koen Vandeputte 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Mika Westerberg 
Acked-by: Lucas Stach 
Cc: stable@vger.kernel.org	# v4.15+
Cc: Binghui Wang 
Cc: Jesper Nilsson 
Cc: Jianguo Sun 
Cc: Jingoo Han 
Cc: Kishon Vijay Abraham I 
Cc: Lucas Stach 
Cc: Mika Westerberg 
Cc: Minghuan Lian 
Cc: Mingkai Hu 
Cc: Murali Karicheri 
Cc: Pratyush Anand 
Cc: Richard Zhu 
Cc: Roy Zang 
Cc: Shawn Guo 
Cc: Stanimir Varbanov 
Cc: Thomas Petazzoni 
Cc: Xiaowei Song 
Cc: Zhou Wang 
[fabio: adapted to the file location of 4.9 kernel]
Signed-off-by: Fabio Estevam 
Signed-off-by: Greg Kroah-Hartman

PCI/ASPM: Deal with missing root ports in link state handling

2018-03-11T15:21:30+00:00

commit ee8bdfb6568d86bb93f55f8d99c4c643e77304ee upstream.

Even though it is unconventional, some PCIe host implementations omit the
root ports entirely, and simply consist of a host bridge (which is not
modeled as a device in the PCI hierarchy) and a link.

When the downstream device is an endpoint, our current code does not seem
to mind this unusual configuration. However, when PCIe switches are
involved, the ASPM code assumes that any downstream switch port has a
parent, and blindly dereferences the bus->parent->self field of the pci_dev
struct to chain the downstream link state to the link state of the root
port. Given that the root port is missing, the link is not modeled at all,
and nor is the link state, and attempting to access it results in a NULL
pointer dereference and a crash.

Avoid this by allowing the link state chain to terminate at the downstream
port if no root port exists.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI/cxgb4: Extend T3 PCI quirk to T4+ devices

2018-02-28T09:18:31+00:00

commit 7dcf688d4c78a18ba9538b2bf1b11dc7a43fe9be upstream.

We've run into a problem where our device is attached
to a Virtual Machine and the use of the new pci_set_vpd_size()
API doesn't help.  The VM kernel has been informed that
the accesses are okay, but all of the actual VPD Capability
Accesses are trapped down into the KVM Hypervisor where it
goes ahead and imposes the silent denials.

The right idea is to follow the kernel.org
commit 1c7de2b4ff88 ("PCI: Enable access to non-standard VPD for
Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored
to establish a PCI Quirk for our T3-based adapters. This commit
extends that PCI Quirk to cover Chelsio T4 devices and later.

The advantage of this approach is that the VPD Size gets set early
in the Base OS/Hypervisor Boot and doesn't require that the cxgb4
driver even be available in the Base OS/Hypervisor.  Thus PF4 can
be exported to a Virtual Machine and everything should work.

Fixes: 67e658794ca1 ("cxgb4: Set VPD size so we can read both VPD structures")
Cc:   # v4.9+
Signed-off-by: Casey Leedom 
Signed-off-by: Arjun Vynipadath 
Signed-off-by: Ganesh Goudar 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

PCI: vmd: Fix suspend handlers defined-but-not-used warning

2018-02-25T10:05:51+00:00

commit 42db500a551f97551a901e2258f84a60baf4edfc upstream.

Fix the following warnings:

  drivers/pci/host/vmd.c:731:12: warning: ‘vmd_suspend’ defined but not used [-Wunused-function]
   static int vmd_suspend(struct device *dev)
              ^
  drivers/pci/host/vmd.c:739:12: warning: ‘vmd_resume’ defined but not used [-Wunused-function]
   static int vmd_resume(struct device *dev)
              ^

Signed-off-by: Borislav Petkov 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Keith Busch 
Signed-off-by: Greg Kroah-Hartman

PCI: keystone: Fix interrupt-controller-node lookup

2018-02-22T14:43:49+00:00

commit eac56aa3bc8af3d9b9850345d0f2da9d83529134 upstream.

Fix child-node lookup during initialisation which was using the wrong
OF-helper and ended up searching the whole device tree depth-first
starting at the parent rather than just matching on its children.

To make things worse, the parent pci node could end up being prematurely
freed as of_find_node_by_name() drops a reference to its first argument.
Any matching child interrupt-controller node was also leaked.

Fixes: 0c4ffcfe1fbc ("PCI: keystone: Add TI Keystone PCIe driver")
Cc: stable      # 3.18
Acked-by: Murali Karicheri 
Signed-off-by: Johan Hovold 
[lorenzo.pieralisi@arm.com: updated commit subject]
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Greg Kroah-Hartman