kernel/include/linux/leds.h, branch linux-3.17.y

Revert "leds: convert blink timer to workqueue"

2014-09-02T17:02:13Z

This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. It's broken as it changes led_blink_set() in a way that it can now sleep (while synchronously waiting for workqueue to be cancelled). That's a problem, because it's possible that this function gets called from atomic context (tpt_trig_timer() takes a readlock and thus disables preemption). This has been brought up 3 weeks ago already [1] but no proper fix has materialized, and I keep seeing the problem since 3.17-rc1. [1] https://lkml.org/lkml/2014/8/16/128 BUG: sleeping function called from invalid context at kernel/workqueue.c:2650 in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant 5 locks held by wpa_supplicant/2335: #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20 #1: (&wdev->mtx){+.+.+.}, at: [] cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211] #2: (&local->mtx){+.+.+.}, at: [] ieee80211_prep_connection+0x17a/0x9a0 [mac80211] #3: (&local->chanctx_mtx){+.+.+.}, at: [] ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211] #4: (&trig->leddev_list_lock){.+.+..}, at: [] tpt_trig_timer+0xec/0x170 [mac80211] CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 ffff8800360b5a50 ffff8800751f76d8 ffffffff8159e97f ffff8800360b5a30 ffff8800751f76e8 ffffffff810739a5 ffff8800751f77b0 ffffffff8106862f ffffffff810685d0 0aa2209200000000 ffff880000000004 ffff8800361c59d0 Call Trace: [] dump_stack+0x4d/0x66 [] __might_sleep+0xe5/0x120 [] flush_work+0x5f/0x270 [] ? mod_delayed_work_on+0x80/0x80 [] ? mark_held_locks+0x6a/0x90 [] ? __cancel_work_timer+0x6f/0x100 [] ? trace_hardirqs_on_caller+0xfd/0x1c0 [] __cancel_work_timer+0x7b/0x100 [] cancel_delayed_work_sync+0xe/0x10 [] led_blink_set+0x1b/0x40 [] tpt_trig_timer+0x110/0x170 [mac80211] [] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [] ieee80211_idle_off+0xe/0x10 [mac80211] [] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [] ieee80211_auth+0x13/0x20 [mac80211] [] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [] cfg80211_connect+0x3f0/0x540 [cfg80211] [] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211] [] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [] ioctl_standard_iw_point+0x14c/0x3e0 [] ? trace_hardirqs_on_caller+0xfd/0x1c0 [] ioctl_standard_call+0x8a/0xd0 [] ? ioctl_standard_iw_point+0x3e0/0x3e0 [] wireless_process_ioctl.constprop.10+0xb6/0x100 [] wext_handle_ioctl+0x5d/0xb0 [] dev_ioctl+0x329/0x620 [] ? trace_hardirqs_on_caller+0xfd/0x1c0 [] sock_ioctl+0x142/0x2e0 [] do_vfs_ioctl+0x300/0x520 [] ? sysret_check+0x1b/0x56 [] ? trace_hardirqs_on_caller+0xfd/0x1c0 [] SyS_ioctl+0x81/0xa0 [] system_call_fastpath+0x1a/0x1f wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3) wlan0: authenticated wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3) wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2) wlan0: associated IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready cfg80211: Calling CRDA for country: NA wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by 00:0b:6b:3c:8c:e4 ================================= [ INFO: inconsistent lock state ] 3.17.0-rc3 #1 Not tainted --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ((&(&led_cdev->blink_work)->work)){+.?...}, at: [] flush_work+0x0/0x270 {SOFTIRQ-ON-W} state was registered at: [] __lock_acquire+0x30e/0x1a30 [] lock_acquire+0x91/0x110 [] flush_work+0x38/0x270 [] __cancel_work_timer+0x7b/0x100 [] cancel_delayed_work_sync+0xe/0x10 [] led_blink_set+0x1b/0x40 [] tpt_trig_timer+0x110/0x170 [mac80211] [] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [] ieee80211_idle_off+0xe/0x10 [mac80211] [] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [] ieee80211_auth+0x13/0x20 [mac80211] [] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [] cfg80211_connect+0x3f0/0x540 [cfg80211] [] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [] ioctl_standard_iw_point+0x14c/0x3e0 [] ioctl_standard_call+0x8a/0xd0 [] wireless_process_ioctl.constprop.10+0xb6/0x100 [] wext_handle_ioctl+0x5d/0xb0 [] dev_ioctl+0x329/0x620 [] sock_ioctl+0x142/0x2e0 [] do_vfs_ioctl+0x300/0x520 [] SyS_ioctl+0x81/0xa0 [] system_call_fastpath+0x1a/0x1f irq event stamp: 493416 hardirqs last enabled at (493416): [] __cancel_work_timer+0x6f/0x100 hardirqs last disabled at (493415): [] try_to_grab_pending+0x1f/0x160 softirqs last enabled at (493408): [] _local_bh_enable+0x1d/0x50 softirqs last disabled at (493409): [] irq_exit+0xa5/0xb0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock((&(&led_cdev->blink_work)->work)); lock((&(&led_cdev->blink_work)->work)); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: (((&tpt_trig->timer))){+.-...}, at: [] call_timer_fn+0x0/0x180 #1: (&trig->leddev_list_lock){.+.?..}, at: [] tpt_trig_timer+0xec/0x170 [mac80211] stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc3 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 ffffffff8246eb30 ffff88007c203b00 ffffffff8159e97f ffffffff81a194c0 ffff88007c203b50 ffffffff81599c29 0000000000000001 ffffffff00000001 ffff880000000000 0000000000000006 ffffffff81a194c0 ffffffff81093ad0 Call Trace: [] dump_stack+0x4d/0x66 [] print_usage_bug+0x1f4/0x205 [] ? check_usage_backwards+0x140/0x140 [] mark_lock+0x223/0x2b0 [] __lock_acquire+0x2b0/0x1a30 [] lock_acquire+0x91/0x110 [] ? mod_delayed_work_on+0x80/0x80 [] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [] flush_work+0x38/0x270 [] ? mod_delayed_work_on+0x80/0x80 [] ? mark_held_locks+0x6a/0x90 [] ? __cancel_work_timer+0x6f/0x100 [] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [] ? trace_hardirqs_on_caller+0xad/0x1c0 [] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [] __cancel_work_timer+0x7b/0x100 [] cancel_delayed_work_sync+0xe/0x10 [] led_blink_set+0x1b/0x40 [] tpt_trig_timer+0x110/0x170 [mac80211] [] call_timer_fn+0x75/0x180 [] ? process_timeout+0x10/0x10 [] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [] run_timer_softirq+0x1fc/0x2f0 [] __do_softirq+0x115/0x2e0 [] irq_exit+0xa5/0xb0 [] do_IRQ+0x53/0xf0 [] common_interrupt+0x6f/0x6f [] ? cpuidle_enter_state+0x6e/0x180 [] cpuidle_enter+0x12/0x20 [] cpu_startup_entry+0x330/0x360 [] rest_init+0xc1/0xd0 [] ? csum_partial_copy_generic+0x170/0x170 [] start_kernel+0x44f/0x45a [] ? set_init_arg+0x53/0x53 [] x86_64_start_reservations+0x2a/0x2c [] x86_64_start_kernel+0xf1/0xf4 Cc: Vincent Donnefort Cc: Hugh Dickins Cc: Tejun Heo Signed-off-by: Jiri Kosina Signed-off-by: Bryan Wu

