linux-stable.git/drivers/pci/controller, branch linux-rolling-lts

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

2026-09-07T15:22:48+00:00

commit 19a30bbb6477bfd7e3109b7a2943e6597ee9de37 upstream.

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
Signed-off-by: Greg Kroah-Hartman

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

2026-09-07T15:22:48+00:00

commit 26b73bae01d6eb81a4a38f36101812f20b2639de upstream.

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
Signed-off-by: Greg Kroah-Hartman

PCI: meson: Fix GPIO state while requesting PERST#

2026-09-07T15:22:48+00:00

commit 40fb390cbcc11797c44c16dabdf763ec87643671 upstream.

Meson devicetree defines the PERST# GPIO as 'reset' GPIO.  Commit
4d3186a525b3 ("PCI: amlogic: Fix reset assertion via gpio descriptor")
inverted the PERST# assertion logic to use proper GPIO descriptor semantics
and moved the polarity configuration to the device tree as GPIO_ACTIVE_LOW.
However, the initial PERST# GPIO state "GPIOD_OUT_LOW" was not updated
accordingly.

This results in the enumeration failure of the endpoint devices as
PERST# would get deasserted while requesting the GPIO even before
power and REFCLK becomes stable.

Without this fix:

  ahci 0000:01:00.0: enabling device (0000 -> 0002)
  ahci 0000:01:00.0: SSS flag set, parallel bus scan disabled
  ahci 0000:01:00.0: Controller reset failed (0xffffffff)
  ahci 0000:01:00.0: probe with driver ahci failed with error -5

With this fix:

  ahci 0000:01:00.0: enabling device (0000 -> 0002)
  ahci 0000:01:00.0: AHCI vers 0001.0300, 32 command slots, 6 Gbps, SATA mode
  ahci 0000:01:00.0: 1/1 ports implemented (port mask 0x1)
  ahci 0000:01:00.0: flags: 64bit ncq led clo only pio ccc

Change the GPIO request flag from GPIOD_OUT_LOW to GPIOD_OUT_HIGH to get
the right behaviour.

Fixes: 4d3186a525b3 ("PCI: amlogic: Fix reset assertion via gpio descriptor")
Signed-off-by: Ronald Claveau 
[mani: CCed stable and commit log]
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Neil Armstrong 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260616-fix-meson-pcie-reset-gpio-v1-1-fca404b4c8be@aliel.fr
Signed-off-by: Greg Kroah-Hartman

PCI: hv: Set irq_retrigger callback for the Hyper-V PCI MSI irqchip

2026-09-07T15:22:48+00:00

commit 86bdd16e8f390d51bae9e77a4bc4164ca2f580fe upstream.

The Hyper-V vPCI MSI irqchip never installs an irq_retrigger() callback.

On CPU hot-unplug fixup_irqs() migrates the interrupts which are affine to
the outgoing CPU to a new target. If an interrupt still has its pending bit
set in the outgoing CPU's IRR at that point, fixup_irqs() resends it on the
new target through the irqchip's irq_retrigger() callback. As the Hyper-V
PCI/MSI chip does not provide that callback, the pending interrupt is
silently dropped, which can result in lost interrupts, stalls and "No irq
handler for vector" messages during CPU hotplug.

Install irq_chip_retrigger_hierarchy() as the irq_retrigger() callback for
the Hyper-V PCI/MSI irqchip, so that a pending interrupt is resent on its
new target CPU via the parent x86 vector domain.

Fixes: 4daace0d8ce85 ("PCI: hv: Add paravirtual PCI front-end for Microsoft Hyper-V VMs")
Cc: stable@vger.kernel.org
Suggested-by: Long Li 
Suggested-by: Thomas Gleixner 
Reviewed-by: Aditya Garg 
Reviewed-by: Shradha Gupta 
Signed-off-by: Naman Jain 
Reviewed-by: Michael Kelley 
Signed-off-by: Wei Liu 
Signed-off-by: Greg Kroah-Hartman

