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.

This is generic OF_DYNAMIC support for MDIO buses. It contains no
Allwinner H616 or X-Powers AC200/AC300-specific behavior and does not
depend on either platform; H616 hardware was used only as the runtime
test platform.

Patch 1 fixes an existing lifetime bug exposed while auditing those races:
PHY attach and detach paths cache the MDIO bus but read its owner after
dropping their PHY device reference. Cache the owner before that lifetime
boundary.

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

Patch 3 serializes MDIO device-map changes, reserves addresses while
registration is in progress, publishes devices only after registration
completes, and coordinates scans, attachment, removal and bus teardown.
Firmware removal is exclusive with registration, scanning and other
firmware changes. Map readers use RCU to acquire device references;
mdiobus_get_phy() and the PHY iterators now return referenced PHYs, and all
in-tree callers release or retain those references explicitly. Removed PHY
generations can therefore be reclaimed when their actual users finish,
without removing dynamic PHY deletion or accumulating retired objects until
bus teardown. Attachment waits for another task's pending publication and
defers same-task recursive attachment.

Patch 4 adds the OF reconfiguration notifier. It supports fixed-address
PHYs and generic MDIO devices, scanned PHY addresses, and Ethernet PHY
packages. It preflights overlay removal before firmware nodes disappear
and refuses removal of attached or in-flight PHYs, including while another
MDIO map operation is still completing.

Strict checkpatch reports only its expected MAINTAINERS warning for the two
required lookup-ownership updates in the obsolete AX88796 driver. Changed
objects were build-tested with W=1 using x86_64 allmodconfig under GCC,
arm64 defconfig under LLVM, native MIPS and SPARC configurations for
architecture-specific callers, and minimal arm64 configurations covering
CONFIG_OF_DYNAMIC=n and CONFIG_OF_DYNAMIC=y with CONFIG_OF_OVERLAY=n. No
new compiler warning was emitted.

Runtime testing used an Allwinner H616 board with AC300, booted from SD. A
forced-ID test PHY completed 700 notifier-driven add/remove/re-add cycles.
Every cycle raced standalone attachment against the interval between
device_add() visibility and MDIO-map publication, held a referenced lookup
across removal, verified that no core reference remained, released the last
reference and re-added the same address. A generic MDIO device completed 150
add/remove cycles. Removal of the attached AC300 PHY was rejected while its
driver, carrier and traffic remained active. Testing also covered rejection
of an out-of-range fixed address, removal of an unrelated non-MDIO overlay,
20 complete MAC/MDIO teardown and recreation cycles, another PHY and generic
MDIO stress run after bus recreation, and bidirectional link traffic. No
refcount, RCU, use-after-free or lock warning occurred.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
Changes in v4:
- make PHY map lookups reference-counted and RCU-protected
- update every in-tree mdiobus_get_phy() and PHY iterator caller for the
  referenced lookup contract
- reclaim dynamically removed PHY generations after their users release
  them instead of retaining every generation until bus teardown
- wait for concurrent map publication before attaching a PHY and defer
  same-task recursive attachment
- handle a missing VSC8584 base PHY without dereferencing NULL
- use RCU-safe map access while checking a dynamic removal scope
- Link to v3: https://patch.msgid.link/20260805-submit-mdio-of-dynamic-v2-v3-0-16f3cc893b0e@gmail.com

Changes in v3:
- add a preparatory fix for MDIO bus-owner lifetime handling
- make teardown take a device reference and honor removal ownership
- use one checked callback for normal and dynamic internal removal
- publish map entries only after device registration completes
- route the remaining direct map reader through mdiobus_get_phy()
- retire only PHY devices which have a borrowed-pointer lookup API
- make firmware removal exclusive with registration, scanning and other
  firmware changes
- preserve existing error handling while propagating package population
  conflicts
- allow global overlay removal to ignore unrelated nodes and absent MDIO
  buses
- annotate the recursive notifier lock owner accesses for KCSAN
- avoid an OF/MDIO lock inversion during overlay preflight
- refuse overlay removal while another MDIO map change is active
- propagate removal-transaction conflicts from the OF notifier
- do not treat malformed fixed addresses as addressless PHYs
- rebase onto current net-next
- Link to v2: https://patch.msgid.link/20260803-submit-mdio-of-dynamic-v2-v2-0-f8841f3124d7@gmail.com

