kernel/git/stable/linux.git/drivers/pci/controller/plda, branch master

Merge branch 'pci/controller/misc'

2026-08-21T21:40:47+00:00

- Use common wait time definitions for PCIe link monitoring instead of defining driver-private duplicates (Thierry Reding) - Add LECARC PMU IDs to the DWC RAS/DES VSEC list so it can take advantage of the existing debugfs support for silicon debug, error injection, and event counters (Brett Zhou) * pci/controller/misc: PCI: dwc: Add PCI ID for LECARC PCIe PMU PCI: Use standard wait times for PCIe link monitoring

Merge branch 'pci/controller/plda-starfive'

2026-08-21T21:40:45+00:00

- Fix resource leaks on error paths in host_init() (Ali Tariq) - Fix runtime PM handling and teardown ordering to avoid register access while power or clocks are disabled (Ali Tariq) - Check for runtime PM resume failure to avoid register access while power or clocks are disabled (Ali Tariq) * pci/controller/plda-starfive: PCI: starfive: Fix unchecked pm_runtime_get_sync() in probe PCI: starfive: Fix Runtime PM handling and teardown ordering PCI: starfive: Fix resource leaks on error paths in host_init()

PCI: starfive: Fix unchecked pm_runtime_get_sync() in probe

2026-07-29T16:42:43+00:00

pm_runtime_get_sync() is called in starfive_pcie_probe() without checking its return value. If runtime resume fails, the driver proceeds to configure PCIe hardware through regmap_update_bits(), enable clocks and resets, and power on the PHY, even though the device may not actually be powered. pm_runtime_get_sync() also increments the usage counter even when resume fails, which would leave the counter unbalanced if this error path were later handled without additional cleanup. Switch to pm_runtime_resume_and_get(), which balances the usage counter internally on failure, and bail out of probe before any hardware is touched if resume does not succeed. Tested on StarFive VisionFive 2 v1.2A board. Fixes: 6168efbebace ("PCI: starfive: Enable controller runtime PM before probing host bridge") Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260718153352.661930-1-alitariq45892@gmail.com

PCI: starfive: Fix Runtime PM handling and teardown ordering

2026-07-29T16:37:39+00:00

The starfive_pcie_remove() path incorrectly disabled runtime PM before executing plda_pcie_host_deinit(), which can cause unmanaged hardware register access in plda_pcie_host_deinit() while power domains or clocks are disabled. Fix this by restructuring starfive_pcie_remove() to deinitialize the host controller first while runtime PM is active, followed by a synchronous pm_runtime_put_sync() and pm_runtime_disable(). This bug was found in automated AI review by sashiko-bot. Fixes: 39b91eb40c6a ("PCI: starfive: Add JH7110 PCIe controller") Closes: https://lore.kernel.org/linux-pci/20260712180440.423421F000E9@smtp.kernel.org/ Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260718133825.445041-1-alitariq45892@gmail.com

PCI: plda: Fix IRQ domain leaks in the error paths of plda_init_interrupts()

2026-07-29T16:33:19+00:00

plda_init_interrupts() initializes IRQ domains and creates IRQ mapping but does not unwind them when later step fails. If platform_get_irq() or either irq_create_mapping() fails in plda_init_interrupts(), the domains are never deinitialized. If irq_create_mapping() fails, port->intx_irq stays initialized. Hence, remove the IRQ domains in the error path by calling plda_pcie_irq_domain_deinit(). Since plda_pcie_irq_domain_deinit() now disposes of the intx_irq and msi_irq mappings itself before removing their domains, the msi_irq mapping failure path can go directly to err_irq_domain_deinit instead of disposing of port->intx_irq separately first. This issue was found by automated review of sashiko-bot Fixes: 4602c370bdf6 ("PCI: microchip: Move IRQ functions to pcie-plda-host.c") Fixes: 76c911396807 ("PCI: plda: Add host init/deinit and map bus functions") Closes: https://lore.kernel.org/linux-pci/20260718120701.DF4111F000E9@smtp.kernel.org/ Signed-off-by: Ali Tariq [mani: commit log] Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260723142824.726655-1-alitariq45892@gmail.com

