Re: [PATCH v7] iio: imu: kmx61: Use guard(mutex)() over manual locking

[Maxwell Doose]

On Fri, May 22, 2026 at 12:29 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>
> On Fri, 22 May 2026 10:38:09 -0500
> Maxwell Doose <m32285159@xxxxxxxxx> wrote:
>
> > On Fri, May 22, 2026 at 7:46 AM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
> > >
> > > On Thu, 21 May 2026 17:30:43 -0500
> > > Maxwell Doose <m32285159@xxxxxxxxx> wrote:
[snip]
> > > > @@ -834,41 +831,40 @@ static int kmx61_read_raw(struct iio_dev *indio_dev,
> > > >               if (chan->type != IIO_ACCEL && chan->type != IIO_MAGN)
> > > >                       return -EINVAL;
> > > >
> > > > -             mutex_lock(&data->lock);
> > > > -             ret = kmx61_get_odr(data, val, val2, chan->address);
> > > > -             mutex_unlock(&data->lock);
> > > > +             scoped_guard(mutex, &data->lock)
> > > > +                     ret = kmx61_get_odr(data, val, val2, chan->address);
> > >
> > > Why is this one a scoped_guard()?  Seems like it would be more consistent
> > > if it was done like the one above with {} and guard()
> > >
> >
> > I'm guessing you're talking about the {} in the switch-case. I guess
> > it's likely because the guard()() in that specific case goes for the
> > whole scope of the case, whereas we only need to hold the lock for
> > this call (I tend to keep section length as close as possible when
> > doing these things, and typically I'd use scoped_guard() for a single
> > call).
>
>         case IIO_CHAN_INFO_SAMP_FREQ:
>                 if (chan->type != IIO_ACCEL && chan->type != IIO_MAGN)
>                         return -EINVAL;
>
>                 mutex_lock(&data->lock);
>                 ret = kmx61_get_odr(data, val, val2, chan->address);
>                 mutex_unlock(&data->lock);
>                 if (ret)
>                         return -EINVAL;
>                 return IIO_VAL_INT_PLUS_MICRO;
>
> Is the block in question.  Given nothing else happens after this point,
> other than returning.  I'd always favour guard as it keeps the error
> check at same level as the source of the error.
>

Sorry if I wasn't clear, I meant that. I see now that it just returns
right after, haha, that's my bad :/

best regards,
max