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

["Russell King (Oracle)" <linux@armlinux.org.uk>]

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!