leds: convert blink timer to workqueue

2014-07-03T19:02:14Z

This patch converts the blink timer from led-core to workqueue which is more suitable for this kind of non-priority operations. Moreover, timer may lead to errors when a LED setting function use a scheduling function such as pinctrl which is using mutex. Signed-off-by: Vincent Donnefort Signed-off-by: Bryan Wu

leds: add led-class attribute-group support

2014-06-25T21:55:03Z

Allow led-class devices to be created with optional attribute groups. This is needed in order to allow led drivers to create custom device attributes in a race-free manner. Signed-off-by: Johan Hovold Signed-off-by: Bryan Wu

leds: add camera LED triggers

2013-04-01T18:04:50Z

Some LED devices support flash/torch functionality through the LED subsystem. This patch enables direct LED trigger controls by the driver. Flash on/off and torch on/off can be done simply by other driver space. Two trigger APIs are added, ledtrig_flash_ctrl() and ledtrig_torch_ctrl(). Signed-off-by: Milo(Woogyom) Kim Signed-off-by: Bryan Wu

leds: trigger: use inline functions instead of macros

2013-04-01T18:04:50Z

Macros are used in case that an inline function doesn't work. Otherwise, use an empty inline function. (a) Case of !CONFIG_LEDS_TRIGGERS Following macros are replaced with inline functions. led_trigger_register_simple() led_trigger_unregister_simple() led_trigger_event() To make inline types, the structure, 'led_trigger' should be defined. This structure has no member at all. (b) Case of !CONFIG_LEDS_TRIGGER_IDE_DISK ledtrig_ide_activity() macro is replaced with an inline function as well. (c) DEFINE_LED_TRIGGER() and DEFINE_LED_TRIGGER_GLOBAL() Struct 'led_trigger' is defined both cases, with CONFIG_LEDS_TRIGGERS and without CONFIG_LEDS_TRIGGERS. Those macros are moved out of CONFIG_LED_TRIGGERS because of no-dependency on CONFIG_LEDS_TRIGGERS. (d) Fix build errors in mmc-core driver After replacing macros with inline functions, following build errors occur. (condition: CONFIG_LEDS_TRIGGERS is not set) drivers/mmc/core/core.c: In function 'mmc_request_done': drivers/mmc/core/core.c:164:25: error: 'struct mmc_host' has no member named 'led' drivers/mmc/core/core.c: In function 'mmc_start_request': drivers/mmc/core/core.c:254:24: error: 'struct mmc_host' has no member named 'led' make[3]: *** [drivers/mmc/core/core.o] Error 1 The reason of these errors is non-existent member variable, 'led'. It is only valid when CONFIG_LEDS_TRIGGERS is set. But now, it can be used without this dependency. To fix build errors, member 'led' is always used without its config option in 'include/linux/mmc/host.h'. Signed-off-by: Milo(Woogyom) Kim Signed-off-by: Bryan Wu

