Re: [PATCH v2 14/15] PCI: rcar-gen4: Route Root Port PME and bandwidth notifications

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: rcar-gen4: lock nesting violation when dispatching Root Port IRQ
--

commit 1ab146ed20149ad07e070a26f36acae4f7dc256f
Author: Koichiro Den <den@valinux.co.jp>

PCI: rcar-gen4: Route Root Port PME and bandwidth notifications

The Root Port's PME and link bandwidth notifications are reported in
PCIEINTSTS0 and routed to intreq_pcim_sub, the interrupt shared with the
integrated MSI receiver and the reset requests. Dispatch these
notifications to the virtual Root Port IRQ from the "msi" IRQ handler
after handling any pending iMSI-RX interrupts.

> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index c01f157a7198b..319f917f90270 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c

[ ... ]

> @@ -753,12 +766,12 @@ static irqreturn_t rcar_gen4_pcie_msi_irq_handler(int irq, void *data)
>  
>  	status = readl(rcar->base + PCIEINTSTS0) &
>  		 readl(rcar->base + PCIEINTSTS0EN);
> -	if (!(status & MSI_CTRL_INT))
> -		return IRQ_NONE;
> +	if (status & MSI_CTRL_INT)
> +		dw_handle_msi_irq(&rcar->dw.pp);
> +	if (status & RP_SUB_MASK)
> +		rcar_gen4_pcie_rp_irq_dispatch(rcar);

[Severity: High]
Does this code introduce a lock nesting violation when dispatching the Root
Port IRQ?

When handling PME or bandwidth notifications, this path calls
rcar_gen4_pcie_rp_irq_dispatch(), which wraps the generic IRQ dispatch
inside a raw spinlock:

drivers/pci/controller/dwc/pcie-rcar-gen4.c:rcar_gen4_pcie_rp_irq_dispatch() {
    ...
    guard(raw_spinlock_irqsave)(&rcar->rp_irq_lock);
    ...
    generic_handle_domain_irq(rcar->rp_irq_domain, 0);
}

The generic IRQ core will then execute leaf handlers, such as pcie_pme_irq(),
which acquire standard spinlocks:

drivers/pci/pcie/pme.c:pcie_pme_irq() {
    ...
    spin_lock_irqsave(&data->lock, flags);
    ...
}

Acquiring a standard spinlock while holding a raw spinlock violates lock
nesting rules and will trigger a lockdep warning when
CONFIG_PROVE_RAW_LOCK_NESTING=y.

The generic IRQ core normally avoids this by dropping its own raw spinlocks
before running action handlers, but wrapping the dispatch inside the driver's
own raw spinlock defeats that protection.

Could the generic IRQ dispatch be safely performed outside of the
rp_irq_lock?

>  
> -	dw_handle_msi_irq(&rcar->dw.pp);
> -
> -	return IRQ_HANDLED;
> +	return status & (MSI_CTRL_INT | RP_SUB_MASK) ? IRQ_HANDLED : IRQ_NONE;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928165230.3397664-1-den@valinux.co.jp?part=14