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

[Oleksij Rempel <o.rempel@pengutronix.de>]

On Mon, Oct 27, 2025 at 01:50:21PM +0100, Andrew Lunn wrote:
> > > Ack. With comment in the code, why we prefer this way, in case some one
> > > wont to spend time on making it work. Probably SmartEEE or some other
> > > word should be used.
> > 
> > So we have options.
> > 
> > However, we need to get to the bottom of what caused the change of
> > behaviour before we start throwing solutions at this.
> 
> It also seems like the PHY is FUBAR. If the standard 802.3 EEE
> registers are being used, a management plane is using them to
> negotiate EEE with the link partner, the PHY firmware should disable
> SmartEEE and only provide 802.3 EEE.
> 
> It sounds like this PHY is not 802.3 compatible.

I do not know better place to post it, so I add it here for archive.
At least, it explains a reason why EEE fails. Something like this is not
possible to handle on the MAC side. At same time it is hard to
diagnose:

In 100BASE-TX EEE mode, the link partner may drop link or loss packet
when the local MAC/PHY (device) starts to transmit the “Wake” signal
immediately following the “Sleep”/“Refresh” signal to exit Low-Power
Idle mode and return to Active mode.

Many EEE PHY link partners require a short “Quiet” (Tq) duration after
receiving the “Sleep”/“Refresh” signal. Without this short Tq wait time,
that is not specified in the IEEE 802.3az Standard, link drop or packet
loss can occur.

https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/Errata/80000708B.pdf

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |