On Wed, Feb 5, 2014 at 10:06 PM, Linus Walleij <[email protected]> wrote:
> On Wed, Feb 5, 2014 at 2:54 AM, Alexandre Courbot <[email protected]> wrote:
>> On Sun, Feb 2, 2014 at 8:35 AM, Evgeny Boger <[email protected]> wrote:
>>> Hello,
>>>
>>> I'm now getting non-boolean values from gpio sysfs interface on 3.13, like
>>> this
>
> You didn't get this before?
>
>> This seems wrong to me, a GPIO should always be 0 or 1.
>
> Yup.
>
>> As it turns out, bgpio_get() does the following:
>>
>>     return bgc->read_reg(bgc->reg_dat) & bgc->pin2mask(bgc, gpio);
>
> OK lemme patch this.
>
>> 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?
>
> We can clamp the returned value in gpiod_get_value() for sure.
>
> Maybe we should even print a warning there if the driver returns
> anything other that 0,1.
>
> Maybe we should even retype the function to a bool, atleast in
> the driver-facing API.

Agree with the bool retyping, and while we are at it let's also change
the driver function's prototype. That's probably the shortest way to
fix this (yay to implicit type conversion!) and to make sure this
problem isn't reintroduced in the future.

Shall I make a patch for this? It will change every driver around, but
shouldn't be too intrusive.

Alex.
--
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

Reply via email to