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

[Heiner Kallweit <hkallweit1@gmail.com>]

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