[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250424142006.021d6ab4@donnerap.manchester.arm.com>
Date: Thu, 24 Apr 2025 14:20:06 +0100
From: Andre Przywara <andre.przywara@....com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Yixun Lan <dlan@...too.org>, Rob Herring <robh@...nel.org>, Krzysztof
Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Chen-Yu
Tsai <wens@...e.org>, Jernej Skrabec <jernej.skrabec@...il.com>, Samuel
Holland <samuel@...lland.org>, Maxime Ripard <mripard@...nel.org>, Andrew
Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo
Abeni <pabeni@...hat.com>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 4/5] arm64: dts: allwinner: a527: add EMAC0 to Radxa A5E
board
On Thu, 24 Apr 2025 14:19:59 +0200
Andrew Lunn <andrew@...n.ch> wrote:
Hi Andrew,
> > I'd not bother to try other combinations, and just stick to vendor's
> > settings
>
> Vendors get stuff wrong all the time. Just because it works does not
> mean it is correct. And RGMII delays are very frequently wrong because
> there are multiple ways to get a link which works, but don't follow
> the DT binding.
Speaking of which: do you know of a good method to verify the delay
timing? Is there *something* which is sensitive to those timings and which
can be easily checked and qualified?
I just tried iperf3 yesterday, but didn't spot any real change in the
numbers when toying with those delay values.
As mentioned in the other email, we can easily hack the values at runtime,
so if there is a way to get some "quality" value, this could even be
automated.
Thanks,
Andre
Powered by blists - more mailing lists