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

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

leds: convert IDE trigger to common disk trigger

2016-06-20T07:57:56Z

This patch converts the IDE specific LED trigger to a generic disk activity LED trigger. The libata core is now a trigger source just like before the IDE disk driver. It's merely a replacement of the string ide by disk. The patch is taken from http://dev.gentoo.org/~josejx/ata.patch and is widely used by any ibook/powerbook owners with great satisfaction. Likewise, it is very often used successfully on different ARM platforms. Unlike the original patch, the existing 'ide-disk' trigger is still available for backward compatibility. That reduce the amount of patches in affected device trees out of the mainline kernel. For further development, the new name 'disk-activity' should be used. Cc: Joseph Jezak Cc: Jörg Sommer Cc: Richard Purdie Signed-off-by: Stephan Linz Signed-off-by: Jacek Anaszewski

leds: core: Fix brightness setting upon hardware blinking enabled

2016-06-08T09:47:06Z

Commit 76931edd54f8 ("leds: fix brightness changing when software blinking is active") changed the semantics of led_set_brightness() which according to the documentation should disable blinking upon any brightness setting. Moreover it made it different for soft blink case, where it was possible to change blink brightness, and for hardware blink case, where setting any brightness greater than 0 was ignored. While the change itself is against the documentation claims, it was driven also by the fact that timer trigger remained active after turning blinking off. Fixing that would have required major refactoring in the led-core, led-class, and led-triggers because of cyclic dependencies. Finally, it has been decided that allowing for brightness change during blinking is beneficial as it can be accomplished without disturbing blink rhythm. The change in brightness setting semantics will not affect existing LED class drivers that implement blink_set op thanks to the LED_BLINK_SW flag introduced by this patch. The flag state will be from now on checked in led_set_brightness() which will allow to distinguish between software and hardware blink mode. In the latter case the control will be passed directly to the drivers which apply their semantics on brightness set, which is disable the blinking in case of most such drivers. New drivers will apply new semantics and just change the brightness while hardware blinking is on, if possible. The issue was smuggled by subsequent LED core improvements, which modified the code that originally introduced the problem. Fixes: f1e80c07416a ("leds: core: Add two new LED_BLINK_ flags") Signed-off-by: Tony Makkiel Signed-off-by: Jacek Anaszewski

leds: gpio: Support the "panic-indicator" firmware property

2016-05-06T08:26:07Z

Calling a GPIO LEDs is quite likely to work even if the kernel has paniced, so they are ideal to blink in this situation. This commit adds support for the new "panic-indicator" firmware property, allowing to mark a given LED to blink on a kernel panic. Signed-off-by: Ezequiel Garcia Reviewed-by: Matthias Brugger Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: triggers: Allow to switch the trigger to "panic" on a kernel panic

2016-05-06T08:22:09Z

This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which allows to mark a specific LED to be switched to the "panic" trigger, on a kernel panic. This is useful to allow the user to assign a regular trigger to a given LED, and still blink that LED on a kernel panic. Signed-off-by: Ezequiel Garcia Reviewed-by: Matthias Brugger Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: trigger: Introduce a MTD (NAND/NOR) trigger

2016-04-13T08:23:14Z

This commit introduces a MTD trigger for flash (NAND/NOR) device activity. The implementation is copied from IDE disk. This trigger deprecates the "nand-disk" LED trigger, but for backwards compatibility, we still keep the "nand-disk" trigger around. The motivation for deprecating the "nand-disk" LED trigger is that it only works for NAND drivers, whereas the "mtd" LED trigger is more generic (in fact, "nand-disk" currently only works for certain NAND drivers). Signed-off-by: Ezequiel Garcia Acked-by: Boris Brezillon Signed-off-by: Jacek Anaszewski

leds: core: avoid error message when a USB LED device is unplugged

2016-03-14T08:22:20Z

When a USB LED device is unplugged the remove call chain calls led_classdev_unregister which tries to switch the LED off. As the device has been removed already this results in a ENODEV error message in dmesg. Avoid this error message by ignoring ENODEV in calls from led_classdev_unregister if the LED device is flagged as pluggable. Therefore a new flag LED_HW_PLUGGABLE was introduced which should be set by all LED drivers handling pluggable LED devices (mainly USB LED devices). Signed-off-by: Heiner Kallweit Signed-off-by: Jacek Anaszewski

leds: core: fix misleading comment after workqueue removal from drivers

2016-03-14T08:22:20Z

Now that workqueues have been removed from individual drivers and were replaced with a core-internal workqueue we shouldn't encourage people to add new workqueues to drivers. Signed-off-by: Heiner Kallweit Signed-off-by: Jacek Anaszewski

leds: core: add managed version of led_trigger_register

2016-01-04T08:57:40Z

Complementing devm_led_classdev_register add a managed version of led_trigger_register. I omit a managed version of led_classdev_unregister as the equivalent devm_led_classdev_unregister isn't used in the kernel as of today. Signed-off-by: Heiner Kallweit Signed-off-by: Jacek Anaszewski