linux-kernel - Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aOU-_tPOmkyuw_kx@shell.armlinux.org.uk>
Date: Tue, 7 Oct 2025 17:25:34 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>
Cc: jjm2473 <jjm2473@...il.com>, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, heiko@...ech.de, quentin.schulz@...rry.de,
	kever.yang@...k-chips.com, naoki@...xa.com, honyuenkwun@...il.com,
	inindev@...il.com, ivan8215145640@...il.com,
	neil.armstrong@...aro.org, mani@...nel.org, dsimic@...jaro.org,
	pbrobinson@...il.com, alchark@...il.com, didi.debian@...ow.org,
	jbx6244@...il.com, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] arm64: dts: rockchip: add LinkEase EasePi R1

On Tue, Oct 07, 2025 at 04:57:32PM +0200, Andrew Lunn wrote:
> On Tue, Oct 07, 2025 at 10:32:26PM +0800, jjm2473 wrote:
> > Andrew Lunn <andrew@...n.ch> 于2025年10月6日周一 23:51写道：
> > > Please change it to rgmii-id, and smaller tx/rx_delay values. Or show
> > > us the schematics which clearly show extra long clock lines.
> > 
> > In fact, the RTL8211F's RXDLY and TXDLY signals are both pulled low,
> > just like the Banana Pi BPI-R2 Pro, so the configuration is also referenced:
> > https://elixir.bootlin.com/linux/v6.15/source/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts#L237
> 
> Pull low makes no difference to the 2ns RGMII delays.

To be clear, while the RXDLY and TXDLY are hardware strapping controls
the hardware configuration of the 2ns RGMII clock delays, the realtek
driver can (and does) override this according to the phy-mode property.
Thus hardware strapping makes no difference to Linux.

So, what we get at the RTL8211F PHY is:

	phy-mode	receive clock delay	transmit clock delay
	"rgmii"		0ns			0ns
	"rgmii-rxid"	2ns			0ns
	"rgmii-txid"	0ns			2ns
	"rgmii-id"	2ns			2ns

irrespective of RXDLY / TXDLY hardware strapping.

> > The tx_delay and rx_delay values were obtained using Rockchip's
> > automatic scanning tool:
> > https://github.com/istoreos/istoreos/blob/54746dfdb5bd34d1f281cf41d1d1620d0c3ee686/target/linux/rockchip/files/drivers/net/ethernet/stmicro/stmmac/dwmac-rk-tool.c
> > https://gitlab.com/firefly-linux/docs/-/blob/rk356x/firefly/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
> > https://github.com/axlrose/rkdocs/blob/main/Common/GMAC/Rockchip_Developer_Guide_Linux_GMAC_RGMII_Delayline_EN.pdf
> 
> Vendors get things wrong, including this. 'rgmii' means the PCB adds
> the 2ns delay. Nearly every Rockchip board follows Rockchip broken
> vendor recommendations, and then i come along, point out how it is
> wrong, and ask for it to be fixed, before being merged to Mainline.

Can we at least get the "tx_delay" and "rx_delay" DT properties (which
are register values) properly documented in the DT binding document?
I know from the driver code that a value of 0 means "no delay". Other
values add an unspecified delay - it is not obvious what any non-zero
value means, or what the default means.

This would help us understand what values such as:

	tx_delay = 0x3c or 0x4f

and

	rx_delay = 0x2f or 0x26

actually mean in terms of the resulting delay at the MAC.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!