led: Add dependency on CONFIG_LEDS_TRIGGERS to led_trigger_rename_static()

2012-11-26T22:28:51Z

This patch fixes build warnings when CONFIG_LEDS_TRIGGERS is disabled as below: include/linux/leds.h:158:18: warning: 'struct led_trigger' declared inside parameter list [enabled by default] include/linux/leds.h:158:18: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] Signed-off-by: Jingoo Han Acked-by: Fabio Baltieri Signed-off-by: Bryan Wu

leds: add led_trigger_rename function

2012-11-26T22:28:50Z

Implements a "led_trigger_rename" function to rename a trigger with proper locking. This assumes that led name was originally allocated in non-constant storage. Signed-off-by: Fabio Baltieri Cc: Kurt Van Dijck Signed-off-by: Bryan Wu

Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds

2012-10-10T11:14:07Z

Pull LED subsystem update from Bryan Wu. * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (24 commits) leds: add output driver configuration for pca9633 led driver leds: lm3642: Use regmap_update_bits() in lm3642_chip_init() leds: Add new LED driver for lm3642 chips leds-lp5523: Fix riskiness of the page fault leds-lp5523: turn off the LED engines on unloading the driver leds-lm3530: Fix smatch warnings leds-lm3530: Use devm_regulator_get function leds: leds-gpio: adopt pinctrl support leds: Add new LED driver for lm355x chips leds-lp5523: use the i2c device id rather than fixed name leds-lp5523: add new device id for LP55231 leds-lp5523: support new LP55231 device leds: triggers: send uevent when changing triggers leds-lp5523: minor code style fixes leds-lp5523: change the return type of lp5523_set_mode() leds-lp5523: set the brightness to 0 forcely on removing the driver leds-lp5523: add channel name in the platform data leds: leds-gpio: Use of_get_child_count() helper leds: leds-gpio: Use platform_{get,set}_drvdata leds: leds-gpio: use of_match_ptr() ...

