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

From: 李志 <[email-masked]>
Date: Mon, 12 Jan 2026 15:05:18 +0800 (GMT+08:00)

> -----原始邮件-----
> 发件人: "Bo Gan" <[email-masked]>
> 发送时间:2026-01-11 12:05:31 (星期日)
> 收件人: "Russell King (Oracle)" <[email-masked]>, "Andrew Lunn" <[email-masked]>
> 抄送: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
> 主题: 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