Message-ID: <ea2434e6-d1db-4ea2-90f4-0a77961b7918@gmail.com>
Date: Tue, 3 Feb 2026 17:42:07 +0200
From: Ovidiu Panait <ovidiu.panait.oss@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Alexandre Torgue <alexandre.torgue@...s.st.com>,
 Andrew Lunn <andrew@...n.ch>, Andrew Lunn <andrew+netdev@...n.ch>,
 Clark Wang <xiaoning.wang@....com>,
 Daniel Scally <dan.scally@...asonboard.com>,
 "David S. Miller" <davem@...emloft.net>,
 Emanuele Ghidoli <ghidoliemanuele@...il.com>,
 Eric Dumazet <edumazet@...gle.com>, Fabio Estevam <festevam@...il.com>,
 Heiner Kallweit <hkallweit1@...il.com>, imx@...ts.linux.dev,
 Jakub Kicinski <kuba@...nel.org>,
 Kieran Bingham <kieran.bingham@...asonboard.com>,
 linux-arm-kernel@...ts.infradead.org,
 linux-stm32@...md-mailman.stormreply.com,
 Maxime Coquelin <mcoquelin.stm32@...il.com>, netdev@...r.kernel.org,
 Oleksij Rempel <o.rempel@...gutronix.de>, Paolo Abeni <pabeni@...hat.com>,
 Pengutronix Kernel Team <kernel@...gutronix.de>,
 Rob Herring <robh@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>,
 Shawn Guo <shawnguo@...nel.org>, Stefan Klug <stefan.klug@...asonboard.com>,
 Wei Fang <wei.fang@....com>,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>
Subject: Re: [PATCH RFC net-next] net: stmmac: provide flag to disable EEE


Hi Russell,

On 2/3/26 12:23 AM, Russell King (Oracle) wrote:
> On Mon, Feb 02, 2026 at 08:54:52PM +0200, Ovidiu Panait wrote:
>>
>> Hi Russell,
>>
>> On 11/24/25 1:27 PM, Russell King (Oracle) wrote:
>>> Some platforms have problems when EEE is enabled, and thus need a way
>>> to disable stmmac EEE support. Add a flag before the other LPI related
>>> flags which tells stmmac to avoid populating the phylink LPI
>>> capabilities, which causes phylink to call phy_disable_eee() for any
>>> PHY that is attached to the affected phylink instance.
>>>
>>> iMX8MP is an example - the lpi_intr_o signal is wired to an OR gate
>>> along with the main dwmac interrupts. Since lpi_intr_o is synchronous
>>> to the receive clock domain, and takes four clock cycles to clear, this
>>> leads to interrupt storms as the interrupt remains asserted for some
>>> time after the LPI control and status register is read.
>>>
>>> This problem becomes worse when the receive clock from the PHY stops
>>> when the receive path enters LPI state - which means that lpi_intr_o
>>> can not deassert until the clock restarts. Since the LPI state of the
>>> receive path depends on the link partner, this is out of our control.
>>> We could disable RX clock stop at the PHY, but that doesn't get around
>>> the slow-to-deassert lpi_intr_o mentioned in the above paragraph.
>>>
>>> Previously, iMX8MP worked around this by disabling gigabit EEE, but
>>> this is insufficient - the problem is also visible at 100M speeds,
>>> where the receive clock is slower.
>>>
>>> There is extensive discussion and investigation in the thread linked
>>> below, the result of which is summarised in this commit message.
>>>
>>
>> We are seeing the same lpi_intr_o interrupt storm on the Renesas RZ/V2H
>> EVK (dwmac-renesas-gbeth.c). On this platform, lpi_intr_o is routed as a
>> separate, dedicated interrupt line to the CPU rather than being OR'd
>> with the main DWMAC interrupt as on iMX8MP. This corresponds to the
>> "eth_lpi" interrupt in the stmmac bindings:
>> """
>> - description: The interrupt that occurs when Rx exits the LPI state
>> const: eth_lpi
>> """
>>
>> Looking through the other glue drivers/device-trees, it looks to me that
>> every platform that defines a separate "eth_lpi" irq might have the
>> interrupt storm problem.
> 
> That is highly likely.
> 
>> To fix this issue on these platforms, rather than disabling EEE
>> altogether, would it be possible to just not request the eth_lpi
>> interrupt and let EEE continue to work? Perhaps a new flag could let
>> each platform decide.
> 
> Yes, because lpi_intr_o serves no purpose from a software point of
> view - see the commit message below for the details. I do like
> removing code from stmmac :)
> 
>> If not, maybe this patch could be merged to add the flag that disables
>> EEE and I will just send a patch to disable EEE on our platforms as well.
> 
> We still need the flag to disable EEE for platforms where lpi_intr_o is
> logically OR'd with the other interrupts, so there's no way to ignore
> its persistent assertion.
> 
> 8<===
> From: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>
> Subject: [PATCH net-next] net: stmmac: remove support for lpi_intr_o
> 
> The dwmac databook for v3.74a states that lpi_intr_o is a sideband
> signal which should be used to ungate the application clock, and this
> signal is synchronous to the receive clock. The receive clock can run
> at 2.5, 25 or 125MHz depending on the media speed, and can stop under
> the control of the link partner. This means that the time it takes to
> clear is dependent on the negotiated media speed, and thus can be 8,
> 40, or 400ns after reading the LPI control and status register.
> 
> It has been observed with some aggressive link partners, this clock
> can stop while lpi_intr_o is still asserted, meaning that the signal
> remains asserted for an indefinite period that the local system has
> no direct control over.
> 
> The LPI interrupts will still be signalled through the main interrupt
> path in any case, and this path is not dependent on the receive clock.
> 
> This, since we do not gate the application clock, and the chances of
> adding clock gating in the future are slim due to the clocks being
> ill-defined, lpi_intr_o serves no useful purpose. Remove the code which
> requests the interrupt, and all associated code.
> 
> Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>

