linux-stable.git/drivers/pci/hotplug, branch linux-3.4.y

PCI: pciehp: Prevent NULL dereference during probe

2015-02-02T09:04:37+00:00

commit bceee4a97eb58bd0e80e39eff11b506ddd9e7ad3 upstream.

pciehp assumes that dev->subordinate, the struct pci_bus for a bridge's
secondary bus, exists.  But we do not create that bus if we run out of bus
numbers during enumeration.  This leads to a NULL dereference in
init_slot() (and other places).

Change pciehp_probe() to return -ENODEV when no secondary bus is present.

Signed-off-by: Andreas Noever 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Zefan Li

PCI: shpchp: Use per-slot workqueues to avoid deadlock

2014-06-07T23:02:07+00:00

commit f652e7d2916fe2fcf9e7d709aa5b7476b431e2dd upstream.

When we have an SHPC-capable bridge with a second SHPC-capable bridge
below it, pushing the upstream bridge's attention button causes a
deadlock.

The deadlock happens because we use the shpchp_wq workqueue to run
shpchp_pushbutton_thread(), which uses shpchp_disable_slot() to remove
devices below the upstream bridge.  When we remove the downstream bridge,
we call shpc_remove(), the shpchp driver's .remove() method.  That calls
flush_workqueue(shpchp_wq), which deadlocks because the
shpchp_pushbutton_thread() work item is still running.

This patch avoids the deadlock by creating a workqueue for every slot
and removing the single shared workqueue.

Here's the call path that leads to the deadlock:

  shpchp_queue_pushbutton_work
    queue_work(shpchp_wq)		# shpchp_pushbutton_thread
    ...

  shpchp_pushbutton_thread
    shpchp_disable_slot
      remove_board
        shpchp_unconfigure_device
          pci_stop_and_remove_bus_device
            ...
              shpc_remove		# shpchp driver .remove method
                hpc_release_ctlr
                  cleanup_slots
                    flush_workqueue(shpchp_wq)

This change is based on code inspection, since we don't have hardware
with this topology.

Based-on-patch-by: Yijing Wang 
Signed-off-by: Bjorn Helgaas 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
[hq: Backported to 3.4: adjust context]
Signed-off-by: Qiang Huang 
Signed-off-by: Greg Kroah-Hartman

PCI: shpchp: Check bridge's secondary (not primary) bus speed

2014-06-07T23:02:03+00:00

commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc upstream.

When a new device is added below a hotplug bridge, the bridge's secondary
bus speed and the device's bus speed must match.  The shpchp driver
previously checked the bridge's *primary* bus speed, not the secondary bus
speed.

This caused hot-add errors like:

  shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch

Check the secondary bus speed instead.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251
Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core")
Signed-off-by: Marcel Apfelbaum 
Signed-off-by: Bjorn Helgaas 
Acked-by: Michael S. Tsirkin 
Signed-off-by: Greg Kroah-Hartman

PCI: shpchp: Handle push button event asynchronously

2013-01-28T04:47:43+00:00

commit d347e75847c1fb299c97736638f45e6ea39702d4 upstream.

Use non-ordered workqueue for attention button events.

Attention button events on each slot can be handled asynchronously. So
we should use non-ordered workqueue. This patch also removes ordered
workqueue in shpchp as a result.

486b10b9f4 ("PCI: pciehp: Handle push button event asynchronously") made
the same change to pciehp.  I split this out from a patch by Yijing Wang
 so we fix one thing at a time and to make the
shpchp history correspond more closely with the pciehp history.

Signed-off-by: Bjorn Helgaas 
CC: Kenji Kaneshige 
Signed-off-by: Greg Kroah-Hartman

PCI: pciehp: Use per-slot workqueues to avoid deadlock

2013-01-28T04:47:43+00:00

commit c2be6f93b383c873a4f9d521afa49b1b67d06085 upstream.

When we have a hotplug-capable PCIe port with a second hotplug-capable
PCIe port below it, removing the device below the upstream port causes
a deadlock.

