linux-kernel - Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board

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: <5FFFBA7FAF5745A7+e0381969-800a-4bf6-9aac-81cffa3469a1@airkyi.com>
Date: Thu, 8 Jan 2026 16:01:43 +0800
From: Chaoyi Chen <kernel@...kyi.com>
To: Chaoyi Chen <chaoyi.chen@...k-chips.com>,
 Alexey Charkov <alchark@...il.com>, Andrew Lunn <andrew@...n.ch>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
 Quentin Schulz <quentin.schulz@...rry.de>,
 Kever Yang <kever.yang@...k-chips.com>, Jonas Karlman <jonas@...boo.se>,
 John Clark <inindev@...il.com>, FUKAUMI Naoki <naoki@...xa.com>,
 Jimmy Hon <honyuenkwun@...il.com>, Dragan Simic <dsimic@...jaro.org>,
 Michael Riesch <michael.riesch@...labora.com>,
 Peter Robinson <pbrobinson@...il.com>, Shawn Lin <shawn.lin@...k-chips.com>,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Andy Yan <andy.yan@...k-chips.com>, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] arm64: dts: rockchip: Add rk3576 evb2 board

On 1/8/2026 3:42 PM, Chaoyi Chen wrote:
> Hello Alexey, Andrew,
> 
> On 1/8/2026 2:53 PM, Alexey Charkov wrote:
>> On Wed, Jan 7, 2026 at 10:18 PM Andrew Lunn <andrew@...n.ch> wrote:
>>>
>>>> +&gmac0 {
>>>> +     clock_in_out = "output";
>>>> +     phy-mode = "rgmii-rxid";
>>>
>>> rgmii-rxid is odd. Does the PCB really have an extra long TX clock
>>> line, but a short RX clock line?
>>>
>>> Try changing this to rgmii-id, and drop the tx_delay property.
>>
>> Actually it would be great if Rockchip could clarify the delay
>> duration introduced by a single delay element in GMAC-IOMUX delay
>> lines, which are controlled in the GMAC driver by the {tx,rx}_delay
>> properties. Maybe we could then switch to using
>> {tx,rx}_internal_delay_ps for fine-tuning the delays on the GMAC side
>> as envisaged in DT bindings [1], and use phy-mode = "rgmii-id"
>> throughout. Chaoyi, any chance you could ask around in your hardware
>> team?
>>
>> Currently though removing the delays at GMAC side altogether causes
>> unstable link operation - see [2] for example.
>>
>> [1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L342-L347
>> [2] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/372f3e9ae62cc62cdf2543391ea57be6bb548a0c
> 
> Sorry, this problem has been discussed many times before. It's because 
> the gmac on the Rockchip platform currently relies on setting the 
> corresponding delay via phy-mode [3].
> 
> [3] https://lore.kernel.org/all/mqoyjn7mnq6tmt6n6oev4wa3herjaxlupml2fmcampwiajvj4a@r5zs4d3jdm5p/
> 
> The delay introduced by the delay line is not absolute. In reality,
> it depends on factors such as the chip's design and process technology.
> 
> And for RK3576, you can assume that:
> 	
> 	time(ns) = 0.0579 * delay_line_count + 0.105
> 
> For example, tx_delay = <0x20> means:
> 
> 	time = 0.0579 * 0x20 + 0.105 ns = 1.9578 ns
> 
> And I believe {tx,rx}_internal_delay_ps is indeed a good idea. 
> I'll try to add them in v3. Thanks.
>

I've also see some dt that use {tx,rx}_internal_delay_ps inside the PHY,
and compared to doing it in the MAC, which one is the better choice?

-- 
Best, 
Chaoyi