linux.git/drivers/pci, branch v3.8-rc5

Merge tag '3.8-pci-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci

2013-01-23T00:36:23+00:00

Pull PCI updates from Bjorn Helgaas:
 "The most important is a fix for a pciehp deadlock that occurs when
  unplugging a Thunderbolt adapter.  We also applied the same fix to
  shpchp, removed CONFIG_EXPERIMENTAL dependencies, fixed a
  pcie_aspm=force problem, and fixed a refcount leak.

  Details:

   - Hotplug
      PCI: pciehp: Use per-slot workqueues to avoid deadlock
      PCI: shpchp: Make shpchp_wq non-ordered
      PCI: shpchp: Handle push button event asynchronously
      PCI: shpchp: Use per-slot workqueues to avoid deadlock

   - Power management
      PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported

   - Misc
      PCI/AER: pci_get_domain_bus_and_slot() call missing required pci_dev_put()
      PCI: remove depends on CONFIG_EXPERIMENTAL"

* tag '3.8-pci-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  PCI: remove depends on CONFIG_EXPERIMENTAL
  PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported
  PCI: shpchp: Use per-slot workqueues to avoid deadlock
  PCI: shpchp: Handle push button event asynchronously
  PCI: shpchp: Make shpchp_wq non-ordered
  PCI/AER: pci_get_domain_bus_and_slot() call missing required pci_dev_put()
  PCI: pciehp: Use per-slot workqueues to avoid deadlock

PCI: remove depends on CONFIG_EXPERIMENTAL

2013-01-17T23:22:05+00:00

The CONFIG_EXPERIMENTAL config item has not carried much meaning for a
while now and is almost always enabled by default. As agreed during the
Linux kernel summit, remove it from any "depends on" lines in Kconfigs.

Signed-off-by: Kees Cook 
Signed-off-by: Bjorn Helgaas

PCI: Allow pcie_aspm=force even when FADT indicates it is unsupported

2013-01-14T23:23:42+00:00

Right now using pcie_aspm=force will not enable ASPM if the FADT indicates
ASPM is unsupported.  However, the semantics of force should probably allow
for this, especially as they did before 3c076351c4 ("PCI: Rework ASPM
disable code")

This patch just skips the clearing of any ASPM setup that the firmware has
carried out on this bus if pcie_aspm=force is being used.

Reference: http://bugs.launchpad.net/bugs/962038
Signed-off-by: Colin Ian King 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org

Merge branch 'pci/yijing-hotplug-workqueues' into for-linus

2013-01-14T17:25:13+00:00

* pci/yijing-hotplug-workqueues:
  PCI: shpchp: Use per-slot workqueues to avoid deadlock
  PCI: shpchp: Handle push button event asynchronously
  PCI: shpchp: Make shpchp_wq non-ordered
  PCI: pciehp: Use per-slot workqueues to avoid deadlock

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

2013-01-14T17:23:22+00:00

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 
CC: stable@vger.kernel.org

PCI: shpchp: Handle push button event asynchronously

2013-01-14T17:23:07+00:00

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

PCI: shpchp: Make shpchp_wq non-ordered

2013-01-13T23:16:03+00:00

e24dcbef93 ("shpchp: update workqueue usage") was described as adding
non-ordered shpchp_wq, but it actually made it an *ordered* workqueue.

This patch changes shpchp_wq to be non-ordered, as described in the
e24dcbef93 commit log and as was done for pciehp by a827ea307b ("pciehp:
update workqueue usage").

Signed-off-by: Bjorn Helgaas 
Acked-by: Tejun Heo

PCI/AER: pci_get_domain_bus_and_slot() call missing required pci_dev_put()

2013-01-13T22:46:18+00:00

The function aer_recover_queue() calls pci_get_domain_bus_and_slot(), which
requires that the caller decrement the reference count with pci_dev_put().
This patch adds the missing call to pci_dev_put().

Signed-off-by: Betty Dall 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Shuah Khan 
CC: stable@vger.kernel.org

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

2013-01-12T20:56:33+00:00

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
CC: stable@vger.kernel.org

pci: fix iov.c kernel-doc warnings

2013-01-10T22:35:23+00:00

Fix kernel-doc warning in iov.c:

  Warning(drivers/pci/iov.c:752): No description found for parameter 'numvfs'

Signed-off-by: Randy Dunlap 
Sorry-by: Don Dutile 
Signed-off-by: Linus Torvalds