Re: [net-next PATCH 1/2] net: phy: Add support for new Aeonsemi PHYs

[Christian Marangi <ansuelsmth@gmail.com>]

On Tue, Mar 25, 2025 at 09:33:26PM +0100, Andrew Lunn wrote:
> On Tue, Mar 25, 2025 at 01:04:30PM +0100, Christian Marangi wrote:
> > On Mon, Mar 24, 2025 at 04:16:09PM +0100, Andrew Lunn wrote:
> > > On Mon, Mar 24, 2025 at 03:16:08PM +0100, Christian Marangi wrote:
> > > > On Mon, Mar 24, 2025 at 03:03:51PM +0100, Andrew Lunn wrote:
> > > > > > Supported PHYs AS21011JB1, AS21011PB1, AS21010JB1, AS21010PB1,
> > > > > > AS21511JB1, AS21511PB1, AS21510JB1, AS21510PB1, AS21210JB1,
> > > > > > AS21210PB1 that all register with the PHY ID 0x7500 0x7500
> > > > > > before the firmware is loaded.
> 
> Do you have details of how these different PHY differ? Do they have
> different features?
>

No but I can ask more details. From what I can assume, gigabit, 2.5g 10g
and probably a PHY that expose multiple port (PHY package thing)

> > Ok update on this... The PHY report 7500 7500 but on enabling PTP clock,
> > a more specific ""family"" ID is filled in MMD that is 0x7500 0x9410.
> 
> Do they all support PTP?
> 

With PTP it's not the PTP we think but I guess it's something internal to
the PHY to actually start it. From comments it's called PTP Clock...

> > They all use the same firmware so matching for the family ID might not
> > be a bad idea... The alternative is either load the firmware in
> > match_phy_device or introduce some additional OPs to handle this
> > correctly...
> > 
> > Considering how the thing are evolving with PHY I really feel it's time
> > we start introducing specific OP for firmware loading and we might call
> > this OP before PHY ID matching is done (or maybe do it again).
> 
> You cannot download firmware before doing some sort of match, because
> you have no idea what PHY you actually have until you do a match, and
> if the PHY needs firmware.
> 
> match_phy_device() gives you a bit more flexibility. It will be called
> for every PHY on the board, independent of the ID registers. So you
> can read the ID registers, see if it is at least a vendor you know how
> to download firmware to, do the download, and then look at the ID
> registers again to see if it is the version of the PHY you want to
> drive. If not, return -ENODEV, and the core will try the next driver
> entry.
>

I'm finishing preparing V2 and I'm curious what you will think of the
implementation.

The approach I found works good is permit PHY device to register a
second time and the PHY driver toggle this.

This way in a PHY driver we register OPs for the to-be-init PHY and then
we probe the real one.

-- 
	Ansuel