summaryrefslogtreecommitdiff
path: root/drivers/pci/controller
AgeCommit message (Collapse)Author
2026-01-21PCI: dwc: Return -ENODEV from dw_pcie_wait_for_link() if device is not foundManivannan Sadhasivam
The dw_pcie_wait_for_link() function waits up to 1 second for the PCIe link to come up and returns -ETIMEDOUT for all failures without distinguishing cases where no device is present on the bus. But the callers may want to just skip the failure if the device is not found on the bus and handle failure for other reasons. So after timeout, if the LTSSM is in Detect.Quiet or Detect.Active state, return -ENODEV to indicate the callers that the device is not found on the bus and return -ETIMEDOUT otherwise. Also add kernel doc to document the parameter and return values. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Tested-by: Richard Zhu <hongxing.zhu@nxp.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20260120-pci-dwc-suspend-rework-v4-1-2f32d5082549@oss.qualcomm.com
2026-01-21PCI: imx6: Clear CLKREQ# override if 'supports-clkreq' DT property is availableRichard Zhu
CLKREQ# is an optional reference clock request signal defined by the PCIe CEM and M.2 specifications to request REFCLK and exit the L1 Substates. The imx6 controller driver so far forced the CLKREQ# signal to low by enabling the CLKREQ# override logic as the slots do not expose this signal. Now, there are board designs coming up exposing this signal to the endpoint devices. This is identified using the 'supports-clkreq' DT property in the controller node. So when the DT node has this property, clear the CLKREQ# override after link up in host_post_init() callback to allow the endpoint to drive the CLKREQ# signal. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> [mani: squashed the imx8mm_pcie_clkreq_override helper patch & reworded description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
2026-01-21PCI: imx6: Add CLKREQ# override to enable REFCLK for i.MX95 PCIeRichard Zhu
The CLKREQ# is an open drain, active low signal that is driven low by the card to request reference clock. It's an optional signal added in PCIe CEM r4.0, sec 2. Thus, this signal wouldn't be driven low if it's not exposed on the slot. On the i.MX95 EVK board, REFCLK to the host and endpoint is gated by this CLKREQ# signal. So if the CLKREQ# signal is not driven by the endpoint, it will gate the REFCLK to host too, leading to operational failure. Hence, enable the REFCLK on this SoC by enabling the CLKREQ# override using imx95_pcie_clkreq_override() helper during probe. This override should only be cleared when the CLKREQ# signal is exposed on the slot. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> [mani: reworded description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251015030428.2980427-11-hongxing.zhu@nxp.com
2026-01-21PCI: dwc: Invoke post_init in dw_pcie_resume_noirq()Richard Zhu
In some SoCs like i.MX95, CLKREQ# is pulled low by the controller driver before link up. After link up, if the 'supports-clkreq' property is specified in DT, the driver will release CLKREQ# so that it can go high and the endpoint can pull it low whenever required i.e., during exit from L1 Substates. Hence, at the end of dw_pcie_resume_noirq(), invoke the '.post_init()' callback if exists to perform the above mentioned action. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> [mani: reworded description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251015030428.2980427-9-hongxing.zhu@nxp.com
2026-01-20PCI: qcom: Rename PERST# assert/deassert helpers for uniformityManivannan Sadhasivam
Rename the PERST# assert/deassert helpers from qcom_ep_reset_{assert/deassert}() to qcom_pcie_perst_{assert/deassert}() to maintain uniformity. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260115-pci-pwrctrl-rework-v5-15-9d26da3ce903@oss.qualcomm.com
2026-01-16PCI: qcom: Drop the assert_perst() callbacksManivannan Sadhasivam
Previously, the pcie-qcom driver probed first, deasserted PERST#, enabled link training and scanned the bus. By the time the pwrctrl driver probe got called, link training was already enabled by the controller driver. Thus the pwrctrl drivers had to call the .assert_perst() callback, to assert PERST#, power on the needed resources, and then call the .assert_perst() callback to deassert PERST#. Now since all pwrctrl drivers and this controller driver have been converted to the new pwrctrl design where the pwrctrl drivers will first power on the devices before this driver deasserts PERST# and scan the bus. So there is no longer a need for .assert_perst() callback in this driver and in DWC core driver. Hence, drop them. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260115-pci-pwrctrl-rework-v5-13-9d26da3ce903@oss.qualcomm.com
2026-01-16PCI/pwrctrl: Switch to pwrctrl create, power on/off, destroy APIsManivannan Sadhasivam
Adopt pwrctrl APIs to create, power on/off, and destroy pwrctrl devices. In qcom_pcie_host_init(), call pci_pwrctrl_create_devices() to create devices, then pci_pwrctrl_power_on_devices() to power them on, both after controller resource initialization. Once successful, deassert PERST# for all devices. In qcom_pcie_host_deinit(), call pci_pwrctrl_power_off_devices() after asserting PERST#. Note that pci_pwrctrl_destroy_devices() is not called here, as deinit is only invoked during system suspend where device destruction is unnecessary. If the driver becomes removable in future, pci_pwrctrl_destroy_devices() should be called in the remove() handler. Remove the old pwrctrl framework code from the PCI core (including devlinks) as the new APIs are now the sole consumer of pwrctrl functionality. And also do not power on the pwrctrl drivers during probe() as this is now handled by the APIs. Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260115-pci-pwrctrl-rework-v5-12-9d26da3ce903@oss.qualcomm.com
2026-01-14PCI: dw-rockchip: Disable BAR 0 and BAR 1 for Root PortShawn Lin
Some Rockchip PCIe Root Ports report bogus size of 1GiB for the BAR memories and they cause below resource allocation issue during probe. pci 0000:00:00.0: [1d87:3588] type 01 class 0x060400 PCIe Root Port pci 0000:00:00.0: BAR 0 [mem 0x00000000-0x3fffffff] pci 0000:00:00.0: BAR 1 [mem 0x00000000-0x3fffffff] pci 0000:00:00.0: ROM [mem 0x00000000-0x0000ffff pref] ... pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: assigned pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: can't assign; no space pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: failed to assign pci 0000:00:00.0: ROM [mem 0xf0200000-0xf020ffff pref]: assigned pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: releasing pci 0000:00:00.0: ROM [mem 0xf0200000-0xf020ffff pref]: releasing pci 0000:00:00.0: BAR 0 [mem 0x900000000-0x93fffffff]: assigned pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: can't assign; no space pci 0000:00:00.0: BAR 1 [mem size 0x40000000]: failed to assign Since there is no use of the Root Port BAR memories, disable both of them. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> [mani: reworded the description and comment] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/1766570461-138256-1-git-send-email-shawn.lin@rock-chips.com
2026-01-13PCI: qcom-ep: Add support for firmware-managed PCIe EndpointMrinmay Sarkar
Some Qualcomm platforms use firmware to manage PCIe resources such as clocks, resets, and PHY through the SCMI interface. In these cases, the Linux driver should not perform resource enable or disable operations directly. So introduce a `firmware_managed` flag in 'struct qcom_pcie_ep_cfg', and set it to true for SA8255p SoC. When this flag is set, the driver will skip the resource handling and rely on runtime PM APIs to let the firmware handle the resources with the help of power domain. Signed-off-by: Mrinmay Sarkar <mrinmay.sarkar@oss.qualcomm.com> [mani: reworded description and tiny code cleanup] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20260106-firmware_managed_ep-v5-2-1933432127ec@oss.qualcomm.com
2026-01-13PCI: sophgo: Disable L0s and L1 on Sophgo 2044 PCIe Root PortsInochi Amaoto
Sophgo 2044 Root Ports advertise L0 and L1 capabilities without supporting them. Since commit f3ac2ff14834 ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") force enabled ASPM on all device tree platforms, the issue became evident and the SG2044 Root Port started breaking. Hence, disable the L0s and L1 capabilities in the LINKCAP register for the SG2044 Root Ports, so that these states won't get enabled. Fixes: 467d9c0348d6 ("PCI: dwc: Add Sophgo SG2044 PCIe controller driver in Root Complex mode") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> [mani: reworded description and corrected fixes tag] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Han Gao <gaohan@iscas.ac.cn> Link: https://patch.msgid.link/20260109040756.731169-1-inochiama@gmail.com
2026-01-13PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slotsHal Feng
The driver has been using the "enable-gpios" property to control the 3v3 power supply of PCIe slots. But it is not documented in the dt-bindings and also using GPIO APIs is not a standard way to control PCIe slot power, so use the documented "vpcie3v3-supply" property and regulator APIs to control the slot supply. This change will break the DTs which used "enable-gpio" or "enable-gpios" property under the controller node. Since these properties were not defined in the bindings, it is safe to switch to "vpcie3v3-supply". Any out-of-tree DTS impacted by this change should migrate to "vpcie3v3-supply" instead. Signed-off-by: Hal Feng <hal.feng@starfivetech.com> [mani: reworded description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Kevin Xie <kevin.xie@starfivetech.com> Link: https://patch.msgid.link/20251218102149.28062-1-hal.feng@starfivetech.com
2026-01-08PCI: dwc: tegra194: Broaden architecture dependencyVidya Sagar
Replace ARCH_TEGRA_194_SOC dependency with a more generic ARCH_TEGRA check for the Tegra194 PCIe controller, allowing it to be built on Tegra platforms beyond Tegra194. Additionally, ensure compatibility by requiring ARM64 or COMPILE_TEST since this driver works only for ARM64 Tegra SoCs. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> [mani: moved ARM64 dependency to ARCH_TEGRA] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Acked-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by: Jon Hunter <jonathanh@nvidia.com> Link: https://patch.msgid.link/20250508051922.4134041-1-vidyas@nvidia.com
2026-01-05PCI: meson: Report that link is up while in ASPM L0s and L1 statesBjorn Helgaas
Previously meson_pcie_link_up() only returned true if the link was in the L0 state. This was incorrect because hardware autonomously manages transitions between L0, L0s, and L1 while both components on the link stay in D0. Those states should all be treated as "link is active". Returning false when the device was in L0s or L1 broke config accesses because dw_pcie_other_conf_map_bus() fails if the link is down, which caused errors like this: meson-pcie fc000000.pcie: error: wait linkup timeout pci 0000:01:00.0: BAR 0: error updating (0xfc700004 != 0xffffffff) Remove the LTSSM state check, timeout, speed check, and error message from meson_pcie_link_up(), the dw_pcie_ops.link_up() method, so it is a simple boolean check of whether the link is active. Timeouts and error messages are handled at a higher level, e.g., dw_pcie_wait_for_link(). Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver") Reported-by: Linnaea Lavia <linnaea-von-lavia@live.com> Closes: https://lore.kernel.org/r/DM4PR05MB102707B8CDF84D776C39F22F2C7F0A@DM4PR05MB10270.namprd05.prod.outlook.com [bhelgaas: squash removal of unused WAIT_LINKUP_TIMEOUT by Martin Blumenstingl <martin.blumenstingl@googlemail.com>: https://patch.msgid.link/20260105125625.239497-1-martin.blumenstingl@googlemail.com] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Linnaea Lavia <linnaea-von-lavia@live.com> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on BananaPi M2S Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251103221930.1831376-1-helgaas@kernel.org Link: https://patch.msgid.link/20260105125625.239497-1-martin.blumenstingl@googlemail.com
2025-12-30PCI: qcom: Parse PERST# from all PCIe bridge nodesManivannan Sadhasivam
Devicetree schema allows the PERST# GPIO to be present in all PCIe bridge nodes, not just in Root Port node. But the current logic parses PERST# only from the Root Port nodes. Though it is not causing any issue on the current platforms, the upcoming platforms will have PERST# in PCIe switch downstream ports also. So this requires parsing all the PCIe bridge nodes for the PERST# GPIO. Hence, rework the parsing logic to extend to all PCIe bridge nodes starting from the Root Port node. If the 'reset-gpios' property is found for a PCI bridge node, the GPIO descriptor will be stored in qcom_pcie_perst::desc and added to the qcom_pcie_port::perst list. It should be noted that if more than one bridge node has the same GPIO for PERST# (shared PERST#), the driver will error out. This is due to the limitation in the GPIOLIB subsystem that allows only exclusive (non-shared) access to GPIOs from consumers. But this is soon going to get fixed. Once that happens, it will get incorporated in this driver. So for now, PERST# sharing is not supported. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20251216-pci-pwrctrl-rework-v2-1-745a563b9be6@oss.qualcomm.com
2025-12-30PCI: qcom: Remove ASPM L0s support for MSM8996 SoCManivannan Sadhasivam
Though I couldn't confirm ASPM L0s support with the Qcom hardware team, a bug report from Dmitry suggests that L0s is broken on this legacy SoC. Hence, remove L0s support from the Root Port Link Capabilities in this SoC. Since qcom_pcie_clear_aspm_l0s() is now used by more than one SoC config, call it from qcom_pcie_host_init() instead. Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Closes: https://lore.kernel.org/linux-pci/4cp5pzmlkkht2ni7us6p3edidnk25l45xrp6w3fxguqcvhq2id@wjqqrdpkypkf Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://patch.msgid.link/20251126081718.8239-1-mani@kernel.org
2025-12-30PCI: rzg3s-host: Drop the lock on RZG3S_PCI_MSIRS and RZG3S_PCI_PINTRCVISClaudiu Beznea
The RZG3S_PCI_MSIRS and RZG3S_PCI_PINTRCVIS registers are of the R/W1C type. According to the RZ/G3S HW Manual, Rev. 1.10, chapter 34.2.1 Register Type, R/W1C register bits are cleared to 0b by writing 1b, while writing 0b has no effect. Therefore, there is no need to take a lock around writes to these registers. Drop the locking. Along with this, add a note about the R/W1C register type to the register offset definitions. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20251217111510.138848-3-claudiu.beznea.uj@bp.renesas.com
2025-12-30PCI: rzg3s-host: Use pci_generic_config_write() for the root busClaudiu Beznea
The Renesas RZ/G3S host controller allows writing to read-only PCIe configuration registers when the RZG3S_PCI_PERM_CFG_HWINIT_EN bit is set in the RZG3S_PCI_PERM register. However, callers of struct pci_ops::write expect the semantics defined by the PCIe specification, meaning that writes to read-only registers must not be allowed. The previous custom struct pci_ops::write implementation for the root bus temporarily enabled write access before calling pci_generic_config_write(). This breaks the expected semantics. Remove the custom implementation and simply use pci_generic_config_write(). Along with this change, the updates of the PCI_PRIMARY_BUS, PCI_SECONDARY_BUS, and PCI_SUBORDINATE_BUS registers were moved so that they no longer depends on the RZG3S_PCI_PERM_CFG_HWINIT_EN bit in the RZG3S_PCI_PERM_CFG register, since these registers are R/W. Fixes: 7ef502fb35b2 ("PCI: Add Renesas RZ/G3S host controller driver") Suggested-by: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://patch.msgid.link/20251217111510.138848-2-claudiu.beznea.uj@bp.renesas.com
2025-12-29PCI: dwc: Use cfg0_base as iMSI-RX target address to support 32-bit MSI devicesShawn Lin
commit f3a296405b6e ("PCI: dwc: Strengthen the MSI address allocation logic") strengthened the iMSI-RX target address allocation logic to handle 64-bit addresses for platforms without 32-bit DMA addresses. However, it still left 32-bit MSI capable endpoints (EPs) non-functional on such platforms. Per DWC databook r6.21a, sec 3.10.2.3, it states: "The iMSI-RX is programmed with an address (MSI_CTRL_ADDR_OFF and MSI_CTRL_UPPER_ADDR_OFF) that is used as the system MSI address. When an inbound MWr request is passed to the AXI bridge and matches this address as well as the conditions specified for an MSI memory write request, an MSI interrupt is detected. When this MWr is about to be driven onto the AXI bridge master interface1, it is dropped and never appears on the AXI bus." Since iMSI-RX MSI_CTRL_ADDR doesn't require actual system memory mapping, any 32-bit address that won't be used for BAR memory allocations can be assigned. So assign cfg0_base to the iMSI-RX target address as the first option if it's a 32-bit address, which satisfies this requirement. Otherwise, fallback to the existing coherent allocation. cc: Ajay Agarwal <ajayagarwal@google.com> cc: Will McVicker <willmcvicker@google.com> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> [mani: trimmed the description to exclude testbed info and used imperative tone] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/1766540332-24235-1-git-send-email-shawn.lin@rock-chips.com
2025-12-26PCI: cadence: Avoid signed 64-bit truncation and invalid sortIan Rogers
The cdns_pcie_host_dma_ranges_cmp() element comparison function used by list_sort() is of type list_cmp_func_t, so it returns a 32-bit int. cdns_pcie_host_dma_ranges_cmp() computes a resource_size_t difference that may be a 64-bit value, and truncating that difference to a 32-bit return value may change the sign and result in an invalid sort order. Avoid the truncation and invalid sort order by returning -1, 0, or 1. Signed-off-by: Ian Rogers <irogers@google.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20251209223756.2321578-1-irogers@google.com
2025-12-26PCI: tegra: Allow building as a moduleAaron Kling
Change the module macro back to builtin, which does not define an exit function. This will prevent the module from being unloaded. There are concerns with modules not cleaning up IRQs on unload, thus unload must be specifically disallowed. Drop the remove callback as it is unused. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250731-pci-tegra-module-v7-3-cad4b088b8fb@gmail.com
2025-12-23PCI: aspeed: Add ASPEED PCIe RC driverJacky Chou
Introduce PCIe Root Complex driver for ASPEED SoCs. Support RC initialization, reset, clock, IRQ domain, and MSI domain setup. Implement platform-specific setup and register configuration for ASPEED. And provide PCI config space read/write and INTx/MSI interrupt handling. Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251216-upstream_pcie_rc-v7-6-4aeb0f53c4ce@aspeedtech.com
2025-12-23PCI: imx6: Add external reference clock input mode supportRichard Zhu
i.MX95 PCIes have two reference clock inputs: one from internal PLL, the other from off chip crystal oscillator. The "extref" clock refers to a reference clock from an external crystal oscillator. Add external reference clock input mode support for i.MX95 PCIes. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251211064821.2707001-4-hongxing.zhu@nxp.com
2025-12-23PCI: xilinx: Fix INTx IRQ domain leak in error pathsHaotian Zhang
In xilinx_pcie_init_irq_domain(), if xilinx_allocate_msi_domains() fails after pcie->leg_domain has been successfully created via irq_domain_create_linear(), the function returns directly without cleaning up the allocated IRQ domain, resulting in a resource leak. In xilinx_free_msi_domains(), pcie->leg_domain is also neglected. Add irq_domain_remove() call in the error path to properly release the IRQ domain before returning the error. Also rename xilinx_free_msi_domains() to xilinx_free_irq_domains() and add the release of pcie->leg_domain to it. Fixes: 313b64c3ae52 ("PCI: xilinx: Convert to MSI domains") Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251219021615.965-1-vulab@iscas.ac.cn
2025-12-23PCI: dwc: ep: Cache MSI outbound iATU mappingKoichiro Den
dw_pcie_ep_raise_msi_irq() currently programs an outbound iATU window for the MSI target address on every interrupt and tears it down again via dw_pcie_ep_unmap_addr(). On systems that heavily use the AXI bridge interface (for example when the integrated eDMA engine is active), this means the outbound iATU registers are updated while traffic is in flight. The DesignWare endpoint databook 5.40a - "3.10.6.1 iATU Outbound Programming Overview" warns that updating iATU registers in this situation is not supported, and the behavior is undefined. Under high MSI and eDMA load this pattern results in occasional bogus outbound transactions and IOMMU faults, on the RC side, such as: ipmmu-vmsa eed40000.iommu: Unhandled fault: status 0x00001502 iova 0xfe000000 followed by the system becoming unresponsive. This is the actual output observed on Renesas R-Car S4, with its ipmmu_hc used with PCIe ch0. There is no need to reprogram the iATU region used for MSI on every interrupt. The host-provided MSI address is stable while MSI is enabled, and the endpoint driver already dedicates a scratch buffer for MSI generation. Cache the aligned MSI address and map size, program the outbound iATU once, and keep the window enabled. Subsequent interrupts only perform a write to the MSI scratch buffer, avoiding dynamic iATU reprogramming in the hot path and fixing the lockups seen under load. dw_pcie_ep_raise_msix_irq() is not modified, as each vector can have a different msg_addr, and because the msg_addr is allowed to be changed while the vector is masked. Neither problem is easy to solve with the current design. Instead, the plan is for the DWC vendor drivers to transition to dw_pcie_ep_raise_msix_irq_doorbell(), which does not rely on the iATU. Signed-off-by: Koichiro Den <den@valinux.co.jp> [cassel: improve commit message] Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251222110144.3299523-2-cassel@kernel.org
2025-12-22Revert "PCI: dwc: Don't wait for link up if driver can detect Link Up event"Niklas Cassel
This reverts commit 8d3bf19f1b585a3cc0027f508b64c33484db8d0d. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. So revert the change that skipped dw_pcie_wait_for_link() if the Link up IRQ was used by a vendor glue driver. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-14-cassel@kernel.org
2025-12-22Revert "PCI: qcom: Enumerate endpoints based on Link up event in ↵Niklas Cassel
'global_irq' interrupt" This reverts commit 4581403f67929d02c197cb187c4e1e811c9e762a. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-13-cassel@kernel.org
2025-12-22Revert "PCI: qcom: Enable MSI interrupts together with Link up if 'Global ↵Niklas Cassel
IRQ' is supported" This reverts commit ba4a2e2317b9faeca9193ed6d3193ddc3cf2aba3. Since the Link up IRQ support is going away, revert the MSI logic that got added for it too. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> [mani: reworded the description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-12-cassel@kernel.org
2025-12-22Revert "PCI: qcom: Don't wait for link if we can detect Link Up"Niklas Cassel
This reverts commit 36971d6c5a9a134c15760ae9fd13c6d5f9a36abb. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-11-cassel@kernel.org
2025-12-22Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ"Niklas Cassel
This reverts commit 0e0b45ab5d770a748487ba0ae8f77d1fb0f0de3e. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-10-cassel@kernel.org
2025-12-22Revert "PCI: dw-rockchip: Don't wait for link since we can detect Link Up"Niklas Cassel
This reverts commit ec9fd499b9c60a187ac8d6414c3c343c77d32e42. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number and bridge resources after initial scan during boot. The long term plan is to migrate this driver to the upcoming pwrctrl APIs that are supposed to handle this problem elegantly. Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-9-cassel@kernel.org
2025-12-19PCI: dwc: Skip PME_Turn_Off broadcast and L2/L3 transition during suspend if ↵Manivannan Sadhasivam
link is not up During system suspend, if the PCIe link is not up, then there is no need to broadcast PME_Turn_Off message and wait for L2/L3 transition. So skip them. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Link: https://patch.msgid.link/20251218-pci-dwc-suspend-rework-v2-1-5a7778c6094a@oss.qualcomm.com
2025-12-18PCI: dw-rockchip: Change get_ltssm() to provide L1 Substates infoShawn Lin
Rename rockchip_pcie_get_ltssm() to rockchip_pcie_get_ltssm_reg() and add rockchip_pcie_get_ltssm() to get_ltssm() callback in order to show the proper L1 Substates. The PCIE_CLIENT_LTSSM_STATUS[5:0] register returns the same LTSSM layout as enum dw_pcie_ltssm. So the driver just need to convey L1 PM Substates by returning the proper value defined in pcie-designware.h. cat /sys/kernel/debug/dwc_pcie_a40000000.pcie/ltssm_status L1_2 (0x142) Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/1765503205-22184-2-git-send-email-shawn.lin@rock-chips.com
2025-12-18PCI: dwc: Add L1 Substates context to ltssm_status of debugfsShawn Lin
DWC core couldn't distinguish LTSSM state among L1.0, L1.1 and L1.2. But the vendor glue driver may implement additional logic to convey this information. So add two pseudo definitions for vendor glue drivers to translate their internal L1 Substates for debugfs to show. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/1765503205-22184-1-git-send-email-shawn.lin@rock-chips.com
2025-12-18PCI: mediatek: Fix IRQ domain leak when MSI allocation failsHaotian Zhang
In mtk_pcie_init_irq_domain(), if mtk_pcie_allocate_msi_domains() fails after port->irq_domain has been successfully created via irq_domain_create_linear(), the function returns directly without cleaning up the allocated IRQ domain, resulting in a resource leak. Add irq_domain_remove() call in the error path to properly release the INTx IRQ domain before returning the error. Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251119023308.476-1-vulab@iscas.ac.cn
2025-12-18PCI: j721e: Add config guards for Cadence Host and Endpoint library APIsSiddharth Vadapalli
Commit under Fixes enabled loadable module support for the driver under the assumption that it shall be the sole user of the Cadence Host and Endpoint library APIs. This assumption guarantees that we won't end up in a case where the driver is built-in and the library support is built as a loadable module. With the introduction of [1], this assumption is no longer valid. The SG2042 driver could be built as a loadable module, implying that the Cadence Host library is also selected as a loadable module. However, the pci-j721e.c driver could be built-in as indicated by CONFIG_PCI_J721E=y due to which the Cadence Endpoint library is built-in. Despite the library drivers being built as specified by their respective consumers, since the 'pci-j721e.c' driver has references to the Cadence Host library APIs as well, we run into a build error as reported at [0]. Fix this by adding config guards as a temporary workaround. The proper fix is to split the 'pci-j721e.c' driver into independent Host and Endpoint drivers as aligned at [2]. [0]: https://lore.kernel.org/r/202511111705.MZ7ls8Hm-lkp@intel.com/ [1]: commit 1c72774df028 ("PCI: sg2042: Add Sophgo SG2042 PCIe driver") [2]: https://lore.kernel.org/r/37f6f8ce-12b2-44ee-a94c-f21b29c98821@app.fastmail.com/ Fixes: a2790bf81f0f ("PCI: j721e: Add support to build as a loadable module") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202511111705.MZ7ls8Hm-lkp@intel.com/ Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251117113246.1460644-1-s-vadapalli@ti.com
2025-12-18PCI: qcom: Remove DPC Extended CapabilityQiang Yu
Some platforms (e.g., X1E80100) expose Downstream Port Containment (DPC) Extended Capability registers in the PCIe Root Port config space, but do not fully support it. To prevent undefined behavior and ensure DPC cap is not visible to PCI framework and users, remove DPC Extended Capability unconditionally, since there is no Qcom platform support DPC till now. Co-developed-by: Wenbin Yao <wenbin.yao@oss.qualcomm.com> Signed-off-by: Wenbin Yao <wenbin.yao@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251109-remove_cap-v1-5-2208f46f4dc2@oss.qualcomm.com
2025-12-18PCI: qcom: Remove MSI-X Capability for Root PortsQiang Yu
On some platforms like Glymur, the hardware does not support MSI-X in RC mode, yet still exposes the MSI-X capability. However, it omits the required MSI-X Table and PBA structures. This mismatch can lead to issues where the PCIe port driver requests MSI-X instead of MSI, causing the Root Port to trigger interrupts by writing to an uninitialized address, resulting in SMMU faults. To address this, remove MSI-X capability unconditionally for Root Ports of all SoCs as none of the Qcom PCIe Root Ports support MSI-X. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> [mani: updated description] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251109-remove_cap-v1-4-2208f46f4dc2@oss.qualcomm.com
2025-12-18PCI: dwc: Remove MSI/MSIX capability for Root Port if iMSI-RX is used as MSI ↵Qiang Yu
controller Some platforms may not support ITS (Interrupt Translation Service) and MBI (Message Based Interrupt), or there are not enough available empty SPI lines for MBI, in which case the msi-map and msi-parent property will not be provided in device tree node. For those cases, the DWC PCIe driver defaults to using the iMSI-RX module as MSI controller. However, due to DWC IP design, iMSI-RX cannot generate MSI interrupts for Root Ports even when MSI is properly configured and supported as iMSI-RX will only monitor and intercept incoming MSI TLPs from PCIe link, but the memory write generated by Root Port are internal system bus transactions instead of PCIe TLPs, so they are ignored. This leads to interrupts such as PME, AER from the Root Port not received on the host and the users have to resort to workarounds such as passing "pcie_pme=nomsi" cmdline parameter. To ensure reliable interrupt handling, remove MSI and MSI-X capabilities from Root Ports when using iMSI-RX as MSI controller, which is indicated by 'dw_pcie_rp::has_msi_ctrl == true'. This forces a fallback to INTx interrupts by default, eliminating the need for manual kernel command line workarounds. With this behavior: - Platforms with ITS/MBI support use ITS/MBI MSI for interrupts from all components. - Platforms without ITS/MBI support fall back to INTx for Root Ports and use iMSI-RX for other PCI devices. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> [mani: reworded the comment] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Tested-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Link: https://patch.msgid.link/20251109-remove_cap-v1-3-2208f46f4dc2@oss.qualcomm.com
2025-12-18PCI: dwc: Add new APIs to remove standard and extended CapabilityQiang Yu
On some platforms, certain PCIe Capabilities may be present in hardware but are not fully implemented as defined in PCIe spec. These incomplete capabilities should be hidden from the PCI framework to prevent unexpected behavior. Introduce two APIs to remove a specific PCIe Capability and Extended Capability by updating the previous capability's next offset field to skip over the unwanted capability. These APIs allow RC drivers to easily hide unsupported or partially implemented capabilities from software. Co-developed-by: Wenbin Yao <wenbin.yao@oss.qualcomm.com> Signed-off-by: Wenbin Yao <wenbin.yao@oss.qualcomm.com> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251109-remove_cap-v1-2-2208f46f4dc2@oss.qualcomm.com
2025-12-18PCI: Add preceding capability position support in PCI_FIND_NEXT_*_CAP macrosQiang Yu
Add support for finding the preceding capability position in PCI capability list by extending the capability finding macros with an additional parameter. This functionality is essential for modifying PCI capability list, as it provides the necessary information to update the "next" pointer of the predecessor capability when removing entries. Modify two macros to accept a new 'prev_ptr' parameter: - PCI_FIND_NEXT_CAP - Now accepts 'prev_ptr' parameter for standard capabilities - PCI_FIND_NEXT_EXT_CAP - Now accepts 'prev_ptr' parameter for extended capabilities When a capability is found, these macros: - Store the position of the preceding capability in *prev_ptr (if prev_ptr != NULL) - Maintain all existing functionality when prev_ptr is NULL Update current callers to accommodate this API change by passing NULL to 'prev_ptr' argument if they do not care about the preceding capability position. No functional changes to driver behavior result from this commit as it maintains the existing capability finding functionality while adding the infrastructure for future capability removal operations. Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251109-remove_cap-v1-1-2208f46f4dc2@oss.qualcomm.com
2025-12-18PCI: rcar-host: Add OF Kconfig dependency to avoid objtool no-cfi warningNathan Chancellor
After commit 894af4a1cde6 ("objtool: Validate kCFI calls"), compile testing pcie-rcar-host.c with CONFIG_FINEIBT=y and CONFIG_OF=n results in a no-cfi objtool warning in rcar_pcie_probe(): $ cat allno.config CONFIG_CFI=y CONFIG_COMPILE_TEST=y CONFIG_CPU_MITIGATIONS=y CONFIG_GENERIC_PHY=y CONFIG_MITIGATION_RETPOLINE=y CONFIG_MODULES=y CONFIG_PCI=y CONFIG_PCI_MSI=y CONFIG_PCIE_RCAR_HOST=y CONFIG_X86_KERNEL_IBT=y $ make -skj"$(nproc)" ARCH=x86_64 KCONFIG_ALLCONFIG=1 LLVM=1 clean allnoconfig vmlinux vmlinux.o: warning: objtool: rcar_pcie_probe+0x191: no-cfi indirect call! When CONFIG_OF is unset, of_device_get_match_data() returns NULL, so LLVM knows this indirect call has no valid destination and drops the kCFI setup before the call, triggering the objtool check that makes sure all indirect calls have kCFI setup. This driver depends on OF for probing with non-NULL data for every match so this call will never be NULL in practice. Add a hard Kconfig dependency on OF to avoid the warning. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202510092124.O2IX0Jek-lkp@intel.com/ Closes: https://github.com/ClangBuiltLinux/linux/issues/2134 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251014-rcar_pcie_probe-avoid-nocfi-objtool-warning-v2-1-6e0204b002c6@kernel.org
2025-12-15PCI: dwc: Enable MSI affinity supportRadu Rendec
Leverage the interrupt redirection infrastructure to enable CPU affinity support for MSI interrupts. Since the parent interrupt affinity cannot be changed, affinity control for the child interrupt (MSI) is achieved by redirecting the handler to run in IRQ work context on the target CPU. This patch was originally prepared by Thomas Gleixner (see Link tag below) in a patch series that was never submitted as is, and only parts of that series have made it upstream so far. Originally-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Radu Rendec <rrendec@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/linux-pci/878qpg4o4t.ffs@tglx/ Link: https://patch.msgid.link/20251128212055.1409093-4-rrendec@redhat.com
2025-12-15PCI: dwc: Code cleanupRadu Rendec
Code cleanup with no functional changes. These changes were originally made by Thomas Gleixner (see Link tag below) in a patch that was never submitted as is. Other parts of that patch were eventually submitted as commit 8e717112caf3 ("PCI: dwc: Switch to msi_create_parent_irq_domain()") and the remaining parts are the code cleanup changes: - Use guard()/scoped_guard() instead of open-coded lock/unlock. - Return void in a few functions whose return value is never used. - Simplify dw_handle_msi_irq() by using for_each_set_bit(). One notable deviation from the original patch is that it reverts back to a simple 1 by 1 iteration over the controllers inside dw_handle_msi_irq. The reason is that with the original changes, the IRQ offset was calculated incorrectly. This prepares the ground for enabling MSI affinity support, which was originally part of that same series that Thomas Gleixner prepared. Originally-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Radu Rendec <rrendec@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/linux-pci/878qpg4o4t.ffs@tglx/ Link: https://patch.msgid.link/20251128212055.1409093-3-rrendec@redhat.com
2025-12-09PCI: rzg3s-host: Initialize MSI status bitmap before useClaudiu Beznea
Initialize rzg3s_pcie_msi_irq() MSI status bitmap before use. Fixes: 7ef502fb35b2 ("PCI: Add Renesas RZ/G3S host controller driver") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/all/202512070218.XVMUQCl7-lkp@intel.com Closes: https://lore.kernel.org/all/202512061812.Xbqmd2Gn-lkp@intel.com Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20251209125122.304129-1-claudiu.beznea.uj@bp.renesas.com
2025-12-04Merge tag 'pci-v6.19-changes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci Pull PCI updates from Bjorn Helgaas: "Enumeration: - Enable host bridge emulation for PCI_DOMAINS_GENERIC platforms (Dan Williams) - Switch vmd from custom domain number allocator to the common allocator to prevent a potential race with new non-VMD buses (Dan Williams) - Enable Precision Time Measurement (PTM) only if device advertises support for a relevant role, to prevent invalid PTM Requests that cause ACS violations that are reported as AER Uncorrectable Non-Fatal errors (Mika Westerberg) Resource management: - Prevent resource tree corruption when BAR resize fails (Ilpo Järvinen) - Restore BARs to the original size if a BAR resize fails (Ilpo Järvinen) - Remove BAR release from BAR resize attempts by the xe, i915, and amdgpu drivers so the PCI core can restore BARs if the resize fails (Ilpo Järvinen) - Move Resizable BAR code to rebar.c (Ilpo Järvinen) - Add pci_rebar_size_supported() and use it in i915 and xe (Ilpo Järvinen) - Add pci_rebar_get_max_size() and use it in xe and amdgpu (Ilpo Järvinen) Power management and error handling: - For drivers using PCI legacy suspend, save config state at suspend so that state (not any earlier state from enumeration, probe, or error recovery) will be restored when resuming (Lukas Wunner) - For devices with no driver or a driver that lacks power management, save config state at hibernate so that state (not any earlier state from enumeration, probe, or error recovery) will be restored when resuming (Lukas Wunner) - Save device config space on device addition, before driver binding, so error recovery works more reliably (Lukas Wunner) - Drop pci_save_state() from several drivers that no longer need it since the PCI core always does it and pci_restore_state() no longer invalidates the saved state (Lukas Wunner) - Document use of pci_save_state() by drivers to capture the state they want restored during error recovery (Lukas Wunner) Power control: - Add a struct pci_ops.assert_perst() function pointer to assert/deassert PCIe PERST# and implement it for the qcom driver (Krishna Chaitanya Chundru) - Add DT binding and pwrctrl driver for the Toshiba TC9563 PCIe switch, which must be held in reset after poweron so the pwrctrl driver can configure the switch via I2C before bringing up the links (Krishna Chaitanya Chundru) Endpoint framework: - Convert the endpoint doorbell test to use a threaded IRQ to fix a 'sleeping while atomic' issue (Bhanu Seshu Kumar Valluri) - Add endpoint VNTB MSI doorbell support to reduce latency between host and endpoint (Frank Li) New native PCIe controller drivers: - Add CIX Sky1 host controller DT binding and driver (Hans Zhang) - Add NXP S32G host controller DT binding and driver (Vincent Guittot) - Add Renesas RZ/G3S host controller DT binding and driver (Claudiu Beznea) - Add SpacemiT K1 host controller DT binding and driver (Alex Elder) Amlogic Meson PCIe controller driver: - Update DT binding to name DBI region 'dbi', not 'elbi', and update driver to support both (Manivannan Sadhasivam) Apple PCIe controller driver: - Move struct pci_host_bridge allocation from pci_host_common_init() to callers, which significantly simplifies pcie-apple (Marc Zyngier) Broadcom STB PCIe controller driver: - Disable advertising ASPM L0s support correctly (Jim Quinlan) - Add a panic/die handler to print diagnostic info in case PCIe caused an unrecoverable abort (Jim Quinlan) Cadence PCIe controller driver: - Add module support for Cadence platform host and endpoint controller driver (Manikandan K Pillai) - Split headers into 'legacy' (LGA) and 'high perf' (HPA) to prepare for new CIX Sky1 driver (Manikandan K Pillai) MediaTek PCIe controller driver: - Convert DT binding to YAML schema (Christian Marangi) - Add Airoha AN7583 DT compatible and driver support (Christian Marangi) Qualcomm PCIe controller driver: - Add Qualcomm Kaanapali to SM8550 DT binding (Qiang Yu) - Add required 'power-domains' and 'resets' to qcom sa8775p, sc7280, sc8280xp, sm8150, sm8250, sm8350, sm8450, sm8550, x1e80100 DT schemas (Krzysztof Kozlowski) - Look up OPP using both frequency and data rate (not just frequency) so RPMh votes can account for both (Krishna Chaitanya Chundru) Rockchip DesignWare PCIe controller driver: - Add Rockchip RK3528 compatible strings in DT binding (Yao Zi) STMicroelectronics STM32MP25 PCIe controller driver: - Fix a race between link training and endpoint register initialization (Christian Bruel) - Align endpoint allocations to match the ATU requirements (Christian Bruel) Synopsys DesignWare PCIe controller driver: - Clear L1 PM Substate Capability 'Supported' bits unless glue driver says it's supported, which prevents users from enabling non-working L1SS. Currently only qcom and tegra194 support L1SS (Bjorn Helgaas) - Remove now-superfluous L1SS disable code from tegra194 (Bjorn Helgaas) - Configure L1SS support in dw-rockchip when DT says 'supports-clkreq' (Shawn Lin) TI Keystone PCIe controller driver: - Fail the probe instead of silently succeeding if ks_pcie_of_data didn't specify Root Complex or Endpoint mode (Siddharth Vadapalli) - Make keystone buildable as a loadable module, except on ARM32 where hook_fault_code() is __init (Siddharth Vadapalli)" * tag 'pci-v6.19-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci: (100 commits) MAINTAINERS: Add Manivannan Sadhasivam as PCI/pwrctrl maintainer MAINTAINERS: Add CIX Sky1 PCIe controller driver maintainer PCI: sky1: Add PCIe host support for CIX Sky1 dt-bindings: PCI: Add CIX Sky1 PCIe Root Complex bindings PCI: cadence: Add support for High Perf Architecture (HPA) controller MAINTAINERS: Add NXP S32G PCIe controller driver maintainer PCI: s32g: Add NXP S32G PCIe controller driver (RC) PCI: dwc: Add register and bitfield definitions dt-bindings: PCI: s32g: Add NXP S32G PCIe controller PCI: Add Renesas RZ/G3S host controller driver PCI: host-generic: Move bridge allocation outside of pci_host_common_init() dt-bindings: PCI: Add Renesas RZ/G3S PCIe controller binding PCI: Validate pci_rebar_size_supported() input Documentation: PCI: Amend error recovery doc with pci_save_state() rules treewide: Drop pci_save_state() after pci_restore_state() PCI/ERR: Ensure error recoverability at all times PCI/PM: Stop needlessly clearing state_saved on enumeration and thaw PCI/PM: Reinstate clearing state_saved in legacy and !PM codepaths PCI: dw-rockchip: Configure L1SS support PCI: tegra194: Remove unnecessary L1SS disable code ...
2025-12-03Merge branch 'pci/pwrctrl-tc9563'Bjorn Helgaas
- Add a struct pci_ops.assert_perst() function pointer to assert/deassert PCIe PERST# and implement it for the qcom driver (Krishna Chaitanya Chundru) - Add DT binding and pwrctrl driver for the Toshiba TC9563 PCIe switch, which must be held in reset after poweron so the pwrctrl driver can configure the switch via I2C before bringing up the links (Krishna Chaitanya Chundru) * pci/pwrctrl-tc9563: PCI: pwrctrl: Add power control driver for TC9563 PCI: qcom: Implement .assert_perst() PCI: dwc: Implement .assert_perst() for dwc glue drivers PCI: Add .assert_perst() to control PCIe PERST# dt-bindings: PCI: Add binding for Toshiba TC9563 PCIe switch
2025-12-03Merge branch 'pci/controller/stm32'Bjorn Helgaas
- Fix a race between link training and endpoint register initialization (Christian Bruel) - Align endpoint allocations to match the ATU requirements (Christian Bruel) - Add #includes to avoid depending on 'proxy' headers (Andy Shevchenko) * pci/controller/stm32: PCI: stm32: Don't use 'proxy' headers PCI: stm32: Fix EP page_size alignment PCI: stm32: Fix LTSSM EP race with start link
2025-12-03Merge branch 'pci/controller/spacemit-k1'Bjorn Helgaas
- Add DT binding and driver for SpacemiT K1 (Alex Elder) * pci/controller/spacemit-k1: PCI: spacemit: Add SpacemiT PCIe host driver dt-bindings: pci: spacemit: Introduce PCIe host controller
2025-12-03Merge branch 'pci/controller/sky1'Bjorn Helgaas
- Add module support for platform controller driver (Manikandan K Pillai) - Split headers into 'legacy' (LGA) and 'high perf' (HPA) (Manikandan K Pillai) - Add DT binding and driver for CIX Sky1 (Hans Zhang) * pci/controller/sky1: MAINTAINERS: Add CIX Sky1 PCIe controller driver maintainer PCI: sky1: Add PCIe host support for CIX Sky1 dt-bindings: PCI: Add CIX Sky1 PCIe Root Complex bindings PCI: cadence: Add support for High Perf Architecture (HPA) controller PCI: cadence: Move PCIe RP common functions to a separate file PCI: cadence: Split PCIe controller header file PCI: cadence: Add module support for platform controller driver
2025-12-03Merge branch 'pci/controller/sg2042'Bjorn Helgaas
- Fix sg2042_pcie_remove() reference count issue (Christophe JAILLET) * pci/controller/sg2042: PCI: sg2042: Fix a reference count issue in sg2042_pcie_remove()
generated by cgit v1.2.3 (git 2.46.0) at 2026-03-14 21:10:24 +0000