Changes in 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

To: Andrew Lunn <andrew@lunn.ch>
To: Heiner Kallweit <hkallweit1@gmail.com>
To: Russell King <linux@armlinux.org.uk>
To: "David S. Miller" <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Florian Fainelli <f.fainelli@gmail.com>
To: Richard Cochran <richardcochran@gmail.com>
To: Rob Herring <robh@kernel.org>
To: Saravana Kannan <saravanak@kernel.org>
To: Florian Fainelli <florian.fainelli@broadcom.com>
To: Jonas Gorski <jonas.gorski@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>
To: Ciprian Regus <ciprian.regus@analog.com>
To: Andreas Larsson <andreas@gaisler.com>
To: Mark Einon <mark.einon@gmail.com>
To: Iyappan Subramanian <iyappan@os.amperecomputing.com>
To: Keyur Chudgar <keyur@os.amperecomputing.com>
To: Michael Chan <michael.chan@broadcom.com>
To: Rafał Miłecki <rafal@milecki.pl>
To: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
To: Doug Berger <opendmb@gmail.com>
To: Pavan Chebbi <pavan.chebbi@broadcom.com>
To: Théo Lebrun <theo.lebrun@bootlin.com>
To: Conor Dooley <conor.dooley@microchip.com>
To: Wei Fang <wei.fang@nxp.com>
To: Frank Li <frank.li@nxp.com>
To: Shenwei Wang <shenwei.wang@nxp.com>
To: Jijie Shao <shaojijie@huawei.com>
To: Jian Shen <shenjian15@huawei.com>
To: Bryan Whitehead <bryan.whitehead@microchip.com>
To: UNGLinuxDriver@microchip.com
To: Vladimir Zapolskiy <vz@mleia.com>
To: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
To: Parthiban Veerasooran <parthiban.veerasooran@microchip.com>
To: Timur Tabi <timur@kernel.org>
To: nic_swsd@realtek.com
To: Byungho An <bh74.an@samsung.com>
To: Steve Glendinning <steve.glendinning@shawell.net>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Maxime Coquelin <mcoquelin.stm32@gmail.com>
To: Alexandre Torgue <alexandre.torgue@foss.st.com>
To: FUJITA Tomonori <fujita.tomonori@gmail.com>
To: Siddharth Vadapalli <s-vadapalli@ti.com>
To: Roger Quadros <rogerq@kernel.org>
To: Jiawen Wu <jiawenwu@trustnetic.com>
To: Mengyuan Lou <mengyuanlou@net-swift.com>
To: Thangaraj Samynathan <Thangaraj.S@microchip.com>
To: Sebastian Reichel <sre@kernel.org>
To: Simon Horman <horms@kernel.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-omap@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-pm@vger.kernel.org