The deadlock happens because we use the pciehp_wq workqueue to run
pciehp_power_thread(), which uses pciehp_disable_slot() to remove devices
below the upstream port. When we remove the downstream PCIe port, we call
pciehp_remove(), the pciehp driver's .remove() method. That calls
flush_workqueue(pciehp_wq), which deadlocks because the
pciehp_power_thread() work item is still running.

This patch avoids the deadlock by creating a workqueue for every PCIe port
and removing the single shared workqueue.

Here's the call path that leads to the deadlock:

pciehp_queue_pushbutton_work
queue_work(pciehp_wq) # queue pciehp_power_thread
...

pciehp_power_thread
pciehp_disable_slot
remove_board
pciehp_unconfigure_device
pci_stop_and_remove_bus_device
...
pciehp_remove # pciehp driver .remove method
pciehp_release_ctrl
pcie_cleanup_slot
flush_workqueue(pciehp_wq)

This is fairly urgent because it can be caused by simply unplugging a
Thunderbolt adapter, as reported by Daniel below.

[bhelgaas: changelog]
Reference: http://lkml.kernel.org/r/CAMVG2ssiRgcTD1bej2tkUUfsWmpL5eNtPcNif9va2-Gzb2u8nQ@mail.gmail.com
Reported-and-tested-by: Daniel J Blueman
Reviewed-by: Kenji Kaneshige
Signed-off-by: Yijing Wang
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman

PCI: acpiphp: check whether _ADR evaluation succeeded

2012-10-12T20:38:38+00:00

commit dfb117b3e50c52c7b3416db4a4569224b8db80bb upstream.

Check whether we evaluated _ADR successfully.  Previously we ignored
failure, so we would have used garbage data from the stack as the device
and function number.

We return AE_OK so that we ignore only this slot and continue looking
for other slots.

Found by Coverity (CID 113981).

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Ben Hutchings 
Signed-off-by: Greg Kroah-Hartman

PCI: make acpihp use __pci_remove_bus_device instead

2012-02-27T20:17:16+00:00

pci_stop_bus_device gets called before in the same loop.

Signed-off-by: Yinghai Lu 
Signed-off-by: Jesse Barnes

PCI: Rename pci_remove_bus_device to pci_stop_and_remove_bus_device

2012-02-27T20:12:18+00:00

The old pci_remove_bus_device actually did stop and remove.

Make the name reflect that to reduce confusion.

This patch is done by sed scripts and changes back some incorrect
__pci_remove_bus_device changes.

Suggested-by: Jesse Barnes 
Signed-off-by: Yinghai Lu 
Signed-off-by: Jesse Barnes

PCI hotplug: cpcihp: fix debug module parameter to be bool

2012-02-14T16:45:03+00:00

Fix debug variable from module parameter to be really bool to
fix 'warning: return from incompatible pointer type'.

Acked-by: Scott Murray 
Signed-off-by: Danny Kukawka 
Signed-off-by: Jesse Barnes

PCI: pciehp: Disable/enable link during slot power off/on

2012-02-14T16:45:02+00:00

On a system with a repeater on the system board to support gen2 hotplug,
we found that when an ExpressModule is removed from some slots,
/var/log/messages will be full of "card present/not present" warnings.

It turns out the root complex is continually trying to train the link to
the repeater because the repeater has not been reset.

This patch will disable the link at removal time to allow the repeater
to be reset properly.  This also prevents a potential AER message at
removal time.

Also, when testing hotplug on a system under development, we found if we
boot the system without an EM installed, and later hot-add an EM, it
does not work with Linux, but another OS is ok.  The root cause is that
BIOS left link disabled when slot was empty at boot time, and other OS
is modifying the link disable bit in link ctrl during power on/off.

So we should do the same thing to disable/enable link during power off/on.

-v2: check link DLLA bit instead of 100ms waiting.
     Separate link disable/enable functions to another patch.

Signed-off-by: Yinghai Lu 
Signed-off-by: Jesse Barnes