[PATCH 11/12] riscv: dts: ultrarisc: Add Shenzhen Rongda M0 board device tree

Andrew Lunn andrew at lunn.ch
Wed Aug 26 19:46:01 PDT 2026


On Thu, Aug 27, 2026 at 10:19:43AM +0800, Jia Wang wrote:
> On 2026-08-24 15:02 +0200, Andrew Lunn wrote:
> > > +&ethernet {
> > > +	phy-handle = <&phy0>;
> > > +	/*
> > > +	 * YT8531 RGMII timing on this board requires no PHY internal delays.
> > 
> > Please extend this sentence with an explanation why it needs no delay?
> > 
> > There are times this is correct, but it is also mostly wrong. Without
> > an explanation, i cannot say if this is correct or not.
> > 
> 
> Thanks for the review.
> 
> The DP1000 SoC integration provides the required TX and RX RGMII clock
> skew, so enabling the YT8531 internal delays would apply the delay twice.

Please take a read of

https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287

You need to make the MAC driver do the correct thing:

# There are a small number of cases where the MAC has hard coded
# delays which cannot be disabled. The 'phy-mode' only describes the
# PCB.  The inability to disable the delays in the MAC does not change
# the meaning of 'phy-mode'. It does however mean that a 'phy-mode' of
# 'rgmii' is now invalid, it cannot be supported, since both the PCB
# and the MAC and PHY adding delays cannot result in a functional
# link. Thus the MAC should report a fatal error for any modes which
# cannot be supported. When the MAC implements the delay, it must
# ensure that the PHY does not also implement the same delay. So it
# must modify the phy-mode it passes to the PHY, removing the delay it
# has added. Failure to remove the delay will result in a
# non-functioning link.

    Andrew



More information about the linux-riscv mailing list