----- Original Message -----
> From: "Linus Walleij" <[email protected]>
> Sent: Tuesday, December 22, 2015 8:11:33 AM
>
> As we want gpio_chip .get() calls to be able to return negative
> error codes and propagate to drivers, we need to go over all
> drivers and make sure their return values are clamped to [0,1].
> We do this by using the ret = !!(val) design pattern.
>
> Cc: Aaron Sierra <[email protected]>
> Signed-off-by: Linus Walleij <[email protected]>
> ---
> drivers/gpio/gpio-ich.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-ich.c b/drivers/gpio/gpio-ich.c
> index 8623d12e23c1..68e525a3cea3 100644
> --- a/drivers/gpio/gpio-ich.c
> +++ b/drivers/gpio/gpio-ich.c
> @@ -236,9 +236,9 @@ static int ich6_gpio_get(struct gpio_chip *chip, unsigned
> nr)
>
> spin_unlock_irqrestore(&ichx_priv.lock, flags);
>
> - return (data >> 16) & (1 << nr) ? 1 : 0;
> + return !!((data >> 16) & (1 << nr));
Linus,
Is this particular change done to simplify verification via Coccinelle?
Otherwise,
this value is already clamped to 0/1.
> } else {
> - return ichx_gpio_get(chip, nr);
> + return !!ichx_gpio_get(chip, nr);
The current definition of ichx_gpio_get() is just a wrapper for
ichx_read_bit(), which clamps the return value to 0 and 1.
Suppose there were an opportunity to catch an error with these GPIOs. In that
case, ichx_gpio_get() would be the best candidate to return an error code. I
think this particular change should be dropped.
> }
> }
-Aaron S.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
