linux-renesas-soc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
	Linus Walleij <linus.walleij@linaro.org>,
	Alexander Graf <agraf@suse.de>,
	Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Magnus Damm <magnus.damm@gmail.com>,
	linux-gpio <linux-gpio@vger.kernel.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver
Date: Fri, 12 Jul 2019 11:27:43 +0200	[thread overview]
Message-ID: <CAMpxmJXCYeGjCu_PhCPffZQZ+ST9YCp27-PTHfL2SJ0Bh8SJFQ@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdUkF32+wOLkfd2BL4h-=0nZjPDMtVOpOcyDYzBbhWXteQ@mail.gmail.com>

wt., 9 lip 2019 o 17:59 Geert Uytterhoeven <geert@linux-m68k.org> napisał(a):
>
> Hi Bartosz,
>
> On Tue, Jul 9, 2019 at 4:59 PM Bartosz Golaszewski
> <bgolaszewski@baylibre.com> wrote:
> > pon., 8 lip 2019 o 12:24 Geert Uytterhoeven <geert@linux-m68k.org> napisał(a):
> > > On Mon, Jul 8, 2019 at 11:45 AM Bartosz Golaszewski
> > > <bgolaszewski@baylibre.com> wrote:
> > > > pt., 5 lip 2019 o 18:05 Geert Uytterhoeven <geert+renesas@glider.be> napisał(a):
> > > > > 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
>
> > Am I doing it right? I'm trying to create a device and am only getting this:
> >
> > # echo gpiochip2 23 > new_device
> > [  707.507039] gpio-virt-agg gpio-virt-agg.0: Cannot find gpiochip gpiochip2
> >
> > gpiochip2 *does* exist in the system.
>
> Please try the name of the platform device instead.
> I.e. for my koelsch (R-Car M2-W), it needs "e6052000.gpio" instead
> of "gpiochip2".
>
> Probably the driver should match on both.
>
> > I see. I'll try to review it more thoroughly once I get to play with
> > it. So far I'm stuck on creating the virtual chip.
>
> Thanks, good luck!
>

This is not a show-stopper but one thing that's bothering me in this
is that lines used by the aggregator are considered 'used' in regard
to the original chip. I'm wondering how much effort would it take to
have them be 'muxed' into two (real and virtual) chips at once.

Other than that - seems to works pretty nice other than the matching
by chip name and by line names.

Bart

> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> 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

  reply	other threads:[~2019-07-12  9:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-05 16:05 [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver 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 [this message]
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
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=CAMpxmJXCYeGjCu_PhCPffZQZ+ST9YCp27-PTHfL2SJ0Bh8SJFQ@mail.gmail.com \
    --to=bgolaszewski@baylibre.com \
    --cc=agraf@suse.de \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).