linux/drivers/leds, branch v3.5

leds: heartbeat: fix bug on panic

2012-07-04T07:55:19Z

With commit 49dca5aebfdeadd4bf27b6cb4c60392147dc35a4 I introduced a bug (visible if CONFIG_PROVE_RCU is enabled) which occures when a panic has happened: [ 1526.520230] =============================== [ 1526.520230] [ INFO: suspicious RCU usage. ] [ 1526.520230] 3.5.0-rc1+ #12 Not tainted [ 1526.520230] ------------------------------- [ 1526.520230] /c/kernel-tests/mm/include/linux/rcupdate.h:436 Illegal context switch in RCU read-side critical section! [ 1526.520230] [ 1526.520230] other info that might help us debug this: [ 1526.520230] [ 1526.520230] [ 1526.520230] rcu_scheduler_active = 1, debug_locks = 0 [ 1526.520230] 3 locks held by net.agent/3279: [ 1526.520230] #0: (&mm->mmap_sem){++++++}, at: [] do_page_fault+0x193/0x390 [ 1526.520230] #1: (panic_lock){+.+...}, at: [] panic+0x37/0x1d3 [ 1526.520230] #2: (rcu_read_lock){.+.+..}, at: [] rcu_lock_acquire+0x0/0x29 [ 1526.520230] [ 1526.520230] stack backtrace: [ 1526.520230] Pid: 3279, comm: net.agent Not tainted 3.5.0-rc1+ #12 [ 1526.520230] Call Trace: [ 1526.520230] [] lockdep_rcu_suspicious+0x109/0x112 [ 1526.520230] [] rcu_preempt_sleep_check+0x45/0x47 [ 1526.520230] [] __might_sleep+0x1e/0x19a [ 1526.520230] [] down_write+0x26/0x81 [ 1526.520230] [] led_trigger_unregister+0x1f/0x9c [ 1526.520230] [] heartbeat_reboot_notifier+0x15/0x19 [ 1526.520230] [] notifier_call_chain+0x96/0xcd [ 1526.520230] [] __atomic_notifier_call_chain+0x8e/0xff [ 1526.520230] [] ? kmsg_dump+0x37/0x1eb [ 1526.520230] [] atomic_notifier_call_chain+0x14/0x16 [ 1526.520230] [] panic+0xe8/0x1d3 [ 1526.520230] [] out_of_memory+0x15d/0x1d3 So in case of a panic, now just turn of the LED. Other approaches like scheduling a work to unregister the trigger aren't working because there isn't much which still runs after a panic occured (except timers). Signed-off-by: Alexander Holler Signed-off-by: Bryan Wu

leds: Make LEDS_ASIC3 and LEDS_RENESAS_TPU depend on LEDS_CLASS=y

2012-06-12T02:56:25Z

Otherwise, I got below build error when CONFIG_LEDS_CLASS=m. LD init/built-in.o drivers/built-in.o: In function `asic3_led_probe': clkdev.c:(.devinit.text+0x4680): undefined reference to `led_classdev_register' drivers/built-in.o: In function `r_tpu_probe': clkdev.c:(.devinit.text+0x4838): undefined reference to `led_classdev_register' drivers/built-in.o: In function `asic3_led_remove': clkdev.c:(.devexit.text+0x564): undefined reference to `led_classdev_unregister' drivers/built-in.o: In function `r_tpu_remove': clkdev.c:(.devexit.text+0x5a0): undefined reference to `led_classdev_unregister' make: *** [vmlinux] Error 1 Signed-off-by: Axel Lin Signed-off-by: Bryan Wu

leds: fixed a coding style issue.

2012-06-12T02:56:24Z

Fixed a coding style issue relating to trailing white space error found by checkpatch.pl tool in drivers/leds/led-class.c Signed-off-by: Jeffrin Jose Signed-off-by: Bryan Wu

leds: don't disable blinking when writing the same value to delay_on or delay_off

2012-06-12T02:56:24Z

