linux-kernel - Re: [PATCH] arm64: dts: rockchip: change eth phy mode to rgmii-id for orangepi r1 plus lts

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: <5ce312f4-f496-4a62-bcda-5e6fbefde376@lunn.ch>
Date: Sun, 19 Jan 2025 17:05:50 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Dragan Simic <dsimic@...jaro.org>
Cc: Tianling Shen <cnsztl@...il.com>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Heiko Stuebner <heiko@...ech.de>, Jonas Karlman <jonas@...boo.se>,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, Peter Geis <pgwipeout@...il.com>
Subject: Re: [PATCH] arm64: dts: rockchip: change eth phy mode to rgmii-id
 for orangepi r1 plus lts

> >  &gmac2io {
> >  	phy-handle = <&yt8531c>;
> > -	tx_delay = <0x19>;
> > -	rx_delay = <0x05>;
> > +	phy-mode = "rgmii-id";
> 
> Shouldn't the "tx_delay" and "rx_delay" DT parameters be converted
> into the "tx-internal-delay-ps" and "rx-internal-delay-ps" parameters,
> respectively, so the Motorcomm PHY driver can pick them up and
> actually configure the internal PHY delays?

Maybe.

One problem is that tx_delay and rx_delay are really bad DT
bindings. They are basically values to be poked into a registers, with
no explanation of what they mean. Maybe 0x19 means 2ns? If so, that is
exactly what the PHY will do with rgmii-id, and you don't need any
additional properties.

The fact testing suggests this works does suggest these delay values
are around 2ns, so there is probably no need for
{rt}x-internal-delay-ps.

In general, i always suggest the PHY does the delay, just so that we
try to make all boards act in the same way. The fact this also removes
the use of these terrible tx_delay and rx_delay makes this patch even
better, if it can be shown to be reliable.

	Andrew