linux-kernel - Re: [net-next RFC PATCH v2 2/3] net: phy: Add support for Aeonsemi AS21xxx PHYs

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: <67e41384.5d0a0220.e4975.e9c3@mx.google.com>
Date: Wed, 26 Mar 2025 15:47:29 +0100
From: Christian Marangi <ansuelsmth@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
	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>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next RFC PATCH v2 2/3] net: phy: Add support for Aeonsemi
 AS21xxx PHYs

On Wed, Mar 26, 2025 at 02:57:09PM +0100, Andrew Lunn wrote:
> > In summary, I really don't like this approach - it feels too much of a
> > hack, _and_ introduces the potential for drivers that makes use of this
> > to get stuff really very wrong. In my opinion that's not a model that
> > we should add to the kernel.
> 
> I agree.
> 
> > 
> > I'll say again - why can't the PHY firmware be loaded by board firmware.
> > You've been silent on my feedback on this point. Given that you're
> > ignoring me... for this patch series...
> 
> And i still think using the match op is something that should be
> investigated, alongside the bootloader loading firmware.
>

The main problem (as said in the other answer) is that I feel match op
won't solve the problem and doesn't seems the good place to do complex
operation like OF and load firmware.

But now that I think about it your idea was to define a match_phy_device
for each PHY ID... The generic PHY ID is detected and firmware is loaded
and the PHY ID is checked again?

That way any other call of match_phy_device for other PHY of the same
family will found the FW loaded and check the ID?

That might work but sound more like a trick than a solid implementation.

-- 
	Ansuel