PCI: host-generic: Fix NULL pointer dereference on 32-bit CAM systems

2026-08-27T12:32:49+00:00

commit 008cb88edb41f3c7c8e0ed763ff9f26719830984 upstream.

On 32-bit systems the config space is too large to ioremap in one go, so
pci_ecam_create() maps each bus segment separately and relies on the
->add_bus callback (pci_ecam_add_bus) to populate the per-bus mapping in
cfg->winp[]. pci_ecam_map_bus() then uses that mapping as the base for
every config access.

The generic ECAM ops (pci_generic_ecam_ops) already provide the ->add_bus
and ->remove_bus callbacks, but the CAM (legacy) ops in pci-host-generic.c
do not. As a result, on a 32-bit host using "pci-host-cam-generic" the
per-bus mapping is never set up and the first config read dereferences a
NULL base, crashing during bus enumeration:

 Unable to handle kernel NULL pointer dereference at virtual address 00000800
 Oops [#1]
 CPU: 0 PID: 1 Comm: swapper Not tainted 6.9.7+ #43
 Hardware name: Digilent Nexys-Video-A7 RV32 (DT)
 epc : pci_generic_config_read+0x40/0xb0
  ra : pci_generic_config_read+0x2c/0xb0
 [] pci_generic_config_read+0x40/0xb0
 [] pci_bus_read_config_dword+0x50/0xb0
 [] pci_bus_generic_read_dev_vendor_id+0x3c/0x1ec
 [] pci_scan_single_device+0xa4/0x11c
 [] pci_scan_slot+0x9c/0x23c
 [] pci_scan_child_bus_extend+0x58/0x2f4
 [] pci_scan_root_bus_bridge+0x64/0xe8
 [] pci_host_probe+0x20/0xc8
 [] pci_host_common_probe+0x144/0x1e4

Fix this by giving the CAM ops the same ->add_bus/->remove_bus callbacks.
Since pci_ecam_add_bus() and pci_ecam_remove_bus() are static to ecam.c,
move the CAM ops definition there as pci_generic_cam_ops (mirroring
pci_generic_ecam_ops) and export it for pci-host-generic.c to reference.

Fixes: 8fe55ef23387 ("PCI: Dynamically map ECAM regions")
Signed-off-by: Steffen Persvold 
[mani: removed timestamp from log]
Signed-off-by: Manivannan Sadhasivam 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260709122446.3151899-1-spersvold@gmail.com
Signed-off-by: Greg Kroah-Hartman

PCI: imx6: Configure REF_USE_PAD before PHY reset for i.MX95

2026-07-24T14:17:21+00:00

[ Upstream commit 0c26b1c34d12d4debfb5363cc0be6cdf68e87ba2 ]

According to the i.MX95 PCIe PHY Databook, the ref_use_pad signal in the
Common Block Signals section selects the reference clock source connected
to the PHY pads. Per the specification, any change to this input must be
followed by a PHY reset assertion to take effect.

Move the REF_USE_PAD configuration before the PHY reset toggle to comply
with the required initialization sequence.

Fixes: 47f54a902dcd ("PCI: imx6: Toggle the core reset for i.MX95 PCIe")
Signed-off-by: Richard Zhu 
[mani: renamed the callback and helper to match the usecase]
Signed-off-by: Manivannan Sadhasivam 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260518072715.3166514-2-hongxing.zhu@nxp.com
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: imx6: Fix reference clock source selection for i.MX95

2026-07-24T14:17:20+00:00

[ Upstream commit 88cc4cbe08bba27bb58888d25d336774aa0ccab1 ]

In the PCIe PHY init for the i.MX95, the reference clock source selection
uses a conditional instead of always passing the mask. This currently
breaks functionality if the internal refclk is used.

To fix this issue, always pass IMX95_PCIE_REF_USE_PAD as the mask and clear
bit if external refclk is not used. This essentially swaps the parameters.

Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support")
Signed-off-by: Franz Schnyder 
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Bjorn Helgaas 
Acked-by: Richard Zhu 
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260325093118.684142-1-fra.schnyder@gmail.com
Stable-dep-of: 0c26b1c34d12 ("PCI: imx6: Configure REF_USE_PAD before PHY reset for i.MX95")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: iproc: Restore .map_irq() for the platform bus driver

2026-07-24T14:16:30+00:00

[ Upstream commit 3c2e6cc6affa8acdb99a580be1f8f297edf54204 ]

Commit b64aa11eb2dd ("PCI: Set bridge map_irq and swizzle_irq to default
functions") moved the assignment of default .map_irq() callback to
devm_of_pci_bridge_init() and removed the initialization of
'iproc_pcie::map_irq' in platform bus driver.  This led to the callback
getting assigned the NULL pointer for platform bus driver, thereby breaking
the INTx functionality, since 'iproc_pcie::map_irq' overrides the
'pci_host_bridge::map_irq' callback in iproc_pcie_setup().

This issue only affected the iproc platform bus driver as this driver
relies on the default callback for non-PAXC controllers. iproc-brcm driver
was already providing the custom mapping function, so it was unaffected.

Restore the original (and intended) behaviour to use the default map_irq
function by removing the local 'iproc_pcie::map_irq' pointer and directly
assigning the 'pci_host_bridge::map_irq' callback in iproc-bcma driver.
This ensures that the default 'map_irq' callback is used for platform bus
driver and only iproc-brcm driver overrides it with a custom one.

Fixes: b64aa11eb2dd ("PCI: Set bridge map_irq and swizzle_irq to default functions")
Signed-off-by: Mark Tomlinson 
[mani: commit log]
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Bjorn Helgaas 
Acked-by: Ray Jui 
Link: https://patch.msgid.link/20260430021628.1343154-1-mark.tomlinson@alliedtelesis.co.nz
Signed-off-by: Sasha Levin

PCI: dwc: Avoid dwc_pcie_rasdes_debugfs_deinit() NULL dereference when no RAS DES capability

2026-07-24T14:16:25+00:00

[ Upstream commit 26b67fa10ef84ea667942491b50e6261a45f098d ]

dwc_pcie_rasdes_debugfs_init() returns success when the controller has no
RAS DES capability, leaving pci->debugfs->rasdes_info unset. The common
debugfs teardown path still calls dwc_pcie_rasdes_debugfs_deinit(), which
dereferences rasdes_info unconditionally.

Return early when no RAS DES state was allocated. In that case no RAS DES
mutex was initialized, so there is nothing to destroy.

Fixes: 4fbfa17f9a07 ("PCI: dwc: Add debugfs based Silicon Debug support for DWC")
Signed-off-by: Shuvam Pandey 
[mani: reworded subject]
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Bjorn Helgaas 
Link: https://patch.msgid.link/0f97352506d8d813f70f441de4d63fcd5b7d1c3e.1779123847.git.shuvampandey1@gmail.com
Signed-off-by: Sasha Levin

PCI: mediatek: Use actual physical address instead of virt_to_phys()

2026-07-24T14:16:25+00:00

[ Upstream commit ebc1d9906894703286d12306a6f242d90cfb49e8 ]

The driver previously used virt_to_phys() on the ioremapped register base
(port->base) to compute the MSI message address. Using virt_to_phys() on an
IO mapped address is incorrect because it expects a kernel virtual address.

To fix it, store the physical start of the I/O register region in
mtk_pcie_port->phys_base and use it to build the MSI address. This replaces
the incorrect virt_to_phys() usage and ensures MSI addresses are generated
correctly.

Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622")
Signed-off-by: Manivannan Sadhasivam 
Signed-off-by: Manivannan Sadhasivam 
Tested-by: Caleb James DeLisle 
Link: https://patch.msgid.link/20260521171951.1495781-2-cjd@cjdns.fr
Signed-off-by: Sasha Levin