user/sven/linux.git/drivers/pci, branch v3.2.64

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

2014-06-09T12:29:12Z

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

PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled

2014-04-01T23:59:02Z

commit 3cdeb713dc66057b50682048c151eae07b186c42 upstream. Andreas reported that after 1f42db786b14 ("PCI: Enable INTx if BIOS left them disabled"), pciehp surprise removal stopped working. This happens because pci_reenable_device() on the hotplug bridge (used in the pciehp_configure_device() path) clears the Interrupt Disable bit, which apparently breaks the bridge's MSI hotplug event reporting. Previously we cleared the Interrupt Disable bit in do_pci_enable_device(), which is used by both pci_enable_device() and pci_reenable_device(). But we use pci_reenable_device() after the driver may have enabled MSI or MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X. This patch clears Interrupt Disable only when MSI/MSI-X has not been enabled. Fixes: 1f42db786b14 PCI: Enable INTx if BIOS left them disabled Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691 Reported-and-tested-by: Andreas Noever Signed-off-by: Bjorn Helgaas CC: Sarah Sharp Signed-off-by: Ben Hutchings

PCI: Enable INTx if BIOS left them disabled

2014-04-01T23:58:52Z

commit 1f42db786b14a31bf807fc41ee5583a00c08fcb1 upstream. Some firmware leaves the Interrupt Disable bit set even if the device uses INTx interrupts. Clear Interrupt Disable so we get those interrupts. Based on the report mentioned below, if the user selects the "EHCI only" option in the Intel Baytrail BIOS, the EHCI device is handed off to the OS with the PCI_COMMAND_INTX_DISABLE bit set. Link: http://lkml.kernel.org/r/20140114181721.GC12126@xanatos Link: https://bugzilla.kernel.org/show_bug.cgi?id=70601 Reported-by: Chris Cheng Reported-and-tested-by: Jamie Chen Signed-off-by: Bjorn Helgaas CC: Sarah Sharp Signed-off-by: Ben Hutchings

PCI: Enable ARI if dev and upstream bridge support it; disable otherwise

2014-02-15T19:20:10Z

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

PCI: Remove duplicate pci_disable_device() from pcie_portdrv_remove()

2014-01-03T04:33:23Z

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

PCI: fix truncation of resource size to 32 bits

2013-11-28T14:01:58Z

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 Signed-off-by: Ben Hutchings

pci: frv architecture needs generic setup-bus infrastructure

2013-09-10T00:57:37Z

commit cd0a2bfb77a3edeecd652081e0b1a163d3b0696b upstream. Otherwise we get this link failure for frv's defconfig: LD .tmp_vmlinux1 drivers/built-in.o: In function `pci_assign_resource': (.text+0xbf0c): undefined reference to `pci_cardbus_resource_alignment' drivers/built-in.o: In function `pci_setup': pci.c:(.init.text+0x174): undefined reference to `pci_realloc_get_opt' pci.c:(.init.text+0x1a0): undefined reference to `pci_realloc_get_opt' make[1]: *** [.tmp_vmlinux1] Error 1 Cc: David Howells Acked-by: Bjorn Helgaas Signed-off-by: Paul Gortmaker Signed-off-by: Ben Hutchings

ahci: Add AMD CZ SATA device ID

2013-07-27T04:34:05Z

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

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