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

leds: disallow /sys/class/leds/:multi: for now

2020-08-03T12:00:06+00:00

All the LEDs in the queue are RGB, so they should not use multi for
their color.

Make sure we don't add such LED by mistake (and make it part of ABI).

Signed-off-by: Pavel Machek

leds: add RGB color option, as that is different from multicolor.

2020-08-03T11:26:15+00:00

Multicolor is a bit too abstract. Yes, we can have
Green-Magenta-Ultraviolet LED, but so far all the LEDs we support are
RGB, and not even RGB-White or RGB-Yellow variants emerged.

Multicolor is not a good fit for RGB LED. It does not really know
about LED color.  In particular, there's no way to make LED "white".

Userspace is interested in knowing "this LED can produce arbitrary
color", which not all multicolor LEDs can.

Signed-off-by: Pavel Machek

leds: Add multicolor ID to the color ID list

2020-07-15T17:33:16+00:00

Add a new color ID that is declared as MULTICOLOR as with the
multicolor framework declaring a definitive color is not accurate
as the node can contain multiple colors.

Signed-off-by: Dan Murphy 
Reviewed-by: Marek Behún 
Signed-off-by: Pavel Machek

leds: Switch to use fwnode instead of be stuck with OF one

2019-08-23T21:39:37+00:00

There is no need to be stuck with OF node when we may use agnostic
firmware node instead.

It allows users to get property if needed independently of provider.

Note, some OF parts are left because %pfw [1] is in progress.

[1]: https://lore.kernel.org/patchwork/cover/1054863/

Signed-off-by: Andy Shevchenko 
Signed-off-by: Jacek Anaszewski

leds: core: Add support for composing LED class device names

2019-07-25T18:07:52+00:00

Add generic support for composing LED class device name. The newly
introduced led_compose_name() function composes device name according
to either  or  pattern,
depending on the configuration of initialization data.

Backward compatibility with in-driver hard-coded LED class device
names is assured thanks to the default_label and devicename properties
of newly introduced struct led_init_data.

In case none of the aforementioned properties was found, then, for OF
nodes, the node name is adopted for LED class device name.

At the occassion of amending the Documentation/leds/leds-class.txt
unify spelling: colour -> color.

Alongside these changes added is a new tool - tools/leds/get_led_device_info.sh.
The tool allows retrieving details of a LED class device's parent device,
which proves that using vendor or product name for devicename part
of LED name doesn't convey any added value since that information had been
already available in sysfs. The script performs also basic validation
of a LED class device name.

Signed-off-by: Jacek Anaszewski 
Cc: Baolin Wang 
Cc: Dan Murphy 
Cc: Daniel Mack 
Cc: Linus Walleij 
Cc: Oleh Kravchenko 
Cc: Sakari Ailus 
Cc: Simon Shields 
Reviewed-by: Linus Walleij 
Acked-by: Pavel Machek

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

2019-06-19T15:09:55+00:00

Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner 
Reviewed-by: Enrico Weigelt 
Reviewed-by: Kate Stewart 
Reviewed-by: Allison Randal 
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman

leds: avoid flush_work in atomic context

2019-05-31T20:29:14+00:00

It turns out that various triggers use led_blink_setup() from atomic
context, so we can't do a flush_work there. Flush is still needed for
slow LEDs, but we can move it to sysfs code where it is safe.

    WARNING: inconsistent lock state
    5.2.0-rc1 #1 Tainted: G        W
    --------------------------------
    inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
    swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
    000000006e30541b
    ((work_completion)(&led_cdev->set_brightness_work)){+.?.}, at:
    +__flush_work+0x3b/0x38a
    {SOFTIRQ-ON-W} state was registered at:
      lock_acquire+0x146/0x1a1
     __flush_work+0x5b/0x38a
     flush_work+0xb/0xd
     led_blink_setup+0x1e/0xd3
     led_blink_set+0x3f/0x44
     tpt_trig_timer+0xdb/0x106
     ieee80211_mod_tpt_led_trig+0xed/0x112

Fixes: 0db37915d912 ("leds: avoid races with workqueue")
Signed-off-by: Pavel Machek 
Tested-by: Hugh Dickins 
Signed-off-by: Jacek Anaszewski

leds: avoid races with workqueue

2019-05-02T20:54:51+00:00

There are races between "main" thread and workqueue. They manifest
themselves on Thinkpad X60:

This should result in LED blinking, but it turns it off instead:

    root@amd:/data/pavel# cd /sys/class/leds/tpacpi\:\:power
    root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger
    root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger

It should be possible to transition from blinking to solid on by echo
0 > brightness; echo 1 > brightness... but that does not work, either,
if done too quickly.

Synchronization of the workqueue fixes both.

Fixes: 1afcadfcd184 ("leds: core: Use set_brightness_work for the blocking op")
Signed-off-by: Pavel Machek 
Signed-off-by: Jacek Anaszewski

leds: Add helper for getting default pattern from Device Tree

2019-01-16T21:08:07+00:00

Multiple LED triggers might need to access default pattern so add a
helper for that.

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Pavel Machek 
Signed-off-by: Jacek Anaszewski

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