[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17a77e44acea33dc7c43e957bbca7a3f0e863ebb.camel@fi.rohmeurope.com>
Date: Wed, 6 Nov 2019 11:30:23 +0000
From: "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To: "robh@...nel.org" <robh@...nel.org>
CC: "dmurphy@...com" <dmurphy@...com>,
"mazziesaccount@...il.com" <mazziesaccount@...il.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"mark.rutland@....com" <mark.rutland@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"pavel@....cz" <pavel@....cz>,
"jacek.anaszewski@...il.com" <jacek.anaszewski@...il.com>,
"linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>
Subject: Re: SPAM (R/EU IT) // Re: [RFC PATCH 2/5] dt-bindings: an30259a:
example for using fixed LED node names.
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@...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 =]
Powered by blists - more mailing lists