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

leds: triggers: new function led_set_trigger_data()

2018-07-05T21:21:11Z

This is the natural counter part to the already existing led_get_trigger_data(). Signed-off-by: Uwe Kleine-König Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: triggers: define module_led_trigger helper

2018-07-05T21:21:11Z

This helps to simplify modules that provide a simple led_trigger. It's inspired by module_platform_driver, module_i2c_driver et al. Signed-off-by: Uwe Kleine-König Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: triggers: add device attribute support

2018-07-05T21:21:10Z

As many triggers use device attributes, add support for these in led_trigger_set which allows simplifying the drivers accordingly. Signed-off-by: Uwe Kleine-König Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: triggers: let struct led_trigger::activate() return an error code

2018-07-05T21:21:10Z

Given that activating a trigger can fail, let the callback return an indication. This prevents to have a trigger active according to the "trigger" sysfs attribute but not functional. All users are changed accordingly to return 0 for now. There is no intended change in behaviour. Signed-off-by: Uwe Kleine-König Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

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