Re: [PATCH v2 08/14] reset: handle removing supplier before consumers

[Bartosz Golaszewski]

On Wed, Mar 4, 2026 at 11:58 AM Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> wrote:
>
> Hi Bartosz,
>
> On Mo, 2026-02-23 at 11:06 +0100, Bartosz Golaszewski wrote:
> > Except for the reset-gpio, all reset drivers use device tree - and as
> > such - benefit from the device links set up by driver core. This means,
> > that no reset supplier will be unbound before all its consumers have
> > been. For this reason, nobody bothered making the reset core resiliant
> > to the object life-time issues that are plagueing the kernel. In this
> > case: reset control handles referencing the reset provider device with
> > no serialization or NULL-pointer checking.
> >
> > We now want to make the reset core fwnode-agnostic but before we do, we
> > must make sure it can survive unbinding of suppliers with consumers
> > still holding reset control handles.
> >
> > To that end: use SRCU to protect the rcdev pointer inside struct
> > reset_control. We protect all sections using the pointer with SRCU
> > read-only critical sections and synchronize SRCU after every
> > modification of the pointer.
> >
> > This is in line with what the GPIO subsystem does and what the proposed
> > revocable API tries to generalize. When and if the latter makes its way
> > into the kernel, reset core could potentially also be generalized to use
> > it.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>
>
> The changes look fine to me, but is there some kind of consensus that
> SRCU is the right tool for this kind of protection? Is there a reason
> to use SRCU over rw_semaphore here, apart from similarity to the
> implementation in the GPIO subsystem?
>

If and when revocable gets upstream, it will become the mechanism of
choice for this. Until that happens, we have to use existing
synchronization primitives and SRCU is the only one that allows to be
called from sleeping and atomic context, while also allowing the
critical section to sleep. Since the reset docs don't really say
whether reset_control_assert() and company can sleep or not and if
they can be called from any context, I went with the safe option.

Bartosz