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

Carlo Szelinsky
2026-03-29T16:10:36Z

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.

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.

Carlo Szelinsky (3):
net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
net: pse-pd: prevent regulator cleanup from disabling unclaimed PSE
PIs
net: pse-pd: add lazy PSE control resolution for modular drivers

drivers/net/mdio/fwnode_mdio.c | 8 ++++--
drivers/net/pse-pd/pse_core.c | 49 ++++++++++++++++++++++++++++++++++
include/linux/pse-pd/pse.h | 6 +++++
net/ethtool/pse-pd.c | 4 +++
4 files changed, 65 insertions(+), 2 deletions(-)

--
2.43.0