kernel/linux.git/drivers/pci, branch v3.4.105

PCI: Fix incorrect vgaarb conditional in WARN_ON()

2014-07-07T01:49:19+00:00

commit 67ebd8140dc8923c65451fa0f6a8eee003c4dcd3 upstream. 3448a19da479 "vgaarb: use bridges to control VGA routing where possible" added the "flags & PCI_VGA_STATE_CHANGE_DECODES" condition to an existing WARN_ON(), but used bitwise AND (&) instead of logical AND (&&), so the condition is never true. Replace with logical AND. Found by Coverity (CID 142811). Fixes: 3448a19da479 "vgaarb: use bridges to control VGA routing where possible" Signed-off-by: Bjorn Helgaas Acked-by: Yinghai Lu Acked-by: David Airlie Signed-off-by: Greg Kroah-Hartman

PCI: Add new ID for Intel GPU "spurious interrupt" quirk

2014-07-07T01:49:19+00:00

commit 7c82126a94e69bbbac586f0249e7ef11e681246c upstream. After a CPU upgrade while keeping the same mainboard, we faced "spurious interrupt" problems again. It turned out that the new CPU also featured a new GPU with a different PCI ID. Add this PCI ID to the quirk table. Probably all other Intel GPU PCI IDs are affected, too, but I don't want to add them without a test system. See f67fd55fa96f ("PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUs") for some history. [bhelgaas: add f67fd55fa96f reference, stable tag] Signed-off-by: Thomas Jarosch Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman

PCI/ASPM: Don't touch ASPM if forcibly disabled

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

commit a26d5ecb3201c11e03663a8f4a7dedc0c5f85c07 upstream. Don't allocate and track PCIe ASPM state when "pcie_aspm=off" is specified on the kernel command line. Based-on-patch-from: Matthew Garrett Signed-off-by: Joe Lawrence Signed-off-by: Bjorn Helgaas Reviewed-by: David Bulkow Acked-by: Myron Stowe [wyj: Backported to 3.4: context adjust] Signed-off-by: Yijing Wang Signed-off-by: Greg Kroah-Hartman

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: Enable ARI if dev and upstream bridge support it; disable otherwise

2014-02-13T19:51:17+00:00

commit b0cc6020e1cc62f1253215f189611b34be4a83c7 upstream. Currently, we enable ARI in a device's upstream bridge if the bridge and the device support it. But we never disable ARI, even if the device is removed and replaced with a device that doesn't support ARI. This means that if we hot-remove an ARI device and replace it with a non-ARI multi-function device, we find only function 0 of the new device because the upstream bridge still has ARI enabled, and next_ari_fn() only returns function 0 for the new non-ARI device. This patch disables ARI in the upstream bridge if the device doesn't support ARI. See the PCIe spec, r3.0, sec 6.13. [bhelgaas: changelog, function comment] [yijing: replace PCIe Cap accessor with legacy PCI accessor] Signed-off-by: Yijing Wang Signed-off-by: Jiang Liu Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman

PCI: Remove duplicate pci_disable_device() from pcie_portdrv_remove()

2013-12-04T18:50:32+00:00

commit e7cc5cf74544d97d7b69e2701595037474db1f96 upstream. The pcie_portdrv .probe() method calls pci_enable_device() once, in pcie_port_device_register(), but the .remove() method calls pci_disable_device() twice, in pcie_port_device_remove() and in pcie_portdrv_remove(). That causes a "disabling already-disabled device" warning when removing a PCIe port device. This happens all the time when removing Thunderbolt devices, but is also easy to reproduce with, e.g., "echo 0000:00:1c.3 > /sys/bus/pci/drivers/pcieport/unbind" This patch removes the disable from pcie_portdrv_remove(). [bhelgaas: changelog, tag for stable] Reported-by: David Bulkow Reported-by: Mika Westerberg Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman

PCI/PM: Clear state_saved during suspend

2013-11-20T18:43:19+00:00

commit 82fee4d67ab86d6fe5eb0f9a9e988ca9d654d765 upstream. This patch clears pci_dev->state_saved at the beginning of suspending. PCI config state may be saved long before that. Some drivers call pci_save_state() from the ->probe() callback to get snapshot of sane configuration space to use in the ->slot_reset() callback. [wangyj: adjust context] Signed-off-by: Konstantin Khlebnikov # add comment Signed-off-by: Bjorn Helgaas Signed-off-by: Yijing Wang Signed-off-by: Greg Kroah-Hartman

PCI: fix truncation of resource size to 32 bits

2013-11-20T18:43:18+00:00

commit d6776e6d5c2f8db0252f447b09736075e1bbe387 upstream. _pci_assign_resource() took an int "size" argument, which meant that sizes larger than 4GB were truncated. Change type to resource_size_t. [bhelgaas: changelog] Signed-off-by: Nikhil P Rao Signed-off-by: Bjorn Helgaas Cc: Jiri Slaby Signed-off-by: Greg Kroah-Hartman

ahci: Add AMD CZ SATA device ID

2013-07-22T01:19:01+00:00

commit fafe5c3d82a470d73de53e6b08eb4e28d974d895 upstream. To add AMD CZ SATA controller device ID of IDE mode. [bhelgaas: drop pci_ids.h update] Signed-off-by: Shane Huang Signed-off-by: Bjorn Helgaas Reviewed-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman