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

[James Hilliard]

On Thu, Feb 19, 2026 at 2:15 AM Bartosz Golaszewski <brgl@xxxxxxxxxx> wrote:
>
> On Thu, Feb 19, 2026 at 12:56 AM James Hilliard
> <james.hilliard1@xxxxxxxxx> wrote:
> >
> > Well the gpio-line-name property for the individual lines is a way of
> > describing what the GPIOs are connected to in a way that userspace
>
> That is hardware description plain and simple.
>
> > can understand, at least that's one of the motivations for this change
> > along with setting up the initial line state. I would probably also add
>
> That is not.
>
> > gpio-line support to u-boot so that initial state is configured prior to
> > the kernel taking over as well.
> >
>
> 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".

Other than the name would the existing code here be essentially the
same for setting default state vs the initial state? If a userspace
consumer attaches then detaches from the line would the state retain
the last state set by the userspace consumer or would it revert to the
default state somehow?

I'm not sure calling it "default-state" is the best option however as this
was also designed to be able to usable for simply setting individual
line "gpio-line-names" name equivalents without altering the default line
state at all.

For example it should allow for simply naming individual lines by doing
something like this(i.e. not setting the line "output-high" or similar
properties) without affecting initial/default line state:
line_c-init {
    gpio-line;
    gpios = <7 0>;
    gpio-line-name = "foo-baz-gpio";
};

>
> To that end: we need DT bindings and I'd say: start with an RFC bindings patch
> even without code, see where it gets us.
>
> > Some of the GPIOs have kernel driver consumers and some have
> > userspace consumers but it would be kinda nice to have a way to
> > name them all without the limitations of the gpio-line-names which
> > isn't really capable of operating on individual lines.
>
> 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:

So "gpio-line-name" is not the consumer, I added it to gpio-hog as well
to allow for configuring "gpio-line-names" equivalent names but for the
individual lines, something that's not currently supported with the array
based "gpio-line-names" property.

>
> gpio@1 {
>         compatible = "foo,bar";
>         reg = <0x1>;
>         gpio-controller;
>         #gpio-cells = <2>;
>
>         gpio-line-names = "foo", "bar", "", "xyz";

This way of defining "gpio-line-names" doesn't allow for defining individual
line names, which is problematic for cases where one wants names to
come from multiple dts/dtso files as array properties like these can only
come from one dts/dtso file at a time(i.e. doesn't allow for combining line
names from multiple sources).

>
>         foo-gpio {
>                 default-state;
>                 gpios = <3 GPIO_ACTIVE_LOW>;
>                 output-high;
>         };
> };
>
> Bartosz