Hi Bo Gan

-----Original Messages-----
From: "Bo Gan" <redacted>
Send time:Saturday, 24/01/2026 12:57:23
To: "Andrew Lunn" <andrew@lunn.ch>
Cc: "Krzysztof Kozlowski" <krzk@kernel.org>, 李志 <redacted>, devicetree@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, rmk+kernel@armlinux.org.uk, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ningyu@eswincomputing.com, linmin@eswincomputing.com, pinkesh.vaghela@einfochips.com, weishangjuan@eswincomputing.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:

quoted

On Fri, Jan 23, 2026 at 02:47:18AM -0800, Bo Gan wrote:

quoted

Hi Krzysztof,

On 1/23/26 02:07, Krzysztof Kozlowski wrote:

quoted

On 23/01/2026 08:39, Bo Gan wrote:

quoted

quoted

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/ (local)

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/ (local)
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