Re: [PATCH net v4 09/15] net: stmmac: track datapath and power ownership across failed reopening

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] net: stmmac: IRQ storm and permanent disablement due to IRQ_NONE return on wakeup
--

commit d1c65d817aaf24471fe20e2504c91eda25ba350f
Author: James Hilliard <james.hilliard1@gmail.com>

net: stmmac: track datapath and power ownership across failed reopening

This patch tracks datapath and power ownership for stmmac interfaces across
failed reopening attempts. It separates core sleep cleanup from platform
and clock restoration, adding guards to skip accessing unpowered MMIO
registers via a hw_unavailable flag.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index c4ba97d57b47e..22a65c1c16810 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
[ ... ]
> @@ -6377,6 +6571,12 @@ static irqreturn_t stmmac_interrupt(int irq, void *dev_id)
>  	struct net_device *dev = (struct net_device *)dev_id;
>  	struct stmmac_priv *priv = netdev_priv(dev);
>  
> +	if (READ_ONCE(priv->hw_unavailable)) {
> +		if (priv->irq_wake)
> +			pm_wakeup_event(priv->device, 0);
> +		return IRQ_NONE;
> +	}
> +
>  	/* Check if adapter is up */
>  	if (test_bit(STMMAC_DOWN, &priv->state))
>  		return IRQ_HANDLED;

[Severity: High]
When the device is suspended with Wake-on-LAN enabled, will returning
IRQ_NONE here cause an interrupt storm?

If a magic packet wakes the system, it asserts the MAC's level-triggered
interrupt line. During the resume_noirq phase, the generic IRQ subsystem
unmasks the interrupt line and this handler is called.

Because hw_unavailable is still true until the later system resume callback
phase, this code returns IRQ_NONE without acknowledging the interrupt at the
MAC hardware or masking the IRQ line. For a level-triggered shared interrupt,
this causes the interrupt controller to immediately re-trigger, creating
an infinite IRQ storm that permanently disables the IRQ line.

[ ... ]
> @@ -6399,6 +6599,12 @@ static irqreturn_t stmmac_mac_interrupt(int irq, void *dev_id)
>  	struct net_device *dev = (struct net_device *)dev_id;
>  	struct stmmac_priv *priv = netdev_priv(dev);
>  
> +	if (READ_ONCE(priv->hw_unavailable)) {
> +		if (priv->irq_wake)
> +			pm_wakeup_event(priv->device, 0);
> +		return IRQ_NONE;
> +	}
> +
>  	/* Check if adapter is up */
>  	if (test_bit(STMMAC_DOWN, &priv->state))
>  		return IRQ_HANDLED;

[Severity: High]
Does this dedicated MAC interrupt handler suffer from the same IRQ storm
issue as stmmac_interrupt above when returning IRQ_NONE during a wakeup
event?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260926-submit-stmmac-reset-fixes-v1-v4-0-ec1c0250b3c9@gmail.com?part=9