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

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

[James Hilliard]

Allow GPIO controller child nodes marked with "gpio-line" to
configure direction/flags at probe time without hogging the line.

Teach OF gpiochip scanning and OF dynamic reconfiguration handlers to
process gpio-line nodes in addition to gpio-hog nodes.

Also parse "gpio-line-name" and apply it to desc->name. For gpio-hog
nodes, keep "line-name" semantics as the hog consumer label.

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
Depends on:
  - https://github.com/devicetree-org/dt-schema/pull/185

Changes v1 -> v2:
  - drop documentation changes
  - add depends on to changelog
---
 drivers/gpio/gpiolib-of.c     | 89 ++++++++++++++++++++++++++++-------
 drivers/gpio/gpiolib-shared.c |  7 +--
 drivers/of/property.c         |  7 +--
 scripts/dtc/checks.c          |  4 +-
 4 files changed, 82 insertions(+), 25 deletions(-)

diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index ef1ac68b94b7..b10a21a63d46 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -744,6 +744,7 @@ struct gpio_desc *of_find_gpio(struct device_node *np, const char *con_id,
  * @lflags:	bitmask of gpio_lookup_flags GPIO_* values - returned from
  *		of_find_gpio() or of_parse_own_gpio()
  * @dflags:	gpiod_flags - optional GPIO initialization flags
+ * @hog:	indicates if this is a gpio-hog node
  *
  * Returns:
  * GPIO descriptor to use with Linux GPIO API, or one of the errno
@@ -753,11 +754,13 @@ static struct gpio_desc *of_parse_own_gpio(struct device_node *np,
 					   struct gpio_chip *chip,
 					   unsigned int idx, const char **name,
 					   unsigned long *lflags,
-					   enum gpiod_flags *dflags)
+					   enum gpiod_flags *dflags,
+					   bool hog)
 {
 	struct device_node *chip_np;
 	enum of_gpio_flags xlate_flags;
 	struct of_phandle_args gpiospec;
+	const char *desc_name;
 	struct gpio_desc *desc;
 	unsigned int i;
 	u32 tmp;
@@ -797,15 +800,19 @@ static struct gpio_desc *of_parse_own_gpio(struct device_node *np,
 		*dflags |= GPIOD_OUT_LOW;
 	else if (of_property_read_bool(np, "output-high"))
 		*dflags |= GPIOD_OUT_HIGH;
-	else {
+	else if (hog) {
 		pr_warn("GPIO line %d (%pOFn): no hogging state specified, bailing out\n",
 			desc_to_gpio(desc), np);
 		return ERR_PTR(-EINVAL);
 	}
 
-	if (name && of_property_read_string(np, "line-name", name))
+	if (hog && name && of_property_read_string(np, "line-name", name))
 		*name = np->name;
 
+	if (!of_property_read_string(np, "gpio-line-name", &desc_name) &&
+	    desc_name[0])
+		desc->name = desc_name;
+
 	return desc;
 }
 
@@ -827,7 +834,8 @@ static int of_gpiochip_add_hog(struct gpio_chip *chip, struct device_node *hog)
 	int ret;
 
 	for (i = 0;; i++) {
-		desc = of_parse_own_gpio(hog, chip, i, &name, &lflags, &dflags);
+		desc = of_parse_own_gpio(hog, chip, i, &name, &lflags, &dflags,
+					 true);
 		if (IS_ERR(desc))
 			break;
 
@@ -843,6 +851,36 @@ static int of_gpiochip_add_hog(struct gpio_chip *chip, struct device_node *hog)
 	return 0;
 }
 
+/**
+ * of_gpiochip_add_line - Configure all lines in a gpio-line device node
+ * @chip:	gpio chip to act on
+ * @line:	device node describing GPIO lines to configure
+ *
+ * Returns:
+ * 0 on success, or negative errno on failure.
+ */
+static int of_gpiochip_add_line(struct gpio_chip *chip, struct device_node *line)
+{
+	enum gpiod_flags dflags;
+	struct gpio_desc *desc;
+	unsigned long lflags;
+	unsigned int i;
+	int ret;
+
+	for (i = 0;; i++) {
+		desc = of_parse_own_gpio(line, chip, i, NULL, &lflags, &dflags,
+					 false);
+		if (IS_ERR(desc))
+			break;
+
+		ret = gpiod_configure_flags(desc, NULL, lflags, dflags);
+		if (ret < 0)
+			return ret;
+	}
+
+	return 0;
+}
+
 /**
  * of_gpiochip_scan_gpios - Scan gpio-controller for gpio definitions
  * @chip:	gpio chip to act on
@@ -858,14 +896,22 @@ static int of_gpiochip_scan_gpios(struct gpio_chip *chip)
 	int ret;
 
 	for_each_available_child_of_node_scoped(dev_of_node(&chip->gpiodev->dev), np) {
-		if (!of_property_read_bool(np, "gpio-hog"))
+		if (of_property_read_bool(np, "gpio-hog")) {
+			ret = of_gpiochip_add_hog(chip, np);
+			if (ret < 0)
+				return ret;
+
+			of_node_set_flag(np, OF_POPULATED);
 			continue;
+		}
 
-		ret = of_gpiochip_add_hog(chip, np);
-		if (ret < 0)
-			return ret;
+		if (of_property_read_bool(np, "gpio-line")) {
+			ret = of_gpiochip_add_line(chip, np);
+			if (ret < 0)
+				return ret;
 
-		of_node_set_flag(np, OF_POPULATED);
+			of_node_set_flag(np, OF_POPULATED);
+		}
 	}
 
 	return 0;
@@ -905,14 +951,15 @@ static int of_gpio_notify(struct notifier_block *nb, unsigned long action,
 	int ret;
 
 	/*
-	 * This only supports adding and removing complete gpio-hog nodes.
-	 * Modifying an existing gpio-hog node is not supported (except for
-	 * changing its "status" property, which is treated the same as
-	 * addition/removal).
+	 * This only supports adding and removing complete gpio-hog and
+	 * gpio-line nodes. Modifying an existing node is not supported
+	 * (except for changing its "status" property, which is treated
+	 * the same as addition/removal).
 	 */
 	switch (of_reconfig_get_state_change(action, arg)) {
 	case OF_RECONFIG_CHANGE_ADD:
-		if (!of_property_read_bool(rd->dn, "gpio-hog"))
+		if (!of_property_read_bool(rd->dn, "gpio-hog") &&
+		    !of_property_read_bool(rd->dn, "gpio-line"))
 			return NOTIFY_DONE;	/* not for us */
 
 		if (of_node_test_and_set_flag(rd->dn, OF_POPULATED))
@@ -922,9 +969,12 @@ static int of_gpio_notify(struct notifier_block *nb, unsigned long action,
 		if (!gdev)
 			return NOTIFY_DONE;	/* not for us */
 
-		ret = of_gpiochip_add_hog(gpio_device_get_chip(gdev), rd->dn);
+		if (of_property_read_bool(rd->dn, "gpio-hog"))
+			ret = of_gpiochip_add_hog(gpio_device_get_chip(gdev), rd->dn);
+		else
+			ret = of_gpiochip_add_line(gpio_device_get_chip(gdev), rd->dn);
 		if (ret < 0) {
-			pr_err("%s: failed to add hogs for %pOF\n", __func__,
+			pr_err("%s: failed to configure lines for %pOF\n", __func__,
 			       rd->dn);
 			of_node_clear_flag(rd->dn, OF_POPULATED);
 			return notifier_from_errno(ret);
@@ -932,6 +982,10 @@ static int of_gpio_notify(struct notifier_block *nb, unsigned long action,
 		return NOTIFY_OK;
 
 	case OF_RECONFIG_CHANGE_REMOVE:
+		if (!of_property_read_bool(rd->dn, "gpio-hog") &&
+		    !of_property_read_bool(rd->dn, "gpio-line"))
+			return NOTIFY_DONE;	/* not for us */
+
 		if (!of_node_check_flag(rd->dn, OF_POPULATED))
 			return NOTIFY_DONE;	/* already depopulated */
 
@@ -939,7 +993,8 @@ static int of_gpio_notify(struct notifier_block *nb, unsigned long action,
 		if (!gdev)
 			return NOTIFY_DONE;	/* not for us */
 
-		of_gpiochip_remove_hog(gpio_device_get_chip(gdev), rd->dn);
+		if (of_property_read_bool(rd->dn, "gpio-hog"))
+			of_gpiochip_remove_hog(gpio_device_get_chip(gdev), rd->dn);
 		of_node_clear_flag(rd->dn, OF_POPULATED);
 		return NOTIFY_OK;
 	}
diff --git a/drivers/gpio/gpiolib-shared.c b/drivers/gpio/gpiolib-shared.c
index b3525d1f06a4..b934e58a07f0 100644
--- a/drivers/gpio/gpiolib-shared.c
+++ b/drivers/gpio/gpiolib-shared.c
@@ -147,10 +147,11 @@ static bool gpio_shared_of_node_ignore(struct device_node *node)
 		return true;
 
 	/*
-	 * GPIO hogs have a "gpios" property which is not a phandle and can't
-	 * possibly refer to a shared GPIO.
+	 * GPIO hog and gpio-line nodes have a "gpios" property which is not a
+	 * phandle and can't possibly refer to a shared GPIO.
 	 */
-	if (of_property_present(node, "gpio-hog"))
+	if (of_property_present(node, "gpio-hog") ||
+	    of_property_present(node, "gpio-line"))
 		return true;
 
 	return false;
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 50d95d512bf5..7689c4315115 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1435,10 +1435,11 @@ static struct device_node *parse_gpio_compat(struct device_node *np,
 		return NULL;
 
 	/*
-	 * Ignore node with gpio-hog property since its gpios are all provided
-	 * by its parent.
+	 * Ignore nodes with gpio-hog and gpio-line properties since their gpios
+	 * are all provided by their parent.
 	 */
-	if (of_property_read_bool(np, "gpio-hog"))
+	if (of_property_read_bool(np, "gpio-hog") ||
+	    of_property_read_bool(np, "gpio-line"))
 		return NULL;
 
 	if (of_parse_phandle_with_args(np, prop_name, "#gpio-cells", index,
diff --git a/scripts/dtc/checks.c b/scripts/dtc/checks.c
index 45d0213f3bf3..ee64cb4ada4f 100644
--- a/scripts/dtc/checks.c
+++ b/scripts/dtc/checks.c
@@ -1533,8 +1533,8 @@ static void check_gpios_property(struct check *c,
 {
 	struct property *prop;
 
-	/* Skip GPIO hog nodes which have 'gpios' property */
-	if (get_property(node, "gpio-hog"))
+	/* Skip gpio-hog and gpio-line nodes which have 'gpios' property */
+	if (get_property(node, "gpio-hog") || get_property(node, "gpio-line"))
 		return;
 
 	for_each_property(node, prop) {
-- 
2.43.0

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

[Bartosz Golaszewski]

On Sat, 14 Feb 2026 22:32:37 +0100, James Hilliard
<james.hilliard1@gmail.com> said:
> Allow GPIO controller child nodes marked with "gpio-line" to
> configure direction/flags at probe time without hogging the line.
>
> Teach OF gpiochip scanning and OF dynamic reconfiguration handlers to
> process gpio-line nodes in addition to gpio-hog nodes.
>
> Also parse "gpio-line-name" and apply it to desc->name. For gpio-hog
> nodes, keep "line-name" semantics as the hog consumer label.
>

One important thing that's missing from this commit description is: what is
the use-case and why do you need this.

The DT binding patch should be sent together with this in a single series. It
should also be documented in the relevant .rst file.

I suppose it's another shot at defining what we previously called
"initial-line-state", "default-line-state", etc. What happens when someone
requests the line, reconfigures it and then releases it?

This should also not be OF-specific but rather a GPIOLIB-wide switch.

Bartosz

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

[James Hilliard]

On Mon, Feb 16, 2026 at 4:38 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Sat, 14 Feb 2026 22:32:37 +0100, James Hilliard
> <james.hilliard1@gmail.com> said:
> > Allow GPIO controller child nodes marked with "gpio-line" to
> > configure direction/flags at probe time without hogging the line.
> >
> > Teach OF gpiochip scanning and OF dynamic reconfiguration handlers to
> > process gpio-line nodes in addition to gpio-hog nodes.
> >
> > Also parse "gpio-line-name" and apply it to desc->name. For gpio-hog
> > nodes, keep "line-name" semantics as the hog consumer label.
> >
>
> One important thing that's missing from this commit description is: what is
> the use-case and why do you need this.

Added some more use-case details in v3:
https://lore.kernel.org/all/20260216211021.3019827-1-james.hilliard1@gmail.com/

In my case I'm setting up the GPIO line initial state and names for
userspace consumers mostly. I want to be able to configure the
individual line names from a combination of the dts file and multiple
dtso files for the same gpiochip along with setting up an initial state
before userspace consumers operate on the lines.

> The DT binding patch should be sent together with this in a single series. It
> should also be documented in the relevant .rst file.

Which file would that be?

I had previously added docs to gpio.txt but was told here to just
drop the docs:
https://lore.kernel.org/all/b851bfd4-3c35-489f-a32d-dcd7a37ca99a@kernel.org/

> I suppose it's another shot at defining what we previously called
> "initial-line-state", "default-line-state", etc. What happens when someone
> requests the line, reconfigures it and then releases it?

This should just provide an initial configuration, subsequent consumers
would override whatever is set here AFAIU.

> This should also not be OF-specific but rather a GPIOLIB-wide switch.

Like this?:
https://lore.kernel.org/all/20260216211021.3019827-1-james.hilliard1@gmail.com/

>
> Bartosz

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

[Bartosz Golaszewski]

On Mon, 16 Feb 2026 22:20:10 +0100, James Hilliard
<james.hilliard1@gmail.com> said:
> On Mon, Feb 16, 2026 at 4:38 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>>
>> On Sat, 14 Feb 2026 22:32:37 +0100, James Hilliard
>> <james.hilliard1@gmail.com> said:
>> > Allow GPIO controller child nodes marked with "gpio-line" to
>> > configure direction/flags at probe time without hogging the line.
>> >
>> > Teach OF gpiochip scanning and OF dynamic reconfiguration handlers to
>> > process gpio-line nodes in addition to gpio-hog nodes.
>> >
>> > Also parse "gpio-line-name" and apply it to desc->name. For gpio-hog
>> > nodes, keep "line-name" semantics as the hog consumer label.
>> >
>>
>> One important thing that's missing from this commit description is: what is
>> the use-case and why do you need this.
>
> Added some more use-case details in v3:
> https://lore.kernel.org/all/20260216211021.3019827-1-james.hilliard1@gmail.com/
>
> In my case I'm setting up the GPIO line initial state and names for
> userspace consumers mostly. I want to be able to configure the
> individual line names from a combination of the dts file and multiple
> dtso files for the same gpiochip along with setting up an initial state
> before userspace consumers operate on the lines.
>
>> The DT binding patch should be sent together with this in a single series. It
>> should also be documented in the relevant .rst file.
>
> Which file would that be?
>

Documentation/driver-api/gpio/board.rst would fit best.

> I had previously added docs to gpio.txt but was told here to just
> drop the docs:
> https://lore.kernel.org/all/b851bfd4-3c35-489f-a32d-dcd7a37ca99a@kernel.org/
>

There's a difference between device-tree bindings (formal, machine-readable
definition of the firmware ABI) under Documentation/devicetree/bindings/ and
documentation for humans residing elsewhere in Documentation/. Make sure to
not confuse the two. I would expect both to be supplied with such a change.

>> I suppose it's another shot at defining what we previously called
>> "initial-line-state", "default-line-state", etc. What happens when someone
>> requests the line, reconfigures it and then releases it?
>
> This should just provide an initial configuration, subsequent consumers
> would override whatever is set here AFAIU.
>

Yeah, that's what I was afraid of. This is not hardware description, this is
user-convencience and as such I don't think it has place in DT bindings and -
by extension - in DTS.

I'm afraid I don't have good alternatives to offer, solving this has been
attempted several times in the past without success. Even gpio-hog would likely
not get past DT maintainer review these days but it's ABI now so will stay
supported.

How early do you need to set these settings?

Bartosz

>> This should also not be OF-specific but rather a GPIOLIB-wide switch.
>
> Like this?:
> https://lore.kernel.org/all/20260216211021.3019827-1-james.hilliard1@gmail.com/
>
>>
>> Bartosz
>

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

[Rob Herring]

On Tue, Feb 17, 2026 at 05:18:18AM -0800, Bartosz Golaszewski wrote:
> On Mon, 16 Feb 2026 22:20:10 +0100, James Hilliard
> <james.hilliard1@gmail.com> said:
> > On Mon, Feb 16, 2026 at 4:38 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> >>
> >> On Sat, 14 Feb 2026 22:32:37 +0100, James Hilliard
> >> <james.hilliard1@gmail.com> said:
> >> > Allow GPIO controller child nodes marked with "gpio-line" to
> >> > configure direction/flags at probe time without hogging the line.
> >> >
> >> > Teach OF gpiochip scanning and OF dynamic reconfiguration handlers to
> >> > process gpio-line nodes in addition to gpio-hog nodes.
> >> >
> >> > Also parse "gpio-line-name" and apply it to desc->name. For gpio-hog
> >> > nodes, keep "line-name" semantics as the hog consumer label.
> >> >
> >>
> >> One important thing that's missing from this commit description is: what is
> >> the use-case and why do you need this.
> >
> > Added some more use-case details in v3:
> > https://lore.kernel.org/all/20260216211021.3019827-1-james.hilliard1@gmail.com/
> >
> > In my case I'm setting up the GPIO line initial state and names for
> > userspace consumers mostly. I want to be able to configure the
> > individual line names from a combination of the dts file and multiple
> > dtso files for the same gpiochip along with setting up an initial state
> > before userspace consumers operate on the lines.
> >
> >> The DT binding patch should be sent together with this in a single series. It
> >> should also be documented in the relevant .rst file.
> >
> > Which file would that be?
> >
> 
> Documentation/driver-api/gpio/board.rst would fit best.
> 
> > I had previously added docs to gpio.txt but was told here to just
> > drop the docs:
> > https://lore.kernel.org/all/b851bfd4-3c35-489f-a32d-dcd7a37ca99a@kernel.org/
> >
> 
> There's a difference between device-tree bindings (formal, machine-readable
> definition of the firmware ABI) under Documentation/devicetree/bindings/ and
> documentation for humans residing elsewhere in Documentation/. Make sure to
> not confuse the two. I would expect both to be supplied with such a change.
> 
> >> I suppose it's another shot at defining what we previously called
> >> "initial-line-state", "default-line-state", etc. What happens when someone
> >> requests the line, reconfigures it and then releases it?
> >
> > This should just provide an initial configuration, subsequent consumers
> > would override whatever is set here AFAIU.
> >
> 
> Yeah, that's what I was afraid of. This is not hardware description, this is
> user-convencience and as such I don't think it has place in DT bindings and -
> by extension - in DTS.

I agree.

> I'm afraid I don't have good alternatives to offer, solving this has been
> attempted several times in the past without success. Even gpio-hog would likely
> not get past DT maintainer review these days but it's ABI now so will stay
> supported.

I might still... I don't love the binding and didn't at the time either. 
There was enough justification which this one completely lacks.

Please slow down your pace and give folks time to review. You're on v3 
already and it's the first I see it. People are in different timezones, 
take days off, get busy on other work, etc. 

Rob

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

[James Hilliard]

On Tue, Feb 17, 2026 at 6:18 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Mon, 16 Feb 2026 22:20:10 +0100, James Hilliard
> <james.hilliard1@gmail.com> said:
> > On Mon, Feb 16, 2026 at 4:38 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> >>
> >> On Sat, 14 Feb 2026 22:32:37 +0100, James Hilliard
> >> <james.hilliard1@gmail.com> said:
> >> > Allow GPIO controller child nodes marked with "gpio-line" to
> >> > configure direction/flags at probe time without hogging the line.
> >> >
> >> > Teach OF gpiochip scanning and OF dynamic reconfiguration handlers to
> >> > process gpio-line nodes in addition to gpio-hog nodes.
> >> >
> >> > Also parse "gpio-line-name" and apply it to desc->name. For gpio-hog
> >> > nodes, keep "line-name" semantics as the hog consumer label.
> >> >
> >>
> >> One important thing that's missing from this commit description is: what is
> >> the use-case and why do you need this.
> >
> > Added some more use-case details in v3:
> > https://lore.kernel.org/all/20260216211021.3019827-1-james.hilliard1@gmail.com/
> >
> > In my case I'm setting up the GPIO line initial state and names for
> > userspace consumers mostly. I want to be able to configure the
> > individual line names from a combination of the dts file and multiple
> > dtso files for the same gpiochip along with setting up an initial state
> > before userspace consumers operate on the lines.
> >
> >> The DT binding patch should be sent together with this in a single series. It
> >> should also be documented in the relevant .rst file.
> >
> > Which file would that be?
> >
>
> Documentation/driver-api/gpio/board.rst would fit best.

Should gpio-hog docs be moved here as well?

>
> > I had previously added docs to gpio.txt but was told here to just
> > drop the docs:
> > https://lore.kernel.org/all/b851bfd4-3c35-489f-a32d-dcd7a37ca99a@kernel.org/
> >
>
> There's a difference between device-tree bindings (formal, machine-readable
> definition of the firmware ABI) under Documentation/devicetree/bindings/ and
> documentation for humans residing elsewhere in Documentation/. Make sure to
> not confuse the two. I would expect both to be supplied with such a change.

What file under bindings would this go in?

>
> >> I suppose it's another shot at defining what we previously called
> >> "initial-line-state", "default-line-state", etc. What happens when someone
> >> requests the line, reconfigures it and then releases it?
> >
> > This should just provide an initial configuration, subsequent consumers
> > would override whatever is set here AFAIU.
> >
>
> Yeah, that's what I was afraid of. This is not hardware description, this is
> user-convencience and as such I don't think it has place in DT bindings and -
> by extension - in DTS.

I guess this is more describing a hardware configuration, but is that
not allowed in DT bindings? There seems to be plenty of DT stuff
that's effectively describing the way the hardware should be configured
initially.

For example uart/serial nodes have a current-speed property that
can be used to configure the initial speed, but this can also be
overridden by userspace consumers at runtime as well via
termios configurations AFAIU. That seems to be a pretty similar
case to what I'm trying to do here with gpios.

What's the reason user-convenience hardware configuration stuff
like this shouldn't go in DT bindings?

> I'm afraid I don't have good alternatives to offer, solving this has been
> attempted several times in the past without success. Even gpio-hog would likely
> not get past DT maintainer review these days but it's ABI now so will stay
> supported.

What did previous attempts look like? At least this is minimally invasive
and shares most of the code paths with gpio-hog.

> How early do you need to set these settings?

Well, before userspace applications can interact with the gpio lines I
suppose. Essentially so that it acts as a failsafe configuration in case
the userspace app doesn't get started for whatever reason as well as
giving some initial starting configuration for a userspace app to act
upon.

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

[Bartosz Golaszewski]

On Tue, Feb 17, 2026 at 8:07 PM James Hilliard
<james.hilliard1@gmail.com> wrote:
>
> On Tue, Feb 17, 2026 at 6:18 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> >
> > On Mon, 16 Feb 2026 22:20:10 +0100, James Hilliard
> > <james.hilliard1@gmail.com> said:
> > > On Mon, Feb 16, 2026 at 4:38 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> > >>
> > >> On Sat, 14 Feb 2026 22:32:37 +0100, James Hilliard
> > >> <james.hilliard1@gmail.com> said:
> > >> > Allow GPIO controller child nodes marked with "gpio-line" to
> > >> > configure direction/flags at probe time without hogging the line.
> > >> >
> > >> > Teach OF gpiochip scanning and OF dynamic reconfiguration handlers to
> > >> > process gpio-line nodes in addition to gpio-hog nodes.
> > >> >
> > >> > Also parse "gpio-line-name" and apply it to desc->name. For gpio-hog
> > >> > nodes, keep "line-name" semantics as the hog consumer label.
> > >> >
> > >>
> > >> One important thing that's missing from this commit description is: what is
> > >> the use-case and why do you need this.
> > >
> > > Added some more use-case details in v3:
> > > https://lore.kernel.org/all/20260216211021.3019827-1-james.hilliard1@gmail.com/
> > >
> > > In my case I'm setting up the GPIO line initial state and names for
> > > userspace consumers mostly. I want to be able to configure the
> > > individual line names from a combination of the dts file and multiple
> > > dtso files for the same gpiochip along with setting up an initial state
> > > before userspace consumers operate on the lines.
> > >
> > >> The DT binding patch should be sent together with this in a single series. It
> > >> should also be documented in the relevant .rst file.
> > >
> > > Which file would that be?
> > >
> >
> > Documentation/driver-api/gpio/board.rst would fit best.
>
> Should gpio-hog docs be moved here as well?
>

Not moved from DT bindings, just added as they are missing.

> >
> > > I had previously added docs to gpio.txt but was told here to just
> > > drop the docs:
> > > https://lore.kernel.org/all/b851bfd4-3c35-489f-a32d-dcd7a37ca99a@kernel.org/
> > >
> >
> > There's a difference between device-tree bindings (formal, machine-readable
> > definition of the firmware ABI) under Documentation/devicetree/bindings/ and
> > documentation for humans residing elsewhere in Documentation/. Make sure to
> > not confuse the two. I would expect both to be supplied with such a change.
>
> What file under bindings would this go in?
>

Typically the top-level GPIO bindings document but we don't have it
yet. Or rather: we have the old .txt format and not yaml. I need to
start chipping away at it at some point...

> >
> > >> I suppose it's another shot at defining what we previously called
> > >> "initial-line-state", "default-line-state", etc. What happens when someone
> > >> requests the line, reconfigures it and then releases it?
> > >
> > > This should just provide an initial configuration, subsequent consumers
> > > would override whatever is set here AFAIU.
> > >
> >
> > Yeah, that's what I was afraid of. This is not hardware description, this is
> > user-convencience and as such I don't think it has place in DT bindings and -
> > by extension - in DTS.
>
> I guess this is more describing a hardware configuration, but is that
> not allowed in DT bindings? There seems to be plenty of DT stuff
> that's effectively describing the way the hardware should be configured
> initially.
>
> For example uart/serial nodes have a current-speed property that
> can be used to configure the initial speed, but this can also be
> overridden by userspace consumers at runtime as well via
> termios configurations AFAIU. That seems to be a pretty similar
> case to what I'm trying to do here with gpios.
>
> What's the reason user-convenience hardware configuration stuff
> like this shouldn't go in DT bindings?
>

We do have many cases like that back from before DT schema and
validation. Bindings have become much stricter since and it's assumed
that DTS should only describe hardware, not its configuration.

> > I'm afraid I don't have good alternatives to offer, solving this has been
> > attempted several times in the past without success. Even gpio-hog would likely
> > not get past DT maintainer review these days but it's ABI now so will stay
> > supported.
>
> What did previous attempts look like? At least this is minimally invasive
> and shares most of the code paths with gpio-hog.
>

They focused more on the "default" state of GPIOs. State to which you
would revert if not requested. If anything: this makes more sense than
"initial" state to me which we forget after the first request. Right
now this is something driver-specific. I'll let DT maintainers speak
if that's something we could put into DT.

Bart

> > How early do you need to set these settings?
>
> Well, before userspace applications can interact with the gpio lines I
> suppose. Essentially so that it acts as a failsafe configuration in case
> the userspace app doesn't get started for whatever reason as well as
> giving some initial starting configuration for a userspace app to act
> upon.

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

[Linus Walleij]

On Tue, Feb 17, 2026 at 8:07 PM James Hilliard
<james.hilliard1@gmail.com> wrote:

> What did previous attempts look like? At least this is minimally invasive
> and shares most of the code paths with gpio-hog.

Gemini gives the following (rather accurate) rundown to the prompt
"Can you find the conversations on the linux-gpio@vger.kernel.org
 mailing list where people have in the past suggested to extend the
 gpio hog functionality to define initial line states for GPIO lines?"

This is based on the response but cleaned from obvious hallucinations...

1. The Original "Hogging" Proposal (2013)

The mechanism was first proposed by Boris Brezillon and later attempt upstreamed
by Benoit Parrot.

Version v1 thru v6, enjoy:
https://lore.kernel.org/linux-gpio/1387463671-1164-2-git-send-email-b.brezillon@overkiz.com/
https://lore.kernel.org/linux-gpio/1416527684-19017-1-git-send-email-bparrot@ti.com/
https://lore.kernel.org/linux-gpio/1417726922-10376-1-git-send-email-bparrot@ti.com/
https://lore.kernel.org/linux-gpio/1418422051-9471-1-git-send-email-bparrot@ti.com/
https://lore.kernel.org/linux-gpio/1419019671-25377-1-git-send-email-bparrot@ti.com/
https://lore.kernel.org/linux-gpio/1422899085-678-1-git-send-email-bparrot@ti.com/

Markus Pargmanns proposal to add gpio-initval (2015):

https://lore.kernel.org/linux-gpio/1439979512-3894-1-git-send-email-mpa@pengutronix.de/
https://lore.kernel.org/linux-gpio/1439979512-3894-4-git-send-email-mpa@pengutronix.de/

The Argument: Users wanted a way to say, "At probe time, set this pin to X,"
but allow a later driver to take over.

All initiatives stalled on the following: you have to provide a DT binding that
the DT maintainers can accept. From a gpiolib point of view this is easy to
support, and to us it seemed (seems) neat.

> > How early do you need to set these settings?
>
> Well, before userspace applications can interact with the gpio lines I
> suppose. Essentially so that it acts as a failsafe configuration in case
> the userspace app doesn't get started for whatever reason as well as
> giving some initial starting configuration for a userspace app to act
> upon.

This essentially becomes a kernel intialization of a userspace driver.

Nothing wrong with that I guess, but it raises the question why it is not
a kernel driver (there are valid reasons for this) but also why, if it is a
pure userspace driver, it has to be initialized so early and can't wait for
that userspace process to start.

Yours,
Linus Walleij

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

[Rob Herring]

On Wed, Feb 18, 2026 at 3:34 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Tue, Feb 17, 2026 at 8:07 PM James Hilliard
> <james.hilliard1@gmail.com> wrote:
> >
> > On Tue, Feb 17, 2026 at 6:18 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> > >
> > > On Mon, 16 Feb 2026 22:20:10 +0100, James Hilliard
> > > <james.hilliard1@gmail.com> said:
> > > > On Mon, Feb 16, 2026 at 4:38 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> > > >>
> > > >> On Sat, 14 Feb 2026 22:32:37 +0100, James Hilliard
> > > >> <james.hilliard1@gmail.com> said:
> > > >> > Allow GPIO controller child nodes marked with "gpio-line" to
> > > >> > configure direction/flags at probe time without hogging the line.
> > > >> >
> > > >> > Teach OF gpiochip scanning and OF dynamic reconfiguration handlers to
> > > >> > process gpio-line nodes in addition to gpio-hog nodes.
> > > >> >
> > > >> > Also parse "gpio-line-name" and apply it to desc->name. For gpio-hog
> > > >> > nodes, keep "line-name" semantics as the hog consumer label.
> > > >> >
> > > >>
> > > >> One important thing that's missing from this commit description is: what is
> > > >> the use-case and why do you need this.
> > > >
> > > > Added some more use-case details in v3:
> > > > https://lore.kernel.org/all/20260216211021.3019827-1-james.hilliard1@gmail.com/
> > > >
> > > > In my case I'm setting up the GPIO line initial state and names for
> > > > userspace consumers mostly. I want to be able to configure the
> > > > individual line names from a combination of the dts file and multiple
> > > > dtso files for the same gpiochip along with setting up an initial state
> > > > before userspace consumers operate on the lines.
> > > >
> > > >> The DT binding patch should be sent together with this in a single series. It
> > > >> should also be documented in the relevant .rst file.
> > > >
> > > > Which file would that be?
> > > >
> > >
> > > Documentation/driver-api/gpio/board.rst would fit best.
> >
> > Should gpio-hog docs be moved here as well?
> >
>
> Not moved from DT bindings, just added as they are missing.
>
> > >
> > > > I had previously added docs to gpio.txt but was told here to just
> > > > drop the docs:
> > > > https://lore.kernel.org/all/b851bfd4-3c35-489f-a32d-dcd7a37ca99a@kernel.org/
> > > >
> > >
> > > There's a difference between device-tree bindings (formal, machine-readable
> > > definition of the firmware ABI) under Documentation/devicetree/bindings/ and
> > > documentation for humans residing elsewhere in Documentation/. Make sure to
> > > not confuse the two. I would expect both to be supplied with such a change.
> >
> > What file under bindings would this go in?
> >
>
> Typically the top-level GPIO bindings document but we don't have it
> yet. Or rather: we have the old .txt format and not yaml. I need to
> start chipping away at it at some point...

Most or all of it can be deleted. The same text exists in dtschema
gpio.yaml already. There might have been some parts not moved yet as I
didn't have rights to dual license.

> > > >> I suppose it's another shot at defining what we previously called
> > > >> "initial-line-state", "default-line-state", etc. What happens when someone
> > > >> requests the line, reconfigures it and then releases it?
> > > >
> > > > This should just provide an initial configuration, subsequent consumers
> > > > would override whatever is set here AFAIU.
> > > >
> > >
> > > Yeah, that's what I was afraid of. This is not hardware description, this is
> > > user-convencience and as such I don't think it has place in DT bindings and -
> > > by extension - in DTS.
> >
> > I guess this is more describing a hardware configuration, but is that
> > not allowed in DT bindings? There seems to be plenty of DT stuff
> > that's effectively describing the way the hardware should be configured
> > initially.
> >
> > For example uart/serial nodes have a current-speed property that
> > can be used to configure the initial speed, but this can also be
> > overridden by userspace consumers at runtime as well via
> > termios configurations AFAIU. That seems to be a pretty similar
> > case to what I'm trying to do here with gpios.
> >
> > What's the reason user-convenience hardware configuration stuff
> > like this shouldn't go in DT bindings?
> >
>
> We do have many cases like that back from before DT schema and
> validation. Bindings have become much stricter since and it's assumed
> that DTS should only describe hardware, not its configuration.

No, configuration is allowed. The oldest example is probably uart baud
rate. pinctrl is completely the configuration of pins. But there is a
limit and it's a judgment call.

> > > I'm afraid I don't have good alternatives to offer, solving this has been
> > > attempted several times in the past without success. Even gpio-hog would likely
> > > not get past DT maintainer review these days but it's ABI now so will stay
> > > supported.
> >
> > What did previous attempts look like? At least this is minimally invasive
> > and shares most of the code paths with gpio-hog.
> >
>
> They focused more on the "default" state of GPIOs. State to which you
> would revert if not requested. If anything: this makes more sense than
> "initial" state to me which we forget after the first request.

Agreed.

> Right
> now this is something driver-specific. I'll let DT maintainers speak
> if that's something we could put into DT.

If the argument was wanting to do this in early boot firmware, I'd be
more convinced. But to say it is needed for userspace, I'm not really
convinced. My main concern is wanting to describe the state, but not
what the GPIOs are connected to. Is it really nothing and we'd never
ever possibly want to describe that.

Rob

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

[James Hilliard]

On Wed, Feb 18, 2026 at 4:45 PM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Feb 18, 2026 at 3:34 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> >
> > On Tue, Feb 17, 2026 at 8:07 PM James Hilliard
> > <james.hilliard1@gmail.com> wrote:
> > >
> > > On Tue, Feb 17, 2026 at 6:18 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> > > >
> > > > On Mon, 16 Feb 2026 22:20:10 +0100, James Hilliard
> > > > <james.hilliard1@gmail.com> said:
> > > > > On Mon, Feb 16, 2026 at 4:38 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
> > > > >>
> > > > >> On Sat, 14 Feb 2026 22:32:37 +0100, James Hilliard
> > > > >> <james.hilliard1@gmail.com> said:
> > > > >> > Allow GPIO controller child nodes marked with "gpio-line" to
> > > > >> > configure direction/flags at probe time without hogging the line.
> > > > >> >
> > > > >> > Teach OF gpiochip scanning and OF dynamic reconfiguration handlers to
> > > > >> > process gpio-line nodes in addition to gpio-hog nodes.
> > > > >> >
> > > > >> > Also parse "gpio-line-name" and apply it to desc->name. For gpio-hog
> > > > >> > nodes, keep "line-name" semantics as the hog consumer label.
> > > > >> >
> > > > >>
> > > > >> One important thing that's missing from this commit description is: what is
> > > > >> the use-case and why do you need this.
> > > > >
> > > > > Added some more use-case details in v3:
> > > > > https://lore.kernel.org/all/20260216211021.3019827-1-james.hilliard1@gmail.com/
> > > > >
> > > > > In my case I'm setting up the GPIO line initial state and names for
> > > > > userspace consumers mostly. I want to be able to configure the
> > > > > individual line names from a combination of the dts file and multiple
> > > > > dtso files for the same gpiochip along with setting up an initial state
> > > > > before userspace consumers operate on the lines.
> > > > >
> > > > >> The DT binding patch should be sent together with this in a single series. It
> > > > >> should also be documented in the relevant .rst file.
> > > > >
> > > > > Which file would that be?
> > > > >
> > > >
> > > > Documentation/driver-api/gpio/board.rst would fit best.
> > >
> > > Should gpio-hog docs be moved here as well?
> > >
> >
> > Not moved from DT bindings, just added as they are missing.
> >
> > > >
> > > > > I had previously added docs to gpio.txt but was told here to just
> > > > > drop the docs:
> > > > > https://lore.kernel.org/all/b851bfd4-3c35-489f-a32d-dcd7a37ca99a@kernel.org/
> > > > >
> > > >
> > > > There's a difference between device-tree bindings (formal, machine-readable
> > > > definition of the firmware ABI) under Documentation/devicetree/bindings/ and
> > > > documentation for humans residing elsewhere in Documentation/. Make sure to
> > > > not confuse the two. I would expect both to be supplied with such a change.
> > >
> > > What file under bindings would this go in?
> > >
> >
> > Typically the top-level GPIO bindings document but we don't have it
> > yet. Or rather: we have the old .txt format and not yaml. I need to
> > start chipping away at it at some point...
>
> Most or all of it can be deleted. The same text exists in dtschema
> gpio.yaml already. There might have been some parts not moved yet as I
> didn't have rights to dual license.
>
> > > > >> I suppose it's another shot at defining what we previously called
> > > > >> "initial-line-state", "default-line-state", etc. What happens when someone
> > > > >> requests the line, reconfigures it and then releases it?
> > > > >
> > > > > This should just provide an initial configuration, subsequent consumers
> > > > > would override whatever is set here AFAIU.
> > > > >
> > > >
> > > > Yeah, that's what I was afraid of. This is not hardware description, this is
> > > > user-convencience and as such I don't think it has place in DT bindings and -
> > > > by extension - in DTS.
> > >
> > > I guess this is more describing a hardware configuration, but is that
> > > not allowed in DT bindings? There seems to be plenty of DT stuff
> > > that's effectively describing the way the hardware should be configured
> > > initially.
> > >
> > > For example uart/serial nodes have a current-speed property that
> > > can be used to configure the initial speed, but this can also be
> > > overridden by userspace consumers at runtime as well via
> > > termios configurations AFAIU. That seems to be a pretty similar
> > > case to what I'm trying to do here with gpios.
> > >
> > > What's the reason user-convenience hardware configuration stuff
> > > like this shouldn't go in DT bindings?
> > >
> >
> > We do have many cases like that back from before DT schema and
> > validation. Bindings have become much stricter since and it's assumed
> > that DTS should only describe hardware, not its configuration.
>
> No, configuration is allowed. The oldest example is probably uart baud
> rate. pinctrl is completely the configuration of pins. But there is a
> limit and it's a judgment call.
>
> > > > I'm afraid I don't have good alternatives to offer, solving this has been
> > > > attempted several times in the past without success. Even gpio-hog would likely
> > > > not get past DT maintainer review these days but it's ABI now so will stay
> > > > supported.
> > >
> > > What did previous attempts look like? At least this is minimally invasive
> > > and shares most of the code paths with gpio-hog.
> > >
> >
> > They focused more on the "default" state of GPIOs. State to which you
> > would revert if not requested. If anything: this makes more sense than
> > "initial" state to me which we forget after the first request.
>
> Agreed.
>
> > Right
> > now this is something driver-specific. I'll let DT maintainers speak
> > if that's something we could put into DT.
>
> If the argument was wanting to do this in early boot firmware, I'd be
> more convinced. But to say it is needed for userspace, I'm not really
> convinced. My main concern is wanting to describe the state, but not
> what the GPIOs are connected to. Is it really nothing and we'd never
> ever possibly want to describe that.

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
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
gpio-line support to u-boot so that initial state is configured prior to
the kernel taking over as well.

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.

>
> Rob

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@gmail.com> 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

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@kernel.org> wrote:
>
> On Thu, Feb 19, 2026 at 12:56 AM James Hilliard
> <james.hilliard1@gmail.com> 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

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@kernel.org> 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

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@kernel.org> wrote:
>
> On Thu, Feb 19, 2026 at 10:15 AM Bartosz Golaszewski <brgl@kernel.org> 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

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@kernel.org> wrote:
> On Thu, Feb 19, 2026 at 12:23 PM Linus Walleij <linusw@kernel.org> wrote:
> > On Thu, Feb 19, 2026 at 10:15 AM Bartosz Golaszewski <brgl@kernel.org> 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