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: <Z-RBIZSdySXhQzra@shell.armlinux.org.uk>
Date: Wed, 26 Mar 2025 18:02:09 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: 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 03:43:47PM +0100, Christian Marangi wrote:
> On Wed, Mar 26, 2025 at 01:53:39PM +0000, Russell King (Oracle) wrote:
> > This probe function allocates devres resources that wil lbe freed when
> > it returns through the unbinding in patch 1. This is a recipe for
> > confusion - struct as21xxx_priv must never be used from any of the
> > "real" driver.
> > 
> > I would suggest:
> > 
> > 1. document that devres resources will not be preserved when
> >    phydev->needs_reregister is set true.
> > 
> > 2. rename struct as21xxx_priv to struct as21xxx_fw_load_priv to make
> >    it clear that it's for firmware loading.
> > 
> > 3. use a prefix that uniquely identifies those functions that can only
> >    be called with this structure populated.
> > 
> > 4. set phydev->priv to NULL at the end of this probe function to ensure
> >    no one dereferences the free'd pointer in a "real" driver, which
> >    could lead to use-after-free errors.
> > 
> > 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'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...
> > 
> > Hard NAK.
> > 
> > until you start responding to my review comments.
> >
> 
> No I wasn't ignoring you, the description in v1 for this was very
> generic and confusing so the idea was to post a real implementation so
> we could discuss on the code in practice... My comments were done before
> checking how phy_registration worked so they were only ideas (the
> implementation changed a lot from what was my idea) Sorry if I gave this
> impression while I was answering only to Andrew...
> 
> The problem of PHY firmware loaded by board firmware is that we
> introduce lots of assumption on the table. Also doesn't that goes
> against the idea that the kernel should not assume stuff set by the
> bootloader (if they can be reset and are not part of the core system?)
> 
> From what I'm seeing on devices that have this, SPI is never mounted and
> bootloader doesn't provide support for this and the thing is loaded only
> by the OS in a crap way.
> 
> Also the PHY doesn't keep the FW with an hardware reset and permit the
> kernel to load an updated (probably fixed) firmware is only beneficial.
> (there is plan to upstream firmware to linux-firmware)
> 
> I agree that the approach of declaring a "generic" PHY entry and "abuse"
> the probe function is an HACK, but I also feel using match_phy_device
> doesn't solve the problem.
> 
> Correct me if I'm wrong but match_phy_device will only give true or
> false, it won't solve the problem of the PHY changing after the FW is
> loaded.
> 
> This current approach permit to provide to the user the exact new OPs of
> the PHY detected after FW is loaded.
> 
> Is it really that bad to introduce the idea that a PHY family require
> some initial tuneup before it can correctly identified?

It's fragile, really fragile.

phy_device_register() can complete before the module loads, and thus
setting the flag has no effect.

Try building the PHY driver as a module with the code that registers
the PHY built-in...

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!