linux-kernel - Re: [PATCH 1/3] gpio: idio-16: Introduce the ACCES IDIO-16 GPIO library module

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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