Two auto corrections:
On 3/10/19 7:28 PM, Jacek Anaszewski wrote:
Add public led_compose_name() API for composing LED class device
name basing on fwnode_handle data. The function composes device name
according to either a new <color:function> pattern or the legacy
<devicename:color:function> pattern. The decision on using the
particular pattern is made basing on whether fwnode contains new
"function" and "color" properties, or the legacy "label" proeprty.
Backwards compatibility with in-driver hard-coded LED class device
names is assured thanks to the default_desc argument.
In case none of the aforementioned properties was found, then, for OF
nodes, the node name is adopted for LED class device name.
Alongside these changes added is a new tool - tools/leds/get_led_device_info.sh.
The tool allows retrieving details of a LED class device's parent device,
which proves that getting rid of a devicename section from LED name pattern
is justified since this information is already available in sysfs.
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>
Cc: Baolin Wang <baolin.wang@xxxxxxxxxx>
Cc: Daniel Mack <daniel@xxxxxxxxxx>
Cc: Dan Murphy <dmurphy@xxxxxx>
Cc: Linus Walleij <linus.walleij@xxxxxxxxxx>
Cc: Oleh Kravchenko <oleg@xxxxxxxxxx>
Cc: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>
---
Documentation/leds/leds-class.txt | 20 +++++++++-
drivers/leds/led-core.c | 82 +++++++++++++++++++++++++++++++++++++++
include/linux/leds.h | 31 +++++++++++++++
tools/leds/get_led_device_info.sh | 81 ++++++++++++++++++++++++++++++++++++++
4 files changed, 213 insertions(+), 1 deletion(-)
create mode 100755 tools/leds/get_led_device_info.sh
diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt
index 8b39cc6b03ee..866fe87063d4 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -43,7 +43,22 @@ LED Device Naming
Is currently of the form:
-"devicename:colour:function"
+"colour:function"
+
+There might be still LED class drivers around using "devicename:colour:function"
+naming pattern, but the "devicename" section is now deprecated since it used
+to convey information that was already available in the sysfs, like product
+name. There is a tool (tools/leds/get_led_device_info.sh) available for
+retrieving that information per a LED class device.
+
+Associations with other devices, like network ones, should be defined
+via LED triggr mechanism. This approach is applied by some of wireless
s/triggr/trigger/
+network drivers that create triggers dynamically and incorporate phy
+name into its name. On the other hand input subsystem offers LED - input
s/its name/the trigger name/
+bridge (drivers/input/input-leds.c) for exposing keyboard LEDs as LED class
+devices. The get_led_device_info.sh script has support for retrieving related
+input device node name. Should it support discovery of associations between
+LEDs and other subsystems, please don't hesitate to submit a relevant patch.
There have been calls for LED properties such as colour to be exported as
individual led class attributes. As a solution which doesn't incur as much
@@ -51,6 +66,9 @@ overhead, I suggest these become part of the device name. The naming scheme
above leaves scope for further attributes should they be needed. If sections
of the name don't apply, just leave that section blank.
+Please also keep in mind that LED subsystem has a protection against LED name
+conflict. It adds numerical suffix (e.g. "_1", "_2", "_3" etc.) to the requested
+LED class device name in case it is already in use.
--
Best regards,
Jacek Anaszewski
