[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANZih_QUvHWhFRr6rNLhYOuyQ77oqUyvrtAMF593zOdWfa=JYQ@mail.gmail.com>
Date: Sat, 14 Jun 2025 18:17:17 -0300
From: Andrew Ijano <andrew.ijano@...il.com>
To: Nuno Sá <noname.nuno@...il.com>
Cc: jic23@...nel.org, andrew.lopes@...mni.usp.br, gustavobastos@....br,
dlechner@...libre.com, nuno.sa@...log.com, andy@...nel.org,
jstephan@...libre.com, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 3/3] iio: accel: sca3000: use guard(mutex)() for
handling mutex lock
On Thu, Jun 12, 2025 at 4:37 AM Nuno Sá <noname.nuno@...il.com> wrote:
>
> On Wed, 2025-06-11 at 16:39 -0300, Andrew Ijano wrote:
> > ---
> > For this one, there are two cases where the previous implementation
> > was a smalllocking portion of the code and now it's locking the whole
> > function. I don't know if this is a desired behavior.
> >
>
> In theory, it should not break anything. But you can always refactor things (like
> small helpers) to lock only the code you want. There's also scoped_guard(). I would
> say, up to you for re-spinning a new version because of the above :).
Oh, thanks for the suggestion! scoped_guard() is exactly what I was looking for.
> Just have something that I'm not totatlly sure... Did you made sure to compile?
> AFAIR, guard() had some complains when used in switch() case statements. Maybe that
> got improved.
>
Well, it did compile for me, but as David and Jonathan suggested, it's
better to create a scope for that.
In fact, when implementing this I looked to other examples that used
guard() in switch() case statements, but I didn't notice that they
added a local scope too.
Thanks,
Andrew
Powered by blists - more mailing lists