netdev - Re: [PATCH net-next v3 8/8] Revert "net: dsa: OF-ware slave_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]

Message-ID: <92fe7016-8c01-4f82-b7ec-a23f52348059@arinc9.com>
Date: Sat, 6 Jan 2024 14:36:43 +0300
From: Arınç ÜNAL <arinc.unal@...nc9.com>
To: Luiz Angelo Daros de Luca <luizluca@...il.com>, netdev@...r.kernel.org
Cc: linus.walleij@...aro.org, alsi@...g-olufsen.dk, andrew@...n.ch,
 f.fainelli@...il.com, olteanv@...il.com, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com
Subject: Re: [PATCH net-next v3 8/8] Revert "net: dsa: OF-ware slave_mii_bus"

On 30.12.2023 18:56, Arınç ÜNAL wrote:
> On 30.12.2023 10:18, Arınç ÜNAL wrote:
>> I think we should do all this in a single patch. I've done it on the MT7530
>> DSA subdriver which I maintain.
> 
> Actually, there's no need to drag this patch further by including the
> improvement of handling the MDIO bus on all relevant subdrivers.
> 
> That said, I'd like to submit this patch myself, if it is OK by everyone
> here.
> 
> Here's the patch log I've prepared:
> 
> net: dsa: do not populate user_mii_bus when switch MDIO bus is described
> 
> The use of ds->user_mii_bus is inappropriate when the MDIO bus of the
> switch is described on the device-tree [1].
> 
> To keep things simple, make [all subdrivers that control switches [with
> MDIO bus] probed on OF] register the bus on the subdriver. This is already
> the case on all of these subdrivers.
> 
> There can be a case where ds->user_mii_bus is not populated, but
> ds_switch_ops.phy_{read,write} is. That would mean the subdriver controls
> switches probed on OF, and it lets the DSA core driver to populate
> ds->user_mii_bus and register the bus. We don't want this to happen.
> Therefore, ds_switch_ops.phy_{read,write} should be only used on the
> subdrivers that control switches probed on platform_data.
> 
> With that, the "!ds->user_mii_bus && ds->ops->phy_read" check under
> dsa_switch_setup() remains in use only for switches probed on
> platform_data. Therefore, remove OF-based registration as it's useless now.
> 
> Currently, none of the subdrivers that control switches [with MDIO bus]
> probed on OF implements ds_switch_ops.phy_{read,write} so no subdriver will
> be affected by this patch.

It looks like this patch will cause the MDIO bus of the switches probed on
OF which are controlled by these subdrivers to only be registered
non-OF-based.

drivers/net/dsa/b53/b53_common.c
drivers/net/dsa/lan9303-core.c
drivers/net/dsa/vitesse-vsc73xx-core.c

These subdrivers let the DSA driver register the bus OF-based or
non-OF-based:
- ds->ops->phy_read() and ds->ops->phy_write() are present.
- ds->user_mii_bus is not populated.

Not being able to register the bus OF-based may cause issues. There is an
example for the switch on the MT7988 SoC which is controlled by the MT7530
DSA subdriver. Being able to reference the PHYs on the switch MDIO bus is
mandatory on MT7988 as calibration data from NVMEM for each PHY is
required.

I suggest that we hold off on this patch until these subdrivers are made to
be capable of registering the MDIO bus as OF-based on their own.

Arınç