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

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: <67b5f5b5-caf9-4dcc-b84d-a7ce338fc25d@kernel.org>
Date: Wed, 3 Dec 2025 08:56:24 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Marek Vasut <marek.vasut@...lbox.org>, netdev@...r.kernel.org
Cc: "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>, Russell King <linux@...linux.org.uk>,
 Vladimir Oltean <vladimir.oltean@....com>, devicetree@...r.kernel.org
Subject: Re: [net-next,PATCH 2/3] dt-bindings: net: realtek,rtl82xx: Document
 realtek,ssc-enable property

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