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: <8516361.T7Z3S40VBb@jernej-laptop>
Date: Thu, 24 Apr 2025 21:21:09 +0200
From: Jernej Škrabec <jernej.skrabec@...il.com>
To: Andrew Lunn <andrew@...n.ch>, wens@...e.org
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>, 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

Dne četrtek, 24. april 2025 ob 21:05:17 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> 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.

Mainline is sorted out as far as I'm aware. Broken PHY drivers are part
of BSP code drops, from where these values are taken from. So, for sure
I wouldn't trust phy mode set in BSP code, but allwinner,tx-delay-ps and
allwinner,rx-delay-ps are usually trustworthy.

Best regards,
Jernej