---
James Hilliard (4):
      net: phy: cache MDIO bus owner before dropping PHY reference
      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/dsa/b53/b53_common.c                   |   9 +-
 drivers/net/ethernet/8390/ax88796.c                |   2 +
 drivers/net/ethernet/adi/adin1140.c                |   6 +-
 drivers/net/ethernet/aeroflex/greth.c              |   2 +
 drivers/net/ethernet/agere/et131x.c                |  10 +-
 drivers/net/ethernet/amd/au1000_eth.c              |  27 +-
 drivers/net/ethernet/apm/xgene-v2/mdio.c           |   8 +-
 drivers/net/ethernet/broadcom/b44.c                |   6 +
 drivers/net/ethernet/broadcom/bgmac-bcma.c         |   1 +
 drivers/net/ethernet/broadcom/genet/bcmmii.c       |   4 +
 drivers/net/ethernet/broadcom/sb1250-mac.c         |   8 +-
 drivers/net/ethernet/broadcom/tg3.c                |  32 +-
 drivers/net/ethernet/broadcom/tg3.h                |   1 +
 drivers/net/ethernet/cadence/macb_main.c           |   1 +
 drivers/net/ethernet/engleder/tsnep_main.c         |   4 +
 drivers/net/ethernet/ethoc.c                       |  14 +-
 drivers/net/ethernet/faraday/ftgmac100.c           |   8 +-
 drivers/net/ethernet/freescale/fec_main.c          |  14 +-
 drivers/net/ethernet/hisilicon/hibmcge/hbg_mdio.c  |   8 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c    |  10 +-
 drivers/net/ethernet/lantiq_etop.c                 |   8 +-
 .../ethernet/mellanox/mlxbf_gige/mlxbf_gige_main.c |   2 +
 drivers/net/ethernet/microchip/lan743x_main.c      |   1 +
 drivers/net/ethernet/nxp/lpc_eth.c                 |  10 +-
 drivers/net/ethernet/oa_tc6.c                      |   3 +
 drivers/net/ethernet/qualcomm/emac/emac-phy.c      |   7 -
 drivers/net/ethernet/rdc/r6040.c                   |  10 +-
 drivers/net/ethernet/realtek/r8169_main.c          |  15 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_mdio.c    |   1 +
 drivers/net/ethernet/smsc/smsc911x.c               |   6 +-
 drivers/net/ethernet/smsc/smsc9420.c               |  10 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |   1 +
 drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c  |   2 +
 drivers/net/ethernet/tehuti/tn40_phy.c             |   5 +-
 drivers/net/ethernet/ti/davinci_emac.c             |  20 +-
 drivers/net/ethernet/toshiba/tc35815.c             |   8 +-
 drivers/net/ethernet/wangxun/ngbe/ngbe_mdio.c      |   8 +
 drivers/net/ethernet/wangxun/txgbe/txgbe_phy.c     |   8 +
 drivers/net/mdio/of_mdio.c                         | 514 +++++++++++++++++++--
 drivers/net/phy/mdio_bus.c                         |  46 +-
 drivers/net/phy/mdio_bus_provider.c                | 141 ++++--
 drivers/net/phy/mdio_device.c                      | 238 +++++++++-
 drivers/net/phy/mscc/mscc_ptp.c                    |  50 +-
 drivers/net/phy/phy_device.c                       | 151 ++++--
 drivers/net/phy/phylib-internal.h                  |   4 +-
 drivers/net/usb/asix_devices.c                     |   4 +
 drivers/net/usb/lan78xx.c                          |   7 +-
 drivers/net/usb/smsc95xx.c                         |   2 +
 drivers/power/reset/linkstation-poweroff.c         |   1 +
 include/linux/mdio.h                               |   4 +-
 include/linux/phy.h                                |  34 +-
 net/dsa/user.c                                     |  12 +-
 52 files changed, 1239 insertions(+), 269 deletions(-)
---
base-commit: a23b36233d4103def55dc8cf65698106d0bd1e62
change-id: 20260803-submit-mdio-of-dynamic-v2-90560ca159b9

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

On Thu, Aug 06, 2026 at 09:54:19PM -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.

Please make the bootloader work around the issues, and drop this
patchset.

	Andrew

On Fri, Aug 7, 2026 at 7:16 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Thu, Aug 06, 2026 at 09:54:19PM -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.
>
> Please make the bootloader work around the issues, and drop this
> patchset.

This is just fixing OF_DYNAMIC for mdio now, it's no longer used
by the AC200/AC300 PHY patches anymore.

>
>         Andrew

On Fri, Aug 07, 2026 at 08:59:47AM -0600, James Hilliard wrote:
> On Fri, Aug 7, 2026 at 7:16 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > On Thu, Aug 06, 2026 at 09:54:19PM -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.
> >
> > Please make the bootloader work around the issues, and drop this
> > patchset.
> 
> This is just fixing OF_DYNAMIC for mdio now, it's no longer used
> by the AC200/AC300 PHY patches anymore.

Meaning it has no users?

We don't add code unless it has a user. To do so pointlessly adds
Maintenance burden.

   Andrew

