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: <f0ecb69c-9163-49fd-b74c-0893d9b95593@mailbox.org>
Date: Wed, 3 Dec 2025 21:16:13 +0100
From: Marek Vasut <marek.vasut@...lbox.org>
To: Krzysztof Kozlowski <krzk@...nel.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 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.