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

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

[Carlo Szelinsky]

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

[PATCH 1/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Carlo Szelinsky]

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
fwnode_find_pse_control() -> of_pse_control_get() to return
-EPROBE_DEFER, which currently propagates up and destroys the PHY
device.

Treat -EPROBE_DEFER as non-fatal, allowing the PHY to register
successfully with psec=NULL. The PSE control can be resolved lazily
when first needed.

Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
---
 drivers/net/mdio/fwnode_mdio.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
index ba7091518265..2a03b3fc41e6 100644
--- a/drivers/net/mdio/fwnode_mdio.c
+++ b/drivers/net/mdio/fwnode_mdio.c
@@ -161,8 +161,12 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 
 	psec = fwnode_find_pse_control(child, phy);
 	if (IS_ERR(psec)) {
-		rc = PTR_ERR(psec);
-		goto unregister_phy;
+		if (PTR_ERR(psec) == -EPROBE_DEFER) {
+			psec = NULL;
+		} else {
+			rc = PTR_ERR(psec);
+			goto unregister_phy;
+		}
 	}
 
 	phy->psec = psec;
-- 
2.43.0

Re: [PATCH 1/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Kory Maincent]

On Sun, 29 Mar 2026 18:10:12 +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
> fwnode_find_pse_control() -> of_pse_control_get() to return
> -EPROBE_DEFER, which currently propagates up and destroys the PHY
> device.
> 
> Treat -EPROBE_DEFER as non-fatal, allowing the PHY to register
> successfully with psec=NULL. The PSE control can be resolved lazily
> when first needed.

I think you should move this patch last on the series because it changes the
probe behavior, and needs the other patches to work properly on the lazy resolve
case.

Acked-by: Kory Maincent <kory.maincent@bootlin.com>

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

[PATCH 2/3] net: pse-pd: prevent regulator cleanup from disabling unclaimed PSE PIs

[Carlo Szelinsky]

When a PSE controller driver is loaded as a module, its PI regulators
are registered before any consumer (PHY) acquires the corresponding PSE
control via of_pse_control_get(). The regulator framework's
regulator_late_cleanup then calls pse_pi_is_enabled(), which queries
hardware and sees the PI is enabled. Since no consumer holds it
(use_count == 0), regulator_late_cleanup disables it, killing PoE.

Add an admin_state_synced flag to struct pse_pi that is set when a
consumer first acquires the PSE control and syncs admin_state_enabled
from hardware. In pse_pi_is_enabled(), report unsynchronized PIs as
disabled so regulator_late_cleanup skips them.

This preserves the existing dual-path behavior: software-tracked state
for software-controlled power domains, and hardware queries for
hardware-controlled domains. The admin_state_synced flag is only false
before the first consumer acquisition, which is the exact window where
regulator_late_cleanup could incorrectly disable the PI.

Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
---
 drivers/net/pse-pd/pse_core.c | 13 +++++++++++++
 include/linux/pse-pd/pse.h    |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 3beaaaeec9e1..566b07c336bf 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -421,6 +421,18 @@ static int pse_pi_is_enabled(struct regulator_dev *rdev)
 
 	id = rdev_get_id(rdev);
 	mutex_lock(&pcdev->lock);
