aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pci/probe.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2014-12-10Merge tag 'pci-v3.19-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds1-45/+35
Pull PCI changes from Bjorn Helgaas: "Here are the PCI changes intended for v3.19. I don't think there's anything very exciting here, but there was a lot of MSI-related stuff coming via Thomas. Details: NUMA - Allow numa_node override via sysfs (Prarit Bhargava) Resource management - Restore detection of read-only BARs (Myron Stowe) - Shrink decoding-disabled window while sizing BARs (Myron Stowe) - Add informational printk for invalid BARs (Myron Stowe) - Remove fixed parameter in pci_iov_resource_bar() (Myron Stowe) MSI - Add pci_msi_ignore_mask to prevent writes to MSI/MSI-X Mask Bits (Yijing Wang) - Revert "PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq()" (Yijing Wang) - s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq() (Yijing Wang) Virtualization - xen: Process failure for pcifront_(re)scan_root() (Chen Gang) - Make FLR and AF FLR reset warning messages different (Gavin Shan) Generic host bridge driver - Allocate config space windows after limiting bus number range (Lorenzo Pieralisi) - Convert to DT resource parsing API (Lorenzo Pieralisi) Freescale Layerscape - Add Freescale Layerscape PCIe driver (Minghuan Lian) NVIDIA Tegra - Do not build on 64-bit ARM (Thierry Reding) - Add Kconfig help text (Thierry Reding) Renesas R-Car - Make rcar_pci static (Jingoo Han) Samsung Exynos - Add exynos prefix to add_pcie_port(), pcie_init() (Jingoo Han) ST Microelectronics SPEAr13xx - Add spear prefix to add_pcie_port(), pcie_init() (Jingoo Han) - Make spear13xx_add_pcie_port() __init (Jingoo Han) - Remove unnecessary OOM message (Jingoo Han) TI DRA7xx - Add dra7xx prefix to add_pcie_port() (Jingoo Han) - Make dra7xx_add_pcie_port() __init (Jingoo Han) TI Keystone - Make ks_dw_pcie_msi_domain_ops static (Jingoo Han) - Remove unnecessary OOM message (Jingoo Han) Miscellaneous - Delete unnecessary NULL pointer checks (Markus Elfring) - Remove unused to_hotplug_slot() (Gavin Shan) - Whitespace cleanup (Jingoo Han) - Simplify if-return sequences (Quentin Lambert)" * tag 'pci-v3.19-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (28 commits) PCI: Remove fixed parameter in pci_iov_resource_bar() PCI: Add informational printk for invalid BARs PCI: tegra: Add Kconfig help text PCI: tegra: Do not build on 64-bit ARM PCI: spear: Remove unnecessary OOM message PCI: mvebu: Add a blank line after declarations PCI: designware: Add a blank line after declarations PCI: exynos: Remove unnecessary return statement PCI: imx6: Use tabs for indentation PCI: keystone: Remove unnecessary OOM message PCI: Remove unused and broken to_hotplug_slot() PCI: Make FLR and AF FLR reset warning messages different PCI: dra7xx: Add __init annotation to dra7xx_add_pcie_port() PCI: spear: Add __init annotation to spear13xx_add_pcie_port() PCI: spear: Rename add_pcie_port(), pcie_init() to spear13xx_add_pcie_port(), etc. PCI: dra7xx: Rename add_pcie_port() to dra7xx_add_pcie_port() PCI: layerscape: Add Freescale Layerscape PCIe driver PCI: Simplify if-return sequences PCI: Delete unnecessary NULL pointer checks PCI: Shrink decoding-disabled window while sizing BARs ...
2014-11-19Merge branches 'pci/enumeration', 'pci/hotplug', 'pci/misc', 'pci/numa' and 'pci/virtualization' into nextBjorn Helgaas1-45/+35
* pci/enumeration: PCI: Remove fixed parameter in pci_iov_resource_bar() PCI: Add informational printk for invalid BARs PCI: Shrink decoding-disabled window while sizing BARs PCI: Restore detection of read-only BARs * pci/hotplug: PCI: Remove unused and broken to_hotplug_slot() * pci/misc: PCI: Make FLR and AF FLR reset warning messages different PCI: Simplify if-return sequences PCI: Delete unnecessary NULL pointer checks * pci/numa: PCI: Allow numa_node override via sysfs * pci/virtualization: xen/pcifront: Process failure for pcifront_(re)scan_root()
2014-11-19PCI: Add informational printk for invalid BARsMyron Stowe1-1/+4
As a consequence of restoring the detection of invalid BARs, add a new informational printk like the following when such occurrences are encountered. pci ssss:bb:dd.f: [Firmware Bug]: reg 0xXX: invalid BAR (can't size) Reported-by: William Unruh <unruh@physics.ubc.ca> Reported-by: Martin Lucina <martin@lucina.net> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Matthew Wilcox <willy@linux.intel.com>
2014-11-19PCI: Support 64-bit bridge windows if we have 64-bit dma_addr_tYinghai Lu1-12/+16
Aaron reported that a 32-bit x86 kernel with Physical Address Extension (PAE) support complains about bridge prefetchable memory windows above 4GB: pci_bus 0000:00: root bus resource [mem 0x380000000000-0x383fffffffff] ... pci 0000:03:00.0: reg 0x10: [mem 0x383fffc00000-0x383fffdfffff 64bit pref] pci 0000:03:00.0: reg 0x20: [mem 0x383fffe04000-0x383fffe07fff 64bit pref] pci 0000:03:00.1: reg 0x10: [mem 0x383fffa00000-0x383fffbfffff 64bit pref] pci 0000:03:00.1: reg 0x20: [mem 0x383fffe00000-0x383fffe03fff 64bit pref] pci 0000:00:02.2: PCI bridge to [bus 03-04] pci 0000:00:02.2: bridge window [io 0x1000-0x1fff] pci 0000:00:02.2: bridge window [mem 0x91900000-0x91cfffff] pci 0000:00:02.2: can't handle 64-bit address space for bridge In this kernel, unsigned long is 32 bits and dma_addr_t is 64 bits. Previously we used "unsigned long" to hold the bridge window address. But this is a bus address, so we should use dma_addr_t instead. Use dma_addr_t to hold the bridge window base and limit. The question of whether the CPU can actually *address* the window is separate and depends on what the physical address space of the CPU is and whether the host bridge does any address translation. [bhelgaas: fix "shift count > width of type", changelog, stable tag] Fixes: d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible") Link: https://bugzilla.kernel.org/show_bug.cgi?id=88131 Reported-by: Aaron Ma <mapengyu@gmail.com> Tested-by: Aaron Ma <mapengyu@gmail.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.14+
2014-11-13PCI: Apply _HPX Link Control settings to all devices with a linkYinghai Lu1-1/+1
Previously we applied _HPX type 2 record Link Control register settings only to bridges with a subordinate bus. But it's better to apply them to all devices with a link because if the subordinate bus has not been allocated yet, we won't apply settings to the device. Use pcie_cap_has_lnkctl() to determine whether the device has a Link Control register instead of looking at dev->subordinate. [bhelgaas: changelog] Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration") Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-11-10PCI: Delete unnecessary NULL pointer checksMarkus Elfring1-2/+1
The functions pci_dev_put(), pci_pme_wakeup_bus(), and put_device() return immediately if their argument is NULL. Thus the test before the call is not needed. Remove these unnecessary tests. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-11-10PCI: Shrink decoding-disabled window while sizing BARsMyron Stowe1-46/+31
__pci_read_base() disables decoding while sizing device BARs. We can't print while decoding is disabled, which leads to some rather messy exit logic. Coalesce the sizing logic to minimize the time decoding is disabled. This lets us print errors where they're detected. The refactoring also takes advantage of the symmetry of obtaining the BAR's extent (pci_size) and storing the result as the 'region' for both the 32-bit and 64-bit BARs, consolidating both cases. No functional change intended. [bhelgaas: move pci_size() up, per Thomas Petazzoni, Thierry Reding, Kevin Hilman] Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Matthew Wilcox <willy@linux.intel.com>
2014-11-10PCI: Restore detection of read-only BARsMyron Stowe1-0/+3
Commit 6ac665c63dca ("PCI: rewrite PCI BAR reading code") masked off low-order bits from 'l', but not from 'sz'. Both are passed to pci_size(), which compares 'base == maxbase' to check for read-only BARs. The masking of 'l' means that comparison will never be 'true', so the check for read-only BARs no longer works. Resolve this by also masking off the low-order bits of 'sz' before passing it into pci_size() as 'maxbase'. With this change, pci_size() will once again catch the problems that have been encountered to date: - AGP aperture BAR of AMD-7xx host bridges: if the AGP window is disabled, this BAR is read-only and read as 0x00000008 [1] - BARs 0-4 of ALi IDE controllers can be non-zero and read-only [1] - Intel Sandy Bridge - Thermal Management Controller [8086:0103]; BAR 0 returning 0xfed98004 [2] - Intel Xeon E5 v3/Core i7 Power Control Unit [8086:2fc0]; Bar 0 returning 0x00001a [3] Link: [1] https://git.kernel.org/cgit/linux/kernel/git/tglx/history.git/commit/drivers/pci/probe.c?id=1307ef6621991f1c4bc3cec1b5a4ebd6fd3d66b9 ("PCI: probing read-only BARs" (pre-git)) Link: [2] https://bugzilla.kernel.org/show_bug.cgi?id=43331 Link: [3] https://bugzilla.kernel.org/show_bug.cgi?id=85991 Reported-by: William Unruh <unruh@physics.ubc.ca> Reported-by: Martin Lucina <martin@lucina.net> Signed-off-by: Myron Stowe <myron.stowe@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Matthew Wilcox <willy@linux.intel.com> CC: stable@vger.kernel.org # v2.6.27+
2014-10-09Merge tag 'pci-v3.18-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds1-5/+162
Pull PCI updates from Bjorn Helgaas: "The interesting things here are: - Turn on Config Request Retry Status Software Visibility. This caused hangs last time, but we included a fix this time. - Rework PCI device configuration to use _HPP/_HPX more aggressively - Allow PCI devices to be put into D3cold during system suspend - Add arm64 PCI support - Add APM X-Gene host bridge driver - Add TI Keystone host bridge driver - Add Xilinx AXI host bridge driver More detailed summary: Enumeration - Check Vendor ID only for Config Request Retry Status (Rajat Jain) - Enable Config Request Retry Status when supported (Rajat Jain) - Add generic domain handling (Catalin Marinas) - Generate uppercase hex for modalias interface class (Ricardo Ribalda Delgado) Resource management - Add missing MEM_64 mask in pci_assign_unassigned_bridge_resources() (Yinghai Lu) - Increase IBM ipr SAS Crocodile BARs to at least system page size (Douglas Lehr) PCI device hotplug - Prevent NULL dereference during pciehp probe (Andreas Noever) - Move _HPP & _HPX handling into core (Bjorn Helgaas) - Apply _HPP to PCIe devices as well as PCI (Bjorn Helgaas) - Apply _HPP/_HPX to display devices (Bjorn Helgaas) - Preserve SERR & PARITY settings when applying _HPP/_HPX (Bjorn Helgaas) - Preserve MPS and MRRS settings when applying _HPP/_HPX (Bjorn Helgaas) - Apply _HPP/_HPX to all devices, not just hot-added ones (Bjorn Helgaas) - Fix wait time in pciehp timeout message (Yinghai Lu) - Add more pciehp Slot Control debug output (Yinghai Lu) - Stop disabling pciehp notifications during init (Yinghai Lu) MSI - Remove arch_msi_check_device() (Alexander Gordeev) - Rename pci_msi_check_device() to pci_msi_supported() (Alexander Gordeev) - Move D0 check into pci_msi_check_device() (Alexander Gordeev) - Remove unused kobject from struct msi_desc (Yijing Wang) - Remove "pos" from the struct msi_desc msi_attrib (Yijing Wang) - Add "msi_bus" sysfs MSI/MSI-X control for endpoints (Yijing Wang) - Use __get_cached_msi_msg() instead of get_cached_msi_msg() (Yijing Wang) - Use __read_msi_msg() instead of read_msi_msg() (Yijing Wang) - Use __write_msi_msg() instead of write_msi_msg() (Yijing Wang) Power management - Drop unused runtime PM support code for PCIe ports (Rafael J. Wysocki) - Allow PCI devices to be put into D3cold during system suspend (Rafael J. Wysocki) AER - Add additional AER error strings (Gong Chen) - Make <linux/aer.h> standalone includable (Thierry Reding) Virtualization - Add ACS quirk for Solarflare SFC9120 & SFC9140 (Alex Williamson) - Add ACS quirk for Intel 10G NICs (Alex Williamson) - Add ACS quirk for AMD A88X southbridge (Marti Raudsepp) - Remove unused pci_find_upstream_pcie_bridge(), pci_get_dma_source() (Alex Williamson) - Add device flag helpers (Ethan Zhao) - Assume all Mellanox devices have broken INTx masking (Gavin Shan) Generic host bridge driver - Fix ioport_map() for !CONFIG_GENERIC_IOMAP (Liviu Dudau) - Add pci_register_io_range() and pci_pio_to_address() (Liviu Dudau) - Define PCI_IOBASE as the base of virtual PCI IO space (Liviu Dudau) - Fix the conversion of IO ranges into IO resources (Liviu Dudau) - Add pci_get_new_domain_nr() and of_get_pci_domain_nr() (Liviu Dudau) - Add support for parsing PCI host bridge resources from DT (Liviu Dudau) - Add pci_remap_iospace() to map bus I/O resources (Liviu Dudau) - Add arm64 architectural support for PCI (Liviu Dudau) APM X-Gene - Add APM X-Gene PCIe driver (Tanmay Inamdar) - Add arm64 DT APM X-Gene PCIe device tree nodes (Tanmay Inamdar) Freescale i.MX6 - Probe in module_init(), not fs_initcall() (Lucas Stach) - Delay enabling reference clock for SS until it stabilizes (Tim Harvey) Marvell MVEBU - Fix uninitialized variable in mvebu_get_tgt_attr() (Thomas Petazzoni) NVIDIA Tegra - Make sure the PCIe PLL is really reset (Eric Yuen) - Add error path tegra_msi_teardown_irq() cleanup (Jisheng Zhang) - Fix extended configuration space mapping (Peter Daifuku) - Implement resource hierarchy (Thierry Reding) - Clear CLKREQ# enable on port disable (Thierry Reding) - Add Tegra124 support (Thierry Reding) ST Microelectronics SPEAr13xx - Pass config resource through reg property (Pratyush Anand) Synopsys DesignWare - Use NULL instead of false (Fabio Estevam) - Parse bus-range property from devicetree (Lucas Stach) - Use pci_create_root_bus() instead of pci_scan_root_bus() (Lucas Stach) - Remove pci_assign_unassigned_resources() (Lucas Stach) - Check private_data validity in single place (Lucas Stach) - Setup and clear exactly one MSI at a time (Lucas Stach) - Remove open-coded bitmap operations (Lucas Stach) - Fix configuration base address when using 'reg' (Minghuan Lian) - Fix IO resource end address calculation (Minghuan Lian) - Rename get_msi_data() to get_msi_addr() (Minghuan Lian) - Add get_msi_data() to pcie_host_ops (Minghuan Lian) - Add support for v3.65 hardware (Murali Karicheri) - Fold struct pcie_port_info into struct pcie_port (Pratyush Anand) TI Keystone - Add TI Keystone PCIe driver (Murali Karicheri) - Limit MRSS for all downstream devices (Murali Karicheri) - Assume controller is already in RC mode (Murali Karicheri) - Set device ID based on SoC to support multiple ports (Murali Karicheri) Xilinx AXI - Add Xilinx AXI PCIe driver (Srikanth Thokala) - Fix xilinx_pcie_assign_msi() return value test (Dan Carpenter) Miscellaneous - Clean up whitespace (Quentin Lambert) - Remove assignments from "if" conditions (Quentin Lambert) - Move PCI_VENDOR_ID_VMWARE to pci_ids.h (Francesco Ruggeri) - x86: Mark DMI tables as initialization data (Mathias Krause) - x86: Move __init annotation to the correct place (Mathias Krause) - x86: Mark constants of pci_mmcfg_nvidia_mcp55() as __initconst (Mathias Krause) - x86: Constify pci_mmcfg_probes[] array (Mathias Krause) - x86: Mark PCI BIOS initialization code as such (Mathias Krause) - Parenthesize PCI_DEVID and PCI_VPD_LRDT_ID parameters (Megan Kamiya) - Remove unnecessary variable in pci_add_dynid() (Tobias Klauser)" * tag 'pci-v3.18-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (109 commits) arm64: dts: Add APM X-Gene PCIe device tree nodes PCI: Add ACS quirk for AMD A88X southbridge devices PCI: xgene: Add APM X-Gene PCIe driver PCI: designware: Remove open-coded bitmap operations PCI/MSI: Remove unnecessary temporary variable PCI/MSI: Use __write_msi_msg() instead of write_msi_msg() MSI/powerpc: Use __read_msi_msg() instead of read_msi_msg() PCI/MSI: Use __get_cached_msi_msg() instead of get_cached_msi_msg() PCI/MSI: Add "msi_bus" sysfs MSI/MSI-X control for endpoints PCI/MSI: Remove "pos" from the struct msi_desc msi_attrib PCI/MSI: Remove unused kobject from struct msi_desc PCI/MSI: Rename pci_msi_check_device() to pci_msi_supported() PCI/MSI: Move D0 check into pci_msi_check_device() PCI/MSI: Remove arch_msi_check_device() irqchip: armada-370-xp: Remove arch_msi_check_device() PCI/MSI/PPC: Remove arch_msi_check_device() arm64: Add architectural support for PCI PCI: Add pci_remap_iospace() to map bus I/O resources of/pci: Add support for parsing PCI host bridge resources from DT of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr() ... Conflicts: arch/arm64/boot/dts/apm-storm.dtsi
2014-10-01Merge branch 'pci/host-generic' into nextBjorn Helgaas1-3/+8
* pci/host-generic: arm64: Add architectural support for PCI PCI: Add pci_remap_iospace() to map bus I/O resources of/pci: Add support for parsing PCI host bridge resources from DT of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr() PCI: Add generic domain handling of/pci: Fix the conversion of IO ranges into IO resources of/pci: Move of_pci_range_to_resource() to of/address.c ARM: Define PCI_IOBASE as the base of virtual PCI IO space of/pci: Add pci_register_io_range() and pci_pio_to_address() asm-generic/io.h: Fix ioport_map() for !CONFIG_GENERIC_IOMAP Conflicts: drivers/pci/host/pci-tegra.c
2014-09-30PCI: Add generic domain handlingCatalin Marinas1-3/+8
The handling of PCI domains (or PCI segments in ACPI speak) is usually a straightforward affair but its implementation is currently left to the architectural code, with pci_domain_nr(b) querying the value of the domain associated with bus b. This patch introduces CONFIG_PCI_DOMAINS_GENERIC as an option that can be selected if an architecture wants a simple implementation where the value of the domain associated with a bus is stored in struct pci_bus. The architectures that select CONFIG_PCI_DOMAINS_GENERIC will then have to implement pci_bus_assign_domain_nr() as a way of setting the domain number associated with a root bus. All child buses except the root bus will inherit the domain_nr value from their parent. Signed-off-by: Catalin Marinas <Catalin.Marinas@arm.com> [Renamed pci_set_domain_nr() to pci_bus_assign_domain_nr()] Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Arnd Bergmann <arnd@arndb.de>
2014-09-23Merge branch 'pci/hotplug' into nextBjorn Helgaas1-0/+134
* pci/hotplug: PCI: pciehp: Prevent NULL dereference during probe PCI: pciehp: Reduce PCIe slot_ctrl to 16 bits PCI: Configure *all* devices, not just hot-added ones PCI: Preserve MPS and MRRS when applying _HPX settings PCI: Apply _HPP settings to all hot-added PCI devices PCI: Preserve BIOS PCI_COMMAND_SERR and PCI_COMMAND_PARITY settings PCI: Apply _HPP settings to PCIe devices as well as PCI and PCI-X PCI: Remove unused pci_configure_slot() ACPI / hotplug / PCI: Remove pci_configure_slot() usage PCI: shpchp: Remove pci_configure_slot() usage PCI: pciehp: Remove pci_configure_slot() usage PCI: Add pci_configure_device() during enumeration PCI: Move pci_configure_slot() to drivers/pci/probe.c PCI: Shuffle pci-acpi.c functions to group them logically PCI: Whitespace cleanup in pci-acpi.c PCI: Move pci_get_hp_params() to drivers/pci/pci-acpi.c PCI: pciehp: Configure hot-added display devices PCI: Remove "no hotplug settings from platform" warning
2014-09-19Revert "PCI: Make sure bus number resources stay within their parents bounds"Bjorn Helgaas1-8/+2
This reverts commit 1820ffdccb9b ("PCI: Make sure bus number resources stay within their parents bounds") because it breaks some systems with LSI Logic FC949ES Fibre Channel Adapters, apparently by exposing a defect in those adapters. Dirk tested a Tyan VX50 (B4985) with this device that worked like this prior to 1820ffdccb9b: bus: [bus 00-7f] on node 0 link 1 ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-07]) pci 0000:00:0e.0: PCI bridge to [bus 0a] pci_bus 0000:0a: busn_res: can not insert [bus 0a] under [bus 00-07] (conflicts with (null) [bus 00-07]) pci 0000:0a:00.0: [1000:0646] type 00 class 0x0c0400 (FC adapter) Note that the root bridge [bus 00-07] aperture is wrong; this is a BIOS defect in the PCI0 _CRS method. But prior to 1820ffdccb9b, we didn't enforce that aperture, and the FC adapter worked fine at 0a:00.0. After 1820ffdccb9b, we notice that 00:0e.0's aperture is not contained in the root bridge's aperture, so we reconfigure it so it *is* contained: pci 0000:00:0e.0: bridge configuration invalid ([bus 0a-0a]), reconfiguring pci 0000:00:0e.0: PCI bridge to [bus 06-07] This effectively moves the FC device from 0a:00.0 to 07:00.0, which should be legal. But when we enumerate bus 06, the FC device doesn't respond, so we don't find anything. This is probably a defect in the FC device. Possible fixes (due to Yinghai): 1) Add a quirk to fix the _CRS information based on what amd_bus.c read from the hardware 2) Reset the FC device after we change its bus number 3) Revert 1820ffdccb9b Fix 1 would be relatively easy, but it does sweep the LSI FC issue under the rug. We might want to reconfigure bus numbers in the future for some other reason, e.g., hotplug, and then we could trip over this again. For that reason, I like fix 2, but we don't know whether it actually works, and we don't have a patch for it yet. This revert is fix 3, which also sweeps the LSI FC issue under the rug. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84281 Reported-by: Dirk Gouders <dirk@gouders.net> Tested-by: Dirk Gouders <dirk@gouders.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.15+ CC: Yinghai Lu <yinghai@kernel.org>
2014-09-19Revert "PCI: Don't scan random busses in pci_scan_bridge()"Bjorn Helgaas1-7/+3
This reverts commit fc1b253141b3 ("PCI: Don't scan random busses in pci_scan_bridge()") because it breaks CardBus on some machines. David tested a Dell Latitude D505 that worked like this prior to fc1b253141b3: pci 0000:00:1e.0: PCI bridge to [bus 01] pci 0000:01:01.0: CardBus bridge to [bus 02-05] Note that the 01:01.0 CardBus bridge has a bus number aperture of [bus 02-05], but those buses are all outside the 00:1e.0 PCI bridge bus number aperture, so accesses to buses 02-05 never reach CardBus. This is later patched up by yenta_fixup_parent_bridge(), which changes the subordinate bus number of the 00:1e.0 PCI bridge: pci_bus 0000:01: Raising subordinate bus# of parent bus (#01) from #01 to #05 With fc1b253141b3, pci_scan_bridge() fails immediately when it notices that we can't allocate a valid secondary bus number for the CardBus bridge, and CardBus doesn't work at all: pci 0000:01:01.0: can't allocate child bus 01 from [bus 01] I'd prefer to fix this by integrating the yenta_fixup_parent_bridge() logic into pci_scan_bridge() so we fix the bus number apertures up front. But I don't think we can do that before v3.17, so I'm going to revert this to avoid the problem while we're working on the long-term fix. Link: https://bugzilla.kernel.org/show_bug.cgi?id=83441 Link: http://lkml.kernel.org/r/1409303414-5196-1-git-send-email-david.henningsson@canonical.com Reported-by: David Henningsson <david.henningsson@canonical.com> Tested-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.15+
2014-09-12PCI: Configure *all* devices, not just hot-added onesBjorn Helgaas1-3/+0
There's not really a good way to determine whether firmware has already configured a device with _HPP/_HPX settings. On legacy systems, the BIOS has probably configured everything, but on UEFI systems it is not required to do so. Per the PCI Firmware Specification, rev 3.1, sec 3.5, if PCI_COMMAND_IO or PCI_COMMAND_MEMORY is set, we can assume firmware has set the corresponding BARs and maybe we can assume it has configured the rest of the device. And if a bridge has PCI_COMMAND_PARITY or PCI_COMMAND_SERR set, we can assume firmware has configured the bridge. But we can't tell much about devices without BARs. I think it should be safe to apply _HPP and _HPX settings anyway, even if firmware has already configured the device, so configure everything we find. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Preserve MPS and MRRS when applying _HPX settingsBjorn Helgaas1-0/+10
Linux manages MPS and MRRS settings to keep them consistent across the PCIe fabric. BIOS doesn't participate in this Linux management, so ignore that part of any _HPX settings it supplies. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Apply _HPP settings to all hot-added PCI devicesBjorn Helgaas1-5/+0
We currently apply _HPP settings only to: - non-bridge devices, and - PCI-to-PCI bridges i.e., we do not apply them to PCI-to-ISA bridges and the like. It has been that way since _HPP support was added by 40abb96c51bb ("pciehp: Fix programming hotplug parameters"), but I don't think there's any reason to exclude these other bridges. Apply _HPP settings to hot-added PCI devices of any type. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Preserve BIOS PCI_COMMAND_SERR and PCI_COMMAND_PARITY settingsBjorn Helgaas1-8/+0
Do not clear PCI_COMMAND_SERR or PCI_COMMAND_PARITY based on _HPP. The spec (ACPI rev 5.0, sec 6.2.7) says that when "Enable SERR" is set to 1, we should enable SERR in the command register. It says nothing about *disabling* SERR or PERR; in fact, the example in 6.2.7.1 says we should leave PERR alone unless "Enable PERR" is 1. For hot-added devices, this probably doesn't matter because they power up with these bits cleared. But in addition to hot-plugged devices, the spec allows the platform to use _HPP for "configuration of PCI devices not configured by the BIOS at system boot," and it may make a difference for devices present at boot. This change means that if BIOS enables SERR or PERR on a device, and it supplies _HPP or _HPX with the SERR or PERR bits *cleared*, we will now leave SERR or PERR reporting enabled on that device instead of disabling it as we previously did. See also 40abb96c51bb ("pciehp: Fix programming hotplug parameters"), where this code was first added. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Apply _HPP settings to PCIe devices as well as PCI and PCI-XBjorn Helgaas1-8/+1
The ACPI _HPP method was defined before PCIe existed, so its documentation only mentions PCI. The _HPX Type 0 setting record is essentially identical to _HPP, but the spec (ACPI rev 5.0, sec 6.2.8.1) says it should be applied to PCI, PCI-X, and PCIe devices, with settings being ignored if they are not applicable. Some platforms with both conventional PCI and PCIe devices provide only _HPP (not _HPX), so treat _HPP the same way as an _HPX Type 0 record and apply it to PCIe devices as well as PCI and PCI-X. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Remove unused pci_configure_slot()Bjorn Helgaas1-28/+0
All pci_configure_slot() uses have been removed, so remove the definition as well. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Add pci_configure_device() during enumerationBjorn Helgaas1-0/+25
Some platforms can tell the OS how to configure PCI devices, e.g., how to set cache line size, error reporting enables, etc. ACPI defines _HPP and _HPX methods for this purpose. This configuration was previously done by some of the hotplug drivers using pci_configure_slot(). But not all hotplug drivers did this, and per the spec (ACPI rev 5.0, sec 6.2.7), we can also do it for "devices not configured by the BIOS at system boot." Move this configuration into the PCI core by adding pci_configure_device() and calling it from pci_device_add(), so we do this for all devices as we enumerate them. This is based on pci_configure_slot(), which is used by hotplug drivers. I omitted: - pcie_bus_configure_settings() because it configures MPS and MRRS, which requires global knowledge of the fabric and must be done later, and - configuration of subordinate devices; that will happen when we call pci_device_add() for those devices. Because pci_configure_slot() was only done by hotplug drivers, this initial version of pci_configure_device() only configures hot-added devices, ignoring anything added during boot. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Yinghai Lu <yinghai@kernel.org>
2014-09-12PCI: Move pci_configure_slot() to drivers/pci/probe.cBjorn Helgaas1-0/+150
Move pci_configure_slot() and related functions from drivers/pci/hotplug/pcihp_slot to drivers/pci/probe.c. This is to prepare for doing device configuration during the normal enumeration process instead of just after hot-add. No functional change. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-08PCI: Enable CRS Software Visibility for root port if it is supportedRajat Jain1-0/+13
Per PCIe r3.0, sec 2.3.2, an endpoint may respond to a Configuration Request with a Completion with Configuration Request Retry Status (CRS). This terminates the Configuration Request. When the CRS Software Visibility feature is disabled (as it is by default), a Root Complex must handle a CRS Completion by re-issuing the Configuration Request. This is invisible to software. From the CPU's point of view, an endpoint that always responds with CRS causes a hang because the Root Complex never supplies data to complete the CPU read. When CRS Software Visibility is enabled, a Root Complex that receives a CRS Completion for a read of the Vendor ID must return data of 0x0001. The Vendor ID of 0x0001 indicates to software that the endpoint is not ready. We now have more devices that require CRS Software Visibility. For example, a PLX 8713 NT bridge may respond with CRS until it has been configured via I2C, and the I2C configuration is completely independent of PCI enumeration. Enable CRS Software Visibility if it is supported. This allows a system with such a device to work (though the PCI core times out waiting for it to become ready, and we have to rescan the bus after it is ready). This essentially reverts ad7edfe04908 ("[PCI] Do not enable CRS Software Visibility by default"). The failures that led to ad7edfe04908 should be addressed by 89665a6a7140 ("PCI: Check only the Vendor ID to identify Configuration Request Retry"). [bhelgaas: changelog] Link: http://lkml.kernel.org/r/20071029061532.5d10dfc6@snowcone Link: http://lkml.kernel.org/r/alpine.LFD.0.9999.0712271023090.21557@woody.linux-foundation.org Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-09-08PCI: Check only the Vendor ID to identify Configuration Request RetryRajat Jain1-2/+7
Per PCIe r3.0, sec 2.3.2, if a Root Complex - has Configuration Request Retry Status Software Visibility enabled, - issues a Configuration Read of both bytes of the Vendor ID, and - receives a Completion with Configuration Request Retry Status (CRS), it must complete the request to the host by fabricating data of 0x0001 for the Vendor ID and 0xff for any additional bytes in the request. Linux issues a single config read for the four bytes containing the Vendor ID and the Device ID. Previously we checked all four bytes for 0xffff0001 to identify CRS. However, it is only the Vendor ID that really indicates CRS, because it's sufficient to read only those two bytes. Checking the Device ID verifies spec compliance but doesn't add any information. Some Root Complexes appear to indicate CRS by returning 0x0001 for the Vendor ID along with the actual the Device ID. Previously we interpreted that as a valid Vendor/Device ID pair, although 0x0001 is reserved and cannot be a valid Vendor ID. [bhelgaas: changelog] Link: http://lkml.kernel.org/r/4729FC36.3040000@gmail.com Signed-off-by: Rajat Jain <rajatxjain@gmail.com> Signed-off-by: Rajat Jain <rajatjain@juniper.net> Signed-off-by: Guenter Roeck <groeck@juniper.net> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-06-10PCI: Merge multi-line quoted stringsRyan Desfosses1-17/+12
Merge quoted strings that are broken across lines into a single entity. The compiler merges them anyway, but checkpatch complains about it, and merging them makes it easier to grep for strings. No functional change. [bhelgaas: changelog, do the same for everything under drivers/pci] Signed-off-by: Ryan Desfosses <ryan@desfo.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-06-10PCI: Whitespace cleanupRyan Desfosses1-12/+10
Fix various whitespace errors. No functional change. [bhelgaas: fix other similar problems] Signed-off-by: Ryan Desfosses <ryan@desfo.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-06-10PCI: Move EXPORT_SYMBOL so it immediately follows function/variableRyan Desfosses1-5/+4
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-28Merge branch 'pci/misc' into nextBjorn Helgaas1-1/+38
* pci/misc: PCI: Fix return value from pci_user_{read,write}_config_*() PCI: Turn pcibios_penalize_isa_irq() into a weak function PCI: Test for std config alias when testing extended config space
2014-05-28Merge branches 'pci/hotplug', 'pci/pci_is_bridge' and 'pci/virtualization' into nextBjorn Helgaas1-2/+2
* pci/hotplug: PCI: cpqphp: Fix possible null pointer dereference NVMe: Implement PCIe reset notification callback PCI: Notify driver before and after device reset * pci/pci_is_bridge: pcmcia: Use pci_is_bridge() to simplify code PCI: pciehp: Use pci_is_bridge() to simplify code PCI: acpiphp: Use pci_is_bridge() to simplify code PCI: cpcihp: Use pci_is_bridge() to simplify code PCI: shpchp: Use pci_is_bridge() to simplify code PCI: rpaphp: Use pci_is_bridge() to simplify code sparc/PCI: Use pci_is_bridge() to simplify code powerpc/PCI: Use pci_is_bridge() to simplify code ia64/PCI: Use pci_is_bridge() to simplify code x86/PCI: Use pci_is_bridge() to simplify code PCI: Use pci_is_bridge() to simplify code PCI: Add new pci_is_bridge() interface PCI: Rename pci_is_bridge() to pci_has_subordinate() * pci/virtualization: PCI: Introduce new device binding path using pci_dev.driver_override Conflicts: drivers/pci/pci-sysfs.c
2014-05-28PCI: Introduce new device binding path using pci_dev.driver_overrideAlex Williamson1-0/+1
The driver_override field allows us to specify the driver for a device rather than relying on the driver to provide a positive match of the device. This shortcuts the existing process of looking up the vendor and device ID, adding them to the driver new_id, binding the device, then removing the ID, but it also provides a couple advantages. First, the above existing process allows the driver to bind to any device matching the new_id for the window where it's enabled. This is often not desired, such as the case of trying to bind a single device to a meta driver like pci-stub or vfio-pci. Using driver_override we can do this deterministically using: echo pci-stub > /sys/bus/pci/devices/0000:03:00.0/driver_override echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers_probe Previously we could not invoke drivers_probe after adding a device to new_id for a driver as we get non-deterministic behavior whether the driver we intend or the standard driver will claim the device. Now it becomes a deterministic process, only the driver matching driver_override will probe the device. To return the device to the standard driver, we simply clear the driver_override and reprobe the device: echo > /sys/bus/pci/devices/0000:03:00.0/driver_override echo 0000:03:00.0 > /sys/bus/pci/devices/0000:03:00.0/driver/unbind echo 0000:03:00.0 > /sys/bus/pci/drivers_probe Another advantage to this approach is that we can specify a driver override to force a specific binding or prevent any binding. For instance when an IOMMU group is exposed to userspace through VFIO we require that all devices within that group are owned by VFIO. However, devices can be hot-added into an IOMMU group, in which case we want to prevent the device from binding to any driver (override driver = "none") or perhaps have it automatically bind to vfio-pci. With driver_override it's a simple matter for this field to be set internally when the device is first discovered to prevent driver matches. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Alexander Graf <agraf@suse.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-27PCI: Test for std config alias when testing extended config spaceAlex Williamson1-1/+38
When a PCI-to-PCIe bridge is stacked on a PCIe-to-PCI bridge, we can have PCIe endpoints masked by a conventional PCI bus. This makes the extended config space of the PCIe endpoint inaccessible. The PCIe-to-PCI bridge is supposed to handle any type 1 configuration transactions where the extended config offset bits are non-zero as an Unsupported Request rather than forward it to the secondary interface. As noted here, there are a couple known offenders to this rule. These bridges drop the extended offset bits, resulting in the conventional config space being aliased many times across the extended config space. For Intel NICs, this alias often seems to expose a bogus SR-IOV cap. Stacking bridges may seem like an uncommon scenario, but note that any conventional PCI slot in a modern PC is already the secondary interface of an onboard PCIe-to-PCI bridge. The user need only add a PCI-to-PCIe adapter and PCIe device to encounter this problem. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-27PCI: Use pci_is_bridge() to simplify codeYijing Wang1-2/+1
Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-26Merge branches 'dma-api', 'pci/virtualization', 'pci/msi', 'pci/misc' and 'pci/resource' into nextBjorn Helgaas1-19/+29
* dma-api: iommu/exynos: Remove unnecessary "&" from function pointers DMA-API: Update dma_pool_create ()and dma_pool_alloc() descriptions DMA-API: Fix duplicated word in DMA-API-HOWTO.txt DMA-API: Capitalize "CPU" consistently sh/PCI: Pass GAPSPCI_DMA_BASE CPU & bus address to dma_declare_coherent_memory() DMA-API: Change dma_declare_coherent_memory() CPU address to phys_addr_t DMA-API: Clarify physical/bus address distinction * pci/virtualization: PCI: Mark RTL8110SC INTx masking as broken * pci/msi: PCI/MSI: Remove pci_enable_msi_block() * pci/misc: PCI: Remove pcibios_add_platform_entries() s390/pci: use pdev->dev.groups for attribute creation PCI: Move Open Firmware devspec attribute to PCI common code * pci/resource: PCI: Add resource allocation comments PCI: Simplify __pci_assign_resource() coding style PCI: Change pbus_size_mem() return values to be more conventional PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources PCI: Support BAR sizes up to 8GB resources: Clarify sanity check message PCI: Don't add disabled subtractive decode bus resources PCI: Don't print anything while decoding is disabled PCI: Don't set BAR to zero if dma_addr_t is too small PCI: Don't convert BAR address to resource if dma_addr_t is too small PCI: Reject BAR above 4GB if dma_addr_t is too small PCI: Fail safely if we can't handle BARs larger than 4GB x86/gart: Tidy messages and add bridge device info x86/gart: Replace printk() with pr_info() x86/PCI: Move pcibios_assign_resources() annotation to definition x86/PCI: Mark ATI SBx00 HPET BAR as IORESOURCE_PCI_FIXED x86/PCI: Don't try to move IORESOURCE_PCI_FIXED resources x86/PCI: Fix Broadcom CNB20LE unintended sign extension
2014-05-23PCI: Don't add disabled subtractive decode bus resourcesBjorn Helgaas1-1/+1
For a subtractive decode bridge, we previously added and printed all resources of the primary bus, even if they were not valid. In the example below, the bridge 00:1c.3 has no windows enabled, so there are no valid resources on bus 02. But since 02:00.0 is subtractive decode bridge, we add and print all those invalid resources, which don't really make sense: pci 0000:00:1c.3: PCI bridge to [bus 02-03] pci 0000:02:00.0: PCI bridge to [bus 03] (subtractive decode) pci 0000:02:00.0: bridge window [??? 0x00000000 flags 0x0] (subtractive decode) Add and print the subtractively-decoded resources only if they are valid. There's an example in the dmesg log attached to the bugzilla below (but this patch doesn't fix the bug reported there). Link: https://bugzilla.kernel.org/show_bug.cgi?id=73141 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Don't print anything while decoding is disabledBjorn Helgaas1-4/+6
If the console is a PCI device, and we try to print to it while its decoding is disabled, the system will hang. This particular printk hasn't caused a problem yet, but it could, so this fixes it. See also 0ff9514b579b ("PCI: Don't print anything while decoding is disabled"). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Don't set BAR to zero if dma_addr_t is too smallBjorn Helgaas1-6/+7
If a BAR is above 4GB and our dma_addr_t is too small, don't clear the BAR to zero: that doesn't disable the BAR, and it makes it more likely that the BAR will conflict with things if we turn on the memory enable bit (as we will at "out:" if the device was already enabled at the handoff). We should also print the BAR info and its original size so we can follow the process when we try to assign space to it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Don't convert BAR address to resource if dma_addr_t is too smallBjorn Helgaas1-2/+3
If dma_addr_t is too small to represent the BAR value, pcibios_bus_to_resource() will fail, so just remember the BAR size directly in the resource. The resource is already marked UNSET, so we know the address isn't valid anyway. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Reject BAR above 4GB if dma_addr_t is too smallBjorn Helgaas1-1/+1
We can only handle BARs above 4GB if dma_addr_t (not resource_size_t) is 64 bits wide. If we have a 64-bit resource_size_t and a 32-bit dma_addr_t, we can't deal with BARs above 4GB. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-05-23PCI: Fail safely if we can't handle BARs larger than 4GBBjorn Helgaas1-6/+12
We can only handle BARs larger than 4GB if both dma_addr_t and resource_size_t are 64 bits wide. If dma_addr_t is 32 bits, we can't represent all the bus addresses, and if resource_size_t is 32 bits, we can't represent all the CPU addresses. Previously we cleared res->flags (at "fail:") for resources that were too large. That means we think the BAR doesn't exist at all, which in turn means that we could enable the device even though we can't keep track of where the BAR is and we can't make sure it doesn't overlap something else. This preserves the type flags (MEM/IO) so we can keep from enabling the device. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-04-29PCI: Fix use of uninitialized MPS valueBjorn Helgaas1-1/+1
If "pcie_bus_config == PCIE_BUS_PERFORMANCE", we don't initialize "smpss", so we pass a pointer to garbage into pcie_bus_configure_set(), where we compute "mps" based on the garbage. We then pass the garbage "mps" to pcie_write_mps(), which ignores it in the PCIE_BUS_PERFORMANCE case. Coverity isn't smart enough to deduce that we ignore the garbage (it's a lot to expect from a human, too), so initialize "smpss" to a safe value in all cases. Found by Coverity (CID 146454). Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-04-29PCI: Remove unnecessary __ref annotationsBjorn Helgaas1-4/+4
Some PCI functions used to be marked __devinit. When CONFIG_HOTPLUG was not set, these functions were discarded after boot. A few callers of these __devinit functions were marked __ref to indicate that they could safely call the __devinit functions even though the callers were not __devinit. But CONFIG_HOTPLUG and __devinit are now gone, and the need for the __ref annotations is also gone, so remove them. Relevant historical commits: 54b956b90360 Remove __dev* markings from init.h a8e4b9c101ae PCI: add generic pci_hp_add_bridge() 0ab2b57f8db8 PCI: fix section mismatch warning in pci_scan_child_bus 451124a7cc6c PCI: fix 4x section mismatch warnings Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-03-19Merge branch 'pci/resource' into nextBjorn Helgaas1-4/+13
* pci/resource: (26 commits) Revert "[PATCH] Insert GART region into resource map" PCI: Log IDE resource quirk in dmesg PCI: Change pci_bus_alloc_resource() type_mask to unsigned long PCI: Check all IORESOURCE_TYPE_BITS in pci_bus_alloc_from_region() resources: Set type in __request_region() PCI: Don't check resource_size() in pci_bus_alloc_resource() s390/PCI: Use generic pci_enable_resources() tile PCI RC: Use default pcibios_enable_device() sparc/PCI: Use default pcibios_enable_device() (Leon only) sh/PCI: Use default pcibios_enable_device() microblaze/PCI: Use default pcibios_enable_device() alpha/PCI: Use default pcibios_enable_device() PCI: Add "weak" generic pcibios_enable_device() implementation PCI: Don't enable decoding if BAR hasn't been assigned an address PCI: Mark 64-bit resource as IORESOURCE_UNSET if we only support 32-bit PCI: Don't try to claim IORESOURCE_UNSET resources PCI: Check IORESOURCE_UNSET before updating BAR PCI: Don't clear IORESOURCE_UNSET when updating BAR PCI: Mark resources as IORESOURCE_UNSET if we can't assign them PCI: Remove pci_find_parent_resource() use for allocation ...
2014-03-19PCI: Log IDE resource quirk in dmesgBjorn Helgaas1-4/+12
Make a note in dmesg when we overwrite legacy IDE BAR info. We previously logged something like this: pci 0000:00:1f.1: reg 0x10: [io 0x0000-0x0007] and then silently overwrote the resource. There's an example in the bugzilla below. This doesn't fix the bugzilla; it just makes what's going on more obvious. No functional change; merely adds some dev_info() calls. Link: https://bugzilla.kernel.org/show_bug.cgi?id=48451 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-27PCI: Mark 64-bit resource as IORESOURCE_UNSET if we only support 32-bitBjorn Helgaas1-0/+1
If we don't support 64-bit addresses, i.e., CONFIG_PHYS_ADDR_T_64BIT is not set, we can't deal with BARs above 4GB. In this case we already pretend the BAR contained zero; this patch also sets IORESOURCE_UNSET so we can try to reallocate it later. I don't think this is exactly correct: what we care about here are *bus* addresses, not CPU addresses, so the tests of sizeof(resource_size_t) probably should be on sizeof(dma_addr_t) instead. But this is what's been in -next, so we'll fix that later. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: Don't scan random busses in pci_scan_bridge()Andreas Noever1-3/+7
When assigning a new bus number in pci_scan_bridge we check whether max+1 is free by calling pci_find_bus. If it does already exist then we assume that we are rescanning and that this is the right bus to scan. This is fragile. If max+1 lies outside of bus->busn_res.end then we will rescan some random bus from somewhere else in the hierachy. This patch checks for this case and prints a warning. [bhelgaas: add parent/child bus number info to dev_warn()] Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: Check for child busses which use more bus numbers than allocatedAndreas Noever1-4/+6
pci_scan_child_bus can (potentially) return a bus number higher than the subordinate value of the child bus. Possible reasons are that bus numbers are reserved for SR-IOV or for CardBus (SR-IOV is done without checks and the CardBus checks are sketchy at best). We clamp the returned value to the actual subordinate value and print a warning if too many bus numbers are reserved. [bhelgaas: whitespace] Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-11PCI: Remove pci_fixup_parent_subordinate_busnr()Andreas Noever1-30/+0
The function has no effect. If pcibios_assign_all_busses() is not set then the function does nothing. If it is set then in pci_scan_bridge we are always in the branch where we assign the bus numbers ourselves and the subordinate values of all parent busses will be set to 0xff since that is what they inherited from their parent bus and ultimately from the root bus. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10PCI: Make sure bus number resources stay within their parents boundsAndreas Noever1-2/+8
Right now we use 0xff for busn_res.end when probing and later reduce it to the value that is actually used. This does not work if a parent bridge has already a lower subordinate value. For example during hotplug of a new bridge below an already-configured bridge the following message is printed from pci_bus_insert_busn_res(): pci_bus 0000:06: busn_res: can not insert [bus 06-ff] under [bus 05-9b] (conflicts with (null) [bus 05-9b]) This patch clamps the bus range to that of the parent and also ensures that we do not exceed the parents range when assigning the final subordinate value. We also check that busses configured by the firmware fit into their parents bounds. [bhelgaas: reword dev_warn() and fix printk format warning] Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10PCI: Use request_resource_conflict() instead of insert_ for bus numbersAndreas Noever1-1/+1
If a conflict happens during insert_resource_conflict() and all conflicts fit within the newly inserted resource then they will become children of the new resource. This is almost certainly not what we want for bus numbers. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2014-02-10PCI: Assign CardBus bus number only during the second passAndreas Noever1-1/+1
Right now the CardBus code in pci_scan_bridge() is executed during both passes. Since we always allocate the bus number ourselves it makes sense to put it into the second pass. Signed-off-by: Andreas Noever <andreas.noever@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.