kernel/drivers/pci/controller/dwc/pcie-designware.h, branch linux-6.18.y

PCI: dwc: Remove duplicate dw_pcie_ep_hide_ext_capability() function

2026-03-12T11:09:31Z

[ Upstream commit 86291f774fe8524178446cb2c792939640b4970c ] Remove dw_pcie_ep_hide_ext_capability() and replace its usage with dw_pcie_remove_ext_capability(). Both functions serve the same purpose of hiding PCIe extended capabilities, but dw_pcie_remove_ext_capability() provides a cleaner API that doesn't require the caller to specify the previous capability ID. Suggested-by: Niklas Cassel Signed-off-by: Qiang Yu Signed-off-by: Manivannan Sadhasivam Tested-by: Niklas Cassel Link: https://patch.msgid.link/20251224-remove_dw_pcie_ep_hide_ext_capability-v1-1-4302c9cdc316@oss.qualcomm.com Stable-dep-of: 43d67ec26b32 ("PCI: dwc: ep: Fix resizable BAR support for multi-PF configurations") Signed-off-by: Sasha Levin

PCI: dwc: Add new APIs to remove standard and extended Capability

2026-03-12T11:09:31Z

[ Upstream commit 0183562f1e824c0ca6c918309a0978e9a269af3e ] 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 Signed-off-by: Wenbin Yao Signed-off-by: Qiang Yu Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20251109-remove_cap-v1-2-2208f46f4dc2@oss.qualcomm.com Stable-dep-of: 43d67ec26b32 ("PCI: dwc: ep: Fix resizable BAR support for multi-PF configurations") Signed-off-by: Sasha Levin

PCI: dwc: Add L1 Substates context to ltssm_status of debugfs

2026-03-12T11:09:25Z