+
+	/*
+	 * Report the PI as disabled until a consumer has acquired it
+	 * and synced admin_state_enabled from hardware. This prevents
+	 * regulator_late_cleanup from disabling unclaimed PSE PIs
+	 * when the PSE controller driver loads as a module.
+	 */
+	if (!pcdev->pi[id].admin_state_synced) {
+		ret = 0;
+		goto out;
+	}
+
 	if (pse_pw_d_is_sw_pw_control(pcdev, pcdev->pi[id].pw_d)) {
 		ret = pcdev->pi[id].admin_state_enabled;
 		goto out;
@@ -1431,6 +1443,7 @@ pse_control_get_internal(struct pse_controller_dev *pcdev, unsigned int index,
 		goto free_psec;
 
 	pcdev->pi[index].admin_state_enabled = ret;
+	pcdev->pi[index].admin_state_synced = true;
 	psec->ps = devm_regulator_get_exclusive(pcdev->dev,
 						rdev_get_name(pcdev->pi[index].rdev));
 	if (IS_ERR(psec->ps)) {
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 4e5696cfade7..b86cce740551 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -260,6 +260,7 @@ struct pse_pi {
 	struct device_node *np;
 	struct regulator_dev *rdev;
 	bool admin_state_enabled;
+	bool admin_state_synced;
 	struct pse_power_domain *pw_d;
 	int prio;
 	bool isr_pd_detected;
-- 
2.43.0

Re: [PATCH 2/3] net: pse-pd: prevent regulator cleanup from disabling unclaimed PSE PIs

[Kory Maincent]

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

> When a PSE controller driver is loaded as a module, its PI regulators
> are registered before any consumer (PHY) acquires the corresponding PSE
> control via of_pse_control_get(). The regulator framework's
> regulator_late_cleanup then calls pse_pi_is_enabled(), which queries
> hardware and sees the PI is enabled. Since no consumer holds it
> (use_count == 0), regulator_late_cleanup disables it, killing PoE.
> 
> Add an admin_state_synced flag to struct pse_pi that is set when a
> consumer first acquires the PSE control and syncs admin_state_enabled
> from hardware. In pse_pi_is_enabled(), report unsynchronized PIs as
> disabled so regulator_late_cleanup skips them.
> 
> This preserves the existing dual-path behavior: software-tracked state
> for software-controlled power domains, and hardware queries for
> hardware-controlled domains. The admin_state_synced flag is only false
> before the first consumer acquisition, which is the exact window where
> regulator_late_cleanup could incorrectly disable the PI.

Acked-by: Kory Maincent <kory.maincent@bootlin.com>

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

[PATCH 3/3] net: pse-pd: add lazy PSE control resolution for modular drivers

[Carlo Szelinsky]

When a PSE controller driver is built as a module and was not probed
during PHY registration, the PHY ends up with psec=NULL. Add
pse_control_try_resolve() to lazily resolve the PSE control on first
ethtool access.

Call pse_control_try_resolve() in both the GET and SET ethtool PSE
handlers, before checking phydev->psec. The function is serialized by
RTNL (enforced via ASSERT_RTNL), preventing concurrent callers from
double-allocating a PSE control.

If resolution fails (e.g. the module still has not loaded), a debug
message is emitted via phydev_dbg() and the handler falls through to
the existing "No PSE is attached" error path.

Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
---
 drivers/net/pse-pd/pse_core.c | 36 +++++++++++++++++++++++++++++++++++
 include/linux/pse-pd/pse.h    |  5 +++++
 net/ethtool/pse-pd.c          |  4 ++++
 3 files changed, 45 insertions(+)

diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 566b07c336bf..390df23a991c 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -1569,6 +1569,42 @@ struct pse_control *of_pse_control_get(struct device_node *node,
 }
 EXPORT_SYMBOL_GPL(of_pse_control_get);
 
+/**
+ * pse_control_try_resolve - attempt to resolve a deferred PSE control
+ * @phydev: the PHY device whose PSE control may need resolution
+ *
+ * When a PSE controller driver is built as a module, it may not have
+ * probed when PHYs were registered on the MDIO bus. This function
+ * retries PSE control acquisition and should be called before
+ * accessing phydev->psec in ethtool handlers.
+ *
+ * Context: Caller must hold RTNL.
+ */
+void pse_control_try_resolve(struct phy_device *phydev)
+{
+	struct device_node *np;
+	struct pse_control *psec;
+
+	ASSERT_RTNL();
+
+	if (phydev->psec)
+		return;
+
+	np = phydev->mdio.dev.of_node;
+	if (!np || !of_property_present(np, "pses"))
+		return;
+
+	psec = of_pse_control_get(np, phydev);
+	if (IS_ERR(psec)) {
+		phydev_dbg(phydev, "failed to resolve PSE control: %pe\n",
+			   psec);
+		return;
+	}
+
+	phydev->psec = psec;
+}
+EXPORT_SYMBOL_GPL(pse_control_try_resolve);
+
 /**
  * pse_get_sw_admin_state - Convert the software admin state to c33 or podl
  *			    admin state value used in the standard
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index b86cce740551..d2f9b7c1acdf 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -350,6 +350,7 @@ int devm_pse_irq_helper(struct pse_controller_dev *pcdev, int irq,
 struct pse_control *of_pse_control_get(struct device_node *node,
 				       struct phy_device *phydev);
 void pse_control_put(struct pse_control *psec);
+void pse_control_try_resolve(struct phy_device *phydev);
 
 int pse_ethtool_get_status(struct pse_control *psec,
 			   struct netlink_ext_ack *extack,
@@ -379,6 +380,10 @@ static inline void pse_control_put(struct pse_control *psec)
 {
 }
 
+static inline void pse_control_try_resolve(struct phy_device *phydev)
+{
+}
+
 static inline int pse_ethtool_get_status(struct pse_control *psec,
 					 struct netlink_ext_ack *extack,
 					 struct ethtool_pse_control_status *status)
diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index 2eb9bdc2dcb9..adffc230acd6 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -42,6 +42,8 @@ static int pse_get_pse_attributes(struct phy_device *phydev,
 		return -EOPNOTSUPP;
 	}
 
+	pse_control_try_resolve(phydev);
+
 	if (!phydev->psec) {
 		NL_SET_ERR_MSG(extack, "No PSE is attached");
 		return -EOPNOTSUPP;
@@ -249,6 +251,8 @@ ethnl_set_pse_validate(struct phy_device *phydev, struct genl_info *info)
 		return -EOPNOTSUPP;
 	}
 
+	pse_control_try_resolve(phydev);
+
 	if (!phydev->psec) {
 		NL_SET_ERR_MSG(info->extack, "No PSE is attached");
 		return -EOPNOTSUPP;
-- 
2.43.0

Re: [PATCH 3/3] net: pse-pd: add lazy PSE control resolution for modular drivers

[Kory Maincent]

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

> When a PSE controller driver is built as a module and was not probed
> during PHY registration, the PHY ends up with psec=NULL. Add
> pse_control_try_resolve() to lazily resolve the PSE control on first
> ethtool access.
> 
> Call pse_control_try_resolve() in both the GET and SET ethtool PSE
> handlers, before checking phydev->psec. The function is serialized by
> RTNL (enforced via ASSERT_RTNL), preventing concurrent callers from
> double-allocating a PSE control.
> 
> If resolution fails (e.g. the module still has not loaded), a debug
> message is emitted via phydev_dbg() and the handler falls through to
> the existing "No PSE is attached" error path.

Acked-by: Kory Maincent <kory.maincent@bootlin.com>

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

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

[Kory Maincent]

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
https://bootlin.com

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

[Carlo Szelinsky]

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

  2. Add pse_control_try_resolve() for lazy PSE control resolution on
     first ethtool access, serialized by RTNL.

  3. Treat -EPROBE_DEFER as non-fatal during PHY registration, allowing
     the PHY to register with psec=NULL. This is ordered last because it
     changes probe behavior and relies on patches 1 and 2 for correct
     lazy resolution.

Thanks to Kory Maincent for the review and feedback on v1.

Changes in v2:
  - Reordered patches: moved the EPROBE_DEFER patch last since it
    changes probe behavior and depends on the other two patches for
    correct lazy resolution (Kory Maincent)
  - Added net-next to subject prefix (Kory Maincent)
  - Collected Acked-by tags

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

 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(-)


base-commit: cf0d9080c6f795bc6be08babbffa29b62c06e9b0
--
2.43.0

[PATCH net-next v2 1/3] net: pse-pd: prevent regulator cleanup from disabling unclaimed PSE PIs

[Carlo Szelinsky]

When a PSE controller driver is loaded as a module, its PI regulators
are registered before any consumer (PHY) acquires the corresponding PSE
control via of_pse_control_get(). The regulator framework's
regulator_late_cleanup then calls pse_pi_is_enabled(), which queries
hardware and sees the PI is enabled. Since no consumer holds it
(use_count == 0), regulator_late_cleanup disables it, killing PoE.

Add an admin_state_synced flag to struct pse_pi that is set when a
consumer first acquires the PSE control and syncs admin_state_enabled
from hardware. In pse_pi_is_enabled(), report unsynchronized PIs as
disabled so regulator_late_cleanup skips them.

This preserves the existing dual-path behavior: software-tracked state
for software-controlled power domains, and hardware queries for
hardware-controlled domains. The admin_state_synced flag is only false
before the first consumer acquisition, which is the exact window where
regulator_late_cleanup could incorrectly disable the PI.

Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Acked-by: Kory Maincent <kory.maincent@bootlin.com>
---
 drivers/net/pse-pd/pse_core.c | 13 +++++++++++++
 include/linux/pse-pd/pse.h    |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 3beaaaeec9e1..566b07c336bf 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -421,6 +421,18 @@ static int pse_pi_is_enabled(struct regulator_dev *rdev)
 
 	id = rdev_get_id(rdev);
 	mutex_lock(&pcdev->lock);
+
+	/*
+	 * Report the PI as disabled until a consumer has acquired it
+	 * and synced admin_state_enabled from hardware. This prevents
+	 * regulator_late_cleanup from disabling unclaimed PSE PIs
+	 * when the PSE controller driver loads as a module.
+	 */
+	if (!pcdev->pi[id].admin_state_synced) {
+		ret = 0;
+		goto out;
+	}
+
 	if (pse_pw_d_is_sw_pw_control(pcdev, pcdev->pi[id].pw_d)) {
 		ret = pcdev->pi[id].admin_state_enabled;
 		goto out;
@@ -1431,6 +1443,7 @@ pse_control_get_internal(struct pse_controller_dev *pcdev, unsigned int index,
 		goto free_psec;
 
 	pcdev->pi[index].admin_state_enabled = ret;
+	pcdev->pi[index].admin_state_synced = true;
 	psec->ps = devm_regulator_get_exclusive(pcdev->dev,
 						rdev_get_name(pcdev->pi[index].rdev));
 	if (IS_ERR(psec->ps)) {
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index 4e5696cfade7..b86cce740551 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -260,6 +260,7 @@ struct pse_pi {
 	struct device_node *np;
 	struct regulator_dev *rdev;
 	bool admin_state_enabled;
+	bool admin_state_synced;
 	struct pse_power_domain *pw_d;
 	int prio;
 	bool isr_pd_detected;
-- 
2.43.0

Re: [PATCH net-next v2 1/3] net: pse-pd: prevent regulator cleanup from disabling unclaimed PSE PIs

[Jakub Kicinski]

On Mon, 30 Mar 2026 15:29:50 +0200 Carlo Szelinsky wrote:
> --- a/include/linux/pse-pd/pse.h
> +++ b/include/linux/pse-pd/pse.h
> @@ -260,6 +260,7 @@ struct pse_pi {
>  	struct device_node *np;
>  	struct regulator_dev *rdev;
>  	bool admin_state_enabled;
> +	bool admin_state_synced;
>  	struct pse_power_domain *pw_d;

new field is missing from the kdoc:

Warning: include/linux/pse-pd/pse.h:267 struct member 'admin_state_synced' not described in 'pse_pi'
-- 
pw-bot: cr

Re: [PATCH net-next v2 1/3] net: pse-pd: prevent regulator cleanup from disabling unclaimed PSE PIs

[Oleksij Rempel]

On Mon, Mar 30, 2026 at 03:29:50PM +0200, Carlo Szelinsky wrote:
> When a PSE controller driver is loaded as a module, its PI regulators
> are registered before any consumer (PHY) acquires the corresponding PSE
> control via of_pse_control_get(). The regulator framework's
> regulator_late_cleanup then calls pse_pi_is_enabled(), which queries
> hardware and sees the PI is enabled. Since no consumer holds it
> (use_count == 0), regulator_late_cleanup disables it, killing PoE.

Let's address the deferred probing issues first. The system shuts the
current for the ports, because ports are not tracked. And ports are not
tracked/claimed, because the first patch breaks it. Which introduces
additional safety, diagnostic and power budget allocation issues.

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH net-next v2 2/3] net: pse-pd: add lazy PSE control resolution for modular drivers

[Carlo Szelinsky]

When a PSE controller driver is built as a module and was not probed
during PHY registration, the PHY ends up with psec=NULL. Add
pse_control_try_resolve() to lazily resolve the PSE control on first
ethtool access.

Call pse_control_try_resolve() in both the GET and SET ethtool PSE
handlers, before checking phydev->psec. The function is serialized by
RTNL (enforced via ASSERT_RTNL), preventing concurrent callers from
double-allocating a PSE control.

If resolution fails (e.g. the module still has not loaded), a debug
message is emitted via phydev_dbg() and the handler falls through to
the existing "No PSE is attached" error path.

Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Acked-by: Kory Maincent <kory.maincent@bootlin.com>
---
 drivers/net/pse-pd/pse_core.c | 36 +++++++++++++++++++++++++++++++++++
 include/linux/pse-pd/pse.h    |  5 +++++
 net/ethtool/pse-pd.c          |  4 ++++
 3 files changed, 45 insertions(+)

diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
index 566b07c336bf..390df23a991c 100644
--- a/drivers/net/pse-pd/pse_core.c
+++ b/drivers/net/pse-pd/pse_core.c
@@ -1569,6 +1569,42 @@ struct pse_control *of_pse_control_get(struct device_node *node,
 }
 EXPORT_SYMBOL_GPL(of_pse_control_get);
 
+/**
+ * pse_control_try_resolve - attempt to resolve a deferred PSE control
+ * @phydev: the PHY device whose PSE control may need resolution
+ *
+ * When a PSE controller driver is built as a module, it may not have
+ * probed when PHYs were registered on the MDIO bus. This function
+ * retries PSE control acquisition and should be called before
+ * accessing phydev->psec in ethtool handlers.
+ *
+ * Context: Caller must hold RTNL.
+ */
+void pse_control_try_resolve(struct phy_device *phydev)
+{
+	struct device_node *np;
+	struct pse_control *psec;
+
+	ASSERT_RTNL();
+
+	if (phydev->psec)
+		return;
+
+	np = phydev->mdio.dev.of_node;
+	if (!np || !of_property_present(np, "pses"))
+		return;
+
+	psec = of_pse_control_get(np, phydev);
+	if (IS_ERR(psec)) {
+		phydev_dbg(phydev, "failed to resolve PSE control: %pe\n",
+			   psec);
+		return;
+	}
+
+	phydev->psec = psec;
+}
+EXPORT_SYMBOL_GPL(pse_control_try_resolve);
+
 /**
  * pse_get_sw_admin_state - Convert the software admin state to c33 or podl
  *			    admin state value used in the standard
diff --git a/include/linux/pse-pd/pse.h b/include/linux/pse-pd/pse.h
index b86cce740551..d2f9b7c1acdf 100644
--- a/include/linux/pse-pd/pse.h
+++ b/include/linux/pse-pd/pse.h
@@ -350,6 +350,7 @@ int devm_pse_irq_helper(struct pse_controller_dev *pcdev, int irq,
 struct pse_control *of_pse_control_get(struct device_node *node,
 				       struct phy_device *phydev);
 void pse_control_put(struct pse_control *psec);
+void pse_control_try_resolve(struct phy_device *phydev);
 
 int pse_ethtool_get_status(struct pse_control *psec,
 			   struct netlink_ext_ack *extack,
@@ -379,6 +380,10 @@ static inline void pse_control_put(struct pse_control *psec)
 {
 }
 
+static inline void pse_control_try_resolve(struct phy_device *phydev)
+{
+}
+
 static inline int pse_ethtool_get_status(struct pse_control *psec,
 					 struct netlink_ext_ack *extack,
 					 struct ethtool_pse_control_status *status)
diff --git a/net/ethtool/pse-pd.c b/net/ethtool/pse-pd.c
index 2eb9bdc2dcb9..adffc230acd6 100644
--- a/net/ethtool/pse-pd.c
+++ b/net/ethtool/pse-pd.c
@@ -42,6 +42,8 @@ static int pse_get_pse_attributes(struct phy_device *phydev,
 		return -EOPNOTSUPP;
 	}
 
+	pse_control_try_resolve(phydev);
+
 	if (!phydev->psec) {
 		NL_SET_ERR_MSG(extack, "No PSE is attached");
 		return -EOPNOTSUPP;
@@ -249,6 +251,8 @@ ethnl_set_pse_validate(struct phy_device *phydev, struct genl_info *info)
 		return -EOPNOTSUPP;
 	}
 
+	pse_control_try_resolve(phydev);
+
 	if (!phydev->psec) {
 		NL_SET_ERR_MSG(info->extack, "No PSE is attached");
 		return -EOPNOTSUPP;
-- 
2.43.0

[PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Carlo Szelinsky]

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
fwnode_find_pse_control() -> of_pse_control_get() to return
-EPROBE_DEFER, which currently propagates up and destroys the PHY
device.

Treat -EPROBE_DEFER as non-fatal, allowing the PHY to register
successfully with psec=NULL. The PSE control can be resolved lazily
when first needed.

Signed-off-by: Carlo Szelinsky <github@szelinsky.de>
Acked-by: Kory Maincent <kory.maincent@bootlin.com>
---
 drivers/net/mdio/fwnode_mdio.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
index ba7091518265..2a03b3fc41e6 100644
--- a/drivers/net/mdio/fwnode_mdio.c
+++ b/drivers/net/mdio/fwnode_mdio.c
@@ -161,8 +161,12 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
 
 	psec = fwnode_find_pse_control(child, phy);
 	if (IS_ERR(psec)) {
-		rc = PTR_ERR(psec);
-		goto unregister_phy;
+		if (PTR_ERR(psec) == -EPROBE_DEFER) {
+			psec = NULL;
+		} else {
+			rc = PTR_ERR(psec);
+			goto unregister_phy;
+		}
 	}
 
 	phy->psec = psec;
-- 
2.43.0

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Andrew Lunn]

> Treat -EPROBE_DEFER as non-fatal, allowing the PHY to register
> successfully with psec=NULL. The PSE control can be resolved lazily
> when first needed.

Is there a reason not to do lazily resolution all the time?

   Andrew

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Carlo Szelinsky]

Hi Andrew,

Thx for helping me! 
I thought of keeping the eager path so we still catch broken DT bindings
early at boot instead of silently failing later on first ethtool access.
But you're right, dropping it would simplify things quite a bit. Do you
think that trade-off is worth it? I will follow your lead. 

cheers Carlo

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Kory Maincent]

On Fri,  3 Apr 2026 15:31:11 +0200
Carlo Szelinsky <github@szelinsky.de> wrote:

> Hi Andrew,
> 
> Thx for helping me! 
> I thought of keeping the eager path so we still catch broken DT bindings
> early at boot instead of silently failing later on first ethtool access.
> But you're right, dropping it would simplify things quite a bit. Do you
> think that trade-off is worth it? I will follow your lead. 

On my side I thinks that's a good idea, and I don't see any issue with that for
now. Oleksij you introduced it here in the first place, is it ok for you?

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

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Oleksij Rempel]

Hi,

On Fri, Apr 03, 2026 at 03:38:49PM +0200, Kory Maincent wrote:
> On Fri,  3 Apr 2026 15:31:11 +0200
> Carlo Szelinsky <github@szelinsky.de> wrote:
> 
> > Hi Andrew,
> > 
> > Thx for helping me! 
> > I thought of keeping the eager path so we still catch broken DT bindings
> > early at boot instead of silently failing later on first ethtool access.
> > But you're right, dropping it would simplify things quite a bit. Do you
> > think that trade-off is worth it? I will follow your lead. 
> 
> On my side I thinks that's a good idea, and I don't see any issue with that for
> now. Oleksij you introduced it here in the first place, is it ok for you?

If I see it correctly - this patch kills all notifications originated
from the PSE core to the users space, until some one calls get/set path
from user space. Means, kernel update may break UAPI behavior of
existing devices.

On other hand, I agree that PSE is not a strickt requirement for PHY
functionality in most cases. At the early stage, as initial PSE support
was introduced, PHYs was kind of representation of the port and related
ethernet interface (needed for LLDP). Are there better methods to solve
it now?

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Kory Maincent]

On Mon, 6 Apr 2026 10:42:31 +0200
Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> Hi,
> 
> On Fri, Apr 03, 2026 at 03:38:49PM +0200, Kory Maincent wrote:
> > On Fri,  3 Apr 2026 15:31:11 +0200
> > Carlo Szelinsky <github@szelinsky.de> wrote:
> >   
> > > Hi Andrew,
> > > 
> > > Thx for helping me! 
> > > I thought of keeping the eager path so we still catch broken DT bindings
> > > early at boot instead of silently failing later on first ethtool access.
> > > But you're right, dropping it would simplify things quite a bit. Do you
> > > think that trade-off is worth it? I will follow your lead.   
> > 
> > On my side I thinks that's a good idea, and I don't see any issue with that
> > for now. Oleksij you introduced it here in the first place, is it ok for
> > you?  
> 
> If I see it correctly - this patch kills all notifications originated
> from the PSE core to the users space, until some one calls get/set path
> from user space. Means, kernel update may break UAPI behavior of
> existing devices.

Indeed you are right, I have missed this point.

> On other hand, I agree that PSE is not a strickt requirement for PHY
> functionality in most cases. At the early stage, as initial PSE support
> was introduced, PHYs was kind of representation of the port and related
> ethernet interface (needed for LLDP). Are there better methods to solve
> it now?

Now that Maxime has merged the phy port representation (mdi) it could be binding
to it. But we should not break the current uAPI of having it bind directly
to the PHY. Thing is, the issue will be still present as PHY ports are only
created and initialized at probe time.

We should be able to get the PSE control either at PSE register time or at PHY
(or PHY port) probe time.

I just see there is more discussion about it in the thread.

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

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Andrew Lunn]

On Fri, Apr 03, 2026 at 03:31:11PM +0200, Carlo Szelinsky wrote:
> Hi Andrew,
> 
> Thx for helping me! 
> I thought of keeping the eager path so we still catch broken DT bindings
> early at boot instead of silently failing later on first ethtool access.
> But you're right, dropping it would simplify things quite a bit. Do you
> think that trade-off is worth it? I will follow your lead. 

I suppose, the real question is, are we fixing the correct thing?

As a general principal in Linux, you don't register a device with the
core until it has all the resources it needs. This is what
EPROBE_DEFFER is about. If it is not registered with the core, the
uAPI is not available, making user space simpler.

As i understand the problem, by deferring the probe, the regulator
gets turned off, cutting the power?

So is the real problem with the regulator code? Do we need a way to
indicate a regulator should not be turned off if it is unused?

Or can we change when the regulator code turns off unused regulators?
I don't remember all the details for deferred probing, but i thought
the driver core had a timer and would keep running the deferred probes
until that timer expires. When does the regulator code turn off unused
regulators relative to this timer?

	   Andrew

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Carlo Szelinsky]

Hi Andrew,

So I went and looked at whether we can just let EPROBE_DEFER do its
thing here, like you suggested.

From what I can tell, the issue is where it happens.
fwnode_mdiobus_register_phy() gets called during the MDIO bus scan in
__of_mdiobus_parse_phys(), and if any PHY returns -EPROBE_DEFER there,
the whole scan bails out - none of the PHYs on that bus get registered.
So you'd lose all networking on that bus just because one PHY's PSE
controller isn't ready yet.

I also dug into the timing question you raised. Correct me if I'm
wrong, but from what I see the deferred probe timeout is 10s and
regulator_late_cleanup fires at 30s, so the ordering would actually
work out - the consumer would get to claim the regulator before
cleanup kills it. It's more the bus level collateral damage that
seemed like the real problem to me.

That's basically why I ended up treating EPROBE_DEFER as non-fatal
for PSE during PHY registration and doing lazy resolution instead.
The admin_state_synced flag then covers the window between PSE
controller probe and whenever the lazy resolution actually happens.

But I might be looking at this the wrong way - would you rather we
defer the whole bus and accept that trade-off? Or does the lazy
approach seem reasonable for this case? Happy to hear if you have
a different idea entirely.

Cheers,
Carlo

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Oleksij Rempel]

On Sun, Apr 05, 2026 at 08:57:30PM +0200, Carlo Szelinsky wrote:
> Hi Andrew,
> 
> So I went and looked at whether we can just let EPROBE_DEFER do its
> thing here, like you suggested.
> 
> From what I can tell, the issue is where it happens.
> fwnode_mdiobus_register_phy() gets called during the MDIO bus scan in
> __of_mdiobus_parse_phys(), and if any PHY returns -EPROBE_DEFER there,
> the whole scan bails out - none of the PHYs on that bus get registered.
> So you'd lose all networking on that bus just because one PHY's PSE
> controller isn't ready yet.
> 
> I also dug into the timing question you raised. Correct me if I'm
> wrong, but from what I see the deferred probe timeout is 10s and
> regulator_late_cleanup fires at 30s, so the ordering would actually
> work out - the consumer would get to claim the regulator before
> cleanup kills it. It's more the bus level collateral damage that
> seemed like the real problem to me.
> 
> That's basically why I ended up treating EPROBE_DEFER as non-fatal
> for PSE during PHY registration and doing lazy resolution instead.
> The admin_state_synced flag then covers the window between PSE
> controller probe and whenever the lazy resolution actually happens.
> 
> But I might be looking at this the wrong way - would you rather we
> defer the whole bus and accept that trade-off? Or does the lazy
> approach seem reasonable for this case? Happy to hear if you have
> a different idea entirely.

The core question, do we need PSE for PHY functionality? And what it
will cost to decouple it?

We can make a step back and re-evaluate - what functionality and what
order is actually required to find potentially better implementation.

We have a lot of current flowing over wires, budget and port
prioritization issues, things which may damage HW if done not correctly.
With other word, if we do not have properly operational environment
providing system specific policies, it is better to run safe
configuration - all ports/regulators are off.

This means:
- PSE controller driver should be registered as early as possible,
  without caring about existence of PHYs, ports or network interfaces.
  And configure ports in to default safe operation - off. Accept we
  have some controller/firmware which would care about safety.
- as soon as we have all needed components, we can start provide
  controllable interfaces to serve external consumers.

If we decouple PSE and PHY registration (and we probably will need to do
it some day), we would need to have own implementation of deferred
probing in the PSE core.  Event driven or by polling - which sounds not
like very good idea. Pick your poison...

Probably there is no quick and easy fix for now.

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Andrew Lunn]

> The core question, do we need PSE for PHY functionality?

I don't think the PHY should require PSE in order to send/receive
frames. If the PSE is not supplying power, the link peer is probably
off, but that is not so different from the cable being unplugged.

> We can make a step back and re-evaluate - what functionality and what
> order is actually required to find potentially better implementation.
> 
> We have a lot of current flowing over wires, budget and port
> prioritization issues, things which may damage HW if done not correctly.
> With other word, if we do not have properly operational environment
> providing system specific policies, it is better to run safe
> configuration - all ports/regulators are off.
> 
> This means:
> - PSE controller driver should be registered as early as possible,
>   without caring about existence of PHYs, ports or network interfaces.
>   And configure ports in to default safe operation - off. Accept we
>   have some controller/firmware which would care about safety.

Don't most PSE have I2C or SPI interfaces? So they have a different
life cycle to PHYs, ports or netdevs. Only PSEs which are embedded
within a PHY, on an MDIO bus, will have a closely linked life
cycle. But do such devices exist?

As soon as the PSE probes with all the resources it needs, and can
impose a safe default setting. And that can be independent of PHY and
netdev. I _think_ we only need the netdev for configuration, since
ethtool addresses netdev's.  There would only be issues with user
space listening to udev creation events, it knows the PSE exists, but
it has no way to access it until the netdev is created.

> - as soon as we have all needed components, we can start provide
>   controllable interfaces to serve external consumers.

Yep.

> If we decouple PSE and PHY registration (and we probably will need to do
> it some day), we would need to have own implementation of deferred
> probing in the PSE core.  Event driven or by polling - which sounds not
> like very good idea. Pick your poison...

I don't see why. Maybe i'm missing something. We have two cases:

1) PSE probes first. When the PHY looks up the PSE, it exists, and it
is passed a handle to the PSE.

2) PHY probes first. The PSE core returns EPROBE_DEFFER, and the PHY
will try again later.

I don't think there is any chicken/egg problems.

	Andrew

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Oleksij Rempel]

On Mon, Apr 06, 2026 at 02:22:16PM +0200, Andrew Lunn wrote:
> > The core question, do we need PSE for PHY functionality?
> 
> I don't think the PHY should require PSE in order to send/receive
> frames. If the PSE is not supplying power, the link peer is probably
> off, but that is not so different from the cable being unplugged.
> 
> > We can make a step back and re-evaluate - what functionality and what
> > order is actually required to find potentially better implementation.
> > 
> > We have a lot of current flowing over wires, budget and port
> > prioritization issues, things which may damage HW if done not correctly.
> > With other word, if we do not have properly operational environment
> > providing system specific policies, it is better to run safe
> > configuration - all ports/regulators are off.
> > 
> > This means:
> > - PSE controller driver should be registered as early as possible,
> >   without caring about existence of PHYs, ports or network interfaces.
> >   And configure ports in to default safe operation - off. Accept we
> >   have some controller/firmware which would care about safety.
> 
> Don't most PSE have I2C or SPI interfaces? So they have a different
> life cycle to PHYs, ports or netdevs. Only PSEs which are embedded
> within a PHY, on an MDIO bus, will have a closely linked life
> cycle. But do such devices exist?

i'm not aware of any.

> As soon as the PSE probes with all the resources it needs, and can
> impose a safe default setting. And that can be independent of PHY and
> netdev. I _think_ we only need the netdev for configuration, since
> ethtool addresses netdev's.  There would only be issues with user
> space listening to udev creation events, it knows the PSE exists, but
> it has no way to access it until the netdev is created.

Ack. netdev is for configuration as virtual representation of PSE PI. And it
is easier to assign corresponding interface for the LLDP.
We do not really care about the PHY; it just happens to represent the
port at the farthest end described in the Device Tree.

> > - as soon as we have all needed components, we can start provide
> >   controllable interfaces to serve external consumers.
> 
> Yep.
> 
> > If we decouple PSE and PHY registration (and we probably will need to do
> > it some day), we would need to have own implementation of deferred
> > probing in the PSE core.  Event driven or by polling - which sounds not
> > like very good idea. Pick your poison...
> 
> I don't see why. Maybe i'm missing something. We have two cases:
> 
> 1) PSE probes first. When the PHY looks up the PSE, it exists, and it
> is passed a handle to the PSE.
> 
> 2) PHY probes first. The PSE core returns EPROBE_DEFFER, and the PHY
> will try again later.
> 
> I don't think there is any chicken/egg problems.

Ack, i guess it is optimization problem.

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Kory Maincent]

On Mon, 6 Apr 2026 16:12:53 +0200
Oleksij Rempel <o.rempel@pengutronix.de> wrote:

> On Mon, Apr 06, 2026 at 02:22:16PM +0200, Andrew Lunn wrote:
> > > The core question, do we need PSE for PHY functionality?  
> > 
> > I don't think the PHY should require PSE in order to send/receive
> > frames. If the PSE is not supplying power, the link peer is probably
> > off, but that is not so different from the cable being unplugged.
> >   
> > > We can make a step back and re-evaluate - what functionality and what
> > > order is actually required to find potentially better implementation.
> > > 
> > > We have a lot of current flowing over wires, budget and port
> > > prioritization issues, things which may damage HW if done not correctly.
> > > With other word, if we do not have properly operational environment
> > > providing system specific policies, it is better to run safe
> > > configuration - all ports/regulators are off.
> > > 
> > > This means:
> > > - PSE controller driver should be registered as early as possible,
> > >   without caring about existence of PHYs, ports or network interfaces.
> > >   And configure ports in to default safe operation - off. Accept we
> > >   have some controller/firmware which would care about safety.  
> > 
> > Don't most PSE have I2C or SPI interfaces? So they have a different
> > life cycle to PHYs, ports or netdevs. Only PSEs which are embedded
> > within a PHY, on an MDIO bus, will have a closely linked life
> > cycle. But do such devices exist?  
> 
> i'm not aware of any.

Same here, but it's not impossible to have such device in the future. 

> > As soon as the PSE probes with all the resources it needs, and can
> > impose a safe default setting. And that can be independent of PHY and
> > netdev. I _think_ we only need the netdev for configuration, since
> > ethtool addresses netdev's.  There would only be issues with user
> > space listening to udev creation events, it knows the PSE exists, but
> > it has no way to access it until the netdev is created.  
> 
> Ack. netdev is for configuration as virtual representation of PSE PI. And it
> is easier to assign corresponding interface for the LLDP.
> We do not really care about the PHY; it just happens to represent the
> port at the farthest end described in the Device Tree.
> 
> > > - as soon as we have all needed components, we can start provide
> > >   controllable interfaces to serve external consumers.  
> > 
> > Yep.
> >   
> > > If we decouple PSE and PHY registration (and we probably will need to do
> > > it some day), we would need to have own implementation of deferred
> > > probing in the PSE core.  Event driven or by polling - which sounds not
> > > like very good idea. Pick your poison...  
> > 
> > I don't see why. Maybe i'm missing something. We have two cases:
> > 
> > 1) PSE probes first. When the PHY looks up the PSE, it exists, and it
> > is passed a handle to the PSE.
> > 
> > 2) PHY probes first. The PSE core returns EPROBE_DEFFER, and the PHY
> > will try again later.
> > 
> > I don't think there is any chicken/egg problems.  
> 
> Ack, i guess it is optimization problem.

Yes, as I reply in another mail of the thread:
We should be able to get the PSE control either at PSE register time or at PHY
(or PHY port) probe time.

Maybe if the PHY can't find the PSE PI, we could save the phandle of the PSE PI
somewhere in the PHY structure. Then at PSE register time, look for each PHY to
resolve every unresolved phandle.

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

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Andrew Lunn]

On Sun, Apr 05, 2026 at 08:57:30PM +0200, Carlo Szelinsky wrote:
> Hi Andrew,
> 
> So I went and looked at whether we can just let EPROBE_DEFER do its
> thing here, like you suggested.
> 
> >From what I can tell, the issue is where it happens.
> fwnode_mdiobus_register_phy() gets called during the MDIO bus scan in
> __of_mdiobus_parse_phys(), and if any PHY returns -EPROBE_DEFER there,
> the whole scan bails out - none of the PHYs on that bus get registered.
> So you'd lose all networking on that bus just because one PHY's PSE
> controller isn't ready yet.

Something does not sounds correct here. The MDIO bus, and the devices
on the bus should have different life cycles.

If the MDIO bus itself is missing resources it needs, it can return
EPROBE_DEFFER. A typical example of this would be the MDIO bus reset,
which applies to all devices on the bus. If that GPIO is missing, the
probe of the MDIO bus will unwind.

I would expect PHYs on the bus to be just devices in the device
model. They can return EPROBE_DEFER, and the driver core will probe
them again later. This could be a per PHY reset signal, reset
controller, etc, or the PSE. If such a resource is missing, just the
PHY should fail probing, not the whole MDIO bus.

> I also dug into the timing question you raised. Correct me if I'm
> wrong, but from what I see the deferred probe timeout is 10s and
> regulator_late_cleanup fires at 30s, so the ordering would actually
> work out - the consumer would get to claim the regulator before
> cleanup kills it. It's more the bus level collateral damage that
> seemed like the real problem to me.

Your patch 0/X says:

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

How are we getting to time t=30 without the PSE probing?

If the PSE controller is a module, and missing from the file system,
so cannot be loaded, then turning off the regulators actually seems
like a good safety policy. But if the module is there, but never gets
loaded, it sounds like we have a different sort of problem, some
cyclic dependency we need to break?

	Andrew

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Carlo Szelinsky]

Hi Andrew, Oleksij,

Thanks for pushing me in the right direction here.

So if I understand correctly, I should move the PSE control lookup
from fwnode_mdiobus_register_phy() into phy_probe(). That way the PHY
just defers like any other device if the PSE controller isn't there
yet, and the bus scan keeps going for the other PHYs.

I checked and bus_probe_device() is void, so device_add() won't fail
even if probe defers. And once the PSE module loads, the deferred
probe retry should kick in and claim the regulator before the 30s
cleanup runs. If the module never loads, the regulator cleanup is
actually the right thing to do safety-wise. So no need for the
admin_state_synced workaround or the lazy resolution stuff -
deferred probe just handles it.

Unlike lazy resolution, this also doesn't break notifications, so
PSE is acquired during probe, not on first ethtool access.

Does that sound like what you had in mind?

Cheers,
Carlo

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Andrew Lunn]

On Mon, Apr 06, 2026 at 04:43:24PM +0200, Carlo Szelinsky wrote:
> Hi Andrew, Oleksij,
> 
> Thanks for pushing me in the right direction here.
> 
> So if I understand correctly, I should move the PSE control lookup
> from fwnode_mdiobus_register_phy() into phy_probe(). That way the PHY
> just defers like any other device if the PSE controller isn't there
> yet, and the bus scan keeps going for the other PHYs.

Ah, yes. That is the correct fix.

	Andrew

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Carlo Szelinsky]

So I went ahead and tested the phy_probe() approach on my setup (RTL930x
DSA switch with an I2C Hasivo HS104 PSE controller as module).

PoE itself works fine, but phydev->psec never gets set - ethtool just
says "No PSE is attached" on all ports.

Took me a while to figure out what's going on. The problem is how DSA
handles PHYs: when phy_probe() returns -EPROBE_DEFER because the PSE
controller hasn't probed yet, the PHY device is registered but sits
there unprobed. Then the DSA switch comes along, sets up its ports, and
phy_attach_direct() force-binds the generic PHY driver with
device_bind_driver(). Now the device already has a driver, so when the
deferred probe retry kicks in it just skips it. phy_probe() never runs
again and psec stays NULL.

What I'm seeing timing-wise:
  - MDIO scan registers PHYs, phy_probe() defers (no PSE yet)
  - DSA probes, phy_attach_direct() binds genphy
  - t=17s: HS104 finally probes
  - deferred retry: nope, driver already bound
  - t=35s: regulator_late_cleanup (caught by admin_state_synced)

Not sure what the best path forward is here. Should we look at fixing
phy_attach_direct() to handle this case, or go back to the non-fatal
EPROBE_DEFER approach from v2 for now?

Cheers,
Carlo

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Andrew Lunn]

On Wed, Apr 08, 2026 at 11:07:11PM +0200, Carlo Szelinsky wrote:
> So I went ahead and tested the phy_probe() approach on my setup (RTL930x
> DSA switch with an I2C Hasivo HS104 PSE controller as module).
> 
> PoE itself works fine, but phydev->psec never gets set - ethtool just
> says "No PSE is attached" on all ports.
> 
> Took me a while to figure out what's going on. The problem is how DSA
> handles PHYs: when phy_probe() returns -EPROBE_DEFER because the PSE
> controller hasn't probed yet, the PHY device is registered but sits
> there unprobed. Then the DSA switch comes along, sets up its ports, and
> phy_attach_direct() force-binds the generic PHY driver with
> device_bind_driver().

Yes, this is a known issue with phylib.

> What I'm seeing timing-wise:
>   - MDIO scan registers PHYs, phy_probe() defers (no PSE yet)
>   - DSA probes, phy_attach_direct() binds genphy
>   - t=17s: HS104 finally probes

That is a long time. Does it actually start probing much earlier, but
it is busy download firmware, and the probe completes after 17
seconds.

>   - deferred retry: nope, driver already bound
>   - t=35s: regulator_late_cleanup (caught by admin_state_synced)
> 
> Not sure what the best path forward is here. Should we look at fixing
> phy_attach_direct() to handle this case.

It is not easy to fix, because generally drivers call
phy_attach_direct() in their open() function, not probe().  It is too
late to return EPROBE_DEFFER, you can only do that in probe. phylib
knows the device exists, but it sees there is no driver, so it does
not have much choice. It can either use genphy, or it can error out
phy_attach_direct().

DSA is however atypical, and does phylink_connect() early. So there
might be a way out. In dsa_user_phy_connect() once you have the
phydev, you could look at phydev->drv and return EPROBE_DEFFER if it
is NULL. Ugly. And a bit of a layering violation. Maybe a helper in
phylib, phy_is_driver_bound() ?

   Andrew

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Andrew Lunn]

On Wed, Apr 08, 2026 at 11:07:11PM +0200, Carlo Szelinsky wrote:
> So I went ahead and tested the phy_probe() approach on my setup (RTL930x
> DSA switch with an I2C Hasivo HS104 PSE controller as module).
> 
> PoE itself works fine, but phydev->psec never gets set - ethtool just
> says "No PSE is attached" on all ports.
> 
> Took me a while to figure out what's going on. The problem is how DSA
> handles PHYs: when phy_probe() returns -EPROBE_DEFER because the PSE
> controller hasn't probed yet, the PHY device is registered but sits
> there unprobed. Then the DSA switch comes along, sets up its ports, and
> phy_attach_direct() force-binds the generic PHY driver with
> device_bind_driver(). Now the device already has a driver, so when the
> deferred probe retry kicks in it just skips it. phy_probe() never runs
> again and psec stays NULL.
> 
> What I'm seeing timing-wise:
>   - MDIO scan registers PHYs, phy_probe() defers (no PSE yet)
>   - DSA probes, phy_attach_direct() binds genphy
>   - t=17s: HS104 finally probes
>   - deferred retry: nope, driver already bound
>   - t=35s: regulator_late_cleanup (caught by admin_state_synced)
> 
> Not sure what the best path forward is here. Should we look at fixing
> phy_attach_direct() to handle this case, or go back to the non-fatal
> EPROBE_DEFER approach from v2 for now?

I thought about this some more. Looking at the phydev->drv might solve
it for DSA switches, but it is not a general solution for when the PSE
is used with a normal MAC, and the phylink_connect() happens in
open().

Now, the HS104 appears to be a quad device, intended for switches. So
maybe solving the issue only for DSA is O.K?

Otherwise, maybe we need the ability to associate the PSE controller
to the MAC? At a quick look, PSE and PHY are not tightly bound
together. So we could make the MAC driver call something similar to
of_pse_control_get() in its probe function, where it can return
EPRODE_DEFFER. net/ethtool/pse-pd.c would need some changes as well.

	Andrew

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Kory Maincent]

On Thu, 9 Apr 2026 14:30:53 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> On Wed, Apr 08, 2026 at 11:07:11PM +0200, Carlo Szelinsky wrote:
> > So I went ahead and tested the phy_probe() approach on my setup (RTL930x
> > DSA switch with an I2C Hasivo HS104 PSE controller as module).
> > 
> > PoE itself works fine, but phydev->psec never gets set - ethtool just
> > says "No PSE is attached" on all ports.
> > 
> > Took me a while to figure out what's going on. The problem is how DSA
> > handles PHYs: when phy_probe() returns -EPROBE_DEFER because the PSE
> > controller hasn't probed yet, the PHY device is registered but sits
> > there unprobed. Then the DSA switch comes along, sets up its ports, and
> > phy_attach_direct() force-binds the generic PHY driver with
> > device_bind_driver(). Now the device already has a driver, so when the
> > deferred probe retry kicks in it just skips it. phy_probe() never runs
> > again and psec stays NULL.
> > 
> > What I'm seeing timing-wise:
> >   - MDIO scan registers PHYs, phy_probe() defers (no PSE yet)
> >   - DSA probes, phy_attach_direct() binds genphy
> >   - t=17s: HS104 finally probes
> >   - deferred retry: nope, driver already bound
> >   - t=35s: regulator_late_cleanup (caught by admin_state_synced)
> > 
> > Not sure what the best path forward is here. Should we look at fixing
> > phy_attach_direct() to handle this case, or go back to the non-fatal
> > EPROBE_DEFER approach from v2 for now?  
> 
> I thought about this some more. Looking at the phydev->drv might solve
> it for DSA switches, but it is not a general solution for when the PSE
> is used with a normal MAC, and the phylink_connect() happens in
> open().
>
> Now, the HS104 appears to be a quad device, intended for switches. So
> maybe solving the issue only for DSA is O.K?
> 
> Otherwise, maybe we need the ability to associate the PSE controller
> to the MAC? At a quick look, PSE and PHY are not tightly bound
> together. So we could make the MAC driver call something similar to
> of_pse_control_get() in its probe function, where it can return
> EPRODE_DEFFER. net/ethtool/pse-pd.c would need some changes as well.

I don't think we should associate it to the MAC. In a hardware point of view the
PSE Power Interfaces are wired the MDIs. It was associated historically to the
PHY, because, at that time there was no representation of the MDI. Now thanks
to Maxime there is, so in the future we should associate the PSE control to the
MDI only. We will already have to keep the PHY association compatibility to not
break binding API but please do not add another layer of association that will
increase more compatibility burden for the future.

As I proposed in another thread, if the PHY can't find the PSE PI, we could
save the phandle of the PSE PI somewhere in the PHY structure. Then at PSE
register time, look for each PHY and try to resolve every unresolved phandle.

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

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Andrew Lunn]

> I don't think we should associate it to the MAC. In a hardware point of view the
> PSE Power Interfaces are wired the MDIs. It was associated historically to the
> PHY, because, at that time there was no representation of the MDI. Now thanks
> to Maxime there is, so in the future we should associate the PSE control to the
> MDI only. We will already have to keep the PHY association compatibility to not
> break binding API but please do not add another layer of association that will
> increase more compatibility burden for the future.
> 
> As I proposed in another thread, if the PHY can't find the PSE PI, we could
> save the phandle of the PSE PI somewhere in the PHY structure. Then at PSE
> register time, look for each PHY and try to resolve every unresolved phandle.

I still think we should be deferring probe until we have all the parts
available. The question is, how do we actually do that?

We could insist that MACs being used with PSE need to call
phylink_connect() in probe, so we can return EPROBE_DEFER. We might
actually need a new API method, phylink_connect_probe(). That can call
down into phylib, maybe again new API methods, which will not bind
genphy, but return EPROBE_DEFER.

This helps solve this problem. And it puts in place a solution for
other similar problems. We have seen PHY drivers which download
firmware get into a similar situation, genphy used because the
download takes too long. It needs MAC driver changes, which is not
great, but the changes themselves should be easy to do.

I don't think having MDI represented helps us. We still get into the
same situation, open() calls phylink_connect() and there is nothing we
can do except use genphy.

    Andrew

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Russell King (Oracle)]

On Thu, Apr 09, 2026 at 05:34:56PM +0200, Andrew Lunn wrote:
> I still think we should be deferring probe until we have all the parts
> available. The question is, how do we actually do that?

Indeed...

> We could insist that MACs being used with PSE need to call
> phylink_connect() in probe, so we can return EPROBE_DEFER. We might
> actually need a new API method, phylink_connect_probe(). That can call
> down into phylib, maybe again new API methods, which will not bind
> genphy, but return EPROBE_DEFER.

How would MACs know whether they should call phylink_connect_probe()
or phylink_connect_phy() ?

What do we do about MAC drivers that are a single driver and device,
but are made up of several network devices (like Marvell PP2) ?

We also have network drivers that provide a MDIO bus for a different
network device, which makes connecting the PHY harder in the probe
path.

Lastly, what do we do where a PHY driver hasn't been configured or
doesn't exist for the PHY?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration

[Andrew Lunn]

On Thu, Apr 09, 2026 at 05:08:33PM +0100, Russell King (Oracle) wrote:
> On Thu, Apr 09, 2026 at 05:34:56PM +0200, Andrew Lunn wrote:
> > I still think we should be deferring probe until we have all the parts
> > available. The question is, how do we actually do that?
> 
> Indeed...
> 
> > We could insist that MACs being used with PSE need to call
> > phylink_connect() in probe, so we can return EPROBE_DEFER. We might
> > actually need a new API method, phylink_connect_probe(). That can call
> > down into phylib, maybe again new API methods, which will not bind
> > genphy, but return EPROBE_DEFER.

I did not say i would be easy...
 
> How would MACs know whether they should call phylink_connect_probe()
> or phylink_connect_phy() ?

It would not. Anybody with a board using PSE would need to modify the
MAC driver to use phylink_connect_probe(), if they have a slow to load
PSE device.

> What do we do about MAC drivers that are a single driver and device,
> but are made up of several network devices (like Marvell PP2) ?

It would need more care, but it should work. You might end up removing
a perfectly good device because the other one is missing its PHY,
which is not ideal, but hopefully you get there in the end.

> We also have network drivers that provide a MDIO bus for a different
> network device, which makes connecting the PHY harder in the probe
> path.

Yes, we would see such setup doing more deferred probing, but again,
they should get there in the end. The most common systems doing this
are using the FEC. Are there any board using the FEC and problematic
PSE?

> Lastly, what do we do where a PHY driver hasn't been configured or
> doesn't exist for the PHY?

I was wondering if we can get from the driver core some idea where we
are in the deferred probing window. If we are 2/3 of the way through
the window, fall back to genphy?

I'm not saying we should change all MAC drivers, or recommend new MAC
drivers connect to the PHY in probe. I just want to offer the option
if you have a problematic PSE or PHY, change the MAC driver.

What we have also said in the past, it is the bootloaders problem to
download firmware into the PHY, or PSE, so that it is ready to go by
the time Linux boots. That would also be the simpler solution here.

    Andrew