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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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.

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.

What kind of consumers do you have in mind for this
feature?

Yours,
Linus Walleij



[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux