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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
 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@xxxxxxxxxxx/
https://lore.kernel.org/linux-gpio/1416527684-19017-1-git-send-email-bparrot@xxxxxx/
https://lore.kernel.org/linux-gpio/1417726922-10376-1-git-send-email-bparrot@xxxxxx/
https://lore.kernel.org/linux-gpio/1418422051-9471-1-git-send-email-bparrot@xxxxxx/
https://lore.kernel.org/linux-gpio/1419019671-25377-1-git-send-email-bparrot@xxxxxx/
https://lore.kernel.org/linux-gpio/1422899085-678-1-git-send-email-bparrot@xxxxxx/

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

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

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