summaryrefslogtreecommitdiffstats
path: root/drivers/leds/led-class.c
Commit message (Collapse)AuthorAgeFilesLines
* leds: avoid races with workqueuePavel Machek2019-05-021-0/+1
| | | | | | | | | | | | | | | | | | | | | 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 <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* leds: class: ensure workqueue is initialized before setting brightnessLuis Henriques2018-05-241-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An application can try to set brightness before all the initialization is done, in particular before the workqueue is initialized with the call to led_init_core(). Here's a WARNING easy to trigger: [ 36.780813] WARNING: CPU: 3 PID: 1411 at ../kernel/workqueue.c:1444 __queue_work+0x37b/0x420 [ 36.780815] Modules linked in: ... [ 36.780868] CPU: 3 PID: 1411 Comm: systemd-backlig Not tainted 4.16.9-1-default #1 openSUSE Tumbleweed (unreleased) [ 36.780868] Hardware name: Dell Inc. Precision 5510/0N8J4R, BIOS 1.6.1 12/11/2017 [ 36.780870] RIP: 0010:__queue_work+0x37b/0x420 [ 36.780871] RSP: 0018:ffffaced048b7d78 EFLAGS: 00010086 [ 36.780873] RAX: 0000000000000000 RBX: ffffffffb3f01440 RCX: 0000000000000000 [ 36.780873] RDX: ffffffffc05a90d8 RSI: 0000000000000000 RDI: ffff8eac7dce2700 [ 36.780874] RBP: ffff8ea547c16400 R08: ffff8ea547800000 R09: ffff8eac7dc22700 [ 36.780875] R10: 0000000000000000 R11: 0000000000000040 R12: 0000000000000003 [ 36.780876] R13: 0000000000000200 R14: ffffffffc05a90d0 R15: ffff8eac7dce8600 [ 36.780877] FS: 00007f871e61cf40(0000) GS:ffff8eac7dcc0000(0000) knlGS:0000000000000000 [ 36.780878] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.780879] CR2: 000055c91115e308 CR3: 0000000883ee0005 CR4: 00000000003606e0 [ 36.780880] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 36.780880] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 36.780881] Call Trace: [ 36.780886] queue_work_on+0x81/0x90 [ 36.780889] brightness_store+0x5d/0x90 [ 36.780892] kernfs_fop_write+0x105/0x180 [ 36.780894] __vfs_write+0x26/0x150 [ 36.780897] ? common_file_perm+0x51/0x150 [ 36.780900] ? security_file_permission+0x3c/0xb0 [ 36.780901] vfs_write+0xad/0x1a0 [ 36.780903] SyS_write+0x42/0x90 [ 36.780906] do_syscall_64+0x76/0x140 [ 36.780908] entry_SYSCALL_64_after_hwframe+0x42/0xb7 [ 36.780910] RIP: 0033:0x7f871dd04c94 [ 36.780910] RSP: 002b:00007ffeb3a57d38 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 36.780912] RAX: ffffffffffffffda RBX: 000055c91115c810 RCX: 00007f871dd04c94 [ 36.780912] RDX: 0000000000000001 RSI: 000055c91115c810 RDI: 0000000000000004 [ 36.780913] RBP: 00007ffeb3a57e10 R08: 0000000000000003 R09: 0000000000000000 [ 36.780914] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 36.780914] R13: 000055c911158f30 R14: 000055c90f3a9a4e R15: 0000000000000004 [ 36.780917] Code: 74 18 e8 49 80 00 00 48 85 c0 74 0e 48 8b 40 20 48 3b 68 08 0f 84 c2 fc ff ff 0f 0b 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b e9 82 fd ff ff 83 cd 02 49 8d 57 60 e9 69 fd ff ff 80 3d [ 36.780942] ---[ end trace 1fce4edad54c4017 ]--- This patch initializes and acquires the led_access mutex early in the of_led_classdev_register function, so that any application trying to write to sysfs to set brightness will block until initialization ends. Signed-off-by: Luis Henriques <lhenriques@suse.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* leds: core: add OF variants of LED registering functionsRafał Miłecki2017-03-081-10/+16
| | | | | | | | | | | | | | These new functions allow passing an additional device_node argument that will be internally set for created LED device. Thanks to this LED core code and triggers will be able to access DT node for reading extra info. The easiest solution for achieving this was reworking old functions to more generic ones & adding simple defines for API compatibility. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* leds: class: Add new optional brightness_hw_changed attributeHans de Goede2017-01-291-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some LEDs may have their brightness level changed autonomously (outside of kernel control) by hardware / firmware. This commit adds support for an optional brightness_hw_changed attribute to signal such changes to userspace (if a driver can detect them): What: /sys/class/leds/<led>/brightness_hw_changed Date: January 2017 KernelVersion: 4.11 Description: Last hardware set brightness level for this LED. Some LEDs may be changed autonomously by hardware/firmware. Only LEDs where this happens and the driver can detect this, will have this file. This file supports poll() to detect when the hardware changes the brightness. Reading this file will return the last brightness level set by the hardware, this may be different from the current brightness. Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to their flags field and call led_classdev_notify_brightness_hw_changed() with the hardware set brightness when they detect a hardware / firmware triggered brightness change. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* led: core: Use atomic bit-field for the blink-flagsHans de Goede2016-11-221-0/+1
| | | | | | | | | | | | | 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>
* leds: Use macro for max device node name sizeDavid Lechner2016-11-221-1/+2
| | | | | | | | Use a macro instead of hard-coding the max device node name size. The uleds driver introduced a macro for this value, so using it. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* leds: core: avoid error message when a USB LED device is unpluggedHeiner Kallweit2016-03-141-0/+2
| | | | | | | | | | | | | | | 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>
* leds: turn off the LED and wait for completion on unregistering LED class deviceMilo Kim2016-01-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Workqueue, 'set_brightness_work' is used for scheduling brightness control. This workqueue is canceled when the LED class device is unregistered. Currently, LED subsystem handles like below. cancel_work_sync(&led_cdev->set_brightness_work) led_set_brightness(led_cdev, LED_OFF) However, this could be a problem. Workqueue is going to be canceled but LED device needs to be off. The worst case is null pointer access due to scheduling a workqueue. LED module is loaded. LED driver private data is allocated by using devm_zalloc(). LED module is unloaded. led_classdev_unregister() is called. cancel_work_sync() led_set_brightness(led_cdev, LED_OFF) schedule_work() if LED driver uses brightness_set_blocking() In the meantime, driver private data will be freed. ..scheduling.. brightness_set_blocking() callback is invoked. For the brightness control, LED driver tries to access private data but resource is removed! To avoid this problem, LED subsystem should turn off the brightness first and wait for completion. led_set_brightness(led_cdev, LED_OFF) flush_work(&led_cdev->set_brightness_work) It guarantees that LED driver turns off the brightness prior to resource management. Cc: linux-leds@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* leds: core: Drivers shouldn't enforce SYNC/ASYNC brightness settingJacek Anaszewski2016-01-041-2/+0
| | | | | | | | | | | | | | | | 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>
* leds: core: Add led_set_brightness_nosleep{nopm} functionsJacek Anaszewski2016-01-041-2/+2
| | | | | | | | | | | | | | | | | 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>
* leds: core: Move LED core callbacks out of led-class.cJacek Anaszewski2015-11-031-68/+1
| | | | | | | | | | 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>
* leds/led-class: Add missing put_device()Ricardo Ribalda Delgado2015-08-281-2/+5
| | | | | | | | | | Devices found by class_find_device must be freed with put_device(). Otherwise the reference count will not work properly. Fixes: a96aa64cb572 ("leds/led-class: Handle LEDs with the same name") Reported-by: Alan Tull <delicious.quinoa@gmail.com> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* Merge branch 'for-next' of ↵Linus Torvalds2015-07-011-0/+5
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED subsystem updates from Bryan Wu: "In this cycle, we finished to merge patches for LED Flash class driver. Other than that we have some bug fixes and new drivers for LED controllers" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (33 commits) leds:lp55xx: fix firmware loading error leds: fix max77693-led build errors leds: fix aat1290 build errors leds: aat1290: pass flags parameter to devm_gpiod_get leds: ktd2692: pass flags parameter to devm_gpiod_get drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c leds: aat1290: add support for V4L2 Flash sub-device DT: aat1290: Document handling external strobe sources leds: max77693: add support for V4L2 Flash sub-device media: Add registration helpers for V4L2 flash sub-devices v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it Documentation: leds: Add description of v4l2-flash sub-device leds: add BCM6358 LED driver leds: add DT binding for BCM6358 LED controller leds: fix brightness changing when software blinking is active Documentation: leds-lp5523: describe master fader attributes leds: lp5523: add master_fader support leds: leds-gpio: Allow compile test if !GPIOLIB leds: leds-gpio: Add missing #include <linux/of.h> gpiolib: Add missing dummies for the unified device properties interface ...
| * leds: fix brightness changing when software blinking is activeStas Sergeev2015-05-251-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | leds / PM: fix hibernation on arm when gpio-led used with CPU led triggerGrygorii Strashko2015-05-121-4/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting a dev_pm_ops suspend/resume pair of callbacks but not a set of hibernation callbacks means those pm functions will not be called upon hibernation - that leads to system crash on ARM during freezing if gpio-led is used in combination with CPU led trigger. It may happen after freeze_noirq stage (GPIO is suspended) and before syscore_suspend stage (CPU led trigger is suspended) - usually when disable_nonboot_cpus() is called. Log: PM: noirq freeze of devices complete after 1.425 msecs Disabling non-boot CPUs ... ^ system may crash or stuck here with message (TI AM572x) WARNING: CPU: 0 PID: 3100 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x22c/0x370() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access CPU1: shutdown ^ or here Fix this by using SIMPLE_DEV_PM_OPS, which appropriately assigns the suspend and hibernation callbacks and move led_suspend/led_resume under CONFIG_PM_SLEEP to avoid build warnings. Fixes: 73e1ab41a80d (leds: Convert led class driver from legacy pm ops to dev_pm_ops) Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* leds: Don't treat the LED name as a format stringSakari Ailus2015-03-301-1/+1
| | | | | | | | The LED name was wrongly interpreted as format string. Stop doing that. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
* leds: Use log level warn instead of info when telling about a name clashSakari Ailus2015-03-301-1/+1
| | | | | | | | | The LED names are expected to be unique in the system. Use KERN_WARNING log level to notify the user about the matter. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
* leds/led-class: Handle LEDs with the same nameRicardo Ribalda Delgado2015-03-301-2/+37
| | | | | | | | | | | | | The current code expected that every LED had an unique name. This is a legit expectation when the device tree can no be modified or extended. But with device tree overlays this requirement can be easily broken. This patch finds out if the name is already in use and adds the suffix _1, _2... if not. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: Introduce devres helper for led_classdev_registerBjorn Andersson2015-03-091-0/+57
| | | | | | | | (cooloney@gmail.com: add _unregister function into the document) Suggested-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: Add LED Flash class extension to the LED subsystemJacek Anaszewski2015-01-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | Some LED devices support two operation modes - torch and flash. This patch provides support for flash LED devices in the LED subsystem by introducing new sysfs attributes and kernel internal interface. The attributes being introduced are: flash_brightness, flash_strobe, flash_timeout, max_flash_timeout, max_flash_brightness, flash_fault, flash_sync_strobe and available_sync_leds. All the flash related features are placed in a separate module. The modifications aim to be compatible with V4L2 framework requirements related to the flash devices management. The design assumes that V4L2 sub-device can take of the LED class device control and communicate with it through the kernel internal interface. When V4L2 Flash sub-device file is opened, the LED class device sysfs interface is made unavailable. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: Use setup_timerJulia Lawall2015-01-141-3/+2
| | | | | | | | | | | | | | | | | | | | | | Convert a call to init_timer and accompanying intializations of the timer's data and function fields to a call to setup_timer. A simplified version of the semantic match that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression t,f,d; @@ -init_timer(&t); +setup_timer(&t,f,d); -t.function = f; -t.data = d; // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: Add support for setting brightness in a synchronous wayJacek Anaszewski2014-11-141-4/+6
| | | | | | | | | | | | | | 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>
* leds: implement sysfs interface locking mechanismJacek Anaszewski2014-11-141-3/+16
| | | | | | | | | | | | | | | | | | | | | | | 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>
* leds: Improve and export led_update_brightnessJacek Anaszewski2014-09-121-6/+0
| | | | | | | | | | | | | | | 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>
* leds: avoid using DEVICE_ATTR macro for max_brightness attributeJacek Anaszewski2014-09-111-2/+2
| | | | | | | | | | | | Make definition of the brightness related sysfs attributes consistent. The modification entails change of the function name: led_max_brightness_show -> max_brightness_show Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: Reorder include directivesJacek Anaszewski2014-09-111-6/+7
| | | | | | | | | | 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>
* Revert "leds: convert blink timer to workqueue"Jiri Kosina2014-09-021-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* leds: convert blink timer to workqueueVincent Donnefort2014-07-031-7/+7
| | | | | | | | | | 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>
* leds: add led-class attribute-group supportJohan Hovold2014-06-251-2/+3
| | | | | | | | | | 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 <johan@kernel.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: convert class code to use dev_groupsGreg Kroah-Hartman2013-07-261-8/+30
| | | | | | | | | | The dev_attrs field of struct class is going away soon, dev_groups should be used instead. This converts the led class code to use the correct field. Acked-by: Bryan Wu <cooloney@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* leds: Convert led class driver from legacy pm ops to dev_pm_opsShuah Khan2013-06-201-3/+7
| | | | | | | | | | | Convert drivers/leds/led-class to use dev_pm_ops for power management and remove Legacy PM ops hooks. With this change, led class registers suspend/resume callbacks via class->pm (dev_pm_ops) instead of Legacy class->suspend/resume. When __device_suspend() runs call-backs, it will find class->pm ops for the led class. Signed-off-by: Shuah Khan <shuah.kh@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: led-class: Fix checkpatch warningSachin Kamat2012-11-271-1/+1
| | | | | | | | | | Fixes the following checkpatch warning: WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then pr_debug(... to printk(KERN_DEBUG ... FILE: leds/led-class.c:214: printk(KERN_DEBUG "Registered led device: %s\n", Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: delay led_set_brightness if stopping soft-blinkFabio Baltieri2012-09-111-0/+15
| | | | | | | | | | | | 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>
* leds: Rename led_brightness_set() to led_set_brightness()Shuah Khan2012-07-241-1/+1
| | | | | | | | | | | | 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>
* leds: Rename led_set_brightness() to __led_set_brightness()Shuah Khan2012-07-241-3/+3
| | | | | | | | | | 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>
* leds: add oneshot blink functionsFabio Baltieri2012-07-241-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* leds: fixed a coding style issue.Jeffrin Jose2012-06-121-1/+1
| | | | | | | | 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 <ahiliation@yahoo.co.in> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
* leds: simple_strtoul() cleanupShuah Khan2012-05-291-13/+8
| | | | | | | | | | | | | | | led-class.c and ledtrig-timer.c still use simple_strtoul(). Change them to use kstrtoul() instead of obsolete simple_strtoul(). Also fix the existing int ret declaration to be ssize_t to match the return type for _store functions in ledtrig-timer.c. Signed-off-by: Shuah Khan <shuahkhan@gmail.com> Cc: Joe Perches <joe@perches.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Bryan Wu <bryan.wu@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* led-class: change back LEDS_CLASS to tristate instead of boolBryan Wu2012-03-231-70/+0
| | | | | | | | | | | 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>
* Merge branch 'driver-core-next' into Linux 3.2Greg Kroah-Hartman2012-01-061-1/+0
|\ | | | | | | | | | | | | | | | | | | | | | | This resolves the conflict in the arch/arm/mach-s3c64xx/s3c6400.c file, and it fixes the build error in the arch/x86/kernel/microcode_core.c file, that the merge did not catch. The microcode_core.c patch was provided by Stephen Rothwell <sfr@canb.auug.org.au> who was invaluable in the merge issues involved with the large sysdev removal process in the driver-core tree. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * driver-core: remove sysdev.h usage.Kay Sievers2011-12-211-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sysdev.h file should not be needed by any in-kernel code, so remove the .h file from these random files that seem to still want to include it. The sysdev code will be going away soon, so this include needs to be removed no matter what. Cc: Jiandong Zheng <jdzheng@broadcom.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Kukjin Kim <kgene.kim@samsung.com> Cc: David Brown <davidb@codeaurora.org> Cc: Daniel Walker <dwalker@fifo99.com> Cc: Bryan Huntsman <bryanh@codeaurora.org> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Wan ZongShun <mcuos.com@gmail.com> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no> Cc: Guan Xuetao <gxt@mprc.pku.edu.cn> Cc: "Venkatesh Pallipadi Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Matthew Garrett <mjg@redhat.com> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
* | Revert "leds: save the delay values after a successful call to blink_set()"Johan Hovold2011-11-151-4/+1
|/ | | | | | | | | | | | | | | | Revert commit 6123b0e274503a0d3588e84fbe07c9aa01bfaf5d. The problem this patch intends to solve has alreadqy been fixed by commit 7a5caabd090b ("drivers/leds/ledtrig-timer.c: fix broken sysfs delay handling"). Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Antonio Ospite <ospite@studenti.unina.it> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* leds: turn the blink_timer off before starting to blinkAntonio Ospite2011-10-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Depending on the implementation of the hardware blinking function in blink_set(), the led can support hardware blinking for some values of delay_on and delay_off and fall-back to software blinking for some other values. Turning off the blink_timer unconditionally before starting to blink make sure that a sequence like: OFF hardware blinking software blinking hardware blinking does not leave the software blinking timer active. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: <stable@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* leds: save the delay values after a successful call to blink_set()Antonio Ospite2011-10-311-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When calling the hardware blinking function implemented by blink_set(), the delay_on and delay_off values are not preserved across calls. Fix that and make the "timer" trigger work as expected when hardware blinking is available. BEFORE the fix: $ cd /sys/class/leds/someled $ echo timer > trigger $ cat delay_on delay_off 0 0 $ echo 100 > delay_on $ cat delay_on delay_off 0 0 $ echo 100 > delay_off $ cat delay_on delay_off 0 0 AFTER the fix: $ cd /sys/class/leds/someled $ echo timer > trigger $ cat delay_on delay_off 0 0 $ echo 100 > delay_on $ cat delay_on delay_off 100 0 $ echo 100 > delay_off $ cat delay_on delay_off 100 100 Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Reviewed-by: Johannes Berg <johannes@sipsolutions.net> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: <stable@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* leds: support automatic start of blinking with ledtrig-timerEsben Haabendal2011-05-251-1/+2
| | | | | | | | | | | | | | | | | | | By setting initial values blink_delay_on and blink_delay_off in a led_classdev struct, this change starts the blinking when the led is initialized. With this patch, you can initialize blink_delay_on and blink_delay_off in led_classdev with default_trigger set to "timer", and the led will start up blinking. The current ledtrig-timer implementation ignores any initial blink_delay_on/blink_delay_off settings, and requires setting blink_delay_on/blink_delay_off (typically from userspace) before the led blinks. Signed-off-by: Esben Haabendal <eha@doredevelopment.dk> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* led_class: fix typo in blink APIJohannes Berg2010-12-221-1/+1
| | | | | | | | | | | | When I added led_blink_set I had a typo: the return value of the hw offload is a regular error code that is zero when succesful, and in that case software emulation should not be used, rather than the other way around. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* led-class: always implement blinkingJohannes Berg2010-11-121-1/+104
| | | | | | | | | | | | | | | | | | | | Currently, blinking LEDs can be awkward because it is not guaranteed that all LEDs implement blinking. The trigger that wants it to blink then needs to implement its own timer solution. Rather than require that, add led_blink_set() API that triggers can use. This function will attempt to use hw blinking, but if that fails implements a timer for it. To stop blinking again, brightness_set() also needs to be wrapped into API that will stop the software blink. As a result of this, the timer trigger becomes a very trivial one, and hopefully we can finally see triggers using blinking as well because it's always easy to use. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* leds: led-class: set permissions on max_brightness file to 0444Axel Lin2010-05-261-1/+1
| | | | | | | max_brightness is not writable, thus set permissions to 0444. Signed-off-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* leds: Fix race between LED device uevent and actual attributes creationFlorian Fainelli2010-03-161-32/+8
| | | | | | | | | | | | | If we were to dynamically register/unregister leds and have udev or other daemons handle the leds class uevents, we would be notified of the adding of a new LED and if the daemon immediately tries to open one of the attributes of the led device, it would fail with a "no such file or directory" error since this the attributes are not yet created. Fix this by switching attributes to be class-wide, such that the driver core will register these attributes with device_add_attrs and then emit the kobject_uevent ADD signal. Signed-off-by: Fainelli <ffainelli@freebox.fr> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
* leds: led-class.c - Quiet boot messagesH Hartley Sweeten2010-03-161-1/+1
| | | | | | | | | | | | As each led device gets registered a kernel message gets printed. In an embedded system with a number of leds this can produce a lot of output that just looks like noise. Change the message type to KERN_DEBUG since it might be useful in the dmesg output "after" booting. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-07 20:04:55 +0000