Re: [PATCH 15/78] ASoC: codecs: cs42l43: Use guard() for mutex locks
David Laight <[email protected]>
| Newsgroups | dev.linux.lists.chrome-platform,dev.linux.lists.asahi,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-mediatek,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-sound |
|---|---|
| Message-ID | <20260617140209.3f89706c@pumpkin> |
On Wed, 17 Jun 2026 11:57:49 +0100 Charles Keepax <[email protected]> wrote: > On Wed, Jun 17, 2026 at 05:31:32PM +0700, [email protected] wrote: > > From: bui duc phuc <[email protected]> > > > > Clean up the code using guard() for mutex locks. > > Merely code refactoring, and no behavior change. > > > > Signed-off-by: bui duc phuc <[email protected]> > > --- > > @@ -913,17 +908,13 @@ int cs42l43_jack_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *u > > if (override >= e->items) > > return -EINVAL; > > > > - mutex_lock(&priv->jack_lock); > > + guard(mutex)(&priv->jack_lock); > > I believe you have to use scoped_guard here, as there is a return > from the function above, if memory serves it attempts to release > the mutex on that path despite it being above the guard. Indeed. I believe clang will complain. That makes these mechanical conversions of existing code dangerous churn. While using guard() (etc) can make it easier to ensure the lock is released when functions have multiple error exits, I'm not convinced it makes the code any easier to read (other people may disagree). David > > Be worth having a quick scan through the rest of the series for > this as well. > > Thanks, > Charles >