[net-next,PATCH 1/3] dt-bindings: net: realtek,rtl82xx: Keep property list sorted

[net-next,PATCH 1/3] dt-bindings: net: realtek,rtl82xx: Keep property list sorted

[Marek Vasut]

Sort the documented properties alphabetically, no functional change.

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michael Klein <michael@fossekall.de>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: netdev@vger.kernel.org
---
 .../devicetree/bindings/net/realtek,rtl82xx.yaml          | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
index 2b5697bd7c5df..eafcc2f3e3d66 100644
--- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
+++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
@@ -40,15 +40,15 @@ properties:
 
   leds: true
 
-  realtek,clkout-disable:
+  realtek,aldps-enable:
     type: boolean
     description:
-      Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
+      Enable ALDPS mode, ALDPS mode default is disabled after hardware reset.
 
-  realtek,aldps-enable:
+  realtek,clkout-disable:
     type: boolean
     description:
-      Enable ALDPS mode, ALDPS mode default is disabled after hardware reset.
+      Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
 
   wakeup-source:
     type: boolean
-- 
2.51.0

[net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property

[Marek Vasut]

Document support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. Introduce new DT property
'realtek,ssc-enable' to enable SSC mode for both RXC and SYSCLK clock
signals.

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michael Klein <michael@fossekall.de>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: netdev@vger.kernel.org
---
 Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
index eafcc2f3e3d66..f1bd0095026be 100644
--- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
+++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
@@ -50,6 +50,11 @@ properties:
     description:
       Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
 
+  realtek,ssc-enable:
+    type: boolean
+    description:
+      Enable SSC mode, SSC mode default is disabled after hardware reset.
+
   wakeup-source:
     type: boolean
     description:
-- 
2.51.0

Re: [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property

[Andrew Lunn]

On Sun, Nov 30, 2025 at 01:58:33AM +0100, Marek Vasut wrote:
> Document support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
> RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. Introduce new DT property
> 'realtek,ssc-enable' to enable SSC mode for both RXC and SYSCLK clock
> signals.
> 
> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Klein <michael@fossekall.de>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
> index eafcc2f3e3d66..f1bd0095026be 100644
> --- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
> +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
> @@ -50,6 +50,11 @@ properties:
>      description:
>        Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
>  
> +  realtek,ssc-enable:
> +    type: boolean
> +    description:
> +      Enable SSC mode, SSC mode default is disabled after hardware reset.

Spread Spectrum Clocking is a generic concept, applicable to more than
Ethernet PHYs. Do we really need a vendor property for this? Or is
there a generic property already?

	Andrew

Re: [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property

[Marek Vasut]

On 11/30/25 2:43 AM, Andrew Lunn wrote:

Hello Andrew,

>> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>> index eafcc2f3e3d66..f1bd0095026be 100644
>> --- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>> +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>> @@ -50,6 +50,11 @@ properties:
>>       description:
>>         Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
>>   
>> +  realtek,ssc-enable:
>> +    type: boolean
>> +    description:
>> +      Enable SSC mode, SSC mode default is disabled after hardware reset.
> 
> Spread Spectrum Clocking is a generic concept, applicable to more than
> Ethernet PHYs. Do we really need a vendor property for this? Or is
> there a generic property already?
Let's see what Krzysztof has to say about this, I am fine with generic 
property ... unless it would be desirable to control the RXC and SYSCLK 
spread spectrum separately ?

Re: [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property

[Rob Herring (Arm)]

On Sun, 30 Nov 2025 01:58:33 +0100, Marek Vasut wrote:
> Document support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
> RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. Introduce new DT property
> 'realtek,ssc-enable' to enable SSC mode for both RXC and SYSCLK clock
> signals.
> 
> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Klein <michael@fossekall.de>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:


doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20251130005843.234656-2-marek.vasut@mailbox.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property

[Krzysztof Kozlowski]

On 30/11/2025 01:58, Marek Vasut wrote:
> Document support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
> RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. Introduce new DT property
> 'realtek,ssc-enable' to enable SSC mode for both RXC and SYSCLK clock
> signals.
> 
> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Klein <michael@fossekall.de>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
>  Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
> index eafcc2f3e3d66..f1bd0095026be 100644
> --- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
> +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
> @@ -50,6 +50,11 @@ properties:
>      description:
>        Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
>  
> +  realtek,ssc-enable:
> +    type: boolean
> +    description:
> +      Enable SSC mode, SSC mode default is disabled after hardware reset.

I don't want more SSC properties. We already had a big discussions about
it - one person pushing vendor property and only shortly after we learnt
that more vendors want it and they are actually working on this.

Best regards,
Krzysztof

Re: [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property

[Marek Vasut]

On 11/30/25 9:20 AM, Krzysztof Kozlowski wrote:

Hello Krzysztof,

>> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>> index eafcc2f3e3d66..f1bd0095026be 100644
>> --- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>> +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>> @@ -50,6 +50,11 @@ properties:
>>       description:
>>         Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
>>   
>> +  realtek,ssc-enable:
>> +    type: boolean
>> +    description:
>> +      Enable SSC mode, SSC mode default is disabled after hardware reset.
> 
> I don't want more SSC properties. We already had a big discussions about
> it - one person pushing vendor property and only shortly after we learnt
> that more vendors want it and they are actually working on this.
What kind of a property would you propose I use for this ?

Re: [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property

[Krzysztof Kozlowski]

On 30/11/2025 14:41, Marek Vasut wrote:
> On 11/30/25 9:20 AM, Krzysztof Kozlowski wrote:
> 
> Hello Krzysztof,
> 
>>> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>>> index eafcc2f3e3d66..f1bd0095026be 100644
>>> --- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>>> +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>>> @@ -50,6 +50,11 @@ properties:
>>>       description:
>>>         Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
>>>   
>>> +  realtek,ssc-enable:
>>> +    type: boolean
>>> +    description:
>>> +      Enable SSC mode, SSC mode default is disabled after hardware reset.
>>
>> I don't want more SSC properties. We already had a big discussions about
>> it - one person pushing vendor property and only shortly after we learnt
>> that more vendors want it and they are actually working on this.
> What kind of a property would you propose I use for this ?

I don't know, please look at existing work around SSC from Peng. If
nothing is applicable, this should be explained somewhere.

Best regards,
Krzysztof

Re: [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property

[Marek Vasut]

On 12/1/25 8:20 AM, Krzysztof Kozlowski wrote:
> On 30/11/2025 14:41, Marek Vasut wrote:
>> On 11/30/25 9:20 AM, Krzysztof Kozlowski wrote:
>>
>> Hello Krzysztof,
>>
>>>> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>>>> index eafcc2f3e3d66..f1bd0095026be 100644
>>>> --- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>>>> +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>>>> @@ -50,6 +50,11 @@ properties:
>>>>        description:
>>>>          Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
>>>>    
>>>> +  realtek,ssc-enable:
>>>> +    type: boolean
>>>> +    description:
>>>> +      Enable SSC mode, SSC mode default is disabled after hardware reset.
>>>
>>> I don't want more SSC properties. We already had a big discussions about
>>> it - one person pushing vendor property and only shortly after we learnt
>>> that more vendors want it and they are actually working on this.
>> What kind of a property would you propose I use for this ?
> 
> I don't know, please look at existing work around SSC from Peng. If
> nothing is applicable, this should be explained somewhere.

The work from Peng you refer to (I guess) is this "assigned-clock-sscs" 
property ? This is not applicable, because this is a boolean property of 
the PHY here, the clock does not expose those clock via the clock API.

However, I can call the property "ssc-enable" without the realtek, 
vendor prefix ?

The remaining question is, should I have one property "ssc-enable" to 
control all SSC in the PHY or one for each bit "realtek,ssc-enable-rxc" 
/ "realtek,ssc-enable-clkout" ?

-- 
Best regards,
Marek Vasut

Re: [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property

[Krzysztof Kozlowski]

On 03/12/2025 02:30, Marek Vasut wrote:
> On 12/1/25 8:20 AM, Krzysztof Kozlowski wrote:
>> On 30/11/2025 14:41, Marek Vasut wrote:
>>> On 11/30/25 9:20 AM, Krzysztof Kozlowski wrote:
>>>
>>> Hello Krzysztof,
>>>
>>>>> diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>>>>> index eafcc2f3e3d66..f1bd0095026be 100644
>>>>> --- a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>>>>> +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml
>>>>> @@ -50,6 +50,11 @@ properties:
>>>>>        description:
>>>>>          Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset.
>>>>>    
>>>>> +  realtek,ssc-enable:
>>>>> +    type: boolean
>>>>> +    description:
>>>>> +      Enable SSC mode, SSC mode default is disabled after hardware reset.
>>>>
>>>> I don't want more SSC properties. We already had a big discussions about
>>>> it - one person pushing vendor property and only shortly after we learnt
>>>> that more vendors want it and they are actually working on this.
>>> What kind of a property would you propose I use for this ?
>>
>> I don't know, please look at existing work around SSC from Peng. If
>> nothing is applicable, this should be explained somewhere.
> 
> The work from Peng you refer to (I guess) is this "assigned-clock-sscs" 
> property ? This is not applicable, because this is a boolean property of 
> the PHY here, the clock does not expose those clock via the clock API.

OK, please mention this in the commit msg - that assigned-clock-sscs is
not applicable, because these are clocks not exposed outside.

I saw already brcm,enable-ssc property, so use rather "realtek,enable-ssc".

> 
> However, I can call the property "ssc-enable" without the realtek, 
> vendor prefix ?

I think no, I am not so sure how generic it would be to cover all
existing cases. Some devices, e.g. cdns, defines the mode of SSC, so
uses an enum.

> 
> The remaining question is, should I have one property "ssc-enable" to 
> control all SSC in the PHY or one for each bit "realtek,ssc-enable-rxc" 
> / "realtek,ssc-enable-clkout" ?

I don't know. Can they be enabled independently? Does it make sense for
the hardware to have different choices?


Best regards,
Krzysztof

Re: [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document realtek,ssc-enable property

[Marek Vasut]

On 12/3/25 8:56 AM, Krzysztof Kozlowski wrote:

>>> I don't know, please look at existing work around SSC from Peng. If
>>> nothing is applicable, this should be explained somewhere.
>>
>> The work from Peng you refer to (I guess) is this "assigned-clock-sscs"
>> property ? This is not applicable, because this is a boolean property of
>> the PHY here, the clock does not expose those clock via the clock API.
> 
> OK, please mention this in the commit msg - that assigned-clock-sscs is
> not applicable, because these are clocks not exposed outside.

OK

> I saw already brcm,enable-ssc property, so use rather "realtek,enable-ssc".

The realtek PHY bindings use realtek,<feature>-{enable,disable} already, 
so I would like to be at least consistent here ?

>> However, I can call the property "ssc-enable" without the realtek,
>> vendor prefix ?
> 
> I think no, I am not so sure how generic it would be to cover all
> existing cases. Some devices, e.g. cdns, defines the mode of SSC, so
> uses an enum.
> 
>>
>> The remaining question is, should I have one property "ssc-enable" to
>> control all SSC in the PHY or one for each bit "realtek,ssc-enable-rxc"
>> / "realtek,ssc-enable-clkout" ?
> 
> I don't know. Can they be enabled independently? Does it make sense for
> the hardware to have different choices?
The hardware can turn SSC on separate on either signal, and the netdev 
discussion seem to be veering in that direction, so I will split them 
and create two properties.

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

[Marek Vasut]

Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
follows EMI improvement application note Rev. 1.2 for these PHYs.

The current implementation enables SSC for both RXC and SYSCLK clock
signals. Introduce new DT property 'realtek,ssc-enable' to enable the
SSC mode.

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michael Klein <michael@fossekall.de>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: netdev@vger.kernel.org
---
 drivers/net/phy/realtek/realtek_main.c | 47 ++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 67ecf3d4af2b1..b1b48936d6422 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -74,11 +74,17 @@
 
 #define RTL8211F_PHYCR2				0x19
 #define RTL8211F_CLKOUT_EN			BIT(0)
+#define RTL8211F_SYSCLK_SSC_EN			BIT(3)
 #define RTL8211F_PHYCR2_PHY_EEE_ENABLE		BIT(5)
 
 #define RTL8211F_INSR_PAGE			0xa43
 #define RTL8211F_INSR				0x1d
 
+/* RTL8211F SSC settings */
+#define RTL8211F_SSC_PAGE			0xc44
+#define RTL8211F_SSC_RXC			0x13
+#define RTL8211F_SSC_SYSCLK			0x17
+
 /* RTL8211F LED configuration */
 #define RTL8211F_LEDCR_PAGE			0xd04
 #define RTL8211F_LEDCR				0x10
@@ -203,6 +209,7 @@ MODULE_LICENSE("GPL");
 struct rtl821x_priv {
 	bool enable_aldps;
 	bool disable_clk_out;
+	bool enable_ssc;
 	struct clk *clk;
 	/* rtl8211f */
 	u16 iner;
@@ -266,6 +273,8 @@ static int rtl821x_probe(struct phy_device *phydev)
 						   "realtek,aldps-enable");
 	priv->disable_clk_out = of_property_read_bool(dev->of_node,
 						      "realtek,clkout-disable");
+	priv->enable_ssc = of_property_read_bool(dev->of_node,
+						 "realtek,ssc-enable");
 
 	phydev->priv = priv;
 
@@ -700,6 +709,37 @@ static int rtl8211f_config_phy_eee(struct phy_device *phydev)
 				RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);
 }
 
+static int rtl8211f_config_ssc(struct phy_device *phydev)
+{
+	struct rtl821x_priv *priv = phydev->priv;
+	struct device *dev = &phydev->mdio.dev;
+	int ret;
+
+	/* The value is preserved if the device tree property is absent */
+	if (!priv->enable_ssc)
+		return 0;
+
+	/* RTL8211FVD has no PHYCR2 register */
+	if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
+		return 0;
+
+	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;
+	}
+
+	ret = phy_write_paged(phydev, RTL8211F_SSC_PAGE, RTL8211F_SSC_SYSCLK, 0x4f00);
+	if (ret < 0) {
+		dev_err(dev, "SYSCLK SCC configuration failed: %pe\n", ERR_PTR(ret));
+		return ret;
+	}
+
+	/* Enable SSC */
+	return phy_modify_paged(phydev, RTL8211F_PHYCR_PAGE, RTL8211F_PHYCR2,
+				RTL8211F_SYSCLK_SSC_EN, RTL8211F_SYSCLK_SSC_EN);
+}
+
 static int rtl8211f_config_init(struct phy_device *phydev)
 {
 	struct device *dev = &phydev->mdio.dev;
@@ -723,6 +763,13 @@ static int rtl8211f_config_init(struct phy_device *phydev)
 		return ret;
 	}
 
+	ret = rtl8211f_config_ssc(phydev);
+	if (ret) {
+		dev_err(dev, "SSC mode configuration failed: %pe\n",
+			ERR_PTR(ret));
+		return ret;
+	}
+
 	return rtl8211f_config_phy_eee(phydev);
 }
 
-- 
2.51.0

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

[Vladimir Oltean]

On Sun, Nov 30, 2025 at 01:58:34AM +0100, Marek Vasut wrote:
> Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
> RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
> follows EMI improvement application note Rev. 1.2 for these PHYs.
> 
> The current implementation enables SSC for both RXC and SYSCLK clock
> signals. Introduce new DT property 'realtek,ssc-enable' to enable the
> SSC mode.
> 
> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Klein <michael@fossekall.de>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
>  drivers/net/phy/realtek/realtek_main.c | 47 ++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> index 67ecf3d4af2b1..b1b48936d6422 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c
> @@ -74,11 +74,17 @@
> 
>  #define RTL8211F_PHYCR2                                0x19
>  #define RTL8211F_CLKOUT_EN                     BIT(0)
> +#define RTL8211F_SYSCLK_SSC_EN                 BIT(3)
>  #define RTL8211F_PHYCR2_PHY_EEE_ENABLE         BIT(5)
> 
>  #define RTL8211F_INSR_PAGE                     0xa43
>  #define RTL8211F_INSR                          0x1d
> 
> +/* RTL8211F SSC settings */
> +#define RTL8211F_SSC_PAGE                      0xc44
> +#define RTL8211F_SSC_RXC                       0x13
> +#define RTL8211F_SSC_SYSCLK                    0x17
> +
>  /* RTL8211F LED configuration */
>  #define RTL8211F_LEDCR_PAGE                    0xd04
>  #define RTL8211F_LEDCR                         0x10
> @@ -203,6 +209,7 @@ MODULE_LICENSE("GPL");
>  struct rtl821x_priv {
>         bool enable_aldps;
>         bool disable_clk_out;
> +       bool enable_ssc;
>         struct clk *clk;
>         /* rtl8211f */
>         u16 iner;
> @@ -266,6 +273,8 @@ static int rtl821x_probe(struct phy_device *phydev)
>                                                    "realtek,aldps-enable");
>         priv->disable_clk_out = of_property_read_bool(dev->of_node,
>                                                       "realtek,clkout-disable");
> +       priv->enable_ssc = of_property_read_bool(dev->of_node,
> +                                                "realtek,ssc-enable");
> 
>         phydev->priv = priv;
> 
> @@ -700,6 +709,37 @@ static int rtl8211f_config_phy_eee(struct phy_device *phydev)
>                                 RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);
>  }
> 
> +static int rtl8211f_config_ssc(struct phy_device *phydev)
> +{
> +       struct rtl821x_priv *priv = phydev->priv;
> +       struct device *dev = &phydev->mdio.dev;
> +       int ret;
> +
> +       /* The value is preserved if the device tree property is absent */
> +       if (!priv->enable_ssc)
> +               return 0;
> +
> +       /* RTL8211FVD has no PHYCR2 register */
> +       if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
> +               return 0;

Ivan, do your conversations with Realtek support suggest that the VFD
PHY variant also supports the spread spectrum clock bits configured here
in RTL8211F_PHYCR2?

> +
> +       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. 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.

> +
> +       ret = phy_write_paged(phydev, RTL8211F_SSC_PAGE, RTL8211F_SSC_SYSCLK, 0x4f00);
> +       if (ret < 0) {
> +               dev_err(dev, "SYSCLK SCC configuration failed: %pe\n", ERR_PTR(ret));
> +               return ret;
> +       }
> +
> +       /* Enable SSC */
> +       return phy_modify_paged(phydev, RTL8211F_PHYCR_PAGE, RTL8211F_PHYCR2,
> +                               RTL8211F_SYSCLK_SSC_EN, RTL8211F_SYSCLK_SSC_EN);
> +}
> +
>  static int rtl8211f_config_init(struct phy_device *phydev)
>  {
>         struct device *dev = &phydev->mdio.dev;
> @@ -723,6 +763,13 @@ static int rtl8211f_config_init(struct phy_device *phydev)
>                 return ret;
>         }
> 
> +       ret = rtl8211f_config_ssc(phydev);
> +       if (ret) {
> +               dev_err(dev, "SSC mode configuration failed: %pe\n",
> +                       ERR_PTR(ret));
> +               return ret;
> +       }
> +
>         return rtl8211f_config_phy_eee(phydev);
>  }
> 
> --
> 2.51.0
>

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

[Russell King (Oracle)]

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!

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

[Marek Vasut]

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 ?

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

[Ivan Galkin]

On Wed, 2025-12-03 at 11:42 +0200, Vladimir Oltean wrote:
> [You don't often get email from vladimir.oltean@nxp.com. Learn why
> this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Sun, Nov 30, 2025 at 01:58:34AM +0100, Marek Vasut wrote:
> > Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-
> > CG,
> > RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
> > follows EMI improvement application note Rev. 1.2 for these PHYs.
> > 
> > The current implementation enables SSC for both RXC and SYSCLK
> > clock
> > signals. Introduce new DT property 'realtek,ssc-enable' to enable
> > the
> > SSC mode.
> > 
> > Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> > ---
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Conor Dooley <conor+dt@kernel.org>
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Florian Fainelli <f.fainelli@gmail.com>
> > Cc: Heiner Kallweit <hkallweit1@gmail.com>
> > Cc: Jakub Kicinski <kuba@kernel.org>
> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> > Cc: Michael Klein <michael@fossekall.de>
> > Cc: Paolo Abeni <pabeni@redhat.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Russell King <linux@armlinux.org.uk>
> > Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> > Cc: devicetree@vger.kernel.org
> > Cc: netdev@vger.kernel.org
> > ---
> >  drivers/net/phy/realtek/realtek_main.c | 47
> > ++++++++++++++++++++++++++
> >  1 file changed, 47 insertions(+)
> > 
> > diff --git a/drivers/net/phy/realtek/realtek_main.c
> > b/drivers/net/phy/realtek/realtek_main.c
> > index 67ecf3d4af2b1..b1b48936d6422 100644
> > --- a/drivers/net/phy/realtek/realtek_main.c
> > +++ b/drivers/net/phy/realtek/realtek_main.c
> > @@ -74,11 +74,17 @@
> > 
> >  #define RTL8211F_PHYCR2                                0x19
> >  #define RTL8211F_CLKOUT_EN                     BIT(0)
> > +#define RTL8211F_SYSCLK_SSC_EN                 BIT(3)
> >  #define RTL8211F_PHYCR2_PHY_EEE_ENABLE         BIT(5)
> > 
> >  #define RTL8211F_INSR_PAGE                     0xa43
> >  #define RTL8211F_INSR                          0x1d
> > 
> > +/* RTL8211F SSC settings */
> > +#define RTL8211F_SSC_PAGE                      0xc44
> > +#define RTL8211F_SSC_RXC                       0x13
> > +#define RTL8211F_SSC_SYSCLK                    0x17
> > +
> >  /* RTL8211F LED configuration */
> >  #define RTL8211F_LEDCR_PAGE                    0xd04
> >  #define RTL8211F_LEDCR                         0x10
> > @@ -203,6 +209,7 @@ MODULE_LICENSE("GPL");
> >  struct rtl821x_priv {
> >         bool enable_aldps;
> >         bool disable_clk_out;
> > +       bool enable_ssc;
> >         struct clk *clk;
> >         /* rtl8211f */
> >         u16 iner;
> > @@ -266,6 +273,8 @@ static int rtl821x_probe(struct phy_device
> > *phydev)
> >                                                    "realtek,aldps-
> > enable");
> >         priv->disable_clk_out = of_property_read_bool(dev->of_node,
> >                                                      
> > "realtek,clkout-disable");
> > +       priv->enable_ssc = of_property_read_bool(dev->of_node,
> > +                                                "realtek,ssc-
> > enable");
> > 
> >         phydev->priv = priv;
> > 
> > @@ -700,6 +709,37 @@ static int rtl8211f_config_phy_eee(struct
> > phy_device *phydev)
> >                                 RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);
> >  }
> > 
> > +static int rtl8211f_config_ssc(struct phy_device *phydev)
> > +{
> > +       struct rtl821x_priv *priv = phydev->priv;
> > +       struct device *dev = &phydev->mdio.dev;
> > +       int ret;
> > +
> > +       /* The value is preserved if the device tree property is
> > absent */
> > +       if (!priv->enable_ssc)
> > +               return 0;
> > +
> > +       /* RTL8211FVD has no PHYCR2 register */
> > +       if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
> > +               return 0;
> 
> Ivan, do your conversations with Realtek support suggest that the VFD
> PHY variant also supports the spread spectrum clock bits configured
> here
> in RTL8211F_PHYCR2?
> 
> 
> 

From what I learned from Realtek, the statement about RTL8211F(D)(I)-
VD-CG not having PHYCR2 (Page 0xa43 Address 0x19) is incorrect. This
register does exist and manages nearly identical configurations as the
rest of the RTL8211F series, with the exception of the CLKOUT
configuration, which has been relocated to a different control
register. Marek, you can read about my findings here
https://lore.kernel.org/netdev/20251202-phy_eee-v1-1-fe0bf6ab3df0@axis.com/

Unfortunately I don't have the complete description of PHYCR2 on this
particular PHY. I will reach out to Realtek regarding SSC and provide
an update once I have more information.

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

[Marek Vasut]

On 12/3/25 2:01 PM, Ivan Galkin wrote:
> On Wed, 2025-12-03 at 11:42 +0200, Vladimir Oltean wrote:
>> [You don't often get email from vladimir.oltean@nxp.com. Learn why
>> this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> On Sun, Nov 30, 2025 at 01:58:34AM +0100, Marek Vasut wrote:
>>> Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-
>>> CG,
>>> RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
>>> follows EMI improvement application note Rev. 1.2 for these PHYs.
>>>
>>> The current implementation enables SSC for both RXC and SYSCLK
>>> clock
>>> signals. Introduce new DT property 'realtek,ssc-enable' to enable
>>> the
>>> SSC mode.
>>>
>>> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
>>> ---
>>> Cc: "David S. Miller" <davem@davemloft.net>
>>> Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
>>> Cc: Andrew Lunn <andrew@lunn.ch>
>>> Cc: Conor Dooley <conor+dt@kernel.org>
>>> Cc: Eric Dumazet <edumazet@google.com>
>>> Cc: Florian Fainelli <f.fainelli@gmail.com>
>>> Cc: Heiner Kallweit <hkallweit1@gmail.com>
>>> Cc: Jakub Kicinski <kuba@kernel.org>
>>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
>>> Cc: Michael Klein <michael@fossekall.de>
>>> Cc: Paolo Abeni <pabeni@redhat.com>
>>> Cc: Rob Herring <robh@kernel.org>
>>> Cc: Russell King <linux@armlinux.org.uk>
>>> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
>>> Cc: devicetree@vger.kernel.org
>>> Cc: netdev@vger.kernel.org
>>> ---
>>>   drivers/net/phy/realtek/realtek_main.c | 47
>>> ++++++++++++++++++++++++++
>>>   1 file changed, 47 insertions(+)
>>>
>>> diff --git a/drivers/net/phy/realtek/realtek_main.c
>>> b/drivers/net/phy/realtek/realtek_main.c
>>> index 67ecf3d4af2b1..b1b48936d6422 100644
>>> --- a/drivers/net/phy/realtek/realtek_main.c
>>> +++ b/drivers/net/phy/realtek/realtek_main.c
>>> @@ -74,11 +74,17 @@
>>>
>>>   #define RTL8211F_PHYCR2                                0x19
>>>   #define RTL8211F_CLKOUT_EN                     BIT(0)
>>> +#define RTL8211F_SYSCLK_SSC_EN                 BIT(3)
>>>   #define RTL8211F_PHYCR2_PHY_EEE_ENABLE         BIT(5)
>>>
>>>   #define RTL8211F_INSR_PAGE                     0xa43
>>>   #define RTL8211F_INSR                          0x1d
>>>
>>> +/* RTL8211F SSC settings */
>>> +#define RTL8211F_SSC_PAGE                      0xc44
>>> +#define RTL8211F_SSC_RXC                       0x13
>>> +#define RTL8211F_SSC_SYSCLK                    0x17
>>> +
>>>   /* RTL8211F LED configuration */
>>>   #define RTL8211F_LEDCR_PAGE                    0xd04
>>>   #define RTL8211F_LEDCR                         0x10
>>> @@ -203,6 +209,7 @@ MODULE_LICENSE("GPL");
>>>   struct rtl821x_priv {
>>>          bool enable_aldps;
>>>          bool disable_clk_out;
>>> +       bool enable_ssc;
>>>          struct clk *clk;
>>>          /* rtl8211f */
>>>          u16 iner;
>>> @@ -266,6 +273,8 @@ static int rtl821x_probe(struct phy_device
>>> *phydev)
>>>                                                     "realtek,aldps-
>>> enable");
>>>          priv->disable_clk_out = of_property_read_bool(dev->of_node,
>>>                                                       
>>> "realtek,clkout-disable");
>>> +       priv->enable_ssc = of_property_read_bool(dev->of_node,
>>> +                                                "realtek,ssc-
>>> enable");
>>>
>>>          phydev->priv = priv;
>>>
>>> @@ -700,6 +709,37 @@ static int rtl8211f_config_phy_eee(struct
>>> phy_device *phydev)
>>>                                  RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);
>>>   }
>>>
>>> +static int rtl8211f_config_ssc(struct phy_device *phydev)
>>> +{
>>> +       struct rtl821x_priv *priv = phydev->priv;
>>> +       struct device *dev = &phydev->mdio.dev;
>>> +       int ret;
>>> +
>>> +       /* The value is preserved if the device tree property is
>>> absent */
>>> +       if (!priv->enable_ssc)
>>> +               return 0;
>>> +
>>> +       /* RTL8211FVD has no PHYCR2 register */
>>> +       if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
>>> +               return 0;
>>
>> Ivan, do your conversations with Realtek support suggest that the VFD
>> PHY variant also supports the spread spectrum clock bits configured
>> here
>> in RTL8211F_PHYCR2?
>>
>>
>>
> 
>  From what I learned from Realtek, the statement about RTL8211F(D)(I)-
> VD-CG not having PHYCR2 (Page 0xa43 Address 0x19) is incorrect. This
> register does exist and manages nearly identical configurations as the
> rest of the RTL8211F series, with the exception of the CLKOUT
> configuration, which has been relocated to a different control
> register. Marek, you can read about my findings here
> https://lore.kernel.org/netdev/20251202-phy_eee-v1-1-fe0bf6ab3df0@axis.com/
> 
> Unfortunately I don't have the complete description of PHYCR2 on this
> particular PHY. I will reach out to Realtek regarding SSC and provide
> an update once I have more information.

I think the bits of interest are PHYCR2 bits 13:12 CLKOUT SSC 
capability, 7 CLKOUT SSC Enable and 3 SYSCLK SSC Enable .

Thank you for this information.

I will send a patchset V2 shortly, with the split configuration that 
follows EMI improvement parameters application note 1.2 and also sets 
the bits in PHYCR2 accordingly .

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

[Ivan Galkin]

On Wed, 2025-12-03 at 11:42 +0200, Vladimir Oltean wrote:
> [You don't often get email from vladimir.oltean@nxp.com. Learn why
> this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Sun, Nov 30, 2025 at 01:58:34AM +0100, Marek Vasut wrote:
> > Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-
> > CG,
> > RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
> > follows EMI improvement application note Rev. 1.2 for these PHYs.
> > 
> > The current implementation enables SSC for both RXC and SYSCLK
> > clock
> > signals. Introduce new DT property 'realtek,ssc-enable' to enable
> > the
> > SSC mode.
> > 
> > Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> > ---
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Conor Dooley <conor+dt@kernel.org>
> > Cc: Eric Dumazet <edumazet@google.com>
> > Cc: Florian Fainelli <f.fainelli@gmail.com>
> > Cc: Heiner Kallweit <hkallweit1@gmail.com>
> > Cc: Jakub Kicinski <kuba@kernel.org>
> > Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> > Cc: Michael Klein <michael@fossekall.de>
> > Cc: Paolo Abeni <pabeni@redhat.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Russell King <linux@armlinux.org.uk>
> > Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> > Cc: devicetree@vger.kernel.org
> > Cc: netdev@vger.kernel.org
> > ---
> >  drivers/net/phy/realtek/realtek_main.c | 47
> > ++++++++++++++++++++++++++
> >  1 file changed, 47 insertions(+)
> > 
> > diff --git a/drivers/net/phy/realtek/realtek_main.c
> > b/drivers/net/phy/realtek/realtek_main.c
> > index 67ecf3d4af2b1..b1b48936d6422 100644
> > --- a/drivers/net/phy/realtek/realtek_main.c
> > +++ b/drivers/net/phy/realtek/realtek_main.c
> > @@ -74,11 +74,17 @@
> > 
> >  #define RTL8211F_PHYCR2                                0x19
> >  #define RTL8211F_CLKOUT_EN                     BIT(0)
> > +#define RTL8211F_SYSCLK_SSC_EN                 BIT(3)
> >  #define RTL8211F_PHYCR2_PHY_EEE_ENABLE         BIT(5)
> > 
> >  #define RTL8211F_INSR_PAGE                     0xa43
> >  #define RTL8211F_INSR                          0x1d
> > 
> > +/* RTL8211F SSC settings */
> > +#define RTL8211F_SSC_PAGE                      0xc44
> > +#define RTL8211F_SSC_RXC                       0x13
> > +#define RTL8211F_SSC_SYSCLK                    0x17
> > +
> >  /* RTL8211F LED configuration */
> >  #define RTL8211F_LEDCR_PAGE                    0xd04
> >  #define RTL8211F_LEDCR                         0x10
> > @@ -203,6 +209,7 @@ MODULE_LICENSE("GPL");
> >  struct rtl821x_priv {
> >         bool enable_aldps;
> >         bool disable_clk_out;
> > +       bool enable_ssc;
> >         struct clk *clk;
> >         /* rtl8211f */
> >         u16 iner;
> > @@ -266,6 +273,8 @@ static int rtl821x_probe(struct phy_device
> > *phydev)
> >                                                    "realtek,aldps-
> > enable");
> >         priv->disable_clk_out = of_property_read_bool(dev->of_node,
> >                                                      
> > "realtek,clkout-disable");
> > +       priv->enable_ssc = of_property_read_bool(dev->of_node,
> > +                                                "realtek,ssc-
> > enable");
> > 
> >         phydev->priv = priv;
> > 
> > @@ -700,6 +709,37 @@ static int rtl8211f_config_phy_eee(struct
> > phy_device *phydev)
> >                                 RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);
> >  }
> > 
> > +static int rtl8211f_config_ssc(struct phy_device *phydev)
> > +{
> > +       struct rtl821x_priv *priv = phydev->priv;
> > +       struct device *dev = &phydev->mdio.dev;
> > +       int ret;
> > +
> > +       /* The value is preserved if the device tree property is
> > absent */
> > +       if (!priv->enable_ssc)
> > +               return 0;
> > +
> > +       /* RTL8211FVD has no PHYCR2 register */
> > +       if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
> > +               return 0;
> 
> Ivan, do your conversations with Realtek support suggest that the VFD
> PHY variant also supports the spread spectrum clock bits configured
> here
> in RTL8211F_PHYCR2?

- Regarding RTL8211F(D)(I)-VD-CG

As I mentioned before, saying that PHYCR2 doesn't exist is incorrect.
However, the SSC settings have indeed been moved away from PHYCR2 as
well.

The procedure for enabling of RXC SSC and CLKOUT SSC is described in
EMI Improvement Application Note v1.0 for RTL8211F(D)(I)-VD-CG.

Enable RXC SSC: Page 0x0d15, register 0x16, Bit 13.
'1' enables default Main Tone Degrade option (aka "middle").

Enable CLK_OUT SSC: This depends on the CLKOUT frequency and the Main
Tone Degrade option.
The sequence is complicated and involves several pages and registers.
The application suggests setting those registers to predefined 16-bit
values, which I struggle to interpret.
I would redirect you to the application note instead. All I can say is
that PHYCR2 (page 0xa43, address 0x19) is not involved.

- Regarding other RTL8211F PHYs.
I compared datasheets for RTL8211F(I)/RTL8211FD(I) and RTL8211FS(I)(-
VS). They both use the following bits:

PHYCR2 (page 0xa43, address 0x19)
bit 3: enables SSC on RXC clock output
bit 7: enables SSC on CLKOUT output clock

Both SSCs are controlled over PHYCR2, which, as far as I can see,
contradicts this patch.
> 

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

[Marek Vasut]

On 12/3/25 3:18 PM, Ivan Galkin wrote:

> - Regarding RTL8211F(D)(I)-VD-CG
> 
> As I mentioned before, saying that PHYCR2 doesn't exist is incorrect.
> However, the SSC settings have indeed been moved away from PHYCR2 as
> well.
> 
> The procedure for enabling of RXC SSC and CLKOUT SSC is described in
> EMI Improvement Application Note v1.0 for RTL8211F(D)(I)-VD-CG.

I have EMI improvement application note v1.2 for RTL8211F(D)(I)-CG .

> Enable RXC SSC: Page 0x0d15, register 0x16, Bit 13.
> '1' enables default Main Tone Degrade option (aka "middle").

Page 0xc44 register 0x13 = 0x5f00

> Enable CLK_OUT SSC: This depends on the CLKOUT frequency and the Main
> Tone Degrade option.
> The sequence is complicated and involves several pages and registers.
> The application suggests setting those registers to predefined 16-bit
> values, which I struggle to interpret.
> I would redirect you to the application note instead. All I can say is
> that PHYCR2 (page 0xa43, address 0x19) is not involved.

Page 0xd09 register 0x10 = 0xcf00
Page 0xa43 register 0x19 = 0x38c3
... and, I also suspect this needs to be done, but is missing in the 
appnote ...
PHYCR2 |= BIT(7) // and maybe also bits 13:12 ?

> - Regarding other RTL8211F PHYs.
> I compared datasheets for RTL8211F(I)/RTL8211FD(I) and RTL8211FS(I)(-
> VS). They both use the following bits:
> 
> PHYCR2 (page 0xa43, address 0x19)
> bit 3: enables SSC on RXC clock output
> bit 7: enables SSC on CLKOUT output clock
> 
> Both SSCs are controlled over PHYCR2, which, as far as I can see,
> contradicts this patch.

The bit 7 part is missing from the EMI appnote for RTL8211F(D)(I)-CG , I 
will add it in V2.

-- 
Best regards,
Marek Vasut

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

[Marek Vasut]

On 12/3/25 10:42 AM, Vladimir Oltean wrote:

Hello Vladimir,

>> +       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. Does it use the RGMII RXC as a system clock?

I believe dwmac (stmmac) uses RXC to drive at least (part of) its DMA.

+CC Christophe

> 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 can split this into realtek,clkout-ssc-enable and realtek,rxc-ssc-enable.

Note that I use this exact configuration with both STM32MP13xx and 
STM32MP25xx RGMII / stmmac .

-- 
Best regards,
Marek Vasut

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

[Russell King (Oracle)]

On Sun, Nov 30, 2025 at 01:58:34AM +0100, Marek Vasut wrote:
> Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
> RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
> follows EMI improvement application note Rev. 1.2 for these PHYs.
> 
> The current implementation enables SSC for both RXC and SYSCLK clock
> signals. Introduce new DT property 'realtek,ssc-enable' to enable the
> SSC mode.

Should there be separate properties for CLKOUT SSC enable and RXC SSC
enable?

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

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

[Vladimir Oltean]

On Wed, Dec 03, 2025 at 10:18:35AM +0000, Russell King (Oracle) wrote:
> On Sun, Nov 30, 2025 at 01:58:34AM +0100, Marek Vasut wrote:
> > Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
> > RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
> > follows EMI improvement application note Rev. 1.2 for these PHYs.
> > 
> > The current implementation enables SSC for both RXC and SYSCLK clock
> > signals. Introduce new DT property 'realtek,ssc-enable' to enable the
> > SSC mode.
> 
> Should there be separate properties for CLKOUT SSC enable and RXC SSC
> enable?

That's what we're trying to work out. I was going to try and give an
example (based on stmmac) why you wouldn't want RXC SSC but you'd still
want CLKOUT SSC, but it doesn't seem to hold water based on your feedback.
Having one device tree property to control both clocks is a bit simpler.

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

[Russell King (Oracle)]

On Wed, Dec 03, 2025 at 02:34:30PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 03, 2025 at 10:18:35AM +0000, Russell King (Oracle) wrote:
> > On Sun, Nov 30, 2025 at 01:58:34AM +0100, Marek Vasut wrote:
> > > Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
> > > RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
> > > follows EMI improvement application note Rev. 1.2 for these PHYs.
> > > 
> > > The current implementation enables SSC for both RXC and SYSCLK clock
> > > signals. Introduce new DT property 'realtek,ssc-enable' to enable the
> > > SSC mode.
> > 
> > Should there be separate properties for CLKOUT SSC enable and RXC SSC
> > enable?
> 
> That's what we're trying to work out. I was going to try and give an
> example (based on stmmac) why you wouldn't want RXC SSC but you'd still
> want CLKOUT SSC, but it doesn't seem to hold water based on your feedback.
> Having one device tree property to control both clocks is a bit simpler.

The problem I see is that if we introduce a single property for both,
we then need to maintain this single property ad infinitum. If we
later find that we need separate control, we could end up with three
properties - the combined one, and two for individual controls.

If we are to go with a single property, then I think we should have at
least discussed what we would do if we need separate control.

If we go with two properties now, then we don't have to consider this,
and we will only ever have the two properties rather than three.

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

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

[Marek Vasut]

On 12/3/25 6:35 PM, Russell King (Oracle) wrote:
> On Wed, Dec 03, 2025 at 02:34:30PM +0200, Vladimir Oltean wrote:
>> On Wed, Dec 03, 2025 at 10:18:35AM +0000, Russell King (Oracle) wrote:
>>> On Sun, Nov 30, 2025 at 01:58:34AM +0100, Marek Vasut wrote:
>>>> Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
>>>> RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
>>>> follows EMI improvement application note Rev. 1.2 for these PHYs.
>>>>
>>>> The current implementation enables SSC for both RXC and SYSCLK clock
>>>> signals. Introduce new DT property 'realtek,ssc-enable' to enable the
>>>> SSC mode.
>>>
>>> Should there be separate properties for CLKOUT SSC enable and RXC SSC
>>> enable?
>>
>> That's what we're trying to work out. I was going to try and give an
>> example (based on stmmac) why you wouldn't want RXC SSC but you'd still
>> want CLKOUT SSC, but it doesn't seem to hold water based on your feedback.
>> Having one device tree property to control both clocks is a bit simpler.
> 
> The problem I see is that if we introduce a single property for both,
> we then need to maintain this single property ad infinitum. If we
> later find that we need separate control, we could end up with three
> properties - the combined one, and two for individual controls.
> 
> If we are to go with a single property, then I think we should have at
> least discussed what we would do if we need separate control.
> 
> If we go with two properties now, then we don't have to consider this,
> and we will only ever have the two properties rather than three.
It seems the CLKOUT and RXC SSC can be enabled entirely separately, so I 
think two properties are the way to go ?

Re: [net-next,PATCH 1/3] dt-bindings: net: realtek,rtl82xx: Keep property list sorted

[Rob Herring (Arm)]

On Sun, 30 Nov 2025 01:58:32 +0100, Marek Vasut wrote:
> Sort the documented properties alphabetically, no functional change.
> 
> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Klein <michael@fossekall.de>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
>  .../devicetree/bindings/net/realtek,rtl82xx.yaml          | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 428, in get_or_retrieve
    resource = registry._retrieve(uri)
  File "/usr/local/lib/python3.13/dist-packages/dtschema/validator.py", line 426, in retrieve
    return DRAFT201909.create_resource(self.schemas[uri])
                                       ~~~~~~~~~~~~^^^^^
KeyError: 'http://devicetree.org/schemas/thermal/qcom-tsens.yaml'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 682, in lookup
    retrieved = self._registry.get_or_retrieve(uri)
  File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 435, in get_or_retrieve
    raise exceptions.Unretrievable(ref=uri) from error
referencing.exceptions.Unretrievable: 'http://devicetree.org/schemas/thermal/qcom-tsens.yaml'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/validators.py", line 463, in _validate_reference
    resolved = self._resolver.lookup(ref)
  File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 686, in lookup
    raise exceptions.Unresolvable(ref=ref) from error
referencing.exceptions.Unresolvable: /schemas/thermal/qcom-tsens.yaml#

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/bin/dt-validate", line 8, in <module>
    sys.exit(main())
             ~~~~^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 158, in main
    sg.check_dtb(filename)
    ~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 95, in check_dtb
    self.check_subtree(dt, subtree, False, "/", "/", filename)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 88, in check_subtree
    self.check_subtree(tree, value, disabled, name, fullname + name, filename)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 88, in check_subtree
    self.check_subtree(tree, value, disabled, name, fullname + name, filename)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 83, in check_subtree
    self.check_node(tree, subtree, disabled, nodename, fullname, filename)
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 34, in check_node
    for error in self.validator.iter_errors(node, filter=match_schema_file,
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                            compatible_match=compatible_match):
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/validator.py", line 448, in iter_errors
    for error in self.DtValidator(schema, registry=self.registry).iter_errors(instance):
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/validators.py", line 384, in iter_errors
    for error in errors:
                 ^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/_keywords.py", line 296, in properties
    yield from validator.descend(
    ...<4 lines>...
    )
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/validators.py", line 432, in descend
    for error in errors:
                 ^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/_keywords.py", line 275, in ref
    yield from validator._validate_reference(ref=ref, instance=instance)
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/validators.py", line 465, in _validate_reference
    raise exceptions._WrappedReferencingError(err) from err
jsonschema.exceptions._WrappedReferencingError: Unresolvable: /schemas/thermal/qcom-tsens.yaml#
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 428, in get_or_retrieve
    resource = registry._retrieve(uri)
  File "/usr/local/lib/python3.13/dist-packages/dtschema/validator.py", line 426, in retrieve
    return DRAFT201909.create_resource(self.schemas[uri])
                                       ~~~~~~~~~~~~^^^^^
KeyError: 'http://devicetree.org/schemas/thermal/qcom-tsens.yaml'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 682, in lookup
    retrieved = self._registry.get_or_retrieve(uri)
  File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 435, in get_or_retrieve
    raise exceptions.Unretrievable(ref=uri) from error
referencing.exceptions.Unretrievable: 'http://devicetree.org/schemas/thermal/qcom-tsens.yaml'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/validators.py", line 463, in _validate_reference
    resolved = self._resolver.lookup(ref)
  File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 686, in lookup
    raise exceptions.Unresolvable(ref=ref) from error
referencing.exceptions.Unresolvable: /schemas/thermal/qcom-tsens.yaml#

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/bin/dt-validate", line 8, in <module>
    sys.exit(main())
             ~~~~^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 158, in main
    sg.check_dtb(filename)
    ~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 95, in check_dtb
    self.check_subtree(dt, subtree, False, "/", "/", filename)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 88, in check_subtree
    self.check_subtree(tree, value, disabled, name, fullname + name, filename)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 88, in check_subtree
    self.check_subtree(tree, value, disabled, name, fullname + name, filename)
    ~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 83, in check_subtree
    self.check_node(tree, subtree, disabled, nodename, fullname, filename)
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/dtb_validate.py", line 34, in check_node
    for error in self.validator.iter_errors(node, filter=match_schema_file,
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                            compatible_match=compatible_match):
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/dtschema/validator.py", line 448, in iter_errors
    for error in self.DtValidator(schema, registry=self.registry).iter_errors(instance):
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/validators.py", line 384, in iter_errors
    for error in errors:
                 ^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/_keywords.py", line 296, in properties
    yield from validator.descend(
    ...<4 lines>...
    )
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/validators.py", line 432, in descend
    for error in errors:
                 ^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/_keywords.py", line 334, in allOf
    yield from validator.descend(instance, subschema, schema_path=index)
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/validators.py", line 432, in descend
    for error in errors:
                 ^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/_keywords.py", line 275, in ref
    yield from validator._validate_reference(ref=ref, instance=instance)
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/dist-packages/jsonschema/validators.py", line 465, in _validate_reference
    raise exceptions._WrappedReferencingError(err) from err
jsonschema.exceptions._WrappedReferencingError: Unresolvable: /schemas/thermal/qcom-tsens.yaml#

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20251130005843.234656-1-marek.vasut@mailbox.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.