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

[PATCH v2] 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/all/E1vNUjC-0000000FhjR-0h6P@rmk-PC.armlinux.org.uk/
---
Changes since v1:

- Fix | operator placement
---
 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..56979849409d 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: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
prerequisite-patch-id: 9229185bf29c206923075a0450e763664af050bb
prerequisite-patch-id: e17c3f8a7cb2b18fc0c3c6250773a9680bdabdba
prerequisite-patch-id: a3c3f8b08fd66ee3ccce632aad3f4a3c21c92718
-- 
Regards,

Laurent Pinchart

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

[Russell King (Oracle)]

On Mon, Feb 09, 2026 at 10:21:55PM +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>
> ---
> This patch depends on https://lore.kernel.org/all/E1vNUjC-0000000FhjR-0h6P@rmk-PC.armlinux.org.uk/

... and a few other patches as well. There is also a conflicting change
in net-next:

commit dc6597fab3e3d291da9e0b4c6f7da01a5a863e80
Author: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Date:   Tue Jan 20 21:30:04 2026 +0100

    net: stmmac: dwmac-imx: keep preamble before sfd on i.MX8MP

> base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b

This is v6.19

> prerequisite-patch-id: 9229185bf29c206923075a0450e763664af050bb
> prerequisite-patch-id: e17c3f8a7cb2b18fc0c3c6250773a9680bdabdba
> prerequisite-patch-id: a3c3f8b08fd66ee3ccce632aad3f4a3c21c92718

I have no idea what these are. These don't exist in Linus', net, nor
net-next trees. I'm not sure what generates these, but they are useless
unless they also indicate the summary line for the commit in question,
so that one can have some clue what change they're referring to.

While this is a fix, I think you previously suggested that this isn't
a regression, which suggests it should be merged in net-next (currently
closed due to the merge window) rather than net.

Also, referring to another patch doesn't get it applied - netdev
workflow uses patchwork, and patches to be applied need to be there.
If patches depend on each other, they need to be submitted as a
series. So either I need to pick up your patch and send it along
with mine, or you need to pick up my patch and send it with yours.
We need to come to agreement on who is submitting it.

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

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

[Laurent Pinchart]

On Tue, Feb 10, 2026 at 12:26:12PM +0000, Russell King (Oracle) wrote:
> On Mon, Feb 09, 2026 at 10:21:55PM +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>
> > ---
> > This patch depends on https://lore.kernel.org/all/E1vNUjC-0000000FhjR-0h6P@rmk-PC.armlinux.org.uk/
> 
> ... and a few other patches as well. There is also a conflicting change
> in net-next:
> 
> commit dc6597fab3e3d291da9e0b4c6f7da01a5a863e80
> Author: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> Date:   Tue Jan 20 21:30:04 2026 +0100
> 
>     net: stmmac: dwmac-imx: keep preamble before sfd on i.MX8MP
> 
> > base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
> 
> This is v6.19
> 
> > prerequisite-patch-id: 9229185bf29c206923075a0450e763664af050bb
> > prerequisite-patch-id: e17c3f8a7cb2b18fc0c3c6250773a9680bdabdba
> > prerequisite-patch-id: a3c3f8b08fd66ee3ccce632aad3f4a3c21c92718
>
> I have no idea what these are. These don't exist in Linus', net, nor
> net-next trees. I'm not sure what generates these, but they are useless
> unless they also indicate the summary line for the commit in question,
> so that one can have some clue what change they're referring to.

The first two are mistakes, I had two unrelated DT changes at the base of my
branch that I needed for testing, and I forgot to rebase before running
git-format-patch. They can be ignored.

