Brian
On 4/2/19 8:24 AM, Brian Masney wrote:
> On Tue, Apr 02, 2019 at 07:56:55AM -0500, Dan Murphy wrote:
>> This would connect control bank B to control bank A. Or just use a flag to denote to connect them
>> and not use led-sources. But led-sources is the property of choice.
>>
>> led@0 {
>> reg = <0>;
>> led-sources = < 0 1 >;
>> label = "main-lcd";
>> default-brightness = <200>;
>> max-brightness = <255>;
>> };
>
> OK, I see. I wondered how we could do that in device tree.
>
>>> + properties:
>>> + label:
>>> + description: |
>>> + The label for this LED. If omitted, the label is taken from the node
>>> + name (excluding the unit address). It has to uniquely identify a
>>> + device, i.e. no other LED class device can be assigned the same label.
>>> +
>>> + led-sources:
>>> + description: |
>>> + List of device current outputs the LED is connected to.
>>> + allOf:
>>> + - $ref: /schemas/types.yaml#/definitions/uint32-array
>>> + - minItems: 1
>>> + maxItems: 2
>>> + items:
>>> + minimum: 0
>>> + maximum: 1
>>> +
>>
>> label and led-sources are already defined in the common.txt no need to redefine them here.
>
> If I'm going to use the new-style bindings, then I'll need to convert
> common.txt over to use the new format as well so that the automated
> schema validations will work. I'm willing to do that work if there is
> interest from the LED / backlight maintainers. The main issue is that
> there are 62 references to the file common.txt in the directory
> Documentation/devicetree/bindings/leds/. Would the maintainers prefer:
>
> - Once common.txt is converted to common.yaml, make common.txt only
> have a line stating that the common bindings were moved into
> common.yaml. We can remove this file once all of the other bindings
> are converted to the new-style format.
>
> - Update all references to common.txt to common.yaml. (1 patch or 62
> patches?)
>
> - Or, just go with the older-style binding format for now.
>
> Thanks Dan for your other comments. They make sense and I'll incorporate
> those changes into my next version.
>
That is up to the maintainers.
Also one other comment I noticed when reviewing the code that there is no definition to
which child led properties are optional and which are required?
Dan
> Brian
>
--
------------------
Dan Murphy
