diff options
author | Hans de Goede <hdegoede@redhat.com> | 2017-01-29 16:42:52 +0300 |
---|---|---|
committer | Jacek Anaszewski <jacek.anaszewski@gmail.com> | 2017-01-29 21:59:42 +0300 |
commit | 0cb8eb30d425d2d2ae28ab630596c44a158784c4 (patch) | |
tree | 8f715703e9e929f615160d3b326f5fff2708d670 /Documentation | |
parent | cbe99c538d1776009e8710755bb6e726f7fffa9b (diff) | |
download | linux-0cb8eb30d425d2d2ae28ab630596c44a158784c4.tar.xz |
leds: class: Add new optional brightness_hw_changed attribute
Some LEDs may have their brightness level changed autonomously
(outside of kernel control) by hardware / firmware. This commit
adds support for an optional brightness_hw_changed attribute to
signal such changes to userspace (if a driver can detect them):
What: /sys/class/leds/<led>/brightness_hw_changed
Date: January 2017
KernelVersion: 4.11
Description:
Last hardware set brightness level for this LED. Some LEDs
may be changed autonomously by hardware/firmware. Only LEDs
where this happens and the driver can detect this, will
have this file.
This file supports poll() to detect when the hardware
changes the brightness.
Reading this file will return the last brightness level set
by the hardware, this may be different from the current
brightness.
Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to
their flags field and call led_classdev_notify_brightness_hw_changed()
with the hardware set brightness when they detect a hardware / firmware
triggered brightness change.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/ABI/testing/sysfs-class-led | 17 | ||||
-rw-r--r-- | Documentation/leds/leds-class.txt | 15 |
2 files changed, 32 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index 491cdeedc195..5f67f7ab277b 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led @@ -23,6 +23,23 @@ Description: If the LED does not support different brightness levels, this should be 1. +What: /sys/class/leds/<led>/brightness_hw_changed +Date: January 2017 +KernelVersion: 4.11 +Description: + Last hardware set brightness level for this LED. Some LEDs + may be changed autonomously by hardware/firmware. Only LEDs + where this happens and the driver can detect this, will have + this file. + + This file supports poll() to detect when the hardware changes + the brightness. + + Reading this file will return the last brightness level set + by the hardware, this may be different from the current + brightness. Reading this file when no hw brightness change + event has happened will return an ENODATA error. + What: /sys/class/leds/<led>/trigger Date: March 2006 KernelVersion: 2.6.17 diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt index f1f7ec9f5cc5..836cb16d6f09 100644 --- a/Documentation/leds/leds-class.txt +++ b/Documentation/leds/leds-class.txt @@ -65,6 +65,21 @@ LED subsystem core exposes following API for setting brightness: blinking, returns -EBUSY if software blink fallback is enabled. +LED registration API +==================== + +A driver wanting to register a LED classdev for use by other drivers / +userspace needs to allocate and fill a led_classdev struct and then call +[devm_]led_classdev_register. If the non devm version is used the driver +must call led_classdev_unregister from its remove function before +free-ing the led_classdev struct. + +If the driver can detect hardware initiated brightness changes and thus +wants to have a brightness_hw_changed attribute then the LED_BRIGHT_HW_CHANGED +flag must be set in flags before registering. Calling +led_classdev_notify_brightness_hw_changed on a classdev not registered with +the LED_BRIGHT_HW_CHANGED flag is a bug and will trigger a WARN_ON. + Hardware accelerated blink of LEDs ================================== |