From: Zhi Li <lizhi2@eswincomputing.com>
The second Ethernet controller (eth1) on the EIC7700 SoC may experience
RX data sampling issues at high speed due to EIC7700-specific receive
clock to data skew at the MAC input.
Add vendor-specific device tree properties to describe optional receive
and transmit clock inversion controls used to compensate for the EIC7700
Ethernet MAC, which may be required to ensure correct RX sampling at
high speed.
This binding also updates the enum values of the rx-internal-delay-ps
and tx-internal-delay-ps properties to reflect the actual delay step
resolution implemented by the EIC7700 hardware. The hardware applies
delay in 20 ps increments, while the previous enum values were based on
an incorrect mapping. This change corrects the DT-to-hardware mapping
without changing the meaning of the delay properties.
In addition, the binding also describes the relevant HSP CSR registers
accessed by the MAC. The TXD and RXD delay control registers are included
so the driver can explicitly clear any residual configuration left by
the bootloader, ensuring the hardware is initialized into a known and
deterministic state.
Fixes: 888bd0eca93c ("dt-bindings: ethernet: eswin: Document for EIC7700 SoC")
Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
---
.../bindings/net/eswin,eic7700-eth.yaml | 57 +++++++++++++++++--
1 file changed, 51 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
index 91e8cd1db67b..c948f62e97e9 100644
--- a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
+++ b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
@@ -63,10 +63,25 @@ properties:
- const: stmmaceth
rx-internal-delay-ps:
- enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
+ enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400]
tx-internal-delay-ps:
- enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
+ enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400]
+
+ eswin,rx-clk-invert:
+ description:
+ Invert the receive clock sampling polarity at the MAC input.
+ This property may be used to compensate for SoC-specific
+ receive clock to data skew and help ensure correct RX data
+ sampling at high speed.
+ type: boolean
+
+ eswin,tx-clk-invert:
+ description:
+ Invert the transmit clock polarity driven by the MAC.
+ This property provides SoC-specific transmit clock control
+ when required by the platform.
+ type: boolean
eswin,hsp-sp-csr:
description:
@@ -81,7 +96,9 @@ properties:
or external clock selection
- description: Offset of AXI clock controller Low-Power request
register
+ - description: Offset of register controlling TXD delay
- description: Offset of register controlling TX/RX clock delay
+ - description: Offset of register controlling RXD delay
required:
- compatible
@@ -111,17 +128,45 @@ examples:
interrupts = <61>;
interrupt-names = "macirq";
phy-mode = "rgmii-id";
- phy-handle = <&phy0>;
+ phy-handle = <&gmac0_phy0>;
resets = <&reset 95>;
reset-names = "stmmaceth";
+ rx-internal-delay-ps = <20>;
+ tx-internal-delay-ps = <100>;
+ eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x114 0x118 0x11c>;
+ snps,axi-config = <&stmmac_axi_setup_gmac0>;
+ snps,aal;
+ snps,fixed-burst;
+ snps,tso;
+ stmmac_axi_setup_gmac0: stmmac-axi-config {
+ snps,blen = <0 0 0 0 16 8 4>;
+ snps,rd_osr_lmt = <2>;
+ snps,wr_osr_lmt = <2>;
+ };
+ };
+
+ ethernet@50410000 {
+ compatible = "eswin,eic7700-qos-eth", "snps,dwmac-5.20";
+ reg = <0x50410000 0x10000>;
+ clocks = <&d0_clock 186>, <&d0_clock 171>, <&d0_clock 40>,
+ <&d0_clock 194>;
+ clock-names = "axi", "cfg", "stmmaceth", "tx";
+ interrupt-parent = <&plic>;
+ interrupts = <70>;
+ interrupt-names = "macirq";
+ phy-mode = "rgmii-rxid";
+ phy-handle = <&gmac1_phy0>;
+ resets = <&reset 94>;
+ reset-names = "stmmaceth";
rx-internal-delay-ps = <200>;
tx-internal-delay-ps = <200>;
- eswin,hsp-sp-csr = <&hsp_sp_csr 0x100 0x108 0x118>;
- snps,axi-config = <&stmmac_axi_setup>;
+ eswin,rx-clk-invert;
+ eswin,hsp-sp-csr = <&hsp_sp_csr 0x200 0x208 0x214 0x218 0x21c>;
+ snps,axi-config = <&stmmac_axi_setup_gmac1>;
snps,aal;
snps,fixed-burst;
snps,tso;
- stmmac_axi_setup: stmmac-axi-config {
+ stmmac_axi_setup_gmac1: stmmac-axi-config {
snps,blen = <0 0 0 0 16 8 4>;
snps,rd_osr_lmt = <2>;
snps,wr_osr_lmt = <2>;
--
2.25.1> rx-internal-delay-ps: > - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400] > + enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400] > > tx-internal-delay-ps: > - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400] > + enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400] You need to add some text to the Changelog to indicate why this is safe to do, and will not cause any regressions for DT blobs already in use. Backwards compatibility is very important and needs to be addressed. > + eswin,rx-clk-invert: > + description: > + Invert the receive clock sampling polarity at the MAC input. > + This property may be used to compensate for SoC-specific > + receive clock to data skew and help ensure correct RX data > + sampling at high speed. > + type: boolean This does not make too much sense to me. The RGMII standard indicates sampling happens on both edges of the clock. The rising edge is for the lower 4 bits, the falling edge for the upper 4 bits. Flipping the polarity would only swap the nibbles around. Andrew
> -----原始邮件-----
> 发件人: "Andrew Lunn" <andrew@lunn.ch>
> 发送时间:2026-01-10 02:27:54 (星期六)
> 收件人: lizhi2@eswincomputing.com
> 抄送: 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
>
> > rx-internal-delay-ps:
> > - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
> > + enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400]
> >
> > tx-internal-delay-ps:
> > - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
> > + enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400]
>
> You need to add some text to the Changelog to indicate why this is
> safe to do, and will not cause any regressions for DT blobs already in
> use. Backwards compatibility is very important and needs to be
> addressed.
>
Thanks for the review.
Understood. Our understanding is that changing the allowed values of
rx-internal-delay-ps / tx-internal-delay-ps needs to be explicitly
justified as DT ABI safe.
For v2, we are planning to replace the enum with a min/max constraint.
These properties carry literal delay values in picoseconds, and all
previously valid values will remain valid and retain the same meaning.
Existing DT blobs will therefore continue to work unchanged.
We will also add explicit text to the commit message explaining why this
change is DT ABI safe and why no regressions are expected.
> > + eswin,rx-clk-invert:
> > + description:
> > + Invert the receive clock sampling polarity at the MAC input.
> > + This property may be used to compensate for SoC-specific
> > + receive clock to data skew and help ensure correct RX data
> > + sampling at high speed.
> > + type: boolean
>
> This does not make too much sense to me. The RGMII standard indicates
> sampling happens on both edges of the clock. The rising edge is for
> the lower 4 bits, the falling edge for the upper 4 bits. Flipping the
> polarity would only swap the nibbles around.
>
You are correct about the RGMII specification. The intent of
eswin,rx-clk-invert is not to change the RGMII sampling rule, but to
compensate for SoC-internal RXC-to-RXD skew and restore the correct
sampling relationship at the MAC input.
On EIC7700, RXC and RXD experience an internal skew before reaching the
MAC. At high speed, this can shift the effective sampling point by
approximately half a cycle, causing the MAC to sample the wrong nibble
on each edge.
Conceptually, the situations are as follows.
RGMII-specified behavior (correct):
RXC: __/‾‾\__/‾‾\__
↑ ↓
| |
| |
| +--------- sample RXD[4:7]
+------------ sample RXD[0:3]
SoC-internal skew causing incorrect sampling (without invert):
RXC: __/‾‾\__/‾‾\__
↑ ↓
| |
| |
| +--------- sample RXD[0:3] (wrong)
+------------ sample RXD[4:7] (wrong)
After enabling internal RX clock invert:
RXC: __/‾‾\__/‾‾\__
↑ ↓
| |
| |
| +--------- sample RXD[4:7] (correct)
+------------ sample RXD[0:3] (correct)
The invert control restores sampling of RXD[0:3] on the rising edge
and RXD[4:7] on the falling edge, exactly as defined by the RGMII
specification. No protocol-level behavior or edge assignment is
changed.
Thanks,
Li Zhi
> On EIC7700, RXC and RXD experience an internal skew before reaching the > MAC. At high speed, this can shift the effective sampling point by > approximately half a cycle, causing the MAC to sample the wrong nibble > on each edge. 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? Andrew
> -----原始邮件----- > 发件人: "Andrew Lunn" <andrew@lunn.ch> > 发送时间:2026-01-22 21:32:34 (星期四) > 收件人: 李志 <lizhi2@eswincomputing.com> > 抄送: 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: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control > > > On EIC7700, RXC and RXD experience an internal skew before reaching the > > MAC. At high speed, this can shift the effective sampling point by > > approximately half a cycle, causing the MAC to sample the wrong nibble > > on each edge. > > 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. -- Li Zhi
> > 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
Hi Andrew, On 1/22/26 19:19, Andrew Lunn wrote: >>> 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/ 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. Bo
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). We really do not care about maximum flexibility. Best regards, Krzysztof
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/ > We really do not care about maximum flexibility. > > Best regards, > Krzysztof Bo
On 23/01/2026 11:47, 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. Really, doing simple search for it is your homework, not our task. You need to try harder if you want to prove that you are not wasting our time. Documentation/devicetree/bindings Or any elinux resources or any recent talks of mine. Best regards, Krzysztof
On 1/28/26 02:05, Krzysztof Kozlowski wrote: > On 23/01/2026 11:47, 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. > > Really, doing simple search for it is your homework, not our task. You > need to try harder if you want to prove that you are not wasting our time. > > Documentation/devicetree/bindings > > Or any elinux resources or any recent talks of mine. > > Best regards, > Krzysztof You brought up the "use arguments in terms of DT rules" approach. and all I ask is just some pointers to make sure I'm not misinterpreting. No offense, but The way you slamming people w/ "not doing their homework" is truly not constructive. Bo
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.
Andrew
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
Hi Bo Gan > -----Original Messages----- > From: "Bo Gan" <ganboing@gmail.com> > Send time:Saturday, 24/01/2026 12:57:23 > To: "Andrew Lunn" <andrew@lunn.ch> > Cc: "Krzysztof Kozlowski" <krzk@kernel.org>, 李志 <lizhi2@eswincomputing.com>, 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: > > 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
On Mon, Jan 26, 2026 at 11:10:12AM +0800, Min Lin wrote: > 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. Let's analyse this. TXC / RXC TXC / RXC Speed Clock rate Clock period 1G 125MHz 8ns 100M 25MHz 40ns 10M 2.5MHz 400ns The required skew for TXC and RXC at the receiver is specified to be between 1 and 2.6ns irrespective of the speed. The edge of the clock is also important: the rising edge indicates the lower 4 bits, and the falling edge indicates the upper 4 bits. At 1G speed, with a "4 to 5ns" skew in the chip. If this is accurate, then inverting the clock and adding 1ns of additional skew by some means (PCB trace, or at the MAC or PHY) will give the required clock at the receiver. The timing table in the RGMII standard (3.3) allows for Tcyc (the clock rate) to be scaled, but there is no allowance for scaling TskewR (the required 1 to 2.6ns skew.) This skew parameter is fixed. So, at the other speeds, you are completely unable to meet the timing specification, whether irrespective of the clock inversion. In effect, the only speed that you can meet the specification is 1G. Thus, I think this is something that needs a lot more than just "do we need to invert the clock". You also need to prevent 10M and 100M being supported IMHO. I can't get my head around why someone would come up with this crazy, crippled design, but maybe they didn't bother reading the RGMII specification and ensuring that their design met the requirements before implementing the hardware. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Hi Russell, > -----Original Messages----- > From: "Russell King (Oracle)" <linux@armlinux.org.uk> > Send time:Tuesday, 27/01/2026 02:29:09 > To: "Min Lin" <linmin@eswincomputing.com> > Cc: "Bo Gan" <ganboing@gmail.com>, "Andrew Lunn" <andrew@lunn.ch>, "Krzysztof Kozlowski" <krzk@kernel.org>, 李志 <lizhi2@eswincomputing.com>, 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, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ningyu@eswincomputing.com, pinkesh.vaghela@einfochips.com, weishangjuan@eswincomputing.com > Subject: Re: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control > > On Mon, Jan 26, 2026 at 11:10:12AM +0800, Min Lin wrote: > > 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. > > Let's analyse this. > > TXC / RXC TXC / RXC > Speed Clock rate Clock period > 1G 125MHz 8ns > 100M 25MHz 40ns > 10M 2.5MHz 400ns > > The required skew for TXC and RXC at the receiver is specified to be > between 1 and 2.6ns irrespective of the speed. The edge of the clock > is also important: the rising edge indicates the lower 4 bits, and > the falling edge indicates the upper 4 bits. > > At 1G speed, with a "4 to 5ns" skew in the chip. If this is accurate, > then inverting the clock and adding 1ns of additional skew by some > means (PCB trace, or at the MAC or PHY) will give the required clock > at the receiver. > Yes, that's exactly the case. > The timing table in the RGMII standard (3.3) allows for Tcyc (the > clock rate) to be scaled, but there is no allowance for scaling > TskewR (the required 1 to 2.6ns skew.) This skew parameter is > fixed. > > So, at the other speeds, you are completely unable to meet the timing > specification, whether irrespective of the clock inversion. In effect, > the only speed that you can meet the specification is 1G. > The timing table in the RGMII standard(3.3) says the max value of Tskew for 10/100 is unspecified. Quotation:"note1: ...,For 10/100 the Max value is unspecified." I think for 10/100, the "4 to 5ns" skew in the chip doesn't break the standard. At 10/100 speeds, it meets the timing specification without having to to add clock inversion. In practice, it works at 10/100 speeds in the rgmii-id phy mode. > Thus, I think this is something that needs a lot more than just "do > we need to invert the clock". You also need to prevent 10M and 100M > being supported IMHO. > Regards, Lin Min
Hi Min, Russell, Krzysztof, On 1/26/26 22:14, Min Lin wrote: > Hi Russell, > > >> -----Original Messages----- >> From: "Russell King (Oracle)" <linux@armlinux.org.uk> >> Send time:Tuesday, 27/01/2026 02:29:09 >> To: "Min Lin" <linmin@eswincomputing.com> >> Cc: "Bo Gan" <ganboing@gmail.com>, "Andrew Lunn" <andrew@lunn.ch>, "Krzysztof Kozlowski" <krzk@kernel.org>, 李志 <lizhi2@eswincomputing.com>, 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, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ningyu@eswincomputing.com, pinkesh.vaghela@einfochips.com, weishangjuan@eswincomputing.com >> Subject: Re: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control >> >> On Mon, Jan 26, 2026 at 11:10:12AM +0800, Min Lin wrote: >>> 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. >> >> Let's analyse this. >> >> TXC / RXC TXC / RXC >> Speed Clock rate Clock period >> 1G 125MHz 8ns >> 100M 25MHz 40ns >> 10M 2.5MHz 400ns >> >> The required skew for TXC and RXC at the receiver is specified to be >> between 1 and 2.6ns irrespective of the speed. The edge of the clock >> is also important: the rising edge indicates the lower 4 bits, and >> the falling edge indicates the upper 4 bits. >> >> At 1G speed, with a "4 to 5ns" skew in the chip. If this is accurate, >> then inverting the clock and adding 1ns of additional skew by some >> means (PCB trace, or at the MAC or PHY) will give the required clock >> at the receiver. >> > > Yes, that's exactly the case. > >> The timing table in the RGMII standard (3.3) allows for Tcyc (the >> clock rate) to be scaled, but there is no allowance for scaling >> TskewR (the required 1 to 2.6ns skew.) This skew parameter is >> fixed. >> >> So, at the other speeds, you are completely unable to meet the timing >> specification, whether irrespective of the clock inversion. In effect, >> the only speed that you can meet the specification is 1G. >> > > The timing table in the RGMII standard(3.3) says the max value of Tskew > for 10/100 is unspecified. > Quotation:"note1: ...,For 10/100 the Max value is unspecified." > > I think for 10/100, the "4 to 5ns" skew in the chip doesn't break the > standard. At 10/100 speeds, it meets the timing specification without > having to to add clock inversion. > In practice, it works at 10/100 speeds in the rgmii-id phy mode. > >> Thus, I think this is something that needs a lot more than just "do >> we need to invert the clock". You also need to prevent 10M and 100M >> being supported IMHO. >> > > Regards, > Lin Min I had an offline discussion with Yao Zi and others regarding this. We feel like the proper way for ESWIN to deal with this broken eth1 is to have a different compatible string just for eth1, where it can be associated with platform data with quirks to do eswin,rx-clk-invert at 1G. The property is therefore not required to be exposed in DT. (Pretend it conforms to spec for 1G). Need confirmation for 10M/100M, though. I double checked Lin Min's claim, and indeed the spec says "For 10/100 the Max value is unspecified": https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/20655/1/RGMIIv2_0_final_hp.pdf Thoughts? Bo
Hi Bo Gan, > -----Original Messages----- > From: "Bo Gan" <ganboing@gmail.com> > Send time:Wednesday, 28/01/2026 10:38:28 > To: "Min Lin" <linmin@eswincomputing.com>, "Russell King (Oracle)" <linux@armlinux.org.uk> > Cc: "Andrew Lunn" <andrew@lunn.ch>, "Krzysztof Kozlowski" <krzk@kernel.org>, 李志 <lizhi2@eswincomputing.com>, 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, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ningyu@eswincomputing.com, pinkesh.vaghela@einfochips.com, weishangjuan@eswincomputing.com > Subject: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control > > Hi Min, Russell, Krzysztof, > > On 1/26/26 22:14, Min Lin wrote: > > Hi Russell, > > > > > >> -----Original Messages----- > >> From: "Russell King (Oracle)" <linux@armlinux.org.uk> > >> Send time:Tuesday, 27/01/2026 02:29:09 > >> To: "Min Lin" <linmin@eswincomputing.com> > >> Cc: "Bo Gan" <ganboing@gmail.com>, "Andrew Lunn" <andrew@lunn.ch>, "Krzysztof Kozlowski" <krzk@kernel.org>, 李志 <lizhi2@eswincomputing.com>, 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, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ningyu@eswincomputing.com, pinkesh.vaghela@einfochips.com, weishangjuan@eswincomputing.com > >> Subject: Re: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control > >> > >> On Mon, Jan 26, 2026 at 11:10:12AM +0800, Min Lin wrote: > >>> 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. > >> > >> Let's analyse this. > >> > >> TXC / RXC TXC / RXC > >> Speed Clock rate Clock period > >> 1G 125MHz 8ns > >> 100M 25MHz 40ns > >> 10M 2.5MHz 400ns > >> > >> The required skew for TXC and RXC at the receiver is specified to be > >> between 1 and 2.6ns irrespective of the speed. The edge of the clock > >> is also important: the rising edge indicates the lower 4 bits, and > >> the falling edge indicates the upper 4 bits. > >> > >> At 1G speed, with a "4 to 5ns" skew in the chip. If this is accurate, > >> then inverting the clock and adding 1ns of additional skew by some > >> means (PCB trace, or at the MAC or PHY) will give the required clock > >> at the receiver. > >> > > > > Yes, that's exactly the case. > > > >> The timing table in the RGMII standard (3.3) allows for Tcyc (the > >> clock rate) to be scaled, but there is no allowance for scaling > >> TskewR (the required 1 to 2.6ns skew.) This skew parameter is > >> fixed. > >> > >> So, at the other speeds, you are completely unable to meet the timing > >> specification, whether irrespective of the clock inversion. In effect, > >> the only speed that you can meet the specification is 1G. > >> > > > > The timing table in the RGMII standard(3.3) says the max value of Tskew > > for 10/100 is unspecified. > > Quotation:"note1: ...,For 10/100 the Max value is unspecified." > > > > I think for 10/100, the "4 to 5ns" skew in the chip doesn't break the > > standard. At 10/100 speeds, it meets the timing specification without > > having to to add clock inversion. > > In practice, it works at 10/100 speeds in the rgmii-id phy mode. > > > >> Thus, I think this is something that needs a lot more than just "do > >> we need to invert the clock". You also need to prevent 10M and 100M > >> being supported IMHO. > >> > > I had an offline discussion with Yao Zi and others regarding this. We feel > like the proper way for ESWIN to deal with this broken eth1 is to have a > different compatible string just for eth1, where it can be associated with > platform data with quirks to do eswin,rx-clk-invert at 1G. The property is > therefore not required to be exposed in DT. (Pretend it conforms to spec > for 1G). Need confirmation for 10M/100M, though. I double checked Lin Min's > claim, and indeed the spec says "For 10/100 the Max value is unspecified": > https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/20655/1/RGMIIv2_0_final_hp.pdf > > Thoughts? I agree with your approach. Regards, Lin Min
Hi Russell, Krzysztof, > -----Original Messages----- > From: "Min Lin" <linmin@eswincomputing.com> > Send time:Wednesday, 28/01/2026 13:48:59 > To: "Bo Gan" <ganboing@gmail.com> > Cc: "Russell King (Oracle)" <linux@armlinux.org.uk>, "Andrew Lunn" <andrew@lunn.ch>, "Krzysztof Kozlowski" <krzk@kernel.org>, 李志 <lizhi2@eswincomputing.com>, 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, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ningyu@eswincomputing.com, pinkesh.vaghela@einfochips.com, weishangjuan@eswincomputing.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@gmail.com> > > Send time:Wednesday, 28/01/2026 10:38:28 > > To: "Min Lin" <linmin@eswincomputing.com>, "Russell King (Oracle)" <linux@armlinux.org.uk> > > Cc: "Andrew Lunn" <andrew@lunn.ch>, "Krzysztof Kozlowski" <krzk@kernel.org>, 李志 <lizhi2@eswincomputing.com>, 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, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ningyu@eswincomputing.com, pinkesh.vaghela@einfochips.com, weishangjuan@eswincomputing.com > > Subject: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control > > > > Hi Min, Russell, Krzysztof, > > > > On 1/26/26 22:14, Min Lin wrote: > > > Hi Russell, > > > > > > > > >> -----Original Messages----- > > >> From: "Russell King (Oracle)" <linux@armlinux.org.uk> > > >> Send time:Tuesday, 27/01/2026 02:29:09 > > >> To: "Min Lin" <linmin@eswincomputing.com> > > >> Cc: "Bo Gan" <ganboing@gmail.com>, "Andrew Lunn" <andrew@lunn.ch>, "Krzysztof Kozlowski" <krzk@kernel.org>, 李志 <lizhi2@eswincomputing.com>, 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, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, ningyu@eswincomputing.com, pinkesh.vaghela@einfochips.com, weishangjuan@eswincomputing.com > > >> Subject: Re: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control > > >> > > >> On Mon, Jan 26, 2026 at 11:10:12AM +0800, Min Lin wrote: > > >>> 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. > > >> > > >> Let's analyse this. > > >> > > >> TXC / RXC TXC / RXC > > >> Speed Clock rate Clock period > > >> 1G 125MHz 8ns > > >> 100M 25MHz 40ns > > >> 10M 2.5MHz 400ns > > >> > > >> The required skew for TXC and RXC at the receiver is specified to be > > >> between 1 and 2.6ns irrespective of the speed. The edge of the clock > > >> is also important: the rising edge indicates the lower 4 bits, and > > >> the falling edge indicates the upper 4 bits. > > >> > > >> At 1G speed, with a "4 to 5ns" skew in the chip. If this is accurate, > > >> then inverting the clock and adding 1ns of additional skew by some > > >> means (PCB trace, or at the MAC or PHY) will give the required clock > > >> at the receiver. > > >> > > > > > > Yes, that's exactly the case. > > > > > >> The timing table in the RGMII standard (3.3) allows for Tcyc (the > > >> clock rate) to be scaled, but there is no allowance for scaling > > >> TskewR (the required 1 to 2.6ns skew.) This skew parameter is > > >> fixed. > > >> > > >> So, at the other speeds, you are completely unable to meet the timing > > >> specification, whether irrespective of the clock inversion. In effect, > > >> the only speed that you can meet the specification is 1G. > > >> > > > > > > The timing table in the RGMII standard(3.3) says the max value of Tskew > > > for 10/100 is unspecified. > > > Quotation:"note1: ...,For 10/100 the Max value is unspecified." > > > > > > I think for 10/100, the "4 to 5ns" skew in the chip doesn't break the > > > standard. At 10/100 speeds, it meets the timing specification without > > > having to to add clock inversion. > > > In practice, it works at 10/100 speeds in the rgmii-id phy mode. > > > > > >> Thus, I think this is something that needs a lot more than just "do > > >> we need to invert the clock". You also need to prevent 10M and 100M > > >> being supported IMHO. > > >> > > > > > I had an offline discussion with Yao Zi and others regarding this. We feel > > like the proper way for ESWIN to deal with this broken eth1 is to have a > > different compatible string just for eth1, where it can be associated with > > platform data with quirks to do eswin,rx-clk-invert at 1G. The property is > > therefore not required to be exposed in DT. (Pretend it conforms to spec > > for 1G). Need confirmation for 10M/100M, though. I double checked Lin Min's > > claim, and indeed the spec says "For 10/100 the Max value is unspecified": > > https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/imx-processors/20655/1/RGMIIv2_0_final_hp.pdf > > > > Thoughts? > > I agree with your approach. > Do you think it would be reasonable for eth1 to have another different compatible string, such as "eswin,eic7700-qos-eth-quirk"? Thanks for your comments. Regards, Lin Min
> Do you think it would be reasonable for eth1 to have another different compatible
> string, such as "eswin,eic7700-qos-eth-quirk"?
I think you can argue the two Ethernets are not compatible with each
other. But i personally would not use 'quirk'. Maybe something which
says how they differ?
Andrew
> -----原始邮件----- > 发件人: "Bo Gan" <ganboing@gmail.com> > 发送时间:2026-01-23 15:39:29 (星期五) > 收件人: "Andrew Lunn" <andrew@lunn.ch>, 李志 <lizhi2@eswincomputing.com> > 抄送: 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: > >>> 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/ > > 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
On Fri, Jan 09, 2026 at 07:27:54PM +0100, Andrew Lunn wrote: > > rx-internal-delay-ps: > > - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400] > > + enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400] > > > > tx-internal-delay-ps: > > - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400] > > + enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400] > > You need to add some text to the Changelog to indicate why this is > safe to do, and will not cause any regressions for DT blobs already in > use. Backwards compatibility is very important and needs to be > addressed. > > > + eswin,rx-clk-invert: > > + description: > > + Invert the receive clock sampling polarity at the MAC input. > > + This property may be used to compensate for SoC-specific > > + receive clock to data skew and help ensure correct RX data > > + sampling at high speed. > > + type: boolean > > This does not make too much sense to me. The RGMII standard indicates > sampling happens on both edges of the clock. The rising edge is for > the lower 4 bits, the falling edge for the upper 4 bits. Flipping the > polarity would only swap the nibbles around. I'm going to ask a rather pertinent question. Why do we have this eswin stuff in the kernel tree? I've just been looking to see whether I can understand more about this, and although I've discovered the TRM is available for the EIC7700: https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases that isn't particularly helpful on its own. There doesn't appear to be any device tree source files that describe the hardware. The DT bindings that I can find seem to describe only ethernet and USB. describe the ethernet and USB, and maybe sdhci. I was looking for something that would lead me to what this eswin,hsp-sp-csr thing is, but that doesn't seem to exist in our DT binding documentation, nor does greping for "hsp.sp.csr" in arch/*/boot/dts find anything. So, we can't know what this "hsp" thing is to even know where to look in the 80MiB of PDF documentation. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
On 1/10/26 10:26, Russell King (Oracle) wrote:
> On Fri, Jan 09, 2026 at 07:27:54PM +0100, Andrew Lunn wrote:
>>> rx-internal-delay-ps:
>>> - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
>>> + enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400]
>>>
>>> tx-internal-delay-ps:
>>> - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
>>> + enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400]
>>
>> You need to add some text to the Changelog to indicate why this is
>> safe to do, and will not cause any regressions for DT blobs already in
>> use. Backwards compatibility is very important and needs to be
>> addressed.
>>
>>> + eswin,rx-clk-invert:
>>> + description:
>>> + Invert the receive clock sampling polarity at the MAC input.
>>> + This property may be used to compensate for SoC-specific
>>> + receive clock to data skew and help ensure correct RX data
>>> + sampling at high speed.
>>> + type: boolean
>>
>> This does not make too much sense to me. The RGMII standard indicates
>> sampling happens on both edges of the clock. The rising edge is for
>> the lower 4 bits, the falling edge for the upper 4 bits. Flipping the
>> polarity would only swap the nibbles around.
>
> I'm going to ask a rather pertinent question. Why do we have this
> eswin stuff in the kernel tree?
>
> I've just been looking to see whether I can understand more about this,
> and although I've discovered the TRM is available for the EIC7700:
>
> https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases
>
> that isn't particularly helpful on its own.
>
> There doesn't appear to be any device tree source files that describe
> the hardware. The DT bindings that I can find seem to describe only
> ethernet and USB. describe the ethernet and USB, and maybe sdhci.
>
> I was looking for something that would lead me to what this
> eswin,hsp-sp-csr thing is, but that doesn't seem to exist in our
> DT binding documentation, nor does greping for "hsp.sp.csr" in
> arch/*/boot/dts find anything.
>
> So, we can't know what this "hsp" thing is to even know where to look
> in the 80MiB of PDF documentation.
>
HSP -> High-Speed Peripheral. eswin,hsp-sp-csr is mentioned in
Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml
Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml
From ESWIN's vendor/testing kernel tree:
hsp_sp_csr: hsp-sp-top-csr@0x50440000 {
compatible = "syscon";
#size-cells = <2>;
reg = <0x0 0x50440000 0x0 0x2000>;
};
Apparently it's just a register block that controls varies behaviors of
high speed peripherals. I'm not sure if DT bindings mandates it, but it's
undocumented in the TRM. Perhaps ESWIN should properly document it going
forward? Also, I think ESWIN needs to check-in the sdhci/eth/usb device-
tree components ASAP, so folks can test it.
Bo
> -----原始邮件-----
> 发件人: "Bo Gan" <ganboing@gmail.com>
> 发送时间:2026-01-11 12:05:31 (星期日)
> 收件人: "Russell King (Oracle)" <linux@armlinux.org.uk>, "Andrew Lunn" <andrew@lunn.ch>
> 抄送: lizhi2@eswincomputing.com, 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, 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
>
> On 1/10/26 10:26, Russell King (Oracle) wrote:
> > On Fri, Jan 09, 2026 at 07:27:54PM +0100, Andrew Lunn wrote:
> >>> rx-internal-delay-ps:
> >>> - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
> >>> + enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400]
> >>>
> >>> tx-internal-delay-ps:
> >>> - enum: [0, 200, 600, 1200, 1600, 1800, 2000, 2200, 2400]
> >>> + enum: [0, 20, 60, 100, 200, 400, 800, 1600, 2400]
> >>
> >> You need to add some text to the Changelog to indicate why this is
> >> safe to do, and will not cause any regressions for DT blobs already in
> >> use. Backwards compatibility is very important and needs to be
> >> addressed.
> >>
> >>> + eswin,rx-clk-invert:
> >>> + description:
> >>> + Invert the receive clock sampling polarity at the MAC input.
> >>> + This property may be used to compensate for SoC-specific
> >>> + receive clock to data skew and help ensure correct RX data
> >>> + sampling at high speed.
> >>> + type: boolean
> >>
> >> This does not make too much sense to me. The RGMII standard indicates
> >> sampling happens on both edges of the clock. The rising edge is for
> >> the lower 4 bits, the falling edge for the upper 4 bits. Flipping the
> >> polarity would only swap the nibbles around.
> >
> > I'm going to ask a rather pertinent question. Why do we have this
> > eswin stuff in the kernel tree?
> >
> > I've just been looking to see whether I can understand more about this,
> > and although I've discovered the TRM is available for the EIC7700:
> >
> > https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases
> >
> > that isn't particularly helpful on its own.
> >
> > There doesn't appear to be any device tree source files that describe
> > the hardware. The DT bindings that I can find seem to describe only
> > ethernet and USB. describe the ethernet and USB, and maybe sdhci.
> >
> > I was looking for something that would lead me to what this
> > eswin,hsp-sp-csr thing is, but that doesn't seem to exist in our
> > DT binding documentation, nor does greping for "hsp.sp.csr" in
> > arch/*/boot/dts find anything.
> >
> > So, we can't know what this "hsp" thing is to even know where to look
> > in the 80MiB of PDF documentation.
> >
>
> HSP -> High-Speed Peripheral. eswin,hsp-sp-csr is mentioned in
>
> Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml
> Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
> Documentation/devicetree/bindings/usb/eswin,eic7700-usb.yaml
>
> From ESWIN's vendor/testing kernel tree:
>
> hsp_sp_csr: hsp-sp-top-csr@0x50440000 {
> compatible = "syscon";
> #size-cells = <2>;
> reg = <0x0 0x50440000 0x0 0x2000>;
> };
>
> Apparently it's just a register block that controls varies behaviors of
> high speed peripherals. I'm not sure if DT bindings mandates it, but it's
> undocumented in the TRM. Perhaps ESWIN should properly document it going
> forward? Also, I think ESWIN needs to check-in the sdhci/eth/usb device-
> tree components ASAP, so folks can test it.
>
Yes, that’s correct. hsp-sp-csr is a shared register block used to control
various high-speed peripherals (Ethernet, USB, SDHCI) on EIC7700.
This block is currently not well documented in the public TRM. We acknowledge
this gap and plan to improve it by adding proper documentation. We also intend
to upstream complete DTS files for EIC7700 so the bindings can be validated
against real hardware.
Thanks for raising this concern.
Li Zhi
> We also intend
> to upstream complete DTS files for EIC7700 so the bindings can be validated
> against real hardware.
I suggest you prioritise this. ARM-SOC is pretty flexible for
accepting work in progress support for new SoCs. All you really need
is for the board to boot to a login prompt on a serial port using an
initramsfs. So the .dtsi and .dts file can be very slim, CPUs, memory
and UARTs.
Once you have that merged you can work on the other drivers, their
bindings, etc.
As Russell pointed out, at the moment, most of the code you have in
the kernel is unusable, so it is a candidate for being thrown out.
Andrew
Hi Andrew, Thank you for taking the time to review the patch. > -----Original Messages----- > From: "Andrew Lunn" <andrew@lunn.ch> > Send time:Thursday, 22/01/2026 21:27:34 > To: 李志 <lizhi2@eswincomputing.com> > Cc: "Bo Gan" <ganboing@gmail.com>, "Russell King (Oracle)" <linux@armlinux.org.uk>, 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, 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: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control > > > We also intend > > to upstream complete DTS files for EIC7700 so the bindings can be validated > > against real hardware. > > I suggest you prioritise this. ARM-SOC is pretty flexible for > accepting work in progress support for new SoCs. All you really need > is for the board to boot to a login prompt on a serial port using an > initramsfs. So the .dtsi and .dts file can be very slim, CPUs, memory > and UARTs. > > Once you have that merged you can work on the other drivers, their > bindings, etc. > The eic7700.dtsi and eic7700-hifive-premier-p550.dts are already in v6.19-rc6. As you said, it only includes CPUs, memory and UARTs right now. It has been verified to be able to login prompt on a serial port using an initramfs. Besides, the reset driver for eic7700 has already been merged in v6.19-rc6. Because the device drivers such as Ethernet rely on the clock driver, our plan is that once the clock driver is applied, we will add other device nodes such as Ethernet and eMMC in the next upstream patch of the DTS. Is this reasonable? Regards, Lin Min
On Tue, Jan 27, 2026 at 03:05:48PM +0800, Min Lin wrote: > Hi Andrew, > > Thank you for taking the time to review the patch. > > > -----Original Messages----- > > From: "Andrew Lunn" <andrew@lunn.ch> > > Send time:Thursday, 22/01/2026 21:27:34 > > To: 李志 <lizhi2@eswincomputing.com> > > Cc: "Bo Gan" <ganboing@gmail.com>, "Russell King (Oracle)" <linux@armlinux.org.uk>, 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, 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: Re: [PATCH v1 1/2] dt-bindings: ethernet: eswin: add clock sampling control > > > > > We also intend > > > to upstream complete DTS files for EIC7700 so the bindings can be validated > > > against real hardware. > > > > I suggest you prioritise this. ARM-SOC is pretty flexible for > > accepting work in progress support for new SoCs. All you really need > > is for the board to boot to a login prompt on a serial port using an > > initramsfs. So the .dtsi and .dts file can be very slim, CPUs, memory > > and UARTs. > > > > Once you have that merged you can work on the other drivers, their > > bindings, etc. > > > The eic7700.dtsi and eic7700-hifive-premier-p550.dts are already in > v6.19-rc6. Great. > Because the device drivers such as Ethernet rely on the clock driver, > our plan is that once the clock driver is applied, we will add other > device nodes such as Ethernet and eMMC in the next upstream patch > of the DTS. Is this reasonable? Yes, this is reasonable. When you submit Ethernet support, please include the DT patches as part of the series, so we can see the full picture. When it comes to actually merging it could be the DT patches get separated out and go a different path, but we can decide that when we get to that stage. Given the new information, it becomes clear that backwards compatibility is not an issue. Since mainline does not have any users of the Ethernet driver, you should make non-backwards compatible changes in order to keep things clean. Just ensure the commit messages point out there are no users, so the changes are safe. Andrew
On Thu, Jan 22, 2026 at 02:27:34PM +0100, Andrew Lunn wrote: > > We also intend > > to upstream complete DTS files for EIC7700 so the bindings can be validated > > against real hardware. > > I suggest you prioritise this. ARM-SOC is pretty flexible for > accepting work in progress support for new SoCs. All you really need > is for the board to boot to a login prompt on a serial port using an > initramsfs. So the .dtsi and .dts file can be very slim, CPUs, memory > and UARTs. > > Once you have that merged you can work on the other drivers, their > bindings, etc. > > As Russell pointed out, at the moment, most of the code you have in > the kernel is unusable, so it is a candidate for being thrown out. Indeed, and we've had drivers merged before for platforms that never made it in, and they just hang around for decades, adding to the maintainer's burden for no benefit what so ever. So please, no more drivers for EIC7700 until there is functional support for the platform, as Andrew states. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
© 2016 - 2026 Red Hat, Inc.