- 15 11月, 2014 5 次提交
-
-
由 Jacek 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: NJacek Anaszewski <j.anaszewski@samsung.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Jacek 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: NJacek Anaszewski <j.anaszewski@samsung.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Linus Walleij 提交于
Currently the syscon LED driver will only handle LEDs on the first syscon found in the system. But there can be several of them, so augment the driver to traverse all syscon nodes and check for syscon LEDs on them. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Linus Walleij 提交于
A chunk of text followed the copied license text, ehm, sorry that kind of things happen from time to time. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Axel Lin 提交于
Signed-off-by: NAxel Lin <axel.lin@ingics.com> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 30 9月, 2014 3 次提交
-
-
由 Xiubo Li 提交于
Remove stray blank line and space. Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Xiubo Li 提交于
Since we cannot make sure the 'pdata->num_leds' will always be none zero here, and then if it equals to zero, the kmemdup() will return ZERO_SIZE_PTR, which equals to ((void *)16). So this patch fix this with just doing the zero check before calling kmemdup(). Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Xiubo Li 提交于
If the inlcude headers aren't sorted alphabetically, then the logical choice is to append new ones, however that creates a lot of potential for conflicts or duplicates because every change will then add new includes in the same location. Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 26 9月, 2014 1 次提交
-
-
由 Linus Walleij 提交于
This makes it possible to create a set of LEDs from a syscon MFD instance, which is lean mean and clean on the ARM reference designs and can replace the Versatile LEDs driver in the long run, as well as other custom syscon LEDs drivers. Cc: Bryan Wu <cooloney@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> [Fixed cocinelle warnings] Signed-off-by: NFengguang Wu <fengguang.wu@intel.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 24 9月, 2014 1 次提交
-
-
由 Andreas Werner 提交于
Added driver to support the 14F021P00 BMC LEDs. The BMC is a Board Management Controller including four LEDs which can be switched on and off. Signed-off-by: NAndreas Werner <andreas.werner@men.de> Acked-by: NBryan Wu <cooloney@gmail.com> Signed-off-by: NLee Jones <lee.jones@linaro.org>
-
- 19 9月, 2014 1 次提交
-
-
由 abdoulaye berthe 提交于
this remove all reference to gpio_remove retval in all driver except pinctrl and gpio. the same thing is done for gpio and pinctrl in two different patches. Signed-off-by: NAbdoulaye Berthe <berthe.ab@gmail.com> Acked-by: NMichael Büsch <m@bues.ch> Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: NMauro Carvalho Chehab <m.chehab@samsung.com> Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
-
- 13 9月, 2014 1 次提交
-
-
由 Jacek 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: NJacek Anaszewski <j.anaszewski@samsung.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 12 9月, 2014 4 次提交
-
-
由 Lothar Waßmann 提交于
When using a GPIO driver whose accessor functions may sleep (e.g. an I2C GPIO extender like PCA9554) the following warning is issued: WARNING: CPU: 0 PID: 665 at drivers/gpio/gpiolib.c:2274 gpiod_get_raw_value+0x3c/0x48() Modules linked in: CPU: 0 PID: 665 Comm: kworker/0:2 Not tainted 3.16.0-karo+ #115 Workqueue: events gpio_trig_work [<c00142cc>] (unwind_backtrace) from [<c00118f8>] (show_stack+0x10/0x14) [<c00118f8>] (show_stack) from [<c001bf10>] (warn_slowpath_common+0x64/0x84) [<c001bf10>] (warn_slowpath_common) from [<c001bf4c>] (warn_slowpath_null+0x1c/0x24) [<c001bf4c>] (warn_slowpath_null) from [<c020a1b8>] (gpiod_get_raw_value+0x3c/0x48) [<c020a1b8>] (gpiod_get_raw_value) from [<c02f68a0>] (gpio_trig_work+0x1c/0xb0) [<c02f68a0>] (gpio_trig_work) from [<c0030c1c>] (process_one_work+0x144/0x38c) [<c0030c1c>] (process_one_work) from [<c0030ef8>] (worker_thread+0x60/0x5cc) [<c0030ef8>] (worker_thread) from [<c0036dd4>] (kthread+0xb4/0xd0) [<c0036dd4>] (kthread) from [<c000f0f0>] (ret_from_fork+0x14/0x24) ---[ end trace cd51a1dad8b86c9c ]--- Fix this by using the _cansleep() variant of gpio_get_value(). Signed-off-by: NLothar Waßmann <LW@KARO-electronics.de> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Jacek Anaszewski 提交于
Fix sparse warning appeared after changing brightness type in the leds.h from int to enum led_brightness. Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Jacek Anaszewski 提交于
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: NJacek Anaszewski <j.anaszewski@samsung.com> Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Jacek Anaszewski 提交于
Reorder include directives so that they are arranged in alphabetical order. Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com> Acked-by: NKyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 09 9月, 2014 1 次提交
-
-
由 Andrew Lunn 提交于
mach-kirkwood has been removed, now that kirkwood lives in mach-mvebu. Use MACH_KIRKWOOD which will be set when kirkwood is built as part of mach-mvebu. Signed-off-by: NAndrew Lunn <andrew@lunn.ch> Acked-by: NBryan Wu <cooloney@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: linux-leds@vger.kernel.org Link: https://lkml.kernel.org/r/1409417172-6846-5-git-send-email-andrew@lunn.chSigned-off-by: NJason Cooper <jason@lakedaemon.net>
-
- 03 9月, 2014 1 次提交
-
-
由 Jiri Kosina 提交于
This reverts commit 8b37e1be. 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: NJiri Kosina <jkosina@suse.cz> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 30 7月, 2014 1 次提交
-
-
由 Wei Yongjun 提交于
Fixes the following sparse warnings: drivers/leds/leds-ipaq-micro.c:130:24: warning: symbol 'micro_leds_device_driver' was not declared. Should it be static? Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 24 7月, 2014 1 次提交
-
-
由 Linus Walleij 提交于
This adds a driver for the iPAQ microcontroller LED. Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 09 7月, 2014 1 次提交
-
-
由 Alexandre Belloni 提交于
The leds-atmel-pwm driver is now obsolete. It is not used by any mainlined boards and is replaced by the generic leds_pwm with the pwm-atmel driver using the generic PWM framework. Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: NBryan Wu <cooloney@gmail.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
- 04 7月, 2014 3 次提交
-
-
由 Vincent 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: NVincent Donnefort <vdonnefort@gmail.com> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Peter Meerwald 提交于
PCA9632 defaults to open-drain PCA9633/4/5 defaults to totem-pole the driver assumed that totem-pole default and didn't actively set the value; the MODE2 register is now written if platform data indicating the mode is given Signed-off-by: NPeter Meerwald <pmeerw@pmeerw.net> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Peter Meerwald 提交于
supports 16 PWM-controlled LEDs Signed-off-by: NPeter Meerwald <pmeerw@pmeerw.net> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 28 6月, 2014 2 次提交
-
-
由 Johan Hovold 提交于
Use the attribute groups of the led-class to create the LED attributes during probe in order to avoid racing with userspace. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Johan Hovold 提交于
Make sure the sysfs group is removed when the LEDs are unregistered. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 26 6月, 2014 10 次提交
-
-
由 Johan Hovold 提交于
Use the attribute groups of the led-class to create the src attribute during probe in order to avoid racing with userspace. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Johan Hovold 提交于
Use the attribute groups of the led-class to create the blink attribute during probe in order to avoid racing with userspace. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Johan Hovold 提交于
Use the attribute groups of the led-class to create the sata attribute during probe in order to avoid racing with userspace. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Johan Hovold 提交于
Use the attribute groups of the led-class to create the sata attribute during probe in order to avoid racing with userspace. [cooloney@gmail.com: clean up return led_classdev_register()] Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Johan Hovold 提交于
Use the attribute groups of the led-class to create the mode attribute during probe in order to avoid racing with userspace. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Johan Hovold 提交于
Use the attribute groups of the led-class to create the flash and torch-LED attributes during probe in order to avoid racing with userspace. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Johan Hovold 提交于
Use the attribute groups of the led-class to create the indicator-LED attributes during probe in order to avoid racing with userspace. Note that the comment about the pattern attribute only being for LM3554 was incorrect and did not match the code (the original leds-lm3556 driver had the attribute before LM3554 support was added). Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Johan Hovold 提交于
Use the attribute groups of the led-class to create the attributes during probe in order to avoid racing with userspace. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Johan Hovold 提交于
Use the attribute groups of the led-class to create the mode attribute during probe in order to avoid racing with userspace. Signed-off-by: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Johan Hovold 提交于
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: NJohan Hovold <johan@kernel.org> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
- 21 5月, 2014 1 次提交
-
-
由 Alexandre Belloni 提交于
The PWM core is now able to initialize the PWM period from a lookup table defined by board files. Use it if available and fallback to the value supplied in pwm_period_ns. Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: NThierry Reding <thierry.reding@gmail.com>
-
- 11 5月, 2014 1 次提交
-
-
由 Arnd Bergmann 提交于
I got a build error today, since LEDS_VERSATILE can be built-in while LEDS_CLASS is a module: drivers/built-in.o: In function `versatile_leds_probe': :(.text+0x155020): undefined reference to `led_classdev_register' I suggest we turn this option into 'tristate' so that the dependency tracking works correctly. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 08 5月, 2014 2 次提交
-
-
由 Xiubo Li 提交于
The OOM message of individual driver is unnecessary, and this is duplicate the memory subsystem generic OOM message. Signed-off-by: NXiubo Li <Li.Xiubo@freescale.com> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-
由 Christoph Lameter 提交于
Use this_cpu_ptr for the address calculation instead of __get_cpu_var. Signed-off-by: NChristoph Lameter <cl@linux.com> Signed-off-by: NBryan Wu <cooloney@gmail.com>
-