linux/drivers/pci, branch v3.2.46

PCI/PM: Fix fallback to PCI_D0 in pci_platform_power_transition()

2013-05-13T14:02:19Z

commit 769ba7212f2059ca9fe0c73371e3d415c8c1c529 upstream. Commit b51306c (PCI: Set device power state to PCI_D0 for device without native PM support) modified pci_platform_power_transition() by adding code causing dev->current_state for devices that don't support native PCI PM but are power-manageable by the platform to be changed to PCI_D0 regardless of the value returned by the preceding platform_pci_set_power_state(). In particular, that also is done if the platform_pci_set_power_state() has been successful, which causes the correct power state of the device set by pci_update_current_state() in that case to be overwritten by PCI_D0. Fix that mistake by making the fallback to PCI_D0 only happen if the platform_pci_set_power_state() has returned an error. [bhelgaas: folded in Yinghai's simplification, added URL & stable info] Reference: http://lkml.kernel.org/r/27806FC4E5928A408B78E88BBC67A2306F466BBA@ORSMSX101.amr.corp.intel.com Reported-by: Chris J. Benenati Signed-off-by: Rafael J. Wysocki Signed-off-by: Bjorn Helgaas Acked-by: Yinghai Lu Signed-off-by: Ben Hutchings

PCI/PM: Clean up PME state when removing a device

2013-03-06T03:23:58Z

commit 249bfb83cf8ba658955f0245ac3981d941f746ee upstream. Devices are added to pci_pme_list when drivers use pci_enable_wake() or pci_wake_from_d3(), but they aren't removed from the list unless the driver explicitly disables wakeup. Many drivers never disable wakeup, so their devices remain on the list even after they are removed, e.g., via hotplug. A subsequent PME poll will oops when it tries to touch the device. This patch disables PME# on a device before removing it, which removes the device from pci_pme_list. This is safe even if the device never had PME# enabled. This oops can be triggered by unplugging a Thunderbolt ethernet adapter on a Macbook Pro, as reported by Daniel below. [bhelgaas: changelog] Reference: http://lkml.kernel.org/r/CAMVG2svG21yiM1wkH4_2pen2n+cr2-Zv7TbH3Gj+8MwevZjDbw@mail.gmail.com Reported-and-tested-by: Daniel J Blueman Signed-off-by: Rafael J. Wysocki Signed-off-by: Bjorn Helgaas Signed-off-by: Ben Hutchings

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

2013-02-06T04:33:34Z

commit 9e16721498b0c3d3ebfa0b503c63d35c0a4c0642 upstream. 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 Signed-off-by: Ben Hutchings

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

2013-02-06T04:33:33Z

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

PCI: shpchp: Handle push button event asynchronously

2013-02-06T04:33:33Z

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: Ben Hutchings

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

2013-02-06T04:33:33Z

commit a82b6af37d20bfe6e99a4d890f1cf1d89059929f upstream. 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 Signed-off-by: Ben Hutchings

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

2013-02-06T04:33:32Z

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 [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

PCI: pciehp: Handle push button event asynchronously

2013-02-06T04:33:32Z

commit 486b10b9f43500741cd63a878d0ef23cd87fc66d 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 pciehp as a result. Signed-off-by: Kenji Kaneshige Signed-off-by: Jesse Barnes Signed-off-by: Ben Hutchings

PCI: pciehp: Fix wrong workqueue cleanup

2013-02-06T04:33:32Z

commit 027e8d52abdd44bc00e405af83cd2fbfb96c0824 upstream. Fix improper workqueue cleanup. In the current pciehp, pcied_cleanup() calls destroy_workqueue() before calling pcie_port_service_unregister(). This causes kernel oops because flush_workqueue() is called in the pcie_port_service_unregister() code path after the workqueue was destroyed. So pcied_cleanup() must call pcie_port_service_unregister() first before calling destroy_workqueue(). Signed-off-by: Kenji Kaneshige Signed-off-by: Jesse Barnes Signed-off-by: Ben Hutchings

PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHz

2013-01-16T01:13:13Z

commit 812089e01b9f65f90fc8fc670d8cce72a0e01fbb upstream. Otherwise it fails like this on cards like the Transcend 16GB SDHC card: mmc0: new SDHC card at address b368 mmcblk0: mmc0:b368 SDC 15.0 GiB mmcblk0: error -110 sending status command, retrying mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0 Tested on my Lenovo x200 laptop. [bhelgaas: changelog] Signed-off-by: Andy Lutomirski Signed-off-by: Bjorn Helgaas Acked-by: Chris Ball CC: Manoj Iyer Signed-off-by: Ben Hutchings