On Thu, May 18, 2017 at 8:20 AM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > On 2017-05-13 15:36, Andy Shevchenko wrote: >> On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: >>> First, the logic for translating a register bit to the return code of >>> exar_get_direction and exar_get_value were wrong. And second, there was >>> a flip regarding the register bank in exar_get_direction. >> >> Again, I wish it was tested in the first place. >> >> After addressing below: >> FWIW: >> Reviewed-by: Andy Shevchenko <andy.shevchenko@xxxxxxxxx> >> >>> @@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg) >>> value = readb(exar_gpio->regs + reg); >>> mutex_unlock(&exar_gpio->lock); >>> >>> - return !!value; >>> + return value; >> >> This one is correct. >> >>> @@ -80,7 +80,7 @@ static int exar_get_direction(struct gpio_chip *chip, unsigned int offset) >>> addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO; >>> val = exar_get(chip, addr) >> (offset % 8); >>> >>> - return !!val; >>> + return val & 1; >> >> It should be rather >> >> val = exar_get(chip, addr) & BIT(offset % 8); > > That won't give us 0 or 1 as return value, thus would be incorrect. Full picture: val = exar_get(chip, addr) & BIT(offset % 8); return !!val; How it could be non-(1 or 0)? -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html