linux-kernel - Re: Re: Re: Re: Re: [PATCH v3 2/2] ethernet: eswin: Add eic7700 ethernet driver

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2b4deeba.3f61.1985fb2e8d4.Coremail.lizhi2@eswincomputing.com>
Date: Thu, 31 Jul 2025 16:56:57 +0800 (GMT+08:00)
From: 李志 <lizhi2@...incomputing.com>
To: "Andrew Lunn" <andrew@...n.ch>
Cc: weishangjuan@...incomputing.com, 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, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, mcoquelin.stm32@...il.com,
	alexandre.torgue@...s.st.com, rmk+kernel@...linux.org.uk,
	yong.liang.choong@...ux.intel.com, vladimir.oltean@....com,
	jszhang@...nel.org, jan.petrous@....nxp.com,
	prabhakar.mahadev-lad.rj@...renesas.com, inochiama@...il.com,
	boon.khai.ng@...era.com, dfustini@...storrent.com, 0x1207@...il.com,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, ningyu@...incomputing.com,
	linmin@...incomputing.com, pinkesh.vaghela@...fochips.com
Subject: Re: Re: Re: Re: Re: [PATCH v3 2/2] ethernet: eswin: Add eic7700
 ethernet driver

Dear Andrew Lunn,
Thank you for your professional and valuable suggestions.
Our questions are embedded below your comments in the original email below.

Best regards,

Li Zhi
Eswin Computing

> -----原始邮件-----
> 发件人: "Andrew Lunn" <andrew@...n.ch>
> 发送时间:2025-07-22 22:07:23 (星期二)
> 收件人: 李志 <lizhi2@...incomputing.com>
> 抄送: weishangjuan@...incomputing.com, 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, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, mcoquelin.stm32@...il.com, alexandre.torgue@...s.st.com, rmk+kernel@...linux.org.uk, yong.liang.choong@...ux.intel.com, vladimir.oltean@....com, jszhang@...nel.org, jan.petrous@....nxp.com, prabhakar.mahadev-lad.rj@...renesas.com, inochiama@...il.com, boon.khai.ng@...era.com, dfustini@...storrent.com, 0x1207@...il.com, linux-stm32@...md-mailman.stormreply.com, linux-arm-kernel@...ts.infradead.org, ningyu@...incomputing.com, linmin@...incomputing.com, pinkesh.vaghela@...fochips.com
> 主题: Re: Re: Re: Re: [PATCH v3 2/2] ethernet: eswin: Add eic7700 ethernet driver
> 
> > In v2, `eswin,dly-param-xxx` is used to configure all delay registers via
> > device tree, including RXCLK and TXCLK. Based on the latest discussion,
> > this approach in the next version:
> > - The delay configuration for RXCLK and TXCLK will be handled using the
> >  standard DT properties `rx-internal-delay-ps` and `tx-internal-delay-ps`.
> > - The remaining delay configuration (e.g., for RXD0-4, TXD0-4, RXDV) will
> >  continue to use the vendor-specific `eswin,dly-param-xxx` properties.
> > - If the standard delay properties are not specified in DT, a default of 0
> > ps
> >  will be assumed.
> 
> Please keep the RGMII standard in mind. All it says is that there
> should be a 2ns delay between the data and the clock signal. It is
> also quite generous on the range of delays which should actually
> work. It says nothing about being able to configure that delay. And it
> definitely says nothing about being able to configure each individual
> single.
> 
> You hardware has a lot of flexibility, but none of if should actually
> be needed, if you follow the standard.
> 
> So phy-mode = "rgmii-id"; should be all you need for most boards.
> Everything else should be optional, with sensible defaults.
> 

On our platform, the vendor-specific attributes eswin,dly-param-* were
initially introduced to compensate for board-specific variations in RGMII
signal timing, primarily due to differences in PCB trace lengths. These
attributes allow fine-grained, per-signal delay control for RXD, TXD,
TXEN, RXDV, RXCLK, and TXCLK, based on empirically derived optimal phase
settings.
In our experience, setting phy-mode = "rgmii-id" alone, along with only
the standard properties rx-internal-delay-ps and tx-internal-delay-ps,
has proven insufficient to meet our hardware's timing requirements.
Therefore these standard properties are treated as controlling only RXCLK
and TXCLK, while continuing to use the eswin,dly-param-* attributes for
other signals.
Additionally, if rx-internal-delay-ps and tx-internal-delay-ps are
omitted, their values default to 0ps due to the use of devm_kzalloc().
This behavior reinforces the need for explicit delay values in certain
configurations. For reference, TI platforms use a dedicated IODELAY
hardware module to program per-signal RGMII delays in a similar fashion.

As per your suggestion, we will set mode="rgmii-id".
We have questions on setting delay parameters from dts we have two
approches. Could you please let us know which approach is appropriate?

1. Setting all delay parameters (RXD, TXD, TXEN, RXDV, RXCLK, and TXCLK)
   using vendor-specific attributes eswin,dly-param-*.
   e.g.
   eswin,dly-param-1000m = <0x20202020 0x96205A20 0x20202020>;
2. Setting delay parameters (RXD, TXD, TXEN, RXDV) using vendor-specific
   attributes eswin,dly-param-* , RXCLK using rx-internal-delay-ps and
   TXCLK using tx-internal-delay-ps.
   e.g
   eswin,dly-param-1000m = <0x20202020 0x80200020 0x20202020>;
   rx-internal-delay-ps = <9000>;
   tx-internal-delay-ps = <2200>;

> 	Andrew