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: <ddefca55-0f5f-4ba9-ac13-06bcfd59ee95@mailbox.org>
Date: Wed, 3 Dec 2025 21:46:38 +0100
From: Marek Vasut <marek.vasut@...lbox.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Vladimir Oltean <vladimir.oltean@....com>
Cc: 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 12/3/25 11:16 AM, Russell King (Oracle) wrote:
> 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.
Uh ... and sadly, the "EMI improvement parameters application note 1.2 
fails to mention this big when enabling CLK_OUT SSC. Also, there is 
PHYCR2 CLKOUT SSC capability bits 13:12 , which does who knows what ?