user/sven/linux.git/include/linux/leds.h, branch v4.18.8

leds: Extends disk trigger for reads and writes

2018-03-11T19:01:55Z

This adds two new disk triggers for triggering on reads and writes respectively, named "disk-read" and "disk-write". The use case comes from working on the D-Link DNS-313 NAS box. This features an RGB LED for disk activity. with these two triggers I can couple the green LED to read activity and the red LED to write activity, which gives the appropriate user feedback about what is happening on the disk. When tested it gave exactly the feedback desired. The in-kernel interface is simply changed to pass a bool indicating if the activity is write activity and update each trigger (and the composite "disk-activity" trigger) depending on what is passed in. Signed-off-by: Linus Walleij Reviewed-by: Bartlomiej Zolnierkiewicz Acked-by: Pavel Machek Acked-by: Tejun Heo Acked-by: David S. Miller Signed-off-by: Jacek Anaszewski

leds: Replace flags bit shift with BIT() macros

2017-10-06T19:31:03Z

This is for readability as well as to avoid checkpatch warnings when adding new bit flag information in the future. Signed-off-by: David Lin Signed-off-by: Jacek Anaszewski

leds: gpio: Allow LED to retain state at shutdown

2017-08-29T19:10:40Z

In some systems, such as Baseboard Management Controllers (BMCs), we want to retain the state of LEDs across a reboot of the BMC (whilst the host remains up). Implement support for the retain-state-shutdown devicetree property in leds-gpio. Signed-off-by: Andrew Jeffery Acked-by: Pavel Machek Tested-by: Brandon Wyman Signed-off-by: Jacek Anaszewski

leds: core: add OF variants of LED registering functions

2017-03-08T20:10:01Z

These new functions allow passing an additional device_node argument that will be internally set for created LED device. Thanks to this LED core code and triggers will be able to access DT node for reading extra info. The easiest solution for achieving this was reworking old functions to more generic ones & adding simple defines for API compatibility. Signed-off-by: Rafał Miłecki Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: class: Add new optional brightness_hw_changed attribute

2017-01-29T18:59:42Z

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//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 Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: add LED_ON brightness as boolean value

2017-01-05T22:01:05Z

Some devices do not handle the led brightness or simply don't care about it. Conceptually said devices want to just switch on or off the led. It is useless in this case to have a 255 range of brightness, while just having an LED_ON and LED_OFF improves the boolean meaning of the led status. Signed-off-by: Andi Shyti Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

led: core: Fix blink_brightness setting race

2016-11-22T11:07:05Z

All 3 of led_timer_func, led_set_brightness and led_set_software_blink set blink_brightness. If led_timer_func or led_set_software_blink race with led_set_brightness they may end up overwriting the new blink_brightness. The new atomic work_flags does not protect against this as it just protects the flags and not blink_brightness. This commit introduces a new new_blink_brightness value which gets set by led_set_brightness and read by led_timer_func on LED on, fixing this. Dealing with the new brightness at LED on time, makes the new brightness apply sooner, which also fixes a led_set_brightness which happens while a oneshot blink which ends in LED on is running not getting applied. Signed-off-by: Hans de Goede Signed-off-by: Jacek Anaszewski

led: core: Use atomic bit-field for the blink-flags

2016-11-22T11:07:05Z

All the LED_BLINK* flags are accessed read-modify-write from e.g. led_set_brightness and led_blink_set_oneshot while both set_brightness_work and the blink_timer may be running. If these race then the modify step done by one of them may be lost, switch the LED_BLINK* flags to a new atomic work_flags bit-field to avoid this race. Signed-off-by: Hans de Goede Signed-off-by: Jacek Anaszewski

leds: gpio: introduce gpio_blink_set_t

2016-09-15T14:49:39Z

Introduce a typedef gpio_blink_set_t to improve readability of the code. Signed-off-by: Heiner Kallweit Signed-off-by: Jacek Anaszewski

leds: Add no-op gpio_led_register_device when LED subsystem is disabled

2016-06-27T06:58:42Z

Some systems use 'gpio_led_register_device' to make an in-memory copy of their LED device table so the original can be removed as .init.rodata. When the LED subsystem is not enabled source in the led directory is not built and so this function may be undefined. Fix this here. Signed-off-by: Andrew F. Davis Signed-off-by: Jacek Anaszewski