[PATCH] arm64: dts: imx8mp-debix-model-a: Disable EEE for 1000T
Russell King (Oracle)
linux at armlinux.org.uk
Sun Nov 23 09:11:27 PST 2025
On Mon, Nov 24, 2025 at 12:23:56AM +0900, Laurent Pinchart wrote:
> On Sun, Nov 23, 2025 at 08:52:00AM +0000, Russell King (Oracle) wrote:
> > On Sun, Nov 23, 2025 at 02:38:02PM +0900, Laurent Pinchart wrote:
> > > On Sat, Nov 22, 2025 at 09:57:49AM +0000, Russell King (Oracle) wrote:
> > > > On Sat, Nov 22, 2025 at 04:22:46PM +0900, Laurent Pinchart wrote:
> > > > > Hello Wei,
> > > > >
> > > > > On Tue, Nov 18, 2025 at 01:50:55AM +0000, Wei Fang wrote:
> > > > > > Sorry, I only have a little experience with DWMac, add Clark to help look
> > > > > > at this issue.
> > > > >
> > > > > Thank you.
> > > > >
> > > > > I think we're getting close to having a good understanding of the
> > > > > problem. I've debugged it as far as I could based on the information
> > > > > available publicly. Let's try to get to the bottom of this issue, it
> > > > > impacts quite a lot of people and it would be very nice to fix it
> > > > > properly in mainline.
> > > > >
> > > > > The short summary is that I'm experiencing an interrupt storm on IRQ 135
> > > > > when EEE is enabled with the EQOS interface.
> > > > >
> > > > > My current theory is that
> > > > >
> > > > > - The lpi_intr_o signal of the EQOS is OR'ed into IRQ 135.
> > > > > - The issue is triggerted by the PHY exiting LPI mode
> > > > > - When it exits LPI mode, the PHY restarts generating the RX clock
> > > > > (clk_rx_i).
> > > > > - The MAC detects exit from LPI, and asserts lpi_intr_o.
> > > > > - Before the CPU has time to process the interrupt, the PHY enters LPI
> > > > > mode again, and stops generating the RX clock.
> > > > > - The CPU processes the interrupt and reads the GMAC4_LPI_CTRL_STATUS
> > > > > registers. This does not clear lpi_intr_o as there's no clk_rx_i.
> > > >
> > > > Please try setting STMMAC_FLAG_RX_CLK_RUNS_IN_LPI in dwmac-imx.c and
> > > > see whether that changes the behaviour.
> > >
> > > I have tested that and it worked like a charm ! I have submitted
> > > https://lore.kernel.org/r/20251123053518.8478-1-laurent.pinchart@ideasonboard.com
> > >
> > > That was quite an adventure. Thank you so much for all your support, I'm
> > > not sure I would have managed without you (or at least I would have
> > > needed way more time). I really really appreciate it.
> > >
> > > If the above patch gets accepted, we will probably be able to remove the
> > > eee-broken-* properties from the i.MX8MP device tree files (and possibly
> > > from i.MX8DXL and i.MX93 as well). I have mentioned that below the
> > > commit message of the patch, with a test procedure as it should be
> > > tested on each board.
> >
> > As stated in reply to that patch, while this may reduce the severity of
> > the storm, I don't think it'll completely eliminate it.
> >
> > I made the suggestion to set the flag as a test to confirm whether the
> > lpi_intr_o is indeed the problem by ensuring that the receive domain is
> > always clocked, and thus ensuring that the signal clears within four
> > clock cycles, rather than an indefinite period should the remote end
> > re-enter LPI mode quicky.
>
> You're right. I've checked replied to the patch with the following
> numbers.
>
> 100TX link, eee-broken-* set: 7000 interrupts
> 1000T link, eee-broken-* set: 2711 interrupts
> 100TX link, eee-broken-* unset: 9450 interrupts
> 1000T link, eee-broken-* unset: 6066 interrupts
Sadly, I think this means for iMX8MP, the correct answer is to disable
EEE completely. What I was thinking when I brought this up is as follows
and dwmac-imx.c can set STMMAC_FLAG_EEE_DISABLE for iMX8MP to prevent
the use of EEE.
This works because, in phylink, pl->mac_supports_eee_ops will be set
since stmmac implements the two LPI operations. pl->mac_supports_eee
will be clear because pl->config->lpi_capabilities will be zero, and
pl->config->lpi_interfaces will be empty. This causes phylink to call
phy_disable_eee() on all PHYs that end up being attached to this
phylink instance, which should result in the PHY EEE advertisement
being cleared.
I'll package this up into a proper patch tomorrow.
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++++++-
include/linux/stmmac.h | 9 +++++----
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 1d37c2b5ad46..113cae2bc593 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1376,7 +1376,12 @@ static int stmmac_phylink_setup(struct stmmac_priv *priv)
config->supported_interfaces,
pcs->supported_interfaces);
- if (priv->dma_cap.eee) {
+ /* Some platforms, e.g. iMX8MP, wire lpi_intr_o to the same interrupt
+ * used for stmmac's main interrupts, which leads to interrupt storms.
+ * STMMAC_FLAG_EEE_DISABLE allows EEE to be disabled on such platforms.
+ */
+ if (priv->dma_cap.eee &&
+ !(priv->plat->flags & STMMAC_FLAG_EEE_DISABLE)) {
/* Assume all supported interfaces also support LPI */
memcpy(config->lpi_interfaces, config->supported_interfaces,
sizeof(config->lpi_interfaces));
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 8ae068706b63..4c770262a2f8 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -187,10 +187,11 @@ enum dwmac_core_type {
#define STMMAC_FLAG_MULTI_MSI_EN BIT(7)
#define STMMAC_FLAG_EXT_SNAPSHOT_EN BIT(8)
#define STMMAC_FLAG_INT_SNAPSHOT_EN BIT(9)
-#define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI BIT(10)
-#define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING BIT(11)
-#define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP BIT(12)
-#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY BIT(13)
+#define STMMAC_FLAG_EEE_DISABLE BIT(10)
+#define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI BIT(11)
+#define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING BIT(12)
+#define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP BIT(13)
+#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY BIT(14)
struct mac_device_info;
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
More information about the linux-arm-kernel
mailing list