summaryrefslogtreecommitdiff
path: root/include/linux/leds.h
AgeCommit message (Collapse)AuthorFilesLines
2021-09-27leds: trigger: use RCU to protect the led_cdevs listJohannes Berg1-1/+1
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>
2021-08-18leds: move default_state read from fwnode to coreDenis Osterland-Heim1-3/+9
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>
2021-02-19leds: led-core: Get rid of enum led_brightnessAbanoub Sameh1-7/+5
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>
2020-07-22leds: trigger: add support for LED-private device triggersMarek Behún1-0/+10
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>
2020-04-06leds: old enums are not really applicable to new codePavel Machek1-0/+1
Warn about old defines that probably should not be used. Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-01-06leds: Add managed API to get a LED from a device driverJean-Jacques Hiblot1-0/+2
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>
2020-01-06leds: Add of_led_get() and led_put()Tomi Valkeinen1-0/+4
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>
2019-11-03leds: core: Fix leds.h structure documentationDan Murphy1-3/+2
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>
2019-11-03leds: core: Remove extern from headerDan Murphy1-51/+44
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>
2019-11-03leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/triggerAkinobu Mita1-5/+0
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>
2019-09-01leds: Replace {devm_}led_classdev_register() macros with inlinesJacek Anaszewski1-4/+25
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>
2019-07-25leds: core: Add support for composing LED class device namesJacek Anaszewski1-0/+45
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>
2019-07-25leds: class: Improve LED and LED flash class registration APIJacek Anaszewski1-10/+24
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>
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner1-5/+1
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>
2019-01-17leds: Add helper for getting default pattern from Device TreeKrzysztof Kozlowski1-0/+13
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>
2018-12-26Merge tag 'leds-for-4.21-rc1' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED updates from Jacek Anaszewski: "There are several few-liners, where most of them are fixes and improvments. One thing standing out is ground preparation for inititializing trigger parameters via Device Tree. We introduce LED_INIT_DEFAULT_TRIGGER flag for that purpose and set it when default trigger is matched. It indicates that trigger should parse DT properties to retrieve the initialization data when set as default one" * tag 'leds-for-4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: led: triggers: Initialize LED_INIT_DEFAULT_TRIGGER if trigger is brought after class led: triggers: Add LED_INIT_DEFAULT_TRIGGER flag led: triggers: Break the for loop after default trigger is found leds: pwm: Use OF variant of LED registering function leds: pwm: Simplify with resource-managed devm_led_classdev_register() leds: gpio: Drop unneeded manual of_node assignment leds: 88pm860x: Use of_node_name_eq for node name comparisons leds: powernv: add of_node_put()
2018-12-10led: triggers: Add LED_INIT_DEFAULT_TRIGGER flagJacek Anaszewski1-0/+1
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>
2018-11-28leds: trigger: Introduce audio mute LED triggerTakashi Iwai1-0/+20
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>
2018-10-11leds: core: Introduce LED pattern triggerBaolin Wang1-0/+15
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>
2018-07-06leds: triggers: new function led_set_trigger_data()Uwe Kleine-König1-0/+7
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>
2018-07-06leds: triggers: define module_led_trigger helperUwe Kleine-König1-0/+4
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>
2018-07-06leds: triggers: add device attribute supportUwe Kleine-König1-0/+11
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>
2018-07-06leds: triggers: let struct led_trigger::activate() return an error codeUwe Kleine-König1-5/+9
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>
2018-03-11leds: Extends disk trigger for reads and writesLinus Walleij1-2/+2
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>
2017-10-06leds: Replace flags bit shift with BIT() macrosDavid Lin1-9/+9
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>
2017-08-29leds: gpio: Allow LED to retain state at shutdownAndrew Jeffery1-0/+2
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>
2017-03-08leds: core: add OF variants of LED registering functionsRafał Miłecki1-4/+10
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>
2017-01-29leds: class: Add new optional brightness_hw_changed attributeHans de Goede1-0/+15
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>
2017-01-06leds: add LED_ON brightness as boolean valueAndi Shyti1-0/+1
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>
2016-11-22led: core: Fix blink_brightness setting raceHans de Goede1-0/+1
All 3 of led_timer_func, led_set_brightness and led_set_software_blink set blink_brightness. If led_timer_func or led_set_software_blink race with led_set_brightness they may end up overwriting the new blink_brightness. The new atomic work_flags does not protect against this as it just protects the flags and not blink_brightness. This commit introduces a new new_blink_brightness value which gets set by led_set_brightness and read by led_timer_func on LED on, fixing this. Dealing with the new brightness at LED on time, makes the new brightness apply sooner, which also fixes a led_set_brightness which happens while a oneshot blink which ends in LED on is running not getting applied. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-22led: core: Use atomic bit-field for the blink-flagsHans de Goede1-10/+14
All the LED_BLINK* flags are accessed read-modify-write from e.g. led_set_brightness and led_blink_set_oneshot while both set_brightness_work and the blink_timer may be running. If these race then the modify step done by one of them may be lost, switch the LED_BLINK* flags to a new atomic work_flags bit-field to avoid this race. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-09-15leds: gpio: introduce gpio_blink_set_tHeiner Kallweit1-3/+6
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>
2016-06-27leds: Add no-op gpio_led_register_device when LED subsystem is disabledAndrew F. Davis1-0/+8
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>
2016-06-20leds: convert IDE trigger to common disk triggerStephan Linz1-3/+3
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>
2016-06-08leds: core: Fix brightness setting upon hardware blinking enabledTony Makkiel1-11/+12
Commit 76931edd54f8 ("leds: fix brightness changing when software blinking is active") changed the semantics of led_set_brightness() which according to the documentation should disable blinking upon any brightness setting. Moreover it made it different for soft blink case, where it was possible to change blink brightness, and for hardware blink case, where setting any brightness greater than 0 was ignored. While the change itself is against the documentation claims, it was driven also by the fact that timer trigger remained active after turning blinking off. Fixing that would have required major refactoring in the led-core, led-class, and led-triggers because of cyclic dependencies. Finally, it has been decided that allowing for brightness change during blinking is beneficial as it can be accomplished without disturbing blink rhythm. The change in brightness setting semantics will not affect existing LED class drivers that implement blink_set op thanks to the LED_BLINK_SW flag introduced by this patch. The flag state will be from now on checked in led_set_brightness() which will allow to distinguish between software and hardware blink mode. In the latter case the control will be passed directly to the drivers which apply their semantics on brightness set, which is disable the blinking in case of most such drivers. New drivers will apply new semantics and just change the brightness while hardware blinking is on, if possible. The issue was smuggled by subsequent LED core improvements, which modified the code that originally introduced the problem. Fixes: f1e80c07416a ("leds: core: Add two new LED_BLINK_ flags") Signed-off-by: Tony Makkiel <tony.makkiel@daqri.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-05-06leds: gpio: Support the "panic-indicator" firmware propertyEzequiel Garcia1-0/+1
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>
2016-05-06leds: triggers: Allow to switch the trigger to "panic" on a kernel panicEzequiel Garcia1-0/+1
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>
2016-04-13leds: trigger: Introduce a MTD (NAND/NOR) triggerEzequiel Garcia1-0/+6
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>
2016-03-14leds: core: avoid error message when a USB LED device is unpluggedHeiner Kallweit1-0/+2
When a USB LED device is unplugged the remove call chain calls led_classdev_unregister which tries to switch the LED off. As the device has been removed already this results in a ENODEV error message in dmesg. Avoid this error message by ignoring ENODEV in calls from led_classdev_unregister if the LED device is flagged as pluggable. Therefore a new flag LED_HW_PLUGGABLE was introduced which should be set by all LED drivers handling pluggable LED devices (mainly USB LED devices). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-03-14leds: core: fix misleading comment after workqueue removal from driversHeiner Kallweit1-2/+4
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>
2016-01-04leds: core: add managed version of led_trigger_registerHeiner Kallweit1-0/+2
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>
2016-01-04leds: core: Drivers shouldn't enforce SYNC/ASYNC brightness settingJacek Anaszewski1-3/+16
This patch removes SET_BRIGHTNESS_ASYNC and SET_BRIGHTNESS_SYNC flags. led_set_brightness() now calls led_set_brightness_nosleep() instead of choosing between sync and async op basing on the flags defined by the driver. From now on, if a user wants to make sure that brightness will be set synchronously, they have to use led_set_brightness_sync() API. It is now being made publicly available since it has become apparent that it is a caller who should decide whether brightness is to be set in a synchronous or an asynchronous way. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2016-01-04leds: core: Use set_brightness_work for the blocking opJacek Anaszewski1-1/+1
This patch makes LED core capable of setting brightness for drivers that implement brightness_set_blocking op. It removes from LED class drivers responsibility for using work queues on their own. In order to achieve this set_brightness_delayed callback is being modified to directly call one of available ops for brightness setting. led_set_brightness_async() function didn't set brightness in an asynchronous way in all cases. It was mistakenly assuming that all LED subsystem drivers used work queue in their brightness_set op, whereas only half of them did that. Since it has no users now, it is being removed. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2016-01-04leds: Rename brightness_set_sync op to brightness_set_blockingJacek Anaszewski1-2/+2
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>
2016-01-04leds: core: Add two new LED_BLINK_ flagsJacek Anaszewski1-4/+6
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>
2015-10-26arcnet: com20020-pci: add led trigger supportMichael Grzeschik1-0/+7
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>
2015-05-04leds: unify the location of led-trigger APIJacek Anaszewski1-0/+25
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>
2015-03-10leds: flash: Remove synchronized flash strobe featureJacek Anaszewski1-1/+0
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>
2015-03-09leds: Introduce devres helper for led_classdev_registerBjorn Andersson1-0/+4
(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>
2015-01-27leds: Add LED Flash class extension to the LED subsystemJacek Anaszewski1-0/+3
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>