Re: [net-next RFC PATCH 6/6] net: phy: bcm7xxx: rework phy_driver table to new multiple PHY ID format

[Christian Marangi]

On Mon, Feb 19, 2024 at 12:15:14PM -0800, Florian Fainelli wrote:
> 
> 
> On 2/19/2024 8:41 AM, Christian Marangi wrote:
> > On Sun, Feb 18, 2024 at 08:26:29PM -0800, Florian Fainelli wrote:
> > > 
> > > 
> > > On 2/18/2024 11:00 AM, Christian Marangi wrote:
> > > > Rework bcm7xxx PHY driver table to new multiple PHY format
> > > > implementation to reduce code duplication and final size of the compiled
> > > > module.
> > > 
> > > I like the idea of sharing as much code as possible and creating a smaller
> > > module, however by changing the name, you are creating an user-space ABI
> > > change, we rely upon the exact PHY name being shown under
> > > /sys/class/mdio_bus/*/* and this change will break that.
> > > 
> > 
> > Thanks for putting this concern on the table but isn't that generated by
> > dev_set_name and PHY_ID_FMT? from bus->id and addr?
> > 
> > Can't find reference of the name entry in sysfs. Am I missing something?
> > The name seems to be used only by logging to print info/err/warn.
> 
> The name will appear under /sys/ like this:
> 
> ls -ls /sys/class/mdio_bus/unimac-mdio-0/unimac-mdio-0\:01/
> total 0
>      0 lrwxrwxrwx    1 root     root             0 Jan  4 21:27 attached_dev
> -> ../../../../net/eth0
>      0 lrwxrwxrwx    1 root     root             0 Jan  4 21:27 driver ->
> ../../../../../../../../bus/mdio_bus/drivers/Broadcom BCM7712
> 
> it might be OK to change the driver, but I can tell you this is going to be
> breaking a number of our scripts here...

Thanks for the command, yes I just notice the problem and yes it's
problematic... Starting to think that the only way to have this cleanup
is to detach ops from the phy_driver struct.

Not fiding a good way to handle the name problem...

-- 
	Ansuel