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

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

[Heiner Kallweit]

MDIO_DEVRES is only set where PHYLIB/PHYLINK are set which
select MDIO_DEVRES. So we can remove this symbol.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
 drivers/net/ethernet/freescale/Kconfig       |  1 -
 drivers/net/ethernet/freescale/enetc/Kconfig |  2 --
 drivers/net/ethernet/marvell/Kconfig         |  1 -
 drivers/net/ethernet/qualcomm/Kconfig        |  1 -
 drivers/net/mdio/Kconfig                     | 11 -----------
 drivers/net/phy/Kconfig                      |  1 -
 drivers/net/phy/Makefile                     |  2 +-
 7 files changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index a2d730092..bbef47c34 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -71,7 +71,6 @@ config FSL_XGMAC_MDIO
 	tristate "Freescale XGMAC MDIO"
 	select PHYLIB
 	depends on OF
-	select MDIO_DEVRES
 	select OF_MDIO
 	help
 	  This driver supports the MDIO bus on the Fman 10G Ethernet MACs, and
diff --git a/drivers/net/ethernet/freescale/enetc/Kconfig b/drivers/net/ethernet/freescale/enetc/Kconfig
index 7250d3bbf..f3a6b3752 100644
--- a/drivers/net/ethernet/freescale/enetc/Kconfig
+++ b/drivers/net/ethernet/freescale/enetc/Kconfig
@@ -18,7 +18,6 @@ config NXP_ENETC_PF_COMMON
 config FSL_ENETC
 	tristate "ENETC PF driver"
 	depends on PCI_MSI
-	select MDIO_DEVRES
 	select FSL_ENETC_CORE
 	select FSL_ENETC_IERB
 	select FSL_ENETC_MDIO
@@ -36,7 +35,6 @@ config FSL_ENETC
 config NXP_ENETC4
 	tristate "ENETC4 PF driver"
 	depends on PCI_MSI
-	select MDIO_DEVRES
 	select FSL_ENETC_CORE
 	select FSL_ENETC_MDIO
 	select NXP_ENETC_PF_COMMON
diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig
index 837295fec..50f7c59e8 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -34,7 +34,6 @@ config MV643XX_ETH
 config MVMDIO
 	tristate "Marvell MDIO interface support"
 	depends on HAS_IOMEM
-	select MDIO_DEVRES
 	select PHYLIB
 	help
 	  This driver supports the MDIO interface found in the network
diff --git a/drivers/net/ethernet/qualcomm/Kconfig b/drivers/net/ethernet/qualcomm/Kconfig
index 9210ff360..a4434eb38 100644
--- a/drivers/net/ethernet/qualcomm/Kconfig
+++ b/drivers/net/ethernet/qualcomm/Kconfig
@@ -52,7 +52,6 @@ config QCOM_EMAC
 	depends on HAS_DMA && HAS_IOMEM
 	select CRC32
 	select PHYLIB
-	select MDIO_DEVRES
 	help
 	  This driver supports the Qualcomm Technologies, Inc. Gigabit
 	  Ethernet Media Access Controller (EMAC). The controller
diff --git a/drivers/net/mdio/Kconfig b/drivers/net/mdio/Kconfig
index 107236cd6..d3219ca19 100644
--- a/drivers/net/mdio/Kconfig
+++ b/drivers/net/mdio/Kconfig
@@ -38,9 +38,6 @@ config ACPI_MDIO
 	help
 	  ACPI MDIO bus (Ethernet PHY) accessors
 
-config MDIO_DEVRES
-	tristate
-
 config MDIO_SUN4I
 	tristate "Allwinner sun4i MDIO interface support"
 	depends on ARCH_SUNXI || COMPILE_TEST
@@ -60,7 +57,6 @@ config MDIO_ASPEED
 	tristate "ASPEED MDIO bus controller"
 	depends on ARCH_ASPEED || COMPILE_TEST
 	depends on OF_MDIO && HAS_IOMEM
-	select MDIO_DEVRES
 	help
 	  This module provides a driver for the independent MDIO bus
 	  controllers found in the ASPEED AST2600 SoC. This is a driver for the
