[PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[Russell King (Oracle)]

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.

Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
For Laurent to add to a patch series appropriately adding
STMMAC_FLAG_EEE_DISABLE to dwmac-imx.c

 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++++++-
 include/linux/stmmac.h                            | 9 +++++----
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 6cacedb2c9b3..ca0eee58a8a8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1324,7 +1324,12 @@ static int stmmac_phylink_setup(struct stmmac_priv *priv)
 				 config->supported_interfaces,
 				 pcs->supported_interfaces);
 
-	if (priv->dma_cap.eee) {
+	/* Some platforms, e.g. iMX8MP, wire lpi_intr_o to the same interrupt
+	 * used for stmmac's main interrupts, which leads to interrupt storms.
+	 * STMMAC_FLAG_EEE_DISABLE allows EEE to be disabled on such platforms.
+	 */
+	if (priv->dma_cap.eee &&
+	    !(priv->plat->flags & STMMAC_FLAG_EEE_DISABLE)) {
 		/* Assume all supported interfaces also support LPI */
 		memcpy(config->lpi_interfaces, config->supported_interfaces,
 		       sizeof(config->lpi_interfaces));
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index f1054b9c2d8a..5ed49d5363ee 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -187,10 +187,11 @@ enum dwmac_core_type {
 #define STMMAC_FLAG_MULTI_MSI_EN		BIT(7)
 #define STMMAC_FLAG_EXT_SNAPSHOT_EN		BIT(8)
 #define STMMAC_FLAG_INT_SNAPSHOT_EN		BIT(9)
-#define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI		BIT(10)
-#define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING	BIT(11)
-#define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP	BIT(12)
-#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY	BIT(13)
+#define STMMAC_FLAG_EEE_DISABLE			BIT(10)
+#define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI		BIT(11)
+#define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING	BIT(12)
+#define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP	BIT(13)
+#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY	BIT(14)
 
 struct mac_device_info;
 
-- 
2.47.3

Re: [PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[Ovidiu Panait]

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.

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.

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.

Thanks,
Ovidiu


> Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Link: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> For Laurent to add to a patch series appropriately adding
> STMMAC_FLAG_EEE_DISABLE to dwmac-imx.c
> 
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++++++-
>  include/linux/stmmac.h                            | 9 +++++----
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 6cacedb2c9b3..ca0eee58a8a8 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1324,7 +1324,12 @@ static int stmmac_phylink_setup(struct stmmac_priv *priv)
>  				 config->supported_interfaces,
>  				 pcs->supported_interfaces);
>  
> -	if (priv->dma_cap.eee) {
> +	/* Some platforms, e.g. iMX8MP, wire lpi_intr_o to the same interrupt
> +	 * used for stmmac's main interrupts, which leads to interrupt storms.
> +	 * STMMAC_FLAG_EEE_DISABLE allows EEE to be disabled on such platforms.
> +	 */
> +	if (priv->dma_cap.eee &&
> +	    !(priv->plat->flags & STMMAC_FLAG_EEE_DISABLE)) {
>  		/* Assume all supported interfaces also support LPI */
>  		memcpy(config->lpi_interfaces, config->supported_interfaces,
>  		       sizeof(config->lpi_interfaces));
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index f1054b9c2d8a..5ed49d5363ee 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -187,10 +187,11 @@ enum dwmac_core_type {
>  #define STMMAC_FLAG_MULTI_MSI_EN		BIT(7)
>  #define STMMAC_FLAG_EXT_SNAPSHOT_EN		BIT(8)
>  #define STMMAC_FLAG_INT_SNAPSHOT_EN		BIT(9)
> -#define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI		BIT(10)
> -#define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING	BIT(11)
> -#define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP	BIT(12)
> -#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY	BIT(13)
> +#define STMMAC_FLAG_EEE_DISABLE			BIT(10)
> +#define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI		BIT(11)
> +#define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING	BIT(12)
> +#define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP	BIT(13)
> +#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY	BIT(14)
>  
>  struct mac_device_info;
>  

Re: [PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[Russell King (Oracle)]

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@armlinux.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@armlinux.org.uk>
---
 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;
-- 
2.47.3

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[Russell King (Oracle)]

On Mon, Feb 02, 2026 at 10:23:45PM +0000, Russell King (Oracle) wrote:
> On Mon, Feb 02, 2026 at 08:54:52PM +0200, Ovidiu Panait wrote:
> > 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.

I'll also state that we need both patches, but there's no point pushing
my original patch (to allow EEE to be disabled) unless Laurent is going
to also submit a patch to make use of the flag - the EEE disable and
Laurent's patch needs to be part of a series. We don't merge stuff that
adds facilities that have no users, because that's been proven time and
time again to be a recipe for accumulating cruft.

So, at the moment, "net: stmmac: provide flag to disable EEE" ain't
going anywhere until there's a patch that makes use of the new flag.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[Laurent Pinchart]

Hi Russell,

On Tue, Feb 03, 2026 at 12:17:06AM +0000, Russell King (Oracle) wrote:
> On Mon, Feb 02, 2026 at 10:23:45PM +0000, Russell King (Oracle) wrote:
> > On Mon, Feb 02, 2026 at 08:54:52PM +0200, Ovidiu Panait wrote:
> > > 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.
> 
> I'll also state that we need both patches, but there's no point pushing
> my original patch (to allow EEE to be disabled) unless Laurent is going
> to also submit a patch to make use of the flag - the EEE disable and
> Laurent's patch needs to be part of a series. We don't merge stuff that
> adds facilities that have no users, because that's been proven time and
> time again to be a recipe for accumulating cruft.

Sorry for having dropped the ball on this. Your patch arrived just when
I travelled to Japan for a month, and then it got burried in my inbox.
Now that it has resurfaced, and that an issue that prevented i.MX8MP
from booting with v6.19-rc has been fixed, I'll rebase my kernel and
finally fix that problem.

Once again, thank you for all your help with this issue, you have been
extremely helpful and I'm very grateful.

> So, at the moment, "net: stmmac: provide flag to disable EEE" ain't
> going anywhere until there's a patch that makes use of the new flag.

-- 
Regards,

Laurent Pinchart

Re: [PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[Laurent Pinchart]

On Wed, Feb 04, 2026 at 01:18:33AM +0200, Laurent Pinchart wrote:
> On Tue, Feb 03, 2026 at 12:17:06AM +0000, Russell King (Oracle) wrote:
> > On Mon, Feb 02, 2026 at 10:23:45PM +0000, Russell King (Oracle) wrote:
> > > On Mon, Feb 02, 2026 at 08:54:52PM +0200, Ovidiu Panait wrote:
> > > > 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.
> > 
> > I'll also state that we need both patches, but there's no point pushing
> > my original patch (to allow EEE to be disabled) unless Laurent is going
> > to also submit a patch to make use of the flag - the EEE disable and
> > Laurent's patch needs to be part of a series. We don't merge stuff that
> > adds facilities that have no users, because that's been proven time and
> > time again to be a recipe for accumulating cruft.
> 
> Sorry for having dropped the ball on this. Your patch arrived just when
> I travelled to Japan for a month, and then it got burried in my inbox.
> Now that it has resurfaced, and that an issue that prevented i.MX8MP
> from booting with v6.19-rc has been fixed, I'll rebase my kernel and
> finally fix that problem.

Done. https://lore.kernel.org/r/20260208232931.2272237-1-laurent.pinchart@ideasonboard.com

> Once again, thank you for all your help with this issue, you have been
> extremely helpful and I'm very grateful.
> 
> > So, at the moment, "net: stmmac: provide flag to disable EEE" ain't
> > going anywhere until there's a patch that makes use of the new flag.

-- 
Regards,

Laurent Pinchart

Re: [PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[Ovidiu Panait]

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@armlinux.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@armlinux.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@renesas.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;

Re: [PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[Russell King (Oracle)]

On Tue, Feb 03, 2026 at 05:42:07PM +0200, Ovidiu Panait wrote:
> 
> 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@armlinux.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@armlinux.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@renesas.com>

Would you say this is a regression or a new problem?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[Ovidiu Panait]

On 2/3/26 5:43 PM, Russell King (Oracle) wrote:
> On Tue, Feb 03, 2026 at 05:42:07PM +0200, Ovidiu Panait wrote:
>>
>> 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@armlinux.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@armlinux.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@renesas.com>
> 
> Would you say this is a regression or a new problem?

I don't think it is a regression per se. AFAICT this behavior was always
present as long as EEE is enabled, but I only noticed it after I changed
the network switch the board was connected to.

Thanks,
Ovidiu

Re: [PATCH RFC net-next] net: stmmac: provide flag to disable EEE

[Russell King (Oracle)]

On Tue, Feb 03, 2026 at 06:28:45PM +0200, Ovidiu Panait wrote:
> >> 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@renesas.com>
> > 
> > Would you say this is a regression or a new problem?
> 
> I don't think it is a regression per se. AFAICT this behavior was always
> present as long as EEE is enabled, but I only noticed it after I changed
> the network switch the board was connected to.

Thanks, I've just sent the patch for net-next, as you would have seen.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!