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

[Rob Herring]

On Wed, Feb 18, 2026 at 3:34 AM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
>
> 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...

Most or all of it can be deleted. The same text exists in dtschema
gpio.yaml already. There might have been some parts not moved yet as I
didn't have rights to dual license.

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

No, configuration is allowed. The oldest example is probably uart baud
rate. pinctrl is completely the configuration of pins. But there is a
limit and it's a judgment call.

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

Agreed.

> Right
> now this is something driver-specific. I'll let DT maintainers speak
> if that's something we could put into DT.

If the argument was wanting to do this in early boot firmware, I'd be
more convinced. But to say it is needed for userspace, I'm not really
convinced. My main concern is wanting to describe the state, but not
what the GPIOs are connected to. Is it really nothing and we'd never
ever possibly want to describe that.

Rob