net: pse-pd: scope pse_control regulator handle to kref lifetime

From: Corey Leavitt <[email protected]>

__pse_control_release() drops psec->ps via devm_regulator_put(), which only succeeds if the devres entry added by the matching devm_regulator_get_exclusive() is still present on pcdev->dev at the time the pse_control's kref hits zero.

That assumption does not hold when the controller is unbound while a pse_control still has consumers: pcdev->dev's devres list is released LIFO, so every per-attach regulator-GET devres runs (and regulator_put()s the underlying regulator) before pse_controller_unregister() itself is invoked. Any later pse_control_put() from that unbind path then reads psec->ps as a dangling pointer inside devm_regulator_put() and WARNs at drivers/regulator/devres.c:232 (devres_release() fails to find the already-released match).

The pse_control's consumer handle is logically scoped to the pse_control's refcount, not to pcdev->dev's devres lifetime. Switch to the plain regulator_get_exclusive() / regulator_put() pair so the regulator put in __pse_control_release() no longer depends on the controller's devres still being present. No change to the regulator-framework-visible refcount or lifetime of the underlying
regulator: a single get paired with a single put. The existing devm_regulator_register() for the per-PI rails is unchanged (those ARE correctly scoped to the controller's lifetime).

This addresses only the regulator handle. The same unbind-while-held scenario also leaves __pse_control_release() reading psec->pcdev->pi[] and psec->pcdev->owner after pse_controller_unregister() has freed pcdev->pi, because the controller does not drain its outstanding pse_control references on unregister. That wider pse_control vs pcdev lifetime problem pre-dates this change and is addressed by the PSE controller notifier series, which drains phydev->psec on PSE_UNREGISTERED before pcdev->pi is freed.

---
This is patch 1 of the "decouple controller lookup from MDIO probe" series, reposted on its own for net as Jakub suggested. The rest of the series targets net-next and is deferred until it reopens.

Changes in v2:
- Reword the commit message to scope the fix to the regulator handle. As Simon's review pointed out, the same unbind-while-held path also reads pcdev->pi[] and pcdev->owner after pse_release_pis(); that wider pse_control vs pcdev lifetime issue is fixed by the notifier series, not here. No code change.

v1: https://lore.kernel.org/netdev/[email protected]/

---
 drivers/net/pse-pd/pse_core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

index 69dbdbde9d71..a5e6d7b26b9f 100644
@@ -1367,7 +1367,7 @@ static void __pse_control_release(struct kref *kref)
 
 	if (psec->pcdev->pi[psec->id].admin_state_enabled)
 		regulator_disable(psec->ps);
-	devm_regulator_put(psec->ps);
+	regulator_put(psec->ps);
 
 	module_put(psec->pcdev->owner);
 

@@ -1436,8 +1436,8 @@ pse_control_get_internal(struct pse_controller_dev *pcdev, unsigned int index,
 		goto free_psec;
 
 	pcdev->pi[index].admin_state_enabled = ret;
-	psec->ps = devm_regulator_get_exclusive(pcdev->dev,
-						rdev_get_name(pcdev->pi[index].rdev));
+	psec->ps = regulator_get_exclusive(pcdev->dev,
+					   rdev_get_name(pcdev->pi[index].rdev));
 	if (IS_ERR(psec->ps)) {
 		ret = PTR_ERR(psec->ps);
 		goto put_module;

base-commit: d87363b0edfc7504ff2b144fe4cdd8154f90f42e

2.43.0

Thanks for the update.