kernel/git/stable/linux.git/drivers/pci, branch linux-3.11.y

PCI: Support PCIe Capability Slot registers only for ports with slots

2013-11-29T18:42:15+00:00

commit 6d3a1741f1e648cfbd5a0cc94477a0d5004c6f5e upstream. Previously we allowed callers to access Slot Capabilities, Status, and Control for Root Ports even if the Root Port did not implement a slot. This seems dubious because the spec only requires these registers if a slot is implemented. It's true that even Root Ports without slots must have *space* for these slot registers, because the Root Capabilities, Status, and Control registers are after the slot registers in the capability. However, for a v1 PCIe Capability, the *semantics* of the slot registers are undefined unless a slot is implemented. Signed-off-by: Bjorn Helgaas Reviewed-By: Jiang Liu Acked-by: Myron Stowe Signed-off-by: Greg Kroah-Hartman

PCI: Remove PCIe Capability version checks

2013-11-29T18:42:15+00:00

commit c8b303d0206b28c4ff3aecada47108d1655ae00f upstream. Previously we relied on the PCIe r3.0, sec 7.8, spec language that says "For Functions that do not implement the [Link, Slot, Root] registers, these spaces must be hardwired to 0b," which means that for v2 PCIe capabilities, we don't need to check the device type at all. But it's simpler if we don't need to check the capability version at all, and I think the spec is explicit enough about which registers are required for which types that we can remove the version checks. Signed-off-by: Bjorn Helgaas Reviewed-By: Jiang Liu Acked-by: Myron Stowe Signed-off-by: Greg Kroah-Hartman

PCI: Allow PCIe Capability link-related register access for switches

2013-11-29T18:42:15+00:00

commit d3694d4fa3f44f6a295f8ab064937c8a1549d174 upstream. Every PCIe device has a link, except Root Complex Integrated Endpoints and Root Complex Event Collectors. Previously we didn't give access to PCIe capability link-related registers for Upstream Ports, Downstream Ports, and Bridges, so attempts to read PCI_EXP_LNKCTL incorrectly returned zero. See PCIe spec r3.0, sec 7.8 and 1.3.2.3. Reference: http://lkml.kernel.org/r/979A8436335E3744ADCD3A9F2A2B68A52AD136BE@SJEXCHMB10.corp.ad.broadcom.com Reported-by: Yuval Mintz Signed-off-by: Bjorn Helgaas Reviewed-By: Jiang Liu Signed-off-by: Greg Kroah-Hartman

PCI / ACPI / PM: Clear pme_poll for devices in D3cold on wakeup

2013-10-01T16:40:57+00:00

commit 834145156bedadfb50121f0bc5e9d9f9f942bcca upstream. Commit 448bd85 (PCI/PM: add PCIe runtime D3cold support) added a piece of code to pci_acpi_wake_dev() causing that function to behave in a special way for devices in D3cold (so that their configuration registers are not accessed before those devices are resumed). However, it didn't take the clearing of the pme_poll flag into account. That has to be done for all devices, even if they are in D3cold, or pci_pme_list_scan() will not know that wakeup has been signaled for the device and will poll its PME Status bit unnecessarily. Fix the problem by moving the clearing of the pme_poll flag in pci_acpi_wake_dev() before the code introduced by commit 448bd85. Reported-and-tested-by: David E. Box Signed-off-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman

ACPI: Try harder to resolve _ADR collisions for bridges

2013-08-07T20:55:00+00:00

In theory, under a given ACPI namespace node there should be only one child device object with _ADR whose value matches a given bus address exactly. In practice, however, there are systems in which multiple child device objects under a given parent have _ADR matching exactly the same address. In those cases we use _STA to determine which of the multiple matching devices is enabled, since some systems are known to indicate which ACPI device object to associate with the given physical (usually PCI) device this way. Unfortunately, as it turns out, there are systems in which many device objects under the same parent have _ADR matching exactly the same bus address and none of them has _STA, in which case they all should be regarded as enabled according to the spec. Still, if those device objects are supposed to represent bridges (e.g. this is the case for device objects corresponding to PCIe ports), we can try harder and skip the ones that have no child device objects in the ACPI namespace. With luck, we can avoid using device objects that we are not expected to use this way. Although this only works for bridges whose children also have ACPI namespace representation, it is sufficient to address graphics adapter detection issues on some systems, so rework the code finding a matching device ACPI handle for a given bus address to implement this idea. Introduce a new function, acpi_find_child(), taking three arguments: the ACPI handle of the device's parent, a bus address suitable for the device's bus type and a bool indicating if the device is a bridge and make it work as outlined above. Reimplement the function currently used for this purpose, acpi_get_child(), as a call to acpi_find_child() with the last argument set to 'false' and make the PCI subsystem use acpi_find_child() with the bridge information passed as the last argument to it. [Lan Tianyu notices that it is not sufficient to use pci_is_bridge() for that, because the device's subordinate pointer hasn't been set yet at this point, so use hdr_type instead.] This change fixes a regression introduced inadvertently by commit 33f767d (ACPI: Rework acpi_get_child() to be more efficient) which overlooked the fact that for acpi_walk_namespace() "post-order" means "after all children have been visited" rather than "on the way back", so for device objects without children and for namespace walks of depth 1, as in the acpi_get_child() case, the "post-order" callbacks ordering is actually the same as the ordering of "pre-order" ones. Since that commit changed the namespace walk in acpi_get_child() to terminate after finding the first matching object instead of going through all of them and returning the last one, it effectively changed the result returned by that function in some rare cases and that led to problems (the switch from a "pre-order" to a "post-order" callback was supposed to prevent that from happening, but it was ineffective). As it turns out, the systems where the change made by commit 33f767d actually matters are those where there are multiple ACPI device objects representing the same PCIe port (which effectively is a bridge). Moreover, only one of them, and the one we are expected to use, has child device objects in the ACPI namespace, so the regression can be addressed as described above. References: https://bugzilla.kernel.org/show_bug.cgi?id=60561 Reported-by: Peter Wu Tested-by: Vladimir Lalov Signed-off-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas Cc: 3.9+ # 3.9+

