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: <37d85b2d-8fca-a998-95ae-61f0c049054d@ti.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