Re: [PATCH V1 1/2] gpio: make it possible to set active-state on GPIO lines

[Harish Jenny K N <harish_kandiga@xxxxxxxxxx>]

Hi,

On 06/05/19 12:27 PM, Linus Walleij wrote:
> Hi Harish,
>
> thank you for your patch!
>
> On Mon, May 6, 2019 at 8:02 AM Harish Jenny K N
> <harish_kandiga@xxxxxxxxxx> wrote:
>
>> Device could decide to have different convention about what "active" means.
>> ( i.e Active-High (output signal "1" means "active", the default)
>> and Active-Low (output signal "0" means "active")).
>> Therefore it is possible to define a GPIO as being either active-high or
>> active-low .
>>
>> Make it possible to add the information of active state of gpio pin
>> as property into device tree configuration using a
>> "active-state" property u8 array.
>>
>> This is useful for user space applications to identify
>> active state of pins.
>>
>> This commit updates gpio_desc flag for active-state.
>>
>> Note: The active-state attribute is completely optional.
>>
>> example device tree line
>> "active-state = /bits/ 8 <0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0>;"
>>
>> Signed-off-by: Harish Jenny K N <harish_kandiga@xxxxxxxxxx>
> I see from the code that the intention of the code is to
> encode on the producer side (the GPIO chip) whether to handle
> a certain line with active high or active low semantics.
> In effect setting FLAG_ACTIVE_LOW on some descriptors.
>
> The usual convention is to refer to this as "polarity" so
> you would probably want to name it "polarity" rather than
> "active-state".

I agree. Thanks.

>
> However:
>
> This is problematic because the convention in the device
> tree is to encode this on the consumer side and not on
> the producer side, so e.g. a device node using a GPIO
> line will use something like this:
>
>                 button@1 {
>                         debounce-interval = <50>;
>                         wakeup-source;
>                         linux,code = <2>;
>                         label = "userpb";
>                         gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
>                 };
>
> If the polarity differs between the consumer and the
> producer, who is going to win? Defining polarity on both
> sides is going to lead to ambiguities.
Can the userspace consumers define the polarity?

Intention was to define polarity for lines which are not having consumers from kernelspace. But yes, there is a possibility of ambiguity if both consumer and producer start defining polarity. But again both consumer and producer should define the same polarity in device tree.
>
> Even when using GPIOs from userspace (which I do not
> recommend) the character device suppors a polarity flag
> GPIOLINE_FLAG_ACTIVE_LOW so also userspace
> consumers define polarity.
yes. aware of the GPIOLINE_FLAG_ACTIVE_LOW flag to get the status.
> What kind of consumers do you have in mind for this
> feature?
Intention is to make it generic. Some pins in hardware be configured as active low, this can vary between hardware samples. User application uses gpio-line-name property to map pins and port, this helps the application to handle pin change from hardware sample to sample. As of now there is no configuration available for user space applications for polarity.


Thanks,

Harish