PCI: plda: Fix use-after-free of event IRQs during teardown

2026-07-29T16:30:41+00:00

plda_pcie_irq_domain_deinit() removes pcie->event_domain via irq_domain_remove(), but the per-event IRQs mapped from that domain are requested with devm_request_irq() in plda_init_interrupts(). The actual free_irq() for a devm-managed IRQ is deferred by devres until after the calling probe()/remove() function returns. This means irq_domain_remove() can free the domain's internal data before the deferred free_irq() for IRQs still mapped into it has run. When devres later processes that deferred cleanup, it can end up dereferencing the already-freed domain. Free each event IRQ explicitly with devm_free_irq() before removing the domain. This triggers the free immediately and removes the IRQ from the devres tracking list, so devres will not attempt to free it a second time later. Also dispose of the event, INTx, and MSI IRQ mappings with irq_dispose_mapping() before their owning domains are removed. Finally, guard the calls to irq_set_chained_handler_and_data() for pcie->irq, pcie->msi_irq, and pcie->intx_irq so they only run when those fields hold a valid (>0) IRQ number. This is a pre-existing issue, flagged by automated review during work on an earlier, unrelated patch to this driver. Build-tested and boot-tested on StarFive VisionFive v1.2A board Fixes: 76c911396807 ("PCI: plda: Add host init/deinit and map bus functions") Closes: https://lore.kernel.org/linux-pci/20260714115343.4D49E1F000E9@smtp.kernel.org/ Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260723140434.675512-2-alitariq45892@gmail.com

PCI: Use standard wait times for PCIe link monitoring

2026-07-29T14:37:44+00:00

Instead of defining the wait values for each driver, use common values defined in the core pci.h header file. Note that while most drivers use the usleep_range(), it looks like these were mostly cargo culted and msleep() is a better choice given the fixed delay that the specification calls for. Convert all drivers to msleep() and use the existing definition. Signed-off-by: Thierry Reding Signed-off-by: Manivannan Sadhasivam Reviewed-by: Aksh Garg Link: https://patch.msgid.link/20260716-tegra264-pcie-v8-3-23e51589229b@nvidia.com

PCI: starfive: Fix resource leaks on error paths in host_init()

2026-07-16T16:52:11+00:00

starfive_pcie_host_init() acquires the PHY, clocks/resets, and an optional regulator in sequence, but does not correctly unwind these resources when a later step fails. If starfive_pcie_clk_rst_init() fails after the PHY has already been successfully enabled, the function returns directly without disabling the PHY, leaking it and leaving it powered. If regulator_enable() fails for the optional vpcie3v3 regulator, the failure is only logged; the function falls through and returns success, leaving the driver believing the regulator is enabled while continuing to configure PCIe hardware that may be unpowered. This also leaves the clocks and PHY enabled with nothing to clean them up. Disable the PHY on the clk/reset failure path, and disable the clocks/resets and PHY, then return the error, if the regulator fails to enable. Build-tested and boot-tested on StarFive VisionFive 2 v1.2A Fixes: 05a75df4182e ("PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slots") Fixes: 39b91eb40c6a ("PCI: starfive: Add JH7110 PCIe controller") Signed-off-by: Ali Tariq Signed-off-by: Manivannan Sadhasivam Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260716102053.185276-1-alitariq45892@gmail.com

PCI: plda: Protect root bus removal with rescan lock

2026-06-18T16:50:55+00:00

Hold the pci_rescan_remove_lock lock while stopping and removing a root bus to avoid racing with concurrent rescan or hotplug operations triggered via sysfs. Such races may lead to use-after-free issues or system crashes. Signed-off-by: Hans Zhang <18255117159@163.com> Signed-off-by: Manivannan Sadhasivam [bhelgaas: commit log] Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260521161822.132996-10-18255117159@163.com

PCI: starfive: Use regulator APIs to control the 3v3 power supply of PCIe slots

2026-01-13T14:05:34+00:00

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 [mani: reworded description] Signed-off-by: Manivannan Sadhasivam Acked-by: Kevin Xie Link: https://patch.msgid.link/20251218102149.28062-1-hal.feng@starfivetech.com