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: <c7771c90-9c0e-429e-b703-661e21e2b1e5@gmail.com>
Date: Wed, 7 May 2025 20:39:02 +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 16:21, Heiner Kallweit wrote:
> 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.
> 
After thinking again, I'll submit a v2 and will make mdio_devres part
of phylib.

> 
>> 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.
>>
>>
> 
-- 
pw-bot: cr