From: Rob Herring <robh@kernel.org>
To: Bartosz Golaszewski <brgl@kernel.org>,
James Hilliard <james.hilliard1@gmail.com>
Cc: linux-gpio@vger.kernel.org, Linus Walleij <linusw@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>
Subject: Re: [PATCH v2 1/1] gpiolib: of: add gpio-line node support
Date: Tue, 17 Feb 2026 08:11:30 -0600 [thread overview]
Message-ID: <20260217141130.GA2953125-robh@kernel.org> (raw)
In-Reply-To: <CAMRc=Me6v2E1zKGQzukJmP45cVkRWOGzYoO9=LKh63rPFRqfqA@mail.gmail.com>
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
next prev parent reply other threads:[~2026-02-17 14:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 21:32 [PATCH v2 1/1] gpiolib: of: add gpio-line node support James Hilliard
2026-02-16 11:37 ` Bartosz Golaszewski
2026-02-16 21:20 ` James Hilliard
2026-02-17 13:18 ` Bartosz Golaszewski
2026-02-17 14:11 ` Rob Herring [this message]
2026-02-17 19:07 ` James Hilliard
2026-02-18 9:33 ` Bartosz Golaszewski
2026-02-18 23:44 ` Rob Herring
2026-02-18 23:56 ` James Hilliard
2026-02-19 9:15 ` Bartosz Golaszewski
2026-02-19 18:18 ` James Hilliard
2026-02-19 18:23 ` Linus Walleij
2026-02-19 21:33 ` Rob Herring
2026-02-19 22:48 ` Linus Walleij
2026-02-18 23:10 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260217141130.GA2953125-robh@kernel.org \
--to=robh@kernel.org \
--cc=brgl@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=james.hilliard1@gmail.com \
--cc=krzk@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=saravanak@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox