summaryrefslogtreecommitdiff
path: root/drivers/pci/bus.c
AgeCommit message (Collapse)AuthorFilesLines
2020-07-08PCI: Add device even if driver attach failedRajat Jain1-5/+1
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 <rajatja@google.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: stable@vger.kernel.org # v4.6+
2019-07-24PCI: Unexport pci_bus_get() and pci_bus_put()Kelsey Skunberg1-2/+0
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 <skunberg.kelsey@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-09PCI: Replace dev_printk(KERN_DEBUG) with dev_info(), etcMohan Kumar1-2/+1
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 <mohankumar718@gmail.com> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2019-05-09PCI: Replace printk(KERN_INFO) with pr_info(), etcMohan Kumar1-1/+1
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 <mohankumar718@gmail.com> [bhelgaas: squash in similar changes from second patch in series] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2018-07-31PCI: Fix is_added/is_busmaster race conditionHari Vyas1-3/+3
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 <hari.vyas@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
2018-05-09PCI: remove CONFIG_PCI_BUS_ADDR_T_64BITChristoph Hellwig1-2/+2
This symbol is now always identical to CONFIG_ARCH_DMA_ADDR_T_64BIT, so remove it. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2018-03-19PCI: Tidy commentsBjorn Helgaas1-2/+0
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 <bhelgaas@google.com>
2018-02-01Merge branch 'pci/spdx' into nextBjorn Helgaas1-0/+1
* 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
2018-01-26PCI: Add SPDX GPL-2.0 when no license was specifiedBjorn Helgaas1-0/+1
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 <bhelgaas@google.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-18PCI: Add wrappers for dev_printk()Frederick Lawler1-2/+2
Add PCI-specific dev_printk() wrappers and use them to simplify the code slightly. No functional change intended. Signed-off-by: Frederick Lawler <fred@fredlawl.com> [bhelgaas: squash into one patch] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-11-18PCI: Autosense device removal in pci_bridge_d3_update()Lukas Wunner1-1/+1
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 <mika.westerberg@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-08-01Merge branches 'pci/demodularize-hosts' and 'pci/host-request-windows' into nextBjorn Helgaas1-1/+29
* 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()
2016-06-13PCI: Put PCIe ports into D3 during suspendMika Westerberg1-0/+1
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 <lukas@wunner.de> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-06PCI: Add devm_request_pci_bus_resources()Bjorn Helgaas1-1/+29
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 <arnd@arndb.de>). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-05-02PCI: Do not treat EPROBE_DEFER as device attach failureLukas Wunner1-1/+1
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 <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Alan Stern <stern@rowland.harvard.edu>
2016-05-02PCI: Fix BUG on device attach failureLukas Wunner1-1/+3
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 <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-20Merge tag 'powerpc-4.6-1' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux 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 ...
2016-03-09PCI: Add pcibios_bus_add_device() weak functionWei Yang1-0/+3
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 <weiyang@linux.vnet.ibm.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-02-05PCI: Check device_attach() return value alwaysBjorn Helgaas1-1/+6
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 <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-07PCI: Fix minimum allocation address overwriteChristoph Biedl1-2/+4
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 <linux-kernel.bfrz@manchmal.in-ulm.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.14+
2015-09-23PCI: Clear IORESOURCE_UNSET when clipping a bridge windowBjorn Helgaas1-0/+2
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 <lorenzo.pieralisi@arm.com> Based-on-patch-by: Yinghai Lu <yinghai@kernel.org> Tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Yinghai Lu <yinghai@kernel.org> CC: stable@vger.kernel.org # v4.1+
2015-05-30PCI: Add pci_bus_addr_tYinghai Lu1-5/+5
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 <david.ahern@oracle.com> Tested-by: David Ahern <david.ahern@oracle.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: David S. Miller <davem@davemloft.net> CC: stable@vger.kernel.org # v3.19+
2015-02-05PCI: Use common resource list management code instead of private implementationJiang Liu1-12/+6
Use common resource list management data structure and interfaces instead of private implementation. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-16PCI: Add pci_bus_clip_resource() to clip to fit upstream windowYinghai Lu1-0/+43
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 <kordikmarek@gmail.com> Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.16+
2014-06-10PCI: Move EXPORT_SYMBOL so it immediately follows function/variableRyan Desfosses1-3/+3
Move EXPORT_SYMBOL so it immediately follows the function or variable. No functional change. [bhelgaas: squash similar changes, fix hotplug, probe, rom, search, too] Signed-off-by: Ryan Desfosses <ryan@desfo.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-30PCI: Make pci_bus_add_device() voidYijing Wang1-8/+2
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 <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-04-15PCI: Remove unnecessary includes of <linux/init.h>Paul Gortmaker1-1/+0
None of these files are actually using any __init type directives and hence don't need to include <linux/init.h>. Most are just a left over from __devinit and __cpuinit removal, or simply due to code getting copied from one driver to the next. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-20PCI: Change pci_bus_alloc_resource() type_mask to unsigned longBjorn Helgaas1-2/+2
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 <bhelgaas@google.com>
2014-03-20PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region()Bjorn Helgaas1-1/+1
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 <bhelgaas@google.com>
2014-03-20PCI: Don't check resource_size() in pci_bus_alloc_resource()Bjorn Helgaas1-2/+0
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 <pebolle@tiscali.nl> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-01-11Merge branch 'pci/resource' into nextBjorn Helgaas1-30/+102
* 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
2014-01-08PCI: Allocate 64-bit BARs above 4G when possibleYinghai Lu1-3/+13
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 <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-01-08PCI: Enforce bus address limits in resource allocationYinghai Lu1-28/+83
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 <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-01-08PCI: Split out bridge window override of minimum allocation addressBjorn Helgaas1-4/+11
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 <bhelgaas@google.com>
2013-12-19PCI: Move pci_proc_attach_device() to pci_bus_add_device()Yinghai Lu1-0/+1
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 <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-07-25PCI: Delay enabling bridges until they're neededYinghai Lu1-19/+0
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 <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-05-28PCI: Introduce pci_bus_{get|put}() to manage PCI bus reference countJiang Liu1-0/+15
Introduce helper functions pci_bus_{get|put}() to manage PCI bus reference count. Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2013-05-08PCI: Delay final fixups until resources are assignedYinghai Lu1-0/+1
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 <David.Bulkow@stratus.com> Tested-by: David Bulkow <David.Bulkow@stratus.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.9+
2013-04-17Merge branch 'pci/cleanup' into nextBjorn Helgaas1-0/+3
* 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
2013-04-17PCI: Warn about failures instead of "must_check" functionsBjorn Helgaas1-0/+3
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 <bhelgaas@google.com>
2013-04-13PCI: Clean up usages of pci_bus->is_addedJiang Liu1-9/+2
Now pci_bus->is_added is only used to guard invoking of pcibios_fixup_bus() in pci_scan_child_bus(), so just set it directly after the fixups and remove the other test and set in pci_bus_add_devices(). [bhelgaas: changelog] Signed-off-by: Jiang Liu <jiang.liu@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Yinghai Lu <yinghai@kernel.org>
2013-01-26PCI: Put pci_dev in device tree as early as possibleYinghai Lu1-66/+12
We want to put pci_dev structs in the device tree as soon as possible so for_each_pci_dev() iteration will not miss them, but driver attachment needs to be delayed until after pci_assign_unassigned_resources() to make sure all devices have resources assigned first. This patch moves device registering from pci_bus_add_devices() to pci_device_add(), which happens earlier, leaving driver attachment in pci_bus_add_devices(). It also removes unattached child bus handling in pci_bus_add_devices(). That's not needed because child bus via pci_add_new_bus() is already in parent bus children list. [bhelgaas: changelog] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-26PCI: Skip attaching driver in device_add()Yinghai Lu1-0/+5
We want to add PCI devices to the device tree as early as possible but delay attaching drivers. device_add() adds a device to the device hierarchy and (via device_attach()) attaches a matching driver and calls its .probe() method. We want to separate adding the device to the hierarchy from attaching the driver. This patch does that by adding "match_driver" in struct pci_dev. When false, we return failure from pci_bus_match(), which makes device_attach() believe there's no matching driver. Later, we set "match_driver = true" and call device_attach() again, which now attaches the driver and calls its .probe() method. [bhelgaas: changelog, explicitly init dev->match_driver, fold device_attach() call into pci_bus_add_device()] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-01-08PCI/ACPI: Reserve firmware-allocated resources for hot-added root busesYinghai Lu1-0/+2
Firmware may have assigned PCI BARs for hot-added devices, so reserve those resources before trying to allocate more. [bhelgaas: move empty weak definition here] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-12-07Merge branch 'pci/mjg-pci-roms-from-efi' into nextBjorn Helgaas1-0/+5
* pci/mjg-pci-roms-from-efi: x86: Use PCI setup data PCI: Add support for non-BAR ROMs PCI: Add pcibios_add_device EFI: Stash ROMs if they're not in the PCI BAR
2012-12-06PCI: Add pcibios_add_deviceMatthew Garrett1-0/+5
Platforms may want to provide architecture-specific functionality during PCI enumeration. Add a pcibios_add_device() call that architectures can override to do so. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Seth Forshee <seth.forshee@canonical.com>
2012-11-02PCI/PM: Fix deadlock when unbinding device if parent in D3coldHuang Ying1-3/+0
If a PCI device and its parents are put into D3cold, unbinding the device will trigger deadlock as follow: - driver_unbind - device_release_driver - device_lock(dev) <--- previous lock here - __device_release_driver - pm_runtime_get_sync ... - rpm_resume(dev) - rpm_resume(dev->parent) ... - pci_pm_runtime_resume ... - pci_set_power_state - __pci_start_power_transition - pci_wakeup_bus(dev->parent->subordinate) - pci_walk_bus - device_lock(dev) <--- deadlock here If we do not do device_lock in pci_walk_bus, we can avoid deadlock. Device_lock in pci_walk_bus is introduced in commit: d71374dafbba7ec3f67371d3b7e9f6310a588808, corresponding email thread is: https://lkml.org/lkml/2006/5/26/38. The patch author Zhang Yanmin said device_lock is added to pci_walk_bus because: Some error handling functions call pci_walk_bus. For example, PCIe aer. Here we lock the device, so the driver wouldn't detach from the device, as the cb might call driver's callback function. So I fixed the deadlock as follows: - remove device_lock from pci_walk_bus - add device_lock into callback if callback will call driver's callback I checked pci_walk_bus users one by one, and found only PCIe aer needs device lock. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> CC: stable@vger.kernel.org # v3.6+ CC: Zhang Yanmin <yanmin.zhang@intel.com>
2012-09-19PCI: Use correct type when freeing bus resource listYinghai Lu1-1/+5
Should use struct pci_bus_resource instead of struct pci_host_bridge_window Commit 45ca9e9730 ("PCI: add helpers for building PCI bus resource lists") added pci_free_resource_list() and used it in pci_bus_remove_resources(). Later it was also used for host bridge aperture lists, which was fine until commit 0efd5aab41 ("PCI: add struct pci_host_bridge_window with CPU/bus address offset"). That commit added offset information, so we needed a struct pci_host_bridge_window that was separate from struct pci_bus_resource. Commit 0efd5aab41 should have split the host bridge aperture users of pci_free_resource_list() from the pci_bus_resource user (pci_bus_remove_resources()), but it did not. [bhelgaas: changelog -- 0efd5aab41 was mine, so this is all my fault] Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2012-07-16PCI: fix undefined reference to 'pci_fixup_final_inited'Myron Stowe1-3/+1
My "PCI: Integrate 'pci_fixup_final' quirks into hot-plug paths" patch introduced an undefined reference to 'pci_fixup_final_inited' when CONFIG_PCI_QUIRKS is not enabled (on x86_64): drivers/built-in.o: In function `pci_bus_add_device': (.text+0x4f62): undefined reference to `pci_fixup_final_inited' This patch removes the external reference ending up with a result closer to what we ultimately want when the boot path issues described in the original patch are resolved. References: https://lkml.org/lkml/2012/7/9/542 Original, offending, patch https://lkml.org/lkml/2012/7/12/338 Randy's catch Reported-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net>
2012-07-10PCI: call final fixups hot-added devicesMyron Stowe1-0/+4
Final fixups are currently applied only at boot-time by pci_apply_final_quirks(), which is an fs_initcall(). Hot-added devices don't get these fixups, so they may not be completely initialized. This patch makes us run final fixups for hot-added devices in pci_bus_add_device() just before the new device becomes eligible for driver binding. This patch keeps the fs_initcall() for devices present at boot because we do resource assignment between pci_bus_add_device and the fs_initcall(), and we don't want to break any fixups that depend on that assignment. This is a design issue that may be addressed in the future -- any resource assignment should be done *before* device_add(). [bhelgaas: changelog] Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>