@@ -130,7 +126,6 @@ config MDIO_I2C
 config MDIO_MVUSB
 	tristate "Marvell USB to MDIO Adapter"
 	depends on USB
-	select MDIO_DEVRES
 	help
 	  A USB to MDIO converter present on development boards for
 	  Marvell's Link Street family of Ethernet switches.
@@ -138,7 +133,6 @@ config MDIO_MVUSB
 config MDIO_MSCC_MIIM
 	tristate "Microsemi MIIM interface support"
 	depends on HAS_IOMEM && REGMAP_MMIO
-	select MDIO_DEVRES
 	help
 	  This driver supports the MIIM (MDIO) interface found in the network
 	  switches of the Microsemi SoCs; it is recommended to switch on
@@ -156,7 +150,6 @@ config MDIO_OCTEON
 	depends on (64BIT && OF_MDIO) || COMPILE_TEST
 	depends on HAS_IOMEM
 	select MDIO_CAVIUM
-	select MDIO_DEVRES
 	help
 	  This module provides a driver for the Octeon and ThunderX MDIO
 	  buses. It is required by the Octeon and ThunderX ethernet device
@@ -166,7 +159,6 @@ config MDIO_IPQ4019
 	tristate "Qualcomm IPQ4019 MDIO interface support"
 	depends on HAS_IOMEM && OF_MDIO
 	depends on COMMON_CLK
-	select MDIO_DEVRES
 	help
 	  This driver supports the MDIO interface found in Qualcomm
 	  IPQ40xx, IPQ60xx, IPQ807x and IPQ50xx series Soc-s.
@@ -175,7 +167,6 @@ config MDIO_IPQ8064
 	tristate "Qualcomm IPQ8064 MDIO interface support"
 	depends on HAS_IOMEM && OF_MDIO
 	depends on MFD_SYSCON
-	select MDIO_DEVRES
 	help
 	  This driver supports the MDIO interface found in the network
 	  interface units of the IPQ8064 SoC
@@ -183,7 +174,6 @@ config MDIO_IPQ8064
 config MDIO_REALTEK_RTL9300
 	tristate "Realtek RTL9300 MDIO interface support"
 	depends on MACH_REALTEK_RTL || COMPILE_TEST
-	select MDIO_DEVRES
 	help
 	  This driver supports the MDIO interface found in the Realtek
 	  RTL9300 family of Ethernet switches with integrated SoC.
@@ -204,7 +194,6 @@ config MDIO_THUNDER
 	depends on 64BIT
 	depends on PCI
 	select MDIO_CAVIUM
-	select MDIO_DEVRES
 	help
 	  This driver supports the MDIO interfaces found on Cavium
 	  ThunderX SoCs when the MDIO bus device appears as a PCI
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 0b8cc325e..677d56e06 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -15,7 +15,6 @@ config PHYLINK
 menuconfig PHYLIB
 	tristate "PHY Device support and infrastructure"
 	select MDIO_DEVICE
-	select MDIO_DEVRES
 	help
 	  Ethernet controllers are usually attached to PHY
 	  devices.  This option provides infrastructure for
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 631859d44..59ac3a9a3 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -20,7 +20,7 @@ obj-y				+= stubs.o
 else
 obj-$(CONFIG_MDIO_DEVICE)	+= mdio-bus.o
 endif
-obj-$(CONFIG_MDIO_DEVRES)	+= mdio_devres.o
+obj-$(CONFIG_PHYLIB)		+= mdio_devres.o
 libphy-$(CONFIG_SWPHY)		+= swphy.o
 libphy-$(CONFIG_LED_TRIGGER_PHY)	+= phy_led_triggers.o
 libphy-$(CONFIG_OPEN_ALLIANCE_HELPERS) += open_alliance_helpers.o
-- 
2.49.0

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

[Russell King (Oracle)]

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?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Andrew Lunn]

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.

	Andrew

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

[Russell King (Oracle)]

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.

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.


-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Heiner Kallweit]

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

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

[Heiner Kallweit]

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

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

[Heiner Kallweit]

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