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

[Bartosz Golaszewski]

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

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:

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;
	};
};

Bartosz