linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).