-----原始邮件-----
发件人: "Bo Gan" [off-list ref]
发送时间:2026-01-23 15:39:29 (星期五)
收件人: "Andrew Lunn" [off-list ref], 李志 [off-list ref]
抄送: 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
主题: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control

Hi Andrew,

On 1/22/26 19:19, Andrew Lunn wrote:

quoted

quoted

quoted

You say internal. So the skew is fixed, it is a property of the
silicon? If so, why a DT property? Why not just hard code it in the
driver? Since it is internal, different boards should not need it set
differently?

Thanks for the question.

EIC7700 has two Ethernet MACs. Only eth1 has this internal RXC/RXD skew,
eth0 does not.

So this is not a chip-wide constant that can be hardcoded in the driver.
We need a way to distinguish the two MAC instances, which is why this is
described per-port in DTS.

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
can provide some sane defaults, and the board vendor can later override
them if the mac/phy requires further tuning. Applying such tuning by
the address of MAC seems messy and it hides the parameters used behind
driver. Through DT, everything becomes really clear.

I assume this is not uncommon: E.g., starfive/jh7110:
https://lore.kernel.org/all/20230714104521.18751-3-samin.guo@starfivetech.com/ (local)

BTW, no need to worry about backward compat. ESWIN hasn't checked-in any
DT for eth yet. As you and Russell said, they need to do it, pronto.

Yes, this can be hardcoded for eth1, similar to what is done in
dwmac-loongson1.c.

However, considering EIC7702, which integrates two EIC7700 dies and thus
has four MACs in total, we believe describing this via DTS is more
appropriate. We are currently working on upstreaming the DTS support for
EIC7702.

With the DT approach, the internal RXC/RXD skew can be described explicitly
for gmac1 and gmac3, without requiring changes to dwmac-eic7700.c when
bringing up EIC7702.

As Bo Gan also mentioned, there are vendors handling similar internal
quirks through DT configuration.

--
Li Zhi