On Fri, Aug 7, 2026 at 9:10 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Fri, Aug 07, 2026 at 08:59:47AM -0600, James Hilliard wrote:
> > On Fri, Aug 7, 2026 at 7:16 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > On Thu, Aug 06, 2026 at 09:54:19PM -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.
> > >
> > > Please make the bootloader work around the issues, and drop this
> > > patchset.
> >
> > This is just fixing OF_DYNAMIC for mdio now, it's no longer used
> > by the AC200/AC300 PHY patches anymore.
>
> Meaning it has no users?

I think OF_OVERLAY depends on OF_DYNAMIC?

I guess it can also be used like this for live dt modification:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/Documentation/devicetree/configfs-overlays.txt?h=topic/overlays

> We don't add code unless it has a user. To do so pointlessly adds
> Maintenance burden.

AFAIU the patches other than the last one are still relevant regardless
since they are fixing a bunch of generic mdio safety issues in code that
has users since MDIO maps already change at runtime through non-OF
paths(i.e. SFP insertion/removal).

>
>    Andrew

> I guess it can also be used like this for live dt modification:

A guess is not good enough. Give us a concrete, in kernel use cases.

> AFAIU the patches other than the last one are still relevant regardless
> since they are fixing a bunch of generic mdio safety issues in code that
> has users since MDIO maps already change at runtime through non-OF
> paths(i.e. SFP insertion/removal).

Fixes are fine, but please word the commit message around real things
that can happen in todays kernel. If it is a race condition, such bug
reports often show the call stack of the two racing threads.

Do you have a board with an SFP cage? Can you test your change.

   Andrew

On Fri, Aug 7, 2026 at 11:15 AM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > I guess it can also be used like this for live dt modification:
>
> A guess is not good enough. Give us a concrete, in kernel use cases.

I searched the current tree for callers of the OF changeset and
overlay APIs and for OF reconfiguration notifiers. I did not find a
current in-tree path which adds or removes a child below an already
registered MDIO bus.

There are concrete existing kernel mechanisms and DT descriptions which
could become users. lan966x_pci already applies an embedded DT overlay
from a PCI driver, and the FPGA region code already coordinates
in-kernel overlay application and removal. Mainline also ships overlays
for TI J7 Ethernet expansion cards, NXP LS1028A QDS cards, and other
boards which add PHY nodes below existing MDIO controllers.

Those overlays are currently normally applied before Linux starts, so
they are not present-day live MDIO users. If an in-kernel line-card,
mezzanine, or FPGA manager applies one of these topologies after
detecting hardware, adding or removing the PHY children below the
persistent MDIO bus is exactly the operation this notifier supports.

Likewise, a driver which identifies a PHY or retimer package from an
EEPROM, NVMEM, or firmware and then enables the matching child nodes
would use the same mechanism. The kernel already uses OF changesets for
analogous late hardware selection in other subsystems.

> > AFAIU the patches other than the last one are still relevant regardless
> > since they are fixing a bunch of generic mdio safety issues in code that
> > has users since MDIO maps already change at runtime through non-OF
> > paths(i.e. SFP insertion/removal).
>
> Fixes are fine, but please word the commit message around real things
> that can happen in todays kernel. If it is a race condition, such bug
> reports often show the call stack of the two racing threads.

After auditing those paths, I would qualify that statement. SFP, AMD
XGBE, and Airoha all modify the MDIO map at runtime, but their known
paths use subsystem-local lifecycle ordering to serialize removal and
attachment. I do not currently have evidence of a reachable race in
those particular paths.

They do demonstrate that the MDIO map cannot be treated as immutable.
Its safety currently depends on every producer and consumer arranging
compatible external serialization, while the MDIO APIs neither express
nor enforce that lifetime contract.

I found more concrete current interleavings elsewhere. For example,
PXA168 can scan and attach from ndo_open while its remove path
unregisters and frees the MDIO bus before unregistering the netdev.
BCM SF2 looks up and removes PHYs belonging to another MDIO provider and
can observe that provider while registration and OF population are
still in progress. GENET ACPI and Davinci also cross lookup, reference,
and attachment lifetime boundaries.

> Do you have a board with an SFP cage? Can you test your change.

I do not currently have an SFP-capable board.

>
>    Andrew

