netdev - Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control

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] [day] [month] [year] [list]

Message-ID: <009aefc4-fbc9-4f91-9230-23d18c281bf3@gmail.com>
Date: Fri, 23 Jan 2026 20:57:23 -0800
From: Bo Gan <ganboing@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, 李志
 <lizhi2@...incomputing.com>, devicetree@...r.kernel.org,
 andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
 kuba@...nel.org, robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 netdev@...r.kernel.org, pabeni@...hat.com, mcoquelin.stm32@...il.com,
 alexandre.torgue@...s.st.com, rmk+kernel@...linux.org.uk,
 linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 ningyu@...incomputing.com, linmin@...incomputing.com,
 pinkesh.vaghela@...fochips.com, weishangjuan@...incomputing.com
Subject: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling
 control

Hi Andrew,

On 1/23/26 11:43, Andrew Lunn wrote:
> On Fri, Jan 23, 2026 at 02:47:18AM -0800, Bo Gan wrote:
>> Hi Krzysztof,
>>
>> On 1/23/26 02:07, Krzysztof Kozlowski wrote:
>>> On 23/01/2026 08:39, Bo Gan wrote:
>>>>> I assume the address of the interface is fixed. So you can just key
>>>>> off that to distinguish the two instances.
>>>>>
>>>>> Since this is an internal property, not a board property, it is not
>>>>> clear it actually belongs on DT.
>>>>>
>>>>>        Andrew
>>>>
>>>> IMO, they should be in DT to provide maximum flexibility. The SoC .dtsi
>>>
>>> This is not the purpose of DT. Please rather use arguments in terms of
>>> DT rules (see docs, presentations).
>>>
>> Any examples? links? Thank you for your patience.
>>
>> I'd say if the board .dts never overrides the eswin,rx-clk-invert, (E.g.,
>> the SoC .dtsi has rx-clk-invert, later the board /delete-property/'s it)
>> then yes, it can be treated as something inherent to the mac, and then
>> "use arguments in terms of DT rules". I was thinking about use cases like:
>> https://lore.kernel.org/all/20230714104521.18751-3-samin.guo@starfivetech.com/
> 
> Your device should be compliant with the RGMII standard by
> default. There should not be a DT property to ask it nicely to follow
> the standard.
> 
> Properties like
> 
> motorcomm,tx-clk-adj-enabled;
> motorcomm,tx-clk-100-inverted;
> motorcomm,tx-clk-1000-inverted;
> 
> are for broken boards which break the standard and require the MAC do
> also break the standard so that everything works. We should not start
> out with the assumption you need to support broken boards which ignore
> the standard.

My reading of
https://lore.kernel.org/all/308b676.2d03.19bb0caebed.Coremail.lizhi2@eswincomputing.com/
is that the eth1 MAC is already breaking the standard at SoC level, and
the boards can un-break it or break it even more. Hence, even for proper
designed board, SoC .dtsi still needs eswin,rx-clk-invert (for *eth1*).
For broken boards, they may require eswin,rx-clk-invert for *eth0*, even
though SoC doesn't mandate. For *eth1* broken boards might have to
/delete-property/ it and use eswin,tx-clk-invert or something else.
It's clearer to have all these parameters visible and explicit in DT.

ESWIN, please correct me if I'm wrong.

P.S. I'm not affiliated to ESWIN, but I do own eic7700/hifive-premier
board, and I can talk to someone who owns eic7700/megrez. I can help
validating ESWIN's patches independently.

> 
>         Andrew
> 
Bo