MDIO buses enumerate firmware children only when the bus is registered. A
later devicetree overlay or status transition is ignored, unlike on I2C and
SPI buses. Supporting live reconfiguration also means that population and
removal can race address scanning, PHY attachment and bus teardown.

Patch 1 factors fixed-address child registration and legacy PHY scanning
into helpers shared by initial and dynamic population.

Patch 2 serializes MDIO device-map changes, reserves addresses while
registration is in progress, and coordinates scans, attachment, removal
and bus teardown. Dynamically removed devices remain pinned until bus
teardown, preserving the borrowed-pointer convention of
mdiobus_get_phy().

Patch 3 adds the OF reconfiguration notifier. It supports fixed-address
PHYs and generic MDIO devices, scanned PHY addresses, and Ethernet PHY
packages. It also preflights overlay removal and rejects removal of
attached or in-flight PHYs before their firmware nodes can disappear.

Build-tested on net-next with arm64 defconfig and x86_64 allmodconfig and
allyesconfig configurations under W=1. No warning was emitted from a
changed file. Runtime-tested on Allwinner H616 hardware with
notifier-driven addition of an AC300 control endpoint at a fixed MDIO
address, 20 relay-driven cold boots, 20 complete MAC/MDIO teardown and
recreation cycles, and link traffic after each topology was populated.

Changes v1 -> v2:
  - split the generic MDIO work from the ACx00 series
  - rebase onto current net-next
  - move touched declarations to function scope for netdev style
  - Link to v1:
    https://patch.msgid.link/20260802-submit-acx00-of-dynamic-v1-v1-0-0a53cd9e21cc@gmail.com

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
James Hilliard (3):
      net: mdio: factor out OF child registration helpers
      net: mdio: make device map changes hotplug-safe
      net: mdio: support dynamic OF device changes

 drivers/net/mdio/of_mdio.c          | 508 +++++++++++++++++++++++++++++++++---
 drivers/net/phy/mdio_bus.c          |  14 +-
 drivers/net/phy/mdio_bus_provider.c | 141 +++++++---
 drivers/net/phy/mdio_device.c       | 235 +++++++++++++++--
 drivers/net/phy/phy_device.c        | 102 ++++++--
 drivers/net/phy/phylib-internal.h   |   4 +-
 include/linux/mdio.h                |   6 +
 include/linux/phy.h                 |  18 ++
 8 files changed, 908 insertions(+), 120 deletions(-)
---
base-commit: d661abdc30c254649c32ef6e0aa1e621e04ff0a7
change-id: 20260803-submit-mdio-of-dynamic-v2-90560ca159b9

Best regards,
--  
James Hilliard <james.hilliard1@gmail.com>

On Mon, Aug 03, 2026 at 05:48:09PM -0600, James Hilliard wrote:
> MDIO buses enumerate firmware children only when the bus is registered. A
> later devicetree overlay or status transition is ignored, unlike on I2C and
> SPI buses. Supporting live reconfiguration also means that population and
> removal can race address scanning, PHY attachment and bus teardown.
> 
> Patch 1 factors fixed-address child registration and legacy PHY scanning
> into helpers shared by initial and dynamic population.
> 
> Patch 2 serializes MDIO device-map changes, reserves addresses while
> registration is in progress, and coordinates scans, attachment, removal
> and bus teardown. Dynamically removed devices remain pinned until bus
> teardown, preserving the borrowed-pointer convention of
> mdiobus_get_phy().
> 
> Patch 3 adds the OF reconfiguration notifier. It supports fixed-address
> PHYs and generic MDIO devices, scanned PHY addresses, and Ethernet PHY
> packages. It also preflights overlay removal and rejects removal of
> attached or in-flight PHYs before their firmware nodes can disappear.

This is a lot of complexity which i think should be avoided by just
getting the bootloader to put the correct nodes in DT.

If this was a hat on top of a SBC, with an EEPROM indicating what the
hat was, then maybe DT overlays would make sense. But from what you
have said, this is a fixed PCB design, nothing hot/cold plugable.

     Andrew

On Mon, Aug 3, 2026 at 8:06 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Mon, Aug 03, 2026 at 05:48:09PM -0600, James Hilliard wrote:
> > MDIO buses enumerate firmware children only when the bus is registered. A
> > later devicetree overlay or status transition is ignored, unlike on I2C and
> > SPI buses. Supporting live reconfiguration also means that population and
> > removal can race address scanning, PHY attachment and bus teardown.
> >
> > Patch 1 factors fixed-address child registration and legacy PHY scanning
> > into helpers shared by initial and dynamic population.
> >
> > Patch 2 serializes MDIO device-map changes, reserves addresses while
> > registration is in progress, and coordinates scans, attachment, removal
> > and bus teardown. Dynamically removed devices remain pinned until bus
> > teardown, preserving the borrowed-pointer convention of
> > mdiobus_get_phy().
> >
> > Patch 3 adds the OF reconfiguration notifier. It supports fixed-address
> > PHYs and generic MDIO devices, scanned PHY addresses, and Ethernet PHY
> > packages. It also preflights overlay removal and rejects removal of
> > attached or in-flight PHYs before their firmware nodes can disappear.
>
> This is a lot of complexity which i think should be avoided by just
> getting the bootloader to put the correct nodes in DT.

