Re: [PATCH 0/3] net: pse-pd: support module-based PSE controller drivers

Kory Maincent
2026-03-30T11:09:14Z

On Sun, 29 Mar 2026 18:10:11 +0200
Carlo Szelinsky <github@szelinsky.de> wrote:

> When a PSE controller driver is built as a module, it may not be probed
> yet when PHYs are registered on the MDIO bus. This causes
> of_pse_control_get() to return -EPROBE_DEFER, destroying the PHY device.
> Later, regulator_late_cleanup disables the unclaimed PSE regulators,
> permanently killing PoE.

That's a good idea. I still think that one day I will remove registering
a regulator for every PIs as it only brings pain and fixups, but well until
then lets continue dealing with it.

You forgot net-next in the patch subject.

> This series fixes the issue in three steps:
>
> 1. Treat -EPROBE_DEFER as non-fatal during PHY registration, allowing
> the PHY to register with psec=NULL.
>
> 2. Add an admin_state_synced flag to pse_pi so that pse_pi_is_enabled()
> reports unclaimed PIs as disabled, preventing regulator_late_cleanup
> from shutting them down. The existing dual-path behavior (software-
> tracked vs. hardware-queried state) is preserved for claimed PIs.
>
> 3. Add pse_control_try_resolve() for lazy PSE control resolution on
> first ethtool access, serialized by RTNL.
>
> This is tested on my setup, but I am not fully sure if this is the right
> approach to solve this problem. I would love to get feedback from the
> maintainers on whether the overall design direction makes sense, or if
> there is a better way to handle the deferred PSE control acquisition.

You approach seems good to me.

--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering