linux-toradex.git/drivers/pci, branch v4.4.150

ACPI / PCI: Bail early in acpi_pci_add_bus() if there is no ACPI handle

2018-08-09T10:19:28+00:00

commit a0040c0145945d3bd203df8fa97f6dfa819f3f7d upstream.

Hyper-V instances support PCI pass-through which is implemented through PV
pci-hyperv driver. When a device is passed through, a new root PCI bus is
created in the guest. The bus sits on top of VMBus and has no associated
information in ACPI. acpi_pci_add_bus() in this case proceeds all the way
to acpi_evaluate_dsm(), which reports

  ACPI: \: failed to evaluate _DSM (0x1001)

While acpi_pci_slot_enumerate() and acpiphp_enumerate_slots() are protected
against ACPI_HANDLE() being NULL and do nothing, acpi_evaluate_dsm() is not
and gives us the error. It seems the correct fix is to not do anything in
acpi_pci_add_bus() in such cases.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: Bjorn Helgaas 
Cc: Sinan Kaya 
Signed-off-by: Greg Kroah-Hartman

PCI: Prevent sysfs disable of device while driver is attached

2018-08-06T14:24:33+00:00

[ Upstream commit 6f5cdfa802733dcb561bf664cc89d203f2fd958f ]

Manipulating the enable_cnt behind the back of the driver will wreak
complete havoc with the kernel state, so disallow it.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Johannes Thumshirn 
Acked-by: Keith Busch 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: pciehp: Clear Presence Detect and Data Link Layer Status Changed on resume

2018-07-03T09:21:30+00:00

commit 13c65840feab8109194f9490c9870587173cb29d upstream.

After a suspend/resume cycle the Presence Detect or Data Link Layer Status
Changed bits might be set.  If we don't clear them those events will not
fire anymore and nothing happens for instance when a device is now
hot-unplugged.

Fix this by clearing those bits in a newly introduced function
pcie_reenable_notification().  This should be fine because immediately
after, we check if the adapter is still present by reading directly from
the status register.

Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Andy Shevchenko 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: Add function 1 DMA alias quirk for Marvell 88SE9220

2018-05-30T05:49:15+00:00

[ Upstream commit 832e4e1f76b8a84991e9db56fdcef1ebce839b8b ]

Add Marvell 88SE9220 DMA quirk as found and tested on bug 42679.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679
Signed-off-by: Thomas Vincent-Cross 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Restore config space on runtime resume despite being unbound

2018-05-30T05:49:12+00:00

[ Upstream commit 5775b843a619b3c93f946e2b55a208d9f0f48b59 ]

We leave PCI devices not bound to a driver in D0 during runtime suspend.
But they may have a parent which is bound and can be transitioned to
D3cold at runtime. Once the parent goes to D3cold, the unbound child
may go to D3cold as well. When the child goes to D3cold, its internal
state, including configuration of BARs, MSI, ASPM, MPS, etc., is lost.

One example are recent hybrid graphics laptops which cut power to the
discrete GPU when the root port above it goes to ACPI power state D3.
Users may provoke this by unbinding the GPU driver and allowing runtime
PM on the GPU via sysfs: The PM core will then treat the GPU as
"suspended", which in turn allows the root port to runtime suspend,
causing the power resources listed in its _PR3 object to be powered off.
The GPU's BARs will be uninitialized when a driver later probes it.

Another example are hybrid graphics laptops where the GPU itself (rather
than the root port) is capable of runtime suspending to D3cold. If the
GPU's integrated HDA controller is not bound and the GPU's driver
decides to runtime suspend to D3cold, the HDA controller's BARs will be
uninitialized when a driver later probes it.

Fix by saving and restoring config space over a runtime suspend cycle
even if the device is not bound.

Acked-by: Bjorn Helgaas
Tested-by: Peter Wu # Nvidia Optimus
Tested-by: Lukas Wunner # MacBook Pro
Signed-off-by: Rafael J. Wysocki
[lukas: add commit message, bikeshed code comments for clarity]
Signed-off-by: Lukas Wunner
Link: https://patchwork.freedesktop.org/patch/msgid/92fb6e6ae2730915eb733c08e2f76c6a313e3860.1520068884.git.lukas@wunner.de
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman

PCI: Add function 1 DMA alias quirk for Marvell 9128

2018-05-30T05:48:53+00:00

[ Upstream commit aa008206634363ef800fbd5f0262016c9ff81dea ]

The Marvell 9128 is the original device generating bug 42679, from which
many other Marvell DMA alias quirks have been sourced, but we didn't have
positive confirmation of the fix on 9128 until now.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679
Link: https://www.spinics.net/lists/kvm/msg161459.html
Reported-by: Binarus 
Tested-by: Binarus 
Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

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