This should all be generic OF_DYNAMIC support for MDIO, so the
changes shouldn't really be tied to a specific PHY driver in any case.

> If this was a hat on top of a SBC, with an EEPROM indicating what the
> hat was, then maybe DT overlays would make sense. But from what you
> have said, this is a fixed PCB design, nothing hot/cold plugable.

Some H616/H618 boards have the ethernet port on an expansion board:
http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/2W-expansion-board.html

>
>      Andrew
>

> > If this was a hat on top of a SBC, with an EEPROM indicating what the
> > hat was, then maybe DT overlays would make sense. But from what you
> > have said, this is a fixed PCB design, nothing hot/cold plugable.
> 
> Some H616/H618 boards have the ethernet port on an expansion board:
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/2W-expansion-board.html

I don't see a list of pins which go across the connector. Does the
MDIO bus go to the expansion board? Is the PHY on the expansion
board. It all looks passive to me.

	Andrew

On Tue, Aug 4, 2026 at 6:54 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > If this was a hat on top of a SBC, with an EEPROM indicating what the
> > > hat was, then maybe DT overlays would make sense. But from what you
> > > have said, this is a fixed PCB design, nothing hot/cold plugable.
> >
> > Some H616/H618 boards have the ethernet port on an expansion board:
> > http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/2W-expansion-board.html
>
> I don't see a list of pins which go across the connector. Does the
> MDIO bus go to the expansion board? Is the PHY on the expansion
> board. It all looks passive to me.

Pins are listed under "24Pin expansion board interface pin description":
https://orangepi.net/wp-content/uploads/2023/10/OrangePi_Zero2w_H618_User-Manual_v1.1.pdf

I think it's just the connector part that's on the expansion board?

>
>         Andrew

On Tue, Aug 04, 2026 at 09:10:30AM -0600, James Hilliard wrote:
> On Tue, Aug 4, 2026 at 6:54 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > > > If this was a hat on top of a SBC, with an EEPROM indicating what the
> > > > hat was, then maybe DT overlays would make sense. But from what you
> > > > have said, this is a fixed PCB design, nothing hot/cold plugable.
> > >
> > > Some H616/H618 boards have the ethernet port on an expansion board:
> > > http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/2W-expansion-board.html
> >
> > I don't see a list of pins which go across the connector. Does the
> > MDIO bus go to the expansion board? Is the PHY on the expansion
> > board. It all looks passive to me.
> 
> Pins are listed under "24Pin expansion board interface pin description":
> https://orangepi.net/wp-content/uploads/2023/10/OrangePi_Zero2w_H618_User-Manual_v1.1.pdf

So just the lines after the PHY, basically the UTP lines without the
twist.

So please stop wasting my time by making invalid points.

   Andrew

On Tue, Aug 4, 2026 at 12:57 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Tue, Aug 04, 2026 at 09:10:30AM -0600, James Hilliard wrote:
> > On Tue, Aug 4, 2026 at 6:54 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > > > If this was a hat on top of a SBC, with an EEPROM indicating what the
> > > > > hat was, then maybe DT overlays would make sense. But from what you
> > > > > have said, this is a fixed PCB design, nothing hot/cold plugable.
> > > >
> > > > Some H616/H618 boards have the ethernet port on an expansion board:
> > > > http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/2W-expansion-board.html
> > >
> > > I don't see a list of pins which go across the connector. Does the
> > > MDIO bus go to the expansion board? Is the PHY on the expansion
> > > board. It all looks passive to me.
> >
> > Pins are listed under "24Pin expansion board interface pin description":
> > https://orangepi.net/wp-content/uploads/2023/10/OrangePi_Zero2w_H618_User-Manual_v1.1.pdf
>
> So just the lines after the PHY, basically the UTP lines without the
> twist.
>
> So please stop wasting my time by making invalid points.

I'm confused how this is an invalid point.

Presumably one may want to use OF_DYNAMIC to dynamically
enable the PHY only when the expansion board is installed.

Whether or not the MDIO bus is wired to the expansion board or
physically integrated into the SoC doesn't seem like it would make
a difference in regards to whether or not one would want to dynamically
enable the PHY using OF_DYNAMIC as that decision would presumably
be made based on the actual configured hardware setup. If the PHY is
not physically connected to an ethernet port then presumably it should
remain disabled due to that being a non-functional hardware configuration.

Or am I missing something here?

>
>    Andrew