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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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