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

Merge branch 'pci/controller/vmd'

2026-09-08T23:17:19+00:00

- Flush initiator posted writes before calling IRQ handler to work around a Meteor Lake erratum, where a DMA completion MSI can arrive before the completion queue in memory has been updated, resulting in an nvme 30 second stall before a QID timeout and possibly other similar problems (Rickey Bartlett) * pci/controller/vmd: PCI: vmd: Flush initiator posted writes before demuxing interrupts on Meteor Lake

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

2026-09-08T23:17:19+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-08T23:17:18+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-08T23:17:18+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) * pci/controller/dwc-imx6: PCI: imx6: Move clock enable after core reset assertion PCI: imx6: Fix pwrctrl device leak on PM runtime setup failure

Merge branch 'pci/controller/dwc-dra7xx'

2026-09-08T23:17:18+00:00

- Fix optional clock leak when .probe() fails by using devm_clk_get_optional_enabled() (Felix Gu) - Fix device link leaks when PHY get or enable fails (Felix Gu) * pci/controller/dwc-dra7xx: PCI: dra7xx: Fix device links leak when dra7xx_pcie_enable_phy() fails PCI: dra7xx: Fix device link leak when devm_phy_get() fails PCI: dra7xx: Fix clock enable leak on probe failure

Merge branch 'pci/controller/cadence'

2026-09-08T23:17:17+00:00

- Fix enum type mismatch warning in LTSSM debugfs (Hans Zhang) * pci/controller/cadence: PCI: cadence: Fix enum type mismatch warning in LTSSM debugfs

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