LKML Archive on
 help / color / Atom feed
From: Phil Reid <>
To: Geert Uytterhoeven <>
Cc: Geert Uytterhoeven <>,
	Linus Walleij <>,
	Bartosz Golaszewski <>,
	Alexander Graf <>,
	Peter Maydell <>,
	Paolo Bonzini <>,
	Magnus Damm <>,
	"open list:GPIO SUBSYSTEM" <>,
	QEMU Developers <>,
	Linux-Renesas <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver
Date: Thu, 11 Jul 2019 17:24:40 +0800
Message-ID: <> (raw)
In-Reply-To: <>

On 10/07/2019 18:21, Geert Uytterhoeven wrote:
> Hi Phil,
> On Wed, Jul 10, 2019 at 4:00 AM Phil Reid <> wrote:
>> On 6/07/2019 00:05, Geert Uytterhoeven wrote:
>>> GPIO controllers are exported to userspace using /dev/gpiochip*
>>> character devices.  Access control to these devices is provided by
>>> standard UNIX file system permissions, on an all-or-nothing basis:
>>> either a GPIO controller is accessible for a user, or it is not.
>>> Currently no mechanism exists to control access to individual GPIOs.
>>> Hence add a virtual GPIO driver to aggregate existing GPIOs (up to 32),
>>> and expose them as a new gpiochip.  This is useful for implementing
>>> access control, and assigning a set of GPIOs to a specific user.
>>> Furthermore, it would simplify and harden exporting GPIOs to a virtual
>>> machine, as the VM can just grab the full virtual GPIO controller, and
>>> no longer needs to care about which GPIOs to grab and which not,
>>> reducing the attack surface.
>>> Virtual GPIO controllers are instantiated by writing to the "new_device"
>>> attribute file in sysfs:
>>>       $ echo "<gpiochipA> <gpioA1> [<gpioA2> ...]"
>>>              "[, <gpiochipB> <gpioB1> [<gpioB2> ...]] ...]"
>>>               > /sys/bus/platform/drivers/gpio-virt-agg/new_device
>>> Likewise, virtual GPIO controllers can be destroyed after use:
>>>       $ echo gpio-virt-agg.<N> \
>>>               > /sys/bus/platform/drivers/gpio-virt-agg/delete_device
>> Nice.
>> This provides similar functionality to the "gpio inverter" driver currently on the list.
>> Other than being just a buffer.
> Indeed, both drivers forward GPIO calls, but the gpio inverter modifies
> some parameters passed.
> The way the drivers obtain references to GPIOs is different, though: the
> inverter driver obtains a fixed description from DT, while the virtual
> aggregator receives the description at runtime, from sysfs.
> But perhaps both drivers could share some code?
Other than probing they're almost the same, except the inversion.
This one's more complete for set / get multiple etc.

>> Would it be possible to do the lookup via line names?
> Doesn't the fact that a GPIO has a line name means that it is in use, and
> thus cannot be aggregated and exported to another user?

They can be given line names via the dt property gpio-line-names.
Which can be used by user space to find a gpio. Not sure if there's an equivalent api inkerenl.
But it looks like we can find the info via struct gpiochip_info / gpioline_info linfo and work
out the chip name and line offsets. So probably not required.

Find the right gpio always seems tricky.
We have systems with multiple i2c gpio behind muxes that may or may not be present.
So i2c bus numbers are never consistent. And then different board revisions move the
same gpio line to a different pin (or cahnge the gpio chip type completely) to make routing easier etc.

Phil Reid

  reply index

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-05 16:05 Geert Uytterhoeven
2019-07-08  9:44 ` Bartosz Golaszewski
2019-07-08 10:24   ` Geert Uytterhoeven
2019-07-09 14:58     ` Bartosz Golaszewski
2019-07-09 15:59       ` Geert Uytterhoeven
2019-07-12  9:27         ` Bartosz Golaszewski
2019-09-06 11:14           ` Geert Uytterhoeven
2019-09-06 11:09       ` Geert Uytterhoeven
2019-07-10  2:00 ` Phil Reid
2019-07-10 10:21   ` Geert Uytterhoeven
2019-07-11  9:24     ` Phil Reid [this message]
2019-07-11  9:54       ` Geert Uytterhoeven
2019-08-01  8:41 ` Linus Walleij
2019-08-05 10:21   ` Marc Zyngier
2019-08-05 10:56     ` Linus Walleij
2019-09-12  8:56 ` Linus Walleij
2019-09-12  8:59   ` Geert Uytterhoeven

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 \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

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

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git

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

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone