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

[Laurent Pinchart]

Hi Oleksij,

On Mon, Oct 27, 2025 at 10:12:12AM +0100, Oleksij Rempel wrote:
> On Mon, Oct 27, 2025 at 04:08:42AM +0100, Andrew Lunn wrote:
> > Adding Russell King
> >
> > On Sun, Oct 26, 2025 at 02:29:04PM +0200, Laurent Pinchart wrote:
> > > Energy Efficient Ethernet (EEE) is broken at least for 1000T on the EQOS
> > > (DWMAC) interface. When connected to an EEE-enabled peer, the ethernet
> > > devices produces an interrupts storm. Disable EEE support to fix it.
> > >
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> > > ---
> > > The exact reason for the interrupt storm is unknown, and my attempts to
> > > diagnose it was hindered by my lack of expertise with DWMAC. As far as I
> > > understand, the DWMAC implements EEE support, and so does the RTL8211E
> > > PHY according to its datasheet.
> >
> > I believe for DWMAC it is a synthesis option. However, there is a bit
> > indicating if the hardware supports it.
> >
> > The PHY should not be able to trigger an interrupt storm in the
> > MAC. So this is likely to be an DWMAC issue.
> >
> > Which interrupt bit is causing the storm?
> >
> > > What each side does exactly is unknown
> > > to me. One theory I've heard to explain the issue is that the two
> > > implementations conflict. There is no register in the RTL8211E PHY to
> > > disable EEE on the PHY side while still advertising its support to the
> > > peer and relying on the implementation in the DWMAC (if this even makes
> > > sense)
> >
> > It does not make sense. EEE is split into two major parts. The two
> > PHYs communicate with each other to negotiate the feature, if both
> > ends support it and both ends want to use it. The result of this
> > negotiation is then passed to the MACs.
> >
> > It is then the MAC who decides when to send a Low Power Indication to
> > the PHY to tell the PHY to enter low power mode. The MAC also wakes
> > the PHY when it has packets to send.
> >
> > A quick look at the data sheet for the RTL8211E suggests this is what
> > is supports.
> >
> > There are a few PHYs which implement SmartEEE, or some other similar
> > name. They operate differently, the PHY does it all, and the MAC is
> > not even aware EEE is happening. Such PHYs should really only be
> > paired with MACs which do not support EEE. An EEE capable MAC paired
> > with a SmartEEE PHY could have problems, but hopefully the EEE
> > abilities and negotiation registers in the PHY would be sufficient to
> > dissuade the MAC from doing EEE. But i would not expect a setup like
> > this to trigger an interrupt storm.
> 
> Please note, RTL8211E PHY do use undocumented SmartEEE mode by default.
> It ignores RGMII LPI opcodes and doing own thing. It can be confirmed by
> monitoring RGMII TX and MDI lines with oscilloscope and changing
> tx-timer configurations. I also confirmed this information from other
> source. To disable SmartEEE and use plain MAC based mode, NDA documentation
> is needed.

That's useful information, thank you. Would you by any chance to know if
such NDA would allow contributing the feature upstream ?

-- 
Regards,

Laurent Pinchart