linux-kernel - Re: [PATCH 1/2] dt-bindings: leds: Mention GPIO triggers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_Jsq+PizSdqJ5Yc4TpNscy5e3gBP4vjQF+ka6SRwnJhSt-0w@mail.gmail.com>
Date:   Thu, 14 Sep 2023 09:27:14 -0500
From:   Rob Herring <robh@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Jan Kundrát <jan.kundrat@...net.cz>,
        Pavel Machek <pavel@....cz>, Lee Jones <lee@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: leds: Mention GPIO triggers

On Thu, Sep 14, 2023 at 3:40 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Wed, Sep 13, 2023 at 3:34 PM Rob Herring <robh@...nel.org> wrote:
> > On Tue, Sep 12, 2023 at 03:44:30PM +0200, Linus Walleij wrote:
> > > We reuse the trigger-sources phandle to just point to
> > > GPIOs we may want to use as LED triggers.
> > >
> > > Example:
> > >
> > > gpio: gpio@0 {
> > >     compatible "my-gpio";
> > >     gpio-controller;
> > >     #gpio-cells = <2>;
> > >     interrupt-controller;
> > >     #interrupt-cells = <2>;
> > >     #trigger-source-cells = <2>;
> >
> > BTW, this is not documented for any GPIO binding. If we want to specify
> > the cell size, then it has to be added to every GPIO controller binding.
> > If not, we then need to reference gpio.yaml in every GPIO controller
> > binding (along with unevaluatedProperties). Doesn't have to be done for
> > this patch to go in though.
>
> Yeah I mean this trigger-sources = <...>; one-size-fits-all is a bit
> weird in a way.
>
> My other idea was to simply add trigger-gpios to the normal way
> and be done with it, but now the trigger binding has this weird
> thing.
>
> Would trigger-gpios be better?

Then GPIOs are different than everyone else. I think we have to think
about other bindings too. While we could standardize the naming here
with trigger-gpios, that won't work with the foos/foo-names style of
bindings.

trigger-sources is not widely used as it is just USB ATM and a few
platforms. We could come up with something different.
"trigger-sources-<cellname>" is the only idea I have. Then the
property name gives you the cell name to read. But variable property
names have their own challenges. We would need to look at all the
current trigger sources (i.e. the linux,default-trigger ones) and see
what else might need this.

Rob