From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 58EB83EC2CF for ; Thu, 26 Mar 2026 15:53:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774540406; cv=none; b=Ra4H+3NGhO725H5yF8oG3WB68xZSnx/Hh1jtssBOHp/0bHVk8NMDsXqdeNsJRkH1M7mTNNePKvITcn2IEq0IQymWUhOwn/NcT/sxGSYNkXID+s7PZ3AaBFkKvYThIV3w6y5NKbrw4b8E9mRe8TX0XWL94C8qhlVNyuQlGnbzJCU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774540406; c=relaxed/simple; bh=jWCzCO8aMHEZUZ7DQtZDmmJccLhh6PSRxwep9L4gXII=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Wn2aI669SDo9QnN0yg17GRzJR+f3jhhUbgXwVbA7rW+S0819oB2Yr6OiKRE9F6ahWaeg5tnvcjNefV2Kwh7tHYKGGb7I2DGVXj2pQE7bEsPHjhhYWMCR26QJ35Pt8Yz6DwdK+1lDkMT4NFRqpT2toPoKJxGk4yg6YWqHF8R9Viw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=joWP8ZbJ; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="joWP8ZbJ" Received: from killaraus.ideasonboard.com (2001-14ba-703d-e500--2a1.rev.dnainternet.fi [IPv6:2001:14ba:703d:e500::2a1]) by perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id 312F39A9; Thu, 26 Mar 2026 16:52:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1774540323; bh=jWCzCO8aMHEZUZ7DQtZDmmJccLhh6PSRxwep9L4gXII=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=joWP8ZbJ4pAXm4DFioLVh0FvhCYCPI2Jv1TfsVBxaf1l2Z7EREDeQUXU3WOu87FSy aQW9zeIZcL2jeCdbhgOk5CT/RA1qzlqrJbeWcPitiNxIHwOlZ5rJYp63cHL83p0Qds pazg0Vl/Jic2PmKa5/02oasm+6KHQh/MY/7KceCQ= Date: Thu, 26 Mar 2026 17:53:20 +0200 From: Laurent Pinchart To: netdev@vger.kernel.org, imx@lists.linux.dev Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Fabio Estevam , Francesco Dolcini , Frank Li , Jakub Kicinski , Joy Zou , Kieran Bingham , Marco Felsch , Paolo Abeni , Pengutronix Kernel Team , "Russell King (Oracle)" , Stefan Klug , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH net-next v4 1/2] net: stmmac: provide flag to disable EEE Message-ID: <20260326155320.GA2929106@killaraus.ideasonboard.com> References: <20260325210003.2752013-1-laurent.pinchart@ideasonboard.com> <20260325210003.2752013-2-laurent.pinchart@ideasonboard.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260325210003.2752013-2-laurent.pinchart@ideasonboard.com> On Wed, Mar 25, 2026 at 11:00:02PM +0200, Laurent Pinchart wrote: > From: "Russell King (Oracle)" > > 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 > Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com > Signed-off-by: Russell King (Oracle) > Tested-by: Ovidiu Panait And I just realized I haven't sent an R-b tag, despite having reviewed the patch. Reviewed-by: Laurent Pinchart > Signed-off-by: Laurent Pinchart > --- > drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++++++- > include/linux/stmmac.h | 13 +++++++------ > 2 files changed, 13 insertions(+), 7 deletions(-) > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > index 9b6b49331639..ce51b9c22129 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c > @@ -1438,7 +1438,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)) { > /* The GMAC 3.74a databook states that EEE is only supported > * in MII, GMII, and RGMII interfaces. > */ > diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h > index 5b2bece81448..e62d21afd56d 100644 > --- a/include/linux/stmmac.h > +++ b/include/linux/stmmac.h > @@ -207,12 +207,13 @@ 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_KEEP_PREAMBLE_BEFORE_SFD BIT(14) > -#define STMMAC_FLAG_SERDES_SUPPORTS_2500M BIT(15) > +#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) > +#define STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD BIT(15) > +#define STMMAC_FLAG_SERDES_SUPPORTS_2500M BIT(16) > > struct mac_device_info; > -- Regards, Laurent Pinchart