Hello Dan, Thanks for the check once again! On Tue, 2019-11-05 at 13:14 -0600, Dan Murphy wrote: > 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@xxxxxxxxxxxxxxxxx> > > --- > > > > 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@xxxxxxxxx> > > + - Pavel Machek <pavel@xxxxxx> > > + - Dan Murphy <dmurphy@xxxxxx> > > + - Rob Herring <robh+dt@xxxxxxxxxx> > > + - Mark Rutland <mark.rutland@xxxxxxx> > I believe you are the maintainer of this driver not the maintainers Right. Thanks for pointing that out. > > + > > +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 This was related to my idea of using the node-names as unique keys. Please see: https://lore.kernel.org/lkml/cover.1572351774.git.matti.vaittinen@xxxxxxxxxxxxxxxxx/ What would you expect the reg = <>; to describe from HW? > 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 That depends on your location :) > 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. This was my original reason for omitting the DT for BD71828 LEDs altogether. LEDs are expected to be green and amber - but it is true that PMIC can not ensure there will be no other colours. > 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 Yes. As I wrote in cover-letter, the LED driver is pending until I see how the RFC for adding LED node finding and some more common property parsing to LED core is received by others. (Although I do understand if you didn't read the cover-letter. It's quite a bunch of text and reading it over and over again is no fun). > > > + $ref: "/schemas/types.yaml#/definitions/uint32" > > + > > +required: > > + - compatible > > Is there an example of the node and properties? Yes, in MFD doc. Br, Matti Vaittinen
