Re: [PATCH v4 1/2] reset: core: Serialize concurrent deassert/reset of shared resets

[Alvin Šipraga]

On Fri, Oct 23, 2026 at 03:16:08PM +0800, shengjiu.wang@xxxxxxxxxxx wrote:
> From: Shengjiu Wang <shengjiu.wang@xxxxxxx>
> 
> Add a reset_controller_dev::can_sleep flag that a provider sets when its
> reset ops may sleep. When it is set, serialize the shared refcount update
> and the hardware op in reset_control_reset(), reset_control_deassert() and
> reset_control_assert() under a new per-control mutex, taken inside the SRCU
> read-side critical section. Providers that leave the flag clear keep the
> existing lockless path, so callers in atomic context are unaffected.
> 
> reset_control_deassert() and reset_control_reset() are documented to
> guarantee that the reset line has been deasserted, respectively that a
> reset pulse has been issued, by the time they return.
> 
> For a shared reset only the first caller runs the hardware op; the other
> callers just bump the refcount and return. When the op can sleep this
> breaks the guarantee: a second caller can observe the bumped refcount and
> return before the first caller's op has finished, and then touch hardware
> that is still in reset. A reset_control_assert() racing a concurrent
> reset_control_deassert() can likewise interleave the two sleeping ops and
> leave the line asserted while the refcount says it is deasserted.
> 
> Suggested-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@xxxxxxx>
> Link: https://lore.kernel.org/all/aszDZlJ0KahNwgZO@xxxxxxxxxx/

Reviewed-by: Alvin Šipraga <alvin.sipraga@xxxxxxxxxx>

> ---
>  drivers/reset/core.c             | 205 ++++++++++++++++++++-----------
>  include/linux/reset-controller.h |   4 +
>  2 files changed, 138 insertions(+), 71 deletions(-)