#
08b7dab9 |
|
28-Feb-2024 |
Arnd Bergmann <arnd@arndb.de> |
leds: Fix ifdef check for gpio_led_register_device() gpio_led_register_device() is built whenever CONFIG_LEDS_GPIO_REGISTER is enabled, and this may be used even when CONFIG_NEW_LEDS is turned off. However, the stub declaration in the header is provided for all configs without CONFIG_NEW_LEDS, resulting in a build failure: drivers/leds/leds-gpio-register.c:24:1: error: redefinition of 'gpio_led_register_device' 24 | gpio_led_register_device(int id, const struct gpio_led_platform_data *pdata) | ^ include/linux/leds.h:646:39: note: previous definition is here Change the #ifdef check to match the definition. Note: this apparently took years of randconfig builds to hit, since a number of other drivers just 'select NEW_LEDS' anyway. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240228093834.2230004-1-arnd@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
|
#
211f8ec9 |
|
09-Jan-2024 |
Arnd Bergmann <arnd@arndb.de> |
leds: Remove led_init_default_state_get() and devm_led_classdev_register_ext() stubs These two functions have stub implementations that are called when NEW_LEDS and/or LEDS_CLASS are disabled, theorerically allowing drivers to optionally use the LED subsystem. However, this has never really worked because a built-in driver is unable to link against these functions if the LED class is in a loadable module. Heiner ran into this problem with a driver that newly gained a LEDS_CLASS dependency and suggested using an IS_REACHABLE() check. This is the reverse approach, removing the stub entirely to acknowledge that it is pointless in its current form, and that not having it avoids misleading developers into thinking that they can rely on it. This survived around 1000 randconfig builds to validate that any callers of the interface already have the correct Kconfig dependency already, with the exception of the one that Heiner just added. Cc: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/linux-leds/0f6f432b-c650-4bb8-a1b5-fe3372804d52@gmail.com/T/#u Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240109090715.982332-1-arnd@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
|
#
c82a1662 |
|
08-Dec-2023 |
Heiner Kallweit <hkallweit1@gmail.com> |
leds: trigger: Remove unused function led_trigger_rename_static() This function was added with a8df7b1ab70b ("leds: add led_trigger_rename function") 11 yrs ago, but it has no users. So remove it. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/d90f30be-f661-4db7-b0b5-d09d07a78a68@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
|
#
59b3e31e |
|
27-Nov-2023 |
Daniel Golle <daniel@makrotopia.org> |
leds: trigger: netdev: Extend speeds up to 10G Add 2.5G, 5G and 10G as available speeds to the netdev LED trigger. Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/99e7d3304c6bba7f4863a4a80764a869855f2085.1701143925.git.daniel@makrotopia.org Signed-off-by: Lee Jones <lee@kernel.org>
|
#
c7d80059 |
|
28-Jul-2023 |
Jean-Jacques Hiblot <jjhiblot@traphandler.com> |
leds: class: Store the color index in struct led_classdev Store the color of the LED so that it is not lost after the LED's name has been composed. This color information can then be exposed to the user space or used by the LED consumer. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Link: https://lore.kernel.org/r/20230728153731.3742339-3-jjhiblot@traphandler.com Signed-off-by: Lee Jones <lee@kernel.org>
|
#
afb48153 |
|
28-Jul-2023 |
Jean-Jacques Hiblot <jjhiblot@traphandler.com> |
leds: Provide devm_of_led_get_optional() Add an optional variant of devm_of_led_get(). It behaves the same as devm_of_led_get() except where the LED doesn't exist. In this case, instead of returning -ENOENT, the function returns NULL. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230728153731.3742339-2-jjhiblot@traphandler.com Signed-off-by: Lee Jones <lee@kernel.org>
|
#
22720a87 |
|
10-May-2023 |
Hans de Goede <hdegoede@redhat.com> |
leds: Fix oops about sleeping in led_trigger_blink() led_trigger_blink() calls led_blink_set() from a RCU read-side critical section so led_blink_set() must not sleep. Note sleeping was not allowed before the switch to RCU either because a spinlock was held before. led_blink_set() does not sleep when sw-blinking is used, but many LED controller drivers with hw blink support have a blink_set function which may sleep, leading to an oops like this one: [ 832.605062] ------------[ cut here ]------------ [ 832.605085] Voluntary context switch within RCU read-side critical section! [ 832.605119] WARNING: CPU: 2 PID: 370 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x4ee/0x690 <snip> [ 832.606453] Call Trace: [ 832.606466] <TASK> [ 832.606487] __schedule+0x9f/0x1480 [ 832.606527] schedule+0x5d/0xe0 [ 832.606549] schedule_timeout+0x79/0x140 [ 832.606572] ? __pfx_process_timeout+0x10/0x10 [ 832.606599] wait_for_completion_timeout+0x6f/0x140 [ 832.606627] i2c_dw_xfer+0x101/0x460 [ 832.606659] ? psi_group_change+0x168/0x400 [ 832.606680] __i2c_transfer+0x172/0x6d0 [ 832.606709] i2c_smbus_xfer_emulated+0x27d/0x9c0 [ 832.606732] ? __schedule+0x430/0x1480 [ 832.606753] ? preempt_count_add+0x6a/0xa0 [ 832.606778] ? get_nohz_timer_target+0x18/0x190 [ 832.606796] ? lock_timer_base+0x61/0x80 [ 832.606817] ? preempt_count_add+0x6a/0xa0 [ 832.606842] __i2c_smbus_xfer+0xa2/0x3f0 [ 832.606862] i2c_smbus_xfer+0x66/0xf0 [ 832.606882] i2c_smbus_read_byte_data+0x41/0x70 [ 832.606901] ? _raw_spin_unlock_irqrestore+0x23/0x40 [ 832.606922] ? __pm_runtime_suspend+0x46/0xc0 [ 832.606946] cht_wc_byte_reg_read+0x2e/0x60 [ 832.606972] _regmap_read+0x5c/0x120 [ 832.606997] _regmap_update_bits+0x96/0xc0 [ 832.607023] regmap_update_bits_base+0x5b/0x90 [ 832.607053] cht_wc_leds_brightness_get+0x412/0x910 [leds_cht_wcove] [ 832.607094] led_blink_setup+0x28/0x100 [ 832.607119] led_trigger_blink+0x40/0x70 [ 832.607145] power_supply_update_leds+0x1b7/0x1c0 [ 832.607174] power_supply_changed_work+0x67/0xe0 [ 832.607198] process_one_work+0x1c8/0x3c0 [ 832.607222] worker_thread+0x4d/0x380 [ 832.607243] ? __pfx_worker_thread+0x10/0x10 [ 832.607258] kthread+0xe9/0x110 [ 832.607279] ? __pfx_kthread+0x10/0x10 [ 832.607300] ret_from_fork+0x2c/0x50 [ 832.607337] </TASK> [ 832.607344] ---[ end trace 0000000000000000 ]--- Add a new led_blink_set_nosleep() function which defers the actual led_blink_set() call to a workqueue when necessary to fix this. This also fixes an existing race where a pending led_set_brightness() has been deferred to set_brightness_work and might then race with a later led_cdev->blink_set() call. Note this race is only an issue with triggers mixing led_trigger_event() and led_trigger_blink() calls, sysfs API calls and led_trigger_blink_oneshot() are not affected. Note rather then adding a separate blink_set_blocking callback this uses the presence of the already existing brightness_set_blocking callback to detect if the blinking call should be deferred to set_brightness_work. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by: Yauhen Kharuzhy <jekhor@gmail.com> Link: https://lore.kernel.org/r/20230510162234.291439-4-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
|
#
fa15d8c6 |
|
10-May-2023 |
Hans de Goede <hdegoede@redhat.com> |
leds: Fix set_brightness_delayed() race When a trigger wants to switch from blinking to LED on it needs to call: led_set_brightness(LED_OFF); led_set_brightness(LED_FULL); To first call disables blinking and the second then turns the LED on (the power-supply charging-blink-full-solid triggers do this). These calls happen immediately after each other, so it is possible that set_brightness_delayed() from the first call has not run yet when the led_set_brightness(LED_FULL) call finishes. If this race hits then this is causing problems for both sw- and hw-blinking: For sw-blinking set_brightness_delayed() clears delayed_set_value when LED_BLINK_DISABLE is set causing the led_set_brightness(LED_FULL) call effects to get lost when hitting the race, resulting in the LED turning off instead of on. For hw-blinking if the race hits delayed_set_value has been set to LED_FULL by the time set_brightness_delayed() runs. So led_cdev->brightness_set_blocking() is never called with LED_OFF as argument and the hw-blinking is never disabled leaving the LED blinking instead of on. Fix both issues by adding LED_SET_BRIGHTNESS and LED_SET_BRIGHTNESS_OFF work_flags making this 2 separate actions to be run by set_brightness_delayed(). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by: Yauhen Kharuzhy <jekhor@gmail.com> Link: https://lore.kernel.org/r/20230510162234.291439-3-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
|
#
e298d8a3 |
|
10-May-2023 |
Hans de Goede <hdegoede@redhat.com> |
leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value led_blink_set[_oneshot]()'s delay_on and delay_off function parameters are pass by reference, so that hw-blink implementations can report back the actual achieved delays when the values have been rounded to something the hw supports. This is really only interesting for the sysfs API / the timer trigger. Other triggers don't really care about this and none of the callers of led_trigger_blink[_oneshot]() do anything with the returned delay values. Change the led_trigger_blink[_oneshot]() delay parameters to pass-by-value, there are 2 reasons for this: 1. led_cdev->blink_set() may sleep, while led_trigger_blink() may not. So on hw where led_cdev->blink_set() sleeps the call needs to be deferred to a workqueue, in which case the actual achieved delays are unknown (this is a preparation patch for the deferring). 2. Since the callers don't care about the actual achieved delays, allowing callers to directly pass a value leads to simpler code for most callers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by: Yauhen Kharuzhy <jekhor@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Florian Westphal <fw@strlen.de> Link: https://lore.kernel.org/r/20230510162234.291439-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
|
#
f22f95b9 |
|
19-Jun-2023 |
Christian Marangi <ansuelsmth@gmail.com> |
leds: trigger: netdev: add additional specific link duplex mode Add additional modes for specific link duplex. Use ethtool APIs to get the current link duplex and enable the LED accordingly. Under netdev event handler the rtnl lock is already held and is not needed to be set to access ethtool APIs. This is especially useful for PHY and Switch that supports LEDs hw control for specific link duplex. Add additional modes: - half_duplex: Turn on LED when link is half duplex - full_duplex: Turn on LED when link is full duplex Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
d5e01266 |
|
19-Jun-2023 |
Christian Marangi <ansuelsmth@gmail.com> |
leds: trigger: netdev: add additional specific link speed mode Add additional modes for specific link speed. Use ethtool APIs to get the current link speed and enable the LED accordingly. Under netdev event handler the rtnl lock is already held and is not needed to be set to access ethtool APIs. This is especially useful for PHY and Switch that supports LEDs hw control for specific link speed. (example scenario a PHY that have 2 LED connected one green and one orange where the green is turned on with 1000mbps speed and orange is turned on with 10mpbs speed) On mode set from sysfs we check if we have enabled split link speed mode and reject enabling generic link mode to prevent wrong and redundant configuration. Rework logic on the set baseline state to support these new modes to select if we need to turn on or off the LED. Add additional modes: - link_10: Turn on LED when link speed is 10mbps - link_100: Turn on LED when link speed is 100mbps - link_1000: Turn on LED when link speed is 1000mbps Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
#
947acaca |
|
29-May-2023 |
Christian Marangi <ansuelsmth@gmail.com> |
leds: trigger: netdev: expose netdev trigger modes in linux include Expose netdev trigger modes to make them accessible by LED driver that will support netdev trigger for hw control. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
052c38eb |
|
29-May-2023 |
Andrew Lunn <andrew@lunn.ch> |
leds: add API to get attached device for LED hw control Some specific LED triggers blink the LED based on events from a device or subsystem. For example, an LED could be blinked to indicate a network device is receiving packets, or a disk is reading blocks. To correctly enable and request the hw control of the LED, the trigger has to check if the network interface or block device configured via a /sys/class/led file match the one the LED driver provide for hw control for. Provide an API call to get the device which the LED blinks for. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
ed554d3f |
|
29-May-2023 |
Christian Marangi <ansuelsmth@gmail.com> |
leds: add APIs for LEDs hw control Add an option to permit LED driver to declare support for a specific trigger to use hw control and setup the LED to blink based on specific provided modes. Add APIs for LEDs hw control. These functions will be used to activate hardware control where a LED will use the provided flags, from an unique defined supported trigger, to setup the LED to be driven by hardware. Add hw_control_is_supported() to ask the LED driver if the requested mode by the trigger are supported and the LED can be setup to follow the requested modes. Deactivate hardware blink control by setting brightness to LED_OFF via the brightness_set() callback. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
8af70e20 |
|
18-Feb-2023 |
Thomas Weißschuh <linux@weissschuh.net> |
leds: Fix reference to led_set_brightness() in doc The referenced function led_classdev_brightness_set() never existed. Fixes: 5ada28bf7675 ("led-class: always implement blinking") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230218-typo-led-set-v1-1-3c35362a2f2d@weissschuh.net
|
#
e5029edd |
|
17-Apr-2023 |
Andrew Lunn <andrew@lunn.ch> |
leds: Provide stubs for when CLASS_LED & NEW_LEDS are disabled Provide stubs for devm_led_classdev_register_ext() and led_init_default_state_get() so that LED drivers embedded within other drivers such as PHYs and Ethernet switches still build when LEDS_CLASS or NEW_LEDS are disabled. This also helps with Kconfig dependencies, which are somewhat hairy for phylib and mdio and only get worse when adding a dependency on LED_CLASS. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
156a5bb8 |
|
03-Jan-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
leds: Move led_init_default_state_get() to the global header There are users inside and outside LED framework that have implemented a local copy of led_init_default_state_get(). In order to deduplicate that, as the first step move the declaration from LED header to the global one. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-3-andriy.shevchenko@linux.intel.com
|
#
d35d0c9d |
|
03-Jan-2023 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
leds: Add missing includes and forward declarations in leds.h Add missing includes and forward declarations to leds.h. While at it, replace headers by forward declarations and vise versa. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230103131256.33894-2-andriy.shevchenko@linux.intel.com
|
#
abc3100f |
|
19-Jan-2023 |
Hans de Goede <hdegoede@redhat.com> |
leds: led-class: Add generic [devm_]led_get() Add a generic [devm_]led_get() method which can be used on both devicetree and non devicetree platforms to get a LED classdev associated with a specific function on a specific device, e.g. the privacy LED associated with a specific camera sensor. Note unlike of_led_get() this takes a string describing the function rather then an index. This is done because e.g. camera sensors might have a privacy LED, or a flash LED, or both and using an index approach leaves it unclear what the function of index 0 is if there is only 1 LED. This uses a lookup-table mechanism for non devicetree platforms. This allows the platform code to map specific LED class_dev-s to a specific device,function combinations this way. For devicetree platforms getting the LED by function-name could be made to work using the standard devicetree pattern of adding a -names string array to map names to the indexes. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-5-hdegoede@redhat.com
|
#
2a5a8fa8 |
|
15-Sep-2021 |
Johannes Berg <johannes.berg@intel.com> |
leds: trigger: use RCU to protect the led_cdevs list Even with the previous commit 27af8e2c90fb ("leds: trigger: fix potential deadlock with libata") to this file, we still get lockdep unhappy, and Boqun explained the report here: https://lore.kernel.org/r/YNA+d1X4UkoQ7g8a@boqun-archlinux Effectively, this means that the read_lock_irqsave() isn't enough here because another CPU might be trying to do a write lock, and thus block the readers. This is all pretty messy, but it doesn't seem right that the LEDs framework imposes some locking requirements on users, in particular we'd have to make the spinlock in the iwlwifi driver always disable IRQs, even if we don't need that for any other reason, just to avoid this deadlock. Since writes to the led_cdevs list are rare (and are done by userspace), just switch the list to RCU. This costs a synchronize_rcu() at removal time so we can ensure things are correct, but that seems like a small price to pay for getting lock-free iterations and no deadlocks (nor any locking requirements imposed on users.) Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
#
791bc411 |
|
08-Jun-2021 |
Denis Osterland-Heim <Denis.Osterland@diehl.com> |
leds: move default_state read from fwnode to core This patch introduces a new function to read initial default_state from fwnode. Suggested-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
#
af0bfab9 |
|
11-Dec-2020 |
Abanoub Sameh <abanoubsameh8@gmail.com> |
leds: led-core: Get rid of enum led_brightness This gets rid of enum led_brightness in the main led files, because it is deprecated, and an unsigned int can be used instead. We can get rid of led_brightness completely and patches can also be supplied for the other drivers' files. Signed-off-by: Abanoub Sameh <abanoubsameh@protonmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
#
93690cdf |
|
16-Jul-2020 |
Marek Behún <marek.behun@nic.cz> |
leds: trigger: add support for LED-private device triggers Some LED controllers may come with an internal HW triggering mechanism for the LED and the ability to switch between SW control and the internal HW control. This includes most PHYs, various ethernet switches, the Turris Omnia LED controller or AXP20X PMIC. This adds support for registering such triggers. This code is based on work by Pavel Machek <pavel@ucw.cz> and Ondřej Jirman <megous@megous.com>. Signed-off-by: Marek Behún <marek.behun@nic.cz> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
#
c7e4ea68 |
|
21-Mar-2020 |
Pavel Machek <pavel@ucw.cz> |
leds: old enums are not really applicable to new code Warn about old defines that probably should not be used. Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
#
e389240a |
|
03-Oct-2019 |
Jean-Jacques Hiblot <jjhiblot@ti.com> |
leds: Add managed API to get a LED from a device driver If the LED is acquired by a consumer device with devm_led_get(), it is automatically released when the device is detached. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
#
699a8c7c |
|
03-Oct-2019 |
Tomi Valkeinen <tomi.valkeinen@ti.com> |
leds: Add of_led_get() and led_put() This patch adds basic support for a kernel driver to get a LED device. This will be used by the led-backlight driver. Only OF version is implemented for now, and the behavior is similar to PWM's of_pwm_get() and pwm_put(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
#
9cc93be7 |
|
02-Oct-2019 |
Dan Murphy <dmurphy@ti.com> |
leds: core: Fix leds.h structure documentation Update the leds.h structure documentation to define the correct arguments. Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
#
ec28a8cf |
|
02-Oct-2019 |
Dan Murphy <dmurphy@ti.com> |
leds: core: Remove extern from header extern is implied and is not needed in the header file. Remove the extern keyword and re-align the code. Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
#
11f70002 |
|
29-Sep-2019 |
Akinobu Mita <akinobu.mita@gmail.com> |
leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/trigger Reading /sys/class/leds/<led>/trigger returns all available LED triggers. However, the size of this file is limited to PAGE_SIZE because of the limitation for sysfs attribute. Enabling LED CPU trigger on systems with thousands of CPUs easily hits PAGE_SIZE limit, and makes it impossible to see all available LED triggers and which trigger is currently activated. We work around it here by converting /sys/class/leds/<led>/trigger to binary attribute, which is not limited by length. This is _not_ good design, do not copy it. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com>A Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
#
e3f12714 |
|
02-Oct-2019 |
Dan Murphy <dmurphy@ti.com> |
leds: core: Fix leds.h structure documentation Update the leds.h structure documentation to define the correct arguments. Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
7c322056 |
|
26-Aug-2019 |
Jacek Anaszewski <jacek.anaszewski@gmail.com> |
leds: Replace {devm_}led_classdev_register() macros with inlines Replace preprocessor macro aliases for legacy LED registration helpers with inline functions. It will allow to avoid misleading compiler error messages about missing symbol that actually wasn't explicitly used in the code. It used to occur when CONFIG_LEDS_CLASS was undefined and legacy (non-ext) function had been used in the code. Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz>
|
#
bb4e9af0 |
|
09-Jun-2019 |
Jacek Anaszewski <jacek.anaszewski@gmail.com> |
leds: core: Add support for composing LED class device names Add generic support for composing LED class device name. The newly introduced led_compose_name() function composes device name according to either <color:function> or <devicename:color:function> pattern, depending on the configuration of initialization data. Backward compatibility with in-driver hard-coded LED class device names is assured thanks to the default_label and devicename properties of newly introduced struct led_init_data. In case none of the aforementioned properties was found, then, for OF nodes, the node name is adopted for LED class device name. At the occassion of amending the Documentation/leds/leds-class.txt unify spelling: colour -> color. Alongside these changes added is a new tool - tools/leds/get_led_device_info.sh. The tool allows retrieving details of a LED class device's parent device, which proves that using vendor or product name for devicename part of LED name doesn't convey any added value since that information had been already available in sysfs. The script performs also basic validation of a LED class device name. Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Baolin Wang <baolin.wang@linaro.org> Cc: Dan Murphy <dmurphy@ti.com> Cc: Daniel Mack <daniel@zonque.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Oleh Kravchenko <oleg@kaa.org.ua> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Simon Shields <simon@lineageos.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Pavel Machek <pavel@ucw.cz>
|
#
b2b998c0 |
|
09-Jun-2019 |
Jacek Anaszewski <jacek.anaszewski@gmail.com> |
leds: class: Improve LED and LED flash class registration API Replace of_led_classdev_register() with led_classdev_register_ext(), which accepts easily extendable struct led_init_data, instead of the fixed struct device_node argument. The latter can be now passed in an fwnode property of the struct led_init_data. The modification is driven by the need for passing additional arguments required for the forthcoming generic mechanism for composing LED names. Currently the LED name is conveyed in the "name" char pointer property of the struct led_classdev. This is redundant since LED class device name is accessible throughout the whole LED class device life time via associated struct device's kobj->name property. The change will not break any existing clients since the patch alters also existing led_classdev{_flash}_register() macro wrappers, that pass NULL in place of init_data, which leads to using legacy name initialization path basing on the struct led_classdev's "name" property. Three existing users of devm_of_led_classdev_registers() are modified to use devm_led_classdev_register(), which will not impact their operation since they in fact didn't need to pass struct device_node on registration from the beginning. Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Baolin Wang <baolin.wang@linaro.org> Cc: Dan Murphy <dmurphy@ti.com> Cc: Daniel Mack <daniel@zonque.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Oleh Kravchenko <oleg@kaa.org.ua> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Simon Shields <simon@lineageos.org> Acked-by: Pavel Machek <pavel@ucw.cz>
|
#
d2912cb1 |
|
04-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
8e1f4561 |
|
09-Jan-2019 |
Krzysztof Kozlowski <krzk@kernel.org> |
leds: Add helper for getting default pattern from Device Tree Multiple LED triggers might need to access default pattern so add a helper for that. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
02d31765 |
|
10-Dec-2018 |
Jacek Anaszewski <jacek.anaszewski@gmail.com> |
led: triggers: Add LED_INIT_DEFAULT_TRIGGER flag Add the flag LED_INIT_DEFAULT_TRIGGER for indicating that trigger being set is a default trigger for the LED class device, and thus it should be initialized with settings provided in the fwnode. Set the flag in the led_trigger_set_default(). It is expected to be cleared in the activate() op of a trigger after trigger fwnode initialization data is parsed and applied. This should happen only once after LED class device registration, to allow leaving triggers in the idle state on re-apply and let the users apply their own settings without interference from the default ones. Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
#
faa2541f |
|
26-Nov-2018 |
Takashi Iwai <tiwai@suse.de> |
leds: trigger: Introduce audio mute LED trigger This patch adds a new LED trigger for coupling the audio mixer change with the LED on laptops or other devices. Currently there are two trigger types, "audio-mute" and "audio-micmute". The audio driver triggers the LED brightness change via ledtrig_audio_set() call with the proper type (either mute or mic-mute). OTOH, the consumers may call ledtrig_audio_get() for the initial brightness value that may have been set by the audio driver beforehand. This new stuff will be used by HD-audio codec driver and some platform drivers (thinkpad_acpi and dell-laptop, also upcoming huawei-wmi). Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
#
5fd752b6 |
|
10-Oct-2018 |
Baolin Wang <baolin.wang@linaro.org> |
leds: core: Introduce LED pattern trigger This patch adds a new LED trigger that LED device can configure to employ software or hardware pattern engine. Consumers can write 'pattern' file to enable the software pattern which alters the brightness for the specified duration with one software timer. Moreover consumers can write 'hw_pattern' file to enable the hardware pattern for some LED controllers which can autonomously control brightness over time, according to some preprogrammed hardware patterns. Signed-off-by: Raphael Teysseyre <rteysseyre@gmail.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
9acc560d |
|
02-Jul-2018 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
leds: triggers: new function led_set_trigger_data() This is the natural counter part to the already existing led_get_trigger_data(). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
a0b75076 |
|
02-Jul-2018 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
leds: triggers: define module_led_trigger helper This helps to simplify modules that provide a simple led_trigger. It's inspired by module_platform_driver, module_i2c_driver et al. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
a7e7a315 |
|
02-Jul-2018 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
leds: triggers: add device attribute support As many triggers use device attributes, add support for these in led_trigger_set which allows simplifying the drivers accordingly. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
2282e125 |
|
02-Jul-2018 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
leds: triggers: let struct led_trigger::activate() return an error code Given that activating a trigger can fail, let the callback return an indication. This prevents to have a trigger active according to the "trigger" sysfs attribute but not functional. All users are changed accordingly to return 0 for now. There is no intended change in behaviour. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
d1ed7c55 |
|
24-Feb-2018 |
Linus Walleij <linus.walleij@linaro.org> |
leds: Extends disk trigger for reads and writes This adds two new disk triggers for triggering on reads and writes respectively, named "disk-read" and "disk-write". The use case comes from working on the D-Link DNS-313 NAS box. This features an RGB LED for disk activity. with these two triggers I can couple the green LED to read activity and the red LED to write activity, which gives the appropriate user feedback about what is happening on the disk. When tested it gave exactly the feedback desired. The in-kernel interface is simply changed to pass a bool indicating if the activity is write activity and update each trigger (and the composite "disk-activity" trigger) depending on what is passed in. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
55edd1da |
|
13-Sep-2017 |
David Lin <dtwlin@google.com> |
leds: Replace flags bit shift with BIT() macros This is for readability as well as to avoid checkpatch warnings when adding new bit flag information in the future. Signed-off-by: David Lin <dtwlin@google.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
f5808ac1 |
|
27-Aug-2017 |
Andrew Jeffery <andrew@aj.id.au> |
leds: gpio: Allow LED to retain state at shutdown In some systems, such as Baseboard Management Controllers (BMCs), we want to retain the state of LEDs across a reboot of the BMC (whilst the host remains up). Implement support for the retain-state-shutdown devicetree property in leds-gpio. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Acked-by: Pavel Machek <pavel@ucw.cz> Tested-by: Brandon Wyman <bjwyman@gmail.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
442c6098 |
|
05-Mar-2017 |
Rafał Miłecki <rafal@milecki.pl> |
leds: core: add OF variants of LED registering functions 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>
|
#
b8c5099b |
|
29-Jan-2017 |
Hans de Goede <hdegoede@redhat.com> |
leds: class: Add new optional brightness_hw_changed attribute 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>
|
#
0cb8eb30 |
|
29-Jan-2017 |
Hans de Goede <hdegoede@redhat.com> |
leds: class: Add new optional brightness_hw_changed attribute 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>
|
#
4e552c8c |
|
04-Jan-2017 |
Andi Shyti <andi@etezian.org> |
leds: add LED_ON brightness as boolean value Some devices do not handle the led brightness or simply don't care about it. Conceptually said devices want to just switch on or off the led. It is useless in this case to have a 255 range of brightness, while just having an LED_ON and LED_OFF improves the boolean meaning of the led status. Signed-off-by: Andi Shyti <andi.shyti@samsung.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
|
#
eb1610b4 |
|
23-Oct-2016 |
Hans de Goede <hdegoede@redhat.com> |
led: core: Fix blink_brightness setting race 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>
|
#
a9c6ce57 |
|
08-Nov-2016 |
Hans de Goede <hdegoede@redhat.com> |
led: core: Use atomic bit-field for the blink-flags 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>
|
#
68620e59 |
|
14-Sep-2016 |
Heiner Kallweit <hkallweit1@gmail.com> |
leds: gpio: introduce gpio_blink_set_t Introduce a typedef gpio_blink_set_t to improve readability of the code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
#
fca23e47 |
|
21-Jun-2016 |
Andrew F. Davis <afd@ti.com> |
leds: Add no-op gpio_led_register_device when LED subsystem is disabled Some systems use 'gpio_led_register_device' to make an in-memory copy of their LED device table so the original can be removed as .init.rodata. When the LED subsystem is not enabled source in the led directory is not built and so this function may be undefined. Fix this here. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
#
eb25cb99 |
|
09-Jun-2016 |
Stephan Linz <linz@li-pro.net> |
leds: convert IDE trigger to common disk trigger This patch converts the IDE specific LED trigger to a generic disk activity LED trigger. The libata core is now a trigger source just like before the IDE disk driver. It's merely a replacement of the string ide by disk. The patch is taken from http://dev.gentoo.org/~josejx/ata.patch and is widely used by any ibook/powerbook owners with great satisfaction. Likewise, it is very often used successfully on different ARM platforms. Unlike the original patch, the existing 'ide-disk' trigger is still available for backward compatibility. That reduce the amount of patches in affected device trees out of the mainline kernel. For further development, the new name 'disk-activity' should be used. Cc: Joseph Jezak <josejx@gentoo.org> Cc: Jörg Sommer <joerg@alea.gnuu.de> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Stephan Linz <linz@li-pro.net> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
#
7cfe749f |
|
18-May-2016 |
Tony Makkiel <tony.makkiel@daqri.com> |
leds: core: Fix brightness setting upon hardware blinking enabled 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>
|
#
80d6737b |
|
28-Apr-2016 |
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> |
leds: gpio: Support the "panic-indicator" firmware property Calling a GPIO LEDs is quite likely to work even if the kernel has paniced, so they are ideal to blink in this situation. This commit adds support for the new "panic-indicator" firmware property, allowing to mark a given LED to blink on a kernel panic. Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
#
ba93cdce |
|
28-Apr-2016 |
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> |
leds: triggers: Allow to switch the trigger to "panic" on a kernel panic This commit adds a new led_cdev flag LED_PANIC_INDICATOR, which allows to mark a specific LED to be switched to the "panic" trigger, on a kernel panic. This is useful to allow the user to assign a regular trigger to a given LED, and still blink that LED on a kernel panic. Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Reviewed-by: Matthias Brugger <mbrugger@suse.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
#
4b721174 |
|
12-Apr-2016 |
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> |
leds: trigger: Introduce a MTD (NAND/NOR) trigger This commit introduces a MTD trigger for flash (NAND/NOR) device activity. The implementation is copied from IDE disk. This trigger deprecates the "nand-disk" LED trigger, but for backwards compatibility, we still keep the "nand-disk" trigger around. The motivation for deprecating the "nand-disk" LED trigger is that it only works for NAND drivers, whereas the "mtd" LED trigger is more generic (in fact, "nand-disk" currently only works for certain NAND drivers). Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
#
d84d80f3 |
|
22-Jan-2016 |
Heiner Kallweit <hkallweit1@gmail.com> |
leds: core: avoid error message when a USB LED device is unplugged 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>
|
#
70b2563b |
|
21-Jan-2016 |
Heiner Kallweit <hkallweit1@gmail.com> |
leds: core: fix misleading comment after workqueue removal from drivers Now that workqueues have been removed from individual drivers and were replaced with a core-internal workqueue we shouldn't encourage people to add new workqueues to drivers. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
#
9534cc31 |
|
01-Jan-2016 |
Heiner Kallweit <hkallweit1@gmail.com> |
leds: core: add managed version of led_trigger_register Complementing devm_led_classdev_register add a managed version of led_trigger_register. I omit a managed version of led_classdev_unregister as the equivalent devm_led_classdev_unregister isn't used in the kernel as of today. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
|
#
13ae79bb |
|
07-Oct-2015 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: core: Drivers shouldn't enforce SYNC/ASYNC brightness setting 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>
|
#
1afcadfc |
|
19-Oct-2015 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: core: Use set_brightness_work for the blocking op 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>
|
#
437a4240 |
|
07-Oct-2015 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: Rename brightness_set_sync op to brightness_set_blocking The initial purpose of brightness_set_sync op, introduced along with the LED flash class extension, was to add a means for setting torch LED brightness as soon as possible, which couldn't have been guaranteed by brightness_set op. This patch renames the op to brightness_set_blocking, which describes its purpose in a more generic way. It is beneficial in view of the prospective changes in the LED core, aiming at removing the need for using work queues in LED class drivers that can sleep or use delays while setting brightness. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
#
f1e80c07 |
|
07-Oct-2015 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: core: Add two new LED_BLINK_ flags 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>
|
#
8890624a |
|
17-Sep-2014 |
Michael Grzeschik <m.grzeschik@pengutronix.de> |
arcnet: com20020-pci: add led trigger support The EAE PLX-PCI card has special leds on the the main io pci resource bar. This patch adds support to trigger the conflict and data leds with the packages. Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
|
#
20f56758 |
|
28-Apr-2015 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: unify the location of led-trigger API Part of led-trigger API was in the private drivers/leds/leds.h header. Move it to the include/linux/leds.h header to unify the API location and announce it as public. It has been already exported from led-triggers.c with EXPORT_SYMBOL_GPL macro. The no-op definitions are changed from macros to inline to match the style of the surrounding code. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
#
94fdec76 |
|
04-Mar-2015 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: flash: Remove synchronized flash strobe feature Synchronized flash strobe feature has been considered not fitting for LED subsystem sysfs interface and thus is being removed. 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>
|
#
ca1bb4ee |
|
23-Feb-2015 |
Bjorn Andersson <bjorn.andersson@sonymobile.com> |
leds: Introduce devres helper for led_classdev_register (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>
|
#
7aea8389 |
|
09-Jan-2015 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: Add LED Flash class extension to the LED subsystem 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>
|
#
4d71a4a1 |
|
14-Nov-2014 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: Add support for setting brightness in a synchronous way 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>
|
#
acd899e4 |
|
22-Sep-2014 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: implement sysfs interface locking mechanism 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>
|
#
c673a2b4 |
|
31-Oct-2014 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
leds: leds-gpio: Convert gpio_blink_set() to use GPIO descriptors Commit 21f2aae91e902aad ("leds: leds-gpio: Add support for GPIO descriptors") already converted most of the driver to use GPIO descriptors. What is still missing is the platform specific hook gpio_blink_set() and board files which pass legacy GPIO numbers to this driver in platform data. In this patch we handle the former and convert gpio_blink_set() to take GPIO descriptor instead. In order to do this we convert the existing four users to accept GPIO descriptor and translate it to legacy GPIO number in the platform code. This effectively "pushes" legacy GPIO number usage from the driver to platforms. Also add comment to the remaining block describing that it is legacy code path and we are getting rid of it eventually. Suggested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
5c51277a |
|
27-Oct-2014 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
leds: leds-gpio: Add support for GPIO descriptors GPIO descriptors are the preferred way over legacy GPIO numbers nowadays. Convert the driver to use GPIO descriptors internally but still allow passing legacy GPIO numbers from platform data to support existing platforms. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Bryan Wu <cooloney@gmail.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Grant Likely <grant.likely@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3ef7de53 |
|
20-Aug-2014 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: Improve and export led_update_brightness 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>
|
#
d8082827 |
|
07-Aug-2014 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: make brightness type consistent across whole subsystem Documentations states that brightness units type is enum led_brightness and this is the type used by the led API functions. Adjust the type of brightness variables in the struct led_classdev accordingly. 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>
|
#
04713306 |
|
07-Aug-2014 |
Jacek Anaszewski <j.anaszewski@samsung.com> |
leds: Reorder include directives 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>
|
#
9067359f |
|
02-Sep-2014 |
Jiri Kosina <jkosina@suse.cz> |
Revert "leds: convert blink timer to workqueue" 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>
|
#
8b37e1be |
|
14-Jun-2014 |
Vincent Donnefort <vdonnefort@gmail.com> |
leds: convert blink timer to workqueue 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>
|
#
d0d480cc |
|
25-Jun-2014 |
Johan Hovold <johan@kernel.org> |
leds: add led-class attribute-group support 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>
|
#
48a1d032 |
|
14-Mar-2013 |
Kim, Milo <Milo.Kim@ti.com> |
leds: add camera LED triggers Some LED devices support flash/torch functionality through the LED subsystem. This patch enables direct LED trigger controls by the driver. Flash on/off and torch on/off can be done simply by other driver space. Two trigger APIs are added, ledtrig_flash_ctrl() and ledtrig_torch_ctrl(). Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
#
39f7e08a |
|
14-Mar-2013 |
Kim, Milo <Milo.Kim@ti.com> |
leds: trigger: use inline functions instead of macros Macros are used in case that an inline function doesn't work. Otherwise, use an empty inline function. (a) Case of !CONFIG_LEDS_TRIGGERS Following macros are replaced with inline functions. led_trigger_register_simple() led_trigger_unregister_simple() led_trigger_event() To make inline types, the structure, 'led_trigger' should be defined. This structure has no member at all. (b) Case of !CONFIG_LEDS_TRIGGER_IDE_DISK ledtrig_ide_activity() macro is replaced with an inline function as well. (c) DEFINE_LED_TRIGGER() and DEFINE_LED_TRIGGER_GLOBAL() Struct 'led_trigger' is defined both cases, with CONFIG_LEDS_TRIGGERS and without CONFIG_LEDS_TRIGGERS. Those macros are moved out of CONFIG_LED_TRIGGERS because of no-dependency on CONFIG_LEDS_TRIGGERS. (d) Fix build errors in mmc-core driver After replacing macros with inline functions, following build errors occur. (condition: CONFIG_LEDS_TRIGGERS is not set) drivers/mmc/core/core.c: In function 'mmc_request_done': drivers/mmc/core/core.c:164:25: error: 'struct mmc_host' has no member named 'led' drivers/mmc/core/core.c: In function 'mmc_start_request': drivers/mmc/core/core.c:254:24: error: 'struct mmc_host' has no member named 'led' make[3]: *** [drivers/mmc/core/core.o] Error 1 The reason of these errors is non-existent member variable, 'led'. It is only valid when CONFIG_LEDS_TRIGGERS is set. But now, it can be used without this dependency. To fix build errors, member 'led' is always used without its config option in 'include/linux/mmc/host.h'. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
#
057407c7 |
|
18-Nov-2012 |
Jingoo Han <jg1.han@samsung.com> |
led: Add dependency on CONFIG_LEDS_TRIGGERS to led_trigger_rename_static() This patch fixes build warnings when CONFIG_LEDS_TRIGGERS is disabled as below: include/linux/leds.h:158:18: warning: 'struct led_trigger' declared inside parameter list [enabled by default] include/linux/leds.h:158:18: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Fabio Baltieri <fabio.baltieri@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
#
a8df7b1a |
|
04-Nov-2012 |
Fabio Baltieri <fabio.baltieri@gmail.com> |
leds: add led_trigger_rename function Implements a "led_trigger_rename" function to rename a trigger with proper locking. This assumes that led name was originally allocated in non-constant storage. Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com> Cc: Kurt Van Dijck <kurt.van.dijck@eia.be> Signed-off-by: Bryan Wu <cooloney@gmail.com>
|
#
d23a22a7 |
|
15-Aug-2012 |
Fabio Baltieri <fabio.baltieri@gmail.com> |
leds: delay led_set_brightness if stopping soft-blink 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>
|
#
8f88731d |
|
25-Jun-2011 |
Bryan Wu <bryan.wu@canonical.com> |
led-triggers: create a trigger for CPU activity Attempting to consolidate the ARM LED code, this removes the custom RealView LED trigger code to turn LEDs on and off in response to CPU activity and replace it with a standard trigger. (bryan.wu@canonical.com: It introduces several syscore stubs into this trigger. It also provides ledtrig_cpu trigger event stub in <linux/leds.h>. Although it was inspired by ARM work, it can be used in other arch.) Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <bryan.wu@canonical.com> Reviewed-by: Jamie Iles <jamie@jamieiles.com> Tested-by: Jochen Friedrich <jochen@scram.de>
|
#
19cd67e2 |
|
13-Jun-2012 |
Shuah Khan <shuah@kernel.org> |
leds: Rename led_brightness_set() to led_set_brightness() 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>
|
#
5bb629c5 |
|
26-May-2012 |
Fabio Baltieri <fabio.baltieri@gmail.com> |
leds: add oneshot blink functions 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>
|
#
b0096182 |
|
29-May-2012 |
Shuah Khan <shuah@kernel.org> |
leds: add new field to led_classdev struct to save activation state Add a new field to led_classdev to save activattion state after activate routine is successful. This saved state is used in deactivate routine to do cleanup such as removing device files, and free memory allocated during activation. Currently trigger_data not being null is used for this purpose. Existing triggers will need changes to use this new field. Signed-off-by: Shuah Khan <shuahkhan@gmail.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>
|
#
4440673a |
|
24-May-2011 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
leds: provide helper to register "leds-gpio" devices This function makes a deep copy of the platform data to allow it to live in init memory. For a kernel that supports several machines and so includes the definition for several leds-gpio devices this saves quite some memory because all but one definition can be free'd after boot. As the function is used by arch code it must be builtin and so cannot go into leds-gpio.c. [akpm@linux-foundation.org: s/CONFIG_LED_REGISTER_GPIO/CONFIG_LEDS_REGISTER_GPIO/] Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Russell King <rmk@arm.linux.org.uk> Acked-by: Richard Purdie <richard.purdie@linuxfoundation.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: H Hartley Sweeten <hartleys@visionengravers.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
9517f925 |
|
22-Mar-2011 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
leds: make *struct gpio_led_platform_data.leds const And fix a typo. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
0b9536c9 |
|
07-Jan-2011 |
Vasily Khoruzhick <anarsoul@gmail.com> |
leds: Add ability to blink via simple trigger As blink API is now available, it's possible to add ability to blink via simple trigger. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
|
#
5ada28bf |
|
11-Nov-2010 |
Johannes Berg <johannes.berg@intel.com> |
led-class: always implement blinking 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>
|
#
2146325d |
|
22-May-2010 |
Benjamin Herrenschmidt <benh@kernel.crashing.org> |
leds: leds-gpio: Change blink_set callback to be able to turn off blinking The leds-gpio blink_set() callback follows the same prototype as the main leds subsystem blink_set() one. The problem is that to stop blink, normally, a leds driver does it in the brightness_set() callback when asked to set a new fixed value. However, with leds-gpio, the platform has no hook to do so, as this later callback results in a standard GPIO manipulation. This changes the leds-gpio specific callback to take a new argument that indicates whether the LED should be blinking or not and in what state it should be set if not. We also update the dns323 platform which seems to be the only user of this so far. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
#
a1dd8c61 |
|
22-Jun-2009 |
Richard Purdie <rpurdie@linux.intel.com> |
leds: Futher document blink_set Futher document blink_set function pointer Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
#
ed88bae6 |
|
12-May-2009 |
Trent Piepho <xyzzy@speakeasy.org> |
leds: Add options to have GPIO LEDs start on or keep their state There already is a "default-on" trigger but there are problems with it. For one, it's a inefficient way to do it and requires led trigger support to be compiled in. But the real reason is that is produces a glitch on the LED. The GPIO is allocate with the LED *off*, then *later* when the trigger runs it is turned back on. If the LED was already on via the GPIO's reset default or action of the firmware, this produces a glitch where the LED goes from on to off to on. While normally this is fast enough that it wouldn't be noticeable to a human observer, there are still serious problems. One is that there may be something else on the GPIO line, like a hardware alarm or watchdog, that is fast enough to notice the glitch. Another is that the kernel may panic before the LED is turned back on, thus hanging with the LED in the wrong state. This is not just speculation, but actually happened to me with an embedded system that has an LED which should turn off when the kernel finishes booting, which was left in the incorrect state due to a bug in the OF LED binding code. We also let GPIO LEDs get their initial value from whatever the current state of the GPIO line is. On some systems the LEDs are put into some state by the firmware or hardware before Linux boots, and it is desired to have them keep this state which is otherwise unknown to Linux. This requires that the underlying GPIO driver support reading the value of output GPIOs. Some drivers support this and some do not. The platform device binding gains a field in the platform data "default_state" that controls this. There are three constants defined to select from on, off, or keeping the current state. The OpenFirmware binding uses a property named "default-state" that can be set to "on", "off", or "keep". The default if the property isn't present is off. Signed-off-by: Trent Piepho <xyzzy@speakeasy.org> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Wolfram Sang <w.sang@pengutronix.de> Acked-by: Sean MacLennan <smaclennan@pikatech.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
#
92722b1b |
|
11-Jun-2009 |
Mark Brown <broonie@opensource.wolfsonmicro.com> |
leds: Further document parameters for blink_set() The documentation for the parameters of blink_set() was a bit hard to find so put some where I'd expected to find it. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
#
defb512d |
|
17-Feb-2009 |
Richard Purdie <rpurdie@linux.intel.com> |
leds: Add suspend/resume state flags to leds-gpio Add an option to preserve LED state when suspending/resuming to the LED gpio driver. Based on a suggestion from Robert Jarzmik. Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
#
1bd465e6 |
|
10-Jan-2009 |
Guennadi Liakhovetski <lg@denx.de> |
leds: allow led-drivers to use a variable range of brightness values This patch allows drivers to override the default maximum brightness value of 255. We take care to preserve backwards-compatibility as much as possible, so that user-space ABI doesn't change for existing drivers. LED trigger code has also been updated to use the per-LED maximum. Signed-off-by: Guennadi Liakhovetski <lg@denx.de> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
#
859cb7f2 |
|
08-Jan-2009 |
Richard Purdie <rpurdie@linux.intel.com> |
leds: Add suspend/resume to the core class Add suspend/resume to the core class and remove all the now unneeded code from various drivers. Originally the class code couldn't support suspend/resume but since class_device can there is no reason for each driver doing its own suspend/resume anymore.
|
#
e2387d6c |
|
17-Nov-2008 |
Wolfram Sang <wsa@kernel.org> |
leds: Make header variable naming consistent There is one place where the struct led_classdev as the function argument is named differently. Fix it. Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
#
326bb8a5 |
|
13-Oct-2008 |
Trent Piepho <tpiepho@freescale.com> |
leds: Make default trigger fields const The default_trigger fields of struct gpio_led and thus struct led_classdev are pretty much always assigned from a string literal, which means the string can't be modified. Which is fine, since there is no reason to modify the string and in fact it never is. But they should be marked const to prevent such code from being added, to prevent warnings if -Wwrite-strings is used, when assigned from a constant string other than a string literal (which produces a warning under current kernel compiler flags), and for general good coding practices. Signed-off-by: Trent Piepho <tpiepho@freescale.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
|
#
f46e9203 |
|
16-Jul-2008 |
Nate Case <ncase@xes-inc.com> |
leds: Add support for Philips PCA955x I2C LED drivers This driver supports the PCA9550, PCA9551, PCA9552, and PCA9553 LED driver chips. Signed-off-by: Nate Case <ncase@xes-inc.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
#
781a54e7 |
|
31-May-2008 |
Anton Vorontsov <avorontsov@ru.mvista.com> |
leds: mark led_classdev.default_trigger as const LED classdev core doesn't modify memory pointed by the default_trigger, so mark it as const and we'll able to pass const char *s without getting compiler warnings. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
#
2e214e0f |
|
24-Apr-2008 |
Richard Purdie <rpurdie@rpsys.net> |
leds: Document the context brightness_set needs Make sure there is no confusion about the contexts brightness_set can be called under by documenting it. Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
#
29d76dfa |
|
18-Mar-2008 |
Henrique de Moraes Holschuh <hmh@hmh.eng.br> |
leds: Add support to leds with readable status Some led hardware allows drivers to query the led state, and this patch adds a hook to let the led class take advantage of that information when available. Without this functionality, when access to the led hardware is not exclusive (i.e. firmware or hardware might change its state behind the kernel's back), reality goes out of sync with the led class' idea of what the led is doing, which is annoying at best. Behaviour for drivers that do not or cannot read the led status is unchanged. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
#
ca3259b3 |
|
09-Mar-2008 |
Herbert Valerio Riedel <hvr@gnu.org> |
leds: enable support for blink_set() platform hook in leds-gpio Enhance leds-gpio to provide hardware-based led flashing by passing through the blink_set() call to a optionally set platform-specific function pointer. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
#
b844eba2 |
|
23-Mar-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
PM: Remove destroy_suspended_device() After 2.6.24 there was a plan to make the PM core acquire all device semaphores during a suspend/hibernation to protect itself from concurrent operations involving device objects. That proved to be too heavy-handed and we found a better way to achieve the goal, but before it happened, we had introduced the functions device_pm_schedule_removal() and destroy_suspended_device() to allow drivers to "safely" destroy a suspended device and we had adapted some drivers to use them. Now that these functions are no longer necessary, it seems reasonable to remove them and modify their users to use the normal device unregistration instead. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
4c79141d |
|
31-Oct-2007 |
Márton Németh <nm127@freemail.hu> |
leds: Add support for hardware accelerated LED flashing Extends the leds subsystem with a blink_set() callback function which can be optionally implemented by a LED driver. If implemented, the driver can use the hardware acceleration for blinking a LED. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
#
fa23f5cc |
|
04-Feb-2008 |
Rafael J. Wysocki <rjw@rjwysocki.net> |
leds: add possibility to remove leds classdevs during suspend/resume Make it possible to unregister a led classdev object in a safe way during a suspend/resume cycle. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Michael Buesch <mb@bu3sch.de> Cc: Pavel Machek <pavel@ucw.cz> Cc: "John W. Linville" <linville@tuxdriver.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Len Brown <lenb@kernel.org> Cc: Greg KH <greg@kroah.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
dc47206e |
|
10-Nov-2007 |
Richard Purdie <rpurdie@rpsys.net> |
leds: Fix led trigger locking bugs Convert part of the led trigger core from rw spinlocks to rw semaphores. We're calling functions which can sleep from invalid contexts otherwise. Fixes bug #9264. Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
#
df96efd7 |
|
11-Sep-2007 |
Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> |
leds: Add missing include for leds.h This patch has added #include <linux/spinlock.h> to include/linux/leds.h for rwlock_t. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
#
0a3021f4 |
|
16-Jul-2007 |
Robert P. J. Day <rpjday@mindspring.com> |
Remove unnecessary includes of spinlock.h under include/linux Remove the obviously unnecessary includes of <linux/spinlock.h> under the include/linux/ directory, and fix the couple errors that are introduced as a result of that. Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
f8a7c6fe |
|
08-Jul-2007 |
Richard Purdie <rpurdie@rpsys.net> |
leds: Convert from struct class_device to struct device Convert the LEDs class from struct class_device to struct device since class_device is scheduled for removal. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
|
#
22e03f3b |
|
27-Feb-2007 |
Raphael Assenat <raph@8d.com> |
leds: Add generic GPIO LED driver This patch adds support for GPIO connected leds via the new GPIO framework. Information about leds (gpio, polarity, name, default trigger) is passed to the driver via platform_data. Signed-off-by: Raphael Assenat <raph@8d.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
|
#
af410fc1 |
|
29-Sep-2006 |
Johannes Berg <johannes@sipsolutions.net> |
[PATCH] make leds.h include relevant headers Make it possible to include linux/leds.h without first including list.h and spinlock.h. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
fb5035db |
|
10-Apr-2006 |
Ben Dooks <ben-linux@fluff.org> |
[PATCH] leds: re-layout include/linux/leds.h Lay out the structure definitions in include/linux/leds.h to be aligned as much as possible. Also minor updates to the comments to make them more concise. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
2bfb646c |
|
31-Mar-2006 |
Richard Purdie <rpurdie@rpsys.net> |
[PATCH] LED: Add IDE disk activity LED trigger Add an LED trigger for IDE disk activity to the ide-disk driver. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Acked-by: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
c3bc9956 |
|
31-Mar-2006 |
Richard Purdie <rpurdie@rpsys.net> |
[PATCH] LED: add LED trigger tupport Add support for LED triggers to the LED subsystem. "Triggers" are events which change the state of an LED. Two kinds of trigger are available, simple ones which can be added to exising code with minimum disruption and complex ones for implementing new or more complex functionality. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
c72a1d60 |
|
31-Mar-2006 |
Richard Purdie <rpurdie@rpsys.net> |
[PATCH] LED: add LED class 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>
|