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

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Wed, Mar 25, 2026 at 10:13:32PM +0200, Laurent Pinchart wrote:
> 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 ?

I don't see it in patchwork's pending queue, so yes please. Don't forget
to specify the tree in the subject line:

[PATCH net-next v4 0/2] net: stmmac: ...

which may be a factor in it not showing up.

It's worth keeping an eye on:

https://patchwork.kernel.org/project/netdevbpf/list/?delegate=123371

about 24h after submission in case of any issues.

Thanks.

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