Message-ID: <cover.1572351774.git.matti.vaittinen@fi.rohmeurope.com>
Date:   Tue, 29 Oct 2019 14:46:20 +0200
From:   Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
To:     mazziesaccount@...il.com, matti.vaittinen@...rohmeurope.com
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, Dan Murphy <dmurphy@...com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-leds@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [RFC PATCH 0/5] leds: Add DT node finding and parsing to core

RFC series improving common LED binding parsing support

Qucik grep for 'for_each' or 'linux,default-trigger' says it all.

Multiple LED controller drivers implement the very similar looping
through the child DT nodes in order to locate the LED nodes and read
and support the common LED dt bindings. Implementing this same
stuff for all LED controllers gets old pretty fast.

This RFC contains 3 suggestions:

Simplest is adding support for parsing the linux,default-trigger,
and default-state DT properties in led-core.

More interesting part is adding correct LED DT node lookup in
LED core. This RFC uses LED DT node names as a 'key' in a same
way regulator framework does for regulators. The thing is that
this approach requires the LED controller binding to dictate allowed
LED node names - which may or may not be doable. I need your help to
evaluate this and suggest better options :) If we still look at the
regulators, the regulator core did originally use "regulator-core"
property to do driver data/DT node pairing - but has since then
changed the approach to using the DT node names.

Last and least clear point is isolating the led_classdev to be owned
by the LED core. Controller drivers should pretty much never touch
it after the initialization. So one approach would be that drivers
only provided initialization data and operations to the core.

The patch series contains the led-core and led-class changes which
introduce (yet another) APIs for registering led class device to
core. Adding new interface is probably not the best option - one
might consider changing the (devm_)led_classdev_register_ext to do
what this new RFC API is doing.

In addition to core changes this series converted two (randomly
selected) existing drivers to use the new API. This can give an
overview how offloading the DT parsing to core could simplify many
of the LED controlled drivers.

Patches HAVE NOT BEEN TESTED other than for compiling. They are
only intended to be a starting point for discussion - and if the
ideas are seen worthy - then the patches should be further worked
and properly tested before being applied.

Matti Vaittinen (5):
  leds: Add common LED binding parsing support to LED class/core
  dt-bindings: an30259a: example for using fixed LED node names.
  leds: an30259a: Offload DT node locating and parsing to core
  dt-bindings: lm3692x: example for using fixed LED node names.
  leds: lm3692x: Offload DT node locating and parsing to core

 .../bindings/leds/leds-an30259a.txt           |   9 +-
 .../devicetree/bindings/leds/leds-lm3692x.txt |   4 +-
 drivers/leds/led-class.c                      | 247 +++++++++++++++++-
 drivers/leds/led-core.c                       | 111 +++++---
 drivers/leds/leds-an30259a.c                  | 181 ++++++-------
 drivers/leds/leds-lm3692x.c                   |  75 +++---
 include/linux/leds.h                          | 144 +++++++++-
 7 files changed, 586 insertions(+), 185 deletions(-)

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