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

[Rob Herring]

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.

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?

> And for Linux: if nobody is using it ... is that after all deferred probes?
> Someone can load a module using these lines at any time. Etc.
>
> > Please don't use a property called "gpio-line-name" to define a state of
> > a GPIO, it makes no sense. The line-name property of a GPIO hog is the
> > label we assign to the line when requesting it. There's no requesting here
> > so let's just not use any new line names. I'd go with something like:
> >
> > 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.


Rob