linux-kernel - 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: <CAGb2v65GPqr5Vnqb_MhAJBAjQzd-vKi1g1pJ53oUnF0Ym2PH9g@mail.gmail.com>
Date: Fri, 25 Apr 2025 03:05:17 +0800
From: Chen-Yu Tsai <wens@...e.org>
To: Andrew Lunn <andrew@...n.ch>
Cc: Jernej Škrabec <jernej.skrabec@...il.com>, 
	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>, 
	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

On Fri, Apr 25, 2025 at 3:02 AM Andrew Lunn <andrew@...n.ch> wrote:
>
> > 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...

I think the incident you are referring to is exactly the one that Jernej
mentioned.

And regarding the bad PHY driver, it could simply be that the PHY driver
was not built or not loaded, hence the kernel falling back to the generic
one, which of course doesn't know how to set the modes.

ChenYu