netdev - Re: 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: <73ea5619.2b71.19bf847c80d.Coremail.linmin@eswincomputing.com>
Date: Mon, 26 Jan 2026 11:10:12 +0800 (GMT+08:00)
From: "Min Lin" <linmin@...incomputing.com>
To: "Bo Gan" <ganboing@...il.com>
Cc: "Andrew Lunn" <andrew@...n.ch>, "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, pinkesh.vaghela@...fochips.com,
	weishangjuan@...incomputing.com
Subject: Re: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock
 sampling control

Hi Bo Gan


> -----Original Messages-----
> From: "Bo Gan" <ganboing@...il.com>
> Send time:Saturday, 24/01/2026 12:57:23
> 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.

Due to chip backend reasons, there is already a ~4-5ns skew between the RX
clock and data of the eth1 MAC controller inside the silicon.
The RX clock must be inverted since it's not able to match the RGMII
timing only by adding rx-internal-delay-ps on the MAC and 2ns delay on the PHY.
So, yes, even for a properly designed board, eth1 still requires
eswin,rx-clk-invert.

This is a chip-level defect, and indeed, it breaks the RGMII standard at
the SoC level.

For the TX of eth1, there is also a skew between the TX clock and data on
the MAC controller inside the silicon. This skew happens to be approximately ~2ns.
Therefore, we can consider that the 2ns delay of TX is provided by the MAC,
so the TX is compliant with the RGMII standard.


Regards,
Lin Min