[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 at lunn.ch>
> ·¢ËÍʱ¼ä:2025-07-21 21:10:55 (ÐÇÆÚÒ»)
> ÊÕ¼þÈË: ÀîÖ¾ <lizhi2 at eswincomputing.com>
> ³­ËÍ: weishangjuan at eswincomputing.com, andrew+netdev at lunn.ch,
davem at davemloft.net, edumazet at google.com, kuba at kernel.org, robh at kernel.org,
krzk+dt at kernel.org, conor+dt at kernel.org, netdev at vger.kernel.org,
devicetree at vger.kernel.org, linux-kernel at vger.kernel.org,
mcoquelin.stm32 at gmail.com, alexandre.torgue at foss.st.com,
rmk+kernel at armlinux.org.uk, yong.liang.choong at linux.intel.com,
vladimir.oltean at nxp.com, jszhang at kernel.org, jan.petrous at oss.nxp.com,
prabhakar.mahadev-lad.rj at bp.renesas.com, inochiama at gmail.com,
boon.khai.ng at altera.com, dfustini at tenstorrent.com, 0x1207 at gmail.com,
linux-stm32 at st-md-mailman.stormreply.com,
linux-arm-kernel at lists.infradead.org, ningyu at eswincomputing.com,
linmin at eswincomputing.com, pinkesh.vaghela at einfochips.com
> Ö÷Ìâ: Re: Re: Re: [PATCH v3 2/2] ethernet: eswin: Add eic7700 ethernet
driver
> 
> > > > Let me clarify the purpose of the three elements in each dly_param_*
array:
> > > >   dly_param_[x][0]: Delay configuration for TXD signals
> > > >   dly_param_[x][1]: Delay configuration for control signals (e.g.,
TX_EN, RX_DV, RX_CLK)
> > > >   dly_param_[x][2]: Delay configuration for RXD signals
> > > 
> > > Maybe add a #define or an enum for the index.
> > > 
> > > Do these delays represent the RGMII 2ns delay?
> > > 
> > 
> > Yes, these delays refer to the RGMII delay, but they are not strictly
2ns. There are a few points that require further clarification:
> > 1. Regarding delay configuration logic:
> >    As you mentioned in version V2, rx-internal-delay-ps and
tx-internal-delay-ps will be mapped to and overwrite the corresponding bits
in the EIC7700_DELAY_VALUE1 register, which controls the rx_clk and tx_clk
delays. Is this understanding and approach correct and feasible?
> 
> Please configure your email client to wrap at about 78
> characters. Standard network etiquette.
> 
> Yes, if rx-internal-delay-ps or/and tx-internal-delay-ps are in DT,
> they should configure the delay the MAC applies.
> 
> 
> > 2. About the phy-mode setting:
> >    In our platform, the internal delays are provided by the MAC. When
configuring rx-internal-delay-ps and tx-internal-delay-ps in the device
tree, is it appropriate to set phy-mode = "rgmii-id" in this case?
> 
> Please read:
> 
>
https://elixir.bootlin.com/linux/v6.15.7/source/Documentation/devicetree/bin
dings/net/ethernet-controller.yaml#L287
> 
> It gives a detailed description of what phy-mode = "rmgii-id" means. 
> 
> > 3. Delay values being greater than 2ns:
> >    In our platform, the optimal delay values for rx_clk and tx_clk are
determined based on the board-level timing adjustment, and both are greater
than 2ns. Given this, is it reasonable and compliant with the RGMII
specification to set both rx-internal-delay-ps and tx-internal-delay-ps to
values greater than 2ns in the Device Tree?
> 
> It is O.K. when the total delay is > 2ns. However, please note what is
> said, the normal way to implement delays in Linux. The PHY does the
> 2ns delay. The MAC can then do fine tuning, adding additional small
> delays.
> 
> > There is a question that needs clarification:
> > The EIC7700_DELAY_VALUE0 and EIC7700_DELAY_VALUE1 registers contain the
optimal delay configurations determined through board-level phase
adjustment. Therefore, they are also used as the default values in our
platform. If the default delay is set to 0ps, the Ethernet interface may
fail to function correctly in our platform.
> 
> So there is only every going to be one board? There will never produce
> a cost optimised version with a different, cheaper PHY? You will never
> support connecting the MAC directly an Ethernet switch? You will never
> make use of a PHY which can translate to SGMII/1000BaseX, and then
> have an SFP cage?
> 
> DT properties are there to make your hardware more flexible. You can
> use it to describe such setups, and handle the timing needed for each.
> 
> By default, when phy-mode is rgmii-id, the MAC adds 0ns, the PHY 2ns,
> and most systems will just work. That 2ns is what the RGMII standard
> requires. You can then fine tune it with rx-internal-delay-ps and
> tx-internal-delay-ps if your design does not correctly follow the
> RGMII standard.
> 

Yes, DT properties are there to make our hardware more flexible.

Our platform uses three dedicated registers to configure RGMII signal
delays, due to differences in board-level designs. These registers control
delays for signals including RXD0¨C3, TXD0¨C3, RXDV, RXCLK, and TXCLK.
Among these, RXCLK and TXCLK are directly related to the standard DT
properties `rx-internal-delay-ps` and `tx-internal-delay-ps`, respectively.
The remaining signals (such as RXD0-4, TXD0-4, RXDV, etc.) require
additional configuration that cannot be expressed using standard
properties.

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.

Is this understanding and approach correct and feasible?

> 	Andrew