On Wed, Jan 29, 2025 at 09:35:21AM +0100, Uwe Kleine-König wrote:
> Hello Andrew,
>
> On Tue, Jan 28, 2025 at 06:44:26PM +0100, Andrew Lunn wrote:
> > > +&gmac1 {
> > > + /* Uses a KSZ9031RNX phy */
> > > + status = "okay";
> > > + phy-mode = "rgmii";
> > > +
> > > + rxd0-skew-ps = <420>;
> > > + rxd1-skew-ps = <420>;
> > > + rxd2-skew-ps = <420>;
> > > + rxd3-skew-ps = <420>;
> > > + txen-skew-ps = <0>;
> > > + txc-skew-ps = <1860>;
> > > + rxdv-skew-ps = <420>;
> > > + rxc-skew-ps = <1680>;
> > > +};
> >
> > The convectional meaning of phy-mode 'rgmii' is that the PCB provides
> > the 2ns delay. Here you are abusing the
> >
> > > + txc-skew-ps = <1860>;
> > > + rxc-skew-ps = <1680>;
> >
> > To add these delays.
>
> Ah, at some point I already knew that. Thanks for repeating that hint.
No problem a with the hint. This is a nice easy case. Some vendors
have made a big mess with RGMII delays, hiding it in the bootloader,
and giving customers bad advice. That is much harder to fix.
> (Back then it was for
> arch/arm64/boot/dts/rockchip/rk3568-qnap-ts433.dts.)
>
> > Please test without these two lines, and change phy-mode to
> > 'rgmii-id'. 1680 is rather low, so it might not work. Look for CRC
> > errors for received packets.
>
> I did an apt upgrade involving > 100 MB downloads with rgmii-id and
> afterwards I had:
>
> # ip -stats link show dev eth0
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAU
> LT group default qlen 1000
> link/ether ee:5f:09:22:72:da brd ff:ff:ff:ff:ff:ff
> RX: bytes packets errors dropped missed mcast
> 158336739 113000 0 0 0 0
> TX: bytes packets errors dropped carrier collsns
> 482481 5094 0 0 0 0
>
> so that seems to be fine, right?
Yes, this looks good.
Thanks
Andrew
