linux-toradex.git/include/linux/leds.h, branch v4.11-rc3

leds: class: Add new optional brightness_hw_changed attribute

2017-01-29T18:59:42+00:00

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:05+00:00

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:05+00:00

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:05+00:00

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:39+00:00

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:42+00:00

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:56+00:00

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:06+00:00

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:07+00:00

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:09+00:00

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