The last one is your patch
(https://lore.kernel.org/all/E1vNUjC-0000000FhjR-0h6P@rmk-PC.armlinux.org.uk/).
Note that the value is the patch-id, not the commit ID.

> While this is a fix, I think you previously suggested that this isn't
> a regression, which suggests it should be merged in net-next (currently
> closed due to the merge window) rather than net.

I think I was first notified of the issue more than a year ago, so I
would indeed not count it as a regression. net-next is fine with me.

> Also, referring to another patch doesn't get it applied - netdev
> workflow uses patchwork, and patches to be applied need to be there.
> If patches depend on each other, they need to be submitted as a
> series. So either I need to pick up your patch and send it along
> with mine, or you need to pick up my patch and send it with yours.
> We need to come to agreement on who is submitting it.

I'm happy to submit a series with both, rebased on top of net-next to
handle the conflict you pointed out. Is that fine with you ?

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

On Tue, Feb 10, 2026 at 04:31:59PM +0200, Laurent Pinchart wrote:
> On Tue, Feb 10, 2026 at 12:26:12PM +0000, Russell King (Oracle) wrote:
> > On Mon, Feb 09, 2026 at 10:21:55PM +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>
> > > ---
> > > This patch depends on https://lore.kernel.org/all/E1vNUjC-0000000FhjR-0h6P@rmk-PC.armlinux.org.uk/
> > 
> > ... and a few other patches as well. There is also a conflicting change
> > in net-next:
> > 
> > commit dc6597fab3e3d291da9e0b4c6f7da01a5a863e80
> > Author: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > Date:   Tue Jan 20 21:30:04 2026 +0100
> > 
> >     net: stmmac: dwmac-imx: keep preamble before sfd on i.MX8MP
> > 
> > > base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
> > 
> > This is v6.19
> > 
> > > prerequisite-patch-id: 9229185bf29c206923075a0450e763664af050bb
> > > prerequisite-patch-id: e17c3f8a7cb2b18fc0c3c6250773a9680bdabdba
> > > prerequisite-patch-id: a3c3f8b08fd66ee3ccce632aad3f4a3c21c92718
> >
> > I have no idea what these are. These don't exist in Linus', net, nor
> > net-next trees. I'm not sure what generates these, but they are useless
> > unless they also indicate the summary line for the commit in question,
> > so that one can have some clue what change they're referring to.
> 
> The first two are mistakes, I had two unrelated DT changes at the base of my
> branch that I needed for testing, and I forgot to rebase before running
> git-format-patch. They can be ignored.
> 
> The last one is your patch
> (https://lore.kernel.org/all/E1vNUjC-0000000FhjR-0h6P@rmk-PC.armlinux.org.uk/).
> Note that the value is the patch-id, not the commit ID.
> 
> > While this is a fix, I think you previously suggested that this isn't
> > a regression, which suggests it should be merged in net-next (currently
> > closed due to the merge window) rather than net.
> 
> I think I was first notified of the issue more than a year ago, so I
> would indeed not count it as a regression. net-next is fine with me.
> 
> > Also, referring to another patch doesn't get it applied - netdev
> > workflow uses patchwork, and patches to be applied need to be there.
> > If patches depend on each other, they need to be submitted as a
> > series. So either I need to pick up your patch and send it along
> > with mine, or you need to pick up my patch and send it with yours.
> > We need to come to agreement on who is submitting it.
> 
> I'm happy to submit a series with both, rebased on top of net-next to
> handle the conflict you pointed out. Is that fine with you ?

If you would like me to submit a series with both patches, should I
resolve the conflict with "net: stmmac: dwmac-imx: keep preamble before
sfd on i.MX8MP" by inserting the STMMAC_FLAG_EEE_DISABLE flag as BIT(10)
and change the value of subsequent flags as you did, or add it at the
end (BIT(15)) ?

I'm also happy if you take my patch and submit a series with both.

-- 
Regards,

Laurent Pinchart

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

[Russell King (Oracle)]

On Tue, Feb 10, 2026 at 06:33:10PM +0200, Laurent Pinchart wrote:
> > I'm happy to submit a series with both, rebased on top of net-next to
> > handle the conflict you pointed out. Is that fine with you ?
> 
> If you would like me to submit a series with both patches, should I
> resolve the conflict with "net: stmmac: dwmac-imx: keep preamble before
> sfd on i.MX8MP" by inserting the STMMAC_FLAG_EEE_DISABLE flag as BIT(10)
> and change the value of subsequent flags as you did, or add it at the
> end (BIT(15)) ?

I would prefer to keep similar flags together rather than just appending
to the end of the list.

> I'm also happy if you take my patch and submit a series with both.

I think it would make sense if you submit it once net-next reopens after
the merge window.

Thanks.

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