From: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
To: "robh@kernel.org" <robh@kernel.org>
Cc: "dmurphy@ti.com" <dmurphy@ti.com>,
"mazziesaccount@gmail.com" <mazziesaccount@gmail.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"pavel@ucw.cz" <pavel@ucw.cz>,
"jacek.anaszewski@gmail.com" <jacek.anaszewski@gmail.com>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>
Subject: Re: SPAM (R/EU IT) // Re: [RFC PATCH 2/5] dt-bindings: an30259a: example for using fixed LED node names.
Date: Wed, 6 Nov 2019 11:30:23 +0000 [thread overview]
Message-ID: <17a77e44acea33dc7c43e957bbca7a3f0e863ebb.camel@fi.rohmeurope.com> (raw)
In-Reply-To: <20191106034206.GA6299@bogus>
Hello Rob & All,
On Tue, 2019-11-05 at 21:42 -0600, Rob Herring wrote:
> On Tue, Oct 29, 2019 at 02:47:26PM +0200, Matti Vaittinen wrote:
> > Use predefined LED node name to match the LED node in driver.
> >
> > It would be nice to offload common LED property parsing to
> > LED core driver. One of the key things to allow this is somehow
> > 'pair' the LED DT node with LED driver initialization data.
> >
> > This patch uses LED node name as a 'key' in a same fashion
> > as regulators do. The an30259a was selected as demonstration
> > example and this change may not be really feasible for an30259a
> > as I have no idea whether the existing DTs for devices out there
> > have specific node names (or can be changed). This servers just
> > as an example to initiate discussion as to how we could pair the
> > driver data and DT node.
> >
> > Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> > ---
> > Documentation/devicetree/bindings/leds/leds-an30259a.txt | 9
> > +++++----
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/leds/leds-
> > an30259a.txt b/Documentation/devicetree/bindings/leds/leds-
> > an30259a.txt
> > index cbd833906b2b..bd1a2d11a0ad 100644
> > --- a/Documentation/devicetree/bindings/leds/leds-an30259a.txt
> > +++ b/Documentation/devicetree/bindings/leds/leds-an30259a.txt
> > @@ -9,7 +9,8 @@ Required properties:
> > - #address-cells: Must be 1.
> > - #size-cells: Must be 0.
> >
> > -Each LED is represented as a sub-node of the panasonic,an30259a
> > node.
> > +Each LED is represented as a sub-node of the panasonic,an30259a
> > node. LED nodes
> > +must be named as led1 led2 and led3.
> >
> > Required sub-node properties:
> > - reg: Pin that the LED is connected to. Must be 1, 2, or 3.
> > @@ -34,20 +35,20 @@ led-controller@30 {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > - led@1 {
> > + led1 {
> > reg = <1>;
>
> This is wrong. reg requires a unit-address and vice-versa.
Right.
I'd be interested to know how using node name(s) to match the driver
data (like regulators do) is seen in general? Is this a bad idea for
LEDs? Would it be better to have a leds-compatible (like we had
regulator-compatible before)?
If node names can be used - would
led1@1 {
};
led2@2 {
};
... do?
Using node names as key requires them to be unique. Other option could
be doing the search based on node name and unit-address combination -
but if unit-address depends on board the led is placed - then driver
might not know it. Should I convert the RFC to introduce and use led-
compatible?
> > linux,default-trigger = "heartbeat";
> > function = LED_FUNCTION_INDICATOR;
> > color = <LED_COLOR_ID_RED>;
> > };
> >
> > - led@2 {
> > + led2 {
> > reg = <2>;
> > function = LED_FUNCTION_INDICATOR;
> > color = <LED_COLOR_ID_GREEN>;
> > };
> >
> > - led@3 {
> > + led3 {
> > reg = <3>;
> > function = LED_FUNCTION_INDICATOR;
> > color = <LED_COLOR_ID_BLUE>;
> > --
> > 2.21.0
> >
> >
> > --
> > Matti Vaittinen, Linux device drivers
> > ROHM Semiconductors, Finland SWDC
> > Kiviharjunlenkki 1E
> > 90220 OULU
> > FINLAND
> >
> > ~~~ "I don't think so," said Rene Descartes. Just then he vanished
> > ~~~
> > Simon says - in Latin please.
> > ~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
> > Thanks to Simon Glass for the translation =]
next prev parent reply other threads:[~2019-11-06 11:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-29 12:46 [RFC PATCH 0/5] leds: Add DT node finding and parsing to core Matti Vaittinen
2019-10-29 12:46 ` [RFC PATCH 1/5] leds: Add common LED binding parsing support to LED class/core Matti Vaittinen
2019-10-29 12:47 ` [RFC PATCH 2/5] dt-bindings: an30259a: example for using fixed LED node names Matti Vaittinen
2019-11-06 3:42 ` Rob Herring
2019-11-06 11:30 ` Vaittinen, Matti [this message]
2019-10-29 12:47 ` [RFC PATCH 3/5] leds: an30259a: Offload DT node locating and parsing to core Matti Vaittinen
2019-10-29 12:48 ` [RFC PATCH 4/5] dt-bindings: lm3692x: example for using fixed LED node names Matti Vaittinen
2019-10-29 12:48 ` [RFC PATCH 5/5] leds: lm3692x: Offload DT node locating and parsing to core Matti Vaittinen
2019-11-18 9:21 ` [RFC PATCH 0/5] leds: Add DT node finding " Enrico Weigelt, metux IT consult
2019-11-18 10:38 ` Vaittinen, Matti
2019-11-19 19:52 ` Enrico Weigelt, metux IT consult
2019-11-20 7:37 ` Vaittinen, Matti
2020-02-09 22:46 ` Pavel Machek
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=17a77e44acea33dc7c43e957bbca7a3f0e863ebb.camel@fi.rohmeurope.com \
--to=matti.vaittinen@fi.rohmeurope.com \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mazziesaccount@gmail.com \
--cc=pavel@ucw.cz \
--cc=robh@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).