Re: [RFC] GPIO User I/O

From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Rodolfo Giometti <giometti@enneenne.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [RFC] GPIO User I/O
Date: Mon, 6 Jul 2020 23:00:48 +0200	[thread overview]
Message-ID: <CAMuHMdUtguuu4FWU4nRS=pBUyEwKM1JZ8DYPdCQHXBYN0i_Frg@mail.gmail.com> (raw)
In-Reply-To: <CACRpkdZPjJSryJc+RtYjRN=X7xKMcao5pYek1fUM2+sE9xgdFQ@mail.gmail.com>

On Mon, Jul 6, 2020 at 10:38 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Mon, Jul 6, 2020 at 5:33 PM Rodolfo Giometti <giometti@enneenne.com> wrote:
> > > With Geert's GPIO aggregator userspace and device tree can conjure
> > > special per-usecase gpio chips as pointed out by Drew: this is
> > > very useful when you want some kernel-managed yet
> > > usecase-specific GPIO lines in a special "container" chip.
> > > To me this is the best of two worlds. (Kernelspace and userspace.)
> >
> > Maybe this is the "best of two worlds" as you say but the problem is that board
> > manufactures need a way to well-define how a GPIO line must be used for within
> > the device-tree and without the need of patches! In this point of view neither
> > the "driver_override" way nor adding a compatible value to
> > gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each
> > board!). That's why at the moment they prefer not specify these GPIO lines at
> > all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it
> > simple...
>
> I think the idea is to add a very generic DT compatible to the
> gpio_aggregator_dt_ids[]. That way, any DT can use the aggregator
> to create a new chip with named lines etc.
>
> But Geert can speak of that.

The idea is to describe the real device in DT, and add it's compatible value
to gpio_aggregator_dt_ids[], or enable support for it dynamically using
driver_override.
The former indeed requires modifying the driver.
Note that if you ever want to write a pure kernelspace driver, you do need
a proper compatible value anyway.

I do agree that it's annoying to have "gpio-leds", but not "gpio-motors"
or "gpio-relays".  However, you can always propose bindings for the
latter, and, when they have been accepted, add those compatible
values to upstream gpio_aggregator_dt_ids[].

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