Re: [PATCH RFC net-next 1/4] net: pse-pd: scope pse_control regulator handle to kref lifetime

[Kory Maincent <kory.maincent@bootlin.com>]

On Thu, 23 Apr 2026 01:42:14 -0600
Corey Leavitt via B4 Relay <devnull+corey.leavitt.info@kernel.org> wrote:

> From: Corey Leavitt <corey@leavitt.info>
> 
> __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@bootlin.com>

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