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