linux-toradex.git/drivers/leds/led-core.c, branch v5.0

leds: core: Fix regression caused by commit 2b83ff96f51d

2018-01-07T12:27:07+00:00

Commit 2b83ff96f51d ("led: core: Fix brightness setting when setting delay_off=0")
replaced del_timer_sync(&led_cdev->blink_timer) with led_stop_software_blink()
in led_blink_set(), which additionally clears LED_BLINK_SW flag as well as
zeroes blink_delay_on and blink_delay_off properties of the struct led_classdev.

Cleansing of the latter ones wasn't required to fix the original issue but
wasn't considered harmful. It nonetheless turned out to be so in case when
pointer to one or both props is passed to led_blink_set() like in the
ledtrig-timer.c. In such cases zeroes are passed later in delay_on and/or
delay_off arguments to led_blink_setup(), which results either in stopping
the software blinking or setting blinking frequency always to 1Hz.

Avoid using led_stop_software_blink() and add a single call required
to clear LED_BLINK_SW flag, which was the only needed modification to
fix the original issue.

Fixes 2b83ff96f51d ("led: core: Fix brightness setting when setting delay_off=0")
Signed-off-by: Jacek Anaszewski

led: core: Fix brightness setting when setting delay_off=0

2017-12-27T19:45:07+00:00

With the current code, the following sequence won't work :
echo timer > trigger

echo 0 >  delay_off
* at this point we call
** led_delay_off_store
** led_blink_set
*** stop timer
** led_blink_setup
** led_set_software_blink
*** if !delay_on, led off
*** if !delay_off, set led_set_brightness_nosleep <--- LED_BLINK_SW is set but timer is stop
*** otherwise start timer/set LED_BLINK_SW flag

echo xxx > brightness
* led_set_brightness
** if LED_BLINK_SW
*** if brightness=0, led off
*** else apply brightness if next timer <--- timer is stop, and will never apply new setting
** otherwise set led_set_brightness_nosleep

To fix that, when we delete the timer, we should clear LED_BLINK_SW.

Cc: linux-leds@vger.kernel.org
Signed-off-by: Matthieu CASTET 
Signed-off-by: Jacek Anaszewski

leds: Convert timers to use timer_setup()

2017-10-25T19:52:22+00:00

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Richard Purdie 
Cc: Pavel Machek 
Cc: Willy Tarreau 
Cc: linux-leds@vger.kernel.org
Signed-off-by: Kees Cook 
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: 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: core: add helpers for calling brightness_set(_blocking)

2016-03-14T08:22:21+00:00

Add helpers for calling brightness_set(_blocking) allowing to
simplify the code and make it better readable.

Signed-off-by: Heiner Kallweit 
Signed-off-by: Jacek Anaszewski

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

2016-03-14T08:22:20+00:00

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: Drivers shouldn't enforce SYNC/ASYNC brightness setting

2016-01-04T08:57:31+00:00

This patch removes SET_BRIGHTNESS_ASYNC and SET_BRIGHTNESS_SYNC flags.
led_set_brightness() now calls led_set_brightness_nosleep() instead of
choosing between sync and async op basing on the flags defined by the
driver.

From now on, if a user wants to make sure that brightness will be set
synchronously, they have to use led_set_brightness_sync() API. It is now
being made publicly available since it has become apparent that it is
a caller who should decide whether brightness is to be set in
a synchronous or an asynchronous way.

Signed-off-by: Jacek Anaszewski 
Acked-by: Sakari Ailus

leds: core: Use set_brightness_work for the blocking op

2016-01-04T08:57:30+00:00

This patch makes LED core capable of setting brightness for drivers
that implement brightness_set_blocking op. It removes from LED class
drivers responsibility for using work queues on their own.

In order to achieve this set_brightness_delayed callback is being
modified to directly call one of available ops for brightness setting.

led_set_brightness_async() function didn't set brightness in an
asynchronous way in all cases. It was mistakenly assuming that all
LED subsystem drivers used work queue in their brightness_set op,
whereas only half of them did that. Since it has no users now,
it is being removed.

Signed-off-by: Jacek Anaszewski 
Acked-by: Sakari Ailus