Merge tag 'pci-v3.11-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci

2013-08-02T20:12:52+00:00

Pull PCI fixes from Bjorn Helgaas: "Yinghai fixed a couple regressions: one resource assignment problem introduced in v3.10 that showed up with SR-IOV on powerpc, and another SR-IOV hot-remove issue related to refcounting changes we merged for v3.11. Yinghai is still working on another SR-IOV-related fix or two, which will be simpler if pciehp is non-modular, so I included the Kconfig changes now to get them in earlier. Finally, a minor fix for the ARM Marvell EBU host bridge driver that was merged for v3.11 Hotplug: PCI: pciehp: Fix null pointer deref when hot-removing SR-IOV device PCI: hotplug: Convert to be builtin only, not modular PCI: pciehp: Convert pciehp to be builtin only, not modular Resource allocation: PCI: Retry allocation of only the resource type that failed ARM: PCI: mvebu: Disable prefetchable memory support in PCI-to-PCI bridge" * tag 'pci-v3.11-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: mvebu: Disable prefetchable memory support in PCI-to-PCI bridge PCI: Retry allocation of only the resource type that failed PCI: pciehp: Convert pciehp to be builtin only, not modular PCI: hotplug: Convert to be builtin only, not modular PCI: pciehp: Fix null pointer deref when hot-removing SR-IOV device

PCI: mvebu: Disable prefetchable memory support in PCI-to-PCI bridge

2013-08-01T20:47:54+00:00

The Marvell PCIe driver uses an emulated PCI-to-PCI bridge to be able to dynamically set up MBus address decoding windows for PCI I/O and memory regions depending on the PCI devices enumerated by Linux. However, this emulated PCI-to-PCI bridge logic makes the Linux PCI core believe that prefetchable memory regions are supported (because the registers are read/write), while in fact no adress decoding window is ever created for such regions. Since the Marvell MBus address decoding windows do not distinguish memory regions and prefetchable memory regions, this patch takes a simple approach: change the PCI-to-PCI bridge emulation to let the Linux PCI core know that we don't support prefetchable memory regions. To achieve this, we simply make the prefetchable memory base a read-only register that always returns 0. Reading/writing all the other prefetchable memory related registers has no effect. This problem was originally reported by Finn Hoffmann , who couldn't get a RTL8111/8168B PCI NIC working on the NSA310 Kirkwood platform after updating to 3.11-rc. The problem was that the PCI-to-PCI bridge emulation was making the Linux PCI core believe that we support prefetchable memory, so the Linux PCI core was only filling the prefetchable memory base and limit registers, which does not lead to a MBus window being created. The below patch has been confirmed by Finn Hoffmann to fix his problem on Kirkwood, and has otherwise been successfully tested on the Armada XP GP platform with a e1000e PCIe NIC and a Marvell SATA PCIe card. Reported-by: Finn Hoffmann Signed-off-by: Thomas Petazzoni Signed-off-by: Bjorn Helgaas

PCI: Retry allocation of only the resource type that failed

2013-07-26T13:32:20+00:00

Ben Herrenschmidt reported the following problem: - The bus has space for all desired MMIO resources, including optional space for SR-IOV devices - We attempt to allocate I/O port space, but it fails because the bus has no I/O space - Because of the I/O allocation failure, we retry MMIO allocation, requesting only the required space, without the optional SR-IOV space This means we don't allocate the optional SR-IOV space, even though we could. This is related to 0c5be0cb0e ("PCI: Retry on IORESOURCE_IO type allocations"). This patch changes how we handle allocation failures. We will now retry allocation of only the resource type that failed. If MMIO allocation fails, we'll retry only MMIO allocation. If I/O port allocation fails, we'll retry only I/O port allocation. [bhelgaas: changelog] Reference: https://lkml.kernel.org/r/1367712653.11982.19.camel@pasglop Reported-by: Benjamin Herrenschmidt Tested-by: Gavin Shan Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.10+

PCI: pciehp: Convert pciehp to be builtin only, not modular

2013-07-26T13:32:12+00:00

Convert pciehp to be builtin only, with no module option. Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki Acked-by: Yinghai Lu

PCI: hotplug: Convert to be builtin only, not modular

2013-07-25T20:11:06+00:00

Convert CONFIG_HOTPLUG_PCI from tristate to bool. This only affects the hotplug core; several of the hotplug drivers can still be modules. Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki Acked-by: Yinghai Lu