Subject: Re: Re: [PATCH net v1 1/2] dt-bindings: ethernet: eswin: refine delay model and HSP register description

From: 李志 <[email-masked]>
Date: Fri, 8 May 2026 13:43:23 +0800 (GMT+08:00)

> -----原始邮件-----
> 发件人: "Conor Dooley" <[email-masked]>
> 发送时间:2026-05-08 01:24:02 (星期五)
> 收件人: [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], [email-masked], [email-masked]
> 主题: Re: [PATCH net v1 1/2] dt-bindings: ethernet: eswin: refine delay model and HSP register description
> 
> On Thu, May 07, 2026 at 04:31:36PM +0800, [email-masked] wrote:
> > From: Zhi Li <[email-masked]>
> > 
> > Refine the EIC7700 Ethernet dt-binding based on observed hardware behavior
> > and clarify the original delay model for eth0.
> > 
> > The previous binding used an enum-based definition for
> > rx-internal-delay-ps and tx-internal-delay-ps. Replace it with a
> > range-based model using:
> > 
> >   - minimum: 0
> >   - maximum: 2540
> >   - multipleOf: 20
> > 
> > This better reflects the actual hardware implementation, which
> > supports 20ps granularity delay steps in the MAC RGMII interface.
> > 
> > The tx/rx internal delay values are clarified as MAC-side programmable
> > delay components applied on the RGMII clock/data path, representing
> > the effective delay seen at the MAC interface.
> > 
> > This does not change the intended hardware semantics, but aligns the
> > binding with the actual hardware implementation.
> > 
> > These properties are optional and only required when MAC-side fine
> > tuning is needed; otherwise delay alignment is provided by PHY or
> > board design.
> > 
> > Depending on the selected RGMII timing mode, delay alignment may be
> > provided by the PHY (e.g. rgmii-id) or by board/MAC-side configuration.
> > When PHY or board design already provides the required delay, these
> > MAC-side properties may be omitted. When MAC-side fine tuning is
> > required, they should be provided to describe the internal RGMII
> > timing adjustment.
> > 
> > Additionally, extend the description of the HSP subsystem register
> > layout used by the MAC glue logic. This includes explicit TXD and RXD
> > delay control registers to ensure deterministic initialization and
> > to override any residual configuration potentially left by bootloaders.
> > 
> > Add reference to the EIC7700X SoC Technical Reference Manual,
> > Chapter 10 ("High-Speed Interface"), Part 4 for background of the
> > HSP CSR block:
> > https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual/releases
> > 
> > There are no in-tree users of this binding, so no ABI impact is
> > expected.
> > 
> > Fixes: 888bd0eca93c ("dt-bindings: ethernet: eswin: Document for EIC7700 SoC")
> > Signed-off-by: Zhi Li <[email-masked]>
> > ---
> 
> While this is v1, it's really v8 and there should therefore be a
> changelog that explains where my ack and the new compatible went.
> 

Thanks for the review.

Based on Jakub's feedback on the previous v7 series, I plan to split the
changes into two separate series:

- a smaller fix series intended for net,
- and a separate eth1 feature series intended for net-next.

After the split, the scope and target trees of the two series will differ
from the original combined series, so I plan to restart the revision
numbering from v1 for both series.

The additional compatible string and the eth1-specific DT binding
extensions will be moved into the separate feature series, and I will
reflect this in the v2 cover letter.

The DT binding changes in this fix series v1 are simply extracted from the
previous v7 series as part of the split.

Since the series has been restructured, I will drop the previous
Acked-by tags.

I will also document the reason for doing so and the impact of the split
in the v2 cover letter.

If you think the binding changes are still effectively unchanged and the
previous Acked-by can still apply, I am happy to retain them or re-apply
them as appropriate. Otherwise I will assume a fresh review is preferred.

Please let me know your preference.

Thanks,
Zhi