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" > 发送时间:2025-07-21 21:10:55 (星期一) > 收件人: 李志 > 抄送: weishangjuan@eswincomputing.com, 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, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, rmk+kernel@armlinux.org.uk, yong.liang.choong@linux.intel.com, vladimir.oltean@nxp.com, jszhang@kernel.org, jan.petrous@oss.nxp.com, prabhakar.mahadev-lad.rj@bp.renesas.com, inochiama@gmail.com, boon.khai.ng@altera.com, dfustini@tenstorrent.com, 0x1207@gmail.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, ningyu@eswincomputing.com, linmin@eswincomputing.com, pinkesh.vaghela@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–3, TXD0–3, 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