Thanks for fixing this. I did some testing on the Renesas RZ/V2H board
with this patch and didn't see any issues:

Tested-by: Ovidiu Panait <ovidiu.panait.rb@...esas.com>

Ovidiu

> ---
>  drivers/net/ethernet/stmicro/stmmac/common.h  |  1 -
>  .../net/ethernet/stmicro/stmmac/dwmac-intel.c |  4 ---
>  .../ethernet/stmicro/stmmac/dwmac-loongson.c  |  7 ----
>  drivers/net/ethernet/stmicro/stmmac/stmmac.h  |  2 --
>  .../net/ethernet/stmicro/stmmac/stmmac_main.c | 36 -------------------
>  .../ethernet/stmicro/stmmac/stmmac_platform.c |  8 -----
>  include/linux/stmmac.h                        |  1 -
>  7 files changed, 59 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h b/drivers/net/ethernet/stmicro/stmmac/common.h
> index 1c5a4af85b58..d26e8a063022 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
> @@ -394,7 +394,6 @@ enum request_irq_err {
>  	REQ_IRQ_ERR_SFTY,
>  	REQ_IRQ_ERR_SFTY_UE,
>  	REQ_IRQ_ERR_SFTY_CE,
> -	REQ_IRQ_ERR_LPI,
>  	REQ_IRQ_ERR_WOL,
>  	REQ_IRQ_ERR_MAC,
>  	REQ_IRQ_ERR_NO,
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> index aad1be1ec4c1..92d77b0c2f54 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
> @@ -719,7 +719,6 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
>  
>  	/* Setup MSI vector offset specific to Intel mGbE controller */
>  	plat->msi_mac_vec = 29;
> -	plat->msi_lpi_vec = 28;
>  	plat->msi_sfty_ce_vec = 27;
>  	plat->msi_sfty_ue_vec = 26;
>  	plat->msi_rx_base_vec = 0;
> @@ -1177,8 +1176,6 @@ static int stmmac_config_multi_msi(struct pci_dev *pdev,
>  		res->irq = pci_irq_vector(pdev, plat->msi_mac_vec);
>  	if (plat->msi_wol_vec < STMMAC_MSI_VEC_MAX)
>  		res->wol_irq = pci_irq_vector(pdev, plat->msi_wol_vec);
> -	if (plat->msi_lpi_vec < STMMAC_MSI_VEC_MAX)
> -		res->lpi_irq = pci_irq_vector(pdev, plat->msi_lpi_vec);
>  	if (plat->msi_sfty_ce_vec < STMMAC_MSI_VEC_MAX)
>  		res->sfty_ce_irq = pci_irq_vector(pdev, plat->msi_sfty_ce_vec);
>  	if (plat->msi_sfty_ue_vec < STMMAC_MSI_VEC_MAX)
> @@ -1294,7 +1291,6 @@ static int intel_eth_pci_probe(struct pci_dev *pdev,
>  	 */
>  	plat->msi_mac_vec = STMMAC_MSI_VEC_MAX;
>  	plat->msi_wol_vec = STMMAC_MSI_VEC_MAX;
> -	plat->msi_lpi_vec = STMMAC_MSI_VEC_MAX;
>  	plat->msi_sfty_ce_vec = STMMAC_MSI_VEC_MAX;
>  	plat->msi_sfty_ue_vec = STMMAC_MSI_VEC_MAX;
>  	plat->msi_rx_base_vec = STMMAC_MSI_VEC_MAX;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> index ed0b534d8d7b..d66ae6ea4df5 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c
> @@ -442,13 +442,6 @@ static int loongson_dwmac_dt_config(struct pci_dev *pdev,
>  		res->wol_irq = res->irq;
>  	}
>  
> -	res->lpi_irq = of_irq_get_byname(np, "eth_lpi");
> -	if (res->lpi_irq < 0) {
> -		dev_err(&pdev->dev, "IRQ eth_lpi not found\n");
> -		ret = -ENODEV;
> -		goto err_put_node;
> -	}
> -
>  	ret = device_get_phy_mode(&pdev->dev);
>  	if (ret < 0) {
>  		dev_err(&pdev->dev, "phy_mode not found\n");
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index 012b0a477255..aafd8c39be63 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -31,7 +31,6 @@ struct stmmac_resources {
>  	void __iomem *addr;
>  	u8 mac[ETH_ALEN];
>  	int wol_irq;
> -	int lpi_irq;
>  	int irq;
>  	int sfty_irq;
>  	int sfty_ce_irq;
> @@ -297,7 +296,6 @@ struct stmmac_priv {
>  	int wol_irq;
>  	u32 gmii_address_bus_config;
>  	struct timer_list eee_ctrl_timer;
> -	int lpi_irq;
>  	u32 tx_lpi_timer;
>  	bool tx_lpi_clk_stop;
>  	bool eee_enabled;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 7a451ae19f50..7925575fb348 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -3734,10 +3734,6 @@ static void stmmac_free_irq(struct net_device *dev,
>  			free_irq(priv->sfty_ce_irq, dev);
>  		fallthrough;
>  	case REQ_IRQ_ERR_SFTY_CE:
> -		if (priv->lpi_irq > 0 && priv->lpi_irq != dev->irq)
> -			free_irq(priv->lpi_irq, dev);
> -		fallthrough;
> -	case REQ_IRQ_ERR_LPI:
>  		if (priv->wol_irq > 0 && priv->wol_irq != dev->irq)
>  			free_irq(priv->wol_irq, dev);
>  		fallthrough;
> @@ -3795,24 +3791,6 @@ static int stmmac_request_irq_multi_msi(struct net_device *dev)
>  		}
>  	}
>  
> -	/* Request the LPI IRQ in case of another line
> -	 * is used for LPI
> -	 */
> -	if (priv->lpi_irq > 0 && priv->lpi_irq != dev->irq) {
> -		int_name = priv->int_name_lpi;
> -		sprintf(int_name, "%s:%s", dev->name, "lpi");
> -		ret = request_irq(priv->lpi_irq,
> -				  stmmac_mac_interrupt,
> -				  0, int_name, dev);
> -		if (unlikely(ret < 0)) {
> -			netdev_err(priv->dev,
> -				   "%s: alloc lpi MSI %d (error: %d)\n",
> -				   __func__, priv->lpi_irq, ret);
> -			irq_err = REQ_IRQ_ERR_LPI;
> -			goto irq_error;
> -		}
> -	}
> -
>  	/* Request the common Safety Feature Correctible/Uncorrectible
>  	 * Error line in case of another line is used
>  	 */
> @@ -3952,19 +3930,6 @@ static int stmmac_request_irq_single(struct net_device *dev)
>  		}
>  	}
>  
> -	/* Request the IRQ lines */
> -	if (priv->lpi_irq > 0 && priv->lpi_irq != dev->irq) {
> -		ret = request_irq(priv->lpi_irq, stmmac_interrupt,
> -				  IRQF_SHARED, dev->name, dev);
> -		if (unlikely(ret < 0)) {
> -			netdev_err(priv->dev,
> -				   "%s: ERROR: allocating the LPI IRQ %d (%d)\n",
> -				   __func__, priv->lpi_irq, ret);
> -			irq_err = REQ_IRQ_ERR_LPI;
> -			goto irq_error;
> -		}
> -	}
> -
>  	/* Request the common Safety Feature Correctible/Uncorrectible
>  	 * Error line in case of another line is used
>  	 */
> @@ -7752,7 +7717,6 @@ static int __stmmac_dvr_probe(struct device *device,
>  
>  	priv->dev->irq = res->irq;
>  	priv->wol_irq = res->wol_irq;
> -	priv->lpi_irq = res->lpi_irq;
>  	priv->sfty_irq = res->sfty_irq;
>  	priv->sfty_ce_irq = res->sfty_ce_irq;
>  	priv->sfty_ue_irq = res->sfty_ue_irq;
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 8979a50b5507..5c9fd91a1db9 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -725,14 +725,6 @@ int stmmac_get_platform_resources(struct platform_device *pdev,
>  		stmmac_res->wol_irq = stmmac_res->irq;
>  	}
>  
> -	stmmac_res->lpi_irq =
> -		platform_get_irq_byname_optional(pdev, "eth_lpi");
> -	if (stmmac_res->lpi_irq < 0) {
> -		if (stmmac_res->lpi_irq == -EPROBE_DEFER)
> -			return -EPROBE_DEFER;
> -		dev_info(&pdev->dev, "IRQ eth_lpi not found\n");
> -	}
> -
>  	stmmac_res->sfty_irq =
>  		platform_get_irq_byname_optional(pdev, "sfty");
>  	if (stmmac_res->sfty_irq < 0) {
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index 5199451dd0bc..2620f0217f88 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -300,7 +300,6 @@ struct plat_stmmacenet_data {
>  	int int_snapshot_num;
>  	int msi_mac_vec;
>  	int msi_wol_vec;
> -	int msi_lpi_vec;
>  	int msi_sfty_ce_vec;
>  	int msi_sfty_ue_vec;
>  	int msi_rx_base_vec;

Powered by blists - more mailing lists