[RFC net-next] net: phy: Allow splitting MDIO bus/device support from PHYs

[RFC net-next] net: phy: Allow splitting MDIO bus/device support from PHYs

[Florian Fainelli]

Introduce a new configuration symbol: MDIO_DEVICE which allows building
the MDIO devices and bus code, without pulling in the entire Ethernet
PHY library and devices code.

PHYLIB nows select MDIO_DEVICE and the relevant Makefile files are
updated to reflect that.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 drivers/net/Makefile       |  2 +-
 drivers/net/phy/Kconfig    | 59 ++++++++++++++++++++++++++--------------------
 drivers/net/phy/Makefile   |  3 ++-
 drivers/net/phy/mdio_bus.c |  2 ++
 4 files changed, 39 insertions(+), 27 deletions(-)

diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 7336cbd3ef5d..a701e390d48f 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -17,7 +17,7 @@ obj-$(CONFIG_MII) += mii.o
 obj-$(CONFIG_MDIO) += mdio.o
 obj-$(CONFIG_NET) += Space.o loopback.o
 obj-$(CONFIG_NETCONSOLE) += netconsole.o
-obj-$(CONFIG_PHYLIB) += phy/
+obj-$(CONFIG_MDIO_DEVICE) += phy/
 obj-$(CONFIG_RIONET) += rionet.o
 obj-$(CONFIG_NET_TEAM) += team/
 obj-$(CONFIG_TUN) += tun.o
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 8dbd59baa34d..01152fb9cb76 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -2,33 +2,12 @@
 # PHY Layer Configuration
 #
 
-menuconfig PHYLIB
-	tristate "PHY Device support and infrastructure"
-	depends on NETDEVICES
+menuconfig MDIO_DEVICE
+	tristate "MDIO bus device drivers"
 	help
-	  Ethernet controllers are usually attached to PHY
-	  devices.  This option provides infrastructure for
-	  managing PHY devices.
-
-if PHYLIB
-
-config SWPHY
-	bool
-
-config LED_TRIGGER_PHY
-	bool "Support LED triggers for tracking link state"
-	depends on LEDS_TRIGGERS
-	---help---
-	  Adds support for a set of LED trigger events per-PHY.  Link
-	  state change will trigger the events, for consumption by an
-	  LED class driver.  There are triggers for each link speed currently
-	  supported by the phy, and are of the form:
-	       <mii bus id>:<phy>:<speed>
-
-	  Where speed is in the form:
-		<Speed in megabits>Mbps or <Speed in gigabits>Gbps
+	   MDIO devices and driver infrastructure code.
 
-comment "MDIO bus device drivers"
+if MDIO_DEVICE
 
 config MDIO_BCM_IPROC
 	tristate "Broadcom iProc MDIO bus controller"
@@ -160,6 +139,36 @@ config MDIO_XGENE
 	  This module provides a driver for the MDIO busses found in the
 	  APM X-Gene SoC's.
 
+endif
+
+menuconfig PHYLIB
+	tristate "PHY Device support and infrastructure"
+	depends on NETDEVICES
+	select MDIO_DEVICE
+	help
+	  Ethernet controllers are usually attached to PHY
+	  devices.  This option provides infrastructure for
+	  managing PHY devices.
+
+if PHYLIB
+
+config SWPHY
+	bool
+
+config LED_TRIGGER_PHY
+	bool "Support LED triggers for tracking link state"
+	depends on LEDS_TRIGGERS
+	---help---
+	  Adds support for a set of LED trigger events per-PHY.  Link
+	  state change will trigger the events, for consumption by an
+	  LED class driver.  There are triggers for each link speed currently
+	  supported by the phy, and are of the form:
+	       <mii bus id>:<phy>:<speed>
+
+	  Where speed is in the form:
+		<Speed in megabits>Mbps or <Speed in gigabits>Gbps
+
+
 comment "MII PHY device drivers"
 
 config AMD_PHY
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 356859ac7c18..441d228f53ed 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -1,6 +1,7 @@
 # Makefile for Linux PHY drivers and MDIO bus drivers
 
-libphy-y			:= phy.o phy_device.o mdio_bus.o mdio_device.o
+libphy-y			:= phy.o phy_device.o
+obj-$(CONFIG_MDIO_DEVICE)	+= mdio_device.o mdio_bus.o
 libphy-$(CONFIG_SWPHY)		+= swphy.o
 libphy-$(CONFIG_LED_TRIGGER_PHY)	+= phy_led_triggers.o
 
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 653d076eafe5..fa6bd2a2ce3e 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -644,9 +644,11 @@ int __init mdio_bus_init(void)
 
 	return ret;
 }
+EXPORT_SYMBOL_GPL(mdio_bus_init);
 
 void mdio_bus_exit(void)
 {
 	class_unregister(&mdio_bus_class);
 	bus_unregister(&mdio_bus_type);
 }
+EXPORT_SYMBOL_GPL(mdio_bus_exit);
-- 
2.9.3

Re: [RFC net-next] net: phy: Allow splitting MDIO bus/device support from PHYs

[Florian Fainelli]

On 01/30/2017 07:29 PM, Florian Fainelli wrote:
> Introduce a new configuration symbol: MDIO_DEVICE which allows building
> the MDIO devices and bus code, without pulling in the entire Ethernet
> PHY library and devices code.
> 
> PHYLIB nows select MDIO_DEVICE and the relevant Makefile files are
> updated to reflect that.
> 
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

Andrew, Russell, does that seem sensible to you, shall I re-submit this
as a proper patch?
-- 
Florian

Re: [RFC net-next] net: phy: Allow splitting MDIO bus/device support from PHYs

[Andrew Lunn]

> > Introduce a new configuration symbol: MDIO_DEVICE which allows building
> > the MDIO devices and bus code, without pulling in the entire Ethernet
> > PHY library and devices code.
> > 
> > PHYLIB nows select MDIO_DEVICE and the relevant Makefile files are
> > updated to reflect that.
> > 
> > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> 
> Andrew, Russell, does that seem sensible to you, shall I re-submit this
> as a proper patch?

Hi Florian

It does make sense, given that we have some MDIO busses not used for
networking.

	Andrew

Re: [RFC net-next] net: phy: Allow splitting MDIO bus/device support from PHYs

[Russell King - ARM Linux]

On Mon, Feb 06, 2017 at 04:01:27PM -0800, Florian Fainelli wrote:
> On 01/30/2017 07:29 PM, Florian Fainelli wrote:
> > Introduce a new configuration symbol: MDIO_DEVICE which allows building
> > the MDIO devices and bus code, without pulling in the entire Ethernet
> > PHY library and devices code.
> > 
> > PHYLIB nows select MDIO_DEVICE and the relevant Makefile files are
> > updated to reflect that.
> > 
> > Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> 
> Andrew, Russell, does that seem sensible to you, shall I re-submit this
> as a proper patch?

I think the only comment I have is that I'd recommend that mdio_bus
and mdio_device end up as one module rather than two for these reasons:

1. they're each relatively small on their own
2. their functionality is tightly related
3. I wonder about the safety of having mdio_device_release() in a
   separate module from the bus_type stuff.

as far as (3) goes, there isn't a good way to ensure that the last
device has been released, and bus_type's (even though they normally
end up as static data) are refcounted objects just like devices, so
I wonder whether allowing driver model bus stuff to be removable is
a good idea.

To that end, I'd add a module_init() for mdio_bus_init() but remove
mdio_bus_exit() entirely, which should mean that the module loader
considers the module non-removable.

Lastly, as this is becoming (a) separate module(s), MODULE_LICENSE()
as an absolute minimum will be required.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.