[PATCH] arm64: dts: imx8mp-debix-model-a: Disable EEE for 1000T

[Russell King (Oracle)]

On Sun, Nov 23, 2025 at 02:38:02PM +0900, Laurent Pinchart wrote:
> Hi Russell,
> 
> On Sat, Nov 22, 2025 at 09:57:49AM +0000, Russell King (Oracle) wrote:
> > On Sat, Nov 22, 2025 at 04:22:46PM +0900, Laurent Pinchart wrote:
> > > Hello Wei,
> > > 
> > > On Tue, Nov 18, 2025 at 01:50:55AM +0000, Wei Fang wrote:
> > > > Sorry, I only have a little experience with DWMac, add Clark to help look
> > > > at this issue.
> > > 
> > > Thank you.
> > > 
> > > I think we're getting close to having a good understanding of the
> > > problem. I've debugged it as far as I could based on the information
> > > available publicly. Let's try to get to the bottom of this issue, it
> > > impacts quite a lot of people and it would be very nice to fix it
> > > properly in mainline.
> > > 
> > > The short summary is that I'm experiencing an interrupt storm on IRQ 135
> > > when EEE is enabled with the EQOS interface.
> > > 
> > > My current theory is that
> > > 
> > > - The lpi_intr_o signal of the EQOS is OR'ed into IRQ 135.
> > > - The issue is triggerted by the PHY exiting LPI mode
> > > - When it exits LPI mode, the PHY restarts generating the RX clock
> > >   (clk_rx_i).
> > > - The MAC detects exit from LPI, and asserts lpi_intr_o.
> > > - 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.
> > 
> > Please try setting STMMAC_FLAG_RX_CLK_RUNS_IN_LPI in dwmac-imx.c and
> > see whether that changes the behaviour.
> 
> I have tested that and it worked like a charm ! I have submitted
> https://lore.kernel.org/r/20251123053518.8478-1-laurent.pinchart@ideasonboard.com
> 
> That was quite an adventure. Thank you so much for all your support, I'm
> not sure I would have managed without you (or at least I would have
> needed way more time). I really really appreciate it.
> 
> If the above patch gets accepted, we will probably be able to remove the
> eee-broken-* properties from the i.MX8MP device tree files (and possibly
> from i.MX8DXL and i.MX93 as well). I have mentioned that below the
> commit message of the patch, with a test procedure as it should be
> tested on each board.

As stated in reply to that patch, while this may reduce the severity of
the storm, I don't think it'll completely eliminate it.

I made the suggestion to set the flag as a test to confirm whether the
lpi_intr_o is indeed the problem by ensuring that the receive domain is
always clocked, and thus ensuring that the signal clears within four
clock cycles, rather than an indefinite period should the remote end
re-enter LPI mode quicky.

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