summaryrefslogtreecommitdiff
path: root/drivers/leds/led-core.c
AgeCommit message (Collapse)Author
2016-11-22led: core: Fix blink_brightness setting raceHans de Goede
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 <hdegoede@redhat.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22led: core: Use atomic bit-field for the blink-flagsHans de Goede
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 <hdegoede@redhat.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-06-08leds: core: Fix brightness setting upon hardware blinking enabledTony Makkiel
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 <tony.makkiel@daqri.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-03-14leds: core: add helpers for calling brightness_set(_blocking)Heiner Kallweit
Add helpers for calling brightness_set(_blocking) allowing to simplify the code and make it better readable. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-03-14leds: core: avoid error message when a USB LED device is unpluggedHeiner Kallweit
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 <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-01-04leds: core: Drivers shouldn't enforce SYNC/ASYNC brightness settingJacek Anaszewski
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 <j.anaszewski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2016-01-04leds: core: Use set_brightness_work for the blocking opJacek Anaszewski
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 <j.anaszewski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2016-01-04leds: core: Add led_set_brightness_nosleep{nopm} functionsJacek Anaszewski
This patch adds led_set_brightness_nosleep() and led_set_brightness_nopm() functions, that guarantee setting LED brightness in a non-blocking way. The latter is used from pm_ops context and doesn't modify the brightness cached in the struct led_classdev. Its execution always ends up with a call to brightness setting op - either directly or through a set_brightness_work, regardless of LED_SUSPENDED flag state. The patch also replaces led_set_brightness_async() with led_set_brightness_nosleep() in all places where the most vital was setting brightness in a non sleeping way but not necessarily asynchronously, which is not needed for non-blocking drivers. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2016-01-04leds: core: Add two new LED_BLINK_ flagsJacek Anaszewski
This patch adds LED_BLINK_BRIGHTNESS_CHANGE flag to indicate that blink brightness has changed, and LED_BLINK_DISABLE flag to indicate that blinking deactivation has been requested. In order to use the flags led_timer_function and set_brightness_delayed callbacks as well as led_set_brightness() function are being modified. The main goal of these modifications is to prepare set_brightness_work for extension of the scope of its responsibilities. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2016-01-04leds: core: Use EXPORT_SYMBOL_GPL consistentlyJacek Anaszewski
LED core has a mixture of EXPORT_SYMBOL and EXPORT_SYMBOL_GPL macros. This patch fixes this discrepancy and switches to using EXPORT_SYMBOL_GPL for each exported function. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Pavel Machek <pavel@ucw.cz>
2015-11-03leds: core: Move LED core callbacks out of led-class.cJacek Anaszewski
Since the API for controlling LED brightness and blinking is defined in the LED core, move the related timer and work callbacks to the led-core.c, and initialize them through a new led_core_init API. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Pavel Machek <pavel@ucw.cz>
2015-05-25leds: fix brightness changing when software blinking is activeStas Sergeev
The following sequence: echo timer >/sys/class/leds/<name>/trigger echo 1 >/sys/class/leds/<name>/brightness should change the ON brightness for blinking. The function led_set_brightness() was mistakenly initiating the delayed blink stop procedure, which resulted in no blinking with the timer trigger still active. This patch fixes the problem by changing led_set_brightness() to not initiate the delayed blink stop when brightness is not 0. CC: Richard Purdie <rpurdie@rpsys.net> CC: Kyungmin Park <kyungmin.park@samsung.com> CC: linux-leds@vger.kernel.org CC: linux-kernel@vger.kernel.org Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Stas Sergeev <stsp@users.sourceforge.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-11-14leds: Add support for setting brightness in a synchronous wayJacek Anaszewski
There are use cases when setting a LED brightness has to have immediate effect (e.g. setting a torch LED brightness). This patch extends LED subsystem to support such operations. The LED subsystem internal API __led_set_brightness is changed to led_set_brightness_async and new led_set_brightness_sync API is added. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-11-14leds: implement sysfs interface locking mechanismJacek Anaszewski
Add a mechanism for locking LED subsystem sysfs interface. This patch prepares ground for addition of LED Flash Class extension, whose API will be integrated with V4L2 Flash API. Such a fusion enforces introducing a locking scheme, which will secure consistent access to the LED Flash Class device. The mechanism being introduced allows for disabling LED subsystem sysfs interface by calling led_sysfs_disable function and enabling it by calling led_sysfs_enable. The functions alter the LED_SYSFS_DISABLE flag state and must be called under mutex lock. The state of the lock is checked with use of led_sysfs_is_disabled function. Such a design allows for providing immediate feedback to the user space on whether the LED Flash Class device is available or is under V4L2 Flash sub-device control. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-09-12leds: Improve and export led_update_brightnessJacek Anaszewski
led_update_brightness helper function used to be exploited only locally in the led-class.c module, where its result was being passed to the brightness_show sysfs callback. With the introduction of v4l2-flash subdevice the same functionality becomes required for reading current brightness from a LED device. This patch adds checking of return value of the brightness_get callback and moves the led_update_brightness() function to the LED subsystem public API. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-09-11leds: Reorder include directivesJacek Anaszewski
Reorder include directives so that they are arranged in alphabetical order. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-09-02Revert "leds: convert blink timer to workqueue"Jiri Kosina
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: [<ffffffff814c7c92>] rtnl_lock+0x12/0x20 #1: (&wdev->mtx){+.+.+.}, at: [<ffffffffc06e649c>] cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211] #2: (&local->mtx){+.+.+.}, at: [<ffffffffc0817dea>] ieee80211_prep_connection+0x17a/0x9a0 [mac80211] #3: (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffc08081ed>] ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211] #4: (&trig->leddev_list_lock){.+.+..}, at: [<ffffffffc081e68c>] 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: [<ffffffff8159e97f>] dump_stack+0x4d/0x66 [<ffffffff810739a5>] __might_sleep+0xe5/0x120 [<ffffffff8106862f>] flush_work+0x5f/0x270 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90 [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211] [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211] [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [<ffffffffc06e36c0>] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211] [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0 [<ffffffff81584fa0>] ? ioctl_standard_iw_point+0x3e0/0x3e0 [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100 [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0 [<ffffffff814cfb29>] dev_ioctl+0x329/0x620 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0 [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520 [<ffffffff815a67fb>] ? sysret_check+0x1b/0x56 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0 [<ffffffff815a67d6>] 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: [<ffffffff810685d0>] flush_work+0x0/0x270 {SOFTIRQ-ON-W} state was registered at: [<ffffffff81094dbe>] __lock_acquire+0x30e/0x1a30 [<ffffffff81096c81>] lock_acquire+0x91/0x110 [<ffffffff81068608>] flush_work+0x38/0x270 [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211] [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211] [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0 [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0 [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100 [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0 [<ffffffff814cfb29>] dev_ioctl+0x329/0x620 [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0 [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520 [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0 [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f irq event stamp: 493416 hardirqs last enabled at (493416): [<ffffffff81068a5f>] __cancel_work_timer+0x6f/0x100 hardirqs last disabled at (493415): [<ffffffff81067e9f>] try_to_grab_pending+0x1f/0x160 softirqs last enabled at (493408): [<ffffffff81053ced>] _local_bh_enable+0x1d/0x50 softirqs last disabled at (493409): [<ffffffff81054c75>] irq_exit+0xa5/0xb0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock((&(&led_cdev->blink_work)->work)); <Interrupt> lock((&(&led_cdev->blink_work)->work)); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: (((&tpt_trig->timer))){+.-...}, at: [<ffffffff810b4c50>] call_timer_fn+0x0/0x180 #1: (&trig->leddev_list_lock){.+.?..}, at: [<ffffffffc081e68c>] 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: <IRQ> [<ffffffff8159e97f>] dump_stack+0x4d/0x66 [<ffffffff81599c29>] print_usage_bug+0x1f4/0x205 [<ffffffff81093ad0>] ? check_usage_backwards+0x140/0x140 [<ffffffff810944d3>] mark_lock+0x223/0x2b0 [<ffffffff81094d60>] __lock_acquire+0x2b0/0x1a30 [<ffffffff81096c81>] lock_acquire+0x91/0x110 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff81068608>] flush_work+0x38/0x270 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90 [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff8109469d>] ? trace_hardirqs_on_caller+0xad/0x1c0 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffff810b4cc5>] call_timer_fn+0x75/0x180 [<ffffffff810b4c50>] ? process_timeout+0x10/0x10 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff810b50ac>] run_timer_softirq+0x1fc/0x2f0 [<ffffffff81054805>] __do_softirq+0x115/0x2e0 [<ffffffff81054c75>] irq_exit+0xa5/0xb0 [<ffffffff810049b3>] do_IRQ+0x53/0xf0 [<ffffffff815a74af>] common_interrupt+0x6f/0x6f <EOI> [<ffffffff8147b56e>] ? cpuidle_enter_state+0x6e/0x180 [<ffffffff8147b732>] cpuidle_enter+0x12/0x20 [<ffffffff8108bba0>] cpu_startup_entry+0x330/0x360 [<ffffffff8158fb51>] rest_init+0xc1/0xd0 [<ffffffff8158fa90>] ? csum_partial_copy_generic+0x170/0x170 [<ffffffff81af3ff2>] start_kernel+0x44f/0x45a [<ffffffff81af399c>] ? set_init_arg+0x53/0x53 [<ffffffff81af35ad>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81af36a0>] x86_64_start_kernel+0xf1/0xf4 Cc: Vincent Donnefort <vdonnefort@gmail.com> Cc: Hugh Dickins <hughd@google.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-07-03leds: convert blink timer to workqueueVincent Donnefort
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 <vdonnefort@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-02-27leds: Turn off led if blinking is disabledStefan Sørensen
When using the timer trigger and setting delay_on to 0, the led will stay in whatever state is was in, while intuitively one would expect it to turn off. This patch changes the behaviour to turn it off. Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2012-09-11leds: delay led_set_brightness if stopping soft-blinkFabio Baltieri
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 <fabio.baltieri@gmail.com> Cc: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24leds: fix sparse warnings due to missing staticBryan Wu
drivers/leds/led-core.c:56:6: sparse: symbol 'led_blink_setup' was not declared. Should it be static? drivers/leds/led-triggers.c:233:6: sparse: symbol 'led_trigger_blink_setup' was not declared. Should it be static? Reported-by: Fengguang Wu <wfg@linux.intel.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24leds: Rename led_brightness_set() to led_set_brightness()Shuah Khan
Rename leds external interface led_brightness_set() to led_set_brightness(). This is the second phase of the change to reduce confusion between the leds internal and external interfaces that set brightness. With this change, now the external interface is led_set_brightness(). The first phase renamed the internal interface led_set_brightness() to __led_set_brightness(). There are no changes to the interface implementations. Signed-off-by: Shuah Khan <shuahkhan@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24leds: Rename led_set_brightness() to __led_set_brightness()Shuah Khan
Rename leds internal interface led_set_brightness() to __led_set_brightness() to reduce confusion between led_set_brightness() and the external interface led_brightness_set(). led_brightness_set() cancels the timer and then calls led_set_brightness(). Signed-off-by: Shuah Khan <shuahkhan@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24leds: fix led_brightness_set when soft-blinkingFabio Baltieri
Move led_stop_software_blink() code into led_brightness_set() to ensure software blink timer is stopped and cleared when changing trigger. Also use led_set_brightness() instead of calling led_cdev->brightness_set() directly to keep led_cdev->brightness consistent with current LED status. This ensure proper cleaning when changing triggers, as without this fix a LED may be turned off while leaving it's led_cdev->brightness = 1, leading to an erratic software-blink behaviour. The problem was easy to reproduce by changing the trigger from "timer" to "oneshot". Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-24leds: add oneshot blink functionsFabio Baltieri
Add two new functions, led_blink_set_oneshot and led_trigger_blink_oneshot, to be used by triggers for one-shot blink of led devices. This is implemented extending the existing software-blink code, and uses the same timer and handler function. The behavior of the code is to do a blink-on, blink-off sequence when the function is called, ignoring other calls until the sequence is completed so that the leds keep blinking at constant rate if the functions are called repeatedly. This is meant to be used by drivers which needs to trigger on sporadic event, but doesn't have clear busy/idle trigger points. After the blink sequence the led remains off. This behavior can be inverted setting the "invert" argument, which blink the led off, than on and leave the led on after the sequence. (bryan.wu@canonical.com: rebase to commit 'leds: don't disable blinking when writing the same value to delay_on or delay_off') Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com> Acked-by: Shuah Khan <shuahkhan@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-06-12leds: don't disable blinking when writing the same value to delay_on or ↵Rafal Prylowski
delay_off 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 <prylowski@metasoft.pl> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-03-23led-class: change back LEDS_CLASS to tristate instead of boolBryan Wu
After moving some core functions to led-core.c, led-class.c can be built as module again. Signed-off-by: Bryan Wu <bryan.wu@canonical.com> Acked-by: Richard Purdie <richard.purdie@linuxfoundation.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-24leds: Cleanup various whitespace and code style issuesNémeth Márton
Break the lines which were more than 80 characters into more lines; replace SPACEs with TABs; correct ident at switch-case; change character encoding from ISO-8859-2 to UTF-8. The order of the functions in led-triggers.c changed in order the similar functions can still be together under titles "Used by LED Class", "LED Trigger Interface" and "Simple LED Tigger Interface" as was grouped before when exported with EXPORT_SYMBOL. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-12-31leds: Fix leds_list_lock locking issuesRichard Purdie
Covert leds_list_lock to a rw_sempahore to match previous LED trigger locking fixes, fixing lock ordering. Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2006-06-27[PATCH] spin/rwlock init cleanupsIngo Molnar
locking init cleanups: - convert " = SPIN_LOCK_UNLOCKED" to spin_lock_init() or DEFINE_SPINLOCK() - convert rwlocks in a similar manner this patch was generated automatically. Motivation: - cleanliness - lockdep needs control of lock initialization, which the open-coded variants do not give - it's also useful for -rt and for lock debugging in general Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31[PATCH] LED: add LED classRichard Purdie
Add the foundations of a new LEDs subsystem. This patch adds a class which presents LED devices within sysfs and allows their brightness to be controlled. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>