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]
Date:   Wed, 13 Sep 2023 08:34:51 -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 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.

> };
> 
> leds {
>     compatible = "gpio-leds";
>     led-my-gpio {
>         label = "device:blue:myled";
>         gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
>         default-state = "off";
>         linux,default-trigger = "gpio";
>         trigger-sources = <&gpio 1 GPIO_ACTIVE_HIGH>;
>     };
> };
> 
> Signed-off-by: Linus Walleij <linus.walleij@...aro.org>
> ---
>  Documentation/devicetree/bindings/leds/common.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
> index 5fb7007f3618..b42950643b9d 100644
> --- a/Documentation/devicetree/bindings/leds/common.yaml
> +++ b/Documentation/devicetree/bindings/leds/common.yaml
> @@ -191,6 +191,8 @@ properties:
>        each of them having its own LED assigned (assuming they are not
>        hardwired). In such cases this property should contain phandle(s) of
>        related source device(s).
> +      Another example is a GPIO line that will be monitored and mirror the
> +      state of the line (with or without inversion flags) to the LED.
>        In many cases LED can be related to more than one device (e.g. one USB LED
>        vs. multiple USB ports). Each source should be represented by a node in
>        the device tree and be referenced by a phandle and a set of phandle
> 
> -- 
> 2.34.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