On Sun, Feb 2, 2014 at 8:35 AM, Evgeny Boger <bo...@contactless.ru> wrote:
> Hello,
>
> I'm now getting non-boolean values from gpio sysfs interface on 3.13, like
> this
>
> root@wirenboard:~# cat /sys/class/gpio/gpio16/value
> 65536
>
> (I'm working with imx23 soc which is handled by gpio-generic.c driver)
>
> Looks like these weird non-boolean values appeared after this commit:
> https://github.com/torvalds/linux/commit/79a9becda8940deb2274b5aa4577c86d52ee7ecb
> .
>
>
> 1) Is it an expected behavior or not?
This seems wrong to me, a GPIO should always be 0 or 1.
> 2) If it's not the case, which one of these should be fixed?
> a) bgpio_get in gpio-generic.c to return only boolean values
> or
> b) gpio_value_show so only the sysfs interface will be affected
> or
> c) gpiod_get_value and gpiod_get_value_cansleep functions
>From what I understand of gpio-generic, this driver uses simple
register accesses and a bitmask to set/read GPIOs. Interestingly you
are accessing GPIO 16, and the value returned is 65536, which happens
to be (1 << 16).
As it turns out, bgpio_get() does the following:
return bgc->read_reg(bgc->reg_dat) & bgc->pin2mask(bgc, gpio);
So it seems like this is where your unexpected value comes from. As
for where to fix it, the GPIO driver should return the value of the
GPIO itself, and not some mask that indicates how it handles GPIOs
internally. But I suppose it would also be nice to make
gpiod_get_value*() more consistent so the whole subsystem gets fixed
in one shot (I suspect a few other drivers are doing the same). I
mean, we never expect a GPIO to be something else than 0 or 1, do we?
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
