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: <ecb0e9404a3f6256a7ba1fe48b5a1471@kernel.org>
Date:   Tue, 28 Jan 2020 13:21:00 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Yash Shah <yash.shah@...ive.com>
Cc:     linus.walleij@...aro.org, bgolaszewski@...libre.com,
        palmer@...belt.com, paul.walmsley@...ive.com, wesley@...ive.com,
        atish.patra@....com, linux-gpio@...r.kernel.org,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
        sachin.ghadi@...ive.com
Subject: Re: [PATCH] gpio/sifive: fix static checker warning

On 2020-01-28 05:24, Yash Shah wrote:
> Typcasting "irq_state" leads to the below static checker warning:
> The fix is to declare "irq_state" as unsigned long instead of u32.
> 
> 	drivers/gpio/gpio-sifive.c:97 sifive_gpio_irq_enable()
> 	warn: passing casted pointer '&chip->irq_state' to
> 	'assign_bit()' 32 vs 64.
> 
> Fixes: 96868dce644d ("gpio/sifive: Add GPIO driver for SiFive SoCs")
> Reported-by: Dan Carpenter <dan.carpenter@...cle.com>
> Signed-off-by: Yash Shah <yash.shah@...ive.com>
> ---
>  drivers/gpio/gpio-sifive.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-sifive.c b/drivers/gpio/gpio-sifive.c
> index 147a1bd..c54dd08 100644
> --- a/drivers/gpio/gpio-sifive.c
> +++ b/drivers/gpio/gpio-sifive.c
> @@ -35,7 +35,7 @@ struct sifive_gpio {
>  	void __iomem		*base;
>  	struct gpio_chip	gc;
>  	struct regmap		*regs;
> -	u32			irq_state;
> +	unsigned long		irq_state;
>  	unsigned int		trigger[SIFIVE_GPIO_MAX];
>  	unsigned int		irq_parent[SIFIVE_GPIO_MAX];
>  };
> @@ -94,7 +94,7 @@ static void sifive_gpio_irq_enable(struct irq_data 
> *d)
>  	spin_unlock_irqrestore(&gc->bgpio_lock, flags);
> 
>  	/* Enable interrupts */
> -	assign_bit(offset, (unsigned long *)&chip->irq_state, 1);
> +	assign_bit(offset, &chip->irq_state, 1);
>  	sifive_gpio_set_ie(chip, offset);
>  }
> 
> @@ -104,7 +104,7 @@ static void sifive_gpio_irq_disable(struct irq_data 
> *d)
>  	struct sifive_gpio *chip = gpiochip_get_data(gc);
>  	int offset = irqd_to_hwirq(d) % SIFIVE_GPIO_MAX;
> 
> -	assign_bit(offset, (unsigned long *)&chip->irq_state, 0);
> +	assign_bit(offset, &chip->irq_state, 0);
>  	sifive_gpio_set_ie(chip, offset);
>  	irq_chip_disable_parent(d);
>  }

Yup, nice one. Should have spotted it.

Reviewed-by: Marc Zyngier <maz@...nel.org>

Linus, do you want me to queue this via the irqchip tree (given that
it is where the original bug came from)? Or would you rather take it?

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