[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 at 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 at 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