netdev - Re: [net-next,PATCH 3/3] net: phy: realtek: Add property to enable SSC

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: <aTAN5lX_OgwQh7E8@shell.armlinux.org.uk>
Date: Wed, 3 Dec 2025 10:16:06 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Marek Vasut <marek.vasut@...lbox.org>,
	Ivan Galkin <ivan.galkin@...s.com>, netdev@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Aleksander Jan Bajkowski <olek2@...pl>,
	Andrew Lunn <andrew@...n.ch>, Conor Dooley <conor+dt@...nel.org>,
	Eric Dumazet <edumazet@...gle.com>,
	Florian Fainelli <f.fainelli@...il.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Michael Klein <michael@...sekall.de>,
	Paolo Abeni <pabeni@...hat.com>, Rob Herring <robh@...nel.org>,
	devicetree@...r.kernel.org
Subject: Re: [net-next,PATCH 3/3] net: phy: realtek: Add property to enable
 SSC

On Wed, Dec 03, 2025 at 11:42:24AM +0200, Vladimir Oltean wrote:
> > +
> > +       ret = phy_write_paged(phydev, RTL8211F_SSC_PAGE, RTL8211F_SSC_RXC, 0x5f00);
> > +       if (ret < 0) {
> > +               dev_err(dev, "RXC SCC configuration failed: %pe\n", ERR_PTR(ret));
> > +               return ret;
> > +       }
> 
> I'm going to show a bit of lack of knowledge, but I'm thinking in the context
> of stmmac (user of phylink_config :: mac_requires_rxc), which I don't exactly
> know what it requires it for.

stmmac requires _all_ clocks to be running in order to complete reset,
as the core is made up of multiple modules, all of which are
synchronously clocked by their respective clocks. So, e.g. for the
receive sections to complete their reset activity, clk_rx_i must be
running. In RGMII mode, this means that the RGMII RXC from the PHY must
be running when either the stmmac core is subject to hardware or
software reset.

> Does it use the RGMII RXC as a system clock?
> If so, I guess intentionally introducing jitter (via the spread spectrum
> feature) would be disastrous for it. In that case we should seriously consider
> separating the "spread spectrum for CLKOUT" and "spread spectrum for RGMII"
> device tree control properties.

I don't think it will affect stmmac - as long as the clock is toggling
so that the synchronous components in stmmac can change state, that's
all that the stmmac reset issue cares about.

However, looking at the RTL8211FS(I)(-VS) datasheet, CLKOUT and RXC
are two different clocks.

CLKOUT can be:
- reference clock generated from internal PLL.
- UTP recovery receive clock (for SyncE)
- Fibre recovery receive clock (for SyncE)
- PTP synchronised clock output

This can't be used for clocking the RGMII data, because it won't be
guaranteed to have the clock edges at the correct point, nor does it
switch clock speed according to the negotiated data rate. In SyncE
modes, the recovered clock is either 125MHz or 25MHz, whereas RXC
is 125, 25 or 2.5MHz.

There is a separate bit for enabling SSC on RXC - PHYCR2 bit 3 vs
CLKOUT SSC in bit 7.

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