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

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:

quoted

On Mon, Mar 23, 2026 at 11:39:32AM +0200, Laurent Pinchart wrote:

quoted

From: "Russell King (Oracle)" <redacted>

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 (local)
Signed-off-by: Russell King (Oracle) <redacted>

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 ?

quoted

 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