Re: SPAM (R/EU IT) // Re: [RFC PATCH 2/5] dt-bindings: an30259a: example for using fixed LED node names.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxx>
> > ---
> >  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 =] 





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux