linux-kernel - Re: [PATCH v1 3/5] gpio: max77620: Replace interrupt-enable array with bitmap

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Jul 2020 12:08:02 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-tegra@...r.kernel.org,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 3/5] gpio: max77620: Replace interrupt-enable array
 with bitmap

08.07.2020 11:44, Andy Shevchenko пишет:
> On Wed, Jul 8, 2020 at 11:30 AM Dmitry Osipenko <digetx@...il.com> wrote:
>>
>> There is no need to dedicate an array where a bitmap could be used.
>> Let's replace the interrupt's enable-array with the enable-mask in order
>> to improve the code a tad.
> 
> ...
> 
>> +#include <linux/bitops.h>
> 
>>         unsigned int            irq_type[MAX77620_GPIO_NR];
>> -       bool                    irq_enabled[MAX77620_GPIO_NR];
>> +       unsigned long           irq_enb_mask;
> 
> I would rather to move to DECLARE_BITMAP()
> (the macro is defined in types.h IIRC)
> 

Hello, Andy! I know about DECLARE_BITMAP(), it is a very useful macro
for bitmaps that are over 32 bits, which is absolutely not the case
here. This macro will make code more difficult to read and then we will
have to use the bitmap API, which is unnecessary overhead for this case,
and thus, it won't be an improvement anymore, IMO.

I'd either keep this patch as-is or drop it.