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

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

On Mon, Mar 23, 2026 at 12:08:02PM +0200, Laurent Pinchart wrote:
> 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>

Should I submit a v4, or can this series be picked for v7.1 with my SoB
added ?

> >  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