netdev - Re: [PATCH net-next] net: phy: remove Kconfig symbol MDIO

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: <fbe1e3e7-cd44-4e13-8cae-9b128d896a0e@gmail.com>
Date: Wed, 7 May 2025 16:21:36 +0200
From: Heiner Kallweit <hkallweit1@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Andrew Lunn <andrew@...n.ch>
Cc: Paolo Abeni <pabeni@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
 David Miller <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Claudiu Manoil <claudiu.manoil@....com>,
 Vladimir Oltean <vladimir.oltean@....com>, Wei Fang <wei.fang@....com>,
 Clark Wang <xiaoning.wang@....com>,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>, imx@...ts.linux.dev
Subject: Re: [PATCH net-next] net: phy: remove Kconfig symbol MDIO_DEVRES

On 07.05.2025 14:56, Russell King (Oracle) wrote:
> On Wed, May 07, 2025 at 02:49:05PM +0200, Andrew Lunn wrote:
>> On Wed, May 07, 2025 at 11:46:08AM +0100, Russell King (Oracle) wrote:
>>> On Wed, May 07, 2025 at 08:17:17AM +0200, Heiner Kallweit wrote:
>>>> MDIO_DEVRES is only set where PHYLIB/PHYLINK are set which
>>>> select MDIO_DEVRES. So we can remove this symbol.
>>>
>>> Does it make sense for mdio_devres to be a separate module from libphy?
>>
>> I _think_ Broadcom have one MDIO bus master which is not used for
>> PHYs/Switches but regulators or GPIOs or something. In theory, you
>> could build a kernel without networking, but still use those
>> regulators or GPIOs. But given that Broadcom SoCs are all about
>> networking, it does seem like a very unlikely situation.
> 
> I'm pointing out that:
> 
> libphy-y                        := phy.o phy-c45.o phy-core.o phy_device.o \
>                                    linkmode.o phy_link_topology.o \
>                                    phy_package.o phy_caps.o mdio_bus_provider.o
> 
> mdio_bus_provider.o provides at least some of the functions used by
> mdio_devres.
> 
> obj-$(CONFIG_PHYLIB)            += mdio_devres.o
> obj-$(CONFIG_PHYLIB)            += libphy.o
> 
> So, when PHYLIB=m, we end up with mdio_devres and libphy as two separate
> loadable modules. I'm questioning whether this makes any sense, or
> whether making mdio_devres part of libphy would be more sensible.
> 
I was asking myself the same question. If mdio_devres is a separate module,
then it won't be loaded if no active phylib user requires the devres
functionality, saving a little bit of memory. However mdio_devres is quite
small and we don't gain much.

For now I decided to keep the current behavior of mdio_devres being a
separate module. However if consensus is that we better make it part of
phylib, fine with me.


> Maybe the only case is if mdio_devres adds dependencies we don't want
> libphy to have, but I think that needs to be spelt out in the commit.
> 
>