Function led_set_software_blink() assumes that blink timer is still running, but commit 488bc35bf40df89d37486c1826b178a2fba36ce7 introduced disabling of blink timer before each call to led_set_software_blink(). Correct led_software_blink(): 1) remove protection against reprogramming blink timer to the same values, because it only disables blinking now, 2) remove unnecessary call to led_stop_software_blink(). Signed-off-by: Rafal Prylowski Cc: Richard Purdie Signed-off-by: Bryan Wu

leds: add LM3533 LED driver

2012-05-29T23:22:32Z

Add sub-driver for the LEDs on National Semiconductor / TI LM3533 lighting power chips. The chip provides 256 brightness levels, hardware accelerated blinking as well as ambient-light-sensor and pwm input control. Signed-off-by: Johan Hovold Cc: Richard Purdie Cc: Rob Landley Cc: Samuel Ortiz Cc: Jonathan Cameron Cc: Greg Kroah-Hartman Cc: Florian Tobias Schandinat Cc: Arnd Bergmann Cc: Mark Brown Cc: Bryan Wu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

drivers/leds/leds-pca955x.c: fix race condition while setting brightness on several LEDs

2012-05-29T23:22:32Z

When issuing the following command: for I in 0 1 2 3 4 5 6 7; do echo 0 > /sys/class/leds/pca955x\:${I}/brightness; done It is possible that all the pca955x_read_ls calls are done sequentially before any pca955x_write_ls call is done. This updates the LS only to the last LED update in its set. Fix this by using a global lock for the pca995x device during pca955x_led_work. Also used a struct for shared data betreen all LEDs. [akpm@linux-foundation.org: revert unintentional rename of pca955x_ledsel()] Signed-off-by: Alexander Stein Cc: Richard Purdie Cc: Bryan Wu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

leds: add new transient trigger for one shot timer activation

2012-05-29T23:22:32Z

The leds timer trigger does not currently have an interface to activate a one shot timer. The current support allows for setting two timers, one for specifying how long a state to be on, and the second for how long the state to be off. The delay_on value specifies the time period an LED should stay in on state, followed by a delay_off value that specifies how long the LED should stay in off state. The on and off cycle repeats until the trigger gets deactivated. There is no provision for one time activation to implement features that require an on or off state to be held just once and then stay in the original state forever. Without one shot timer interface, user space can still use timer trigger to set a timer to hold a state, however when user space application crashes or goes away without deactivating the timer, the hardware will be left in that state permanently. As a specific example of this use-case, let's look at vibrate feature on phones. Vibrate function on phones is implemented using PWM pins on SoC or PMIC. There is a need to activate one shot timer to control the vibrate feature, to prevent user space crashes leaving the phone in vibrate mode permanently causing the battery to drain. This trigger exports three properties, activate, state, and duration When transient trigger is activated these properties are set to default values. - duration allows setting timer value in msecs. The initial value is 0. - activate allows activating and deactivating the timer specified by duration as needed. The initial and default value is 0. This will allow duration to be set after trigger activation. - state allows user to specify a transient state to be held for the specified duration. Signed-off-by: Shuah Khan Cc: Jonas Bonn Cc: Richard Purdie Cc: NeilBrown Cc: Bryan Wu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

leds: heartbeat: stop on shutdown

2012-05-29T23:22:32Z

A halted kernel should not show a heartbeat. [akpm@linux-foundation.org: checkpatch fixes] Signed-off-by: Alexander Holler Cc: Shuah Khan Cc: Richard Purdie Cc: Bryan Wu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

drivers/leds/leds-lm3530.c: simplify als configuration on initialization

2012-05-29T23:22:32Z

For better code readability, ALS code is moved to new a function - lm3530_als_configure() Signed-off-by: Milo(Woogyom) Kim Acked-by: Linus Walleij Cc: Shreshtha Kumar SAHU Cc: Richard Purdie Cc: Bryan Wu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

leds: change ledtrig-timer to use activated flag

2012-05-29T23:22:31Z

Change existing timer trigger to use the new ->activated flag to set activate successful status in activate routine and check it in deactivate routine to do cleanup. Signed-off-by: Shuah Khan Cc: Richard Purdie Cc: Bryan Wu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds