08 Jul, 2020

1 commit

  • device_attach() returning failure indicates a driver error while trying to
    probe the device. In such a scenario, the PCI device should still be added
    in the system and be visible to the user.

    When device_attach() fails, merely warn about it and keep the PCI device in
    the system.

    This partially reverts ab1a187bba5c ("PCI: Check device_attach() return
    value always").

    Link: https://lore.kernel.org/r/20200706233240.3245512-1-rajatja@google.com
    Signed-off-by: Rajat Jain
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Greg Kroah-Hartman
    Cc: stable@vger.kernel.org # v4.6+

    Rajat Jain
     

24 Jul, 2019

1 commit

  • pci_bus_get() and pci_bus_put() are not used by a loadable kernel module
    and do not need to be exported.

    These were exported by fe830ef62ac6 ("PCI: Introduce pci_bus_{get|put}() to
    manage PCI bus reference count"), but there are no loadable modules in the
    tree that use them.

    Link: https://lore.kernel.org/r/20190717182353.45557-1-skunberg.kelsey@gmail.com
    Signed-off-by: Kelsey Skunberg
    Signed-off-by: Bjorn Helgaas
    Acked-by: Greg Kroah-Hartman

    Kelsey Skunberg
     

09 May, 2019

2 commits

  • Replace dev_printk(KERN_DEBUG) with dev_info(), etc to be more consistent
    with other logging and avoid checkpatch warnings.

    The KERN_DEBUG messages could be converted to dev_dbg(), but that depends
    on CONFIG_DYNAMIC_DEBUG and DEBUG, and we want most of these messages to
    *always* be in the dmesg log.

    Link: https://lore.kernel.org/lkml/1555733240-19875-1-git-send-email-mohankumar718@gmail.com
    Signed-off-by: Mohan Kumar
    [bhelgaas: commit log]
    Signed-off-by: Bjorn Helgaas

    Mohan Kumar
     
  • Replace printk() with pr_*() to be more consistent with other logging and
    avoid checkpatch warnings.

    Link: https://lore.kernel.org/lkml/1555733026-19609-1-git-send-email-mohankumar718@gmail.com
    Link: https://lore.kernel.org/lkml/1555733130-19804-1-git-send-email-mohankumar718@gmail.com
    Signed-off-by: Mohan Kumar
    [bhelgaas: squash in similar changes from second patch in series]
    Signed-off-by: Bjorn Helgaas

    Mohan Kumar
     

01 Aug, 2018

1 commit

  • When a PCI device is detected, pdev->is_added is set to 1 and proc and
    sysfs entries are created.

    When the device is removed, pdev->is_added is checked for one and then
    device is detached with clearing of proc and sys entries and at end,
    pdev->is_added is set to 0.

    is_added and is_busmaster are bit fields in pci_dev structure sharing same
    memory location.

    A strange issue was observed with multiple removal and rescan of a PCIe
    NVMe device using sysfs commands where is_added flag was observed as zero
    instead of one while removing device and proc,sys entries are not cleared.
    This causes issue in later device addition with warning message
    "proc_dir_entry" already registered.

    Debugging revealed a race condition between the PCI core setting the
    is_added bit in pci_bus_add_device() and the NVMe driver reset work-queue
    setting the is_busmaster bit in pci_set_master(). As these fields are not
    handled atomically, that clears the is_added bit.

    Move the is_added bit to a separate private flag variable and use atomic
    functions to set and retrieve the device addition state. This avoids the
    race because is_added no longer shares a memory location with is_busmaster.

    Link: https://bugzilla.kernel.org/show_bug.cgi?id=200283
    Signed-off-by: Hari Vyas
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Lukas Wunner
    Acked-by: Michael Ellerman

    Hari Vyas
     

09 May, 2018

1 commit


20 Mar, 2018

1 commit

  • Remove pointless comments that tell us the file name, remove blank line
    comments, follow multi-line comment conventions. No functional change
    intended.

    Signed-off-by: Bjorn Helgaas

    Bjorn Helgaas
     

02 Feb, 2018

1 commit

  • * pci/spdx:
    PCI: Add SPDX GPL-2.0+ to replace implicit GPL v2 or later statement
    PCI: Add SPDX GPL-2.0+ to replace GPL v2 or later boilerplate
    PCI: Add SPDX GPL-2.0 to replace COPYING boilerplate
    PCI: Add SPDX GPL-2.0 to replace GPL v2 boilerplate
    PCI: Add SPDX GPL-2.0 when no license was specified

    Bjorn Helgaas
     

27 Jan, 2018

1 commit

  • b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to
    files with no license") added SPDX GPL-2.0 to several PCI files that
    previously contained no license information.

    Add SPDX GPL-2.0 to all other PCI files that did not contain any license
    information and hence were under the default GPL version 2 license of the
    kernel.

    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Greg Kroah-Hartman

    Bjorn Helgaas
     

19 Jan, 2018

1 commit


18 Nov, 2016

1 commit

  • The algorithm to update the flag indicating whether a bridge may go to D3
    makes a few optimizations based on whether the update was caused by the
    removal of a device on the one hand, versus the addition of a device or the
    change of its D3cold flags on the other hand.

    The information whether the update pertains to a removal is currently
    passed in by the caller, but the function may as well determine that itself
    by examining the device in question, thereby allowing for a considerable
    simplification and reduction of the code.

    Out of several options to determine removal, I've chosen the function
    device_is_registered() because it's cheap: It merely returns the
    dev->kobj.state_in_sysfs flag. That flag is set through device_add() when
    the root bus is scanned and cleared through device_remove(). The call to
    pci_bridge_d3_update() happens after each of these calls, respectively, so
    the ordering is correct.

    No functional change intended.

    Tested-by: Mika Westerberg
    Signed-off-by: Lukas Wunner
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Rafael J. Wysocki

    Lukas Wunner
     

02 Aug, 2016

1 commit

  • * pci/demodularize-hosts:
    PCI: xgene: Make explicitly non-modular
    PCI: thunder-pem: Make explicitly non-modular
    PCI: thunder-ecam: Make explicitly non-modular
    PCI: tegra: Make explicitly non-modular
    PCI: rcar-gen2: Make explicitly non-modular
    PCI: rcar: Make explicitly non-modular
    PCI: mvebu: Make explicitly non-modular
    PCI: layerscape: Make explicitly non-modular
    PCI: keystone: Make explicitly non-modular
    PCI: hisi: Make explicitly non-modular
    PCI: generic: Make explicitly non-modular
    PCI: designware-plat: Make it explicitly non-modular
    PCI: artpec6: Make explicitly non-modular
    PCI: armada8k: Make explicitly non-modular
    PCI: artpec: Add PCI_MSI_IRQ_DOMAIN dependency
    PCI: artpec: Add Axis ARTPEC-6 PCIe controller driver
    PCI: Add DT binding for Axis ARTPEC-6 PCIe controller
    PCI: generic: Select IRQ_DOMAIN

    * pci/host-request-windows:
    PCI: versatile: Simplify host bridge window iteration
    PCI: versatile: Request host bridge window resources with core function
    PCI: tegra: Request host bridge window resources with core function
    PCI: tegra: Remove top-level resource from hierarchy
    PCI: rcar: Simplify host bridge window iteration
    PCI: rcar: Request host bridge window resources with core function
    PCI: rcar Gen2: Request host bridge window resources
    PCI: rcar: Drop gen2 dummy I/O port region
    ARM: Make PCI I/O space optional
    PCI: mvebu: Request host bridge window resources with core function
    PCI: generic: Simplify host bridge window iteration
    PCI: generic: Request host bridge window resources with core function
    PCI: altera: Simplify host bridge window iteration
    PCI: altera: Request host bridge window resources with core function
    PCI: xilinx-nwl: Use dev_printk() when possible
    PCI: xilinx-nwl: Request host bridge window resources
    PCI: xilinx-nwl: Free bridge resource list on failure
    PCI: xilinx: Request host bridge window resources
    PCI: xilinx: Free bridge resource list on failure
    PCI: xgene: Request host bridge window resources
    PCI: xgene: Free bridge resource list on failure
    PCI: iproc: Request host bridge window resources
    PCI: designware: Simplify host bridge window iteration
    PCI: designware: Request host bridge window resources
    PCI: designware: Free bridge resource list on failure
    PCI: Add devm_request_pci_bus_resources()

    Bjorn Helgaas
     

14 Jun, 2016

1 commit

  • Currently the Linux PCI core does not touch power state of PCI bridges and
    PCIe ports when system suspend is entered. Leaving them in D0 consumes
    power unnecessarily and may prevent the CPU from entering deeper C-states.

    With recent PCIe hardware we can power down the ports to save power given
    that we take into account few restrictions:

    - The PCIe port hardware is recent enough, starting from 2015.

    - Devices connected to PCIe ports are effectively in D3cold once the port
    is transitioned to D3 (the config space is not accessible anymore and
    the link may be powered down).

    - Devices behind the PCIe port need to be allowed to transition to D3cold
    and back. There is a way both drivers and userspace can forbid this.

    - If the device behind the PCIe port is capable of waking the system it
    needs to be able to do so from D3cold.

    This patch adds a new flag to struct pci_device called 'bridge_d3'. This
    flag is set and cleared by the PCI core whenever there is a change in power
    management state of any of the devices behind the PCIe port. When system
    later on is suspended we only need to check this flag and if it is true
    transition the port to D3 otherwise we leave it in D0.

    Also provide override mechanism via command line parameter
    "pcie_port_pm=[off|force]" that can be used to disable or enable the
    feature regardless of the BIOS manufacturing date.

    Tested-by: Lukas Wunner
    Signed-off-by: Mika Westerberg
    Signed-off-by: Bjorn Helgaas
    Acked-by: Rafael J. Wysocki

    Mika Westerberg
     

07 Jun, 2016

1 commit

  • Several host bridge drivers iterate through the list of bridge windows to
    request resources. Several others don't request the window resources at
    all.

    Add a devm_request_pci_bus_resources() interface to make it easier for
    drivers to request all the window resources. Export to GPL modules (from
    Arnd Bergmann ).

    Signed-off-by: Bjorn Helgaas

    Bjorn Helgaas
     

03 May, 2016

2 commits

  • Linux 4.5 introduced a behavioral change in device probing during the
    suspend process with commit 013c074f8642 ("PM / sleep: prohibit devices
    probing during suspend/hibernation"): It defers device probing during the
    entire suspend process, starting from the prepare phase and ending with the
    complete phase. A rule existed before that "we rely on subsystems not to
    do any probing once a device is suspended" but it is enforced only now
    (Alan Stern, https://lkml.org/lkml/2015/9/15/908).

    This resulted in a WARN splat if a PCI device (e.g., Thunderbolt) is
    plugged in while the system is asleep: Upon waking up, pciehp_resume()
    discovers new devices in the resume phase and immediately tries to bind
    them to a driver. Since probing is now deferred, device_attach() returns
    -EPROBE_DEFER, which provoked a WARN in pci_bus_add_device().

    Linux 4.6-rc1 aggravates the situation with commit ab1a187bba5c ("PCI:
    Check device_attach() return value always"): If device_attach() returns a
    negative value, pci_bus_add_device() now removes the sysfs and procfs
    entries for the device and pci_bus_add_devices() subsequently locks up with
    a BUG. Even with the BUG fixed we're still in trouble because the device
    remains on the deferred probing list even though its sysfs and procfs
    entries are gone and its children won't be added.

    Fix by not interpreting -EPROBE_DEFER as failure. The device will be
    probed eventually (through device_unblock_probing() in dpm_complete()) and
    there is proper locking in place to avoid races (e.g., if devices are
    unplugged again und thus deleted from the system before deferred probing
    happens, I have tested this). Also, those functions which dereference
    dev->driver (e.g. pci_pm_*()) do contain proper NULL pointer checks. So it
    seems safe to ignore -EPROBE_DEFER.

    Fixes: ab1a187bba5c ("PCI: Check device_attach() return value always")
    Signed-off-by: Lukas Wunner
    Signed-off-by: Bjorn Helgaas
    Acked-by: Rafael J. Wysocki
    Cc: Grygorii Strashko
    Cc: Alan Stern

    Lukas Wunner
     
  • Previously when pci_bus_add_device() called device_attach() and it returned
    a negative value, we emitted a WARN but carried on.

    Commit ab1a187bba5c ("PCI: Check device_attach() return value always"),
    introduced in Linux 4.6-rc1, changed this to unwind all steps preceding
    device_attach() and to not set dev->is_added = 1.

    The latter leads to a BUG if pci_bus_add_device() was called from
    pci_bus_add_devices(). Fix by not recursing to a child bus if
    device_attach() failed for the bridge leading to it.

    This can be triggered by plugging in a PCI device (e.g. Thunderbolt) while
    the system is asleep. The system locks up when woken because
    device_attach() returns -EPROBE_DEFER.

    Fixes: ab1a187bba5c ("PCI: Check device_attach() return value always")
    Signed-off-by: Lukas Wunner
    Signed-off-by: Bjorn Helgaas
    Acked-by: Rafael J. Wysocki

    Lukas Wunner
     

20 Mar, 2016

1 commit

  • Pull powerpc updates from Michael Ellerman:
    "This was delayed a day or two by some build-breakage on old toolchains
    which we've now fixed.

    There's two PCI commits both acked by Bjorn.

    There's one commit to mm/hugepage.c which is (co)authored by Kirill.

    Highlights:
    - Restructure Linux PTE on Book3S/64 to Radix format from Paul
    Mackerras
    - Book3s 64 MMU cleanup in preparation for Radix MMU from Aneesh
    Kumar K.V
    - Add POWER9 cputable entry from Michael Neuling
    - FPU/Altivec/VSX save/restore optimisations from Cyril Bur
    - Add support for new ftrace ABI on ppc64le from Torsten Duwe

    Various cleanups & minor fixes from:
    - Adam Buchbinder, Andrew Donnellan, Balbir Singh, Christophe Leroy,
    Cyril Bur, Luis Henriques, Madhavan Srinivasan, Pan Xinhui, Russell
    Currey, Sukadev Bhattiprolu, Suraj Jitindar Singh.

    General:
    - atomics: Allow architectures to define their own __atomic_op_*
    helpers from Boqun Feng
    - Implement atomic{, 64}_*_return_* variants and acquire/release/
    relaxed variants for (cmp)xchg from Boqun Feng
    - Add powernv_defconfig from Jeremy Kerr
    - Fix BUG_ON() reporting in real mode from Balbir Singh
    - Add xmon command to dump OPAL msglog from Andrew Donnellan
    - Add xmon command to dump process/task similar to ps(1) from Douglas
    Miller
    - Clean up memory hotplug failure paths from David Gibson

    pci/eeh:
    - Redesign SR-IOV on PowerNV to give absolute isolation between VFs
    from Wei Yang.
    - EEH Support for SRIOV VFs from Wei Yang and Gavin Shan.
    - PCI/IOV: Rename and export virtfn_{add, remove} from Wei Yang
    - PCI: Add pcibios_bus_add_device() weak function from Wei Yang
    - MAINTAINERS: Update EEH details and maintainership from Russell
    Currey

    cxl:
    - Support added to the CXL driver for running on both bare-metal and
    hypervisor systems, from Christophe Lombard and Frederic Barrat.
    - Ignore probes for virtual afu pci devices from Vaibhav Jain

    perf:
    - Export Power8 generic and cache events to sysfs from Sukadev
    Bhattiprolu
    - hv-24x7: Fix usage with chip events, display change in counter
    values, display domain indices in sysfs, eliminate domain suffix in
    event names, from Sukadev Bhattiprolu

    Freescale:
    - Updates from Scott: "Highlights include 8xx optimizations, 32-bit
    checksum optimizations, 86xx consolidation, e5500/e6500 cpu
    hotplug, more fman and other dt bits, and minor fixes/cleanup"

    * tag 'powerpc-4.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: (179 commits)
    powerpc: Fix unrecoverable SLB miss during restore_math()
    powerpc/8xx: Fix do_mtspr_cpu6() build on older compilers
    powerpc/rcpm: Fix build break when SMP=n
    powerpc/book3e-64: Use hardcoded mttmr opcode
    powerpc/fsl/dts: Add "jedec,spi-nor" flash compatible
    powerpc/T104xRDB: add tdm riser card node to device tree
    powerpc32: PAGE_EXEC required for inittext
    powerpc/mpc85xx: Add pcsphy nodes to FManV3 device tree
    powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)
    powerpc/86xx: Introduce and use common dtsi
    powerpc/86xx: Update device tree
    powerpc/86xx: Move dts files to fsl directory
    powerpc/86xx: Switch to kconfig fragments approach
    powerpc/86xx: Update defconfigs
    powerpc/86xx: Consolidate common platform code
    powerpc32: Remove one insn in mulhdu
    powerpc32: small optimisation in flush_icache_range()
    powerpc: Simplify test in __dma_sync()
    powerpc32: move xxxxx_dcache_range() functions inline
    powerpc32: Remove clear_pages() and define clear_page() inline
    ...

    Linus Torvalds
     

09 Mar, 2016

1 commit

  • This adds weak function pcibios_bus_add_device() for arch dependent
    code could do proper setup. For example, powerpc could setup EEH
    related resources for SRIOV VFs.

    Signed-off-by: Wei Yang
    Reviewed-by: Gavin Shan
    Acked-by: Bjorn Helgaas
    Signed-off-by: Michael Ellerman

    Wei Yang
     

06 Feb, 2016

1 commit

  • Previously we checked the device_attach() return value only when
    CONFIG_BUG=y. That caused this warning in builds where CONFIG_BUG is not
    set:

    drivers/pci/bus.c:237:6: warning: variable 'retval' set but not used [-Wunused-but-set-variable]

    Check the return value of device_attach() always and clean up after
    failure.

    Signed-off-by: Bjorn Helgaas
    Acked-by: Rafael J. Wysocki

    Bjorn Helgaas
     

07 Jan, 2016

1 commit

  • 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
    CC: stable@vger.kernel.org # v3.14+

    Christoph Biedl
     

23 Sep, 2015

1 commit

  • c770cb4cb505 ("PCI: Mark invalid BARs as unassigned") sets IORESOURCE_UNSET
    if we fail to claim a resource. If we tried to claim a bridge window,
    failed, clipped the window, and tried to claim the clipped window, we
    failed again because of IORESOURCE_UNSET:

    pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff window]
    pci 0000:00:01.0: can't claim BAR 15 [mem 0xbdf00000-0xddefffff 64bit pref]: no compatible bridge window
    pci 0000:00:01.0: [mem size 0x20000000 64bit pref] clipped to [mem size 0x1df00000 64bit pref]
    pci 0000:00:01.0: bridge window [mem size 0x1df00000 64bit pref]
    pci 0000:00:01.0: can't claim BAR 15 [mem size 0x1df00000 64bit pref]: no address assigned

    The 00:01.0 window started as [mem 0xbdf00000-0xddefffff 64bit pref]. That
    starts before the host bridge window [mem 0xc0000000-0xffffffff window], so
    we clipped the 00:01.0 window to [mem 0xc0000000-0xddefffff 64bit pref].
    But we left it marked IORESOURCE_UNSET, so the second claim failed when it
    should have succeeded.

    This means downstream devices will also fail for lack of resources, e.g.,
    in the bugzilla below,

    radeon 0000:01:00.0: Fatal error during GPU init

    Clear IORESOURCE_UNSET when we clip a bridge window. Also clear
    IORESOURCE_UNSET in our copy of the unclipped window so we can see exactly
    what the original window was and how it now fits inside the upstream
    window.

    Fixes: c770cb4cb505 ("PCI: Mark invalid BARs as unassigned")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491#c47
    Based-on-patch-by: Lorenzo Pieralisi
    Based-on-patch-by: Yinghai Lu
    Tested-by: Lorenzo Pieralisi
    Signed-off-by: Bjorn Helgaas
    Reviewed-by: Lorenzo Pieralisi
    Acked-by: Yinghai Lu
    CC: stable@vger.kernel.org # v4.1+

    Bjorn Helgaas
     

30 May, 2015

1 commit

  • David Ahern reported that d63e2e1f3df9 ("sparc/PCI: Clip bridge windows
    to fit in upstream windows") fails to boot on sparc/T5-8:

    pci 0000:06:00.0: reg 0x184: can't handle BAR above 4GB (bus address 0x110204000)

    The problem is that sparc64 assumed that dma_addr_t only needed to hold DMA
    addresses, i.e., bus addresses returned via the DMA API (dma_map_single(),
    etc.), while the PCI core assumed dma_addr_t could hold *any* bus address,
    including raw BAR values. On sparc64, all DMA addresses fit in 32 bits, so
    dma_addr_t is a 32-bit type. However, BAR values can be 64 bits wide, so
    they don't fit in a dma_addr_t. d63e2e1f3df9 added new checking that
    tripped over this mismatch.

    Add pci_bus_addr_t, which is wide enough to hold any PCI bus address,
    including both raw BAR values and DMA addresses. This will be 64 bits
    on 64-bit platforms and on platforms with a 64-bit dma_addr_t. Then
    dma_addr_t only needs to be wide enough to hold addresses from the DMA API.

    [bhelgaas: changelog, bugzilla, Kconfig to ensure pci_bus_addr_t is at
    least as wide as dma_addr_t, documentation]
    Fixes: d63e2e1f3df9 ("sparc/PCI: Clip bridge windows to fit in upstream windows")
    Fixes: 23b13bc76f35 ("PCI: Fail safely if we can't handle BARs larger than 4GB")
    Link: http://lkml.kernel.org/r/CAE9FiQU1gJY1LYrxs+ma5LCTEEe4xmtjRG0aXJ9K_Tsu+m9Wuw@mail.gmail.com
    Link: http://lkml.kernel.org/r/1427857069-6789-1-git-send-email-yinghai@kernel.org
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=96231
    Reported-by: David Ahern
    Tested-by: David Ahern
    Signed-off-by: Yinghai Lu
    Signed-off-by: Bjorn Helgaas
    Acked-by: David S. Miller
    CC: stable@vger.kernel.org # v3.19+

    Yinghai Lu
     

05 Feb, 2015

1 commit


17 Jan, 2015

1 commit

  • Add pci_bus_clip_resource(). If a PCI-PCI bridge window overlaps an
    upstream bridge window but is not completely contained by it, this clips
    the downstream window so it fits inside the upstream one.

    No functional change (this adds the function but no callers).

    [bhelgaas: changelog, split into separate patch]
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
    Reported-by: Marek Kordik
    Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
    Signed-off-by: Yinghai Lu
    Signed-off-by: Bjorn Helgaas
    CC: stable@vger.kernel.org # v3.16+

    Yinghai Lu
     

11 Jun, 2014

1 commit


30 May, 2014

1 commit

  • pci_bus_add_device() always returns 0, so there's no point in returning
    anything at all. Make it a void function and remove the tests of the
    return value from the callers.

    [bhelgaas: changelog, remove unused "err" from i82875p_setup_overfl_dev()]
    Signed-off-by: Yijing Wang
    Signed-off-by: Bjorn Helgaas

    Yijing Wang
     

15 Apr, 2014

1 commit


20 Mar, 2014

3 commits

  • The pci_bus_alloc_resource() "type_mask" parameter is used to compare with
    the "flags" member of a struct resource, so it should be the same type,
    namely "unsigned long".

    No functional change because all current IORESOURCE_* flags fit in 32 bits.

    Signed-off-by: Bjorn Helgaas

    Bjorn Helgaas
     
  • When allocating space from a bus resource, i.e., from apertures leading to
    this bus, make sure the entire resource type matches. The previous code
    assumed the IORESOURCE_TYPE_BITS field was a bitmask with only a single bit
    set, but this is not true. IORESOURCE_TYPE_BITS is really an enumeration,
    and we have to check all the bits.

    See 72dcb1197228 ("resources: Add register address resource type").

    No functional change. If we used this path for allocating IRQs, DMA
    channels, or bus numbers, this would fix a bug because those types are
    indistinguishable when masked by IORESOURCE_IO | IORESOURCE_MEM. But we
    don't, so this shouldn't make any difference.

    Signed-off-by: Bjorn Helgaas

    Bjorn Helgaas
     
  • 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

    Bjorn Helgaas
     

11 Jan, 2014

1 commit

  • * 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

    Bjorn Helgaas
     

08 Jan, 2014

3 commits

  • 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

    Yinghai Lu
     
  • 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

    Yinghai Lu
     
  • 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

    Bjorn Helgaas
     

19 Dec, 2013

1 commit

  • 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

    Yinghai Lu
     

26 Jul, 2013

1 commit

  • 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

    Yinghai Lu
     

28 May, 2013

1 commit


08 May, 2013

1 commit

  • 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+

    Yinghai Lu
     

18 Apr, 2013

2 commits

  • * pci/cleanup:
    PCI: Remove "extern" from function declarations
    PCI: Warn about failures instead of "must_check" functions
    PCI: Remove __must_check from definitions
    PCI: Remove unused variables
    PCI: Move cpci_hotplug_init() proto to header file
    PCI: Make local functions/structs static
    PCI: Fix missing prototype for pcie_port_acpi_setup()

    Conflicts:
    drivers/pci/hotplug/acpiphp.h
    include/linux/pci.h

    Bjorn Helgaas
     
  • These places capture return values to avoid "must_check" warnings,
    but we didn't *do* anything with the return values, which causes
    "set but not used" warnings. We might as well do something instead
    of just trying to evade the "must_check" warnings.

    Signed-off-by: Bjorn Helgaas

    Bjorn Helgaas