netdev - Re: [PATCH net-next v2 5/7] net: dsa: realtek: Migrate user_mii

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]

Date: Fri, 22 Dec 2023 12:48:31 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Arınç ÜNAL <arinc.unal@...nc9.com>
Cc: Luiz Angelo Daros de Luca <luizluca@...il.com>,
	linus.walleij@...aro.org, alsi@...g-olufsen.dk, andrew@...n.ch,
	f.fainelli@...il.com, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 5/7] net: dsa: realtek: Migrate user_mii_bus
 setup to realtek-dsa

On Thu, Dec 21, 2023 at 09:34:52PM +0300, Arınç ÜNAL wrote:
> On 21.12.2023 20:47, Vladimir Oltean wrote:
> > ds->user_mii_bus helps when
> > (1) the switch probes with platform_data (not on OF), or
> > (2) the switch probes on OF but its MDIO bus is not described in OF
> > 
> > Case (2) is also eliminated because realtek_smi_setup_mdio() bails out
> > if it cannot find the "mdio" node described in OF. So the ds->user_mii_bus
> > assignment is only ever executed when the bus has an OF node, aka when
> > it is not useful.
> 
> I don't like the fact that the driver bails out if it doesn't find the
> "mdio" child node. This basically forces the hardware design to use the
> MDIO bus of the switch. Hardware designs which don't use the MDIO bus of
> the switch are perfectly valid.
> 
> It looks to me that, to make all types of hardware designs work, we must
> not use ds->user_mii_bus for switch probes on OF. Case (2) is one of the
> cases of the ethernet controller lacking link definitions in OF so we
> should enforce link definitions on ethernet controllers. This way, we make
> sure all types of hardware designs work and are described in OF properly.
> 
> Arınç

The bindings for the realtek switches can be extended in compatible ways,
e.g. by making the 'mdio' node optional. If we want that to mean "there
is no internal PHY that needs to be used", there is no better time than
now to drop the driver's linkage to ds->user_mii_bus, while its bindings
still strictly require an 'mdio' node.

If we don't drop that linkage _before_ making 'mdio' optional, there
is no way to disprove the existence of device trees which lack a link
description on user ports (which is now possible). So the driver will
always have to pay the penalty of mdiobus_register(ds->user_mii_bus),
which will always enumerate the internal PHYs even if they will end up
unused, as you say should be possible. Listing the MDIO bus in OF
deactivates bus scanning, which speeds up probing and booting in most
cases.

There are other ways to reduce that PHY enumeration pain, like manually
setting the bus->phy_mask and moving code around such that it gets
executed only once in the presence of -EPROBE_DEFER. This is what Klaus
Kudielka had to go through with mv88e6xxx, all because the Turris Omnia
device tree lacks phy-handle to the internal PHYs, his boot time shot up
by a wide margin.
https://lore.kernel.org/lkml/449bde236c08d5ab5e54abd73b645d8b29955894.camel@gmail.com/
commit 2c7e46edbd03 ("net: dsa: mv88e6xxx: mask apparently non-existing phys during probing")
commit 2cb0658d4f88 ("net: dsa: mv88e6xxx: move call to mv88e6xxx_mdios_register()")

We support device trees with 'hidden' switch internal MDIO buses and it
would be unwise to break them. But they are a self-inflicted pain and it
would be even more unwise for me to go on record not discouraging their use.
Honestly, I don't want any more of them.