Linux-GPIO Archive on
 help / color / Atom feed
From: Linus Walleij <>
To: Bartosz Golaszewski <>
Cc: Drew Fustini <>,
	"open list:GPIO SUBSYSTEM" <>,
	Thomas Petazzoni <>
Subject: Re: [RFC] gpio: expose pull-up/pull-down line flags to userspace
Date: Thu, 3 Oct 2019 14:47:41 +0200
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Sep 23, 2019 at 10:38 AM Bartosz Golaszewski <> wrote:

> I remember discussing it with Linus some time ago. This may not be as
> straightforward as simply adding new flags. Since PULL-UP/DOWN
> resistors can - among other parameters - also have configurable
> resistance, we'll probably need some kind of a structure for this
> ioctl() to pass any additional information to the kernel. Since we
> can't change ABI this may require adding a whole new ioctl() for
> extended configuration. This in turn has to be as future-proof as
> possible - if someone asks for user-space-configurable drive-strength,
> the new ioctl() should be ready for it.
> I should have some bandwidth in the coming days, so I'll try to give it a try.

What we did for the in-kernel API and the Device Tree ABI
was to simply say that if you need such elaborate control over
the line, it needs to be done with a proper pin control driver.

So for lines that just have the GPIO_PULL_UP or
GPIO_PULL_DOWN set as a (one-bit) flag, what you will
get is "typical" pull down/up (whatever the hardware default
is, or what the driver thinks is default, which should be safe
so the highest possible pull resistance I suppose).

So one option is to just go with these flags and explicitly
say that it will give a "system default (high resistance)
pull up/down".

That said, the pin controller back-end is fully capable of
accepting more elaborate configuration, so if we prefer then
we can make the more complex userspace ABI that can
set it to a desired-or-default resistance.

I lean toward simplicity here. I haven't seen that these
userspace consumers need very elaborate control of this
resistance, they are for one-off hacks and as such should
be fine with just default pull up/down I think?

I  think that specifying "this line will use pull up/down"
at request time and having the driver set a safe default
pull-up/down as response, (and pretty much what this
patch does) and then add another explicit
ioctl to refine it the day we need it is a viable way forward.

 in the future something like:

And then, when we need it, try to come up with some
really flexible ABI for the config, based on

But no upfront code for that right now as it is not needed.
A practical usecase must come first.

Linus Walleij

  parent reply index

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-21 10:25 Drew Fustini
2019-09-23  8:38 ` Bartosz Golaszewski
2019-10-02 11:10   ` Drew Fustini
2019-10-03 12:47   ` Linus Walleij [this message]
2019-10-04  7:22     ` Bartosz Golaszewski
2019-10-04 12:46       ` Bartosz Golaszewski
2019-10-05 17:02       ` Linus Walleij
2019-10-06  3:12         ` Kent Gibson
2019-10-06 21:06           ` Linus Walleij
2019-10-07  4:37             ` Kent Gibson
2019-10-08  6:15 ` Kent Gibson
2019-10-08 20:56   ` Bartosz Golaszewski
2019-10-08 23:21     ` Kent Gibson
2019-10-08 23:30       ` Bartosz Golaszewski
2019-10-08 23:56         ` Kent Gibson
2019-10-09  0:03           ` Bartosz Golaszewski
2019-10-09  0:22             ` Kent Gibson
2019-10-09  6:55               ` Kent Gibson
2019-10-09 12:57                 ` Drew Fustini
2019-10-09 13:23                   ` Kent Gibson
2019-10-09 13:30                 ` Drew Fustini
2019-10-09 14:11                   ` Kent Gibson
2019-10-09 15:50                     ` Bartosz Golaszewski
2019-10-09 16:19                       ` Kent Gibson
2019-10-09 23:59                   ` Kent Gibson
2019-10-10  7:47                     ` Drew Fustini
2019-10-10 10:14                       ` Kent Gibson
2019-10-10 11:17                         ` Kent Gibson
2019-10-11 13:04                           ` Drew Fustini
2019-10-11 13:06                         ` Drew Fustini
2019-10-11 13:49                           ` Kent Gibson
2019-10-09 11:32               ` Drew Fustini
2019-10-09 13:57       ` Drew Fustini
2019-10-09 14:01         ` Kent Gibson
2019-10-09 11:46   ` Drew Fustini

Reply instructions:

You may reply publically 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 \ \ \ \ \ \ \

* 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