netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Marek Vasut <marek.vasut@mailbox.org>,
	Ivan Galkin <ivan.galkin@axis.com>,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Aleksander Jan Bajkowski <olek2@wp.pl>,
	Andrew Lunn <andrew@lunn.ch>, Conor Dooley <conor+dt@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Michael Klein <michael@fossekall.de>,
	Paolo Abeni <pabeni@redhat.com>, Rob Herring <robh@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [net-next,PATCH 3/3] net: phy: realtek: Add property to enable SSC
Date: Wed, 3 Dec 2025 10:16:06 +0000	[thread overview]
Message-ID: <aTAN5lX_OgwQh7E8@shell.armlinux.org.uk> (raw)
In-Reply-To: <20251203094224.jelvaizfq7h6jzke@skbuf>

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!

  reply	other threads:[~2025-12-03 10:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-30  0:58 [net-next,PATCH 1/3] dt-bindings: net: realtek,rtl82xx: Keep property list sorted Marek Vasut
2025-11-30  0:58 ` [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property Marek Vasut
2025-11-30  1:43   ` Andrew Lunn
2025-11-30 13:43     ` Marek Vasut
2025-11-30  2:29   ` Rob Herring (Arm)
2025-11-30  8:20   ` Krzysztof Kozlowski
2025-11-30 13:41     ` Marek Vasut
2025-12-01  7:20       ` Krzysztof Kozlowski
2025-12-03  1:30         ` Marek Vasut
2025-12-03  7:56           ` Krzysztof Kozlowski
2025-12-03 20:16             ` Marek Vasut
2025-11-30  0:58 ` [net-next,PATCH 3/3] net: phy: realtek: Add property to enable SSC Marek Vasut
2025-12-03  9:42   ` Vladimir Oltean
2025-12-03 10:16     ` Russell King (Oracle) [this message]
2025-12-03 20:46       ` Marek Vasut
2025-12-03 13:01     ` Ivan Galkin
2025-12-03 20:51       ` Marek Vasut
2025-12-03 14:18     ` Ivan Galkin
2025-12-03 20:56       ` Marek Vasut
2025-12-03 20:17     ` Marek Vasut
2025-12-03 10:18   ` Russell King (Oracle)
2025-12-03 12:34     ` Vladimir Oltean
2025-12-03 17:35       ` Russell King (Oracle)
2025-12-03 19:21         ` Marek Vasut
2025-11-30  2:29 ` [net-next,PATCH 1/3] dt-bindings: net: realtek,rtl82xx: Keep property list sorted Rob Herring (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aTAN5lX_OgwQh7E8@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=ivan.galkin@axis.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=marek.vasut@mailbox.org \
    --cc=michael@fossekall.de \
    --cc=netdev@vger.kernel.org \
    --cc=olek2@wp.pl \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).