Re: [PATCH v3] reset: core: Serialize concurrent deassert/reset of shared resets

[Philipp Zabel <p.zabel@pengutronix.de>]

On Do, 2026-10-22 at 15:58 +0200, Alvin Šipraga wrote:
[...]
> > > I had the same thought. But I kept bumping into the fact that the
> > > rcdev->lock mutex is taken in reset_control_acquire() while we are
> > > holding rstc->lock. If rstc->lock becomes a spinlock
> > 
> > Why would it? shared_lock is a mutex, too.
> 
> I'm talking about the next step, after auditing all drivers and setting
> can_sleep = true where necessary.
> 
> As I pointed out in my reply to v2 [1], the shared reset race exists
> regardless of whether the underlying reset controller can sleep or
> not. Shengjiu's fix only applies to controllers which can sleep. The fix
> can be extended to controllers that can't sleep too, but only if
> shared_lock is a spinlock - since, in general, the API permits calls in
> atomic context. (Those atomic callers obviously rely implicitly on the
> non-blocking nature of the backing controller, but that's a bit besides
> the point).
> 
> So the idea I outlined in [1] is for this shared_lock to be either a
> mutex or a spinlock depending on the controller's can_sleep. The logic
> of this patch staying the same.
> 
> Maybe I misunderstood you here:
> 
> > > > We could also combine this with the exclusive reset control's acquire
> > > > "lock" if we move that inside the SRCU section.
> 
> I understood this to mean "collapse lock and shared_lock into a single
> lock". And I was just saying that - with the above in mind - if
> shared_lock might be either a mutex or a spinlock, then it doesn't work
> to collapse them, because...

The disconnect might be that I assumed the mutex would still exist and
we'd just add a spinlock next to it, and you plan to use a union like
regmap does?

Either way, the point is moot if no (acquire_)lock is needed in struct
reset_control.

> > 
> Anyway, I will prepare some patches and you can take a look.
[...]
> I'll send a patch.

Thank you.

regards
Philipp