From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: linux-leds@vger.kernel.org
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
pavel@ucw.cz, robh@kernel.org, dtor@google.com,
linux@roeck-us.net, dmurphy@ti.com, jacek.anaszewski@gmail.com
Subject: [PATCH v5 00/26] Add generic support for composing LED class device name
Date: Sun, 9 Jun 2019 21:07:37 +0200 [thread overview]
Message-ID: <20190609190803.14815-1-jacek.anaszewski@gmail.com> (raw)
Changes from v4:
- switched "charge" function name to "charging"
- added "cpu", "mute", "micmute", "disk-activity", "panic", "mtd" LED functions
to cover all existing triggers and removed now redundant "nand" and "mmc"
- added "capslock", "scrollock", "numlock" LED functions
- removed now redundant "keyboard" and "keypad" since there is "kbd_backlight"
already available
- removed "tv" LED function as depreciated
- switched LED_COLOR_ID_COUNT to LED_COLOR_ID_MAX
- fixed led_classdev_register_ext() to not leave struct led_classdev's
name pointing to no longer existing composed_name stack variable
- fixed leds-as3645 and leds-aat1290 to no longer rely on struct led_classdev's
name property
- added basic LED class device name validation to get_led_device_info.sh
- tweaked LED naming section in leds_class.txt to allow devicename section
also for non hot-pluggable devices
- always initialize all fields of struct led_init_data to zero on declaration
in drivers
- fix leds-gpio to avoid overwriting the LED name coming from platform_data
- add description of LED function names with regard to whether devicename
section is initialized or not
Changes from v3:
- allow for devicename section for hot-pluggable devices
- move led_colors array to led-core.c to avoid build break
due to Kconfig dependency issue
- add a patch fixing led_colors array name clash with ALSA driver
- change led-enumerator DT property name to more meaningful function-enumerator
- add LED_FUNCTION_KBD_BACKLIGHT
- change naming and add new proprties to struct led_init_data
and struct led_properties
Changes from v2:
- removed from drivers the responsibility of calling led_compose_name()
- added struct device* argument to led_compose_name() to allow using
dev_<level> logging functions for more informative logs
- adjusted the list of LED_FUNCTION definitions according to the v2 review
remarks
- renamed default_desc to default_label in the struct led_init_data
- added led-enumerator DT property to the common LED bindings
- removed LED_COLOR_NAME definitions from include/dt-bindings/leds/common.h
- change DT color property type from string to integer
- change struct initialization list to explicit property assignment in leds-sc27xx-bltc.c
- use led->client->name for led_hw_name in leds-lm3692x.c
- few other minor improvements to docs etc.
Changes from v1:
- improved led_parse_properties() to parse label property at first
and return immediately after parsing succeeds
- added tool get_led_device_info.sh for retrieving LED class device's
parent device related information
- extended LED naming section of Documentation/leds/leds-class.txt
- adjusted the list of LED_FUNCTION definitions according to the v1 review
remarks
- added standard LED_COLOR_NAME definitions
- removed functions.h and moved both LED_FUNCTION and LED_COLOR_NAME
definitions to include/dt-bindings/common.h
- rebased leds-as3645a changes on top of the patch switching to fwnode
property API
- updated DT bindings to use new LED_COLOR_NAME definitions
- improved common LED bindings to not use address unit for sub-nodes
without reg property
Generally I still insist on deprecating label property and devicename
section of LED name. The tool I added for obtaining LED device name
proves availability of the related information in other places in
the sysfs. Other discussed use cases are covered in the updated
Documentation/leds/leds-class.txt.
Beside that, I tried also to create macros for automatic composition
of "-N" suffixed LED functions, so that it would not be necessary
to pollute common.h with plenty repetitions of the same function,
differing only with the postfix. Unfortunately, the preprocessor
of the dtc compiler seems not to accept string concatenetation.
I.e. it is not possible to to the following assighment:
function = "hdd""-1"
If anyone knows how to obviate this shortocoming please let me know.
Original cover letter:
LED class device naming pattern included devicename section, which had
unpleasant effect of varying userspace interface dependent on underlaying
hardware. Moreover, this information was redundant in the LED name, since
the LED controller name could have been obtained from sysfs device group
This patch set introduces a led_compose_name() function in the LED core,
which unifies and simplifies LED class device name composition. This
change is accompanied by the improvements in the common LED DT bindings
where two new properties are introduced: "function" and "color" . The two
deprecate the old "label" property which was leaving too much room for
interpretation, leading to inconsistent LED naming.
There are also changes in LED DT node naming, which are in line with
DT maintainer's request from [0].
Since some DT LED naming unification, related to not including devicename
section in "label" DT property, is being requested during reviews of new
LED class drivers for almost a year now, then those drivers are the first
candidates for optimalization and the first users of the new
led_compose_name() API. The modifications were tested with Qemu,
by stubbing the driver internals where hardware interaction was needed
for proper probing.
Thanks,
Jacek Anaszewski
Jacek Anaszewski (26):
leds: class: Improve LED and LED flash class registration API
dt-bindings: leds: Add LED_COLOR_ID definitions
dt-bindings: leds: Add LED_FUNCTION definitions
dt-bindings: leds: Add properties for LED name construction
leds: core: Add support for composing LED class device names
dt-bindings: sc27xx-blt: Add function and color properties
leds: sc27xx-blt: Use generic support for composing LED names
dt-bindings: lt3593: Add function and color properties
leds: lt3593: Use generic support for composing LED names
dt-bindings: lp8860: Add function and color properties
leds: lp8860: Use generic support for composing LED names
dt-bindings: lm3692x: Add function and color properties
leds: lm3692x: Use generic support for composing LED names
dt-bindings: lm36010: Add function and color properties
leds: lm3601x: Use generic support for composing LED names
dt-bindings: cr0014114: Add function and color properties
leds: cr0014114: Use generic support for composing LED names
dt-bindings: aat1290: Add function and color properties
leds: aat1290: Use generic support for composing LED names
dt-bindings: as3645a: Add function and color properties
leds: as3645a: Use generic support for composing LED names
dt-bindings: leds-gpio: Add function and color properties
leds: gpio: Use generic support for composing LED names
dt-bindings: an30259a: Add function and color properties
leds: an30259a: Use generic support for composing LED names
leds: Document standard LED functions
.../devicetree/bindings/leds/ams,as3645a.txt | 22 +-
Documentation/devicetree/bindings/leds/common.txt | 62 +++++-
.../devicetree/bindings/leds/leds-aat1290.txt | 12 +-
.../devicetree/bindings/leds/leds-an30259a.txt | 22 +-
.../devicetree/bindings/leds/leds-cr0014114.txt | 26 ++-
.../devicetree/bindings/leds/leds-gpio.txt | 23 ++-
.../devicetree/bindings/leds/leds-lm3601x.txt | 10 +-
.../devicetree/bindings/leds/leds-lm3692x.txt | 9 +-
.../devicetree/bindings/leds/leds-lp8860.txt | 9 +-
.../devicetree/bindings/leds/leds-lt3593.txt | 11 +-
.../devicetree/bindings/leds/leds-sc27xx-bltc.txt | 10 +-
Documentation/leds/led-functions.txt | 223 +++++++++++++++++++++
Documentation/leds/leds-class.txt | 70 ++++++-
drivers/leds/led-class-flash.c | 9 +-
drivers/leds/led-class.c | 49 +++--
drivers/leds/led-core.c | 127 ++++++++++++
drivers/leds/leds-aat1290.c | 16 +-
drivers/leds/leds-an30259a.c | 25 +--
drivers/leds/leds-as3645a.c | 74 +++----
drivers/leds/leds-cr0014114.c | 33 +--
drivers/leds/leds-gpio.c | 26 +--
drivers/leds/leds-lm3601x.c | 38 ++--
drivers/leds/leds-lm3692x.c | 22 +-
drivers/leds/leds-lp8860.c | 35 ++--
drivers/leds/leds-lt3593.c | 20 +-
drivers/leds/leds-pwm.c | 2 +-
drivers/leds/leds-sc27xx-bltc.c | 22 +-
drivers/leds/leds.h | 1 +
include/dt-bindings/leds/common.h | 55 ++++-
include/linux/led-class-flash.h | 15 +-
include/linux/leds.h | 79 +++++++-
tools/leds/get_led_device_info.sh | 201 +++++++++++++++++++
32 files changed, 1086 insertions(+), 272 deletions(-)
create mode 100644 Documentation/leds/led-functions.txt
create mode 100755 tools/leds/get_led_device_info.sh
--
2.11.0
next reply other threads:[~2019-06-09 19:08 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-09 19:07 Jacek Anaszewski [this message]
2019-06-09 19:07 ` [PATCH v5 01/26] leds: class: Improve LED and LED flash class registration API Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 02/26] dt-bindings: leds: Add LED_COLOR_ID definitions Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 03/26] dt-bindings: leds: Add LED_FUNCTION definitions Jacek Anaszewski
2019-11-15 13:01 ` Geert Uytterhoeven
2019-11-15 20:14 ` Jacek Anaszewski
2019-11-25 15:17 ` Pavel Machek
2019-06-09 19:07 ` [PATCH v5 04/26] dt-bindings: leds: Add properties for LED name construction Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 05/26] leds: core: Add support for composing LED class device names Jacek Anaszewski
2019-06-26 19:05 ` Jacek Anaszewski
2019-06-26 20:07 ` Oleh Kravchenko
2019-06-27 18:28 ` Jacek Anaszewski
2019-06-28 8:46 ` Linus Walleij
2019-06-28 13:30 ` David Laight
2019-07-03 22:05 ` Various LED complexities was " Pavel Machek
2019-07-03 22:00 ` Pavel Machek
2019-07-17 21:03 ` Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 06/26] dt-bindings: sc27xx-blt: Add function and color properties Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 07/26] leds: sc27xx-blt: Use generic support for composing LED names Jacek Anaszewski
2019-06-10 2:52 ` Baolin Wang
2019-06-09 19:07 ` [PATCH v5 08/26] dt-bindings: lt3593: Add function and color properties Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 09/26] leds: lt3593: Use generic support for composing LED names Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 10/26] dt-bindings: lp8860: Add function and color properties Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 11/26] leds: lp8860: Use generic support for composing LED names Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 12/26] dt-bindings: lm3692x: Add function and color properties Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 13/26] leds: lm3692x: Use generic support for composing LED names Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 14/26] dt-bindings: lm36010: Add function and color properties Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 15/26] leds: lm3601x: Use generic support for composing LED names Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 16/26] dt-bindings: cr0014114: Add function and color properties Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 17/26] leds: cr0014114: Use generic support for composing LED names Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 18/26] dt-bindings: aat1290: Add function and color properties Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 19/26] leds: aat1290: Use generic support for composing LED names Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 20/26] dt-bindings: as3645a: Add function and color properties Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 21/26] leds: as3645a: Use generic support for composing LED names Jacek Anaszewski
2019-06-09 19:07 ` [PATCH v5 22/26] dt-bindings: leds-gpio: Add function and color properties Jacek Anaszewski
2019-06-09 19:08 ` [PATCH v5 23/26] leds: gpio: Use generic support for composing LED names Jacek Anaszewski
2019-06-09 19:08 ` [PATCH v5 24/26] dt-bindings: an30259a: Add function and color properties Jacek Anaszewski
2019-06-09 19:08 ` [PATCH v5 25/26] leds: an30259a: Use generic support for composing LED names Jacek Anaszewski
2019-06-09 19:08 ` [PATCH v5 26/26] leds: Document standard LED functions Jacek Anaszewski
2019-07-18 11:03 ` Pavel Machek
2019-07-18 13:31 ` Jacek Anaszewski
2019-07-17 21:14 ` [PATCH v5 00/26] Add generic support for composing LED class device name Jacek Anaszewski
2019-07-18 10:52 ` Pavel Machek
2019-07-24 21:02 ` Jacek Anaszewski
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=20190609190803.14815-1-jacek.anaszewski@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=dtor@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux@roeck-us.net \
--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).