[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YyWMai1UZPaBbsOx@surfacebook>
Date: Sat, 17 Sep 2022 11:59:22 +0300
From: andy.shevchenko@...il.com
To: William Breathitt Gray <william.gray@...aro.org>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>, brgl@...ev.pl,
linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
linux-gpio@...r.kernel.org
Subject: Re: [PATCH 1/3] gpio: idio-16: Introduce the ACCES IDIO-16 GPIO
library module
Thu, Sep 15, 2022 at 11:46:13AM -0400, William Breathitt Gray kirjoitti:
> On Tue, Sep 13, 2022 at 07:16:23PM +0300, Andy Shevchenko wrote:
> > On Sun, Sep 11, 2022 at 04:34:38PM -0400, William Breathitt Gray wrote:
...
> > > + if (value)
> > > + set_bit(offset, state->out_state);
> > > + else
> > > + clear_bit(offset, state->out_state);
> >
> > assign_bit()
> >
> > But I'm wondering why do you need the atomic bitops under the lock?
>
> I don't think atomic bitops are necessary in this case because of the
> lock as you pointedly out, but I felt using these made the intention of
> the code clearer. Is there a non-atomic version of assign_bit(), or do
> you recommend I use bitwise operations directly here instead?
__assign_bit()
Hint: All __ prefixed bitops (for a single bit operation!) are considered
non-atomic. There are exceptions when no __-variant of op is present, but
it not the case here AFAICS.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists