From: Dan Murphy <dmurphy@ti.com>
To: Brian Masney <masneyb@onstation.org>
Cc: <lee.jones@linaro.org>, <daniel.thompson@linaro.org>,
<jingoohan1@gmail.com>, <robh+dt@kernel.org>,
<jacek.anaszewski@gmail.com>, <pavel@ucw.cz>,
<mark.rutland@arm.com>, <b.zolnierkie@samsung.com>,
<dri-devel@lists.freedesktop.org>, <linux-leds@vger.kernel.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-fbdev@vger.kernel.org>, <jonathan@marek.ca>
Subject: Re: [PATCH v2 2/3] dt-bindings: backlight: add lm3630a bindings
Date: Tue, 2 Apr 2019 08:44:22 -0500 [thread overview]
Message-ID: <c88d954a-ce37-35dc-414b-df28d6095d89@ti.com> (raw)
In-Reply-To: <20190402132440.GA10359@basecamp>
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
next prev parent reply other threads:[~2019-04-02 13:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-01 10:30 [PATCH v2 0/3] backlight: lm3630a: bug fix and device tree support Brian Masney
2019-04-01 10:30 ` [PATCH v2 1/3] backlight: lm3630a: return 0 on success in update_status functions Brian Masney
2019-04-01 21:34 ` Pavel Machek
2019-04-01 10:30 ` [PATCH v2 2/3] dt-bindings: backlight: add lm3630a bindings Brian Masney
2019-04-01 21:39 ` Pavel Machek
2019-04-01 23:04 ` Brian Masney
2019-04-02 12:56 ` Dan Murphy
2019-04-02 13:24 ` Brian Masney
2019-04-02 13:44 ` Dan Murphy [this message]
2019-04-07 11:28 ` Brian Masney
2019-04-03 1:50 ` Rob Herring
2019-04-01 10:30 ` [PATCH v2 3/3] backlight: lm3630a: add device tree supprt Brian Masney
2019-04-01 21:48 ` Pavel Machek
2019-04-02 0:02 ` Brian Masney
2019-04-02 13:45 ` Dan Murphy
2019-04-02 16:45 ` Pavel Machek
2019-04-02 17:07 ` Dan Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c88d954a-ce37-35dc-414b-df28d6095d89@ti.com \
--to=dmurphy@ti.com \
--cc=b.zolnierkie@samsung.com \
--cc=daniel.thompson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jacek.anaszewski@gmail.com \
--cc=jingoohan1@gmail.com \
--cc=jonathan@marek.ca \
--cc=lee.jones@linaro.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=masneyb@onstation.org \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).