kernel.git/drivers/pci/bus.c, branch linux-3.14.y

PCI: Fix minimum allocation address overwrite

2016-02-17T20:34:35Z

commit 3460baa620685c20f5ee19afb6d99d26150c382c upstream. Commit 36e097a8a297 ("PCI: Split out bridge window override of minimum allocation address") claimed to do no functional changes but unfortunately did: The "min" variable is altered. At least the AVM A1 PCMCIA adapter was no longer detected, breaking ISDN operation. Use a local copy of "min" to restore the previous behaviour. [bhelgaas: avoid gcc "?:" extension for portability and readability] Fixes: 36e097a8a297 ("PCI: Split out bridge window override of minimum allocation address") Signed-off-by: Christoph Biedl Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman

PCI: Don't check resource_size() in pci_bus_alloc_resource()

2014-03-12T17:19:20Z

Paul reported that after f75b99d5a77d ("PCI: Enforce bus address limits in resource allocation") on a 32-bit kernel (CONFIG_PHYS_ADDR_T_64BIT not set), intel-gtt complained "can't ioremap flush page - no chipset flushing". In addition, other PCI resource allocations, e.g., for bridge windows, failed. This happens because we incorrectly skip bus resources of [mem 0x00000000-0xffffffff] because we think they are of size zero. When resource_size_t is 32 bits wide, resource_size() on [mem 0x00000000-0xffffffff] returns 0 because (r->end - r->start + 1) overflows. Therefore, we can't use "resource_size() == 0" to decide that allocation from this resource will fail. allocate_resource() should fail anyway if it can't satisfy the address constraints, so we should just depend on that. A [mem 0x00000000-0xffffffff] bus resource is obviously not really valid, but we do fall back to it as a default when we don't have information about host bridge apertures. Link: https://bugzilla.kernel.org/show_bug.cgi?id=71611 Fixes: f75b99d5a77d PCI: Enforce bus address limits in resource allocation Reported-and-tested-by: Paul Bolle Signed-off-by: Bjorn Helgaas

Merge branch 'pci/resource' into next

2014-01-10T21:23:15Z

* pci/resource: PCI: Allocate 64-bit BARs above 4G when possible PCI: Enforce bus address limits in resource allocation PCI: Split out bridge window override of minimum allocation address agp/ati: Use PCI_COMMAND instead of hard-coded 4 agp/intel: Use CPU physical address, not bus address, for ioremap() agp/intel: Use pci_bus_address() to get GTTADR bus address agp/intel: Use pci_bus_address() to get MMADR bus address agp/intel: Support 64-bit GMADR agp/intel: Rename gtt_bus_addr to gtt_phys_addr drm/i915: Rename gtt_bus_addr to gtt_phys_addr agp: Use pci_resource_start() to get CPU physical address for BAR agp: Support 64-bit APBASE PCI: Add pci_bus_address() to get bus address of a BAR PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev PCI: Change pci_bus_region addresses to dma_addr_t

PCI: Allocate 64-bit BARs above 4G when possible

2014-01-07T23:24:33Z

Try to allocate space for 64-bit BARs above 4G first, to preserve the space below 4G for 32-bit BARs. If there's no space above 4G available, fall back to allocating anywhere. [bhelgaas: reworked starting from http://lkml.kernel.org/r/1387485843-17403-2-git-send-email-yinghai@kernel.org] Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas

PCI: Enforce bus address limits in resource allocation

2014-01-07T23:24:33Z

When allocating space for 32-bit BARs, we previously limited RESOURCE addresses so they would fit in 32 bits. However, the BUS address need not be the same as the resource address, and it's the bus address that must fit in the 32-bit BAR. This patch adds: - pci_clip_resource_to_region(), which clips a resource so it contains only the range that maps to the specified bus address region, e.g., to clip a resource to 32-bit bus addresses, and - pci_bus_alloc_from_region(), which allocates space for a resource from the specified bus address region, and changes pci_bus_alloc_resource() to allocate space for 64-bit BARs from the entire bus address region, and space for 32-bit BARs from only the bus address region below 4GB. If we had this window: pci_root HWP0002:0a: host bridge window [mem 0xf0180000000-0xf01fedfffff] (bus address [0x80000000-0xfedfffff]) we previously could not put a 32-bit BAR there, because the CPU addresses don't fit in 32 bits. This patch fixes this, so we can use this space for 32-bit BARs. It's also possible (though unlikely) to have resources with 32-bit CPU addresses but bus addresses above 4GB. In this case the previous code would allocate space that a 32-bit BAR could not map. Remove PCIBIOS_MAX_MEM_32, which is no longer used. [bhelgaas: reworked starting from http://lkml.kernel.org/r/1386658484-15774-3-git-send-email-yinghai@kernel.org] Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas

PCI: Split out bridge window override of minimum allocation address

2014-01-07T23:24:33Z

pci_bus_alloc_resource() avoids allocating space below the "min" supplied by the caller (usually PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM). This is to protect badly documented motherboard resources. But if we're allocating space inside an already-configured PCI-PCI bridge window, we ignore "min". See 688d191821de ("pci: make bus resource start address override minimum IO address"). This patch moves the check to make it more visible and simplify future patches. No functional change. Signed-off-by: Bjorn Helgaas

PCI: Move pci_proc_attach_device() to pci_bus_add_device()

2013-12-18T20:53:38Z

4f535093cf8f ("PCI: Put pci_dev in device tree as early as possible") moved pci_proc_attach_device() from pci_bus_add_device() to pci_device_add(). This moves it back to pci_bus_add_device(), essentially reverting that part of 4f535093cf8f. This makes it symmetric with pci_stop_dev(), where we call pci_proc_detach_device() and pci_remove_sysfs_dev_files() and set dev->is_added = 0. [bhelgaas: changelog, create sysfs then attach proc for symmetry] Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas

PCI: Delay enabling bridges until they're needed

2013-07-25T18:35:03Z

We currently enable PCI bridges after scanning a bus and assigning resources. This is often done in arch code. This patch changes this so we don't enable a bridge until necessary, i.e., until we enable a PCI device behind the bridge. We do this in the generic pci_enable_device() path, so this also removes the arch-specific code to enable bridges. [bhelgaas: changelog] Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas

PCI: Introduce pci_bus_{get|put}() to manage PCI bus reference count

2013-05-27T22:22:09Z

Introduce helper functions pci_bus_{get|put}() to manage PCI bus reference count. Signed-off-by: Jiang Liu Signed-off-by: Yijing Wang Signed-off-by: Gu Zheng Signed-off-by: Bjorn Helgaas

PCI: Delay final fixups until resources are assigned

2013-05-07T20:35:44Z

Commit 4f535093cf "PCI: Put pci_dev in device tree as early as possible" moved final fixups from pci_bus_add_device() to pci_device_add(). But pci_device_add() happens before resource assignment, so BARs may not be valid yet. Typical flow for hot-add: pciehp_configure_device pci_scan_slot pci_scan_single_device pci_device_add pci_fixup_device(pci_fixup_final, dev) # previous location # resource assignment happens here pci_bus_add_devices pci_bus_add_device pci_fixup_device(pci_fixup_final, dev) # new location [bhelgaas: changelog, move fixups to pci_bus_add_device()] Reference: https://lkml.kernel.org/r/20130415182614.GB9224@xanatos Reported-by: David Bulkow Tested-by: David Bulkow Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.9+