summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)AuthorFilesLines
2021-08-23PCI: Support populating MSI domains of root buses via bridgesBoqun Feng1-1/+5
Currently, at probing time, the MSI domains of root buses are populated if either the information of MSI domain is available from firmware (DT or ACPI), or arch-specific sysdata is used to pass the fwnode of the MSI domain. These two conditions don't cover all, e.g. Hyper-V virtual PCI on ARM64, which doesn't have the MSI information in the firmware and couldn't use arch-specific sysdata because running on an architecture with PCI_DOMAINS_GENERIC=y. To support populating MSI domains of the root buses at the probing when neither of the above condition is true, the ->msi_domain of the corresponding bridge device is used: in pci_host_bridge_msi_domain(), which should return the MSI domain of the root bus, the ->msi_domain of the corresponding bridge is fetched first as a potential value of the MSI domain of the root bus. In order to use the approach to populate MSI domains, the driver needs to dev_set_msi_domain() on the bridge before calling pci_register_host_bridge(), and makes sure GENERIC_MSI_IRQ_DOMAIN=y. Another advantage of this new approach is providing an arch-independent way to populate MSI domains, which allows sharing the driver code as much as possible between architectures. Originally-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210726180657.142727-3-boqun.feng@gmail.com Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-23PCI: Introduce domain_nr in pci_host_bridgeBoqun Feng1-1/+5
Currently we retrieve the PCI domain number of the host bridge from the bus sysdata (or pci_config_window if PCI_DOMAINS_GENERIC=y). Actually we have the information at PCI host bridge probing time, and it makes sense that we store it into pci_host_bridge. One benefit of doing so is the requirement for supporting PCI on Hyper-V for ARM64, because the host bridge of Hyper-V doesn't have pci_config_window, whereas ARM64 is a PCI_DOMAINS_GENERIC=y arch, so we cannot retrieve the PCI domain number from pci_config_window on ARM64 Hyper-V guest. As the preparation for ARM64 Hyper-V PCI support, we introduce the domain_nr in pci_host_bridge and a sentinel value to allow drivers to set domain numbers properly at probing time. Currently CONFIG_PCI_DOMAINS_GENERIC=y archs are only users of this newly-introduced field. Link: https://lore.kernel.org/r/20210726180657.142727-2-boqun.feng@gmail.com Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-21PCI: Make saved capability state private to coreBjorn Helgaas1-2/+21
Interfaces and structs for saving and restoring PCI Capability state were declared in include/linux/pci.h, but aren't needed outside drivers/pci/. Move these to drivers/pci/pci.h: struct pci_cap_saved_data struct pci_cap_saved_state void pci_allocate_cap_save_buffers() void pci_free_cap_save_buffers() int pci_add_cap_save_buffer() int pci_add_ext_cap_save_buffer() struct pci_cap_saved_state *pci_find_saved_cap() struct pci_cap_saved_state *pci_find_saved_ext_cap() Link: https://lore.kernel.org/r/20210802221728.1469304-1-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2021-08-21PCI: Add schedule point in proc_bus_pci_read()Krzysztof Wilczyński1-0/+1
PCI configuration space reads from /proc/bus/pci can often take several milliseconds to complete. Add a schedule point in proc_bus_pci_read() to reduce the maximum latency. A similar change was made for sysfs by 2ce02a864ac1 ("PCI: Add schedule point in pci_read_config()"). Link: https://lore.kernel.org/r/20200824052025.48362-1-benbjiang@tencent.com Link: https://lore.kernel.org/r/20210815150824.96773-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-21PCI/ACS: Enforce pci=noats with Transaction BlockingAlex Williamson2-3/+3
PCIe Address Translation Services (ATS) provides a mechanism for a device to provide an on-device caching translation agent (device IOTLB). We already have a means to disable support for this feature via the pci=noats option. For untrusted and externally facing devices, we not only disable ATS support for the device, but we use Access Control Services (ACS) Transaction Blocking to actively prevent devices from sending TLPs with non-default AT field values. Extend pci=noats to also make use of PCI_ACS_TB so that not only is ATS disabled at the device, but blocked at the downstream ports. This provides a means to further lock-down ATS for cases such as device assignment, where it may not be the hardware configuration of the device that makes it untrusted, but the driver running on the device. Link: https://lore.kernel.org/r/162404966325.2362347.12176138291577486015.stgit@omen Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: Rajat Jain <rajatja@google.com>
2021-08-21PCI: Add ACS quirks for Cavium multi-function devicesGeorge Cherian1-0/+4
Some Cavium endpoints are implemented as multi-function devices without ACS capability, but they actually don't support peer-to-peer transactions. Add ACS quirks to declare DMA isolation for the following devices: - BGX device found on Octeon-TX (8xxx) - CGX device found on Octeon-TX2 (9xxx) - RPM device found on Octeon-TX3 (10xxx) Link: https://lore.kernel.org/r/20210810122425.1115156-1-george.cherian@marvell.com Signed-off-by: George Cherian <george.cherian@marvell.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-21PCI/PTM: Remove error message at bootJakub Kicinski1-3/+1
Since 39850ed51062 ("PCI/PTM: Save/restore Precision Time Measurement Capability for suspend/resume"), devices that have PTM capability but don't enable it see this message on calls to pci_save_state(): no suspend buffer for PTM Drop the message, it's perfectly fine not to use a capability. Fixes: 39850ed51062 ("PCI/PTM: Save/restore Precision Time Measurement Capability for suspend/resume") Link: https://lore.kernel.org/r/20210811185955.3112534-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: David E. Box <david.e.box@linux.intel.com>
2021-08-20PCI/VPD: Add pci_vpd_check_csum()Heiner Kallweit1-0/+23
VPD checksum information and checksum calculation are specified by PCIe r5.0, sec 6.28.2.2. Therefore checksum handling can and should be moved into the PCI VPD core. Add pci_vpd_check_csum() to validate the VPD checksum. [bhelgaas: split to separate patch] Link: https://lore.kernel.org/r/1643bd7a-088e-1028-c9b0-9d112cf48d63@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-20PCI/VPD: Add pci_vpd_find_ro_info_keyword()Heiner Kallweit1-0/+33
All users of pci_vpd_find_info_keyword() are interested in the VPD RO section only. In addition all calls are followed by the same activities to calculate start of tag data area and size of the data area. Add pci_vpd_find_ro_info_keyword() that combines these functionalities. pci_vpd_find_info_keyword() can be phased out once all users are converted. [bhelgaas: split pci_vpd_check_csum() to separate patch] Link: https://lore.kernel.org/r/1643bd7a-088e-1028-c9b0-9d112cf48d63@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-20PCI/VPD: Add pci_vpd_alloc()Heiner Kallweit1-0/+26
Several users of the VPD API use a fixed-size buffer and read the VPD into it for further usage. This requires special handling for the case that the buffer isn't big enough to hold the full VPD data. Also the buffer is often allocated on the stack, which isn't too nice. Add pci_vpd_alloc() to dynamically allocate buffer of the correct size and read VPD into it. Link: https://lore.kernel.org/r/955ff598-0021-8446-f856-0c2c077635d7@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-20Merge tag 'pci-v5.14-fixes-2' of ↵Linus Torvalds2-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci Pull PCI fixes from Bjorn Helgaas: - Add Rahul Tanwar as Intel LGM Gateway PCIe maintainer (Rahul Tanwar) - Add Jim Quinlan et al as Broadcom STB PCIe maintainers (Jim Quinlan) - Increase D3hot-to-D0 delay for AMD Renoir/Cezanne XHCI (Marcin Bachry) - Correct iomem_get_mapping() usage for legacy_mem sysfs (Krzysztof Wilczyński) * tag 'pci-v5.14-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI/sysfs: Use correct variable for the legacy_mem sysfs object PCI: Increase D3 delay for AMD Renoir/Cezanne XHCI MAINTAINERS: Add Jim Quinlan et al as Broadcom STB PCIe maintainers MAINTAINERS: Add Rahul Tanwar as Intel LGM Gateway PCIe maintainer
2021-08-20PCI: keembay: Add support for Intel Keem BaySrikanth Thokala3-0/+489
Add driver for Intel Keem Bay SoC PCIe controller. This controller is based on DesignWare PCIe core. In Root Complex mode, only internal reference clock is possible for Keem Bay A0. For Keem Bay B0, external reference clock can be used and will be the default configuration. Currently, keembay_pcie_of_data structure has one member. It will be expanded later to handle this difference. Endpoint mode link initialization is handled by the boot firmware. Link: https://lore.kernel.org/r/20210805211010.29484-3-srikanth.thokala@intel.com Signed-off-by: Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com> Signed-off-by: Srikanth Thokala <srikanth.thokala@intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
2021-08-20PCI: aardvark: Configure PCIe resources from 'ranges' DT propertyPali Rohár1-1/+194
In commit 6df6ba974a55 ("PCI: aardvark: Remove PCIe outbound window configuration") was removed aardvark PCIe outbound window configuration and commit description said that was recommended solution by HW designers. But that commit completely removed support for configuring PCIe IO resources without removing PCIe IO 'ranges' from DTS files. After that commit PCIe IO space started to be treated as PCIe MEM space and accessing it just caused kernel crash. Moreover implementation of PCIe outbound windows prior that commit was incorrect. It completely ignored offset between CPU address and PCIe bus address and expected that in DTS is CPU address always same as PCIe bus address without doing any checks. Also it completely ignored size of every PCIe resource specified in 'ranges' DTS property and expected that every PCIe resource has size 128 MB (also for PCIe IO range). Again without any check. Apparently none of PCIe resource has in DTS specified size of 128 MB. So it was completely broken and thanks to how aardvark mask works, configuration was completely ignored. This patch reverts back support for PCIe outbound window configuration but implementation is a new without issues mentioned above. PCIe outbound window is required when DTS specify in 'ranges' property non-zero offset between CPU and PCIe address space. To address recommendation by HW designers as specified in commit description of 6df6ba974a55, set default outbound parameters as PCIe MEM access without translation and therefore for this PCIe 'ranges' it is not needed to configure PCIe outbound window. For PCIe IO space is needed to configure aardvark PCIe outbound window. This patch fixes kernel crash when trying to access PCIe IO space. Link: https://lore.kernel.org/r/20210624215546.4015-2-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org # 6df6ba974a55 ("PCI: aardvark: Remove PCIe outbound window configuration")
2021-08-20Merge tag 'soc-fixes-5.14-3' of ↵Linus Torvalds1-4/+4
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "Not much to see here. Half the fixes this time are for Qualcomm dts files, fixing small mistakes on certain machines. The other fixes are: - A 5.13 regression fix for freescale QE interrupt controller\ - A fix for TI OMAP gpt12 timer error handling - A randconfig build regression fix for ixp4xx - Another defconfig fix following the CONFIG_FB dependency rework" * tag 'soc-fixes-5.14-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: soc: fsl: qe: fix static checker warning ARM: ixp4xx: fix building both pci drivers ARM: configs: Update the nhk8815_defconfig bus: ti-sysc: Fix error handling for sysc_check_active_timer() soc: fsl: qe: convert QE interrupt controller to platform_device arm64: dts: qcom: sdm845-oneplus: fix reserved-mem arm64: dts: qcom: msm8994-angler: Disable cont_splash_mem arm64: dts: qcom: sc7280: Fixup cpufreq domain info for cpu7 arm64: dts: qcom: msm8992-bullhead: Fix cont_splash_mem mapping arm64: dts: qcom: msm8992-bullhead: Remove PSCI arm64: dts: qcom: c630: fix correct powerdown pin for WSA881x
2021-08-19PCI/sysfs: Use correct variable for the legacy_mem sysfs objectKrzysztof Wilczyński1-1/+1
Two legacy PCI sysfs objects "legacy_io" and "legacy_mem" were updated to use an unified address space in the commit 636b21b50152 ("PCI: Revoke mappings like devmem"). This allows for revocations to be managed from a single place when drivers want to take over and mmap() a /dev/mem range. Following the update, both of the sysfs objects should leverage the iomem_get_mapping() function to get an appropriate address range, but only the "legacy_io" has been correctly updated - the second attribute seems to be using a wrong variable to pass the iomem_get_mapping() function to. Thus, correct the variable name used so that the "legacy_mem" sysfs object would also correctly call the iomem_get_mapping() function. Fixes: 636b21b50152 ("PCI: Revoke mappings like devmem") Link: https://lore.kernel.org/r/20210812132144.791268-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2021-08-19PCI: Increase D3 delay for AMD Renoir/Cezanne XHCIMarcin Bachry1-0/+1
The Renoir XHCI controller apparently doesn't resume reliably with the standard D3hot-to-D0 delay. Increase it to 20ms. [Alex: I talked to the AMD USB hardware team and the AMD Windows team and they are not aware of any HW errata or specific issues. The HW works fine in Windows. I was told Windows uses a rather generous default delay of 100ms for PCI state transitions.] Link: https://lore.kernel.org/r/20210722025858.220064-1-alexander.deucher@amd.com Signed-off-by: Marcin Bachry <hegel666@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Prike Liang <prike.liang@amd.com> Cc: Shyam Sundar S K <shyam-sundar.s-k@amd.com>
2021-08-19PCI: j721e: Add PCIe support for AM64Kishon Vijay Abraham I1-0/+19
AM64 has the same PCIe IP as in J7200 with certain erratas not applicable (quirk_detect_quiet_flag). Add support for "ti,am64-pcie-host" compatible and "ti,am64-pcie-ep" compatible that is specific to AM64. Link: https://lore.kernel.org/r/20210811123336.31357-5-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19PCI: j721e: Add PCIe support for J7200Kishon Vijay Abraham I1-4/+36
J7200 has the same PCIe IP as in J721E with minor changes in the wrapper. J7200 allows byte access of bridge configuration space registers and the register field for LINK_DOWN interrupt is different. J7200 also requires "quirk_detect_quiet_flag" to be set. Configure these changes as part of driver data applicable only to J7200. Link: https://lore.kernel.org/r/20210811123336.31357-4-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19PCI: cadence: Add quirk flag to set minimum delay in LTSSM Detect.Quiet stateNadeem Athani4-0/+38
PCIe fails to link up if SERDES lanes not used by PCIe are assigned to another protocol. For example, link training fails if lanes 2 and 3 are assigned to another protocol while lanes 0 and 1 are used for PCIe to form a two lane link. This failure is due to an incorrect tie-off on an internal status signal indicating electrical idle. Status signals going from SERDES to PCIe Controller are tied-off when a lane is not assigned to PCIe. Signal indicating electrical idle is incorrectly tied-off to a state that indicates non-idle. As a result, PCIe sees unused lanes to be out of electrical idle and this causes LTSSM to exit Detect.Quiet state without waiting for 12ms timeout to occur. If a receiver is not detected on the first receiver detection attempt in Detect.Active state, LTSSM goes back to Detect.Quiet and again moves forward to Detect.Active state without waiting for 12ms as required by PCIe base specification. Since wait time in Detect.Quiet is skipped, multiple receiver detect operations are performed back-to-back without allowing time for capacitance on the transmit lines to discharge. This causes subsequent receiver detection to always fail even if a receiver gets connected eventually. Add a quirk flag "quirk_detect_quiet_flag" to program the minimum time the LTSSM should wait on entering Detect.Quiet state here. This has to be set for J7200 as it has an incorrect tie-off on unused lanes. Link: https://lore.kernel.org/r/20210811123336.31357-3-kishon@ti.com Signed-off-by: Nadeem Athani <nadeem@cadence.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19PCI: cadence: Use bitfield for *quirk_retrain_flag* instead of boolKishon Vijay Abraham I2-2/+2
No functional change. As we are intending to add additional 1-bit members in struct j721e_pcie_data/struct cdns_pcie_rc, use bitfields instead of bool since it takes less space. As discussed in [1], the preference is to use bitfileds instead of bool inside structures. [1] -> https://lore.kernel.org/linux-fsdevel/CA+55aFzKQ6Pj18TB8p4Yr0M4t+S+BsiHH=BJNmn=76-NcjTj-g@mail.gmail.com/ Suggested-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20210811123336.31357-2-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19PCI: cadence: Add support to configure virtual functionsKishon Vijay Abraham I2-21/+128
Now that support for SR-IOV is added in PCIe endpoint core, add support to configure virtual functions in the Cadence PCIe EP driver. Link: https://lore.kernel.org/r/20210819123343.1951-7-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19PCI: cadence: Simplify code to get register base address for configuring BARKishon Vijay Abraham I2-14/+7
No functional change. Simplify code to get register base address for configuring PCI BAR. Link: https://lore.kernel.org/r/20210819123343.1951-6-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19PCI: endpoint: Add virtual function number in pci_epc opsKishon Vijay Abraham I8-163/+297
Add virtual function number in pci_epc ops. EPC controller driver can perform virtual function specific initialization based on the virtual function number. Link: https://lore.kernel.org/r/20210819123343.1951-5-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19PCI: endpoint: Add support to link a physical function to a virtual functionKishon Vijay Abraham I1-0/+24
While the physical function has to be linked to endpoint controller, the virtual function has to be linked to a physical function. Add support to link a physical function to a virtual function in pci-ep-cfs. Link: https://lore.kernel.org/r/20210819123343.1951-4-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19PCI: endpoint: Add support to add virtual function in endpoint coreKishon Vijay Abraham I2-2/+98
Add support to add virtual function in endpoint core. The virtual function can only be associated with a physical function instead of a endpoint controller. Provide APIs to associate a virtual function with a physical function here. [weiyongjun1@huawei.com: PCI: endpoint: Fix missing unlock on error in pci_epf_add_vepf() - Reported-by: Hulk Robot <hulkci@huawei.com>] Link: https://lore.kernel.org/r/20210819123343.1951-3-kishon@ti.com Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2021-08-19PCI: Change the type of probe argument in reset functionsAmey Narkhede8-44/+44
Change the type of probe argument in functions which implement reset methods from int to bool to make the context and intent clear. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-10-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-19PCI: Add support for ACPI _RST reset methodShanker Donthineni3-0/+30
_RST is a standard ACPI method that performs a function level reset of a device (ACPI v6.3, sec 7.3.25). Add pci_dev_acpi_reset() to probe for _RST method and execute if present. The default priority of this reset is set to below device-specific and above hardware resets. Suggested-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-9-ameynarkhede03@gmail.com Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Sinan Kaya <okaya@kernel.org> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2021-08-19PCI: Setup ACPI fwnode early and at the same time with OFShanker Donthineni2-25/+16
Previously, the ACPI_COMPANION() of a pci_dev was usually set by acpi_bind_one() in this path: pci_device_add pci_configure_device pci_init_capabilities device_add device_platform_notify acpi_platform_notify acpi_device_notify # KOBJ_ADD acpi_bind_one ACPI_COMPANION_SET However, things like pci_configure_device() and pci_init_capabilities() that run before device_add() need the ACPI_COMPANION, e.g., acpi_pci_bridge_d3() uses a _DSD method to learn about D3 support. These places had special-case code to manually look up the ACPI_COMPANION. Set the ACPI_COMPANION earlier, in pci_setup_device(), so it will be available while configuring the device. This covers both paths to creating pci_dev objects: pci_scan_single_device # for normal non-SR-IOV devices pci_scan_device pci_setup_device pci_set_acpi_fwnode pci_device_add pci_iov_add_virtfn # for SR-IOV virtual functions pci_setup_device pci_set_acpi_fwnode Also move the OF fwnode setup to the same spot. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20210817180500.1253-8-ameynarkhede03@gmail.com Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2021-08-19PCI: Use acpi_pci_power_manageable()Shanker Donthineni1-8/+10
Use acpi_pci_power_manageable() instead of duplicating the logic in acpi_pci_bridge_d3(). No functional change intended. [bhelgaas: split out from https://lore.kernel.org/r/20210817180500.1253-8-ameynarkhede03@gmail.com] Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-19PCI: Add pci_set_acpi_fwnode() to set ACPI_COMPANIONShanker Donthineni2-4/+10
Move the existing logic from acpi_pci_bridge_d3() to a separate function pci_set_acpi_fwnode() to set the ACPI fwnode. No functional change intended. Link: https://lore.kernel.org/r/20210817180500.1253-7-ameynarkhede03@gmail.com Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
2021-08-19PCI: Allow userspace to query and set device reset mechanismAmey Narkhede3-0/+125
Add "reset_method" sysfs attribute to enable user to query and set preferred device reset methods and their ordering. [bhelgaas: on invalid sysfs input, return error and preserve previous config, as in earlier patch versions] Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-6-ameynarkhede03@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-18PCI: Remove reset_fn field from pci_devAmey Narkhede5-7/+5
"reset_fn" indicates whether the device supports any reset mechanism. Remove the use of reset_fn in favor of the reset_methods array that tracks supported reset mechanisms of a device and their ordering. The octeon driver incorrectly used reset_fn to detect whether the device supports FLR or not. Use pcie_reset_flr() to probe whether it supports FLR. Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-5-ameynarkhede03@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-18PCI: Add array to track reset method orderingAmey Narkhede3-44/+63
Add reset_methods[] in struct pci_dev to keep track of reset mechanisms supported by the device and their ordering. Refactor probing and reset functions to take advantage of calling convention of reset functions. Co-developed-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20210817180500.1253-4-ameynarkhede03@gmail.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-17PCI: Add pcie_reset_flr() with 'probe' argumentAmey Narkhede3-39/+38
Most reset methods are of the form "pci_*_reset(dev, probe)". pcie_flr() was an exception because it relied on a separate pcie_has_flr() function instead of taking a "probe" argument. Add "pcie_reset_flr(dev, probe)" to follow the convention. Remove pcie_has_flr(). Some pcie_flr() callers that did not use pcie_has_flr() remain. [bhelgaas: commit log, rework pcie_reset_flr() to use dev->devcap directly] Link: https://lore.kernel.org/r/20210817180500.1253-3-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-17PCI: Cache PCIe Device Capabilities registerAmey Narkhede2-6/+5
Add a new member called devcap in struct pci_dev for caching the PCIe Device Capabilities register to avoid reading PCI_EXP_DEVCAP multiple times. Refactor pcie_has_flr() to use cached device capabilities. Link: https://lore.kernel.org/r/20210817180500.1253-2-ameynarkhede03@gmail.com Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
2021-08-16PCI: rcar: Add L1 link state fix into data abort hookMarek Vasut2-0/+93
When the link is in L1, hardware should return it to L0 automatically whenever a transaction targets a component on the other end of the link (PCIe r5.0, sec 5.2). The R-Car PCIe controller doesn't handle this transition correctly. If the link is not in L0, an MMIO transaction targeting a downstream device fails, and the controller reports an ARM imprecise external abort. Work around this by hooking the abort handler so the driver can detect this situation and help the hardware complete the link state transition. When the R-Car controller receives a PM_ENTER_L1 DLLP from the downstream component, it sets PMEL1RX bit in PMSR register, but then the controller enters some sort of in-between state. A subsequent MMIO transaction will fail, resulting in the external abort. The abort handler detects this condition and completes the link state transition by setting the L1IATN bit in PMCTLR and waiting for the link state transition to complete. Link: https://lore.kernel.org/r/20210815181650.132579-1-marek.vasut@gmail.com Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: linux-renesas-soc@vger.kernel.org
2021-08-13PCI: hv: Support for create interrupt v3Sunil Muthuswamy1-5/+62
Hyper-V vPCI protocol version 1_4 adds support for create interrupt v3. Create interrupt v3 essentially makes the size of the vector field bigger in the message, thereby allowing bigger vector values. For example, that will come into play for supporting LPI vectors on ARM, which start at 8192. Link: https://lore.kernel.org/r/MW4PR21MB20026A6EA554A0B9EC696AA8C0159@MW4PR21MB2002.namprd21.prod.outlook.com Signed-off-by: Sunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Reviewed-by: Wei Liu <wei.liu@kernel.org>
2021-08-13PCI: xilinx-nwl: Enable the clock through CCFHyun Kwon1-0/+12
Enable PCIe reference clock. There is no remove function that's why this should be enough for simple operation. Normally this clock is enabled by default by firmware but there are usecases where this clock should be enabled by driver itself. It is also good that PCIe clock is recorded in a clock framework. Link: https://lore.kernel.org/r/ee6997a08fab582b1c6de05f8be184f3fe8d5357.1624618100.git.michal.simek@xilinx.com Fixes: ab597d35ef11 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller") Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com> Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org
2021-08-13ARM: ixp4xx: fix building both pci driversArnd Bergmann1-4/+4
When both the old and the new PCI drivers are enabled in the same kernel, there are a couple of namespace conflicts that cause a build failure: drivers/pci/controller/pci-ixp4xx.c:38: error: "IXP4XX_PCI_CSR" redefined [-Werror] 38 | #define IXP4XX_PCI_CSR 0x1c | In file included from arch/arm/mach-ixp4xx/include/mach/hardware.h:23, from arch/arm/mach-ixp4xx/include/mach/io.h:15, from arch/arm/include/asm/io.h:198, from include/linux/io.h:13, from drivers/pci/controller/pci-ixp4xx.c:20: arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h:221: note: this is the location of the previous definition 221 | #define IXP4XX_PCI_CSR(x) ((volatile u32 *)(IXP4XX_PCI_CFG_BASE_VIRT+(x))) | drivers/pci/controller/pci-ixp4xx.c:148:12: error: 'ixp4xx_pci_read' redeclared as different kind of symbol 148 | static int ixp4xx_pci_read(struct ixp4xx_pci *p, u32 addr, u32 cmd, u32 *data) | ^~~~~~~~~~~~~~~ Rename both the ixp4xx_pci_read/ixp4xx_pci_write functions and the IXP4XX_PCI_CSR macro. In each case, I went with the version that has fewer callers to keep the change small. Fixes: f7821b493458 ("PCI: ixp4xx: Add a new driver for IXP4xx") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: soc@kernel.org Link: https://lore.kernel.org/r/20210721151546.2325937-1-arnd@kernel.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2021-08-12PCI: Fix pci_dev_str_match_path() alloc while atomic bugDan Carpenter1-1/+1
pci_dev_str_match_path() is often called with a spinlock held so the allocation has to be atomic. The call tree is: pci_specified_resource_alignment() <-- takes spin_lock(); pci_dev_str_match() pci_dev_str_match_path() Fixes: 45db33709ccc ("PCI: Allow specifying devices using a base bus and path of devfns") Link: https://lore.kernel.org/r/20210812070004.GC31863@kili Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
2021-08-12PCI/VPD: Treat invalid VPD like missing VPD capabilityHeiner Kallweit1-6/+3
Exporting sysfs files that can't be accessed doesn't make much sense. Therefore, if either a quirk or the dynamic size calculation result in VPD being marked as invalid, treat this as though the device has no VPD capability. One consequence is that the "vpd" sysfs file is not visible. Link: https://lore.kernel.org/r/6a02b204-4ed2-4553-c3b2-eacf9554fa8d@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Determine VPD size in pci_vpd_init()Heiner Kallweit1-23/+19
Determine VPD size in pci_vpd_init(). Quirks set dev->vpd.len to a non-zero value, so they cause us to skip the dynamic size calculation. Prerequisite is that we move the quirks from FINAL to HEADER so they are run before pci_vpd_init(). Link: https://lore.kernel.org/r/cc4a6538-557a-294d-4f94-e6d1d3c91589@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Embed struct pci_vpd in struct pci_devHeiner Kallweit2-50/+14
Now that struct pci_vpd is really small, simplify the code by embedding struct pci_vpd directly in struct pci_dev instead of dynamically allocating it. Link: https://lore.kernel.org/r/d898489e-22ba-71f1-2f31-f1a78dc15849@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Remove struct pci_vpd.valid memberHeiner Kallweit1-17/+12
Instead of having a separate flag, use vp->len != 0 as indicator that VPD validity has been checked. Now vpd->len == PCI_VPD_SZ_INVALID indicates that VPD is invalid. Link: https://lore.kernel.org/r/9f777bc7-5316-e1b8-e5d4-f9f609bdb5dd@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Remove struct pci_vpd_opsHeiner Kallweit1-54/+32
Some multi-function devices share VPD hardware across functions and don't work correctly for concurrent VPD accesses to different functions. Struct pci_vpd_ops was added by 932c435caba8 ("PCI: Add dev_flags bit to access VPD through function 0") so that on these devices, VPD accesses to any function would always go to function 0. It's easier to just check for the PCI_DEV_FLAGS_VPD_REF_F0 quirk bit in the two places we need it than to deal with the struct pci_vpd_ops. Simplify the code by removing struct pci_vpd_ops and removing the indirect calls. [bhelgaas: check for !func0_dev earlier, commit log] Link: https://lore.kernel.org/r/b2532a41-df8b-860f-461f-d5c066c819d0@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-12PCI/VPD: Reorder pci_read_vpd(), pci_write_vpd()Heiner Kallweit1-30/+30
Reorder pci_read_vpd() and pci_write_vpd() to prepare for future patches. No functional change intended. Link: https://lore.kernel.org/r/89f0f5a2-293b-a017-fc67-a36473a792bf@gmail.com Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2021-08-10PCI/MSI: Use new mask/unmask functionsThomas Gleixner1-81/+21
Switch the PCI/MSI core to use the new mask/unmask functions. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210729222543.311207034@linutronix.de
2021-08-10PCI/MSI: Provide a new set of mask and unmask functionsThomas Gleixner1-0/+72
The existing mask/unmask functions are convoluted and generate suboptimal assembly code. Provide a new set of functions which will be used in later patches to replace the exisiting ones. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/875ywetozb.ffs@tglx
2021-08-10PCI/MSI: Cleanup msi_mask()Thomas Gleixner1-14/+11
msi_mask() is calculating the possible mask bits for MSI per vector masking. Rename it to msi_multi_mask() and hand the MSI descriptor pointer into it to simplify the call sites. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210729222543.203905260@linutronix.de
2021-08-10PCI/MSI: Deobfuscate virtual MSI-XThomas Gleixner1-17/+8
Handling of virtual MSI-X is obfuscated by letting pci_msix_desc_addr() return NULL and checking the pointer. Just use msi_desc::msi_attrib.is_virtual at the call sites and get rid of that pointer check. No functional change. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20210729222543.151522318@linutronix.de
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-14 12:04:38 +0300