kernel/git/next/linux-next.git/drivers/pci/controller/dwc, branch master

Merge branch 'pci/controller/dwc-rcar-gen4'

2026-09-11T22:14:39+00:00

- Limit Max_Read_Request_Size to 256 to avoid hardware erratum (Marek Vasut) - Add a .post_deinit() callback to handle dw_pcie_ep_init() failures (Marek Vasut) * pci/controller/dwc-rcar-gen4: PCI: rcar-gen4: Use .post_deinit() to handle dw_pcie_ep_init() failures PCI: dwc: Add dw_pcie_ep_ops->post_deinit() callback PCI: rcar-gen4: Limit Max_Read_Request_Size to 256 Bytes

Merge branch 'pci/controller/dwc-qcom'

2026-09-11T22:14:38+00:00

- Only collect reset GPIOs from PCI bridge DT nodes to avoid stealing resets used by downstream devices like USB controllers (Christopher Obbard) - Block accesses to downstream devices on link down to reduce a storm of Completion Timeout AER interrupts (Qiang Yu) - Skip system suspend/resume for firmware-managed PCIe, where firmware manages clocks, regulators, resets, etc (Mrinmay Sarkar) * pci/controller/dwc-qcom: PCI: qcom: Skip system suspend/resume for firmware-managed PCIe PCI: qcom: Block accesses to downstream devices on link down PCI: qcom: Only check bridge nodes for PERST# GPIOs

Merge branch 'pci/controller/dwc-imx6'

2026-09-11T22:14:38+00:00

- Fix pwrctrl device leak when .probe() PM runtime setup fail (hanzhijian) - Enable clock after core reset is asserted to fix enumeration regression on i.MX6Q Apalis platforms with ASM1061/ASM1062 SATA controllers (Richard Zhu) - Improve i.MX95 Gen3 link stability by changing MPLLB_BANDWIDTH from default 120 to 140 (Richard Zhu) * pci/controller/dwc-imx6: PCI: imx6: Update MPLLB bandwidth to improve i.MX95 Gen3 PCIe stability PCI: imx6: Move clock enable after core reset assertion PCI: imx6: Fix pwrctrl device leak on PM runtime setup failure

PCI: imx6: Update MPLLB bandwidth to improve i.MX95 Gen3 PCIe stability

2026-09-11T17:44:53+00:00

Poor bandwidth margins are observed during i.MX95 Gen3 PCIe tests with the default MPLLB_BANDWIDTH value (120). The margins worsened across voltage and temperature (VT) variations and different test matrices, potentially causing link stability issues. Testing with MPLLB_BANDWIDTH value of 140 (0x8c) shows significant improvement in bandwidth margins across all VT conditions and test scenarios. Implement PHY register write helper function and configure: - MPLLB_BW_OVRD_IN = 140 (0x8c) for improved bandwidth margin - MPLLB_BW_OVRD_EN to enable the override This ensures robust PCIe Gen3 performance across all operating conditions. Signed-off-by: Richard Zhu [mani: added regmap_read() to flush IMX95_PCIE_PHY_CR_PARA_SEL update] Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260803034319.992323-1-hongxing.zhu@oss.nxp.com

PCI: Remove device links to PHY

2026-09-10T11:25:10+00:00

This is practically a full revert of commit 7a4db656a635 ("PCI: dra7xx: Create functional dependency between PCIe and PHY") and a partial revert of the device link pieces from commits dfb80534692d ("PCI: cadence: Add generic PHY support to host and EP drivers") 49229238ab47 ("PCI: keystone: Cleanup PHY handling") The trouble with these commits is that they dereference fields inside struct phy from a consumer driver, which will become no longer possible. Since commit 987351e1ea77 ("phy: core: Add consumer device link support") from 2019, the PHY core also adds a device link to order PHY provider and consumer suspend/resume operations. All reverted commits are from 2017-2018, and what they do should actually be redundant now. Signed-off-by: Vladimir Oltean Signed-off-by: Manivannan Sadhasivam Reviewed-by: Manivannan Sadhasivam Acked-by: Bjorn Helgaas Link: https://patch.msgid.link/20260810124315.433448-4-vladimir.oltean@nxp.com

PCI: Add missing headers transitively included by

2026-09-10T11:25:10+00:00

The tegra as well as a few dwc PCI controller drivers uses PM runtime operations without including the required header. Similarly, pcie-rockchip-host, pcie-starfive as well as a few dwc PCI controllers use the regulator consumer API without including . pcie-spacemit-k1.c uses of_get_next_available_child() and of_node_put() without including . It seems these function prototypes were indirectly provided by , mostly by mistake (none of the functions it exports need it). Before the PHY header can drop the unnecessary includes, make sure the PCI controller drivers include what they use. Signed-off-by: Vladimir Oltean Signed-off-by: Manivannan Sadhasivam Acked-by: Bjorn Helgaas Link: https://patch.msgid.link/20260810124315.433448-3-vladimir.oltean@nxp.com

PCI: rcar-gen4: Use .post_deinit() to handle dw_pcie_ep_init() failures

2026-09-03T20:25:35+00:00