On Fri, Aug 07, 2026 at 12:48:43PM -0600, James Hilliard wrote:
> On Fri, Aug 7, 2026 at 11:15 AM Andrew Lunn <andrew@lunn.ch> wrote:
> >
> > > I guess it can also be used like this for live dt modification:
> >
> > A guess is not good enough. Give us a concrete, in kernel use cases.
> 
> I searched the current tree for callers of the OF changeset and
> overlay APIs and for OF reconfiguration notifiers. I did not find a
> current in-tree path which adds or removes a child below an already
> registered MDIO bus.

So lets wait for a real user to come along.

	Andrew

On Fri, Aug 7, 2026 at 1:16 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> On Fri, Aug 07, 2026 at 12:48:43PM -0600, James Hilliard wrote:
> > On Fri, Aug 7, 2026 at 11:15 AM Andrew Lunn <andrew@lunn.ch> wrote:
> > >
> > > > I guess it can also be used like this for live dt modification:
> > >
> > > A guess is not good enough. Give us a concrete, in kernel use cases.
> >
> > I searched the current tree for callers of the OF changeset and
> > overlay APIs and for OF reconfiguration notifiers. I did not find a
> > current in-tree path which adds or removes a child below an already
> > registered MDIO bus.
>
> So lets wait for a real user to come along.

So should I just drop the final "net: mdio: support dynamic OF device
changes" patch and keep the MDIO hardening patches?

>
>         Andrew

> So should I just drop the final "net: mdio: support dynamic OF device
> changes" patch and keep the MDIO hardening patches?

If you can provide suitable commit messages which indicate you are
fixing real problems. We get way too many AI generated patches which
fix theoretical issues which nobody ever encounters. That is wasting a
lot of Reviewer time, preventing me and other reviewers from helping
developers doing real work adding new hardware support, or fixing bugs
which both them. Those are the people which i prefer to help, not the
newbies using AI and have never taken Operating Systems 101.

       Andrew

On Fri, Aug 7, 2026 at 2:26 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > So should I just drop the final "net: mdio: support dynamic OF device
> > changes" patch and keep the MDIO hardening patches?
>
> If you can provide suitable commit messages which indicate you are
> fixing real problems.

I guess I'm just trying to figure out if mdio map hotplug safety is something
that's considered to be a real issue or not when most existing drivers tend
to sidestep the safety issues.

If OF_DYNAMIC is something that will eventually be supported for mdio
then this is something that will be needed eventually anyways.

> We get way too many AI generated patches which
> fix theoretical issues which nobody ever encounters.

I did hit it in practice with my original series so I used that for validating
the fixes, however my later revisions use a different design that uses
phy_package instead of a separate ctrl driver which avoids the need
for OF_DYNAMIC support for mdio.

> That is wasting a
> lot of Reviewer time, preventing me and other reviewers from helping
> developers doing real work adding new hardware support, or fixing bugs
> which both them.

So to me it seems like hotplug safety for the mdio api is mostly an API
footgun at the moment if anything for existing drivers, so I figured since
I already had done a lot of the work refactoring it to be safer that I should
then submit that upstream anyways.

Most of my embedded Linux designs heavily incorporate different
hardware autodetection/autoconfiguration techniques which is probably
one reason I like the idea of making more use of the OF_DYNAMIC
feature where feasible for the kernel.

> Those are the people which i prefer to help, not the
> newbies using AI and have never taken Operating Systems 101.

I'm certainly not a newbie[0] but I have been using AI workflows quite
extensively as AI greatly increases the speed at which I can iterate on
patches as well as significantly increasing code quality.

In general I run all my patches through many rounds of AI review before
submitting as well to try and reduce the amount of bugs and such in
addition to my own manual review.

Whether or not to preemptively refactor code like this mdio code is kind
of a personal preference however so it's not always clear to me whether
or not it's something I should be submitting fixes for upstream.

Maybe incorporating AI tools more in your own workflows can help with
keeping maintainer workload manageable? I certainly use AI a lot when
reviewing code from other developers.

[0] https://lore.kernel.org/all/?q=james.hilliard1@gmail.com

>
>        Andrew
>