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] [day] [month] [year] [list]

Message-ID: <03e2e1c7-326f-4b0e-94dd-18536c2f537e@gmail.com>
Date: Sun, 11 May 2025 23:06:39 +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 20:39, Heiner Kallweit wrote:
> 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.
> 
kernel test robot reported circular dependencies. So I'll re-submit
the original version, leaving mdio_devres a separate module.

depmod: ERROR: Cycle detected: libphy -> of_mdio -> fixed_phy -> libphy
depmod: ERROR: Cycle detected: libphy -> of_mdio -> libphy
depmod: ERROR: Cycle detected: libphy -> of_mdio -> fwnode_mdio -> libphy

>>
>>> 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.
>>>
>>>
>>