linux-kernel - Re: [PATCH] arm64: dts: rockchip: increase gmac rx

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] [day] [month] [year] [list]

Message-ID: <CAPv9Zmmz2W6aU16n1NYZvCrMcsXL8QK3d-mtfWy6d0vsTaNYQw@mail.gmail.com>
Date: Thu, 5 Dec 2024 13:51:28 +0100
From: Jakob Unterwurzacher <jakobunt@...il.com>
To: Peter Geis <pgwipeout@...il.com>
Cc: Heiko Stübner <heiko@...ech.de>, 
	Rob Herring <robh+dt@...nel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, 
	Sasha Levin <sashal@...nel.org>, Iskander Amara <iskander.amara@...obroma-systems.com>, 
	Jakob Unterwurzacher <jakob.unterwurzacher@...rry.de>, 
	Vahe Grigoryan <vahe.grigoryan@...obroma-systems.com>, 
	Quentin Schulz <quentin.schulz@...rry.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: rockchip: increase gmac rx_delay to 0x11 on rk3399-puma

On Thu, Dec 5, 2024 at 2:33 AM Peter Geis <pgwipeout@...il.com> wrote:
> > > > Cycling through the rx_delay range on two boards shows that is a large
> > > > "good" region from 0x11 to 0x35 (see below for details).
> > > >
> > >
> > > Is this missing a "there" after that? "that there is a large good region"?
>
> That large good region is actually an eye that you are aligning to the
> clock signal. The board is on the tail end of the eye where it is
> barely working. This value is supposed to be tuned to be in the middle
> of that eye. You may want to test the old boards against the new
> boards, because if the original board was tuned correctly something
> may have changed in hardware that caused a significant shift in the
> eye location. Examples of this would be changing to a new phy,
> enabling phy delays, or changes in the trace length. If this is the
> case, you'll probably want to make a new variant of the dts to cover
> this.

Thanks for the comment.

Nothing should have changed on the board, and I dug out a really old
one to verify. It behaves the same.
0x10 seems to be the lower edge of things still working.

I will put rx_delay in the center of the eye with the v3 patch.

I also checked tx_delay, and we already seem to be in the middle of
the eye, so I won't touch it.

Best regards,
Jakob