netdev - Re: [PATCH 4/5] arm64: dts: allwinner: a527: add EMAC0 to Radxa A5E 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: <7fcedce7-5cfe-48a4-9769-e6e7e82dc786@lunn.ch>
Date: Thu, 24 Apr 2025 21:02:35 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jernej Škrabec <jernej.skrabec@...il.com>
Cc: Andre Przywara <andre.przywara@....com>, 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>,
	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, clabbe.montjoie@...il.com
Subject: Re: [PATCH 4/5] arm64: dts: allwinner: a527: add EMAC0 to Radxa A5E
 board

> In my experience, vendor DT has proper delays specified, just 7 instead of
> 700, for example. What they get wrong, or better said, don't care, is phy
> mode. It's always set to rgmii because phy driver most of the time ignores
> this value and phy IC just uses mode set using resistors. Proper way here
> would be to check schematic and set phy mode according to that. This method
> always works, except for one board, which had resistors set wrong and
> phy mode configured over phy driver was actually fix for it.

What PHY driver is this? If it is ignoring the mode, it is broken.

We have had problems in the past in this respect. A PHY driver which
ignored the RGMII modes, and strapping was used. That 'worked' until
somebody built a board with broken strapping and added code to respect
the RGMII mode, overriding the strapping. It made that board work, but
broke lots of others which had the wrong RGMII mode....

If we have this again, i would like to know so we can try to get in
front of the problem, before we have lots of broken boards...

	Andrew