linux-kernel - Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K

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: <20250831122800.330c9ab3.xunil@tahomasoft.com>
Date: Sun, 31 Aug 2025 12:28:00 -0400
From: Erik Beck <xunil@...omasoft.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Chukun Pan <amadeus@....edu.cn>, Heiko Stuebner <heiko@...ech.de>, Rob
 Herring <robh@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Krzysztof
 Kozlowski <krzk+dt@...nel.org>, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org
Subject: Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K

On Sun, 31 Aug 2025 17:53:19 +0200
Andrew Lunn <andrew@...n.ch> wrote:

> > > > Rockchip by default do bad things with RGMII delays.
> > > > 
> > > >  tx_delay:
> > > >    description: Delay value for TXD timing.
> > > >    $ref: /schemas/types.yaml#/definitions/uint32
> > > >    minimum: 0
> > > >    maximum: 0x7F
> > > >    default: 0x30
> > > > 
> > > >  rx_delay:
> > > >    description: Delay value for RXD timing.
> > > >    $ref: /schemas/types.yaml#/definitions/uint32
> > > >    minimum: 0
> > > >    maximum: 0x7F
> > > >    default: 0x10
> > > > 
> > > > Try setting both of these to 0. And then use 'rgmii-id'.
> > > > 
> > > >    Andrew    
> > Setting both gmac0 and gmac1 to phy-mode=rgmii-id with tx/rx delay set to
> > <0x0> yields about a 7x improvement from ~6 Mbs (with phy-mode=rgmii-id
> > and tx/rx delay unset) to about 43 Mbps, which is still well below the
> > ~950 Mbs with phy-mode=rgmii and tx/rx delay unset.  
> 
> You need to split the problem into two. Rx delays and Tx delays. Use
> something like iperf in UDP mode, to send a stream of UDP packets, or
> receive a stream of UDP packets. TCP is bad for this sort of testing
> because Rx and Tx are interconnected due to flow control and
> retransmissions.
> 
> Try small values of rx_delay to see if you can improve the Rx
> performance. Try small values to tx_delay, to see if you can improve
> the Tx performance.
> 
OK, thanks. 

Just so I am clear, the units are tenths of nanoseconds? So <0x02> is .2
nanoseconds?



> One problem we have with rx_delay and tx_delay is that they are
> magic. We have no idea what they mean. The RGMII standard says there
> should be a 2ns delay between data and clock. A poorly designed board
> could mean the MAC/PHY pair needs to insert say 1.8ns or 2.2ns, not
> 2ns as defined by the RGMiI standard. Rockchip also seem to encourage
> using rx_delay and tx_delay, so i would not be surprised to find
> Rockchip boards are often poorly designed and don't follow the RGMII
> standard.
> 
> rx_delay/tx_delay can probably insert 0.2ns of delay, but it probably
> cannot insert -0.2ns of delay. So it could be, you cannot improve
> it. If that is the case, we need to consider another solution.
> 
>    Andrew
>