linux-kernel - Re: [RFC PATCH v3 04/15] dt-bindings: leds: ROHM BD71282 PMIC LED driver

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:   Tue, 5 Nov 2019 13:14:33 -0600
From:   Dan Murphy <dmurphy@...com>
To:     Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        <mazziesaccount@...il.com>
CC:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Lee Jones <lee.jones@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        <linux-leds@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-clk@...r.kernel.org>,
        <linux-gpio@...r.kernel.org>, <linux-rtc@...r.kernel.org>
Subject: Re: [RFC PATCH v3 04/15] dt-bindings: leds: ROHM BD71282 PMIC LED
 driver

Matti

On 11/1/19 6:32 AM, Matti Vaittinen wrote:
> Document ROHM BD71828 PMIC LED driver device tree bindings.
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
> ---
>
> Changes from v2 - new patch
>
>   .../bindings/leds/rohm,leds-bd71828.yaml      | 46 +++++++++++++++++++
>   1 file changed, 46 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/leds/rohm,leds-bd71828.yaml
>
> diff --git a/Documentation/devicetree/bindings/leds/rohm,leds-bd71828.yaml b/Documentation/devicetree/bindings/leds/rohm,leds-bd71828.yaml
> new file mode 100644
> index 000000000000..d8aeac9911ef
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/rohm,leds-bd71828.yaml
> @@ -0,0 +1,46 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/rohm,leds-bd71828.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ROHM BD71828 Power Management Integrated Circuit LED driver
> +
> +maintainers:
> +  - Jacek Anaszewski <jacek.anaszewski@...il.com>
> +  - Pavel Machek <pavel@....cz>
> +  - Dan Murphy <dmurphy@...com>
> +  - Rob Herring <robh+dt@...nel.org>
> +  - Mark Rutland <mark.rutland@....com>
I believe you are the maintainer of this driver not the maintainers
> +
> +description: |
> +  This module is part of the ROHM BD71828 MFD device. For more details
> +  see Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml.
> +
> +  The LED controller is represented as a sub-node of the PMIC node on the device
> +  tree.
> +
> +  The device has two LED outputs referred as GRNLED and AMBLED in data-sheet.
> +
> +properties:
> +  compatible:
> +    const: rohm,bd71828-led
> +
> +patternProperties:
> +  "^led-[1-2]$":
> +    type: object
> +    description:
> +      Properties for a single LED. Nodes must be named as led-1 and led-2.

Why is this required?  Can't we use the reg as the number and then we 
can use standard node labels

like led@<reg value>.  Then we can check in the code to make sure that 
the output is not out of bounds.

> +    properties:
> +      #$ref: "common.yaml#"
> +      function:
> +        description:
> +          Purpose of LED as defined in dt-bindings/leds/common.h
> +        $ref: "/schemas/types.yaml#/definitions/string"
> +      color:
> +        description:
> +          LED colour as defined in dt-bindings/leds/common.h

s/colour/color

But again I believe it is indicated above that the LEDs are either going 
to be green or amber.  Unless they can be any color.

Are there plans to make sure that the color is either green or amber in 
the code?  I don't see a patch for the code in this series

> +        $ref: "/schemas/types.yaml#/definitions/uint32"
> +
> +required:
> +  - compatible

Is there an example of the node and properties?

Dan