summaryrefslogtreecommitdiff
path: root/drivers/pci
AgeCommit message (Collapse)Author
2026-06-09PCI: mediatek: Fix operator precedence in PCIE_FTS_NUM_L0 macroLi RongQing
The original PCIE_FTS_NUM_L0(x) macro was buggy due to improper operator precedence, where ((x) & 0xff << 8) was evaluated as ((x) & 0xff00). Instead of just fixing the parentheses, use the standard FIELD_PREP() macro. This makes the code more robust by automatically handling masks and shifts, while also adding compile-time type and range checking to ensure the value fits within PCIE_FTS_NUM_MASK. Fixes: 637cfacae96f ("PCI: mediatek: Add MediaTek PCIe host controller support") Signed-off-by: Li RongQing <lirongqing@baidu.com> [mani: added the bitfield header include spotted by Sashiko] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Link: https://patch.msgid.link/20260515005552.2343-1-lirongqing@baidu.com
2026-06-04PCI: qcom: Initialize DWC MSI lock for firmware-managed ECAM hostsYadu M G
A lockdep warning is observed during boot on a Qcom firmware-managed platform: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. ... Call trace: register_lock_class+0x128/0x4d8 __lock_acquire+0x110/0x1db0 lock_acquire+0x278/0x3d8 _raw_spin_lock_irq+0x6c/0xc0 dw_pcie_irq_domain_alloc+0x48/0x190 irq_domain_alloc_irqs_parent+0x2c/0x48 msi_domain_alloc+0x90/0x160 ... dw_pcie_irq_domain_alloc() takes pp->lock while allocating MSI interrupts. pp->lock is normally initialized by dw_pcie_host_init(), but Qcom firmware-managed hosts use the ECAM init path instead: pci_host_common_ecam_create() pci_ecam_create() qcom_pcie_ecam_host_init() dw_pcie_msi_host_init() dw_pcie_allocate_domains() That path constructs a fresh struct dw_pcie_rp and calls dw_pcie_msi_host_init() directly, without going through dw_pcie_host_init(). As a result, pp->lock was not initialized, which triggers the warning. Initialize pp->lock in qcom_pcie_ecam_host_init() before registering the MSI domains so the firmware-managed ECAM path matches the normal DWC host initialization sequence. Fixes: 7d944c0f1469 ("PCI: qcom: Add support for Qualcomm SA8255p based PCIe Root Complex") Signed-off-by: Yadu M G <yadu.mg@oss.qualcomm.com> [mani: added fixes tag and CCed stable] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Cc: stable@kernel.org Link: https://patch.msgid.link/20260604122418.727274-1-yadu.mg@oss.qualcomm.com
2026-05-28PCI: tegra: Explicitly specify PMC instance to useThierry Reding
Currently the kernel relies on a global variable to reference the PMC context. Use an explicit lookup for the PMC and pass that to the public PMC APIs. Acked-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-05-28PCI: qcom: Disable ASPM L0s for SA8775PShawn Guo
Due to a hardware issue, L0s is not properly supported by the PCIe controller on the SA8775p SoC. If enabled, the L0s to L0 transition triggers below correctable AER errors and may also affect link stability: pcieport 0000:00:00.0: PME: Signaling with IRQ 332 pcieport 0000:00:00.0: AER: enabled with IRQ 332 pcieport 0000:00:00.0: AER: Correctable error message received from 0000:01:00.0 pci 0000:01:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) pci 0000:01:00.0: device [17cb:1103] error status/mask=00001000/0000e000 pci 0000:01:00.0: [12] Timeout pcieport 0000:00:00.0: AER: Multiple Correctable error message received from 0000:01:00.0 pcieport 0000:00:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID) pcieport 0000:00:00.0: device [17cb:0115] error status/mask=00001000/0000e000 pcieport 0000:00:00.0: [12] Timeout Hence, disable L0s for the SA8775p SoC to allow it to properly function by sacrificing a little bit of power saving. Fixes: 58d0d3e032b3 ("PCI: qcom-ep: Add support for SA8775P SOC") Assisted-by: Claude:claude-4-6-sonnet Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com> [mani: commit log, corrected fixes tag] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260419093934.1223027-1-shengchao.guo@oss.qualcomm.com
2026-05-28PCI: Allow ATS to be always on for pre-CXL devicesNicolin Chen
Some NVIDIA GPU/NIC devices, though they don't implement CXL config space, have many CXL-like properties. Call this kind "pre-CXL". Similar to CXL.cache capability, these pre-CXL devices also require the ATS function even when their RIDs are IOMMU bypassed, i.e. keep ATS "always on" v.s. "on demand" when a non-zero PASID line gets enabled in SVA use cases. Introduce pci_dev_specific_ats_required() quirk function to scan a list of IDs for these devices. Then, include it in pci_ats_required(). Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Nirmoy Das <nirmoyd@nvidia.com> Tested-by: Nirmoy Das <nirmoyd@nvidia.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-05-28PCI: Add pci_ats_required() for CXL.cache capable devicesNicolin Chen
Controlled by IOMMU drivers, ATS can be enabled "on demand", when a given PASID on a device is attached to an I/O page table. This is working, even when a device has no translation on its RID (i.e., RID is IOMMU bypassed). However, certain PCIe devices require non-PASID ATS on their RID even when the RID is IOMMU bypassed. Call this "ATS always on" in IOMMU term. For example, CXL spec r4.0 notes in sec 3.2.5.13 Memory Type on CXL.cache: "To source requests on CXL.cache, devices need to get the Host Physical Address (HPA) from the Host by means of an ATS request on CXL.io." In other words, the CXL.cache capability requires ATS; otherwise, it can't access host physical memory. Introduce a new pci_ats_required() helper for the IOMMU driver to scan a PCI device and shift ATS policies between "on demand" and "always on". Add the support for CXL.cache devices first. Pre-CXL devices will be added in quirks.c file. Note that pci_ats_required() validates against pci_ats_supported(), so we ensure that untrusted devices (e.g. external ports) will not be always on. This maintains the existing ATS security policy regarding potential side- channel attacks via ATS. Cc: linux-cxl@vger.kernel.org Suggested-by: Vikram Sethi <vsethi@nvidia.com> Suggested-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Tested-by: Nirmoy Das <nirmoyd@nvidia.com> Acked-by: Nirmoy Das <nirmoyd@nvidia.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Yi Liu <yi.l.liu@intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
2026-05-26PCI: qcom: Program T_POWER_ONKrishna Chaitanya Chundru
Some platforms have incorrect T_POWER_ON value programmed in hardware. Generally these will be corrected by bootloaders, but not all targets support bootloaders to program correct values. That means the LTR_L1.2_THRESHOLD value calculated by aspm.c can be wrong, which can result in improper L1.2 exit behavior. If AER happens to be supported and enabled, the error may be *reported* via AER. Parse the 't-power-on-us' property from each Root Port node and program it as part of host initialization using dw_pcie_program_t_power_on() before link training. This property in added to the dtschema here [1]. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> [mani: reworded comment] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link[1]: https://lore.kernel.org/all/20260205093346.667898-1-krishna.chundru@oss.qualcomm.com/ Link: https://patch.msgid.link/20260428-t_power_on_fux-v5-3-f1ef926a91ff@oss.qualcomm.com
2026-05-26PCI: dwc: Add dw_pcie_program_t_power_on() to program T_POWER_ONKrishna Chaitanya Chundru
The T_POWER_ON indicates the time (in μs) that a Port requires the port on the opposite side of Link to wait in L1.2.Exit after sampling CLKREQ# asserted before actively driving the interface. This value is used by the ASPM driver to compute the LTR_L1.2_THRESHOLD. Currently, some controllers expose T_POWER_ON value of zero in the L1SS capability registers, leading to incorrect LTR_L1.2_THRESHOLD calculations, which can result in improper L1.2 exit behavior and if AER happens to be supported and enabled, the error may be *reported* via AER. Add a helper to override T_POWER_ON value by the DWC controller drivers. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> [mani: changed t_power_on to u32] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://patch.msgid.link/20260428-t_power_on_fux-v5-2-f1ef926a91ff@oss.qualcomm.com
2026-05-26PCI/ASPM: Add pcie_encode_t_power_on() helper to encode L1SS T_POWER_ON fieldsKrishna Chaitanya Chundru
Add pcie_encode_t_power_on() to encode the PCIe L1 PM Substates T_POWER_ON parameter into the T_POWER_ON Scale and T_POWER_ON Value fields. This helper can be used by the controller drivers to change the default/wrong value of T_POWER_ON in L1SS capability register to avoid incorrect calculation of LTR_L1.2_THRESHOLD value. The helper converts a T_POWER_ON time specified in microseconds into the appropriate scale/value encoding defined by PCIe r7.0, sec 7.8.3.2. Values that exceed the maximum encodable range are clamped to the largest representable encoding. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> [mani: changed t_power_on_us to u32, added helper name to subject] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260428-t_power_on_fux-v5-1-f1ef926a91ff@oss.qualcomm.com
2026-05-26PCI: qcom: Handle mixed PERST#/PHY DT configurationQiang Yu
The driver currently supports two PERST# and PHY DT configurations. In one case, PHY and PERST# are described in the RC node. In the other case, they are described in the RP node. A mixed setup is not supported. One common example is PHY on the RP node while PERST# remains on the RC node. In that case the driver goes through the RP parse path, does not find PERST# on RP, and does not report an error because PERST# is optional. Probe can then succeed silently while PERST# is left uncontrolled, and PCIe endpoints fail to work later. This silent probe success makes debugging difficult. Handle this mixed case in the RP parse path by checking whether PERST# is present on RC and, if so, using the RC PERST# GPIO for RP ports while keeping RP parsing for PHY. Emit a warning to indicate mixed DT content so it can be fixed. This keeps mixed systems functional and makes the configuration issue visible instead of failing later at endpoint bring-up. Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> [mani: folded the fix: https://lore.kernel.org/linux-pci/20260526-fix_perst_gpio_handling-v1-1-9170507bb4e9@oss.qualcomm.com] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20260508-mix_perst_phy_dts-v1-1-9eff6ee9b51a@oss.qualcomm.com
2026-05-25Merge tag 'v7.1-rc5' into driver-core-nextDanilo Krummrich
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-23PCI: qcom: Indicate broken L1SS exit during resume from system suspendManivannan Sadhasivam
Qcom PCIe RCs can successfully exit from L1SS during OS runtime. However, during system suspend, the Qcom PCIe RC driver may remove all resource votes and turn off the PHY to maximize power savings. Consequently, when the host is in system suspend with the link in L1SS and the endpoint asserts CLKREQ#, the RC driver must restore the PHY and enable the REFCLK. This recovery process causes the L1SS exit latency time to be exceeded (roughly L10_REFCLK_ON + T_COMMONMODE). If the RC driver were to retain all votes during suspend, L1SS exit would succeed without issue but at the expense of higher power consumption. When the host fails to move the link from L1SS to L0 within the L10_REFCLK_ON + T_COMMONMODE time, the endpoint may treat it as a fatal condition and trigger Link Down (LDn) during resume. This LDn results in a reset that destroys the internal device state. To ensure that the client drivers can properly handle this scenario, let them know about this platform limitation by setting the 'pci_host_bridge::broken_l1ss_resume' flag. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260519-l1ss-fix-v2-3-b2c3a4bdeb15@oss.qualcomm.com
2026-05-23PCI: Indicate context lost if L1SS exit is broken during resume from system ↵Manivannan Sadhasivam
suspend Per PCIe v7.0, sec 5.5.3.3.1, when exiting L1.2 due to an endpoint asserting CLKREQ# signal, the REFCLK must be turned on within the latency advertised in the LTR message. This requirement applies to L1.1 as well. On some platforms like Qcom, these requirements are satisfied during OS runtime, but not while resuming from the system suspend. This happens because the PCIe RC driver may remove all resource votes and turn off the PHY analog circuitry during suspend to maximize power savings while keeping the link in L1SS. Consequently, when the endpoint asserts CLKREQ# to wake up, the RC driver must restore the PHY and enable the REFCLK. When this recovery process exceeds the L1SS exit latency time (roughly L10_REFCLK_ON + T_COMMONMODE), the endpoint may treat it as a fatal condition and trigger Link Down (LDn). This results in a reset that destroys the internal device state. So to indicate this platform limitation to the client drivers, introduce a new flag 'pci_host_bridge::broken_l1ss_resume' and check it in pci_suspend_retains_context(). If the flag is set by the RC driver, the API will return 'false' indicating the client drivers that the device context may not be retained and the drivers must be prepared for context loss. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260519-l1ss-fix-v2-2-b2c3a4bdeb15@oss.qualcomm.com
2026-05-23PCI: Add pci_suspend_retains_context() to check if device state is preserved ↵Manivannan Sadhasivam
during suspend Currently, PCI endpoint drivers (e.g. nvme) use pm_suspend_via_firmware() to check whether device state is preserved during system suspend. If firmware will be invoked at the end of suspend, we don't know whether devices will retain their internal state. But device context might be lost due to platform issues as well. Having those checks in endpoint drivers will not scale and will cause a lot of code duplication. Add pci_suspend_retains_context() as a sole point of truth that the endpoint drivers can rely on to check whether they can expect the device context to be retained or not. If pci_suspend_retains_context() returns 'false', drivers need to prepare for context loss by performing actions such as resetting the device, saving the context, shutting it down etc. If it returns 'true', drivers do not need to perform any special action and can leave the device in active state. Right now, this API only incorporates pm_suspend_via_firmware(), but will be extended in future commits. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260519-l1ss-fix-v2-1-b2c3a4bdeb15@oss.qualcomm.com
2026-05-21Merge tag 'pci-v7.1-fixes-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI fixes from Bjorn Helgaas: - Remove obsolete PCIe maintainer addresses (Florian Eckert, Hans Zhang) - Restore a brcmstb link speed assignment that was inadvertently removed, reducing bcm2712 performance (Florian Fainelli) * tag 'pci-v7.1-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: PCI: brcmstb: Assign pcie->gen from of_pci_get_max_link_speed() MAINTAINERS: Remove Jianjun Wang as PCIe mediatek maintainer MAINTAINERS: Remove Chuanhua Lei as PCIe intel-gw maintainer
2026-05-21PCI: qcom: Add D3cold supportKrishna Chaitanya Chundru
Add support for transitioning PCIe endpoints under host bridge into D3cold by integrating with the DWC core suspend/resume helpers. Implement PME_Turn_Off message generation via ELBI_SYS_CTRL and hook it into the DWC host operations so the controller follows the standard PME_Turn_Off based power-down sequence before entering D3cold. When the device is suspended into D3cold, fully tear down interconnect bandwidth and OPP votes. If D3cold is not entered, retain existing behavior by keeping the required interconnect and OPP votes. Use dw_pcie::skip_pwrctrl_off to avoid powering off devices during suspend to preserve wakeup capability of the devices and also not to power on the devices in the init path. Finally, drop the qcom_pcie::suspended flag and rely on the existing dw_pcie::suspended state, which now drives both the power-management flow and the interconnect/OPP handling. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260429-d3cold-v5-5-89e9735b9df6@oss.qualcomm.com
2026-05-21PCI: dwc: Use common D3cold eligibility helper in suspend pathKrishna Chaitanya Chundru
Previously, the driver skipped putting the link into L2 and device state in D3cold whenever L1 ASPM was enabled, since some devices (e.g. NVMe) expect low resume latency and may not tolerate deeper power states. However, such devices typically remain in D0 and are already covered by the new helper's requirement that all endpoints be in D3hot before the devices under host bridge may enter D3cold. Replace the local L1/L1SS-based check in dw_pcie_suspend_noirq() with the shared pci_host_common_d3cold_possible() helper to decide whether the devices under host bridge can safely transition to D3cold. In addition, propagate PME-from-D3cold capability information from the helper and record it in skip_pwrctrl_off. Some devices (e.g. M.2 cards without auxiliary power) cannot send PME when the main power is removed, even if they advertise PME-from-D3cold support. This allows controller power-off to be skipped when required to preserve wakeup functionality. While at it, update the 'dw_pcie::suspended' flag in dw_pcie_resume_noirq() only after the PCIe link resumes successfully, to avoid marking the controller as active when link resume fails. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> [mani: commit log and added TODO to query Vaux] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260429-d3cold-v5-4-89e9735b9df6@oss.qualcomm.com
2026-05-21PCI: qcom: Power down PHY via PARF_PHY_CTRL before disabling rails/clocksKrishna Chaitanya Chundru
Some Qcom PCIe controller variants bring the PHY out of test power-down (PHY_TEST_PWR_DOWN) during init. When the link is later transitioned to D3cold and the driver disables PCIe clocks and/or regulators without explicitly re-asserting PHY_TEST_PWR_DOWN, the PHY can remain partially powered, leading to avoidable power leakage. Update the init-path comments to reflect that PARF_PHY_CTRL is used to power the PHY on. Also, for controller revisions that enable PHY power in init (2.3.2, 2.3.3, 2.4.0, 2.7.0 and 2.9.0), explicitly power the PHY down via PARF_PHY_CTRL in the deinit path before disabling clocks or regulators. This ensures the PHY is put into a defined low-power state prior to removing its supplies, preventing leakage when entering D3cold. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260429-d3cold-v5-3-89e9735b9df6@oss.qualcomm.com
2026-05-21PCI: qcom: Add .get_ltssm() callback to query LTSSM statusKrishna Chaitanya Chundru
For older SoCs like SC7280, reading DBI LTSSM register after sending PME_Turn_Off message causes NOC error. To avoid unsafe DBI accesses, introduce qcom_pcie_get_ltssm() to retrieve the LTSSM state without DBI. For newer platforms, read the LTSSM state from the PARF_LTSSM register; for older platforms continue to retrieve it from ELBI_SYS_STTS. This helper is used in place of direct DBI-based link state checks in the D3cold path after sending PME_Turn_Off message, ensuring the LTSSM state can be queried safely even after DBI access is no longer valid. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> [mani: commit log and fixed get_ltssm() check] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260429-d3cold-v5-2-89e9735b9df6@oss.qualcomm.com
2026-05-21PCI: host-common: Add pci_host_common_d3cold_possible() helperKrishna Chaitanya Chundru
Add a common helper, pci_host_common_d3cold_possible(), to determine whether PCIe devices under host bridge can safely transition to D3cold. This helper is intended to be used by PCI host controller drivers to decide whether they can safely put the endpoint devices into D3cold based on their power state and wakeup capabilities. Once the devices are transitioned into D3cold, the host controller can be safely powered off. The helper walks all devices on the all downstream buses and only allows the devices to enter D3cold if all PCIe endpoints are already in PCI_D3hot. This ensures that the host controller driver does not broadcast PME_Turn_Off or power down the controller while any active endpoint still requires the link to remain powered. For devices that may wake the system, the helper additionally requires that the device supports PME wake from D3cold (via WAKE#). Devices that do not have wakeup enabled are not restricted by this check and do not block the devices under host bridge from entering D3cold. Devices without a bound driver and with PCI not enabled via sysfs are treated as inactive and therefore do not prevent the devices under host bridge from entering D3cold. This allows controllers to power down more aggressively when there are no actively managed endpoints. Some devices (e.g. M.2 without auxiliary power) lose PME detection when main power is removed. Even if such devices advertise PME-from-D3cold capability, entering D3cold may break wakeup. Return PME-from-D3cold capability via 'pme_capable' parameter so PCIe controller drivers can apply platform-specific handling to preserve wakeup functionality. Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> [mani: commit log and removed the device checks for d3cold] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260429-d3cold-v5-1-89e9735b9df6@oss.qualcomm.com
2026-05-19PCI: loongson: Override PCIe bridge supported speeds for Loongson-3C6000 seriesZiyao Li
Older steppings of the Loongson-3C6000 series incorrectly report the supported link speeds on their PCIe bridges (device IDs 0x3c19, 0x3c29) as only 2.5 GT/s, despite the upstream bus supporting speeds from 2.5 GT/s up to 16 GT/s. As a result, since commit 774c71c52aa4 ("PCI/bwctrl: Enable only if more than one speed is supported"), bwctrl will be disabled if there's only one 2.5 GT/s value in vector 'supported_speeds'. Manually override the 'supported_speeds' field for affected PCIe bridges with those found on the upstream bus to correctly reflect the supported link speeds. Updating the speeds to reflect what the hardware actually supports avoids quirks in drivers consuming the speed information. This commit was originally found from AOSC OS[1]. Fixes: cd89edda4002 ("PCI: loongson: Add ACPI init support") Signed-off-by: Ayden Meng <aydenmeng@yeah.net> Signed-off-by: Mingcong Bai <jeffbai@aosc.io> [Ziyao Li: move from drivers/pci/quirks.c to drivers/pci/controller/pci-loongson.c] Signed-off-by: Ziyao Li <liziyao@uniontech.com> [Xi Ruoyao: Fixed falling through logic, added debug log, Fixes tag and rebased to 7.0-rc7] Signed-off-by: Xi Ruoyao <xry111@xry111.site> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: commit log, https://lore.kernel.org/all/9d815df3b33a63223112b97440c01247935363c1.camel@xry111.site] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Lain Fearyncess Yang <fsf@live.com> Tested-by: Ayden Meng <aydenmeng@yeah.net> Tested-by: Mingcong Bai <jeffbai@aosc.io> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Cc: stable@vger.kernel.org Link: https://github.com/AOSC-Tracking/linux/commit/4392f441363abdf6fa0a0433d73175a17f493454 Link: https://github.com/AOSC-Tracking/linux/pull/2 #1 Link: https://patch.msgid.link/20260412101731.107059-1-xry111@xry111.site
2026-05-19PCI: mediatek-gen3: Fix incorrectly skipped pwrctrl error messageChen-Yu Tsai
When pwrctrl integration was added, the error message for pci_pwrctrl_create_devices() failure was incorrectly added after the goto statement, causing it to be skipped. Move the goto statement after the dev_err_probe() call so that the error message actually gets printed (or saved if probe is deferred). Fixes: 1a152e21940a ("PCI: mediatek-gen3: Integrate new pwrctrl API") Reported-by: Dan Carpenter <error27@gmail.com> Closes: https://lore.kernel.org/all/adjNaKB5KGpl6qIp@stanley.mountain/ Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260512103347.1751080-1-wenst@chromium.org
2026-05-19PCI: dwc: Fix signedness bug in fault injection test codeDan Carpenter
The kstrtou32() function returns negative error code or zero on success. However, in this case "val" is a u32 and the function returns signed long, so negative error codes from kstrtou32() are returned as high positive values. Store the error code in an int instead. Fixes: d20ee8e2dbd6 ("PCI: dwc: Add debugfs based Error Injection support for DWC") Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/agL-Uwfn26SI4Gb0@stanley.mountain
2026-05-19PCI: tegra194: Use aspm-l1-entry-delay-ns DT property for L1 entrance latencyManikanta Maddireddy
Program the Synopsys DesignWare PORT_AFR L1 entrance latency field from the optional aspm-l1-entry-delay-ns device tree property (nanoseconds). Convert delay to whole microseconds with ceiling division (DIV_ROUND_UP), then derive the 3-bit hw encoding as the minimum of order_base_2(us) and 7. If the property is not present or cannot be read, default to 7. Hardware encoding (PORT_AFR L1 entrance latency, bits 27:29): +--------------------------+----------+ | Advertised maximum | Code | +--------------------------+----------+ | Maximum of 1 us | 000b | +--------------------------+----------+ | Maximum of 2 us | 001b | +--------------------------+----------+ | Maximum of 4 us | 010b | +--------------------------+----------+ | Maximum of 8 us | 011b | +--------------------------+----------+ | Maximum of 16 us | 100b | +--------------------------+----------+ | Maximum of 32 us | 101b | +--------------------------+----------+ | Maximum of 64 us | 110b | +--------------------------+----------+ | Rest | 111b | +--------------------------+----------+ Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260515070753.3852840-2-mmaddireddy@nvidia.com
2026-05-19PCI: dwc: Use DEFINE_SHOW_ATTRIBUTE for ltssm_status debugfsHans Zhang
Replace the custom open function and file_operations with the standard DEFINE_SHOW_ATTRIBUTE macro to reduce boilerplate code. This also adds the previously missing .release() callback and fixes the seq_file leak during close. Signed-off-by: Hans Zhang <18255117159@163.com> [mani: added a note about implicit release callback change spotted by Sashiko] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260508133432.1964491-1-18255117159@163.com
2026-05-18PCI: imx6: Parse 'reset-gpios' in Root Port nodesSherry Sun
The current DT binding for pci-imx6 specifies the 'reset-gpios' property in the host bridge node. However, the PERST# signal logically belongs to individual Root Ports rather than the host bridge itself. This becomes important when supporting PCIe Key E connector and the PCI power control framework for pci-imx6 driver, which requires properties to be specified in Root Port nodes. Parse 'reset-gpios' from Root Port nodes and the PCIe bridge nodes under the Root Port using the common helper pci_host_common_parse_ports(), and update the reset GPIO handling to use the parsed port list from bridge->ports. To maintain DT backwards compatibility, fall back to the legacy method of parsing the host bridge node if the reset property is not present in the Root Port nodes. Since now the reset GPIO is obtained with GPIOD_ASIS flag, it may be in input mode, so use gpiod_direction_output() instead of gpiod_set_value_cansleep() to ensure the reset GPIO is properly configured as output before setting its value. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Richard Zhu <hongxing.zhu@nxp.com> Link: https://patch.msgid.link/20260422093549.407022-5-sherry.sun@nxp.com
2026-05-18PCI: imx6: Assert PERST# before enabling regulatorsSherry Sun
The PCIe endpoint may start responding or driving signals as soon as its supply is enabled, even before the reference clock is stable. Asserting PERST# before enabling the regulator ensures that the endpoint remains in reset throughout the entire power-up sequence, until both power and refclk are known to be stable and link initialization can safely begin. Currently, the driver enables the vpcie3v3aux regulator in imx_pcie_probe() before PERST# is asserted in imx_pcie_host_init(), which may cause PCIe endpoint undefined behavior during early power-up. However, there is no issue so far because PERST# is requested as GPIOD_OUT_HIGH in imx_pcie_probe(), which guarantees that PERST# is asserted before enabling the vpcie3v3aux regulator. This prepares for an upcoming changes that will parse the reset property using the new Root Port binding, which will use GPIOD_ASIS when requesting the reset GPIO. With GPIOD_ASIS, the GPIO state is not guaranteed, so explicit sequencing is required. Fix the power sequencing by: 1. Moving vpcie3v3aux regulator enable from probe to imx_pcie_host_init(), where it can be properly sequenced with PERST#. 2. Moving imx_pcie_assert_perst() before regulator and clock enable to ensure correct ordering. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Richard Zhu <hongxing.zhu@nxp.com> Link: https://patch.msgid.link/20260422093549.407022-4-sherry.sun@nxp.com
2026-05-18PCI: host-generic: Add common helpers for parsing Root Port propertiesSherry Sun
Introduce generic helper functions to parse Root Port device tree nodes and extract common properties like reset GPIOs. This allows multiple PCI host controller drivers to share the same parsing logic. Define struct pci_host_port to hold common Root Port properties (currently only list of PERST# GPIO descriptors) and add pci_host_common_parse_ports() to parse Root Port nodes from device tree. Also add the 'ports' list to struct pci_host_bridge to better maintain parsed Root Port information. Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260422093549.407022-3-sherry.sun@nxp.com
2026-05-18PCI: imx6: Fix IMX6SX_GPR12_PCIE_TEST_POWERDOWN handlingRichard Zhu
The IMX6SX_GPR12_PCIE_TEST_POWERDOWN bit does not control the PCIe reference clock on i.MX6SX. Instead, it is part of i.MX6SX PCIe core reset sequence. Move the IMX6SX_GPR12_PCIE_TEST_POWERDOWN assertion/deassertion into the core reset functions to properly reflect its purpose. Remove the .enable_ref_clk() callback for i.MX6SX since it was incorrectly manipulating this bit. Fixes: e3c06cd063d6 ("PCI: imx6: Add initial imx6sx support") Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260319090844.444987-1-hongxing.zhu@nxp.com
2026-05-18PCI/pwrctrl: Lock device when calling device_is_bound()Bartosz Golaszewski
The kerneldoc for device_is_bound() states that it must be called with the device lock taken. Synchronize the two calls in pwrctrl core. Fixes: b35cf3b6aa1e ("PCI/pwrctrl: Add APIs to power on/off pwrctrl devices") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260518100700.47581-1-bartosz.golaszewski@oss.qualcomm.com
2026-05-18PCI: Drop unnecessary retries when restoring BARsLukas Wunner
In 2012, commit 26f41062f28d ("PCI: check for pci bar restore completion and retry") amended pci_restore_state() to attempt BAR restoration up to 10 times. This was necessary because back in the day, only a 100 msec delay was observed after pcie_flr() carried out a Function Level Reset. The retries ensured that BARs were restored even if devices needed more time to come out of reset. In 2016, commit 5adecf817dd6 ("PCI: Wait for up to 1000ms after FLR reset") extended the delay to 1 sec. Commit a2758b6b8fdb ("PCI: Rename pci_flr_wait() to pci_dev_wait() and make it generic") subsequently extended it further to 60 sec. The lengthened delay makes it unnecessary to retry BAR restoration, so drop it. Reported-by: Bjorn Helgaas <bhelgaas@google.com> Closes: https://lore.kernel.org/r/20260416225745.GA41850@bhelgaas/ Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/785c98b50a7a00d0698848c75d51b8f5669ad18f.1777814679.git.lukas@wunner.de
2026-05-18PCI: Wait for device readiness after D3hot -> D0uninitialized transitionBjorn Helgaas
For a device that advertises No_Soft_Reset == 0, a transition from D3hot to D0uninitialized is a soft reset, and the resulting internal device state is undefined. Per PCIe r7.0, sec 2.3.1, a transition from D3hot to D0uninitialized mandates a minimum 10 ms delay before accessing the device. Following this delay, the device is permitted to respond to initial configuration requests with a Request Retry Status (RRS) completion status if it needs more time to initialize. Call pci_dev_wait() after pci_power_up() performs a D3hot->D0uninitialized transition to ensure the device is ready to accept config accesses, as is done after the similar transition in pci_pm_reset(). If the device is already ready, this is essentially a no-op except for one additional config read. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260518191220.636213-3-bhelgaas@google.com
2026-05-18PCI: Log device readiness timeouts as errorsBjorn Helgaas
pci_dev_wait() waits for a device to be Configuration-Ready after a reset, such as a Function-Level Reset (FLR), a soft reset during a D3hot-> D0uninitialized transition when No_Soft_Reset == 0), or a power-up sequence from D3cold->D0uninitialized. If pci_dev_wait() returns success, the device is guaranteed to respond to configuration requests with Successful Completion status. If it times out, device is completely non-responsive. Upgrade the log level from pci_warn() to pci_err() to reflect this failure state. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Link: https://patch.msgid.link/20260518191220.636213-2-bhelgaas@google.com
2026-05-18PCI: mediatek-gen3: Do full device power down on removalChen-Yu Tsai
When power control for downstream devices was introduced in the mediatek-gen3 PCIe controller driver, only the power to the downstream devices was cut when the controller driver is removed. This matched existing behavior, but in hindsight a proper power down sequence should have been followed. Call mtk_pcie_devices_power_down() on driver removal so that in addition to removing power from the downstream devices, PERST# is asserted. Fixes: 1a152e21940a ("PCI: mediatek-gen3: Integrate new pwrctrl API") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260505105918.1823170-1-wenst@chromium.org
2026-05-18PCI: mediatek-gen3: Add a .shutdown() callback to control PERST# signalJian Yang
Add a .shutdown() callback to control the timing of PERST# and power during system shutdown to ensure that PERST# is asserted before power to the connector is removed, as required by PCIe CEM r6.0, sec 2.2. Signed-off-by: Jian Yang <jian.yang@mediatek.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260413071401.1151-3-jian.yang@mediatek.com
2026-05-18PCI: mediatek-gen3: Fix PERST# control timing during system startupJian Yang
Some MediaTek chips stop generating REFCLK if the PCIE_PHY_RSTB signal of PCIe controller is asserted at the start of mtk_pcie_devices_power_up(). But the driver deasserts PCIE_PHY_RSTB together with PCIE_PE_RSTB signal that is used to deassert PERST#. This violates PCIe CEM r6.0, sec 2.11.2, which mandates waiting for 100ms (PCIE_T_PVPERL_MS) after power becomes stable. Move the MAC, PHY and BRG reset deassert code above the PCIE_T_PVPERL_MS delay and leave the PCIE_PE_RSTB deassertion after the delay. Add the 10ms delay mentioned in the MediaTek datasheet after asserting PCIE_BRG_RSTB and before accessing the PCIE_RST_CTRL_REG register. Signed-off-by: Jian Yang <jian.yang@mediatek.com> [mani: commit log and comments rewording] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260413071401.1151-2-jian.yang@mediatek.com
2026-05-15PCI: brcmstb: Assign pcie->gen from of_pci_get_max_link_speed()Florian Fainelli
After commit 03f920936977 ("PCI: controller: Validate max-link-speed"), pcie->gen stopped being assigned and as a result the established PCIe link would stop supporting Gen3 speeds on 2712 since pcie->gen is used to populate LnkCntl2 and LnkCap in brcm_pcie_set_gen(). If the 'max-link-speed' property is not specified, or it exceeds Gen3, resort to the HW defaults. Link: https://github.com/raspberrypi/linux/issues/7343 Reported-by: Dom Cobley <popcornmix@gmail.com> Reported-by: Phil Elwell <phil@raspberrypi.com> Fixes: 03f920936977 ("PCI: controller: Validate max-link-speed") Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Hans Zhang <18255117159@163.com> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260506164537.103196-1-florian.fainelli@broadcom.com
2026-05-15PCI: altera: Fix resource leaks on probe failureMahesh Vaidya
The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pci_host_probe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct altera_pcie will be released, leaving the handler with a stale data pointer. Interrupts are also enabled before pci_host_probe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed. So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pci_host_probe() fails. Fixes: c63aed7334c2 ("PCI: altera: Use pci_host_probe() to register host") Signed-off-by: Mahesh Vaidya <mahesh.vaidya@altera.com> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Subhransu S. Prusty <subhransu.sekhar.prusty@altera.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260430204330.3121003-3-mahesh.vaidya@altera.com
2026-05-15PCI: altera: Do not dispose parent IRQ mappingMahesh Vaidya
altera_pcie_irq_teardown() calls irq_dispose_mapping() on pcie->irq. However, pcie->irq is the parent IRQ returned by platform_get_irq(), not the mapping created by Altera INTx irq_domain. The Altera driver only sets the chained handler on the parent IRQ. It should detach that handler during teardown, but it should not dispose the parent IRQ mapping, which belongs to the parent interrupt controller's irq_domain. Drop irq_dispose_mapping(pcie->irq) from the teardown path. Note that during irqchip remove(), the child IRQs should've disposed. But since the chained handler itself is removed, there is no way the stale child IRQs (if exists) could fire. So it is safe here. Fixes: ec15c4d0d5d2 ("PCI: altera: Allow building as module") Signed-off-by: Mahesh Vaidya <mahesh.vaidya@altera.com> [mani: added a note about IRQ disposal] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Subhransu S. Prusty <subhransu.sekhar.prusty@altera.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260430204330.3121003-2-mahesh.vaidya@altera.com
2026-05-15PCI: keembay: Use common mode field in struct dw_pcieHans Zhang
Remove the redundant mode field from struct keembay_pcie and use the existing mode field in struct dw_pcie instead. This avoids duplication and prevents potential inconsistencies between the two mode fields. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260501161010.71688-5-18255117159@163.com
2026-05-15PCI: dwc: Use common mode field in struct dw_pcieHans Zhang
Remove the redundant mode field from struct dw_plat_pcie and use the existing mode field in struct dw_pcie instead. This avoids duplication and prevents potential inconsistencies between the two mode fields. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260501161010.71688-4-18255117159@163.com
2026-05-15PCI: artpec6: Use common mode field in struct dw_pcieHans Zhang
Remove the redundant mode field from struct artpec6_pcie and use the existing mode field in struct dw_pcie instead. This avoids duplication and prevents potential inconsistencies between the two mode fields. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260501161010.71688-3-18255117159@163.com
2026-05-15PCI: dra7xx: Use common mode field in struct dw_pcieHans Zhang
Remove the redundant mode field from struct dra7xx_pcie and use the existing mode field in struct dw_pcie instead. This avoids duplication and prevents potential inconsistencies between the two mode fields. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260501161010.71688-2-18255117159@163.com
2026-05-13PCI: qcom: Set max OPP before DBI access during resumeQiang Yu
During resume, qcom_pcie_icc_opp_update() may access DBI registers before the OPP votes are restored, triggering NoC errors. Set the PCIe controller to the maximum OPP first in resume_noirq(), then proceed with link/DBI accesses. The OPP is later updated again based on the actual link bandwidth requirements. Introduce a helper to reuse the max-OPP setup code and share it with probe(). Fixes: 5b6272e0efd5 ("PCI: qcom: Add OPP support to scale performance") Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> [mani: commit log and error log rewording] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260416-setmaxopp-v1-1-6a74e2d945a0@oss.qualcomm.com
2026-05-12PCI: dwc: Apply ECRC workaround for DesignWare cores prior to 5.10aManikanta Maddireddy
The ECRC (TLP digest) workaround was originally applied only for DesignWare core version 4.90a. Per discussion in Synopsys case, the dependency of the iATU TD bit on ECRC generation was removed in 5.10a, so apply the workaround for all DWC versions below that release. Replace the misleading comment that referred to raw version constants with readable DesignWare release name to help readability. Fixes: b210b1595606 ("PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well") Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> [mani: corrected fixes tag format] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20260410062507.657453-1-mmaddireddy@nvidia.com
2026-05-12PCI: ultrarisc: Add UltraRISC DP1000 PCIe Root Complex driverXincheng Zhang
Add DP1000 SoC PCIe Root Complex driver. The controller only supports 32-bit aligned configuration space accesses. Signed-off-by: Xincheng Zhang <zhangxincheng@ultrarisc.com> Signed-off-by: Jia Wang <wangjia@ultrarisc.com> [mani: changed to builtin_platform_driver() to prevent irqchip removal] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: squash MAINTAINERS update here] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260427-ultrarisc-pcie-v4-3-98935f6cdfb5@ultrarisc.com
2026-05-12PCI: amd-mdb: Assert PERST# on shutdownSai Krishna Musham
Add a shutdown handler for the AMD MDB PCIe host controller that asserts the PERST# signal via GPIO before the system powers off or reboots. This ensures the connected PCIe endpoint is held in reset during shutdown. Signed-off-by: Sai Krishna Musham <sai.krishna.musham@amd.com> [mani: removed conditional check since GPIO APIs return safely if desc is NULL] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260427121227.290604-1-sai.krishna.musham@amd.com
2026-05-12PCI: loongson: Do not ignore downstream devices on external bridgesRong Zhang
Loongson PCI host controllers have a hardware quirk that requires software to ignore downstream devices with device number > 0 on the internal bridges. The current implementation applies the workaround to all non-root buses, which breaks external bridges (e.g., PCIe switches) with multiple downstream devices. Fix it by only applying the workaround to internal bridges. Tested on Loongson-LS3A4000-7A1000-NUC-SE, using AMD Promontory 21 chipset add-in card [1]. $ lspci -tnnnvvv -[0000:00]-+-00.0 Loongson Technology LLC 7A1000 Chipset Hyper Transport Bridge Controller [0014:7a00] +-00.1 Loongson Technology LLC 7A2000 Chipset Hyper Transport Bridge Controller [0014:7a10] +-03.0 Loongson Technology LLC 2K1000/2000 / 7A1000 Chipset Gigabit Ethernet Controller [0014:7a03] +-04.0 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB OHCI Controller [0014:7a24] +-04.1 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB EHCI Controller [0014:7a14] +-05.0 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB OHCI Controller [0014:7a24] +-05.1 Loongson Technology LLC 2K1000 / 7A1000/2000 Chipset USB EHCI Controller [0014:7a14] +-06.0 Loongson Technology LLC 7A1000 Chipset Vivante GC1000 GPU [0014:7a15] +-06.1 Loongson Technology LLC 2K1000 / 7A1000 Chipset Display Controller [0014:7a06] +-07.0 Loongson Technology LLC 2K1000/2000/3000 / 3B6000M / 7A1000/2000 Chipset HD Audio Controller [0014:7a07] +-08.0 Loongson Technology LLC 2K1000 / 7A1000 Chipset 3Gb/s SATA AHCI Controller [0014:7a08] +-08.1 Loongson Technology LLC 2K1000 / 7A1000 Chipset 3Gb/s SATA AHCI Controller [0014:7a08] +-08.2 Loongson Technology LLC 2K1000 / 7A1000 Chipset 3Gb/s SATA AHCI Controller [0014:7a08] +-09.0-[01]----00.0 Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter [17cb:1103] +-0a.0-[02]----00.0 Etron Technology, Inc. EJ188/EJ198 USB 3.0 Host Controller [1b6f:7052] +-0f.0-[03-08]----00.0-[04-08]--+-00.0-[05]----00.0 Shenzhen Longsys Electronics Co., Ltd. FORESEE XP1000 / Lexar Professional CFexpress Type B Gold series, NM620 PCIe NVME SSD (DRAM-less) [1d97:5216] | +-08.0-[06]----00.0 MAXIO Technology (Hangzhou) Ltd. NVMe SSD Controller MAP1202 (DRAM-less) [1e4b:1202] | +-0c.0-[07]----00.0 Advanced Micro Devices, Inc. [AMD] 600 Series Chipset USB 3.2 Controller [1022:43f7] | \-0d.0-[08]----00.0 Advanced Micro Devices, Inc. [AMD] 600 Series Chipset SATA Controller [1022:43f6] \-16.0 Loongson Technology LLC 7A1000 Chipset SPI Controller [0014:7a0b] Fixes: 2410e3301fcc ("PCI: loongson: Don't access non-existent devices") Co-developed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Co-developed-by: Lain "Fearyncess" Yang <i@lain.vg> Signed-off-by: Lain "Fearyncess" Yang <i@lain.vg> Signed-off-by: Rong Zhang <i@rong.moe> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://oshwhub.com/wesd/b650 [1] Link: https://patch.msgid.link/20260501-ls7a-bridge-fixes-v2-1-69fa93683805@rong.moe
2026-05-11PCI: intel-gw: Fix ATU base address setup and add optional DT 'atu' regionFlorian Eckert
The ATU base address was set in intel_pcie_host_setup(), which is called via pp->ops->init(). However, dw_pcie_get_resources() runs before this callback and sets a default atu_base of 0x300000, which then gets overwritten by the driver's value of 0xC0000. But this ordering is broken because atu_base must be set before dw_pcie_get_resources() runs, not after. So move the atu_base assignment from intel_pcie_host_setup() to intel_pcie_probe() to fix the initialization order. The call stack is: intel_pcie_probe dw_pcie_host_init dw_pcie_host_get_resources dw_pcie_get_resources <- sets atu_base = 0x300000 pp->ops->init intel_pcie_rc_init intel_pcie_host_setup <- was overwriting atu_base here Additionally, add support for parsing the ATU region from the device tree. If an 'atu' region is present in DT, the DWC core parses it via dw_pcie_get_resources() and the driver does not set atu_base explicitly. If 'atu' is absent, the driver falls back to the hardcoded offset (0xC0000 from DBI base) for backwards compatibility, with a warning to the user. Signed-off-by: Florian Eckert <fe@dev.tdt.de> [mani: commit log] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-6-0a2b933fe04f@dev.tdt.de
2026-05-11PCI: intel-gw: Add .start_link() callbackFlorian Eckert
The pcie-intel-gw driver had no .start_link() callback. Add one so the driver works again and does not abort with the following error messages during probing: intel-gw-pcie d1000000.pcie: host bridge /soc/pcie@d1000000 ranges: intel-gw-pcie d1000000.pcie: MEM 0x00dc000000..0x00ddffffff -> 0x00dc000000 intel-combo-phy d0c00000.combo-phy: Set combo mode: combophy[1]: mode: PCIe single lane mode intel-gw-pcie d1000000.pcie: No outbound iATU found intel-gw-pcie d1000000.pcie: Cannot initialize host intel-gw-pcie d1000000.pcie: probe with driver intel-gw-pcie failed with error -22 intel-gw-pcie c1100000.pcie: host bridge /soc/pcie@c1100000 ranges: intel-gw-pcie c1100000.pcie: MEM 0x00ce000000..0x00cfffffff -> 0x00ce000000 intel-combo-phy c0c00000.combo-phy: Set combo mode: combophy[3]: mode: PCIe single lane mode intel-gw-pcie c1100000.pcie: No outbound iATU found intel-gw-pcie c1100000.pcie: Cannot initialize host intel-gw-pcie c1100000.pcie: probe with driver intel-gw-pcie failed with error -22 Fixes: c5097b9869a1 ("Revert "PCI: dwc: Wait for link up only if link is started"") Fixes: da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started") Signed-off-by: Florian Eckert <fe@dev.tdt.de> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: remove timestamps] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260417-pcie-intel-gw-v5-5-0a2b933fe04f@dev.tdt.de
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-23 01:22:59 +0000