netdev - Re: [PATCH net-next v5 5/7] net: stmmac: Signal to PHY/PCS drivers to keep RX clock on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZeXb6p/RpJj1HRgn@shell.armlinux.org.uk>
Date: Mon, 4 Mar 2024 14:34:18 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Romain Gantois <romain.gantois@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Jose Abreu <joabreu@...opsys.com>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Clément Léger <clement.leger@...tlin.com>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	Miquel Raynal <miquel.raynal@...tlin.com>,
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
	netdev@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org,
	linux-renesas-soc@...r.kernel.org,
	Clark Wang <xiaoning.wang@....com>
Subject: Re: [PATCH net-next v5 5/7] net: stmmac: Signal to PHY/PCS drivers
 to keep RX clock on

On Fri, Mar 01, 2024 at 04:35:02PM +0100, Romain Gantois wrote:
> There is a reocurring issue with stmmac controllers where the MAC fails to
> initialize its hardware if an RX clock signal isn't provided on the MAC/PHY
> link.
> 
> This causes issues when PHY or PCS devices either go into suspend while
> cutting the RX clock or do not bring the clock signal up early enough for
> the MAC to initialize successfully.
> 
> Set the mac_requires_rxc flag in the stmmac phylink config so that PHY/PCS
> drivers know to keep the RX clock up at all times.
> 
> Reported-by: Clark Wang <xiaoning.wang@....com>
> Link: https://lore.kernel.org/all/20230202081559.3553637-1-xiaoning.wang@nxp.com/
> Reported-by: Clément Léger <clement.leger@...tlin.com>
> Link: https://lore.kernel.org/linux-arm-kernel/20230116103926.276869-4-clement.leger@bootlin.com/
> Suggested-by: Russell King <linux@...linux.org.uk>

This should be:
Co-developed-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>

> Signed-off-by: Romain Gantois <romain.gantois@...tlin.com>
> ---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 79844dbe4258..2290f4808d7e 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1218,6 +1218,9 @@ static int stmmac_phy_setup(struct stmmac_priv *priv)
>  	priv->phylink_config.type = PHYLINK_NETDEV;
>  	priv->phylink_config.mac_managed_pm = true;
>  
> +	/* Stmmac always requires an RX clock for hardware initialization */
> +	priv->phylink_config.mac_requires_rxc = true;
> +
>  	mdio_bus_data = priv->plat->mdio_bus_data;
>  	if (mdio_bus_data)
>  		priv->phylink_config.ovr_an_inband =
> @@ -3408,6 +3411,10 @@ static int stmmac_hw_setup(struct net_device *dev, bool ptp_register)
>  	u32 chan;
>  	int ret;
>  
> +	/* Make sure RX clock is enabled */
> +	if (priv->hw->phylink_pcs)
> +		phylink_pcs_pre_init(priv->phylink, priv->hw->phylink_pcs);
> +
>  	/* DMA initialization and SW reset */
>  	ret = stmmac_init_dma_engine(priv);
>  	if (ret < 0) {
> 
> -- 
> 2.43.2
> 
> 

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