[PATCH v3 0/2] net: stmmac: Disable EEE on i.MX

[PATCH v3 0/2] net: stmmac: Disable EEE on i.MX

[Laurent Pinchart]

Hello,

This small patch series fixes a long-standing interrupt storm issue with
stmmac on NXP i.MX platforms.

The initial attempt to fix^Wwork around the problem in DT ([1]) was
painfully but rightfully rejected by Russell, who helped me investigate
the issue in depth. It turned out that the root cause is a mistake in
how interrupts are wired in the SoC, a hardware bug that has been
replicated in all i.MX SoCs that integrate an stmmac. The only viable
solution is to disable EEE on those devices.

Individual patches explain the issue in more details. Patch 1/2,
authored by Russell, adds a new STMMAC_FLAG to disable EEE, and patch
2/2 sets the flag for i.MX platforms.

[1] https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com

Laurent Pinchart (1):
  net: stmmac: imx: Disable EEE

Russell King (Oracle) (1):
  net: stmmac: provide flag to disable EEE

 drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c   |  9 +++------
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |  7 ++++++-
 include/linux/stmmac.h                            | 11 ++++++-----
 3 files changed, 15 insertions(+), 12 deletions(-)


base-commit: fb78a629b4f0eb399b413f6c093a3da177b3a4eb
-- 
Regards,

Laurent Pinchart

[PATCH v3 1/2] net: stmmac: provide flag to disable EEE

[Laurent Pinchart]

From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>

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>
Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |  7 ++++++-
 include/linux/stmmac.h                            | 11 ++++++-----
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 5062537f79e9..7f7682a5fbe4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1445,7 +1445,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)) {
 		/* The GMAC 3.74a databook states that EEE is only supported
 		 * in MII, GMII, and RGMII interfaces.
 		 */
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 72febd246bdb..435a890a3b2e 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -208,11 +208,12 @@ 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_KEEP_PREAMBLE_BEFORE_SFD	BIT(14)
+#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)
+#define STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD	BIT(15)
 
 struct mac_device_info;
 
-- 
Regards,

Laurent Pinchart

[PATCH v3 2/2] net: stmmac: imx: Disable EEE

[Laurent Pinchart]

The i.MX8MP suffers from an interrupt storm related to the stmmac and
EEE. A long and tedious analysis ([1]) concluded that the SoC wires the
stmmac lpi_intr_o signal to an OR gate along with the main dwmac
interrupts, which causes an interrupt storm for two reasons.

First, there's a race condition due to the interrupt deassertion being
synchronous to the RX clock domain:

- When the PHY exits LPI mode, it restarts generating the RX clock
  (clk_rx_i input signal to the GMAC).
- The MAC detects exit from LPI, and asserts lpi_intr_o. This triggers
  the ENET_EQOS interrupt.
- Before the CPU has time to process the interrupt, the PHY enters LPI
  mode again, and stops generating the RX clock.
- The CPU processes the interrupt and reads the GMAC4_LPI_CTRL_STATUS
  registers. This does not clear lpi_intr_o as there's no clk_rx_i.

An attempt was made to fixing the issue by not stopping RX_CLK in Rx LPI
state ([2]). This alleviates the symptoms but doesn't fix the issue.
Since lpi_intr_o takes four RX_CLK cycles to clear, an interrupt storm
can still occur during that window. In 1000T mode this is harder to
notice, but slower receive clocks cause hundreds to thousands of
spurious interrupts.

Fix the issue by disabling EEE completely on i.MX8MP.

[1] https://lore.kernel.org/all/20251026122905.29028-1-laurent.pinchart@ideasonboard.com/
[2] https://lore.kernel.org/all/20251123053518.8478-1-laurent.pinchart@ideasonboard.com/

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Changes since v1:

- Fix | operator placement
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
index 9d1bd72ffb73..01260dbbb698 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
@@ -325,11 +325,7 @@ static int imx_dwmac_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	if (data->flags & STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY)
-		plat_dat->flags |= STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY;
-
-	if (data->flags & STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD)
-		plat_dat->flags |= STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD;
+	plat_dat->flags |= data->flags;
 
 	/* Default TX Q0 to use TSO and rest TXQ for TBS */
 	for (int i = 1; i < plat_dat->tx_queues_to_use; i++)
@@ -366,7 +362,8 @@ static struct imx_dwmac_ops imx8mp_dwmac_data = {
 	.addr_width = 34,
 	.mac_rgmii_txclk_auto_adj = false,
 	.set_intf_mode = imx8mp_set_intf_mode,
-	.flags = STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
+	.flags = STMMAC_FLAG_EEE_DISABLE |
+		 STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY |
 		 STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD,
 };
 
-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 2/2] net: stmmac: imx: Disable EEE

[Russell King (Oracle)]

