| Message ID | 5b9f9e7cd3dc959962fc43d27e471245e63f5f29.1572351774.git.matti.vaittinen@fi.rohmeurope.com |
|---|---|
| State | Rejected, archived |
| Headers | show |
| Series | leds: Add DT node finding and parsing to core | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success |
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. > 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 =]
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 =]
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>; 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>;
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(-)