Implement .post_deinit() callback in R-Car Gen4 'struct dw_pcie_ep_ops' which asserts reset and stops the clock. This undoes start of clock and deassert of reset performed in .pre_init(), in case dw_pcie_ep_init() fails after successful call of .pre_init() callback. The use of .post_deinit() callback correctly handles the clock and reset unwind, unlike the call of rcar_gen4_pcie_ep_deinit() in dw_pcie_ep_init() which could not discern at which point the dw_pcie_ep_init() failed and can attempt to stop clock and assert reset twice. Since dw_pcie_ep_deinit() also invokes the .post_deinit() callback, drop calls to rcar_gen4_pcie_ep_deinit() in both rcar_gen4_add_dw_pcie_ep() and dw_pcie_ep_init_registers() fail paths and rcar_gen4_remove_dw_pcie_ep() to avoid duplicate stop of clock and assert of reset, and drop no longer used rcar_gen4_pcie_ep_deinit() entirely. Initialize PCIEDMAINTSTSEN early in rcar_gen4_pcie_ep_pre_init() to 0, to make sure that edma_int bits will never be left set in case of failure of dw_pcie_ep_init(), and will only be set in case dw_pcie_ep_init() succeeds. Signed-off-by: Marek Vasut Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Koichiro Den Reviewed-by: Koichiro Den Link: https://patch.msgid.link/20260821122808.238248-2-marek.vasut+renesas@mailbox.org

PCI: dwc: Add dw_pcie_ep_ops->post_deinit() callback

2026-09-03T20:25:34+00:00

If .pre_init() succeeds but subsequent initialization fails, it is mandatory to correctly undo the hardware configuration which the .pre_init() callback did. Introduce a .post_deinit() callback to do exactly that, undo what the .pre_init() callback did. Usually, that means stop the clock, assert reset, and possibly program some registers to quiesce the hardware. Invoke the .post_deinit() callback in dw_pcie_ep_deinit() to retain functional symmetry. Signed-off-by: Marek Vasut Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Tested-by: Koichiro Den Reviewed-by: Koichiro Den Link: https://patch.msgid.link/20260821122808.238248-1-marek.vasut+renesas@mailbox.org

PCI: rcar-gen4: Limit Max_Read_Request_Size to 256 Bytes

2026-09-03T20:24:19+00:00

R-Car Gen4 PCIe controller has a hardware limitation of 256 Bytes Max_Payload_Size (MPS). PCIe specification indicates that the MPS must not exceed minimum MPS of any element along the packet path. The PCI core already enforces this, but add a check to warn if MPS is ever set larger than 256. R-Car Gen4 Reference Manual, chapter 104.4.8 Usage notes for MRRS (Max Read Request Size) states: Please set "Max Read Request Size" to 128 bytes or 256 bytes. If "Max Read Request Size" is set to anything other than the above, the transferred data will not match the expected value. This limitation also seems to apply to devices doing DMA reads, i.e., issuing MRd TLPs. This limitation can be triggered by using non-HMB NVMe SSD with Max_Read_Request_Size 512 Bytes, for example Crucial P5 Plus. Any write to the SSD (MRd TLP issued by the SSD controller) longer than 256 Bytes wraps around at the 256 Byte boundary, and the same data are written to the SSD starting at offset 0 and at 256 Bytes. Limit Max_Read_Request_Size to at most 256 Bytes for each device connected to this PCIe controller to avoid this behavior. A non-HMB (Host Memory Buffer) NVMe SSD can be identified using the following command. Affected SSD reports 'hmpre' field as 0: $ nvme id-ctrl /dev/nvme0 | grep hmpre hmpre : 0 The symptom is a read from the SSD which wraps around at 256 Byte boundary. The test for this symptom can be implemented by writing 512 Byte of random data into the SSD and reading the data back. If the read back data repeat after 256 Bytes, the device is affected. $ dd if=/dev/urandom of=/tmp/data.bin bs=256 count=2 ; \ dd if=/tmp/data.bin of=/dev/nvme0n1 bs=256 count=2 ; \ dd if=/dev/nvme0n1 bs=256 count=2 of=/tmp/readback.bin Expected data: $ hexdump -vC /tmp/data.bin 00000000 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca 00000010 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b ... 00000100 7a ce 3c b2 e1 d5 d9 11 88 63 10 59 76 3c dc 32 <-- random 00000110 72 32 2a 7d a3 e1 aa 13 7c da 58 a1 7b 21 11 50 <-- data Faulty readback, collected without this change in place: $ hexdump -vC /tmp/readback.bin 00000000 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca <---. 00000010 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b <-. | ... | | 00000100 97 81 b7 3b 0e 38 2b 4d a7 d3 e0 47 ff c2 4b ca <-:-+- repeated 00000110 c1 85 98 f0 4a ac 03 a0 3b ab f3 19 44 dd 06 8b <-+--- data ^^^ | '--- Repeat starts at offset 0x100 = 256 Bytes Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode") Signed-off-by: Marek Vasut Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260821020636.111719-1-marek.vasut+renesas@mailbox.org

PCI: qcom: Skip system suspend/resume for firmware-managed PCIe

2026-09-03T13:44:11+00:00

For firmware-managed PCIe controllers, all resources, including clocks, regulators, resets, PHYs and link state, are owned and managed by firmware. The host driver must not attempt to manage these resources during system suspend or resume. Firmware will properly transition the devices/controller into relevant low power modes. Skip the suspend and resume operations for firmware-managed controllers. The associated power domain transitions are handled independently by the genpd framework through its own system suspend/resume callbacks, so no explicit action is required by the PCIe controller driver. Signed-off-by: Mrinmay Sarkar Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260831-skip_suspend-v1-1-ba2d877e22b1@oss.qualcomm.com