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

[Heiner Kallweit <hkallweit1@gmail.com>]

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