Re: [PATCH v3 1/2] net: stmmac: provide flag to disable EEE

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

On Mon, Mar 23, 2026 at 09:55:36AM +0000, Russell King (Oracle) wrote:
> On Mon, Mar 23, 2026 at 11:39:32AM +0200, Laurent Pinchart wrote:
> > From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
> > 
> > Some platforms have problems when EEE is enabled, and thus need a way
> > to disable stmmac EEE support. Add a flag before the other LPI related
> > flags which tells stmmac to avoid populating the phylink LPI
> > capabilities, which causes phylink to call phy_disable_eee() for any
> > PHY that is attached to the affected phylink instance.
> > 
> > iMX8MP is an example - the lpi_intr_o signal is wired to an OR gate
> > along with the main dwmac interrupts. Since lpi_intr_o is synchronous
> > to the receive clock domain, and takes four clock cycles to clear, this
> > leads to interrupt storms as the interrupt remains asserted for some
> > time after the LPI control and status register is read.
> > 
> > This problem becomes worse when the receive clock from the PHY stops
> > when the receive path enters LPI state - which means that lpi_intr_o
> > can not deassert until the clock restarts. Since the LPI state of the
> > receive path depends on the link partner, this is out of our control.
> > We could disable RX clock stop at the PHY, but that doesn't get around
> > the slow-to-deassert lpi_intr_o mentioned in the above paragraph.
> > 
> > Previously, iMX8MP worked around this by disabling gigabit EEE, but
> > this is insufficient - the problem is also visible at 100M speeds,
> > where the receive clock is slower.
> > 
> > There is extensive discussion and investigation in the thread linked
> > below, the result of which is summarised in this commit message.
> > 
> > Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> 
> As you are sending this on my behalf, you need to add your s-o-b after
> mine:

Oops, I'm not sure how I missed that. Sorry.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

>  Any further SoBs (Signed-off-by:'s) following the author's SoB are from
>  people handling and transporting the patch, but were not involved in its
>  development. SoB chains should reflect the **real** route a patch took
>  as it was propagated to the maintainers and ultimately to Linus, with
>  the first SoB entry signalling primary authorship of a single author.

-- 
Regards,

Laurent Pinchart