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

ACPI / hotplug / PCI: Check presence of slot itself in get_slot_status()

2018-04-24T07:32:06+00:00

commit 13d3047c81505cc0fb9bdae7810676e70523c8bf upstream.

Mike Lothian reported that plugging in a USB-C device does not work
properly in his Dell Alienware system.  This system has an Intel Alpine
Ridge Thunderbolt controller providing USB-C functionality.  In these
systems the USB controller (xHCI) is hotplugged whenever a device is
connected to the port using ACPI-based hotplug.

The ACPI description of the root port in question is as follows:

  Device (RP01)
  {
      Name (_ADR, 0x001C0000)

      Device (PXSX)
      {
          Name (_ADR, 0x02)

          Method (_RMV, 0, NotSerialized)
          {
              // ...
          }
      }

Here _ADR 0x02 means device 0, function 2 on the bus under root port (RP01)
but that seems to be incorrect because device 0 is the upstream port of the
Alpine Ridge PCIe switch and it has no functions other than 0 (the bridge
itself).  When we get ACPI Notify() to the root port resulting from
connecting a USB-C device, Linux tries to read PCI_VENDOR_ID from device 0,
function 2 which of course always returns 0xffffffff because there is no
such function and we never find the device.

In Windows this works fine.

Now, since we get ACPI Notify() to the root port and not to the PXSX device
we should actually start our scan from there as well and not from the
non-existent PXSX device.  Fix this by checking presence of the slot itself
(function 0) if we fail to do that otherwise.

While there use pci_bus_read_dev_vendor_id() in get_slot_status(), which is
the recommended way to read Device and Vendor IDs of devices on PCI buses.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=198557
Reported-by: Mike Lothian 
Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki 
Cc: Greg Kroah-Hartman 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

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

2018-04-08T09:52:01+00:00

This reverts commit 4fbe422076d36615ec6fe8648d1aecfa460bc67d which was
commit fda78d7a0ead144f4b2cdb582dcba47911f4952c upstream.

The dependancy tree is just too messy here, just drop it from this
kernel as it's not really needed here.

Reported-by: Ben Hutchings 
Cc: Prarit Bhargava 
Cc: Bjorn Helgaas 
Cc: Alex Williamson 
Cc: David Arcari 
Cc: Myron Stowe 
Cc: Lukas Wunner 
Cc: Keith Busch 
Cc: Mika Westerberg 
Cc: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Make PCI_ROM_ADDRESS_MASK a 32-bit constant

2018-04-08T09:51:57+00:00

commit 76dc52684d0f72971d9f6cc7d5ae198061b715bd upstream.

A 64-bit value is not needed since a PCI ROM address consists in 32 bits.
This fixes a clang warning about "implicit conversion from 'unsigned long'
to 'u32'".

Also remove now unnecessary casts to u32 from __pci_read_base() and
pci_std_update_resource().

Signed-off-by: Matthias Kaehlcke 
Signed-off-by: Bjorn Helgaas 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman

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

2018-03-28T16:40:13+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/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()

2018-03-22T08:23:19+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: keystone: Fix interrupt-controller-node lookup

2018-02-28T09:17:21+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 
[johan: backport to 4.4]
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

PCI: layerscape: Fix MSG TLP drop setting

2018-01-31T11:06:08+00:00

commit 1195c103f6c98d9ff381cac3a8760d4f8a133627 upstream.

Some kinds of Layerscape PCIe controllers will forward the received message
TLPs to system application address space, which could corrupt system memory
or lead to a system hang.  Enable MSG_DROP to fix this issue.

Signed-off-by: Minghuan Lian 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Matthias Brugger 
Signed-off-by: Greg Kroah-Hartman

PCI: layerscape: Add "fsl,ls2085a-pcie" compatible ID

2018-01-31T11:06:08+00:00

commit dbae40b76abef2f8a7e7bf1701f77df9e73def48 upstream.

The Layerscape PCI host driver must recognize ls2085a compatible when using
firmware with ls2085a compatible property, otherwise the PCI bus won't be
detected even though ls2085a compatible is included by the dts.

Signed-off-by: Yang Shi 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Matthias Brugger 
Signed-off-by: Greg Kroah-Hartman

PCI / PM: Force devices to D0 in pci_pm_thaw_noirq()

2018-01-02T19:33:20+00:00

commit 5839ee7389e893a31e4e3c9cf17b50d14103c902 upstream.

It is incorrect to call pci_restore_state() for devices in low-power
states (D1-D3), as that involves the restoration of MSI setup which
requires MMIO to be operational and that is only the case in D0.

However, pci_pm_thaw_noirq() may do that if the driver's "freeze"
callbacks put the device into a low-power state, so fix it by making
it force devices into D0 via pci_set_power_state() instead of trying
to "update" their power state which is pointless.

Fixes: e60514bd4485 (PCI/PM: Restore the status of PCI devices across hibernation)
Reported-by: Thomas Gleixner 
Reported-by: Maarten Lankhorst 
Tested-by: Thomas Gleixner 
Tested-by: Maarten Lankhorst 
Signed-off-by: Rafael J. Wysocki 
Acked-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI/AER: Report non-fatal errors only to the affected endpoint

2017-12-25T13:22:15+00:00

[ Upstream commit 86acc790717fb60fb51ea3095084e331d8711c74 ]

Previously, if an non-fatal error was reported by an endpoint, we
called report_error_detected() for the endpoint, every sibling on the
bus, and their descendents.  If any of them did not implement the
.error_detected() method, do_recovery() failed, leaving all these
devices unrecovered.

For example, the system described in the bugzilla below has two devices:

  0000:74:02.0 [19e5:a230] SAS controller, driver has .error_detected()
  0000:74:03.0 [19e5:a235] SATA controller, driver lacks .error_detected()

When a device such as 74:02.0 reported a non-fatal error, do_recovery()
failed because 74:03.0 lacked an .error_detected() method.  But per PCIe
r3.1, sec 6.2.2.2.2, such an error does not compromise the Link and
does not affect 74:03.0:

  Non-fatal errors are uncorrectable errors which cause a particular
  transaction to be unreliable but the Link is otherwise fully functional.
  Isolating Non-fatal from Fatal errors provides Requester/Receiver logic
  in a device or system management software the opportunity to recover from
  the error without resetting the components on the Link and disturbing
  other transactions in progress.  Devices not associated with the
  transaction in error are not impacted by the error.

Report non-fatal errors only to the endpoint that reported them.  We really
want to check for AER_NONFATAL here, but the current code structure doesn't
allow that.  Looking for pci_channel_io_normal is the best we can do now.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=197055
Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver")
Signed-off-by: Gabriele Paoloni 
Signed-off-by: Dongdong Liu 
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman