[PATCH] net: stmmac: imx: Disable EEE

[PATCH] 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>
---
This patch depends on https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
index db288fbd5a4d..e8e6f325d92d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
@@ -317,8 +317,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;
+	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++)
@@ -355,7 +354,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_HWTSTAMP_CORRECT_LATENCY
+	       | STMMAC_FLAG_EEE_DISABLE,
 };
 
 static struct imx_dwmac_ops imx8dxl_dwmac_data = {

base-commit: 18f7fcd5e69a04df57b563360b88be72471d6b62
prerequisite-patch-id: a3c3f8b08fd66ee3ccce632aad3f4a3c21c92718
-- 
Regards,

Laurent Pinchart

Re: [PATCH] net: stmmac: imx: Disable EEE

[Russell King (Oracle)]

On Mon, Feb 09, 2026 at 01:29:31AM +0200, Laurent Pinchart wrote:
...
> 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>
> ---
> This patch depends on https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com

Are you sure? That's the one adding the DT property, not my patch that
adds the flag you need for this.

> @@ -355,7 +354,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_HWTSTAMP_CORRECT_LATENCY
> +	       | STMMAC_FLAG_EEE_DISABLE,

I thought we had a coding style comment about wrapping like this
(operators should be trailing on the previous line, not at the
beginning of the following line) but I can find nothing in
Documentation/process/coding-style.rst  Confused. Maybe it's
somewhere else in the re-organised documentation.

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] net: stmmac: imx: Disable EEE

[Laurent Pinchart]

On Mon, Feb 09, 2026 at 01:12:25PM +0000, Russell King (Oracle) wrote:
> On Mon, Feb 09, 2026 at 01:29:31AM +0200, Laurent Pinchart wrote:
> ...
> > 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>
> > ---
> > This patch depends on https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
> 
> Are you sure? That's the one adding the DT property, not my patch that
> adds the flag you need for this.

Oops, wrong link. I meant

https://lore.kernel.org/all/E1vNUjC-0000000FhjR-0h6P@rmk-PC.armlinux.org.uk/

> > @@ -355,7 +354,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_HWTSTAMP_CORRECT_LATENCY
> > +	       | STMMAC_FLAG_EEE_DISABLE,
> 
> I thought we had a coding style comment about wrapping like this
> (operators should be trailing on the previous line, not at the
> beginning of the following line) but I can find nothing in
> Documentation/process/coding-style.rst  Confused. Maybe it's
> somewhere else in the re-organised documentation.

I'll move it at the end of the line, no problem. It's one of those
pieces of coding style where different driver authors and subsystems
have different opinion so I'm never quite sure what to do when
submitting patches for areas of the kernel I don't usually touch. I
should have looked at the rest of the file, sorry about missing it.

-- 
Regards,

Laurent Pinchart