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

[Linus Walleij]

[CC Conor as inofficial DT+pinctrl expert]

On Thu, Feb 19, 2026 at 10:34 PM Rob Herring <robh@xxxxxxxxxx> wrote:
> On Thu, Feb 19, 2026 at 12:23 PM Linus Walleij <linusw@xxxxxxxxxx> wrote:
> > On Thu, Feb 19, 2026 at 10:15 AM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
> >
> > > The problem here is that the state of a GPIO that's not requested is considered
> > > "undefined" and controlled by the GPIO chip driver. The whole "initial state"
> > > sounds very hacky. You would have a much better case if you instead worked on
> > > a "default state". It seems Rob is not entirely against it. Neither am I. It
> > > would make sense to tell the GPIO driver: "if nobody's using it, do this".
> >
> > Pin control actually has both initial state and default state...
>
> I'm drawing a blank on how we define initial states.
>
> >
> > Maybe it's a bit of a game of definitions here.
>
> Default here means when no one is using it. Default for pinctrl is in
> use for normal operation.

Indeed.

> But I do wonder how pinctrl and GPIO would interact here as you can't
> set a GPIO state with GPIO alone. First, pinctrl might need to be
> setup to put a pin into GPIO mode. And what about non-GPIOs that also
> need some initial and default state.
>
> Are folks putting pinctrl properties in hog nodes?

Yes sometimes in to pinctrl hogs. It's a bit messy so I wouldn't
recommend it.

If there is a device using pin control it is handled
orthogonally from GPIO, just like any other resource.
Sometimes this is affecting the same electronics: e.g. pin control
sets up the muxing and GPIO sets up the polarity of the
same electrical pad/pin.

One way is to associate a bunch of pin control
settings with the GPIO device itself, since it is a device after
all. There all the GPIOs can be set up as a default state of
the pin controller itself, there is no restriction on what the
pin control state can affect, all say 100 pins in a GPIO
block can be configured into a single pin control state
node.

This is necessary for example if the SoC has muxes
that will affect an array of pins and not just one pin per
mux setting.

> > > gpio@1 {
> > >         compatible = "foo,bar";
> > >         reg = <0x1>;
> > >         gpio-controller;
> > >         #gpio-cells = <2>;
> > >
> > >         gpio-line-names = "foo", "bar", "", "xyz";
> > >
> > >         foo-gpio {
> > >                 default-state;
> > >                 gpios = <3 GPIO_ACTIVE_LOW>;
> > >                 output-high;
> > >         };
> > > };
> >
> > And that makes the name of line 3 "foo".
> >
> > Fair enough, I didn't think of that. This is a good pattern,
> > whether default-state or initial-state.
>
> That makes the node name important (aka ABI) which we generally try to
> avoid. That also collides with the existing foo-gpio(s) properties.
>
> If you are doing all this in early boot, then we're taking something
> that's just stuff some number of GPIO direction and data registers
> with fixed values to parsing lots of nodes and multiple properties in
> those nodes. And early (even u-boot which isn't early anymore) boot
> code just parses the FDT as-is which isn't very efficient. Size and
> processing time (single core, possibly disabled caches) are important
> for boot code. So again, I'm not interested in any binding that can't
> support that use case.

There are some custom precedents, or uh oh we actually merged
something that looks really generic....
Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml

  lines-initial-states:
    $ref: /schemas/types.yaml#/definitions/uint32
    description:
      Bitmask that specifies the initial state of each line.
      When a bit is set to zero, the corresponding line will be initialized to
      the input (pulled-up) state.
      When the  bit is set to one, the line will be initialized to the
      low-level output state.
      If the property is not specified all lines will be initialized to the
      input state.

c.f. arch/arm/boot/dts/nxp/imx/imx6-logicpd-baseboard.dtsi:

        pcf8575: gpio@20 {
(...)
                lines-initial-states = <0x0710>;
(...)
        };

This was there since ancient text bindings times.

So that solves part of the problem if we only want to configure
input/output, we could use this. I don't know if it's a good
precedent. It does seem to fit nicely with really early dead simple
parsing.

Yours,
Linus Walleij