Re: [PATCH RFC net-next 1/4] net: pse-pd: scope pse_control regulator handle to kref lifetime
From: Kory Maincent
Date: Fri Apr 24 2026 - 04:37:10 EST
On Thu, 23 Apr 2026 01:42:14 -0600
Corey Leavitt via B4 Relay <devnull+corey.leavitt.info@xxxxxxxxxx> wrote:
> From: Corey Leavitt <corey@xxxxxxxxxxxx>
>
> __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.
>
> In practice that assumption does not hold when the controller is
> unbound while any 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
> __pse_control_release() does the right put regardless of whether
> the controller's devres has already been unwound.
>
> 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).
Acked-by: Kory Maincent <kory.maincent@xxxxxxxxxxx>
Thank you!
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com