Re: [PATCH RFC net-next 0/4] net: pse-pd: decouple controller lookup from MDIO probe

[Corey Leavitt]

Hi Kory,

Thanks for the pointer -- I had not seen Carlo's thread; I should have
searched lore before sending and will do so before v2. Adding Carlo on
cc.

Having read it end-to-end, my read of the state as of 2026-04-13 was
that the conversation had narrowed to two open directions: propagate
EPROBE_DEFER further up into phylink/MAC probe (Andrew/Russell), or
resolve psec at PSE controller register time (your msg on 9 Apr,
"save the phandle ... then at PSE register time look for each PHY and
try to resolve every unresolved phandle"). Nothing concrete had been
posted for either.

This RFC implements the second direction. pse_core publishes a
BLOCKING_NOTIFIER chain with REGISTERED / UNREGISTERED events,
phy_device subscribes, and psec ownership moves from fwnode_mdio probe
into the notifier handler. Concretely with respect to points raised in
the earlier thread:

  - fwnode_mdio loses PSE awareness entirely, so the MDIO bus scan no
    longer sees -EPROBE_DEFER from PSE lookup. Consistent with
    Andrew's point that bus and device lifecycles are separate.

  - psec is acquired at PSE register time, before
    regulator_late_cleanup (30s) can run. Carlo's admin_state_synced
    guard (his patch 1) therefore isn't needed in this model. psec
    resolution happens eagerly on the REGISTERED event rather than
    lazily on first ethtool access, so his patch 2 is also not needed.
    And because fwnode_mdio no longer looks up PSE at all, the
    non-fatal EPROBE_DEFER handling there (patch 3) drops out. This
    series is a different architectural shape, not an increment on
    his v2.

  - Oleksij's concern about lazy resolution dropping UAPI
    notifications is addressed: the notifier fires at register time,
    so boot-time observer semantics are preserved.

  - One caveat I already owe a fix for in v2: the attach helper in
    phy_device currently treats every error from of_pse_control_get()
    as retry-on-notifier, including non-transient ones. Carlo's v2
    patch 3 was careful to differentiate -EPROBE_DEFER from bad-DT
    errors at the fwnode_mdio lookup site (which matches his msg 1
    concern about catching broken bindings at boot rather than
    silently later). I need to preserve that discrimination at the
    notifier-handler site -- phydev_warn() on anything other than
    -EPROBE_DEFER. Trivial, but worth flagging.

  - The DSA genphy force-bind sequence Carlo hit
    (phy_attach_direct -> device_bind_driver -> deferred retry
    skipped) does not apply, because psec attachment is not tied to
    phy_probe.

  - Patch 1 of this series scopes the regulator handle held by
    pse_control to its own kref lifetime, fixing a latent
    dangling-handle sequence that the notifier unregister path makes
    reachable. This is a separate regulator-lifetime bug from the one
    Carlo's patch 1 addresses.

Validated end-to-end on a Cudy C200P (MT7621 DSA + i2c IP804AR as
module), with lockdep active, across the i2c driver unbind/rebind
cycle that triggers UNREGISTERED -> REGISTERED on the live system.
The cover letter has the full evidence.

I would welcome your view on whether this is the shape you had in
mind on 9 Apr, or whether the MDI-based binding you raised with
Maxime is the better endpoint and we should be reshaping around that.
Happy to keep this RFC as the scaffolding either way.

Carlo -- your debugging work on the DSA phy_attach_direct interaction
is what made it clear this kind of approach was needed; thanks for
laying that groundwork. Would value your thoughts on the tradeoffs.

Best regards,
Corey