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

[Kory Maincent <kory.maincent@bootlin.com>]

On Thu, 23 Apr 2026 09:48:53 +0000
Corey Leavitt <corey@leavitt.info> wrote:

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

This seems to provide a solution to all our problems, and it is well designed.
Carlo, it would be nice if you could test it on your side.

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

After a second thought, MDI-based binding is currently not in the pipe and we
should solve this without it for now.

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com