Re: [PATCH v2 1/1] gpiolib: of: add gpio-line node support

[James Hilliard]

On Tue, Feb 17, 2026 at 6:18 AM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
>
> On Mon, 16 Feb 2026 22:20:10 +0100, James Hilliard
> <james.hilliard1@xxxxxxxxx> said:
> > On Mon, Feb 16, 2026 at 4:38 AM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
> >>
> >> On Sat, 14 Feb 2026 22:32:37 +0100, James Hilliard
> >> <james.hilliard1@xxxxxxxxx> said:
> >> > Allow GPIO controller child nodes marked with "gpio-line" to
> >> > configure direction/flags at probe time without hogging the line.
> >> >
> >> > Teach OF gpiochip scanning and OF dynamic reconfiguration handlers to
> >> > process gpio-line nodes in addition to gpio-hog nodes.
> >> >
> >> > Also parse "gpio-line-name" and apply it to desc->name. For gpio-hog
> >> > nodes, keep "line-name" semantics as the hog consumer label.
> >> >
> >>
> >> One important thing that's missing from this commit description is: what is
> >> the use-case and why do you need this.
> >
> > Added some more use-case details in v3:
> > https://lore.kernel.org/all/20260216211021.3019827-1-james.hilliard1@xxxxxxxxx/
> >
> > In my case I'm setting up the GPIO line initial state and names for
> > userspace consumers mostly. I want to be able to configure the
> > individual line names from a combination of the dts file and multiple
> > dtso files for the same gpiochip along with setting up an initial state
> > before userspace consumers operate on the lines.
> >
> >> The DT binding patch should be sent together with this in a single series. It
> >> should also be documented in the relevant .rst file.
> >
> > Which file would that be?
> >
>
> Documentation/driver-api/gpio/board.rst would fit best.

Should gpio-hog docs be moved here as well?

>
> > I had previously added docs to gpio.txt but was told here to just
> > drop the docs:
> > https://lore.kernel.org/all/b851bfd4-3c35-489f-a32d-dcd7a37ca99a@xxxxxxxxxx/
> >
>
> There's a difference between device-tree bindings (formal, machine-readable
> definition of the firmware ABI) under Documentation/devicetree/bindings/ and
> documentation for humans residing elsewhere in Documentation/. Make sure to
> not confuse the two. I would expect both to be supplied with such a change.

What file under bindings would this go in?

>
> >> I suppose it's another shot at defining what we previously called
> >> "initial-line-state", "default-line-state", etc. What happens when someone
> >> requests the line, reconfigures it and then releases it?
> >
> > This should just provide an initial configuration, subsequent consumers
> > would override whatever is set here AFAIU.
> >
>
> Yeah, that's what I was afraid of. This is not hardware description, this is
> user-convencience and as such I don't think it has place in DT bindings and -
> by extension - in DTS.

I guess this is more describing a hardware configuration, but is that
not allowed in DT bindings? There seems to be plenty of DT stuff
that's effectively describing the way the hardware should be configured
initially.

For example uart/serial nodes have a current-speed property that
can be used to configure the initial speed, but this can also be
overridden by userspace consumers at runtime as well via
termios configurations AFAIU. That seems to be a pretty similar
case to what I'm trying to do here with gpios.

What's the reason user-convenience hardware configuration stuff
like this shouldn't go in DT bindings?

> I'm afraid I don't have good alternatives to offer, solving this has been
> attempted several times in the past without success. Even gpio-hog would likely
> not get past DT maintainer review these days but it's ABI now so will stay
> supported.

What did previous attempts look like? At least this is minimally invasive
and shares most of the code paths with gpio-hog.

> How early do you need to set these settings?

Well, before userspace applications can interact with the gpio lines I
suppose. Essentially so that it acts as a failsafe configuration in case
the userspace app doesn't get started for whatever reason as well as
giving some initial starting configuration for a userspace app to act
upon.