leds: delay led_set_brightness if stopping soft-blink

2012-09-11T10:32:40Z

Delay execution of led_set_brightness() if need to stop soft-blink timer. This allows led_set_brightness to be called in hard-irq context even if soft-blink was activated on that LED. Signed-off-by: Fabio Baltieri Cc: Pawel Moll Signed-off-by: Bryan Wu

Merge branch 'for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds into next/drivers

2012-08-13T14:45:48Z

From Bryan Wu : Based on Linus Walleij's ARM LED consolidation work, this patchset introduce a new generic led trigger for CPU not only for ARM but also for others. For enabling CPU idle event, CPU arch code should call ledtrig_cpu() stub to trigger idle start or idle end event. These patches convert old style LED driver in arch/arm to gpio_led or new led driver interface. Against 3.5 release and build successfully for all the machines. Test ledtrig-cpu driver on OMAP4 Panda board. v9 --> v10 * fix compiling issue on versatile_defconfig reported by Russell King * rebase to 3.5 kernel and move patches to new git tree v8 --> v9: * use mutex to replace rw_sema pointed out by Tim Gardner * add a new struct led_trigger_cpu * add lock_is_inited to record mutex lock initialization v6 --> v7: * add a patch to unify the led-trigger name * fix some typo pointed * use BUG_ON to detect CPU numbers during building stage v5 --> v6: * replace __get_cpu_var() to per_cpu() * remove smp_processor_id() which is wrong with for_each_possible_cpu() * test on real OMAP4 Panda board * add comments about CPU hotplug in the CPU LED trigger driver v4 --> v5: * rebase all the patches on top of latest linux-next * replace on_each_cpu() with for_each_possible_cpu() * add some description of ledtrig_cpu() API * remove old leds code from driver nwflash.c, which should use a new led trigger then * this trigger driver can be built as module now v3 --> v4: * fix a typo pointed by Jochen Friedrich * fix some building errors * add Reviewed-by and Tested-by into patch log v2 --> v3: * almost rewrote the whole ledtrig-cpu driver, which is more simple * every CPU will have a per-CPU trigger * cpu trigger can be assigned to any leds * fix a lockdep issue in led-trigger common code * other fix according to review v1 --> v2: * remove select operations in Kconfig of every machines * add back supporting of led in core module of mach-integrator * solidate name scheme in ledtrig-cpu.c * add comments of CPU_LED_* cpu led events * fold patches of RealView and Versatile together * add machine_is_ check during assabet led driver init * add some Acked-by in patch logs * remove code for simpad machine in machine-sa11000, since Jochen Friedrich introduced gpiolib and gpio-led driver for simpad * on Assabet and Netwinder machine, LED operations is reversed like: setting bit means turn off leds clearing bit means turn on leds * add a new function to read CM_CTRL register for led driver * 'for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: ARM: use new LEDS CPU trigger stub to replace old one ARM: mach-sa1100: retire custom LED code ARM: mach-omap1: retire custom LED code ARM: mach-pnx4008: remove including old leds event API header file ARM: plat-samsung: remove including old leds event API header file ARM: mach-pxa: retire custom LED code char: nwflash: remove old led event code ARM: mach-footbridge: retire custom LED code ARM: mach-ebsa110: retire custom LED code ARM: mach-clps711x: retire custom LED code of P720T machine ARM: mach-integrator: retire custom LED code ARM: mach-integrator: move CM_CTRL to header file for accessing by other functions ARM: mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger ARM: mach-shark: retire custom LED code ARM: mach-ks8695: remove leds driver, since nobody use it ARM: mach-realview and mach-versatile: retire custom LED code ARM: at91: convert old leds drivers to gpio_led and led_trigger drivers led-triggers: create a trigger for CPU activity Conflicts: arch/arm/mach-clps711x/p720t.c arch/arm/mach-sa1100/leds-cerf.c arch/arm/mach-sa1100/leds-lart.c Let's hope this is the last time we pull this and it doesn't cause more trouble. I have verified that version 10 causes no build warnings or errors any more, and the patches still look good. Signed-off-by: Arnd Bergmann