linux-kernel - Re: [PATCH net v2] net: phy: realtek: Reset after clock enable

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: <y3xhsgbcykfjmz6hjtjzfytb66bm2fomr7cesau45xcuxuin7n@jiryheq3qyvs>
Date: Sat, 26 Jul 2025 04:21:22 +0200
From: Sebastian Reichel <sebastian.reichel@...labora.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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>, 
	Florian Fainelli <florian.fainelli@...adcom.com>, Detlev Casanova <detlev.casanova@...labora.com>, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org, kernel@...labora.com, 
	stable@...r.kernel.org
Subject: Re: [PATCH net v2] net: phy: realtek: Reset after clock enable

Hi,

On Thu, Jul 24, 2025 at 05:51:58PM +0100, Russell King (Oracle) wrote:
> On Thu, Jul 24, 2025 at 04:39:42PM +0200, Sebastian Reichel wrote:
> > On Radxa ROCK 4D boards we are seeing some issues with PHY detection and
> > stability (e.g. link loss or not capable of transceiving packages) after
> > new board revisions switched from a dedicated crystal to providing the
> > 25 MHz PHY input clock from the SoC instead.
> > 
> > This board is using a RTL8211F PHY, which is connected to an always-on
> > regulator. Unfortunately the datasheet does not explicitly mention the
> > power-up sequence regarding the clock, but it seems to assume that the
> > clock is always-on (i.e. dedicated crystal).
> > 
> > By doing an explicit reset after enabling the clock, the issue on the
> > boards could no longer be observed.
> > 
> > Note, that the RK3576 SoC used by the ROCK 4D board does not yet
> > support system level PM, so the resume path has not been tested.
> > 
> > Cc: stable@...r.kernel.org
> > Fixes: 7300c9b574cc ("net: phy: realtek: Add optional external PHY clock")
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
> > ---
> > Changes in v2:
> > - Switch to PHY_RST_AFTER_CLK_EN + phy_reset_after_clk_enable(); the
> >   API is so far only used by the freescale/NXP MAC driver and does
> >   not seem to be written for usage from within the PHY driver, but
> >   I also don't see a good reason not to use it.
> > - Also reset after re-enabling the clock in rtl821x_resume()
> > - Link to v1: https://lore.kernel.org/r/20250704-phy-realtek-clock-fix-v1-1-63b33d204537@kernel.org
> > ---
> >  drivers/net/phy/realtek/realtek_main.c | 7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> > index c3dcb62574303374666b46a454cd4e10de455d24..cf128af0ec0c778262d70d6dc4524d06cbfccf1f 100644
> > --- a/drivers/net/phy/realtek/realtek_main.c
> > +++ b/drivers/net/phy/realtek/realtek_main.c
> > @@ -230,6 +230,7 @@ static int rtl821x_probe(struct phy_device *phydev)
> >  	if (IS_ERR(priv->clk))
> >  		return dev_err_probe(dev, PTR_ERR(priv->clk),
> >  				     "failed to get phy clock\n");
> > +	phy_reset_after_clk_enable(phydev);
> 
> Should this depend on priv->clk existing?
> 
> >  
> >  	ret = phy_read_paged(phydev, RTL8211F_PHYCR_PAGE, RTL8211F_PHYCR1);
> >  	if (ret < 0)
> > @@ -627,8 +628,10 @@ static int rtl821x_resume(struct phy_device *phydev)
> >  	struct rtl821x_priv *priv = phydev->priv;
> >  	int ret;
> >  
> > -	if (!phydev->wol_enabled)
> > +	if (!phydev->wol_enabled) {
> >  		clk_prepare_enable(priv->clk);
> > +		phy_reset_after_clk_enable(phydev);
> 
> Should this depend on priv->clk existing?
> 
> I'm thinking about platforms such as Jetson Xavier NX, which I
> believe uses a crystal, and doesn't appear to suffer from any
> problems.

Doing the extra reset should not hurt, but I can add it to speed up
PHY initialization on systems with an always-on clock source. I will
send a PATCHv3.

Greetings,

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)