Linux-GPIO Archive on
 help / color / Atom feed
From: Geert Uytterhoeven <>
To: Eugeniu Rosca <>
Cc: Linus Walleij <>,
	Harish Jenny K N <>,
	Rob Herring <>,
	Mark Rutland <>,
	Bartosz Golaszewski <>,
	Balasubramani Vivekanandan 
	Laurent Pinchart <>,
	Stephen Warren <>,
	Stephen Warren <>,
	Phil Reid <>,
	Enrico Weigelt <>,
	"open list:GPIO SUBSYSTEM" <>,
	Eugeniu Rosca <>
Subject: Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings
Date: Fri, 27 Sep 2019 11:07:20 +0200
Message-ID: <> (raw)
In-Reply-To: <>

Hi Eugeniu,

On Wed, Sep 25, 2019 at 6:51 PM Eugeniu Rosca <> wrote:
> I've additionally Cc-ed Laurent and Stephen, since their fruitful
> discussion in [1] back in 2014 concluded with a useful documentation
> update [2] which is precisely related to the interpretation and usage
> of the polarity flag in GPIO specifiers.
> I've also Cc-ed those people who have participated in reviewing the
> previous patch iterations (Geert, Phil, Enrico).
> Before leaving this thread in limbo, I would like to attempt clarifying
> what it actually tried to accomplish, one more time.
> First of all, it stems from the need to implement a specific customer
> requirement. Whether this requirement is sane or not, that's actually
> a very important question, but I haven't found much discussion around
> it the comments posted so far.
> To paraphrase what Harish stated in [3], the customer has a list of GPIO
> pins which need to be controlled from userspace. Of course, the customer
> can set the polarity of those pins from userspace, as pointed out by
> Linus in [4] (thanks!). But, keeping track of GPIO polarity in userspace
> is seen like a burden. The customer thinks that the right place for this
> HW-specific detail is in device trees. Do you think this preference
> is ill-formed?
> If we hog a GPIO pin in DTS (which allows specifying its polarity),
> userspace no longer has access to that pin. There isn't a way to define
> GPIO polarity by means of DTS without affecting userspace access
> (can anybody contradict this statement?).
> Whether it is obvious or not, the main goal of this series is actually
> to provide the possibility of inverting the default ACTIVE_HIGH polarity
> for GPIO pin X _via DTS_ while still allowing to operate on that pin
> _from userspace_. My two questions are then:
>  - I hope it is something sane to desire?
>  - If it is sane, how can this be accomplished, if the functionality
>    implemented by Harish doesn't pass the community review?
> [1] ("Correct meaning of the GPIO active low flag")
> [2] ("gpio: document polarity flag best practices")
> [3] ("[PATCH V1 1/2] gpio: make it possible to set active-state on GPIO lines")
> [4] ("[PATCH V1 1/2] gpio: make it possible to set active-state on GPIO lines")

My standard reply would be: describe the device connected to the GPIO(s)
in DT.  The GPIO line polarities are specified in the device's "gpios"

BTW, can you give an example of what's actually connected to those
Is it a complex device (the GPIO is only a part of it, it's also hanging
off e.g. an I2C bus)?
Is it something simple (e.g. an LED ("gpio-leds"), relay, or actuator)?

Next step would be to use the device from Linux.  For that to work, you
need a dedicated driver (for the complex case), or something generic
(for the simple case).
The latter is not unlike e.g. spidev.  Once you have a generic driver,
you can use "driver_override" in sysfs to bind the generic driver to
your device.  See e.g. commit 5039563e7c25eccd ("spi: Add
driver_override SPI device attribute").

Currently we don't have a "generic" driver for GPIOs. We do have the
GPIO chardev interface, which exports a full gpio_chip.
It indeed looks like this "gpio-inverter" could be used as a generic
driver.  But it is limited to GPIOs that are inverted, which rules out
some use cases.

So what about making it more generic, and dropping the "inverter" from
its name, and the "inverted" from the "inverted-gpios" property? After
all the inversion can be specified by the polarity of the GPIO cells in
the "gpios" property, and the GPIO core will take care of it[*]?
Which boils down to adding a simple DT interface to my gpio-aggregator
("[PATCH/RFC v2 0/5] gpio: Add GPIO Aggregator Driver",
And now I have realized[*], we probably no longer need the GPIO
Forwarder Helper, as there is no need to add inversion on top.



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  parent reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28  9:30 Harish Jenny K N
2019-07-04  5:01 ` Harish Jenny K N
2019-07-08 22:36 ` Rob Herring
2019-07-09  5:25   ` Harish Jenny K N
2019-07-09 16:08     ` Rob Herring
2019-07-10  8:28       ` Harish Jenny K N
2019-07-17 13:51         ` Harish Jenny K N
2019-07-29 11:07           ` Harish Jenny K N
2019-08-05 11:15         ` Linus Walleij
2019-08-09 14:08           ` Rob Herring
2019-08-10  8:51             ` Linus Walleij
2019-08-19  9:36               ` Harish Jenny K N
2019-08-27  7:47                 ` Harish Jenny K N
2019-08-30  5:21                   ` Harish Jenny K N
2019-09-04  4:58                     ` Harish Jenny K N
2019-09-10  7:47                       ` Rob Herring
2019-09-11 12:52                         ` Harish Jenny K N
2019-09-25 16:51 ` Eugeniu Rosca
2019-09-27  5:52   ` Phil Reid
2019-09-27  9:07   ` Geert Uytterhoeven [this message]
2019-10-05 13:07     ` Eugeniu Rosca
2019-10-07  8:18       ` Geert Uytterhoeven
2019-10-11  4:35         ` Harish Jenny K N
2019-11-12 11:52           ` Harish Jenny K N
2019-11-12 12:19             ` Geert Uytterhoeven
2019-10-04 19:07   ` Stephen Warren
2019-10-05 17:50     ` Eugeniu Rosca
2019-10-07 15:36       ` Stephen Warren
  -- strict thread matches above, loose matches on Subject: below --
2019-06-28  5:20 [PATCH V4 0/2] Add Inverter controller for gpio configuration Harish Jenny K N
2019-06-28  5:20 ` [PATCH V4 2/2] gpio: inverter: document the inverter bindings Harish Jenny K N

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-GPIO Archive on

Archives are clonable:
	git clone --mirror linux-gpio/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-gpio linux-gpio/ \
	public-inbox-index linux-gpio

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone