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

[Christian Marangi <ansuelsmth@gmail.com>]

On Wed, Mar 26, 2025 at 06:08:09PM +0000, Russell King (Oracle) wrote:
> On Wed, Mar 26, 2025 at 03:56:15PM +0100, Andrew Lunn wrote:
> > After the firmware download, the phylib core will still have the wrong
> > ID values. So you cannot use PHY_ID_MATCH_EXACT(PHY_ID_AS21011JB1).
> > But what you can do is have a .match_phy_device function. It will get
> > called, and it can read the real ID from the device, and perform a
> > match. If it does not match return -ENODEV, and the core will try the
> > next entry.
> 
> Before it returns -ENODEV, it could re-read the ID values and fill
> them into struct phy_device. This would allow phylib's matching to
> work.
>

Is it ok for PHY driver to change values in phy_device ""externally"" to
phy_device.c ? Maybe you still have to read the other response but a
bool with needs_rescan to handle this internally? 

> > You either need N match_phy_device functions, one per ID value, or you
> > can make use of the .driver_data in phy_driver, and place the matching
> > data there.
> 
> An alternative would be to change the match_phy_device() method to
> pass the phy_driver, which would allow a single match_phy_device
> function to match the new hardware ID values against the PHY IDs in
> the phy_driver without needing to modify the IDs in phy_device.
> 

I also considered extending the function with additional stuff but then
I considered that would mean rework each PHY driver and destroy PHY
driver downstream, not something we should care but still quite a big
task. If the -ENODEV path is not OK, I feel an additional OP is better
than tweaking match_phy_device.

-- 
	Ansuel