Re: [PATCH net-next] net: dsa: honor "max-speed" for implicit PHYs on user ports

["Sverdlin, Alexander" <alexander.sverdlin@siemens.com>]

Hi Vladimir!

On Thu, 2024-12-19 at 21:36 +0200, Vladimir Oltean wrote:
> On Thu, Dec 19, 2024 at 06:50:18PM +0000, Sverdlin, Alexander wrote:
> > There are still switch drivers in tree, which only implement .phy_read/.phy_write
> > callbacks (which means, they rely on .user_mii_bus ?), even gigabit-capable,
> > such as vsc73xx, rtl8365mb, rtl8366rb... But I'm actually interested in an
> > out of tree driver for a new generation of lantiq_gsw hardware, under
> > Maxlinear branch, which is planned to be submitted upstream at some point.
> > 
> > The relevant question is then, is it acceptable API (.phy_read/.phy_write),
> > or any new gigabit-capable driver must use some form of mdiobus_register
> > to populate the MDIO bus explicitly itself?
> 
> See the documentation patches which I never managed to finish for general
> future directions:
> https://patchwork.kernel.org/project/netdevbpf/patch/20231208193518.2018114-4-vladimir.oltean@nxp.com/
> 
> Not explicitly having a phy-handle should be seen a legacy feature,
> which we are forced to keep for compatibility with existing drivers.

Thanks for the references!

I've complitely missed the story of
fe7324b93222 ("net: dsa: OF-ware slave_mii_bus")
vs ae94dc25fd73
("net: dsa: remove OF-based MDIO bus registration from DSA core").

But I'm still having hard time to get the motivation behind removing
2 function calls from the DSA core and forcing all individual DSA drivers
to have this very same boilerplate...

But well, if all the DSA maintainers are so committed to it, this answers
my original question... Please ignore the patch!

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com