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

[Linus Walleij]

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

Maybe it's a bit of a game of definitions here.

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.

(I might not be entirely consistent in my reviews today,
it's mostly because I realize I'm wrong on some details.)

Yours,
Linus Walleij