[ Upstream commit 679ec639f29cbdaf36bd79bf3e98240fffa335ee ] 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 Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/1765503205-22184-1-git-send-email-shawn.lin@rock-chips.com Stable-dep-of: 180c3cfe3678 ("Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ"") Signed-off-by: Sasha Levin

PCI: dwc: Advertise L1 PM Substates only if driver requests it

2026-03-12T11:09:24Z

[ Upstream commit a00bba406b5a682764ecb507e580ca8159196aa3 ] L1 PM Substates require the CLKREQ# signal and may also require device-specific support. If CLKREQ# is not supported or driver support is lacking, enabling L1.1 or L1.2 may cause errors when accessing devices, e.g., nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10 If the kernel is built with CONFIG_PCIEASPM_POWER_SUPERSAVE=y or users enable L1.x via sysfs, users may trip over these errors even if L1 Substates haven't been enabled by firmware or the driver. To prevent such errors, disable advertising the L1 PM Substates unless the driver sets "dw_pcie.l1ss_support" to indicate that it knows CLKREQ# is present and any device-specific configuration has been done. Set "dw_pcie.l1ss_support" in tegra194 (if DT includes the "supports-clkreq' property) and qcom (for cfg_2_7_0, cfg_1_9_0, cfg_1_34_0, and cfg_sc8280xp controllers) so they can continue to use L1 Substates. Based on Niklas's patch: https://patch.msgid.link/20251017163252.598812-2-cassel@kernel.org [bhelgaas: drop hiding for endpoints] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20251118214312.2598220-2-helgaas@kernel.org Stable-dep-of: 180c3cfe3678 ("Revert "PCI: dw-rockchip: Enumerate endpoints based on dll_link_up IRQ"") Signed-off-by: Sasha Levin

PCI: dwc: Skip waiting for L2/L3 Ready if dw_pcie_rp::skip_l23_wait is true

2026-03-04T12:21:11Z

[ Upstream commit 58a17b2647ba5aac47e3ffafd0a9b92bf4a9bcbe ] In NXP i.MX6QP and i.MX7D SoCs, LTSSM registers are not accessible once PME_Turn_Off message is broadcasted to the link. So there is no way to verify whether the link has entered L2/L3 Ready state or not. Hence, add a new flag 'dw_pcie_rp::skip_l23_ready' and set it to 'true' for the above mentioned SoCs. This flag when set, will allow the DWC core to skip polling for L2/L3 Ready state and just wait for 10ms as recommended in the PCIe spec r6.0, sec 5.3.3.2.1. Fixes: a528d1a72597 ("PCI: imx6: Use DWC common suspend resume method") Signed-off-by: Richard Zhu [mani: renamed flag to skip_l23_ready and reworded description] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Frank Li Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260114083300.3689672-2-hongxing.zhu@nxp.com Signed-off-by: Sasha Levin

Revert "PCI: dwc: Don't wait for link up if driver can detect Link Up event"

2026-03-04T12:20:55Z

[ Upstream commit 142d5869f6eec3110adda0ad2d931f5b3c22371d ] 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 Signed-off-by: Niklas Cassel Signed-off-by: Manivannan Sadhasivam Tested-by: Shawn Lin Acked-by: Shawn Lin Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20251222064207.3246632-14-cassel@kernel.org Signed-off-by: Sasha Levin

PCI: dwc: Fix wrong PORT_LOGIC_LTSSM_STATE_MASK definition

2025-12-18T13:03:17Z

[ Upstream commit bcc9a4a0bca3aee4303fa4a20302e57b24ac8f68 ] As per DesignWare Cores PCI Express Controller Databook, section 5.50, SII: Debug Signals, cxpl_debug_info[63:0]: [5:0] smlh_ltssm_state: LTSSM current state. Encoding is same as the dedicated smlh_ltssm_state output. The mask should be 6 bits, from 0 to 5. Hence, fix the mask definition. Fixes: 23fe5bd4be90 ("PCI: keystone: Cleanup ks_pcie_link_up()") Signed-off-by: Shawn Lin [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/1763122140-203068-1-git-send-email-shawn.lin@rock-chips.com Signed-off-by: Sasha Levin

Merge branch 'pci/controller/qcom'

2025-10-03T17:13:20Z

- Select PCI Power Control Slot driver so slot voltage rails can be turned on/off if described in Root Port device tree node (Qiang Yu) - Parse only PCI bridge child nodes in device tree, skipping unrelated nodes such as OPP (Operating Performance Points), which caused probe failures (Krishna Chaitanya Chundru) - Add 8.0 GT/s and 32.0 GT/s equalization settings (Ziyue Zhang) - Fix typo in CURSOR macro names (Ziyue Zhang) - Consolidate Root Port 'phy' and 'reset' properties in struct qcom_pcie_port, regardless of whether we got them from the Root Port node or the host bridge node (Manivannan Sadhasivam) - Fetch and map the ELBI register space in the DWC core rather than in each driver individually (Krishna Chaitanya Chundru) - Enable ECAM mechanism in DWC core by setting up iATU with 'CFG Shift Feature' and use this in the qcom driver (Krishna Chaitanya Chundru) * pci/controller/qcom: PCI: dwc: Support ECAM mechanism by enabling iATU 'CFG Shift Feature' PCI: qcom: Prepare for the DWC ECAM enablement PCI: dwc: Prepare the driver for enabling ECAM mechanism using iATU 'CFG Shift Feature' PCI: dwc: Add support for ELBI resource mapping PCI: qcom: Move host bridge 'phy' and 'reset' pointers to struct qcom_pcie_port PCI: qcom: Fix macro typo for CURSOR PCI: qcom: Add equalization settings for 8.0 GT/s and 32.0 GT/s PCI: qcom: Restrict port parsing only to PCIe bridge child nodes PCI: qcom: Select PCI Power Control Slot driver

Merge branch 'pci/controller/dwc'

2025-10-03T17:13:16Z

- Add support for x16 in devicetree 'num-lanes' property (Konrad Dybcio) * pci/controller/dwc: PCI: dwc: Support 16-lane operation

PCI: dwc: Support 16-lane operation

2025-09-26T21:03:02Z

Some hosts support 16 lanes of PCIe. Make num-lanes accept that number. Signed-off-by: Konrad Dybcio Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20250926-topic-pcie_16ln-v1-1-c249acc18790@oss.qualcomm.com