On Mon, Mar 23, 2026 at 11:39:33AM +0200, Laurent Pinchart wrote:
> The i.MX8MP suffers from an interrupt storm related to the stmmac and
> EEE. A long and tedious analysis ([1]) concluded that the SoC wires the
> stmmac lpi_intr_o signal to an OR gate along with the main dwmac
> interrupts, which causes an interrupt storm for two reasons.
> 
> First, there's a race condition due to the interrupt deassertion being
> synchronous to the RX clock domain:
> 
> - When the PHY exits LPI mode, it restarts generating the RX clock
>   (clk_rx_i input signal to the GMAC).
> - The MAC detects exit from LPI, and asserts lpi_intr_o. This triggers
>   the ENET_EQOS interrupt.
> - Before the CPU has time to process the interrupt, the PHY enters LPI
>   mode again, and stops generating the RX clock.
> - The CPU processes the interrupt and reads the GMAC4_LPI_CTRL_STATUS
>   registers. This does not clear lpi_intr_o as there's no clk_rx_i.
> 
> An attempt was made to fixing the issue by not stopping RX_CLK in Rx LPI
> state ([2]). This alleviates the symptoms but doesn't fix the issue.
> Since lpi_intr_o takes four RX_CLK cycles to clear, an interrupt storm
> can still occur during that window. In 1000T mode this is harder to
> notice, but slower receive clocks cause hundreds to thousands of
> spurious interrupts.
> 
> Fix the issue by disabling EEE completely on i.MX8MP.
> 
> [1] https://lore.kernel.org/all/20251026122905.29028-1-laurent.pinchart@ideasonboard.com/
> [2] https://lore.kernel.org/all/20251123053518.8478-1-laurent.pinchart@ideasonboard.com/
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Thanks!

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

Re: [PATCH v3 1/2] net: stmmac: provide flag to disable EEE

[Russell King (Oracle)]

On Mon, Mar 23, 2026 at 11:39:32AM +0200, Laurent Pinchart wrote:
> From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
> 
> 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>
> Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

As you are sending this on my behalf, you need to add your s-o-b after
mine:

 Any further SoBs (Signed-off-by:'s) following the author's SoB are from
 people handling and transporting the patch, but were not involved in its
 development. SoB chains should reflect the **real** route a patch took
 as it was propagated to the maintainers and ultimately to Linus, with
 the first SoB entry signalling primary authorship of a single author.

Thanks.

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

Re: [PATCH v3 1/2] net: stmmac: provide flag to disable EEE

[Laurent Pinchart]

On Mon, Mar 23, 2026 at 09:55:36AM +0000, Russell King (Oracle) wrote:
> On Mon, Mar 23, 2026 at 11:39:32AM +0200, Laurent Pinchart wrote:
> > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
> > 
> > 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>
> > Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> 
> As you are sending this on my behalf, you need to add your s-o-b after
> mine:

Oops, I'm not sure how I missed that. Sorry.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

>  Any further SoBs (Signed-off-by:'s) following the author's SoB are from
>  people handling and transporting the patch, but were not involved in its
>  development. SoB chains should reflect the **real** route a patch took
>  as it was propagated to the maintainers and ultimately to Linus, with
>  the first SoB entry signalling primary authorship of a single author.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 1/2] net: stmmac: provide flag to disable EEE

[Laurent Pinchart]

On Mon, Mar 23, 2026 at 12:08:02PM +0200, Laurent Pinchart wrote:
> On Mon, Mar 23, 2026 at 09:55:36AM +0000, Russell King (Oracle) wrote:
> > On Mon, Mar 23, 2026 at 11:39:32AM +0200, Laurent Pinchart wrote:
> > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
> > > 
> > > 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>
> > > Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > 
> > As you are sending this on my behalf, you need to add your s-o-b after
> > mine:
> 
> Oops, I'm not sure how I missed that. Sorry.
> 
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

Should I submit a v4, or can this series be picked for v7.1 with my SoB
added ?

> >  Any further SoBs (Signed-off-by:'s) following the author's SoB are from
> >  people handling and transporting the patch, but were not involved in its
> >  development. SoB chains should reflect the **real** route a patch took
> >  as it was propagated to the maintainers and ultimately to Linus, with
> >  the first SoB entry signalling primary authorship of a single author.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 1/2] net: stmmac: provide flag to disable EEE

[Russell King (Oracle)]

On Wed, Mar 25, 2026 at 10:13:32PM +0200, Laurent Pinchart wrote:
> On Mon, Mar 23, 2026 at 12:08:02PM +0200, Laurent Pinchart wrote:
> > On Mon, Mar 23, 2026 at 09:55:36AM +0000, Russell King (Oracle) wrote:
> > > On Mon, Mar 23, 2026 at 11:39:32AM +0200, Laurent Pinchart wrote:
> > > > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
> > > > 
> > > > 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>
> > > > Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
> > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > > 
> > > As you are sending this on my behalf, you need to add your s-o-b after
> > > mine:
> > 
> > Oops, I'm not sure how I missed that. Sorry.
> > 
> > Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Should I submit a v4, or can this series be picked for v7.1 with my SoB
> added ?

I don't see it in patchwork's pending queue, so yes please. Don't forget
to specify the tree in the subject line:

[PATCH net-next v4 0/2] net: stmmac: ...

which may be a factor in it not showing up.

It's worth keeping an eye on:

https://patchwork.kernel.org/project/netdevbpf/list/?delegate=123371

about 24h after submission in case of any issues.

Thanks.

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