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 for Android: free password hash cracker in your pocket

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

Message-ID: <88c6c40e-8c19-429d-a7d8-c8f2755f515c@cherry.de>
Date: Tue, 7 Oct 2025 18:32:15 +0200
From: Quentin Schulz <quentin.schulz@...rry.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Andrew Lunn <andrew@...n.ch>
Cc: jjm2473 <jjm2473@...il.com>, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, heiko@...ech.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

Hi Russel,

On 10/7/25 6:25 PM, Russell King (Oracle) wrote:
> 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.
> 

I couldn't figure out what they actually mean empirically, see 
https://lore.kernel.org/linux-rockchip/96d32ce8-394b-4454-8910-a66be2813588@cherry.de/

Without Rockchip's explanation on what this actually does, I'm not sure 
there's something we can do on this side.

Cheers,
Quentin