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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b708216ed804755678f01f62b286928763a1f645.camel@siemens.com>
Date: Fri, 20 Dec 2024 07:17:37 +0000
From: "Sverdlin, Alexander" <alexander.sverdlin@...mens.com>
To: "olteanv@...il.com" <olteanv@...il.com>, "andrew@...n.ch" <andrew@...n.ch>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] net: dsa: honor "max-speed" for implicit PHYs on
 user ports

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