On Mon, Jan 4, 2016 at 10:41 AM, Jean Delvare [off-list ref] wrote:

On Tue, 22 Dec 2015 15:20:54 +0100, Linus Walleij wrote:

quoted

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: Thierry Reding <redacted>
Cc: Daniel Krueger <redacted>
Cc: Jean Delvare <redacted>
Signed-off-by: Linus Walleij <redacted>
---
 drivers/gpio/gpio-pch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c
index af0715f8524b..8c45b74dcf21 100644
--- a/drivers/gpio/gpio-pch.c
+++ b/drivers/gpio/gpio-pch.c

@@ -127,7 +127,7 @@ static int pch_gpio_get(struct gpio_chip *gpio, unsigned nr)
 {
      struct pch_gpio *chip = container_of(gpio, struct pch_gpio, gpio);

-     return ioread32(&chip->reg->pi) & (1 << nr);
+     return !!(ioread32(&chip->reg->pi) & (1 << nr));
 }

 static int pch_gpio_direction_output(struct gpio_chip *gpio, unsigned nr,

I would prefer:

        return (ioread32(&chip->reg->pi) >> nr) & 1;

which is faster for the same result.

At x86 assembly level, your approach requires 5 CPU instructions (mov,
shl, test, setne and movzbl), mine only 2 CPU instructions (shr and
and.)

I was mainly going over and fixing all drivers with the simplest
pattern I can think of, already merged this as it was a regression
basically, but a patch based on my GPIO devel branch or Linux-next
to fix it the way you want it would be
appreciated.

Yours,
Linus Walleij