linux-toradex.git/drivers/pci/hotplug, branch v4.4.136

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

PCI: shpchp: Enable bridge bus mastering if MSI is enabled

2017-09-27T09:00:16+00:00

commit 48b79a14505349a29b3e20f03619ada9b33c4b17 upstream.

An SHPC may generate MSIs to notify software about slot or controller
events (SHPC spec r1.0, sec 4.7).  A PCI device can only generate an MSI if
it has bus mastering enabled.

Enable bus mastering if the bridge contains an SHPC that uses MSI for event
notifications.

Signed-off-by: Aleksandr Bezzubikov 
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Marcel Apfelbaum 
Acked-by: Michael S. Tsirkin 
Signed-off-by: Greg Kroah-Hartman

powerpc/pci/rpadlpar: Fix device reference leaks

2017-01-12T10:22:50+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

ACPI / PCI / hotplug: unlock in error path in acpiphp_enable_slot()

2016-03-03T23:07:24+00:00

commit 2c3033a0664dfae91e1dee7fabac10f24354b958 upstream.

In acpiphp_enable_slot(), there is a missing unlock path
when error occurred.  It needs to be unlocked before returning
an error.

Signed-off-by: Insu Yun 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PCI: pciehp: Queue power work requests in dedicated function

2015-10-21T18:55:37+00:00

Up to now, work items to be queued to be handled by pciehp_power_thread()
are allocated using kmalloc() in three different locations.  If not needed,
kfree() is called to free the allocated data.

Introduce a separate function to allocate the work item and queue it, and
call it only if needed.  This reduces code duplication and avoids having to
free memory if the work item does not need to get executed.

[bhelgaas: tweak "no memory" message, make pciehp_queue_power_work() static]
Signed-off-by: Guenter Roeck 
Signed-off-by: Bjorn Helgaas

PCI: pciehp: Remove ignored MRL sensor interrupt events

2015-08-10T19:24:09+00:00

We queued interrupt events for the MRL being opened or closed, but the code
in interrupt_event_handler() that handles these events ignored them.

Stop enabling MRL interrupts and remove the ignored events.

Signed-off-by: Bjorn Helgaas

PCI: pciehp: Remove unused interrupt events

2015-08-10T19:24:09+00:00

The list of interrupt events (INT_BUTTON_IGNORE, INT_PRESENCE_ON, etc.) was
copied from other hotplug drivers, but pciehp doesn't use them all.

Remove the interrupt events that aren't used by pciehp.

Signed-off-by: Bjorn Helgaas

PCI: pciehp: Handle invalid data when reading from non-existent devices

2015-08-10T19:24:09+00:00

It's platform-dependent, but an MMIO read to a non-existent PCI device
generally returns data with all bits set.  This happens when the host
bridge or Root Complex times out waiting for a response from the device and
fabricates return data to complete the CPU's read.

One example, reported in the bugzilla below, involved this hierarchy:

  pci 0000:00:1c.0: PCI bridge to [bus 02-3a] Root Port
  pci 0000:02:00.0: PCI bridge to [bus 03-0a] Upstream Port
  pci 0000:03:03.0: PCI bridge to [bus 05-07] Downstream Port
  pci 0000:05:00.0: PCI bridge to [bus 06-07] Thunderbolt Upstream Port
  pci 0000:06:00.0: PCI bridge to [bus 07]    Thunderbolt Downstream Port
  pci 0000:07:00.0: BCM57762 NIC

Unplugging the Thunderbolt switch and the NIC below it resulted in this:

  pciehp 0000:03:03.0: Surprise Removal
  tg3 0000:07:00.0: tg3_abort_hw timed out, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
  pciehp 0000:06:00.0: unloading service driver pciehp
  pciehp 0000:06:00.0: pcie_isr: intr_loc 11f
  pciehp 0000:06:00.0: Switch interrupt received
  pciehp 0000:06:00.0: Latch open on Slot
  pciehp 0000:06:00.0: Attention button interrupt received
  pciehp 0000:06:00.0: Button pressed on Slot
  pciehp 0000:06:00.0: Presence/Notify input change
  pciehp 0000:06:00.0: Card present on Slot
  pciehp 0000:06:00.0: Power fault interrupt received
  pciehp 0000:06:00.0: Data Link Layer State change
  pciehp 0000:06:00.0: Link Up event

The pciehp driver correctly noticed that the Thunderbolt switch (05:00.0
and 06:00.0) and NIC (07:00.0) had been removed, and it called their driver
remove methods.

Since the NIC was already gone, tg3 received 0xffffffff when it tried to
read from the device.  The resulting timeout is a tg3 issue and not of
interest here.

Similarly, since the 06:00.0 Thunderbolt switch was already gone,
pcie_isr() received 0xffff when it tried to read PCI_EXP_SLTSTA, and pciehp
thought that was valid status showing that many events had happened: the
latch had been opened, the attention button had been pressed, a card was
now present, and the link was now up.  These are all wrong, of course, but
pciehp went on to try to power up and enumerate devices below the
non-existent bridge:

  pciehp 0000:06:00.0: PCI slot - powering on due to button press
  pciehp 0000:06:00.0: Surprise Insertion
  pci 0000:07:00.0 id reading try 50 times with interval 20 ms to get ffffffff

[bhelgaas: changelog, also check in pcie_poll_cmd() & pcie_do_write_cmd()]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99841
Suggested-by: Bjorn Helgaas 
Signed-off-by: Jarod Wilson 
Signed-off-by: Bjorn Helgaas

PCI: pciehp: Simplify pcie_poll_cmd()

2015-07-16T03:03:33+00:00

Move first slot status read into while to simplify code.

Signed-off-by: Yijing Wang 
Signed-off-by: Bjorn Helgaas

PCI: Use "slot" and "pci_slot" for struct hotplug_slot and struct pci_slot

2015-07-16T03:03:31+00:00

Now in pci_hotplug_core.c, we randomly name a struct hotplug_slot and a
struct pci_slot.  It's easy to confuse them, so let us use "slot" for a
struct hotplug_slot and "pci_slot" for a struct pci_slot.

No functional change.

Signed-off-by: Yijing Wang 
Signed-off-by: Bjorn Helgaas