linux-kernel - Re: [PATCH] gpio/sifive: fix static checker warning

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]

Message-ID: <934410721310a3107e1d9d2600ec438a@kernel.org>
Date:   Wed, 29 Jan 2020 09:12:08 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     JaeJoon Jung <rgbi3307@...il.com>
Cc:     Yash Shah <yash.shah@...ive.com>, atish.patra@....com,
        wesley@...ive.com, linus.walleij@...aro.org,
        linux-kernel@...r.kernel.org, bgolaszewski@...libre.com,
        Palmer Dabbelt <palmer@...belt.com>, sachin.ghadi@...ive.com,
        linux-gpio@...r.kernel.org,
        Paul Walmsley <paul.walmsley@...ive.com>,
        linux-riscv <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH] gpio/sifive: fix static checker warning

JaeJoon,

On 2020-01-29 01:27, JaeJoon Jung wrote:
> Because SiFive FU540 GPIO Registers are aligned 32-bit,
> I think that irq_state is good "unsigned int" than "unsigned long".
> 
> I refer to SiFive FU540-C000 Manual v1p0 (GPIO Register Table 103)
> as "Only naturally aligned 32-bit memory accesses are supported"

You realize that we're talking about variables here, and not hardware
registers, right?

> when you use assign_bit(offset, &chip->irq_state, 1),
> offset is 32-bit.

And? assign_bit takes an "unsigned long *" as a parameter. irrespective
of the size of long on a given architecture, by the way.

> I prefer to use bit operation instead of assign_bit().
> 
> u32 bit = BIT(offset);
> chip->irq_state |= bit;

which is not what assign_bit() does.

> If you use this code, you do not use the assign_bit() and
> need not change irq_state data type.

Or we can use the correct API and not introduce additional bugs, which
your suggestion above would lead to.

> There are many improvements in my works for drivers/gpio/gpio-sifive.c.
> I hope to check my attached source file.

That's not how we submit patches to the Linux kernel. I suggest you
read the documentation on how to do this.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...