summaryrefslogtreecommitdiffstats
path: root/include/linux/leds.h
Commit message (Collapse)AuthorAgeFilesLines
* leds: triggers: new function led_set_trigger_data()Uwe Kleine-König2018-07-051-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>
* leds: triggers: define module_led_trigger helperUwe Kleine-König2018-07-051-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>
* leds: triggers: add device attribute supportUwe Kleine-König2018-07-051-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>
* leds: triggers: let struct led_trigger::activate() return an error codeUwe Kleine-König2018-07-051-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>
* leds: Extends disk trigger for reads and writesLinus Walleij2018-03-111-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>
* leds: Replace flags bit shift with BIT() macrosDavid Lin2017-10-061-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>
* leds: gpio: Allow LED to retain state at shutdownAndrew Jeffery2017-08-291-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>
* leds: core: add OF variants of LED registering functionsRafał Miłecki2017-03-081-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>
* leds: class: Add new optional brightness_hw_changed attributeHans de Goede2017-01-291-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>
* leds: add LED_ON brightness as boolean valueAndi Shyti2017-01-051-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>
* led: core: Fix blink_brightness setting raceHans de Goede2016-11-221-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>
* led: core: Use atomic bit-field for the blink-flagsHans de Goede2016-11-221-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>
* leds: gpio: introduce gpio_blink_set_tHeiner Kallweit2016-09-151-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>
* leds: Add no-op gpio_led_register_device when LED subsystem is disabledAndrew F. Davis2016-06-271-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>
* leds: convert IDE trigger to common disk triggerStephan Linz2016-06-201-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>
* leds: core: Fix brightness setting upon hardware blinking enabledTony Makkiel2016-06-081-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>
* leds: gpio: Support the "panic-indicator" firmware propertyEzequiel Garcia2016-05-061-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>
* leds: triggers: Allow to switch the trigger to "panic" on a kernel panicEzequiel Garcia2016-05-061-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>
* leds: trigger: Introduce a MTD (NAND/NOR) triggerEzequiel Garcia2016-04-131-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>
* leds: core: avoid error message when a USB LED device is unpluggedHeiner Kallweit2016-03-141-0/+2
| | | | | | | | | | | | | | | When a USB LED device is unplugged the remove call chain calls led_classdev_unregister which tries to switch the LED off. As the device has been removed already this results in a ENODEV error message in dmesg. Avoid this error message by ignoring ENODEV in calls from led_classdev_unregister if the LED device is flagged as pluggable. Therefore a new flag LED_HW_PLUGGABLE was introduced which should be set by all LED drivers handling pluggable LED devices (mainly USB LED devices). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* leds: core: fix misleading comment after workqueue removal from driversHeiner Kallweit2016-03-141-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>
* leds: core: add managed version of led_trigger_registerHeiner Kallweit2016-01-041-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>
* leds: core: Drivers shouldn't enforce SYNC/ASYNC brightness settingJacek Anaszewski2016-01-041-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>
* leds: core: Use set_brightness_work for the blocking opJacek Anaszewski2016-01-041-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>
* leds: Rename brightness_set_sync op to brightness_set_blockingJacek Anaszewski2016-01-041-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>
* leds: core: Add two new LED_BLINK_ flagsJacek Anaszewski2016-01-041-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>
* arcnet: com20020-pci: add led trigger supportMichael Grzeschik2015-10-261-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>
* leds: unify the location of led-trigger APIJacek Anaszewski2015-05-041-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>
* leds: flash: Remove synchronized flash strobe featureJacek Anaszewski2015-03-091-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>
* leds: Introduce devres helper for led_classdev_registerBjorn Andersson2015-03-091-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>
* leds: Add LED Flash class extension to the LED subsystemJacek Anaszewski2015-01-261-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>
* Merge branch 'for-next' of ↵Linus Torvalds2014-12-151-0/+40
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED subsystem update from Bryan Wu: "We got some cleanup and driver for LP8860 as well as some patches for LED Flash Class" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: leds: lp8860: Fix module dependency leds: lp8860: Introduce TI lp8860 4 channel LED driver leds: Add support for setting brightness in a synchronous way leds: implement sysfs interface locking mechanism leds: syscon: handle multiple syscon instances leds: delete copy/paste mistake leds: regulator: Convert to devm_regulator_get_exclusive
| * leds: Add support for setting brightness in a synchronous wayJacek Anaszewski2014-11-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There are use cases when setting a LED brightness has to have immediate effect (e.g. setting a torch LED brightness). This patch extends LED subsystem to support such operations. The LED subsystem internal API __led_set_brightness is changed to led_set_brightness_async and new led_set_brightness_sync API is added. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * leds: implement sysfs interface locking mechanismJacek Anaszewski2014-11-141-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a mechanism for locking LED subsystem sysfs interface. This patch prepares ground for addition of LED Flash Class extension, whose API will be integrated with V4L2 Flash API. Such a fusion enforces introducing a locking scheme, which will secure consistent access to the LED Flash Class device. The mechanism being introduced allows for disabling LED subsystem sysfs interface by calling led_sysfs_disable function and enabling it by calling led_sysfs_enable. The functions alter the LED_SYSFS_DISABLE flag state and must be called under mutex lock. The state of the lock is checked with use of led_sysfs_is_disabled function. Such a design allows for providing immediate feedback to the user space on whether the LED Flash Class device is available or is under V4L2 Flash sub-device control. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* | leds: leds-gpio: Convert gpio_blink_set() to use GPIO descriptorsMika Westerberg2014-11-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | leds: leds-gpio: Add support for GPIO descriptorsMika Westerberg2014-11-041-0/+1
|/ | | | | | | | | | | | | | 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>
* leds: Improve and export led_update_brightnessJacek Anaszewski2014-09-121-0/+10
| | | | | | | | | | | | | | | led_update_brightness helper function used to be exploited only locally in the led-class.c module, where its result was being passed to the brightness_show sysfs callback. With the introduction of v4l2-flash subdevice the same functionality becomes required for reading current brightness from a LED device. This patch adds checking of return value of the brightness_get callback and moves the led_update_brightness() function to the LED subsystem public API. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: make brightness type consistent across whole subsystemJacek Anaszewski2014-09-111-2/+2
| | | | | | | | | | | 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>
* leds: Reorder include directivesJacek Anaszewski2014-09-111-1/+1
| | | | | | | | | | Reorder include directives so that they are arranged in alphabetical order. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* Revert "leds: convert blink timer to workqueue"Jiri Kosina2014-09-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758. It's broken as it changes led_blink_set() in a way that it can now sleep (while synchronously waiting for workqueue to be cancelled). That's a problem, because it's possible that this function gets called from atomic context (tpt_trig_timer() takes a readlock and thus disables preemption). This has been brought up 3 weeks ago already [1] but no proper fix has materialized, and I keep seeing the problem since 3.17-rc1. [1] https://lkml.org/lkml/2014/8/16/128 BUG: sleeping function called from invalid context at kernel/workqueue.c:2650 in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant 5 locks held by wpa_supplicant/2335: #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c7c92>] rtnl_lock+0x12/0x20 #1: (&wdev->mtx){+.+.+.}, at: [<ffffffffc06e649c>] cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211] #2: (&local->mtx){+.+.+.}, at: [<ffffffffc0817dea>] ieee80211_prep_connection+0x17a/0x9a0 [mac80211] #3: (&local->chanctx_mtx){+.+.+.}, at: [<ffffffffc08081ed>] ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211] #4: (&trig->leddev_list_lock){.+.+..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211] CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 ffff8800360b5a50 ffff8800751f76d8 ffffffff8159e97f ffff8800360b5a30 ffff8800751f76e8 ffffffff810739a5 ffff8800751f77b0 ffffffff8106862f ffffffff810685d0 0aa2209200000000 ffff880000000004 ffff8800361c59d0 Call Trace: [<ffffffff8159e97f>] dump_stack+0x4d/0x66 [<ffffffff810739a5>] __might_sleep+0xe5/0x120 [<ffffffff8106862f>] flush_work+0x5f/0x270 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90 [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211] [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211] [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [<ffffffffc06e36c0>] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211] [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0 [<ffffffff81584fa0>] ? ioctl_standard_iw_point+0x3e0/0x3e0 [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100 [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0 [<ffffffff814cfb29>] dev_ioctl+0x329/0x620 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0 [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520 [<ffffffff815a67fb>] ? sysret_check+0x1b/0x56 [<ffffffff810946ed>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0 [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3) wlan0: authenticated wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3) wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2) wlan0: associated IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready cfg80211: Calling CRDA for country: NA wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by 00:0b:6b:3c:8c:e4 ================================= [ INFO: inconsistent lock state ] 3.17.0-rc3 #1 Not tainted --------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes: ((&(&led_cdev->blink_work)->work)){+.?...}, at: [<ffffffff810685d0>] flush_work+0x0/0x270 {SOFTIRQ-ON-W} state was registered at: [<ffffffff81094dbe>] __lock_acquire+0x30e/0x1a30 [<ffffffff81096c81>] lock_acquire+0x91/0x110 [<ffffffff81068608>] flush_work+0x38/0x270 [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffffc081ecdd>] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211] [<ffffffffc07e4278>] __ieee80211_recalc_idle+0x98/0x140 [mac80211] [<ffffffffc07e59ce>] ieee80211_idle_off+0xe/0x10 [mac80211] [<ffffffffc0804e5b>] ieee80211_add_chanctx+0x3b/0x220 [mac80211] [<ffffffffc08062e4>] ieee80211_new_chanctx+0x44/0xf0 [mac80211] [<ffffffffc080838a>] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211] [<ffffffffc0817df8>] ieee80211_prep_connection+0x188/0x9a0 [mac80211] [<ffffffffc081c246>] ieee80211_mgd_auth+0x256/0x2e0 [mac80211] [<ffffffffc07eab33>] ieee80211_auth+0x13/0x20 [mac80211] [<ffffffffc06cb006>] cfg80211_mlme_auth+0x106/0x270 [cfg80211] [<ffffffffc06ce085>] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211] [<ffffffffc06cf670>] cfg80211_connect+0x3f0/0x540 [cfg80211] [<ffffffffc06e6148>] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211] [<ffffffffc06e651e>] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211] [<ffffffffc06e36dd>] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211] [<ffffffff81584d0c>] ioctl_standard_iw_point+0x14c/0x3e0 [<ffffffff8158502a>] ioctl_standard_call+0x8a/0xd0 [<ffffffff81584b76>] wireless_process_ioctl.constprop.10+0xb6/0x100 [<ffffffff8158521d>] wext_handle_ioctl+0x5d/0xb0 [<ffffffff814cfb29>] dev_ioctl+0x329/0x620 [<ffffffff8149c7f2>] sock_ioctl+0x142/0x2e0 [<ffffffff811b0140>] do_vfs_ioctl+0x300/0x520 [<ffffffff811b03e1>] SyS_ioctl+0x81/0xa0 [<ffffffff815a67d6>] system_call_fastpath+0x1a/0x1f irq event stamp: 493416 hardirqs last enabled at (493416): [<ffffffff81068a5f>] __cancel_work_timer+0x6f/0x100 hardirqs last disabled at (493415): [<ffffffff81067e9f>] try_to_grab_pending+0x1f/0x160 softirqs last enabled at (493408): [<ffffffff81053ced>] _local_bh_enable+0x1d/0x50 softirqs last disabled at (493409): [<ffffffff81054c75>] irq_exit+0xa5/0xb0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock((&(&led_cdev->blink_work)->work)); <Interrupt> lock((&(&led_cdev->blink_work)->work)); *** DEADLOCK *** 2 locks held by swapper/0/0: #0: (((&tpt_trig->timer))){+.-...}, at: [<ffffffff810b4c50>] call_timer_fn+0x0/0x180 #1: (&trig->leddev_list_lock){.+.?..}, at: [<ffffffffc081e68c>] tpt_trig_timer+0xec/0x170 [mac80211] stack backtrace: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.17.0-rc3 #1 Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008 ffffffff8246eb30 ffff88007c203b00 ffffffff8159e97f ffffffff81a194c0 ffff88007c203b50 ffffffff81599c29 0000000000000001 ffffffff00000001 ffff880000000000 0000000000000006 ffffffff81a194c0 ffffffff81093ad0 Call Trace: <IRQ> [<ffffffff8159e97f>] dump_stack+0x4d/0x66 [<ffffffff81599c29>] print_usage_bug+0x1f4/0x205 [<ffffffff81093ad0>] ? check_usage_backwards+0x140/0x140 [<ffffffff810944d3>] mark_lock+0x223/0x2b0 [<ffffffff81094d60>] __lock_acquire+0x2b0/0x1a30 [<ffffffff81096c81>] lock_acquire+0x91/0x110 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff81068608>] flush_work+0x38/0x270 [<ffffffff810685d0>] ? mod_delayed_work_on+0x80/0x80 [<ffffffff810945ca>] ? mark_held_locks+0x6a/0x90 [<ffffffff81068a5f>] ? __cancel_work_timer+0x6f/0x100 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff8109469d>] ? trace_hardirqs_on_caller+0xad/0x1c0 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff81068a6b>] __cancel_work_timer+0x7b/0x100 [<ffffffff81068b0e>] cancel_delayed_work_sync+0xe/0x10 [<ffffffff8147cf3b>] led_blink_set+0x1b/0x40 [<ffffffffc081e6b0>] tpt_trig_timer+0x110/0x170 [mac80211] [<ffffffff810b4cc5>] call_timer_fn+0x75/0x180 [<ffffffff810b4c50>] ? process_timeout+0x10/0x10 [<ffffffffc081e5a0>] ? __ieee80211_get_rx_led_name+0x10/0x10 [mac80211] [<ffffffff810b50ac>] run_timer_softirq+0x1fc/0x2f0 [<ffffffff81054805>] __do_softirq+0x115/0x2e0 [<ffffffff81054c75>] irq_exit+0xa5/0xb0 [<ffffffff810049b3>] do_IRQ+0x53/0xf0 [<ffffffff815a74af>] common_interrupt+0x6f/0x6f <EOI> [<ffffffff8147b56e>] ? cpuidle_enter_state+0x6e/0x180 [<ffffffff8147b732>] cpuidle_enter+0x12/0x20 [<ffffffff8108bba0>] cpu_startup_entry+0x330/0x360 [<ffffffff8158fb51>] rest_init+0xc1/0xd0 [<ffffffff8158fa90>] ? csum_partial_copy_generic+0x170/0x170 [<ffffffff81af3ff2>] start_kernel+0x44f/0x45a [<ffffffff81af399c>] ? set_init_arg+0x53/0x53 [<ffffffff81af35ad>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81af36a0>] x86_64_start_kernel+0xf1/0xf4 Cc: Vincent Donnefort <vdonnefort@gmail.com> Cc: Hugh Dickins <hughd@google.com> Cc: Tejun Heo <tj@kernel.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: convert blink timer to workqueueVincent Donnefort2014-07-031-2/+1
| | | | | | | | | | This patch converts the blink timer from led-core to workqueue which is more suitable for this kind of non-priority operations. Moreover, timer may lead to errors when a LED setting function use a scheduling function such as pinctrl which is using mutex. Signed-off-by: Vincent Donnefort <vdonnefort@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: add led-class attribute-group supportJohan Hovold2014-06-251-0/+2
| | | | | | | | | | Allow led-class devices to be created with optional attribute groups. This is needed in order to allow led drivers to create custom device attributes in a race-free manner. Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* leds: add camera LED triggersKim, Milo2013-04-011-0/+8
| | | | | | | | | | 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>
* leds: trigger: use inline functions instead of macrosKim, Milo2013-04-011-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* led: Add dependency on CONFIG_LEDS_TRIGGERS to led_trigger_rename_static()Jingoo Han2012-11-261-18/+17
| | | | | | | | | | | | 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>
* leds: add led_trigger_rename functionFabio Baltieri2012-11-261-0/+18
| | | | | | | | | | | | 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>
* Merge branch 'for-next' of ↵Linus Torvalds2012-10-101-0/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED subsystem update from Bryan Wu. * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (24 commits) leds: add output driver configuration for pca9633 led driver leds: lm3642: Use regmap_update_bits() in lm3642_chip_init() leds: Add new LED driver for lm3642 chips leds-lp5523: Fix riskiness of the page fault leds-lp5523: turn off the LED engines on unloading the driver leds-lm3530: Fix smatch warnings leds-lm3530: Use devm_regulator_get function leds: leds-gpio: adopt pinctrl support leds: Add new LED driver for lm355x chips leds-lp5523: use the i2c device id rather than fixed name leds-lp5523: add new device id for LP55231 leds-lp5523: support new LP55231 device leds: triggers: send uevent when changing triggers leds-lp5523: minor code style fixes leds-lp5523: change the return type of lp5523_set_mode() leds-lp5523: set the brightness to 0 forcely on removing the driver leds-lp5523: add channel name in the platform data leds: leds-gpio: Use of_get_child_count() helper leds: leds-gpio: Use platform_{get,set}_drvdata leds: leds-gpio: use of_match_ptr() ...
| * leds: delay led_set_brightness if stopping soft-blinkFabio Baltieri2012-09-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'for-arm-soc' of ↵Arnd Bergmann2012-08-131-0/+16
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds into next/drivers From Bryan Wu <bryan.wu@canonical.com>: Based on Linus Walleij's ARM LED consolidation work, this patchset introduce a new generic led trigger for CPU not only for ARM but also for others. For enabling CPU idle event, CPU arch code should call ledtrig_cpu() stub to trigger idle start or idle end event. These patches convert old style LED driver in arch/arm to gpio_led or new led driver interface. Against 3.5 release and build successfully for all the machines. Test ledtrig-cpu driver on OMAP4 Panda board. v9 --> v10 * fix compiling issue on versatile_defconfig reported by Russell King * rebase to 3.5 kernel and move patches to new git tree v8 --> v9: * use mutex to replace rw_sema pointed out by Tim Gardner * add a new struct led_trigger_cpu * add lock_is_inited to record mutex lock initialization v6 --> v7: * add a patch to unify the led-trigger name * fix some typo pointed * use BUG_ON to detect CPU numbers during building stage v5 --> v6: * replace __get_cpu_var() to per_cpu() * remove smp_processor_id() which is wrong with for_each_possible_cpu() * test on real OMAP4 Panda board * add comments about CPU hotplug in the CPU LED trigger driver v4 --> v5: * rebase all the patches on top of latest linux-next * replace on_each_cpu() with for_each_possible_cpu() * add some description of ledtrig_cpu() API * remove old leds code from driver nwflash.c, which should use a new led trigger then * this trigger driver can be built as module now v3 --> v4: * fix a typo pointed by Jochen Friedrich * fix some building errors * add Reviewed-by and Tested-by into patch log v2 --> v3: * almost rewrote the whole ledtrig-cpu driver, which is more simple * every CPU will have a per-CPU trigger * cpu trigger can be assigned to any leds * fix a lockdep issue in led-trigger common code * other fix according to review v1 --> v2: * remove select operations in Kconfig of every machines * add back supporting of led in core module of mach-integrator * solidate name scheme in ledtrig-cpu.c * add comments of CPU_LED_* cpu led events * fold patches of RealView and Versatile together * add machine_is_ check during assabet led driver init * add some Acked-by in patch logs * remove code for simpad machine in machine-sa11000, since Jochen Friedrich introduced gpiolib and gpio-led driver for simpad * on Assabet and Netwinder machine, LED operations is reversed like: setting bit means turn off leds clearing bit means turn on leds * add a new function to read CM_CTRL register for led driver * 'for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: ARM: use new LEDS CPU trigger stub to replace old one ARM: mach-sa1100: retire custom LED code ARM: mach-omap1: retire custom LED code ARM: mach-pnx4008: remove including old leds event API header file ARM: plat-samsung: remove including old leds event API header file ARM: mach-pxa: retire custom LED code char: nwflash: remove old led event code ARM: mach-footbridge: retire custom LED code ARM: mach-ebsa110: retire custom LED code ARM: mach-clps711x: retire custom LED code of P720T machine ARM: mach-integrator: retire custom LED code ARM: mach-integrator: move CM_CTRL to header file for accessing by other functions ARM: mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger ARM: mach-shark: retire custom LED code ARM: mach-ks8695: remove leds driver, since nobody use it ARM: mach-realview and mach-versatile: retire custom LED code ARM: at91: convert old leds drivers to gpio_led and led_trigger drivers led-triggers: create a trigger for CPU activity Conflicts: arch/arm/mach-clps711x/p720t.c arch/arm/mach-sa1100/leds-cerf.c arch/arm/mach-sa1100/leds-lart.c Let's hope this is the last time we pull this and it doesn't cause more trouble. I have verified that version 10 causes no build warnings or errors any more, and the patches still look good. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
| * led-triggers: create a trigger for CPU activityBryan Wu2012-07-311-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-02 17:42:07 +0000