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

[Bartosz Golaszewski]

On Tue, Feb 17, 2026 at 8:07 PM James Hilliard
<james.hilliard1@xxxxxxxxx> wrote:
>
> 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?
>

Not moved from DT bindings, just added as they are missing.

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

Typically the top-level GPIO bindings document but we don't have it
yet. Or rather: we have the old .txt format and not yaml. I need to
start chipping away at it at some point...

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

We do have many cases like that back from before DT schema and
validation. Bindings have become much stricter since and it's assumed
that DTS should only describe hardware, not its configuration.

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

They focused more on the "default" state of GPIOs. State to which you
would revert if not requested. If anything: this makes more sense than
"initial" state to me which we forget after the first request. Right
now this is something driver-specific. I'll let DT maintainers speak
if that's something we could put into DT.

Bart

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