aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2016-12-12PCI: pciehp: Remove loading messageBjorn Helgaas1-5/+4
Remove the "PCI Express Hot Plug Controller Driver" version message. I don't think it contains any useful information. Remove unused #defines and move the author information to a comment. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-12PCI: hotplug: Remove hotplug core messageBjorn Helgaas1-7/+3
Remove the "PCI Hot Plug PCI Core" version message. I don't think it contains any useful information. Remove unused #defines and move the author information to a comment. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-12PCI: Remove service driver load/unload messagesBjorn Helgaas1-3/+0
Remove the "service driver %s loaded" and unloaded messages. All service drivers already log something in their probe functions, where they can log more useful details. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-12PCI/AER: Log AER IRQ when claiming Root PortBjorn Helgaas1-2/+2
Add a log message when we enable AER on a Root Port and the hierarchy below it. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-12PCI/AER: Log errors with PCI device, not PCIe service deviceBjorn Helgaas1-3/+4
All other AER-related log messages use the PCI device, e.g., "pci 0000:00:1c.0", not the PCIe service device, e.g., "aer 0000:00:1c.0:pcie02". Change the probe error messages to match the rest and include a little context. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-12PCI/AER: Remove unused version macrosBjorn Helgaas1-7/+0
Remove the unused DRIVER_VERSION, DRIVER_AUTHOR, and DRIVER_DESC macros. The author information is already included in a comment above. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-12PCI/PME: Log PME IRQ when claiming Root PortBjorn Helgaas1-6/+6
We already log a "Signaling PME" whenever the PME service driver claims a Root Port. In fact, we also log the same message for every device in the hierarchy below the Root Port. Log the "Signaling PME" once (only for the Root Port, since we can trivially find out which devices are below the Root Port), and include the IRQ number in the message to help connect the dots with /proc/interrupts. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-12PCI/PME: Drop unused support for PMEs from Root Complex Event CollectorsBjorn Helgaas1-16/+1
Since we register pcie_pme_driver only for PCI_EXP_TYPE_ROOT_PORT, the PME driver never claims Root Complex Event Collectors. Remove unused code related to Root Complex Event Collectors. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-12-12PCI: Move config space size macros to pci_regs.hWang Sheng-Hui1-3/+0
Move PCI configuration space size macros (PCI_CFG_SPACE_SIZE and PCI_CFG_SPACE_EXP_SIZE) from drivers/pci/pci.h to include/uapi/linux/pci_regs.h so they can be used by more drivers and eliminate duplicate definitions. [bhelgaas: Expand comment to include PCI-X details] Signed-off-by: Wang Sheng-Hui <shhuiw@foxmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-12x86/platform/intel-mid: Constify mid_pci_platform_pmLukas Wunner1-1/+1
This struct never needs to be modified. The size of pci-mid.o ELF sections changes thusly: -.data 56 +.data 0 -.rodata 32 +.rodata 88 Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-08PCI/ASPM: Don't retrain link if ASPM not possibleDavid Daney1-2/+16
Some (defective) PCIe devices are not able to reliably do link retraining. Check to see if ASPM is possible between link partners before configuring common clocking, and doing the resulting link retraining. If ASPM is not possible, there is no reason to risk losing access to a device due to an unnecessary link retraining. Signed-off-by: David Daney <david.daney@cavium.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-08PCI: iproc: Skip check for legacy IRQ on PAXC busesAndy Gospodarek2-2/+12
PAXC and PAXCv2 buses do not support legacy IRQs so there is no reason to even try and map them. Without a change like this, one cannot create VFs on Nitro ports since legacy interrupts are checked as part of the PCI device creation process. Testing on PAXC hardware showed that VFs are properly created with only the change to not set pcie->map_irq, but just to be safe the change in iproc_pcie_setup() will ensure that pdev_fixup_irq() will not panic. Signed-off-by: Andy Gospodarek <gospo@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Ray Jui <ray.jui@broadcom.com>
2016-12-08PCI: pciehp: Leave power indicator on when enabling already-enabled slotAshok Raj1-1/+1
If an error occurs when enabling a slot, pciehp_power_thread() turns off the power indicator. But if the only error is that the slot was already enabled, we should leave the power indicator on. Return success if called to enable an already-enabled slot. This is in the same spirit of the special handling for EEXISTS when pciehp_configure_device() determines the slot devices already exist. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Keith Busch <keith.busch@intel.com>
2016-12-07PCI: pciehp: Prioritize data-link event over presence detectAshok Raj1-9/+12
If Slot Status indicates changes in both Data Link Layer Status and Presence Detect, prioritize the Link status change. When both events are observed, pciehp currently relies on the Slot Status Presence Detect State (PDS) to agree with the Link Status Data Link Layer Active status. The Presence Detect State, however, may be set to 1 through out-of-band presence detect even if the link is down, which creates conflicting events. Since the Link Status accurately reflects the reachability of the downstream bus, the Link Status event should take precedence over a Presence Detect event. Skip checking the PDC status if we handled a link event in the same handler. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Keith Busch <keith.busch@intel.com>
2016-12-07PCI: rcar: Add gen3 fallback compatibility string for pcie-rcarSimon Horman1-0/+1
Add fallback compatibility string for the R-Car Gen 3 family. This is in keeping with the both the existing fallback compatibility string for the R-Car Gen 2 family and the fallback scheme being adopted wherever appropriate for drivers for Renesas SoCs. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: rcar: Use gen2 fallback compatibility lastSimon Horman1-2/+2
Improve readability by listing fallback compatibility strings after the more-specific compatibility strings they provide a fallback for. This does not affect run-time behaviour as it is the order in the DTB that determines which compatibility string is used. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: rcar-gen2: Use gen2 fallback compatibility lastSimon Horman1-1/+1
Improve readability by listing fallback compatibility strings after the more-specific compatibility strings they provide a fallback for. This does not affect run-time behaviour as it is the order in the DTB that determines which compatibility string is used. Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: rockchip: Move the deassert of pm/aclk/pclk after phy_init()Shawn Lin1-20/+20
Move deassert of pm/aclk/pclk after phy_init() as we want to optimize the logic of reset control and reuse rockchip_pcie_init_port() later which should fully follow the cold boot procedure of ROM code. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Brian Norris <briannorris@chromium.org>
2016-12-07PCI: rockchip: Split out rockchip_cfg_atu()Shawn Lin1-49/+55
Split out a new function, rockchip_cfg_atu(), in order to re-configure the ATU when missing these information after wakeup from S3. [bhelgaas: add "dev" temporary, return 0 when known] Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Brian Norris <briannorris@chromium.org>
2016-12-07PCI: rockchip: Clean up bit definitions for PCIE_RC_CONFIG_LCSShawn Lin1-10/+4
PCIE_RC_CONFIG_LCS contains control and status bits specific to the PCIe link. The layout for this register looks the same as the existing PCI_EXP_LNKCTL and PCI_EXP_LNKSTA. So let's reuse them. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: rockchip: Correct the use of FTS maskBrian Norris1-1/+1
We're trying to mask out bits[23:8] while retaining [32:24, 7:0], but we're doing the inverse. That doesn't have too much effect, since we're setting all the [23:8] bits to 1, and the other bits are only relevant for modes we're currently not using. But we should get this right. Fixes: ca1989084054 ("PCI: rockchip: Fix wrong transmitted FTS count") Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Shawn Lin <shawn.lin@rock-chips.com>
2016-12-07PCI: rockchip: Remove the pointer to L1 substate capShawn Lin1-9/+8
Per the errata of TRM, the RC can't support L1 substate, so remove the L1 substate cap as well as operation for PCIE_RC_CONFIG_L1_SUBSTATE_CTRL2. Tested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: rockchip: Specify the link capabilityShawn Lin1-23/+37
rk3399 supports PCIe 2.x link speeds marginally at best, and on some boards, the link won't train at 5 GT/s at all. Rather than sacrifice 500ms waiting for training that will never happen, let's use the helper function, of_pci_get_max_link_speed(), to get the max link speed from DT and specify link capability. Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: rockchip: Fix negotiated lanes calculationShawn Lin1-2/+2
The calculation of negotiated lanes is wrong: it should be shifted by PCIE_CORE_PL_CONF_LANE_SHIFT, but it is shifted by PCIE_CORE_PL_CONF_LANE_MASK instead. Let's fix it. Fixes: e77f847df54c ("PCI: rockchip: Add Rockchip PCIe controller support") Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: rockchip: Add Kconfig COMPILE_TESTShawn Lin1-1/+1
Allow selection of the Rockchip driver for compile testing, even if we aren't building for ARCH_ROCKCHIP. [bhelgaas: changelog] Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: rockchip: Mark RC as common clock architectureShawn Lin1-0/+6
The default value of common clock configuration is zero indicating Rockchip's RC is using asynchronous clock architecture but actually we are using common clock. This will confuse some EP drivers if they need some different settings referring to this value. Set the Common Clock Configuration bit in the Link Control Register. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: rockchip: Provide captured slot power limit and scaleShawn Lin1-0/+40
If vpcie3v3 is available, we could provide these information via RC's configure register to make EP able to know the power limit. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: Explain ARM64 ACPI/MCFG quirk Kconfig and build strategyBjorn Helgaas1-4/+15
Add Makefile comments to explain the Kconfig and build strategy for ARM64 drivers that work around not-quite-ECAM issues. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: spear: Use builtin_platform_driver() to simplify the codeGeliang Tang1-5/+1
Use builtin_platform_driver() helper to simplify the code. Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-07PCI: vmd: Fix suspend handlers defined-but-not-used warningBorislav Petkov1-1/+1
Fix the following warnings: drivers/pci/host/vmd.c:731:12: warning: ‘vmd_suspend’ defined but not used [-Wunused-function] static int vmd_suspend(struct device *dev) ^ drivers/pci/host/vmd.c:739:12: warning: ‘vmd_resume’ defined but not used [-Wunused-function] static int vmd_resume(struct device *dev) ^ Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org> Reviewed-by: Keith Busch <keith.busch@intel.com>
2016-12-07PCI: vmd: Use SRCU as a local RCU to prevent delaying global RCUJon Derrick2-7/+22
SRCU lets synchronize_srcu() depend on VMD-local RCU primitives, preventing long delays from locking up RCU in other systems. VMD performs a synchronize when removing a device, but will hit all IRQ lists if the device uses all VMD vectors. This patch will not help VMD's RCU synchronization, but will isolate the read side delays to the VMD subsystem. Additionally, the use of SRCU in VMD's ISR will keep it isolated from any other RCU waiters in the rest of the system. Tested using concurrent FIO and NVMe resets: [global] rw=read bs=4k direct=1 ioengine=libaio iodepth=32 norandommap timeout=300 runtime=1000000000 [nvme0] cpus_allowed=0-63 numjobs=8 filename=/dev/nvme0n1 [nvme1] cpus_allowed=0-63 numjobs=8 filename=/dev/nvme1n1 while (true) do for i in /sys/class/nvme/nvme*; do echo "Resetting ${i##*/}" echo 1 > $i/reset_controller; sleep 5 done; done Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Keith Busch <keith.busch@intel.com>
2016-12-07PCI: tegra: Enable the driver on 64-bit ARMThierry Reding1-1/+1
The Tegra PCI host controller driver no longer relies on any of the 32-bit ARM glue for PCI, so it can be enabled on 64-bit configurations. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2016-12-07PCI: tegra: Add Tegra210 supportThierry Reding1-8/+34
The PCIe host controller found on Tegra X1 is very similar to its predecessor on Tegra K1. A bug was introduced in the new revision that is worked around by always enabling the performance counter, otherwise accesses to configuration space will block for a number of seconds. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2016-12-07PCI: tegra: Implement PCA enable workaroundThierry Reding1-0/+13
Tegra210's PCIe controller has a bug that requires the PCA (performance counter) feature to be enabled. If this isn't done, accesses to device configuration space will hang the chip for tens of seconds. Implement the workaround. Based on commit 514e19138af2 ("pci: tegra: implement PCA enable workaround") from U-Boot by Stephen Warren <swarren@nvidia.com>. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2016-12-07PCI: tegra: Use new pci_register_host_bridge() interfaceArnd Bergmann1-51/+54
Tegra is one of the remaining platforms that still use the traditional pci_common_init_dev() interface for probing PCI host bridges. This demonstrates how to convert it to the pci_register_host interface I just added in a previous patch. This leads to a more linear probe sequence that can handle errors better because we avoid callbacks into the driver, and it makes the driver architecture independent. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2016-12-07PCI: Export host bridge registration interfaceThierry Reding1-2/+4
Allow PCI host bridge drivers to use the new host bridge interfaces to register their host bridge. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2016-12-07PCI: Allow driver-specific data in host bridgeThierry Reding1-3/+3
Provide a way to allocate driver-specific data along with a PCI host bridge structure. The bridge's ->private field points to this data. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2016-12-07PCI: Add pci_register_host_bridge() interfaceArnd Bergmann1-97/+141
Make the existing pci_host_bridge structure a proper device that is usable by PCI host drivers in a more standard way. In addition to the existing pci_scan_bus(), pci_scan_root_bus(), pci_scan_root_bus_msi(), and pci_create_root_bus() interfaces, this unfortunately means having to add yet another interface doing basically the same thing, and add some extra code in the initial step. However, this time it's more likely to be extensible enough that we won't have to do another one again in the future, and we should be able to reduce code much more as a result. The main idea is to pull the allocation of 'struct pci_host_bridge' out of the registration, and let individual host drivers and architecture code fill the members before calling the registration function. There are a number of things we can do based on this: * Use a single memory allocation for the driver-specific structure and the generic PCI host bridge * consolidate the contents of driver-specific structures by moving them into pci_host_bridge * Add a consistent interface for removing a PCI host bridge again when unloading a host driver module * Replace the architecture specific __weak pcibios_*() functions with callbacks in a pci_host_bridge device * Move common boilerplate code from host drivers into the generic function, based on contents of the structure * Extend pci_host_bridge with additional members when needed without having to add arguments to pci_scan_*(). * Move members of struct pci_bus into pci_host_bridge to avoid having lots of identical copies. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Bjorn Helgaas <helgaas@kernel.org>
2016-12-06PCI: Add MCFG quirks for X-Gene host controllerDuc Dang3-10/+122
PCIe controllers in X-Gene SoCs are not ECAM compliant: software needs to configure additional controller's register to address device at bus:dev:function. Add a quirk to discover controller MMIO register space and configure controller registers to select and address the target secondary device. The quirk will only be applied for X-Gene PCIe MCFG table with OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs). Tested-by: Jon Masters <jcm@redhat.com> Signed-off-by: Duc Dang <dhdang@apm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06PCI: Add MCFG quirks for Cavium ThunderX pass1.x host controllerTomasz Nowicki3-3/+11
ThunderX pass1.x requires to emulate the EA headers for on-chip devices hence it has to use custom pci_thunder_ecam_ops for accessing PCI config space (pci-thunder-ecam.c). Add new entries to MCFG quirk array where it can be applied while probing ACPI based PCI host controller. ThunderX pass1.x is using the same way for accessing off-chip devices (so-called PEM) as silicon pass-2.x so we need to add PEM quirk entries too. Quirk is considered for ThunderX silicon pass1.x only which is identified via MCFG revision 2. ThunderX pass 1.x requires the following accessors: NUMA node 0 PCI segments 0- 3: pci_thunder_ecam_ops (MCFG quirk) NUMA node 0 PCI segments 4- 9: thunder_pem_ecam_ops (MCFG quirk) NUMA node 1 PCI segments 10-13: pci_thunder_ecam_ops (MCFG quirk) NUMA node 1 PCI segments 14-19: thunder_pem_ecam_ops (MCFG quirk) [bhelgaas: change Makefile/ifdefs so quirk doesn't depend on CONFIG_PCI_HOST_THUNDER_ECAM] Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controllerTomasz Nowicki3-2/+47
ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully compliant with ECAM standard. It uses non-standard configuration space accessors (see thunder_pem_ecam_ops) and custom configuration space granulation (see bus_shift = 24). In order to access configuration space and probe PEM as ACPI-based PCI host controller we need to add MCFG quirk infrastructure. This involves: 1. A new thunder_pem_acpi_init() init function to locate PEM-specific register ranges using ACPI. 2. Export PEM thunder_pem_ecam_ops structure so it is visible to MCFG quirk code. 3. New quirk entries for each PEM segment. Each contains platform IDs, mentioned thunder_pem_ecam_ops and CFG resources. Quirk is considered for ThunderX silicon pass2.x only which is identified via MCFG revision 1. ThunderX pass 2.x requires the following accessors: NUMA Node 0 PCI segments 0- 3: pci_generic_ecam_ops (ECAM-compliant) NUMA Node 0 PCI segments 4- 9: thunder_pem_ecam_ops (MCFG quirk) NUMA Node 1 PCI segments 10-13: pci_generic_ecam_ops (ECAM-compliant) NUMA Node 1 PCI segments 14-19: thunder_pem_ecam_ops (MCFG quirk) [bhelgaas: adapt to use acpi_get_rc_resources(), update Makefile/ifdefs so quirk doesn't depend on CONFIG_PCI_HOST_THUNDER_PEM] Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06PCI: thunder-pem: Factor out resource lookupBjorn Helgaas1-23/+27
Pull the register resource lookup out of thunder_pem_init() so we can easily add a corresponding lookup using ACPI. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06PCI: Add MCFG quirks for HiSilicon Hip05/06/07 host controllersDongdong Liu2-1/+102
The PCIe controller in Hip05/Hip06/Hip07 SoCs is not completely ECAM-compliant. It is non-ECAM only for the RC bus config space; for any other bus underneath the root bus it does support ECAM access. Add specific quirks for PCI config space accessors. This involves: 1. New initialization call hisi_pcie_init() to obtain RC base addresses from PNP0C02 at the root of the ACPI namespace (under \_SB). 2. New entry in common quirk array. [bhelgaas: move to pcie-hisi.c and change Makefile/ifdefs so quirk doesn't depend on CONFIG_PCI_HISI] Signed-off-by: Dongdong Liu <liudongdong3@huawei.com> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06PCI: Add MCFG quirks for Qualcomm QDF2432 host controllerChristopher Covington1-0/+12
The Qualcomm Technologies QDF2432 SoC does not support accesses smaller than 32 bits to the PCI configuration space. Register the appropriate quirk. [bhelgaas: add QCOM_ECAM32 macro, ifdef for ACPI and PCI_QUIRKS] Signed-off-by: Christopher Covington <cov@codeaurora.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06PCI/ACPI: Provide acpi_get_rc_resources() for ARM64 platformDongdong Liu2-0/+81
The acpi_get_rc_resources() is used to get the RC register address that can not be described in MCFG. It takes the _HID & segment to look for and outputs the RC address resource. Use PNP0C02 devices to describe such RC address resource. Use _UID to match segment to tell which root bus the PNP0C02 resource belongs to. [bhelgaas: add dev argument, wrap in #ifdef CONFIG_PCI_QUIRKS] Signed-off-by: Dongdong Liu <liudongdong3@huawei.com> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2016-12-06Merge branches 'arm/mediatek', 'arm/smmu', 'x86/amd', 's390', 'core' and 'arm/exynos' into nextJoerg Roedel1-2/+1
2016-12-01Merge tag 'pci-v4.9-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds3-16/+28
Pull PCI fixes from Bjorn Helgaas: "PCI fixes: - Fix Read Completion Boundary setting, which fixes a boot failure on IBM x3850 with Mellanox MT27500 ConnectX-3 - Update some MAINTAINERS entries and email addresses" * tag 'pci-v4.9-fixes-4' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX) PCI: Export pcie_find_root_port PCI: designware-plat: Update author email PCI: designware: Change maintainer to Joao Pinto MAINTAINERS: Add devicetree binding to PCI i.MX6 entry MAINTAINERS: Update Richard Zhu's email address
2016-11-30Merge branch 'for-joerg/arm-smmu/updates' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into arm/smmuJoerg Roedel1-2/+1
2016-11-29PCI: Add comments about ROM BAR updatingBjorn Helgaas2-0/+11
pci_update_resource() updates a hardware BAR so its address matches the kernel's struct resource UNLESS it's a disabled ROM BAR. We only update those when we enable the ROM. It's not obvious from the code why ROM BARs should be handled specially. Apparently there are Matrox devices with defective ROM BARs that read as zero when disabled. That means that if pci_enable_rom() reads the disabled BAR, sets PCI_ROM_ADDRESS_ENABLE (without re-inserting the address), and writes it back, it would enable the ROM at address zero. Add comments and references to explain why we can't make the code look more rational. The code changes are from 755528c860b0 ("Ignore disabled ROM resources at setup") and 8085ce084c0f ("[PATCH] Fix PCI ROM mapping"). Link: https://lkml.org/lkml/2005/8/30/138 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
2016-11-29PCI: Decouple IORESOURCE_ROM_ENABLE and PCI_ROM_ADDRESS_ENABLEBjorn Helgaas1-1/+2
Remove the assumption that IORESOURCE_ROM_ENABLE == PCI_ROM_ADDRESS_ENABLE. PCI_ROM_ADDRESS_ENABLE is the ROM enable bit defined by the PCI spec, so if we're reading or writing a BAR register value, that's what we should use. IORESOURCE_ROM_ENABLE is a corresponding bit in struct resource flags. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.