kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-13 07:31:07 +00:00
Code Issues Releases Packages Activity
linux/drivers/leds/Kconfig

1059 lines
32 KiB
Raw Permalink Normal View History

treewide: Add SPDX license identifier - Makefile/Kconfig Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-19 13:07:45 +01:00
leds: move LEDS_GPIO_REGISTER out of menuconfig NEW_LEDS Commit 4440673a95e6 ("leds: provide helper to register "leds-gpio" devices") broke the display of the NEW_LEDS menu as it didn't depend on NEW_LEDS and so made "LED drivers" and "LED Triggers" appear at the same level as "LED Support" instead of below it as it was before 4440673a. Moving LEDS_GPIO_REGISTER out of the menuconfig NEW_LEDS fixes this unintended side effect. Reported-by: Axel Lin <axel.lin@gmail.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.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>
2011-06-15 15:08:31 -07:00
leds: expresswire: Don't depend on NEW_LEDS The ExpressWire library does not depend on NEW_LEDS and selecting it from a subsystem other than LEDs may cause Kconfig warnings: WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y] Selected by [y]: - BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y] Move it out of the "if NEW_LEDS" block to allow selection from other subsystems (in particular backlight) without raising this warning. Reported-by: Arnd Bergmann <arnd@arndb.de> Closes: https://lore.kernel.org/20240212111819.936815-1-arnd@kernel.org Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402161410.IG9I4odj-lkp@intel.com/ Suggested-by: Daniel Thompson <daniel.thompson@linaro.org> Fixes: 25ae5f5f4168 ("leds: Introduce ExpressWire library") Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr> Link: https://lore.kernel.org/r/20240216-expresswire-deps-v2-2-8be59c4a75f5@skole.hr Signed-off-by: Lee Jones <lee@kernel.org>
2024-02-16 22:15:44 +01:00
leds: Use menuconfig objects II - LED Change Kconfig objects from "menu, config" into "menuconfig" so that the user can disable the whole feature without having to enter the menu first. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-05-10 10:44:11 +01:00
[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>
2006-03-31 02:31:04 -08:00
[PATCH] LED: Improve Kconfig information Improve the NEW_LEDS Kconfig information to say what it does as well as what it doesn't. Signed-off-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-05-15 09:44:14 -07:00
leds: fix the incorrect display in menuconfig Seems when a config option does not have a dependency of the menuconfig, it messes the display of the rest configs, even if it's a hidden one. Signed-off-by: Eric Miao <eric.y.miao@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu> Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-06-15 15:08:40 -07:00
[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>
2006-03-31 02:31:04 -08:00
led-class: change back LEDS_CLASS to tristate instead of bool After moving some core functions to led-core.c, led-class.c can be built as module again. Signed-off-by: Bryan Wu <bryan.wu@canonical.com> Acked-by: Richard Purdie <richard.purdie@linuxfoundation.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-03-23 15:02:14 -07:00
[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>
2006-03-31 02:31:04 -08:00
leds: Kconfig: Be consistent with the usage of "LED" Update the Kconfig to be consistent in the case of using "LED" in the Kconfig. LED is an acronym and should be capitalized. Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2019-10-01 13:04:35 -05:00
leds: Kconfig: LEDS_CLASS is usually selected. People should really say Y to the LEDS_CLASS prompt. Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-03-25 11:39:29 +01:00
[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>
2006-03-31 02:31:04 -08:00
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>
2015-01-09 07:22:51 -08:00
leds: Small fixes for Flash class description Fix misspelling and capitalization of LED in the Kconfig. Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-04-03 13:19:22 -05:00
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>
2015-01-09 07:22:51 -08:00
leds: multicolor: Introduce a multicolor class definition Introduce a multicolor class that groups colored LEDs within a LED node. The multicolor class groups monochrome LEDs and allows controlling two aspects of the final combined color: hue and lightness. The former is controlled via the intensity file and the latter is controlled via brightness file. Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> [squashed leds: multicolor: Fix camel case in documentation in]
2020-07-16 13:19:56 -05:00
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>
2017-01-29 14:42:52 +01:00
leds: Kconfig: Be consistent with the usage of "LED" Update the Kconfig to be consistent in the case of using "LED" in the Kconfig. LED is an acronym and should be capitalized. Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2019-10-01 13:04:35 -05:00
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>
2017-01-29 14:42:52 +01:00
leds: Provide skeleton KUnit testing for the LEDs framework Apply a very basic implementation of KUnit LED testing. More tests / use-cases will be added steadily over time. CMD: tools/testing/kunit/kunit.py run --kunitconfig drivers/leds OUTPUT: [15:34:19] Configuring KUnit Kernel ... [15:34:19] Building KUnit Kernel ... Populating config with: $ make ARCH=um O=.kunit olddefconfig Building with: $ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=20 [15:34:22] Starting KUnit Kernel (1/1)... [15:34:22] ============================================================ Running tests with: $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt [15:34:23] ===================== led (1 subtest) ====================== [15:34:23] [PASSED] led_test_class_register [15:34:23] ======================= [PASSED] led ======================= [15:34:23] ============================================================ [15:34:23] Testing complete. Ran 1 tests: passed: 1 [15:34:23] Elapsed time: 4.268s total, 0.001s configuring, 3.048s building, 1.214s running Link: https://lore.kernel.org/r/20250424144544.1438584-1-lee@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-04-24 15:45:38 +01:00
[PATCH] leds: reorganise Kconfig Reorganise the drivers/leds Kconfig file to have the LED trigger enable with the triggers themselves. Also add comments to divide up the sections into the drivers and triggers 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>
2006-04-10 22:54:01 -07:00
[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>
2006-03-31 02:31:05 -08:00
led: Enable led in 88pm860x Enable led sub device in Marvell 88PM860x. Two LED arrays can be supported. Each LED array can be used for R,G,B leds. Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2010-01-06 17:10:09 -05:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig fixes Soekris net5501 is x86 only and cleanup some undeeded dependencies Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-05-27 13:08:33 +01:00
led: Enable led in 88pm860x Enable led sub device in Marvell 88PM860x. Two LED arrays can be supported. Each LED array can be used for R,G,B leds. Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2010-01-06 17:10:09 -05:00
leds: add Panasonic AN30259A support AN30259A is a 3-channel LED driver which uses I2C. It supports timed operation via an internal PWM clock, and variable brightness. This driver offers support for basic hardware-based blinking and brightness control. The datasheet is freely available: https://www.alliedelec.com/m/d/a9d2b3ee87c2d1a535a41dd747b1c247.pdf Signed-off-by: Simon Shields <simon@lineageos.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-09-09 20:38:25 +10:00
leds: Add driver for PC Engines APU/APU2 LEDs This patch implements the driver to support the front panel LEDs for PC Engines APU and APU2 boards. Signed-off-by: Alan Mizrahi <alan@mizrahi.com.ve> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-11-03 10:38:07 +09:00
leds: Modify PC Engines apu/apu2 driver to support apu3 PC Engines apu3 is an improved version of the apu2, using the same SoC and almost everything else. This patch reuses as much as possible from the apu2 definitions, to avoid redundancy. Signed-off-by: Raffaello D. Di Napoli <rafdev@dinapo.li> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-06-25 08:50:02 -04:00
leds: Add driver for PC Engines APU/APU2 LEDs This patch implements the driver to support the front panel LEDs for PC Engines APU and APU2 boards. Signed-off-by: Alan Mizrahi <alan@mizrahi.com.ve> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-11-03 10:38:07 +09:00
leds: apu: drop superseeded apu2/3 led support This driver only supports gpio-attached LEDs on apu1/2/3 boards, but neither gpio's themselves, nor other gpio-attached devices (eg. front button). For apu2+ a newer, more complete driver exists, based on a generic driver for the AMD SOCs gpio-controller, supporting LEDs as well other devices. Therefore these boards don't need legacy support from this driver anymore. Both drivers claim the same device, so only one driver may exist in a system, putting distros in the position to decide between either apu2+ keys or apu1 led support. Therefore drop the apu2+ led support from the old driver, solve the conflict and reduce unnecessary code. Signed-off-by: Enrico Weigelt <info@metux.net> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-07-15 16:57:28 +02:00
leds: Add driver for PC Engines APU/APU2 LEDs This patch implements the driver to support the front panel LEDs for PC Engines APU and APU2 boards. Signed-off-by: Alan Mizrahi <alan@mizrahi.com.ve> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-11-03 10:38:07 +09:00
leds: apu: drop superseeded apu2/3 led support This driver only supports gpio-attached LEDs on apu1/2/3 boards, but neither gpio's themselves, nor other gpio-attached devices (eg. front button). For apu2+ a newer, more complete driver exists, based on a generic driver for the AMD SOCs gpio-controller, supporting LEDs as well other devices. Therefore these boards don't need legacy support from this driver anymore. Both drivers claim the same device, so only one driver may exist in a system, putting distros in the position to decide between either apu2+ keys or apu1 led support. Therefore drop the apu2+ led support from the old driver, solve the conflict and reduce unnecessary code. Signed-off-by: Enrico Weigelt <info@metux.net> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-07-15 16:57:28 +02:00
leds: Add driver for PC Engines APU/APU2 LEDs This patch implements the driver to support the front panel LEDs for PC Engines APU and APU2 boards. Signed-off-by: Alan Mizrahi <alan@mizrahi.com.ve> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-11-03 10:38:07 +09:00
leds: Add driver for AAT1290 flash LED controller This patch adds a driver for the 1.5A Step-Up Current Regulator for Flash LEDs. The device is programmed through a Skyworks proprietary AS2Cwire serial digital interface. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-04-30 03:34:57 -07:00
leds: ariel: Add driver for status LEDs on Dell Wyse 3020 This adds support for controlling the LEDs attached to the Embedded Controller on a Dell Wyse 3020 "Ariel" board. Signed-off-by: Lubomir Rintel <lkundrak@v3.sk> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-04-25 00:02:40 +02:00
leds: as3668: Driver for the ams Osram 4-channel i2c LED driver Since there were no existing drivers for the AS3668 or related devices, a new driver was introduced in a separate file. Similar devices were reviewed, but none shared enough characteristics to justify code reuse. As a result, this driver is written specifically for the AS3668. Signed-off-by: Lukas Timmermann <linux@timmermann.space> Link: https://patch.msgid.link/20260118165010.902086-3-linux@timmermann.space Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-18 17:50:10 +01:00
leds: Add AW20xx driver This commit adds support for AWINIC AW20036/AW20054/AW20072 LED driver. This driver supports following AW200XX features: - Individual 64-level DIM currents Signed-off-by: Martin Kurbanov <mmkurbanov@sberdevices.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230519130403.212479-3-mmkurbanov@sberdevices.ru Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-19 16:04:03 +03:00
leds: aw200xx: Add support for aw20108 device Add support for the Awinic aw20108 device, which belongs to the same LED drivers family. The new device supports 108 LEDs using a matrix of 12x9 outputs." Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com> Link: https://lore.kernel.org/r/20231125200519.1750-10-ddrokosov@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-25 23:05:17 +03:00
leds: Add AW20xx driver This commit adds support for AWINIC AW20036/AW20054/AW20072 LED driver. This driver supports following AW200XX features: - Individual 64-level DIM currents Signed-off-by: Martin Kurbanov <mmkurbanov@sberdevices.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230519130403.212479-3-mmkurbanov@sberdevices.ru Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-19 16:04:03 +03:00
leds: aw200xx: Add support for aw20108 device Add support for the Awinic aw20108 device, which belongs to the same LED drivers family. The new device supports 108 LEDs using a matrix of 12x9 outputs." Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com> Link: https://lore.kernel.org/r/20231125200519.1750-10-ddrokosov@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-25 23:05:17 +03:00
leds: Add AW20xx driver This commit adds support for AWINIC AW20036/AW20054/AW20072 LED driver. This driver supports following AW200XX features: - Individual 64-level DIM currents Signed-off-by: Martin Kurbanov <mmkurbanov@sberdevices.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230519130403.212479-3-mmkurbanov@sberdevices.ru Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-19 16:04:03 +03:00
leds: add aw2013 driver This commit adds support for AWINIC AW2013 3-channel LED driver. The chip supports 3 PWM channels and is controlled with I2C. Signed-off-by: Nikita Travkin <nikitos.tr@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-05-11 16:11:28 +05:00
leds: aw2013: Select missing dependency REGMAP_I2C The AW2013 driver uses devm_regmap_init_i2c, so REGMAP_I2C needs to be selected. Otherwise build process may fail with: ld: drivers/leds/leds-aw2013.o: in function `aw2013_probe': leds-aw2013.c:345: undefined reference to `__devm_regmap_init_i2c' Signed-off-by: Dang Huynh <danct12@riseup.net> Acked-by: Nikita Travkin <nikita@trvn.ru> Fixes: 59ea3c9faf32 ("leds: add aw2013 driver") Link: https://lore.kernel.org/r/20231103114203.1108922-1-danct12@riseup.net Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-03 18:42:03 +07:00
leds: add aw2013 driver This commit adds support for AWINIC AW2013 3-channel LED driver. The chip supports 3 PWM channels and is controlled with I2C. Signed-off-by: Nikita Travkin <nikitos.tr@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-05-11 16:11:28 +05:00
leds: add BCM6328 LED driver This adds support for the LED controller on Broadcom's BCM6328. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Signed-off-by: Jonas Gorski <jogo@openwrt.org> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-04-28 09:50:50 -07:00
leds: add HAS_IOMEM dependency to LEDS_BCM6328/LEDS_BCM6358 Ran into this on UML: drivers/built-in.o: In function `bcm6328_leds_probe': drivers/leds/leds-bcm6328.c:340: undefined reference to `devm_ioremap_resource' drivers/built-in.o: In function `bcm6358_leds_probe': drivers/leds/leds-bcm6358.c:173: undefined reference to `devm_ioremap_resource' collect2: error: ld returned 1 exit status devm_ioremap_resource() is defined only when HAS_IOMEM is selected. Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: linux-leds@vger.kernel.org Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-01-02 14:05:49 +01:00
leds: add BCM6328 LED driver This adds support for the LED controller on Broadcom's BCM6328. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Signed-off-by: Jonas Gorski <jogo@openwrt.org> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-04-28 09:50:50 -07:00
leds: add BCM6358 LED driver This adds support for the LED controller on Broadcom's BCM6358. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-05-21 10:11:10 -07:00
leds: add HAS_IOMEM dependency to LEDS_BCM6328/LEDS_BCM6358 Ran into this on UML: drivers/built-in.o: In function `bcm6328_leds_probe': drivers/leds/leds-bcm6328.c:340: undefined reference to `devm_ioremap_resource' drivers/built-in.o: In function `bcm6358_leds_probe': drivers/leds/leds-bcm6358.c:173: undefined reference to `devm_ioremap_resource' collect2: error: ld returned 1 exit status devm_ioremap_resource() is defined only when HAS_IOMEM is selected. Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: linux-leds@vger.kernel.org Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-01-02 14:05:49 +01:00
leds: add BCM6358 LED driver This adds support for the LED controller on Broadcom's BCM6358. Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-05-21 10:11:10 -07:00
leds: Add Intel Cherry Trail Whiskey Cove PMIC LED driver Add support for LEDs connected to the Intel Cherry Trail Whiskey Cove PMIC. Charger and general-purpose LEDs are supported. Hardware blinking is implemented, breathing is not. This driver was tested with Lenovo Yoga Book notebook. Changes by Hans de Goede (in response to review of v2): - Since the PMIC is connected to the battery any changes we make to the LED settings are permanent, even surviving reboot / poweroff. Save LED1 register settings on probe() and if auto-/hw-control was enabled on probe() restore the settings on remove() and shutdown(). - Delay switching LED1 to software control mode to first brightness write. - Use dynamically allocated drvdata instead of a global drvdata variable. - Ensure the LED is on when activating blinking. - Fix CHT_WC_LED_EFF_BREATHING val ((3 << 1) rather then BIT(3)). Link: https://lore.kernel.org/r/20190212205901.13037-2-jekhor@gmail.com Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430195952.862527-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-04-30 21:59:48 +02:00
leds: cpcap: new driver Motorola CPCAP is a PMIC (power management integrated circuit) found in multiple smartphones. This driver adds support for the chip's LED controllers. This introduces support for all controllers used by the Droid 4. According to Motorola's driver (no datasheets available) there a couple of more LED controllers. I did not add support for them, since I cannot verify that they work with my modifications. Signed-off-by: Sebastian Reichel <sre@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-24 09:47:32 +01:00
leds: add LED driver for CR0014114 board This patch adds a LED class driver for the RGB LEDs found on the Crane Merchandising System CR0014114 LEDs board. Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-04-02 15:53:50 +03:00
leds: Add ChromeOS EC driver The ChromeOS Embedded Controller exposes an LED control command. Expose its functionality through the leds subsystem. The LEDs are exposed as multicolor devices. A hardware trigger, which is active by default, is provided to let the EC itself take over control over the LED. The driver is designed to be probed via the cros_ec mfd device. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-4-500b50f41e0f@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-13 16:48:39 +02:00
leds: add LED driver for EL15203000 board This patch adds a LED class driver for the LEDs found on the Crane Merchandising System EL15203000 LEDs board (aka RED LEDs board). Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua> Reviewed-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2019-09-19 15:53:13 +03:00
leds: initial support for Turris Omnia LEDs This adds basic support for LEDs on the front side of CZ.NIC's Turris Omnia router. There are 12 RGB LEDs. The controller supports HW triggering mode for the LEDs, but this driver does not support it yet, and sets all the LEDs defined in device-tree into SW mode upon probe. This driver uses the multicolor LED framework. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-23 14:53:19 +02:00
leds: turris-omnia: Use command execution functions from the MCU driver Use the MCU command execution functions from the MCU driver instead of the ad-hoc implementation in the LED driver. This allows as to drop the LED driver implementation, which is a duplicate. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20241111100355.6978-3-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-11 11:03:46 +01:00
leds: turris-omnia: Notify sysfs on MCU global LEDs brightness change Recall that on Turris Omnia, the LED controller has a global brightness property, which allows the user to make the front LED panel dimmer. There is also a button on the front panel, which by default is configured so that pressing it changes the global brightness to a lower value (unless it is at 0%, in which case pressing the button changes the global brightness to 100%). Newer versions of the MCU firmware support informing the SOC that the brightness was changed by button press event via an interrupt. Now that we have the turris-omnia-mcu driver, which adds support for MCU interrupts, add the ability to inform the userspace (via a sysfs notification) that the global brightness was changed. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20241111100355.6978-8-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-11 11:03:51 +01:00
leds: turris-omnia: Support HW controlled mode via private trigger Add support for enabling MCU controlled mode of the Turris Omnia LEDs via a LED private trigger called "omnia-mcu". Recall that private LED triggers will only be listed in the sysfs trigger file for LEDs that support them (currently there is no user of this mechanism). When in MCU controlled mode, the user can still set LED color, but the blinking is done by MCU, which does different things for different LEDs: - WAN LED is blinked according to the LED[0] pin of the WAN PHY - LAN LEDs are blinked according to the LED[0] output of the corresponding port of the LAN switch - PCIe LEDs are blinked according to the logical OR of the MiniPCIe port LED pins In the future I want to make the netdev trigger to transparently offload the blinking to the HW if user sets compatible settings for the netdev trigger (for LEDs associated with network devices). There was some work on this already, and hopefully we will be able to complete it sometime, but for now there are still multiple blockers for this, and even if there weren't, we still would not be able to configure HW controlled mode for the LEDs associated with MiniPCIe ports. In the meantime let's support HW controlled mode via the private LED trigger mechanism. If, in the future, we manage to complete the netdev trigger offloading, we can still keep this private trigger for backwards compatibility, if needed. We also set "omnia-mcu" to cdev->default_trigger, so that the MCU keeps control until the user first wants to take over it. If a different default trigger is specified in device-tree via the 'linux,default-trigger' property, LED class will overwrite cdev->default_trigger, and so the DT property will be respected. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20230918161104.20860-4-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-09-18 18:11:03 +02:00
leds: initial support for Turris Omnia LEDs This adds basic support for LEDs on the front side of CZ.NIC's Turris Omnia router. There are 12 RGB LEDs. The controller supports HW triggering mode for the LEDs, but this driver does not support it yet, and sets all the LEDs defined in device-tree into SW mode upon probe. This driver uses the multicolor LED framework. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-23 14:53:19 +02:00
leds: add driver for LM3530 ALS Simple backlight driver for National Semiconductor LM3530. Presently only manual mode is supported, PWM and ALS support to be added. Signed-off-by: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com> Cc: Linus Walleij <linus.walleij@stericsson.com> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-03-22 16:30:16 -07:00
leds: lm3532: Introduce the lm3532 LED driver Introduce the Texas Instruments LM3532 White LED driver. The driver supports ALS configurability or manual brightness control. The driver also supports associating LED strings with specific control banks in a group or as individually controlled strings. Signed-off-by: Dan Murphy <dmurphy@ti.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-03-21 09:28:38 -05:00
leds: lm3532: select regmap I2C API Regmap APIs should be selected, otherwise link can fail ERROR: modpost: "__devm_regmap_init_i2c" [drivers/leds/leds-lm3532.ko] undefined! Fixes: bc1b8492c764 ("leds: lm3532: Introduce the lm3532 LED driver") Cc: Dan Murphy <dmurphy@ti.com> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-05-10 12:50:31 +03:00
leds: lm3532: Introduce the lm3532 LED driver Introduce the Texas Instruments LM3532 White LED driver. The driver supports ALS configurability or manual brightness control. The driver also supports associating LED strings with specific control banks in a group or as individually controlled strings. Signed-off-by: Dan Murphy <dmurphy@ti.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-03-21 09:28:38 -05:00
leds: add LM3533 LED driver Add sub-driver for the LEDs on National Semiconductor / TI LM3533 lighting power chips. The chip provides 256 brightness levels, hardware accelerated blinking as well as ambient-light-sensor and pwm input control. Signed-off-by: Johan Hovold <jhovold@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Rob Landley <rob@landley.net> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Jonathan Cameron <jic23@cam.ac.uk> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> 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>
2012-05-29 15:07:31 -07:00
leds: Add new LED driver for lm3642 chips This driver is a general version for LM642 led chip of TI. LM3642 : The LM3642 is a 4MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. The LM3642 is controlled via an I2C-compatible interface. Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-12 20:05:50 +08:00
leds: lm3692x: Introduce LM3692x dual string driver Introducing the LM3692x Dual-String white LED driver. Data sheet is located http://www.ti.com/lit/ds/snvsa29/snvsa29.pdf Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-12 12:15:50 -06:00
leds: Add new LED driver for lm3642 chips This driver is a general version for LM642 led chip of TI. LM3642 : The LM3642 is a 4MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. The LM3642 is controlled via an I2C-compatible interface. Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-12 20:05:50 +08:00
[PATCH] LED: add LED device support for locomo devices Adds an LED driver for LEDs exported by the Sharp LOCOMO chip as found on some models of Sharp Zaurus. 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>
2006-03-31 02:31:10 -08:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
[PATCH] LED: add LED device support for locomo devices Adds an LED driver for LEDs exported by the Sharp LOCOMO chip as found on some models of Sharp Zaurus. 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>
2006-03-31 02:31:10 -08:00
leds: Add rb532 LED driver for the User LED Mikrotik built six LEDs into the Routerboard 532, from which one is destined for custom use, the so called "User LED". This patch adds a driver for it, based on the LEDs class. Signed-off-by: Phil Sutter <n0-1@freewrt.org> Acked-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-22 19:35:48 +01:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: Add rb532 LED driver for the User LED Mikrotik built six LEDs into the Routerboard 532, from which one is destined for custom use, the so called "User LED". This patch adds a driver for it, based on the LEDs class. Signed-off-by: Phil Sutter <n0-1@freewrt.org> Acked-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-22 19:35:48 +01:00
leds: Add LED support for MT6323 PMIC MT6323 PMIC is a multi-function device that includes LED function. It allows attaching up to 4 LEDs which can either be on, off or dimmed and/or blinked with the controller. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-03-20 14:47:26 +08:00
[PATCH] LED Class support for Soekris net48xx Add LED Class device support for the Soekris net48xx Error LED. Tested only on a net4801, but should work on a net4826 as well. I'd love to find a way of detecting a Soekris net48xx device but there is no DMI or any Soekris-specific PCI devices. [akpm@osdl.org: fixlets, cleanups] Signed-off-by: Chris Boot <bootc@bootc.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-10 04:45:34 -07:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
[PATCH] LED Class support for Soekris net48xx Add LED Class device support for the Soekris net48xx Error LED. Tested only on a net4801, but should work on a net4826 as well. I'd love to find a way of detecting a Soekris net48xx device but there is no DMI or any Soekris-specific PCI devices. [akpm@osdl.org: fixlets, cleanups] Signed-off-by: Chris Boot <bootc@bootc.net> Cc: Ben Dooks <ben-linux@fluff.org> Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-07-10 04:45:34 -07:00
[PATCH] PCEngines WRAP LED Support A driver for the PCEngines WRAP boards (http://www.pcengines.ch), which are very similar to the Soekris net4801 (same NS SC1100 geode reference design). The LEDs on the WRAP are on different GPIO lines and I have modified and copied the net48xx error led support for this. It also includes support for an "extra" led (in addition to error). The three LEDs on the WRAP are at GPIO lines 2,3,18 (WRAP LEDs from left to right). This driver gives access to the second and third LEDs by twiddling GPIO lines 3 & 18. Because these boards are so similar to the net48xx, I basically sed-ed that driver to form the basis for leds-wrap.c. The only changes from leds-net48xx.c are: - #define WRAP_EXTRA_LED_GPIO - name changes - duplicate relevant sections to provide support for the "extra" led - reverse the various *_led_set values. The WRAP is "backwards" from the net48xx, and these needed to be updated for that. [akpm@osdl.org: build fix] Signed-off-by: Kristian Kielhofner <kris@krisk.org> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-06 20:37:28 -08:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
[PATCH] PCEngines WRAP LED Support A driver for the PCEngines WRAP boards (http://www.pcengines.ch), which are very similar to the Soekris net4801 (same NS SC1100 geode reference design). The LEDs on the WRAP are on different GPIO lines and I have modified and copied the net48xx error led support for this. It also includes support for an "extra" led (in addition to error). The three LEDs on the WRAP are at GPIO lines 2,3,18 (WRAP LEDs from left to right). This driver gives access to the second and third LEDs by twiddling GPIO lines 3 & 18. Because these boards are so similar to the net48xx, I basically sed-ed that driver to form the basis for leds-wrap.c. The only changes from leds-net48xx.c are: - #define WRAP_EXTRA_LED_GPIO - name changes - duplicate relevant sections to provide support for the "extra" led - reverse the various *_led_set values. The WRAP is "backwards" from the net48xx, and these needed to be updated for that. [akpm@osdl.org: build fix] Signed-off-by: Kristian Kielhofner <kris@krisk.org> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-12-06 20:37:28 -08:00
leds: Rename leds-cobalt driver The leds-cobalt driver only supports the Coable Qube series (not included in Cobalt Raq series). Rename the driver and update Kconfig/Makefile. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Acked-by: Florian Fainelli <florian.fainelli@telecomint.eu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-09-21 00:02:47 +01:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: various: compile if COMPILE_TEST=y These drivers can be compiled without modification when COMPILE_TEST=y: cobalt-qube, cobalt-raq, netxbig, ns2 and s3c24xx Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-09-18 00:32:49 +02:00
leds: Add support for Cobalt Server front LED Add support for Cobalt Server front LED (MIPS) Signed-off-by: Florian Fainell <florian.fainelli@int-evry.fr> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-02-12 23:16:27 +00:00
leds: Rename leds-cobalt driver The leds-cobalt driver only supports the Coable Qube series (not included in Cobalt Raq series). Rename the driver and update Kconfig/Makefile. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Acked-by: Florian Fainelli <florian.fainelli@telecomint.eu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-09-21 00:02:47 +01:00
leds: Add support for Cobalt Server front LED Add support for Cobalt Server front LED (MIPS) Signed-off-by: Florian Fainell <florian.fainelli@int-evry.fr> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-02-12 23:16:27 +00:00
leds: Add Cobalt Raq series LEDs support Add Cobalt Raq series LEDs support. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-09-27 17:51:05 +09:00
leds: various: compile if COMPILE_TEST=y These drivers can be compiled without modification when COMPILE_TEST=y: cobalt-qube, cobalt-raq, netxbig, ns2 and s3c24xx Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-09-18 00:32:49 +02:00
leds: Add Cobalt Raq series LEDs support Add Cobalt Raq series LEDs support. Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp> Acked-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-09-27 17:51:05 +09:00
leds: sun50i-a100: New driver for the A100 LED controller Some Allwinner sunxi SoCs, starting with the A100, contain an LED controller designed to drive RGB LED pixels. Add a driver for it using the multicolor LED framework, and with LEDs defined in the device tree. Acked-by: Guo Ren <guoren@kernel.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20231029212738.7871-3-samuel@sholland.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-10-29 16:26:56 -05:00
leds: sun50i-a100: Convert to be agnostic to property provider Convert the driver to be agnostic to the property provider. LEDS subsytem is not dependent on OF, so no need to make drivers be a such. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20231214192131.1309912-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-12-14 21:21:31 +02:00
leds: sun50i-a100: New driver for the A100 LED controller Some Allwinner sunxi SoCs, starting with the A100, contain an LED controller designed to drive RGB LED pixels. Add a driver for it using the multicolor LED framework, and with LEDs defined in the device tree. Acked-by: Guo Ren <guoren@kernel.org> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Samuel Holland <samuel@sholland.org> Link: https://lore.kernel.org/r/20231029212738.7871-3-samuel@sholland.org Signed-off-by: Lee Jones <lee@kernel.org>
2023-10-29 16:26:56 -05:00
leds: Add driver for Sunfire UltraSPARC server LEDs. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-08-31 20:26:48 -07:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: Add driver for Sunfire UltraSPARC server LEDs. Signed-off-by: David S. Miller <davem@davemloft.net>
2008-08-31 20:26:48 -07:00
leds: add driver for the iPAQ micro This adds a driver for the iPAQ microcontroller LED. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-07-23 05:36:00 -07:00
leds: leds-ipaq-micro: Add LEDS_CLASS dependency Fix missing Kconfig LEDS_CLASS dependency. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
2015-09-07 17:06:05 +02:00
leds: add driver for the iPAQ micro This adds a driver for the iPAQ microcontroller LED. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-07-23 05:36:00 -07:00
leds: Add HP Jornada 6xx driver Add support for the LEDs on the HP Jornada 620/660/680/690 devices. Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-02-07 10:10:28 +00:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: Add HP Jornada 6xx driver Add support for the LEDs on the HP Jornada 620/660/680/690 devices. Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-02-07 10:10:28 +00:00
trivial: fix typos/grammar errors in Kconfig texts Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-01-26 11:12:25 +01:00
leds: Add HP Jornada 6xx driver Add support for the LEDs on the HP Jornada 620/660/680/690 devices. Signed-off-by: Kristoffer Ericson <kristoffer.ericson@gmail.com> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-02-07 10:10:28 +00:00
leds: Add pca9532 led driver NXP pca9532 is a LED dimmer/controller attached to i2c bus. It allows attaching upto 16 leds which can either be on, off or dimmed and/or blinked with the two PWM modulators available. This driver is a "new-style" i2c driver that adheres to the driver model and implements the led framework api. Since the leds connected to the driver are platform specific, it is only useful when platform data is passed to the driver to define what leds are connected to which pins. Signed-off-by: Riku Voipio <riku.voipio@iki.fi> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-05-31 14:43:41 +01:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
drivers/leds: remove depends on CONFIG_EXPERIMENTAL The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. CC: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-01-16 18:53:41 -08:00
leds: Add pca9532 led driver NXP pca9532 is a LED dimmer/controller attached to i2c bus. It allows attaching upto 16 leds which can either be on, off or dimmed and/or blinked with the two PWM modulators available. This driver is a "new-style" i2c driver that adheres to the driver model and implements the led framework api. Since the leds connected to the driver are platform specific, it is only useful when platform data is passed to the driver to define what leds are connected to which pins. Signed-off-by: Riku Voipio <riku.voipio@iki.fi> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-05-31 14:43:41 +01:00
trivial: fix typos/grammar errors in Kconfig texts Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-01-26 11:12:25 +01:00
leds: Add pca9532 led driver NXP pca9532 is a LED dimmer/controller attached to i2c bus. It allows attaching upto 16 leds which can either be on, off or dimmed and/or blinked with the two PWM modulators available. This driver is a "new-style" i2c driver that adheres to the driver model and implements the led framework api. Since the leds connected to the driver are platform specific, it is only useful when platform data is passed to the driver to define what leds are connected to which pins. Signed-off-by: Riku Voipio <riku.voipio@iki.fi> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-05-31 14:43:41 +01:00
drivers/leds/leds-pca9532.c: add gpio capability Allow unused leds on pca9532 to be used as gpio. The board I am working on now has no less than 6 pca9532 chips. One chips is used for only leds, one has 14 leds and 2 gpio and the rest of the chips are gpio only. There is also one board in mainline which could use this capabilty; arch/arm/mach-iop32x/n2100.c 232 { .type = PCA9532_TYPE_NONE }, /* power OFF gpio */ 233 { .type = PCA9532_TYPE_NONE }, /* reset gpio */ This patch defines a new pin type, PCA9532_TYPE_GPIO, and registers a gpiochip if any pin has this type set. The gpio will registers all chip pins but will filter on gpio_request. [randy.dunlap@oracle.com: fix build when GPIOLIB is not enabled] Signed-off-by: Joachim Eastwood <joachim.eastwood@jotron.com> Reviewed-by: Wolfram Sang <w.sang@pengutronix.de> Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: Jan Weitzel <j.weitzel@phytec.de> Cc: Juergen Kilb <j.kilb@phytec.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-24 17:13:23 -07:00
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>
2007-02-27 19:49:53 +00:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: leds-gpio: Allow compile test if !GPIOLIB The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer functionality only, can still be compiled if GPIOLIB is not enabled. Relax the dependency of LEDS_GPIO on GPIOLIB if COMPILE_TEST is enabled. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-05-07 01:08:10 -07:00
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>
2007-02-27 19:49:53 +00:00
leds: Add openfirmware platform device support Add bindings to support LEDs defined as of_platform devices in addition to the existing bindings for platform devices. New options in Kconfig allow the platform binding code and/or the of_platform code to be turned on. The of_platform code is of course only available on archs that have OF support. The existing probe and remove methods are refactored to use new functions create_gpio_led(), to create and register one led, and delete_gpio_led(), to unregister and free one led. The new probe and remove methods for the of_platform driver can then share most of the common probe and remove code with the platform driver. The suspend and resume methods aren't shared, but they are very short. The actual led driving code is the same for LEDs created by either binding. The OF bindings are based on patch by Anton Vorontsov <avorontsov@ru.mvista.com>. They have been extended to allow multiple LEDs per device. Signed-off-by: Trent Piepho <tpiepho@freescale.com> Acked-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Sean MacLennan <smaclennan@pikatech.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-10 17:26:01 +00:00
leds: LED driver for National Semiconductor LP3944 Funlight Chip LEDs driver for National Semiconductor LP3944 Funlight Chip http://www.national.com/pf/LP/LP3944.html This helper chip can drive up to 8 leds, with two programmable DIM modes; it could even be used as a gpio expander but this driver assumes it is used as a led controller. The DIM modes are used to set _blink_ patterns for leds, the pattern is specified supplying two parameters: - period: from 0s to 1.6s - duty cycle: percentage of the period the led is on, from 0 to 100 LP3944 can be found on Motorola A910 smartphone, where it drives the rgb leds, the camera flash light and the displays backlights. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-06-19 13:55:42 +02:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: LED driver for National Semiconductor LP3944 Funlight Chip LEDs driver for National Semiconductor LP3944 Funlight Chip http://www.national.com/pf/LP/LP3944.html This helper chip can drive up to 8 leds, with two programmable DIM modes; it could even be used as a gpio expander but this driver assumes it is used as a led controller. The DIM modes are used to set _blink_ patterns for leds, the pattern is specified supplying two parameters: - period: from 0s to 1.6s - duty cycle: percentage of the period the led is on, from 0 to 100 LP3944 can be found on Motorola A910 smartphone, where it drives the rgb leds, the camera flash light and the displays backlights. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-06-19 13:55:42 +02:00
leds: Fix indentation in LEDS_LP3944 Kconfig entry Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-07-03 16:18:45 +02:00
leds: LED driver for National Semiconductor LP3944 Funlight Chip LEDs driver for National Semiconductor LP3944 Funlight Chip http://www.national.com/pf/LP/LP3944.html This helper chip can drive up to 8 leds, with two programmable DIM modes; it could even be used as a gpio expander but this driver assumes it is used as a led controller. The DIM modes are used to set _blink_ patterns for leds, the pattern is specified supplying two parameters: - period: from 0s to 1.6s - duty cycle: percentage of the period the led is on, from 0 to 100 LP3944 can be found on Motorola A910 smartphone, where it drives the rgb leds, the camera flash light and the displays backlights. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-06-19 13:55:42 +02:00
leds: LED driver for TI LP3952 6-Channel Color LED The chip can drive 2 sets of RGB leds. Controller can be controlled via PWM, I2C and audio synchronisation. This driver uses I2C to communicate with the chip. Datasheet: http://www.ti.com/lit/gpn/lp3952 Signed-off-by: Tony Makkiel <tony.makkiel@daqri.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-07-11 11:48:49 +01:00
leds: lp50xx: Add the LP50XX family of the RGB LED driver Introduce the LP5036/30/24/18/12/9 RGB LED driver. The difference in these parts are the number of LED outputs where the: LP5036 can control 36 LEDs LP5030 can control 30 LEDs LP5024 can control 24 LEDs LP5018 can control 18 LEDs LP5012 can control 12 LEDs LP5009 can control 9 LEDs The device has the ability to group LED outputs into control banks so that multiple LED banks can be controlled with the same mixing and brightness. Or the LED outputs can also be controlled independently. Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-08-12 14:50:16 -05:00
leds: lp50xx: Fix chip name in KConfig The 9-channel one is called LP5009, not LP509. Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-07-30 23:59:11 +02:00
leds: lp50xx: Add the LP50XX family of the RGB LED driver Introduce the LP5036/30/24/18/12/9 RGB LED driver. The difference in these parts are the number of LED outputs where the: LP5036 can control 36 LEDs LP5030 can control 30 LEDs LP5024 can control 24 LEDs LP5018 can control 18 LEDs LP5012 can control 12 LEDs LP5009 can control 9 LEDs The device has the ability to group LED outputs into control banks so that multiple LED banks can be controlled with the same mixing and brightness. Or the LED outputs can also be controlled independently. Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-08-12 14:50:16 -05:00
leds: Make flash and multicolor dependencies unconditional Along the same lines as making devm_led_classdev_register() declared extern unconditional, do the same thing for the two sub-classes that have similar stubs. The users of these interfaces go to great lengths to allow building with both the generic leds API and the extended version, but realistically there is not much use in this, so just simplify it to always rely on it and remove the confusing fallback logic. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240109090715.982332-2-arnd@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-01-09 10:06:40 +01:00
leds: lp50xx: Add the LP50XX family of the RGB LED driver Introduce the LP5036/30/24/18/12/9 RGB LED driver. The difference in these parts are the number of LED outputs where the: LP5036 can control 36 LEDs LP5030 can control 30 LEDs LP5024 can control 24 LEDs LP5018 can control 18 LEDs LP5012 can control 12 LEDs LP5009 can control 9 LEDs The device has the ability to group LED outputs into control banks so that multiple LED banks can be controlled with the same mixing and brightness. Or the LED outputs can also be controlled independently. Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-08-12 14:50:16 -05:00
leds-lp55xx: add new common driver for lp5521/5523 This patch supports basic common driver code for LP5521, LP5523/55231 devices. ( Driver Structure Data ) lp55xx_led and lp55xx_chip In lp55xx common driver, two different data structure is used. o lp55xx_led control multi output LED channels such as led current, channel index. o lp55xx_chip general chip control such like the I2C and platform data. For example, LP5521 has maximum 3 LED channels. LP5523/55231 has 9 output channels. lp55xx_chip for LP5521 ... lp55xx_led #1 lp55xx_led #2 lp55xx_led #3 lp55xx_chip for LP5523 ... lp55xx_led #1 lp55xx_led #2 . . lp55xx_led #9 ( Platform Data ) LP5521 and LP5523/55231 have own specific platform data. However, this data can be handled with just one platform data structure. The lp55xx platform data is declared in the header. This structure is derived from leds-lp5521.h and leds-lp5523.h Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-05 18:01:23 +09:00
leds: leds-lp5569: Add support for Texas Instruments LP5569 Add support for Texas Instruments LP5569 LED driver. Texas Instruments LP5569 is 9 channels chip with programmable engines. It almost a copy of LP5523 with fundamental changes to regs order and regs content. Has difference in how the clock is handled and doesn't support detecting clock time automatically, different handling for selftest and different scheme for the status regs. LED chip supports ENGINE and MUX to group LED and run precompiled code with magic values to run patterns. This is loaded via the sysfs entry and it's passed as a string of ASCII HEX char. One some devices using this LED Controller (a NBG7815 Router) it was found loading big precompiled pattern with up to 96 bytes of code. To have support for this "extended" scenario, hardcode each engine to support 4 pages of precompiled pattern (128 bytes of code) and 1 page for each MUX. This gives plenty of space for any kind precompiled pattern keeping simple logic for page handling of each engine and mux. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-21-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 18:00:25 +02:00
leds: LP55XX_COMMON needs to depend on LEDS_CLASS With these kernel configs: CONFIG_LEDS_CLASS=m # CONFIG_LEDS_CLASS_MULTICOLOR is not set CONFIG_LEDS_LP55XX_COMMON=y CONFIG_LEDS_LP5521=m CONFIG_LEDS_LP5562=m leds-lp55xx-common.c has a build error because it is builtin and calls an interface that is built as a loadable module (due to LEDS_CLASS=m). By making LEDS_LP55XX_COMMON depend on LEDS_CLASS, this config combination cannot happen, thus preventing the build error. ld: drivers/leds/leds-lp55xx-common.o: in function `lp55xx_register_leds': leds-lp55xx-common.c:(.text+0xc5f): undefined reference to `devm_led_classdev_register_ext' Fixes: 33b3a561f417 ("leds: support new LP8501 device - another LP55xx common") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com> Cc: Milo Kim <milo.kim@ti.com> Cc: linux-leds@vger.kernel.org Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-08-17 12:11:29 -07:00
leds: Make flash and multicolor dependencies unconditional Along the same lines as making devm_led_classdev_register() declared extern unconditional, do the same thing for the two sub-classes that have similar stubs. The users of these interfaces go to great lengths to allow building with both the generic leds API and the extended version, but realistically there is not much use in this, so just simplify it to always rely on it and remove the confusing fallback logic. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240109090715.982332-2-arnd@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-01-09 10:06:40 +01:00
leds: lp55xx: Add multicolor framework support to lp55xx Add multicolor framework support for the lp55xx family. Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-16 13:20:01 -05:00
Make LEDS_LP55XX_COMMON depend on I2C to fix build errors: leds-lp55xx-common.c:(.text+0x9d): undefined reference to `i2c_smbus_read_byte_data' leds-lp55xx-common.c:(.text+0x8fc): undefined reference to `i2c_smbus_write_byte_data' These errors happened when I2C=m and LEDS_LP55XX_COMMON=y, so prevent that from being possible. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com> Cc: linux-leds@vger.kernel.org Cc: Milo Kim <milo.kim@ti.com> Cc: Mathias Nyman <mathias.nyman@nokia.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-28 12:26:13 +02:00
leds: lp55xx_common: Enable use without FW_LOADER_USER_HELPER Many distributions disable FW_LOADER_USER_HELPER, and this configuration makes lp55xx LEDs completely unusable. Enable their use by only implying the user helper, since the basic LEDs and the hardware patterns can be used with only the sysfs interface. Tested on Nokia N900 with LP5523. Additionally do not refer to the sysfs interface as legacy anymore, since it might be the only one available to users. Signed-off-by: Sicelo A. Mhlongo <absicsz@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org>
2025-10-06 12:37:53 +02:00
leds-lp55xx: add new common driver for lp5521/5523 This patch supports basic common driver code for LP5521, LP5523/55231 devices. ( Driver Structure Data ) lp55xx_led and lp55xx_chip In lp55xx common driver, two different data structure is used. o lp55xx_led control multi output LED channels such as led current, channel index. o lp55xx_chip general chip control such like the I2C and platform data. For example, LP5521 has maximum 3 LED channels. LP5523/55231 has 9 output channels. lp55xx_chip for LP5521 ... lp55xx_led #1 lp55xx_led #2 lp55xx_led #3 lp55xx_chip for LP5523 ... lp55xx_led #1 lp55xx_led #2 . . lp55xx_led #9 ( Platform Data ) LP5521 and LP5523/55231 have own specific platform data. However, this data can be handled with just one platform data structure. The lp55xx platform data is declared in the header. This structure is derived from leds-lp5521.h and leds-lp5523.h Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-05 18:01:23 +09:00
leds: leds-lp5569: Add support for Texas Instruments LP5569 Add support for Texas Instruments LP5569 LED driver. Texas Instruments LP5569 is 9 channels chip with programmable engines. It almost a copy of LP5523 with fundamental changes to regs order and regs content. Has difference in how the clock is handled and doesn't support detecting clock time automatically, different handling for selftest and different scheme for the status regs. LED chip supports ENGINE and MUX to group LED and run precompiled code with magic values to run patterns. This is loaded via the sysfs entry and it's passed as a string of ASCII HEX char. One some devices using this LED Controller (a NBG7815 Router) it was found loading big precompiled pattern with up to 96 bytes of code. To have support for this "extended" scenario, hardcode each engine to support 4 pages of precompiled pattern (128 bytes of code) and 1 page for each MUX. This gives plenty of space for any kind precompiled pattern keeping simple logic for page handling of each engine and mux. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-21-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 18:00:25 +02:00
leds-lp55xx: add new common driver for lp5521/5523 This patch supports basic common driver code for LP5521, LP5523/55231 devices. ( Driver Structure Data ) lp55xx_led and lp55xx_chip In lp55xx common driver, two different data structure is used. o lp55xx_led control multi output LED channels such as led current, channel index. o lp55xx_chip general chip control such like the I2C and platform data. For example, LP5521 has maximum 3 LED channels. LP5523/55231 has 9 output channels. lp55xx_chip for LP5521 ... lp55xx_led #1 lp55xx_led #2 lp55xx_led #3 lp55xx_chip for LP5523 ... lp55xx_led #1 lp55xx_led #2 . . lp55xx_led #9 ( Platform Data ) LP5521 and LP5523/55231 have own specific platform data. However, this data can be handled with just one platform data structure. The lp55xx platform data is declared in the header. This structure is derived from leds-lp5521.h and leds-lp5523.h Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-05 18:01:23 +09:00
leds: update LP552x support Kconfig and Makefile Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-11 14:05:23 -08:00
leds: lp55xx: Add multicolor framework support to lp55xx Add multicolor framework support for the lp55xx family. Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-16 13:20:01 -05:00
leds: update LP552x support Kconfig and Makefile Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-11 14:05:23 -08:00
leds-lp5523: support new LP55231 device New TI LP55231 device has same I2C register layout as LP5523. Therefore, all of LED operations can be shared with the LP5523 driver. To support new LP55231 device explicitly, the device description is added in the configuration file. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-04 15:06:11 +08:00
leds: update LP552x support Kconfig and Makefile Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-11 14:05:23 -08:00
leds: lp55xx: Add multicolor framework support to lp55xx Add multicolor framework support for the lp55xx family. Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-16 13:20:01 -05:00
leds: update LP552x support Kconfig and Makefile Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-11 14:05:23 -08:00
leds-lp5523: support new LP55231 device New TI LP55231 device has same I2C register layout as LP5523. Therefore, all of LED operations can be shared with the LP5523 driver. To support new LP55231 device explicitly, the device description is added in the configuration file. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-04 15:06:11 +08:00
leds: update LP552x support Kconfig and Makefile Provide configuration and compilation support for LP5521 and LP5523 Signed-off-by: Samu Onkalo <samu.p.onkalo@nokia.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Jean Delvare <khali@linux-fr.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-11-11 14:05:23 -08:00
leds: add new LP5562 LED driver LP5562 can drive up to 4 channels, RGB and White. LEDs can be controlled directly via the led class control interface. LP55xx common driver LP5562 is one of LP55xx family device, so LP55xx common code are used. On the other hand, chip specific configuration is defined in the structure 'lp55xx_device_config' LED pattern data LP5562 has also internal program memory which is used for running various LED patterns. LP5562 driver supports the firmware interface and the predefined pattern data as well. LP5562 device attributes: 'led_pattern' and 'engine_mux' A 'led_pattern' is an index code which runs the predefined pattern data. And 'engine_mux' is updated with the firmware interface is activated. Detailed description has been updated in the documentation files, 'leds-lp55xx.txt' and 'leds-lp5562.txt'. Changes on the header file LP5562 configurable definitions are added. Pattern RGB data is fixed as constant value. (No side effect on other devices, LP5521 or LP5523.) (cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan Carpenter <dan.carpenter@oracle.com>) Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-18 21:10:14 -08:00
leds: lp55xx: Add multicolor framework support to lp55xx Add multicolor framework support for the lp55xx family. Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-16 13:20:01 -05:00
leds: add new LP5562 LED driver LP5562 can drive up to 4 channels, RGB and White. LEDs can be controlled directly via the led class control interface. LP55xx common driver LP5562 is one of LP55xx family device, so LP55xx common code are used. On the other hand, chip specific configuration is defined in the structure 'lp55xx_device_config' LED pattern data LP5562 has also internal program memory which is used for running various LED patterns. LP5562 driver supports the firmware interface and the predefined pattern data as well. LP5562 device attributes: 'led_pattern' and 'engine_mux' A 'led_pattern' is an index code which runs the predefined pattern data. And 'engine_mux' is updated with the firmware interface is activated. Detailed description has been updated in the documentation files, 'leds-lp55xx.txt' and 'leds-lp5562.txt'. Changes on the header file LP5562 configurable definitions are added. Pattern RGB data is fixed as constant value. (No side effect on other devices, LP5521 or LP5523.) (cooloney@gmail.com: remove redundant mutex_unlock(). Reported by Dan Carpenter <dan.carpenter@oracle.com>) Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-18 21:10:14 -08:00
leds: leds-lp5569: Add support for Texas Instruments LP5569 Add support for Texas Instruments LP5569 LED driver. Texas Instruments LP5569 is 9 channels chip with programmable engines. It almost a copy of LP5523 with fundamental changes to regs order and regs content. Has difference in how the clock is handled and doesn't support detecting clock time automatically, different handling for selftest and different scheme for the status regs. LED chip supports ENGINE and MUX to group LED and run precompiled code with magic values to run patterns. This is loaded via the sysfs entry and it's passed as a string of ASCII HEX char. One some devices using this LED Controller (a NBG7815 Router) it was found loading big precompiled pattern with up to 96 bytes of code. To have support for this "extended" scenario, hardcode each engine to support 4 pages of precompiled pattern (128 bytes of code) and 1 page for each MUX. This gives plenty of space for any kind precompiled pattern keeping simple logic for page handling of each engine and mux. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-21-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26 18:00:25 +02:00
leds: support new LP8501 device - another LP55xx common LP8501 can drive up to 9 channels like LP5523. LEDs can be controlled directly via the I2C and programmable engines are supported. LP55xx common driver LP8501 is one of LP55xx family device, so LP55xx common code are used. Chip specific data is defined in the structure, 'lp55xx_device_config'. Differences between LP8501 and LP5523 Different register layout for LED output control and others. LP8501 specific feature for separate output power selection. LP8501 doesn't support external clock detection. Different programming engine data. LP8501 specific feature - output power selection Output channels are selected by power selection - Vout or Vdd. Separate power for VDD1-6 and VDD7-9 are available. It is configurable in the platform data. To support this feature, LP55xx DT structure and header are changed. Device tree binding is updated as well. LED pattern data Example pattern data is updated in the driver documentation. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-07-09 02:11:37 -07:00
leds: lp55xx: Add multicolor framework support to lp55xx Add multicolor framework support for the lp55xx family. Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-07-16 13:20:01 -05:00
leds: support new LP8501 device - another LP55xx common LP8501 can drive up to 9 channels like LP5523. LEDs can be controlled directly via the I2C and programmable engines are supported. LP55xx common driver LP8501 is one of LP55xx family device, so LP55xx common code are used. Chip specific data is defined in the structure, 'lp55xx_device_config'. Differences between LP8501 and LP5523 Different register layout for LED output control and others. LP8501 specific feature for separate output power selection. LP8501 doesn't support external clock detection. Different programming engine data. LP8501 specific feature - output power selection Output channels are selected by power selection - Vout or Vdd. Separate power for VDD1-6 and VDD7-9 are available. It is configurable in the platform data. To support this feature, LP55xx DT structure and header are changed. Device tree binding is updated as well. LED pattern data Example pattern data is updated in the driver documentation. Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-07-09 02:11:37 -07:00
leds: add new lp8788 led driver TI LP8788 PMU has the current sink as the keyboard led driver. The brightness is controlled by the i2c commands. Configurable parameters can be defined in the platform side. Patch v2. (a) use workqueue on changing the brightness (b) use mutex_lock/unlock when the brightness is set and the led block of lp8788 device is enabled (c) remove err_dev on _probe() : just return as returned value if any errors (d) replace module_init/exit() with module_platform_driver() (e) add led configuration structure and loading them by default if platform data is null Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-20 16:43:59 +08:00
leds: lp8860: Introduce TI lp8860 4 channel LED driver Introduce the Texas Instruments lp8860 4 channel LED driver. This driver configures the device in display cluster mode as this seems to be the most used configuration at the time of the driver configuration. For more product information please see the link below: http://www.ti.com/product/lp8860-q1 Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-11-19 04:48:35 -08:00
leds: lp8860: Various fixes to align with LED framework Update the driver to conform with the LED framework: - use devm_led_classdev_register - destroy mutex on exit - remove dependency on CONFIG_OF in the driver and move to the Kconfig - update the MODULE_LICENSE to GPL v2 - remove setting of MAX brightness as the LED framework does this. Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-12-18 14:23:07 -06:00
leds: lp8860: Fix module dependency The driver should select REGMAP_I2C rather than depend on it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-11-21 05:48:26 -08:00
leds: lp8860: Introduce TI lp8860 4 channel LED driver Introduce the Texas Instruments lp8860 4 channel LED driver. This driver configures the device in display cluster mode as this seems to be the most used configuration at the time of the driver configuration. For more product information please see the link below: http://www.ti.com/product/lp8860-q1 Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-11-19 04:48:35 -08:00
leds: lp8864: Add support for Texas Instruments LP8864, LP8864S, LP8866 LED-backlights Add driver for TI LP8864, LP8864S, LP8866 4/6 channel LED-backlight drivers with I2C interface. Link: https://www.ti.com/lit/gpn/lp8864-q1 Link: https://www.ti.com/lit/gpn/lp8864s-q1 Link: https://www.ti.com/lit/gpn/lp8866-q1 Link: https://www.ti.com/lit/gpn/lp8866s-q1 Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://lore.kernel.org/r/20241218210829.73191-3-alexander.sverdlin@siemens.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-12-18 22:08:27 +01:00
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 11:46:41 +01:00
leds: remove experimental flag from leds-clevo-mail The leds-clevo-mail driver is in the mainline kernel since 2.6.25 and works without severe problems. Make this driver available for a larger audience. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-04-03 07:42:47 +02:00
leds: clevo-mail: Mark as broken pending interface fix Setting blink rate using brightness is unusual and should be fixed. Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-07-17 12:59:48 +02:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 11:46:41 +01:00
leds: clevo-mail: Mark as broken pending interface fix Setting blink rate using brightness is unusual and should be fixed. Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-07-17 12:59:48 +02:00
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 11:46:41 +01:00
leds: hw acceleration for Clevo mail LED driver Add support for hardware accelerated LED blinking for the mail LED commonly found on Clevo notebooks. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 15:09:05 +01:00
leds: clevo-mail: fix Kconfig "its" grammar Use the possessive "its" instead of the contraction "it's" where appropriate. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Lee Jones <lee.jones@linaro.org> Cc: linux-leds@vger.kernel.org Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-07-14 18:59:48 -07:00
leds: hw acceleration for Clevo mail LED driver Add support for hardware accelerated LED blinking for the mail LED commonly found on Clevo notebooks. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 15:09:05 +01:00
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 11:46:41 +01:00
drivers: leds: Kconfig: pedantic cleanups Clean up spaces before tabs. Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-03-06 19:15:46 +01:00
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 11:46:41 +01:00
leds: Add mail LED support for "Clevo D400P" The leds-clevo-mail module also works with model "Clevo D400P", add this model to the white list. Signed-off-by: Mrton Nmeth <nm127@freemail.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-03-09 20:47:59 +00:00
trivial: fix typos/grammar errors in Kconfig texts Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-01-26 11:12:25 +01:00
leds: Add mail LED support for "Clevo D400P" The leds-clevo-mail module also works with model "Clevo D400P", add this model to the white list. Signed-off-by: Mrton Nmeth <nm127@freemail.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2008-03-09 20:47:59 +00:00
leds: Add clevo notebook LED driver The driver supports the mail LED commonly found on different Clevo notebooks. The driver access the LED through the i8042 hardware which is handled by the input subsystem. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-10-31 11:46:41 +01:00
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>
2008-07-16 22:49:55 +01:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
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>
2008-07-16 22:49:55 +01:00
leds: pca955x: add GPIO support The PCA955x family of chips are I2C LED blinkers whose pins not used to control LEDs can be used as general purpose I/Os (GPIOs). The following adds such a support by defining different operation modes for the pins (See bindings documentation for more details). The pca955x driver is then extended with a gpio_chip when some of pins are operating as GPIOs. The default operating mode is to behave as a LED. The GPIO support is conditioned by CONFIG_LEDS_PCA955X_GPIO. Signed-off-by: Cédric Le Goater <clg@kaod.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2017-08-08 15:42:39 +02:00
leds-pca9633: Rename to leds-pca963x The driver now supports the chips pca9633 and pca9634, therefore we rename the files to more generic and meaningul names Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-14 14:23:50 -07:00
leds-pca9633: Add support for PCA9634 Add support for PCA9634 chip, which belongs to the same family as the 9633 but with support for 8 outputs instead of 4. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-14 14:23:47 -07:00
drivers/leds: add driver for PCA9633 I2C chip Driver for the PCA9633 I2C chip supporting four LEDs and 255 brightness levels. [akpm@linux-foundation.org: fix kcalloc() call] [axel.lin@gmail.com: fix kcalloc parameters swapped] Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com> Signed-off-by: Axel Lin <axel.lin@gmail.com> 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>
2012-03-23 15:02:10 -07:00
leds: pca963x: Add multicolor LED class support Allow grouping of individual PCA963x PWM channels into a single multicolor LED device by adding support for the LED multicolor class. A child node with sub-children is treated as a multicolor group, others are treated as single leds, keeping full backwards compatibility. Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260727-monza-leds-v8-3-6e7e93d44dba@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-27 16:54:35 +02:00
drivers/leds: add driver for PCA9633 I2C chip Driver for the PCA9633 I2C chip supporting four LEDs and 255 brightness levels. [akpm@linux-foundation.org: fix kcalloc() call] [axel.lin@gmail.com: fix kcalloc parameters swapped] Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com> Signed-off-by: Axel Lin <axel.lin@gmail.com> 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>
2012-03-23 15:02:10 -07:00
leds-pca9633: Add support for PCA9634 Add support for PCA9634 chip, which belongs to the same family as the 9633 but with support for 8 outputs instead of 4. Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-08-14 14:23:47 -07:00
drivers/leds: add driver for PCA9633 I2C chip Driver for the PCA9633 I2C chip supporting four LEDs and 255 brightness levels. [akpm@linux-foundation.org: fix kcalloc() call] [axel.lin@gmail.com: fix kcalloc parameters swapped] Signed-off-by: Peter Meerwald <p.meerwald@bct-electronic.com> Signed-off-by: Axel Lin <axel.lin@gmail.com> 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>
2012-03-23 15:02:10 -07:00
leds: pca995x: Add support for PCA995X chips The PCA995x chips are I2C controlled LED drivers. Each chip has up to 16 outputs, each one with an individual 8-bit resolution PWM for brightness control. Signed-off-by: Isai Gaspar <isaiezequiel.gaspar@nxp.com> Signed-off-by: Marek Vasut <marex@denx.de> # Basically rewrite the driver Link: https://lore.kernel.org/r/20230713163516.21644-2-marex@denx.de Signed-off-by: Lee Jones <lee@kernel.org>
2023-07-13 18:35:16 +02:00
leds: Add driver for LEDs from qnap-mcu devices This adds a driver that connects to the qnap-mcu mfd driver and provides access to the LEDs on it. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20241107114712.538976-6-heiko@sntech.de Signed-off-by: Lee Jones <lee@kernel.org>
2024-11-07 12:47:08 +01:00
leds: Add WM831x status LED driver The WM831x devices feature two software controlled status LEDs with hardware assisted blinking. The device can also autonomously control the LEDs based on a selection of sources. This can be configured at boot time using either platform data or the chip OTP. A sysfs file in the style of that for triggers allowing the control source to be configured at run time. Triggers can't be used here since they can't depend on the implementation details of a specific LED type. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-09-05 14:09:21 +01:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: Add WM831x status LED driver The WM831x devices feature two software controlled status LEDs with hardware assisted blinking. The device can also autonomously control the LEDs based on a selection of sources. This can be configured at boot time using either platform data or the chip OTP. A sysfs file in the style of that for triggers allowing the control source to be configured at run time. Triggers can't be used here since they can't depend on the implementation details of a specific LED type. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-09-05 14:09:21 +01:00
drivers: leds: Kconfig: pedantic cleanups Clean up spaces before tabs. Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-03-06 19:15:46 +01:00
leds: Add WM831x status LED driver The WM831x devices feature two software controlled status LEDs with hardware assisted blinking. The device can also autonomously control the LEDs based on a selection of sources. This can be configured at boot time using either platform data or the chip OTP. A sysfs file in the style of that for triggers allowing the control source to be configured at run time. Triggers can't be used here since they can't depend on the implementation details of a specific LED type. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-09-05 14:09:21 +01:00
leds: Add WM8350 LED driver The voltage and current regulators on the WM8350 AudioPlus PMIC can be used in concert to provide a power efficient LED driver. This driver implements support for this within the standard LED class. Platform initialisation code should configure the LED hardware in the init callback provided by the WM8350 core driver. The callback should use wm8350_isink_set_flash(), wm8350_dcdc25_set_mode() and wm8350_dcdc_set_slot() to configure the operating parameters of the regulators for their hardware and then then use wm8350_register_led() to instantiate the LED driver. This driver was originally written by Liam Girdwood, though it has been extensively modified since then. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2008-12-04 16:52:33 +00:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: Add WM8350 LED driver The voltage and current regulators on the WM8350 AudioPlus PMIC can be used in concert to provide a power efficient LED driver. This driver implements support for this within the standard LED class. Platform initialisation code should configure the LED hardware in the init callback provided by the WM8350 core driver. The callback should use wm8350_isink_set_flash(), wm8350_dcdc25_set_mode() and wm8350_dcdc_set_slot() to configure the operating parameters of the regulators for their hardware and then then use wm8350_register_led() to instantiate the LED driver. This driver was originally written by Liam Girdwood, though it has been extensively modified since then. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2008-12-04 16:52:33 +00:00
leds: da903x: Add support for LEDs found on DA9030/DA9034 Signed-off-by: Mike Rapoport <mike@compulab.co.il> Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2008-10-13 09:06:10 +01:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: da903x: Add support for LEDs found on DA9030/DA9034 Signed-off-by: Mike Rapoport <mike@compulab.co.il> Signed-off-by: Eric Miao <eric.miao@marvell.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2008-10-13 09:06:10 +01:00
leds: driver for DA9052/53 PMIC v2 LED Driver for Dialog Semiconductor DA9052/53 PMICs. [akpm@linux-foundation.org: make led_reg static] Signed-off-by: David Dajun Chen <dchen@diasemi.com> Signed-off-by: Ashish Jangam <ashish.jangam@kpitcummins.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> 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>
2012-05-29 15:07:26 -07:00
leds: Add dac124s085 driver Add an LED driver using the DAC124S085 DAC from NatSemi [randy.dunlap@oracle.com: use header files for interfaces] Signed-off-by: Guennadi Liakhovetski <lg@denx.de> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-10 18:58:28 +00:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: Add dac124s085 driver Add an LED driver using the DAC124S085 DAC from NatSemi [randy.dunlap@oracle.com: use header files for interfaces] Signed-off-by: Guennadi Liakhovetski <lg@denx.de> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-01-10 18:58:28 +00:00
leds: simple driver for pwm driven LEDs Add a simple driver for pwm driver LEDs. pwm_id and period can be defined in board file. It is developed for pxa, however it is probably generic enough to be used on other platforms with pwm. Signed-off-by: Luotao Fu <l.fu@pengutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-02-11 13:24:40 -08:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: leds-pwm: make it depend on PWM and not HAVE_PWM The correct dependency for the leds-pwm is PWM and not HAVE_PWM since PWM drivers now have their own subsystem. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-01-23 00:35:04 -08:00
leds: simple driver for pwm driven LEDs Add a simple driver for pwm driver LEDs. pwm_id and period can be defined in board file. It is developed for pxa, however it is probably generic enough to be used on other platforms with pwm. Signed-off-by: Luotao Fu <l.fu@pengutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-02-11 13:24:40 -08:00
leds: Add LED class driver for regulator driven LEDs. This driver provides an interface for controlling LEDs (or vibrators) connected to PMICs for which there is a regulator framework driver. This driver can be used, for instance, to control vibrator on all Motorola EZX phones using the pcap-regulator driver services. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-12-07 15:08:13 +01:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: Add LED class driver for regulator driven LEDs. This driver provides an interface for controlling LEDs (or vibrators) connected to PMICs for which there is a regulator framework driver. This driver can be used, for instance, to control vibrator on all Motorola EZX phones using the pcap-regulator driver services. Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-12-07 15:08:13 +01:00
leds: bd2606mvv: Driver for the Rohm 6 Channel i2c LED driver The device provides 6 channels which can be individually turned off and on but groups of two channels share a common brightness register. Limitation: The GPIO to enable the device is not used yet. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419111806.1100437-3-andreas@kemnade.info
2023-04-19 13:18:06 +02:00
leds: Kconfig: Fix spelling mistake "limitiation" -> "limitation" There is a spelling mistake in the LEDS_BD2606MVV config. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20250724112030.142121-1-colin.i.king@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24 12:20:30 +01:00
leds: bd2606mvv: Driver for the Rohm 6 Channel i2c LED driver The device provides 6 channels which can be individually turned off and on but groups of two channels share a common brightness register. Limitation: The GPIO to enable the device is not used yet. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230419111806.1100437-3-andreas@kemnade.info
2023-04-19 13:18:06 +02:00
leds: add BD2802GU LED driver ROHM BD2802GU is a RGB LED controller attached to i2c bus and specifically engineered for decoration purposes. This RGB controller incorporates lighting patterns and illuminates. This driver is designed to minimize power consumption, so when there is no emitting LED, it enters to reset state. And because the BD2802GU has lots of features that can't be covered by the current LED framework, it provides Advanced Configuration Function(ADF) mode, so that user applications can set registers of BD2802GU directly. Here are basic usage examples : ; to turn on LED (not blink) $ echo 1 > /sys/class/leds/led1_R/brightness ; to blink LED $ echo timer > /sys/class/leds/led1_R/trigger $ echo 1 > /sys/class/leds/led1_R/delay_on $ echo 1 > /sys/class/leds/led1_R/delay_off ; to turn off LED $ echo 0 > /sys/class/leds/led1_R/brightness [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Kim Kyuwon <chammoru@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-03-04 11:59:29 -08:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: add BD2802GU LED driver ROHM BD2802GU is a RGB LED controller attached to i2c bus and specifically engineered for decoration purposes. This RGB controller incorporates lighting patterns and illuminates. This driver is designed to minimize power consumption, so when there is no emitting LED, it enters to reset state. And because the BD2802GU has lots of features that can't be covered by the current LED framework, it provides Advanced Configuration Function(ADF) mode, so that user applications can set registers of BD2802GU directly. Here are basic usage examples : ; to turn on LED (not blink) $ echo 1 > /sys/class/leds/led1_R/brightness ; to blink LED $ echo timer > /sys/class/leds/led1_R/trigger $ echo 1 > /sys/class/leds/led1_R/delay_on $ echo 1 > /sys/class/leds/led1_R/delay_off ; to turn off LED $ echo 0 > /sys/class/leds/led1_R/brightness [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Kim Kyuwon <chammoru@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-03-04 11:59:29 -08:00
leds: LED driver for Intel NAS SS4200 series (v5) This code is based on a driver that came in the "Open-source and GPL components" download here: http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Server+Products&ProductLine=Intel%C2%AE+Storage+Systems&ProductProduct=Intel%C2%AE+Entry+Storage+System+SS4200-E&OSVersion=OS+Independent It was in a file called nasgpio.c inside of a second zip file called SS4200-E_Linux_SIO_Driver-v1.4.zip and is based on this updated to use the LED subsystem with the ioctl and hardware monitor support removed. I don't have any need for brightness control, and its code is *completely* separate from the on/off controls implemented here. If anyone else wants it, I'd be happy to look into adding it, but I don't care enough for now. Except for the probe routines, I rewrote most of it. I also Note that I don't have any hardware documentation except for the original driver. Thanks go to Arjan for his help in getting the original source for this released and for chasing down some licensing issues. Signed-off-by: Dave Hansen <dave@sr71.net> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-01 15:43:32 -07:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: ss4200: Add depend on x86 arch There is only one x86 hardware where the driver leds-ss4200 applies to. Add kconfig dependency to x86 architecture, fix help text whitespace. Signed-off-by: Martin Dummer <martin.dummer@gmx.net> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-04-17 13:27:52 +02:00
leds: LED driver for Intel NAS SS4200 series (v5) This code is based on a driver that came in the "Open-source and GPL components" download here: http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Server+Products&ProductLine=Intel%C2%AE+Storage+Systems&ProductProduct=Intel%C2%AE+Entry+Storage+System+SS4200-E&OSVersion=OS+Independent It was in a file called nasgpio.c inside of a second zip file called SS4200-E_Linux_SIO_Driver-v1.4.zip and is based on this updated to use the LED subsystem with the ioctl and hardware monitor support removed. I don't have any need for brightness control, and its code is *completely* separate from the on/off controls implemented here. If anyone else wants it, I'd be happy to look into adding it, but I don't care enough for now. Except for the probe routines, I rewrote most of it. I also Note that I don't have any hardware documentation except for the original driver. Thanks go to Arjan for his help in getting the original source for this released and for chasing down some licensing issues. Signed-off-by: Dave Hansen <dave@sr71.net> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-01 15:43:32 -07:00
leds: ss4200: Add depend on x86 arch There is only one x86 hardware where the driver leds-ss4200 applies to. Add kconfig dependency to x86 architecture, fix help text whitespace. Signed-off-by: Martin Dummer <martin.dummer@gmx.net> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-04-17 13:27:52 +02:00
leds: LED driver for Intel NAS SS4200 series (v5) This code is based on a driver that came in the "Open-source and GPL components" download here: http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Server+Products&ProductLine=Intel%C2%AE+Storage+Systems&ProductProduct=Intel%C2%AE+Entry+Storage+System+SS4200-E&OSVersion=OS+Independent It was in a file called nasgpio.c inside of a second zip file called SS4200-E_Linux_SIO_Driver-v1.4.zip and is based on this updated to use the LED subsystem with the ioctl and hardware monitor support removed. I don't have any need for brightness control, and its code is *completely* separate from the on/off controls implemented here. If anyone else wants it, I'd be happy to look into adding it, but I don't care enough for now. Except for the probe routines, I rewrote most of it. I also Note that I don't have any hardware documentation except for the original driver. Thanks go to Arjan for his help in getting the original source for this released and for chasing down some licensing issues. Signed-off-by: Dave Hansen <dave@sr71.net> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-01 15:43:32 -07:00
leds: Add driver for LT3593 controlled LEDs The LT3593 is a step-up DC/DC converter designed to drive up to ten white LEDs in series. The current flow can be set with a control pin. This driver controls any number of such devices connected on generic GPIOs and exports the function as as platform_driver. The gpio_led platform data struct definition is reused for this purpose. Successfully tested on a PXA embedded board. Signed-off-by: Daniel Mack <daniel@caiaq.de> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-15 02:59:35 +02:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Allow compile test of GPIO consumers if !GPIOLIB The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer functionality only, can still be compiled if GPIOLIB is not enabled. Relax the dependency on GPIOLIB if COMPILE_TEST is enabled, where appropriate. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: linux-leds@vger.kernel.org Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2015-05-05 18:32:25 +02:00
leds: Add driver for LT3593 controlled LEDs The LT3593 is a step-up DC/DC converter designed to drive up to ten white LEDs in series. The current flow can be set with a control pin. This driver controls any number of such devices connected on generic GPIOs and exports the function as as platform_driver. The gpio_led platform data struct definition is reused for this purpose. Successfully tested on a PXA embedded board. Signed-off-by: Daniel Mack <daniel@caiaq.de> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-15 02:59:35 +02:00
leds: Add driver for ADP5520/ADP5501 MFD PMICs Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-08 04:00:19 -04:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: Add driver for ADP5520/ADP5501 MFD PMICs Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2009-10-08 04:00:19 -04:00
leds: max5970: Add support for max5970 The MAX5970 is hot swap controller and has 4 indication LED. Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com> Link: https://lore.kernel.org/r/20231123132803.1107174-1-naresh.solanki@9elements.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-23 13:28:02 +00:00
leds: Add mc13783 LED support This add basic led support for Freescale MC13783 PMIC. Signed-off-by: Philippe Rétornaz <philippe.retornaz@epfl.ch> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-05-19 09:24:31 +02:00
leds: leds-mc13783: Add MC13892 LED support Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Tested-by: Philippe Retornaz <philippe.retornaz@epfl.ch> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-10 09:59:31 -07:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: leds-mc13783: Add MC13892 LED support Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Tested-by: Philippe Retornaz <philippe.retornaz@epfl.ch> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-06-10 09:59:31 -07:00
leds: Add mc13783 LED support This add basic led support for Freescale MC13783 PMIC. Signed-off-by: Philippe Rétornaz <philippe.retornaz@epfl.ch> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-05-19 09:24:31 +02:00
leds: fix Kconfig text for MLXCPLD, SYSCON, MC13783, NETXBIG It fixes grammatical errors in Kconfig file for LEDS_SYSCON, LEDS_MLXCPLD, LEDS_MC13783, LEDS_NETXBIG. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-02-15 18:11:37 +00:00
leds: leds-mc13783: Add MC34708 LED support This patch adds support for two LEDs on MC34708 PMIC. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2014-01-31 22:36:28 -08:00
leds: Add mc13783 LED support This add basic led support for Freescale MC13783 PMIC. Signed-off-by: Philippe Rétornaz <philippe.retornaz@epfl.ch> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-05-19 09:24:31 +02:00
leds: add LED driver for Network Space v2 LEDs This patch add a LED class driver for the dual-GPIO LEDs found on the Network Space v2 board (and parents). This include Internet Space v2, Network Space (Max) v2 and d2 Network v2 boards. This dual-GPIO LED is wired to a CPLD and can blink in relation with the SATA activity. The driver expose this capability through a "sata" sysfs attribute. Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-07-06 16:08:46 +02:00
leds: fix up dependencies It's not useful to build LED triggers when there's no LEDs that can be triggered by them. Therefore, fix up the dependencies so that this cannot happen, and fix a few users that select triggers to depend on LEDS_CLASS as well (there is also one user that also selects LEDS_CLASS, which is OK). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Tested-by: Ingo Molnar <mingo@elte.hu> Cc: Arnd Hannemann <arnd@arndnet.de> Cc: Michal Hocko <mhocko@suse.cz> Cc: Richard Purdie <rpurdie@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-12-02 14:31:14 -08:00
leds: various: compile if COMPILE_TEST=y These drivers can be compiled without modification when COMPILE_TEST=y: cobalt-qube, cobalt-raq, netxbig, ns2 and s3c24xx Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-09-18 00:32:49 +02:00
leds: Do not enable by default during compile testing Enabling the compile test should not cause automatic enabling of all drivers, but only allow to choose to compile them. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250417074656.81626-1-krzysztof.kozlowski@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-04-17 09:46:56 +02:00
leds: add LED driver for Network Space v2 LEDs This patch add a LED class driver for the dual-GPIO LEDs found on the Network Space v2 board (and parents). This include Internet Space v2, Network Space (Max) v2 and d2 Network v2 boards. This dual-GPIO LED is wired to a CPLD and can blink in relation with the SATA activity. The driver expose this capability through a "sata" sysfs attribute. Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-07-06 16:08:46 +02:00
leds: leds-ns2: depends on MACH_ARMADA_370 The leds-ns2 driver is also used by the n090401 board (Seagate NAS 4-Bay), which is based on the Marvell Armada-370 SoC. Then this patch allows to select the leds-ns2 driver if MACH_ARMADA_370 is enabled. Additionally, this also updates the Kconfig help message. Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2015-07-02 19:56:43 +02:00
leds: add LED driver for Network Space v2 LEDs This patch add a LED class driver for the dual-GPIO LEDs found on the Network Space v2 board (and parents). This include Internet Space v2, Network Space (Max) v2 and d2 Network v2 boards. This dual-GPIO LED is wired to a CPLD and can blink in relation with the SATA activity. The driver expose this capability through a "sata" sysfs attribute. Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-07-06 16:08:46 +02:00
leds: add LED driver for Big Network series LEDs This patch add a LED class driver for LEDs found on the LaCie 2Big and 5Big Network v2 boards. The LEDs are wired to a CPLD and are controlled through a GPIO extension bus. Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-10-07 16:38:49 +02:00
drivers/leds/leds-netxbig: make LEDS_NETXBIG depend on LEDS_CLASS We call led_classdev_register/led_classdev_unregister in create_netxbig_led/delete_netxbig_led, thus make LEDS_NETXBIG depend on LEDS_CLASS. This patch fixes below build error if LEDS_CLASS is not configured. LD .tmp_vmlinux1 drivers/built-in.o: In function `create_netxbig_led': drivers/leds/leds-netxbig.c:350: undefined reference to `led_classdev_register' drivers/leds/leds-netxbig.c:361: undefined reference to `led_classdev_unregister' drivers/built-in.o: In function `delete_netxbig_led': drivers/leds/leds-netxbig.c:313: undefined reference to `led_classdev_unregister' Signed-off-by: Axel Lin <axel.lin@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> Acked-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-07-25 17:13:16 -07:00
leds: various: compile if COMPILE_TEST=y These drivers can be compiled without modification when COMPILE_TEST=y: cobalt-qube, cobalt-raq, netxbig, ns2 and s3c24xx Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-09-18 00:32:49 +02:00
leds: Do not enable by default during compile testing Enabling the compile test should not cause automatic enabling of all drivers, but only allow to choose to compile them. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250417074656.81626-1-krzysztof.kozlowski@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-04-17 09:46:56 +02:00
leds: add LED driver for Big Network series LEDs This patch add a LED class driver for LEDs found on the LaCie 2Big and 5Big Network v2 boards. The LEDs are wired to a CPLD and are controlled through a GPIO extension bus. Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-10-07 16:38:49 +02:00
leds: fix Kconfig text for MLXCPLD, SYSCON, MC13783, NETXBIG It fixes grammatical errors in Kconfig file for LEDS_SYSCON, LEDS_MLXCPLD, LEDS_MC13783, LEDS_NETXBIG. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-02-15 18:11:37 +00:00
leds: add LED driver for Big Network series LEDs This patch add a LED class driver for LEDs found on the LaCie 2Big and 5Big Network v2 boards. The LEDs are wired to a CPLD and are controlled through a GPIO extension bus. Signed-off-by: Simon Guinot <sguinot@lacie.com> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
2010-10-07 16:38:49 +02:00
leds: add driver for TCA6507 LED controller TI's TCA6507 is the LED driver in the GTA04 Openmoko motherboard. The driver provides full support for brightness levels and hardware blinking. This driver can drive each of 7 outputs as an LED or a GPIO output, and provides hardware-assist blinking. [akpm@linux-foundation.org: fix __mod_i2c_device_table alias] [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: NeilBrown <neilb@suse.de> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Randy Dunlap <rdunlap@xenotime.net> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-01-10 15:09:40 -08:00
leds: tlc591xx: Driver for the TI 8/16 Channel i2c LED driver The TLC59116 is an I2C bus controlled 16-channel LED driver. The TLC59108 is an I2C bus controlled 8-channel LED driver, which is very similar to the TLC59116. Each LED output has its own 8-bit fixed-frequency PWM controller to control the brightness of the LED. The LEDs can also be fixed off and on, making them suitable for use as GPOs. This is based on a driver from Belkin, but has been extensively rewritten and extended to support both 08 and 16 versions. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Imre Kaloz <kaloz@openwrt.org> Cc: Matthew.Fatheree@belkin.com Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2015-03-17 15:08:27 -07:00
leds: max77650: Add LEDs support This adds basic support for LEDs for the max77650 PMIC. The device has three current sinks for driving LEDs. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2019-04-23 11:04:49 +02:00
leds: max77705: Add LEDs support This adds basic support for LEDs for the max77705 PMIC. Signed-off-by: Dzmitry Sankouski <dsankouski@gmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250123-starqltechn_integration_upstream-v17-7-8b06685b6612@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-01-23 18:04:32 +03:00
leds: Add suuport for MAX8997-LED driver This patch enables LED controller in MAX8997 PMIC. Signed-off-by: Donggeun Kim <dg77.kim@samsung.com> Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2011-12-14 18:23:56 +09:00
leds: Add new LED driver for lm355x chips This driver is a general version for LM355x,lm3554 and lm3556,led chips of TI. LM3554 : The LM3554 is a 2 MHz fixed-frequency synchronous boost converter with 1.2A dual high side led drivers. Datasheet: www.ti.com/lit/ds/symlink/lm3554.pdf LM3556 : The LM3556 is a 4 MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. Datasheet: www.national.com/ds/LM/LM3556.pdf (bryan.wu@canonical.com: use flush_work() to replace flush_work_sync() which is deprecated) Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-09-05 15:05:58 +08:00
leds: Clarify supported chips by LM355x driver Clarify which controllers are supported by which driver. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-02-01 21:26:34 +01:00
leds: Add LED driver for lm3556 chip LM3556 : The LM3556 is a 4 MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. Datasheet: www.national.com/ds/LM/LM3556.pdf Tested on OMAP4430 (bryan.wu@canonical.com: use module_i2c_driver() rather than lm3556_init/lm3556_exit for code simplicity; fixed some typo pointed out by Rob Landley) Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Reviewed-by: Axel Lin <axel.lin@gmail.com> Reviewed-by: Kim, Milo <Milo.Kim@ti.com> Acked-by: Rob Landley <rob@landley.net> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-06-22 08:12:06 +08:00
leds: Clarify supported chips by LM355x driver Clarify which controllers are supported by which driver. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-02-01 21:26:34 +01:00
leds: Add LED driver for lm3556 chip LM3556 : The LM3556 is a 4 MHz fixed-frequency synchronous boost converter plus 1.5A constant current driver for a high-current white LED. Datasheet: www.national.com/ds/LM/LM3556.pdf Tested on OMAP4430 (bryan.wu@canonical.com: use module_i2c_driver() rather than lm3556_init/lm3556_exit for code simplicity; fixed some typo pointed out by Rob Landley) Signed-off-by: G.Shark Jeong <gshark.jeong@gmail.com> Reviewed-by: Axel Lin <axel.lin@gmail.com> Reviewed-by: Kim, Milo <Milo.Kim@ti.com> Acked-by: Rob Landley <rob@landley.net> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-06-22 08:12:06 +08:00
leds: add led driver for Bachmann's ot200 Add support for leds on Bachmann's ot200 visualisation device. The device has three leds on the back panel (led_err, led_init and led_run) and can handle up to seven leds on the front panel. The driver was written by Linutronix on behalf of Bachmann electronic GmbH. It incorporates feedback from Lars-Peter Clausen [akpm@linux-foundation.org: add dependency on HAS_IOMEM] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> 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>
2012-01-20 14:33:59 -08:00
leds: Add HAS_IOPORT dependencies In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20230522105049.1467313-18-schnelle@linux.ibm.com Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-22 12:50:22 +02:00
leds: add led driver for Bachmann's ot200 Add support for leds on Bachmann's ot200 visualisation device. The device has three leds on the back panel (led_err, led_init and led_run) and can handle up to seven leds on the front panel. The driver was written by Linutronix on behalf of Bachmann electronic GmbH. It incorporates feedback from Lars-Peter Clausen [akpm@linux-foundation.org: add dependency on HAS_IOMEM] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> 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>
2012-01-20 14:33:59 -08:00
leds: leds-menf21bmc: Introduce MEN 14F021P00 BMC LED driver Added driver to support the 14F021P00 BMC LEDs. The BMC is a Board Management Controller including four LEDs which can be switched on and off. Signed-off-by: Andreas Werner <andreas.werner@men.de> Acked-by: Bryan Wu <cooloney@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2014-08-27 19:52:36 +02:00
leds: is31fl319x: 1/3/6/9-channel light effect led driver This is a driver for the Integrated Silicon Solution Inc. LED driver chips series IS31FL319x. They can drive 1, 3, 6 or up to 9 LEDs. Each LED is individually controllable in brightness (through pwm) in 256 steps so that RGB LEDs can show any of ca. 16 Mio colors. The maximum current of the LEDs can be programmed and limited to 5 .. 40mA through a device tree property. The chip is connected through I2C and can have one of 4 addresses in the range 0x64 .. 0x67 depending on how the AD pin is connected. The address is defined by the reg property as usual. The chip also has a shutdown input which could be connected to a GPIO, but this driver uses software shutdown if all LEDs are inactivated. The chip also has breathing and audio features which are not fully supported by this driver. Tested-on: OMAP5 based Pyra handheld prototype. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Andrey Utkin <andrey_utkin@fastmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-07-19 13:47:30 +02:00
leds: is31fl319x: Make use of device properties Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. Add mod_devicetable.h include. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-07-12 12:08:34 +02:00
leds: is31fl319x: 1/3/6/9-channel light effect led driver This is a driver for the Integrated Silicon Solution Inc. LED driver chips series IS31FL319x. They can drive 1, 3, 6 or up to 9 LEDs. Each LED is individually controllable in brightness (through pwm) in 256 steps so that RGB LEDs can show any of ca. 16 Mio colors. The maximum current of the LEDs can be programmed and limited to 5 .. 40mA through a device tree property. The chip is connected through I2C and can have one of 4 addresses in the range 0x64 .. 0x67 depending on how the AD pin is connected. The address is defined by the reg property as usual. The chip also has a shutdown input which could be connected to a GPIO, but this driver uses software shutdown if all LEDs are inactivated. The chip also has breathing and audio features which are not fully supported by this driver. Tested-on: OMAP5 based Pyra handheld prototype. Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Andrey Utkin <andrey_utkin@fastmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-07-19 13:47:30 +02:00
leds: Add driver for the ISSI IS31FL32xx family of LED controllers The IS31FL32xx family of LED controllers are I2C devices with multiple constant-current channels, each with independent 256-level PWM control. Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml This has been tested on the IS31FL3236 and IS31FL3216, on an ARM (TI am335x) platform. The programming paradigm of these devices is similar in the following ways: - All registers are 8 bit - All LED control registers are write-only - Each LED channel has a PWM register (0-255) - PWM register writes are shadowed until an Update register is poked - All have a concept of Software Shutdown, which disables output However, there are some differences in devices: - 3236/3235 have a separate Control register for each LED, (3218/3216 pack the enable bits into fewer registers) - 3236/3235 have a per-channel current divisor setting - 3236/3235 have a Global Control register that can turn off all LEDs - 3216 is unique in a number of ways - OUT9-OUT16 can be configured as GPIOs instead of LED controls - LEDs can be programmed with an 8-frame animation, with programmable delay between frames - LEDs can be modulated by an input audio signal - Max output current can be adjusted from 1/4 to 2x globally - Has a Configuration register instead of a Shutdown register This driver currently only supports the base PWM control function of these devices. The following features of these devices are not implemented, although it should be possible to add them in the future: - All devices are capable of going into a lower-power "software shutdown" mode. - The is31fl3236 and is31fl3235 can reduce the max output current per-channel with a divisor of 1, 2, 3, or 4. - The is31fl3216 can use some LED channels as GPIOs instead. - The is31fl3216 can animate LEDs in hardware. - The is31fl3216 can modulate LEDs according to an audio input. - The is31fl3216 can reduce/increase max output current globally. Signed-off-by: David Rivshin <drivshin@allworx.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-03-07 19:57:15 -05:00
leds: Add SN3218 and SN3216 support to the IS31FL32XX driver Si-En Technology was acquired by ISSI in 2011, and it appears that the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices. Add the "si-en,sn3218" and "si-en,sn3216" compatible strings into the IS31FL32XX driver as aliases for the issi equivalents, and update binding documentation. Datasheets: IS31FL3218: http://www.issi.com/WW/pdf/31FL3218.pdf SN3218: http://www.si-en.com/uploadpdf/s2011517171720.pdf IS31FL3216: http://www.issi.com/WW/pdf/31FL3216.pdf SN3216: http://www.si-en.com/uploadpdf/SN3216201152410148.pdf Signed-off-by: David Rivshin <drivshin@allworx.com> Acked-by: Rob Herring <robh@kernel.org> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-03-07 19:57:16 -05:00
leds: Add driver for the ISSI IS31FL32xx family of LED controllers The IS31FL32xx family of LED controllers are I2C devices with multiple constant-current channels, each with independent 256-level PWM control. Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml This has been tested on the IS31FL3236 and IS31FL3216, on an ARM (TI am335x) platform. The programming paradigm of these devices is similar in the following ways: - All registers are 8 bit - All LED control registers are write-only - Each LED channel has a PWM register (0-255) - PWM register writes are shadowed until an Update register is poked - All have a concept of Software Shutdown, which disables output However, there are some differences in devices: - 3236/3235 have a separate Control register for each LED, (3218/3216 pack the enable bits into fewer registers) - 3236/3235 have a per-channel current divisor setting - 3236/3235 have a Global Control register that can turn off all LEDs - 3216 is unique in a number of ways - OUT9-OUT16 can be configured as GPIOs instead of LED controls - LEDs can be programmed with an 8-frame animation, with programmable delay between frames - LEDs can be modulated by an input audio signal - Max output current can be adjusted from 1/4 to 2x globally - Has a Configuration register instead of a Shutdown register This driver currently only supports the base PWM control function of these devices. The following features of these devices are not implemented, although it should be possible to add them in the future: - All devices are capable of going into a lower-power "software shutdown" mode. - The is31fl3236 and is31fl3235 can reduce the max output current per-channel with a divisor of 1, 2, 3, or 4. - The is31fl3216 can use some LED channels as GPIOs instead. - The is31fl3216 can animate LEDs in hardware. - The is31fl3216 can modulate LEDs according to an audio input. - The is31fl3216 can reduce/increase max output current globally. Signed-off-by: David Rivshin <drivshin@allworx.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-03-07 19:57:15 -05:00
leds: Add Spreadtrum SC27xx breathing light controller driver This patch adds Spreadtrum SC27xx PMIC series breathing light controller driver, which can support 3 LEDs. Each LED can work at normal PWM mode and breathing mode. Signed-off-by: Xiaotong Lu <xiaotong.lu@spreadtrum.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-05-14 14:34:51 +08:00
leds: Add AAEON UP board LED driver Add support for LEDs on AAEON UP boards. These leds are managed by the onboard FPGA: - UP boards: yellow, green, red - UP Squared boards: blue, yellow, green, red Based on the work done by Gary Wang <garywang@aaeon.com.tw>, largely rewritten. Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> Link: https://lore.kernel.org/r/20241211-aaeon-up-board-pinctrl-support-v1-2-24719be27631@bootlin.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-12-11 17:27:17 +01:00
HID: thingm: refactor blink(1) support This patch refactors the way the thingm driver registers a blink(1) LED. In order to make the driver simpler and more standard, drop the "rgb" sysfs attribute and create one instance of LED class per RGB channel. Actually, the name of the LED class instance registered for a blink(1) device is "blink1::ABCD", where ABCD is the last 4 chars of the serial number. The driver now registers 3 instances per RGB chip, named "thingmX:{red,green,blue}:ledY" where X is the hidraw minor number and Y is the RGB chip number (as seen by the firmware). This patch also uses work queues to defer calls with the device, which now allows triggers to work as expected with this LED device. Also remove the brightness structure field and the brightness_get backend, as it is already handled by the LED class, and changes the prefix of functions and structures to thingm_ to match the driver name. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-04-14 16:50:19 -04:00
LEDS: add BlinkM RGB LED driver, documentation and update MAINTAINERS Add driver for BlinkM device to drivers/leds/. Add entry to MAINTAINERS file. Add documentation in Documentation/leds/. A BlinkM is a RGB LED controlled through I2C. This driver implements an interface to the LED framework and another sysfs group to access the internal options of the BlinkM. rev6: Use module_i2c_driver(). rev5: Removed own workqueue in favor of events wq. rev4: Fixed comments by Bryan Wu. rev3: Fixed issues found by Jonathan Neuschäfer. (bryan.wu@canonical.com: remove 2 trailing whitespace) Signed-off-by: Jan-Simon Möller <jansimon.moeller@gmx.de> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
2012-07-20 16:49:06 +08:00
leds: Add multicolor support to BlinkM LED driver Add multicolor support to the BlinkM driver, making it easier to control from userspace. The BlinkM LED is a programmable RGB LED. The driver currently supports only the regular LED sysfs class, resulting in the creation of three distinct classes, one for red, green, and blue. The user then has to input three values into the three seperate brightness files within those classes. The multicolor LED framework makes the device easier to control with the multi_intensity file: the user can input three values at once to form a color, while still controlling the lightness with the brightness file. The main struct blinkm_led has changed slightly. The struct led_classdev for the regular sysfs classes remain. The blinkm_probe function checks CONFIG_LEDS_BLINKM_MULTICOLOR to decide whether to load the seperate sysfs classes or the single multicolor one, but never both. The blinkm_set_mc_brightness() function had to be added to calculate the three color components and then set the fields of the blinkm_data structure accordingly. Signed-off-by: Joseph Strauss <jstrauss@mailbox.org> Link: https://lore.kernel.org/r/20240710184844.108006-1-jstrauss@mailbox.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-10 13:48:44 -05:00
leds: blinkm: Fix CONFIG_LEDS_CLASS_MULTICOLOR dependency With CONFIG_LEDS_CLASS_MULTICOLOR=m, a builtin leds-blinkm driver causes a link failure: arm-linux-gnueabi-ld: drivers/leds/leds-blinkm.o: in function `blinkm_set_mc_brightness': leds-blinkm.c:(.text.blinkm_set_mc_brightness+0xc): undefined reference to `led_mc_calc_color_components' Add a more specific dependency that only allows multicoler mode to be enabled for blinkm if it can build and link. Fixes: 56e8c56c9af0 ("leds: Add multicolor support to BlinkM LED driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Joseph Strauss <jstrauss@mailbox.org> Link: https://lore.kernel.org/r/20240807075614.2118068-1-arnd@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-08-07 09:55:53 +02:00
leds: Add multicolor support to BlinkM LED driver Add multicolor support to the BlinkM driver, making it easier to control from userspace. The BlinkM LED is a programmable RGB LED. The driver currently supports only the regular LED sysfs class, resulting in the creation of three distinct classes, one for red, green, and blue. The user then has to input three values into the three seperate brightness files within those classes. The multicolor LED framework makes the device easier to control with the multi_intensity file: the user can input three values at once to form a color, while still controlling the lightness with the brightness file. The main struct blinkm_led has changed slightly. The struct led_classdev for the regular sysfs classes remain. The blinkm_probe function checks CONFIG_LEDS_BLINKM_MULTICOLOR to decide whether to load the seperate sysfs classes or the single multicolor one, but never both. The blinkm_set_mc_brightness() function had to be added to calculate the three color components and then set the fields of the blinkm_data structure accordingly. Signed-off-by: Joseph Strauss <jstrauss@mailbox.org> Link: https://lore.kernel.org/r/20240710184844.108006-1-jstrauss@mailbox.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-07-10 13:48:44 -05:00
leds/powernv: Add driver for PowerNV platform This patch implements LED driver for PowerNV platform using the existing generic LED class framework. PowerNV platform has below type of LEDs: - System attention Indicates there is a problem with the system that needs attention. - Identify Helps the user locate/identify a particular FRU or resource in the system. - Fault Indicates there is a problem with the FRU or resource at the location with which the indicator is associated. We register classdev structures for all individual LEDs detected on the system through LED specific device tree nodes. Device tree nodes specify what all kind of LEDs present on the same location code. It registers LED classdev structure for each of them. All the system LEDs can be found in the same regular path /sys/class/leds/. We don't use LED colors. We use LED node and led-types property to form LED classdev. Our LEDs have names in this format. <location_code>:<attention|identify|fault> Any positive brightness value would turn on the LED and a zero value would turn off the LED. The driver will return LED_FULL (255) for any turned on LED and LED_OFF (0) for any turned off LED. The platform level implementation of LED get and set state has been achieved through OPAL calls. These calls are made available for the driver by exporting from architecture specific codes. Signed-off-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com> Acked-by: Stewart Smith <stewart@linux.vnet.ibm.com> Tested-by: Stewart Smith <stewart@linux.vnet.ibm.com> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-08-19 22:19:54 +05:30
leds: add a driver for syscon-based LEDs This makes it possible to create a set of LEDs from a syscon MFD instance, which is lean mean and clean on the ARM reference designs and can replace the Versatile LEDs driver in the long run, as well as other custom syscon LEDs drivers. Cc: Bryan Wu <cooloney@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> [Fixed cocinelle warnings] Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-05-22 00:34:16 +02:00
leds: fix Kconfig text for MLXCPLD, SYSCON, MC13783, NETXBIG It fixes grammatical errors in Kconfig file for LEDS_SYSCON, LEDS_MLXCPLD, LEDS_MC13783, LEDS_NETXBIG. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-02-15 18:11:37 +00:00
leds: add a driver for syscon-based LEDs This makes it possible to create a set of LEDs from a syscon MFD instance, which is lean mean and clean on the ARM reference designs and can replace the Versatile LEDs driver in the long run, as well as other custom syscon LEDs drivers. Cc: Bryan Wu <cooloney@gmail.com> Cc: Richard Purdie <rpurdie@rpsys.net> [Fixed cocinelle warnings] Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-05-22 00:34:16 +02:00
leds: add PM8058 LEDs driver This adds a driver for the six PM8058 LEDs, three ordinary LEDs, two "flash" LEDs and one "keypad" LED. The "keypad" and "flash" LEDs are not really hard-wired to these usecases: for example on the APQ8060 Dragonboard, the "keypad" LED is instead used to drive an IR LED used for the proximity sensor. The "flash" LEDs are just ordinary high-current LED drivers. Cc: linux-arm-msm@vger.kernel.org Cc: Andy Gross <andy.gross@linaro.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-08-16 11:25:10 +02:00
mfd: qcom-pm8xxx: Clean up PM8XXX namespace The Kconfig and file naming for the PM8xxx driver is totally confusing: - Kconfig options MFD_PM8XXX and MFD_PM8921_CORE, some in-kernel users depending on or selecting either at random. - A driver file named pm8921-core.c even if it is indeed used by the whole PM8xxx family of chips. - An irqchip named pm8xxx since it was (I guess) realized that the driver was generic for all pm8xxx PMICs. As I may want to add support for PM8901 this is starting to get really messy. Fix this situation by: - Remove the MFD_PM8921_CORE symbol and rely solely on MFD_PM8XXX and convert all users, including LEDs Kconfig and ARM defconfigs for qcom and multi_v7 to use that single symbol. - Renaming the driver to qcom-pm8xxx.c to fit along the two other qcom* prefixed drivers. - Rename functions withing the driver from 8921 to 8xxx to indicate it is generic. - Just drop the =m config from the pxa_defconfig, I have no clue why it is even there, it is not a Qualcomm platform. (Possibly older Kconfig noise from saveconfig.) Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Andy Gross <andy.gross@linaro.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2016-11-19 16:15:18 +01:00
leds: add PM8058 LEDs driver This adds a driver for the six PM8058 LEDs, three ordinary LEDs, two "flash" LEDs and one "keypad" LED. The "keypad" and "flash" LEDs are not really hard-wired to these usecases: for example on the APQ8060 Dragonboard, the "keypad" LED is instead used to drive an IR LED used for the proximity sensor. The "flash" LEDs are just ordinary high-current LED drivers. Cc: linux-arm-msm@vger.kernel.org Cc: Andy Gross <andy.gross@linaro.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-08-16 11:25:10 +02:00
leds: add driver for Mellanox systems LEDs This makes it possible to create a set of LEDs for Mellanox systems: "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740", "msn2100". Driver obtains LED devices according to system configuration, provided through system DMI data, like mlxcpld:fan1:green, mlxcpld:fan1:red and creates devices in form: "devicename:colour:function". LED setting is controlled through on board CPLD Lattice device. For setting particular LED off, solid, blink: echo 0 > /sys/class/leds/mlxcpld\:status\:green/brightness echo 1 > /sys/class/leds/mlxcpld\:status\:green/brightness echo timer > /sys/class/leds/mlxcpld\:status\:green/trigger On module probing all LEDs are set green, on removing - off. Last setting overwrites previous, f.e. sequence for changing LED from green - red - green: echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness echo 1 > /sys/class/leds/mlxcpld\:psu\:red/brightness echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness Note: LEDs cannot be turned on/off simultaneously. The Kconfig currently controlling compilation of this code is: drivers/leds/Kconfig:config LEDS_MLXCPLD Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-09-08 07:25:53 +00:00
leds: leds-mlxcpld: Allow compilation for 32 bit arch It makes leds-mlxcpld available for 32 bit architecture. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Reported-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-02-01 08:10:34 +00:00
leds: add driver for Mellanox systems LEDs This makes it possible to create a set of LEDs for Mellanox systems: "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740", "msn2100". Driver obtains LED devices according to system configuration, provided through system DMI data, like mlxcpld:fan1:green, mlxcpld:fan1:red and creates devices in form: "devicename:colour:function". LED setting is controlled through on board CPLD Lattice device. For setting particular LED off, solid, blink: echo 0 > /sys/class/leds/mlxcpld\:status\:green/brightness echo 1 > /sys/class/leds/mlxcpld\:status\:green/brightness echo timer > /sys/class/leds/mlxcpld\:status\:green/trigger On module probing all LEDs are set green, on removing - off. Last setting overwrites previous, f.e. sequence for changing LED from green - red - green: echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness echo 1 > /sys/class/leds/mlxcpld\:psu\:red/brightness echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness Note: LEDs cannot be turned on/off simultaneously. The Kconfig currently controlling compilation of this code is: drivers/leds/Kconfig:config LEDS_MLXCPLD Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-09-08 07:25:53 +00:00
leds: fix Kconfig text for MLXCPLD, SYSCON, MC13783, NETXBIG It fixes grammatical errors in Kconfig file for LEDS_SYSCON, LEDS_MLXCPLD, LEDS_MC13783, LEDS_NETXBIG. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-02-15 18:11:37 +00:00
leds: add driver for Mellanox systems LEDs This makes it possible to create a set of LEDs for Mellanox systems: "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740", "msn2100". Driver obtains LED devices according to system configuration, provided through system DMI data, like mlxcpld:fan1:green, mlxcpld:fan1:red and creates devices in form: "devicename:colour:function". LED setting is controlled through on board CPLD Lattice device. For setting particular LED off, solid, blink: echo 0 > /sys/class/leds/mlxcpld\:status\:green/brightness echo 1 > /sys/class/leds/mlxcpld\:status\:green/brightness echo timer > /sys/class/leds/mlxcpld\:status\:green/trigger On module probing all LEDs are set green, on removing - off. Last setting overwrites previous, f.e. sequence for changing LED from green - red - green: echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness echo 1 > /sys/class/leds/mlxcpld\:psu\:red/brightness echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness Note: LEDs cannot be turned on/off simultaneously. The Kconfig currently controlling compilation of this code is: drivers/leds/Kconfig:config LEDS_MLXCPLD Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-09-08 07:25:53 +00:00
leds: add driver for support Mellanox regmap LEDs for BMC and x86 platform Driver obtains LED devices according to system configuration and creates devices in form: "devicename:color:function", like The full path is to be: /sys/class/leds/mlxreg\:status\:amber/brightness After timer trigger activation: echo timer > /sys/class/leds/mlxreg\:status\:amber/trigger Attributes for LED blinking will appaer in sysfs infrastructure: /sys/class/leds/mlxreg\:status\:amber/delay_off /sys/class/leds/mlxreg\:status\:amber/delay_on LED setting is controlled through the on-board programmable devices, which exports its register map. This device could be attached to any bus type, for which register mapping is supported. Signed-off-by: Vadim Pasternak <vadimp@mellanox.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2018-02-15 23:37:50 +00:00
leds: Introduce userspace LED class driver This driver creates a userspace leds driver similar to uinput. New LEDs are created by opening /dev/uleds and writing a uleds_user_dev struct. A new LED class device is registered with the name given in the struct. Reading will return a single byte that is the current brightness. The poll() syscall is also supported. It will be triggered whenever the brightness changes. Closing the file handle to /dev/uleds will remove the leds class device. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-09-16 14:16:48 -05:00
leds: Add user LED driver for NIC78bx device Add the driver to support User LEDs on PXI Embedded Controller. Signed-off-by: Hui Chun Ong <hui.chun.ong@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-04 13:31:47 +08:00
leds: nic78bx: Tidy up ACPI ID table Tidy up ACPI ID table: - Drop ACPI_PTR() and hence replace acpi.h with mod_devicetable.h and other necessary headers - Remove explicit driver_data initializer - Drop comma in the terminator entry With that done, extend compile test coverage. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250313161630.415515-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-03-13 18:16:30 +02:00
leds: Add user LED driver for NIC78bx device Add the driver to support User LEDs on PXI Embedded Controller. Signed-off-by: Hui Chun Ong <hui.chun.ong@ni.com> Signed-off-by: Brad Mouring <brad.mouring@ni.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-11-04 13:31:47 +08:00
leds: spi-byte: add single byte SPI LED driver This driver adds support for simple SPI based LED controller which use only one byte for setting the brightness. Signed-off-by: Christian Mauderer <oss@c-mauderer.de> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-05-13 21:33:07 +02:00
leds: TI LMU: Add common code for TI LMU devices Create a TI LMU common framework for TI LMU devices that share common features. Currently the runtime ramp and brightness setting have been identified as common features with common register settings. This work is derived from Milo Kims TI LMU MFD code. Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-05-06 14:16:11 -05:00
leds: Make LEDS_TI_LMU_COMMON invisible Currently, LEDS_LM3697 and LEDS_LM36274 depend on LEDS_TI_LMU_COMMON, which contains the common code to support TI LMU devices. This means the user is asked about the common code first, followed by the individual drivers, if their dependencies are met. Simplify this, and reduce the number of questions by making LEDS_TI_LMU_COMMON invisible, and letting it be selected when needed. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/91f6efaa48c36320e58b6a312025ae9b39ee206b.1683644796.git.geert+renesas@glider.be Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-09 17:07:47 +02:00
leds: TI_LMU_COMMON: select REGMAP instead of depending on it REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on REGMAP" to "select REGMAP". Fixes: 3fce8e1eb994 ("leds: TI LMU: Add common code for TI LMU devices") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230226053953.4681-5-rdunlap@infradead.org
2023-02-25 21:39:49 -08:00
leds: TI LMU: Add common code for TI LMU devices Create a TI LMU common framework for TI LMU devices that share common features. Currently the runtime ramp and brightness setting have been identified as common features with common register settings. This work is derived from Milo Kims TI LMU MFD code. Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-05-06 14:16:11 -05:00
leds: lm3697: Introduce the lm3697 driver Introduce the lm3697 LED driver for backlighting and display. Datasheet location: http://www.ti.com/lit/ds/symlink/lm3697.pdf Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-05-06 14:16:14 -05:00
leds: Make LEDS_TI_LMU_COMMON invisible Currently, LEDS_LM3697 and LEDS_LM36274 depend on LEDS_TI_LMU_COMMON, which contains the common code to support TI LMU devices. This means the user is asked about the common code first, followed by the individual drivers, if their dependencies are met. Simplify this, and reduce the number of questions by making LEDS_TI_LMU_COMMON invisible, and letting it be selected when needed. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/91f6efaa48c36320e58b6a312025ae9b39ee206b.1683644796.git.geert+renesas@glider.be Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-09 17:07:47 +02:00
leds: lm3697: Introduce the lm3697 driver Introduce the lm3697 LED driver for backlighting and display. Datasheet location: http://www.ti.com/lit/ds/symlink/lm3697.pdf Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-05-06 14:16:14 -05:00
leds: lm36274: Introduce the TI LM36274 LED driver Introduce the LM36274 LED driver. This driver uses the ti-lmu MFD driver to probe this LED driver. The driver configures only the LED registers and enables the outputs according to the config file. The driver utilizes the TI LMU (Lighting Management Unit) LED common framework to set the brightness bits. Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-06-05 07:56:34 -05:00
leds: Make LEDS_TI_LMU_COMMON invisible Currently, LEDS_LM3697 and LEDS_LM36274 depend on LEDS_TI_LMU_COMMON, which contains the common code to support TI LMU devices. This means the user is asked about the common code first, followed by the individual drivers, if their dependencies are met. Simplify this, and reduce the number of questions by making LEDS_TI_LMU_COMMON invisible, and letting it be selected when needed. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/91f6efaa48c36320e58b6a312025ae9b39ee206b.1683644796.git.geert+renesas@glider.be Signed-off-by: Lee Jones <lee@kernel.org>
2023-05-09 17:07:47 +02:00
leds: lm36274: Introduce the TI LM36274 LED driver Introduce the LM36274 LED driver. This driver uses the ti-lmu MFD driver to probe this LED driver. The driver configures only the LED registers and enables the outputs according to the config file. The driver utilizes the TI LMU (Lighting Management Unit) LED common framework to set the brightness bits. Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2019-06-05 07:56:34 -05:00
leds: Add LED1202 I2C driver The output current can be adjusted separately for each channel by 8-bit analog (current sink input) and 12-bit digital (PWM) dimming control. The LED1202 implements 12 low-side current generators with independent dimming control. Internal volatile memory allows the user to store up to 8 different patterns, each pattern is a particular output configuration in terms of PWM duty-cycle (on 4096 steps). Analog dimming (on 256 steps) is per channel but common to all patterns. Each device tree LED node will have a corresponding entry in /sys/class/leds with the label name. The brightness property corresponds to the per channel analog dimming, while the patterns[1-8] to the PWM dimming control. Signed-off-by: Vicentiu Galanopulo <vicentiu.galanopulo@remote-tech.co.uk> Link: https://lore.kernel.org/r/20241218182001.41476-4-vicentiu.galanopulo@remote-tech.co.uk Signed-off-by: Lee Jones <lee@kernel.org>
2024-12-18 18:19:55 +00:00
leds: Kconfig: leds-st1202: Add select for required LEDS_TRIGGER_PATTERN leds-st1202 requires the LED Pattern Trigger (LEDS_TRIGGER_PATTERN), which is not selected when LED Trigger support is (LEDS_TRIGGERS). To reproduce this: - make menuconfig KCONFIG_CONFIG= - select LEDS_ST1202 dependencies OF, I2C and LEDS_CLASS. - select LEDS_ST1202 - LEDS_TRIGGERS is selected but LEDS_TRIGGER_PATTERN isn't. The absence of LEDS_TRIGGER_PATTERN explicitly required can lead to builds in which LEDS_ST1202 is selected while LEDS_TRIGGER_PATTERN isn't. The direct result of that would be that /sys/class/leds/<led>/hw_pattern wouldn't be available and there would be no way of interacting with the driver and hardware from user space. Add select LEDS_TRIGGER_PATTERN to Kconfig to meet the requirement and indirectly document it as well. Signed-off-by: Manuel Fombuena <fombuena@outlook.com> Link: https://lore.kernel.org/r/CWLP123MB5473F4DF3A668F7DD057A280C5C22@CWLP123MB5473.GBRP123.PROD.OUTLOOK.COM Signed-off-by: Lee Jones <lee@kernel.org>
2025-02-26 17:12:50 +00:00
leds: Add LED1202 I2C driver The output current can be adjusted separately for each channel by 8-bit analog (current sink input) and 12-bit digital (PWM) dimming control. The LED1202 implements 12 low-side current generators with independent dimming control. Internal volatile memory allows the user to store up to 8 different patterns, each pattern is a particular output configuration in terms of PWM duty-cycle (on 4096 steps). Analog dimming (on 256 steps) is per channel but common to all patterns. Each device tree LED node will have a corresponding entry in /sys/class/leds with the label name. The brightness property corresponds to the per channel analog dimming, while the patterns[1-8] to the PWM dimming control. Signed-off-by: Vicentiu Galanopulo <vicentiu.galanopulo@remote-tech.co.uk> Link: https://lore.kernel.org/r/20241218182001.41476-4-vicentiu.galanopulo@remote-tech.co.uk Signed-off-by: Lee Jones <lee@kernel.org>
2024-12-18 18:19:55 +00:00
leds: ltc3220: Add Support for LTC3220 18 channel LED Driver Add driver for the LTC3220 18-channel LED driver with I2C interface, individual brightness control, and hardware-assisted blink/gradation features. Signed-off-by: Edelweise Escala <edelweise.escala@analog.com> Link: https://patch.msgid.link/20260709-ltc3220-driver-v13-2-9b53237642eb@analog.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-07-09 08:41:20 +08:00
leds: tps6105x: add driver for MFD chip LED mode This driver adds support for the LED operational mode of the tps6105x MFD device. Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2019-12-16 09:32:58 -05:00
leds: add SGI IP30 led support This patch implemenets a driver to support the front panel LEDs of SGI Octane (IP30) workstations. Reviewed-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-02-24 12:17:33 +01:00
leds: ip30: compile if COMPILE_TEST=y This driver can be compiled on other platforms with small change if COMPILE_TEST=y. Signed-off-by: Marek Behún <marek.behun@nic.cz> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com> Cc: Thomas Bogendoerfer <tbogendoerfer@suse.de> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-09-18 00:32:50 +02:00
leds: add SGI IP30 led support This patch implemenets a driver to support the front panel LEDs of SGI Octane (IP30) workstations. Reviewed-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-02-24 12:17:33 +01:00
leds: Add driver for Acer Iconia Tab A500 Acer Iconia Tab A500 is an Android tablet device which has two LEDs embedded into the Power Button. Orange LED indicates "battery charging" status and white LED indicates "wake-up/charge-done" status. The new LED driver provides control over both LEDs to userspace. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2020-09-06 22:51:02 +03:00
leds: lgm: Improve Kconfig help Remove unnecessary Kconfig symbol LEDS_BLINK Improve Kconfig help text to make it more useful. Signed-off-by: Rahul Tanwar <rtanwar@maxlinear.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-03-25 11:35:10 +01:00
leds: rt8515: Add Richtek RT8515 LED driver This adds a driver for the Richtek RT8515 dual channel torch/flash white LED driver. This LED driver is found in some mobile phones from Samsung such as the GT-S7710 and GT-I8190. A V4L interface is added. We do not have a proper datasheet for the RT8515 but it turns out that RT9387A has a public datasheet and is essentially the same chip. We designed the driver in accordance with this datasheet. The day someone needs to drive a RT9387A this driver can probably easily be augmented to handle that chip too. Sakari Ailus, Pavel Machek and Andy Shevchenko helped significantly in getting this driver right. Cc: Sakari Ailus <sakari.ailus@iki.fi> Cc: newbytee@protonmail.com Cc: Stephan Gerhold <stephan@gerhold.net> Cc: linux-media@vger.kernel.org Cc: phone-devel@vger.kernel.org Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-01-03 00:15:10 +01:00
leds: Add driver for Qualcomm LPG The Light Pulse Generator (LPG) is a PWM-block found in a wide range of PMICs from Qualcomm. These PMICs typically comes with 1-8 LPG instances, with their output being routed to various other components, such as current sinks or GPIOs. Each LPG instance can operate on fixed parameters or based on a shared lookup-table, altering the duty cycle over time. This provides the means for hardware assisted transitions of LED brightness. A typical use case for the fixed parameter mode is to drive a PWM backlight control signal, the driver therefor allows each LPG instance to be exposed to the kernel either through the LED framework or the PWM framework. A typical use case for the LED configuration is to drive RGB LEDs in smartphones etc, for which the driver supports multiple channels to be ganged up to a MULTICOLOR LED. In this configuration the pattern generators will be synchronized, to allow for multi-color patterns. The idea of modelling this as a LED driver ontop of a PWM driver was considered, but setting the properties related to patterns does not fit in the PWM API. Similarly the idea of just duplicating the lower bits in a PWM and LED driver separately was considered, but this would not allow the PWM channels and LEDs to be configured on a per-board basis. The driver implements the more complex LED interface, and provides a PWM interface on the side of that, in the same driver. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Tested-by: Marijn Suijten <marijn.suijten@somainline.org> [On the Sony Xperia Nile Discovery, SDM630] Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-03-03 13:43:00 -08:00
leds: Kconfig cleanup Remove the need for "depends on LEDS_CLASS" by wrapping the affected config options in an if/endif block. Similar for "depends on LEDS_TRIGGERS". LEDS_COBALT_RAQ still has a "depends on LEDS_CLASS=y" since it cannot be selected to build as a module. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
2010-01-20 16:08:30 -07:00
leds: move LED trigger drivers into new subdirectory For better driver management, new subdirectory, 'trigger' is created. All LED trigger drivers are moved into this directory. Internal header, 'leds.h' is included in each LED trigger drivers. Fix the location of header file, "leds.h" -> "../leds.h" in driver files. One exception is here, 'ledtrig-timer.c'. There is no need to include 'leds.h'. so '#include "leds.h"' line was removed. Signed-off-by: Milo(Woogyom) Kim <milo.kim@ti.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
2013-02-20 00:36:01 -08:00
leds: add new transient trigger for one shot timer activation The leds timer trigger does not currently have an interface to activate a one shot timer. The current support allows for setting two timers, one for specifying how long a state to be on, and the second for how long the state to be off. The delay_on value specifies the time period an LED should stay in on state, followed by a delay_off value that specifies how long the LED should stay in off state. The on and off cycle repeats until the trigger gets deactivated. There is no provision for one time activation to implement features that require an on or off state to be held just once and then stay in the original state forever. Without one shot timer interface, user space can still use timer trigger to set a timer to hold a state, however when user space application crashes or goes away without deactivating the timer, the hardware will be left in that state permanently. As a specific example of this use-case, let's look at vibrate feature on phones. Vibrate function on phones is implemented using PWM pins on SoC or PMIC. There is a need to activate one shot timer to control the vibrate feature, to prevent user space crashes leaving the phone in vibrate mode permanently causing the battery to drain. This trigger exports three properties, activate, state, and duration When transient trigger is activated these properties are set to default values. - duration allows setting timer value in msecs. The initial value is 0. - activate allows activating and deactivating the timer specified by duration as needed. The initial and default value is 0. This will allow duration to be set after trigger activation. - state allows user to specify a transient state to be held for the specified duration. Signed-off-by: Shuah Khan <shuahkhan@gmail.com> Cc: Jonas Bonn <jonas@southpole.se> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: NeilBrown <neilb@suse.de> 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>
2012-05-29 15:07:30 -07:00
leds: Rename simple directory to simatic The drivers contained in this directory are not simplistic. Signed-off-by: Lee Jones <lee@kernel.org>
2025-03-07 10:01:10 -08:00
leds: simatic-ipc-leds: add new driver for Siemens Industial PCs This driver adds initial support for several devices from Siemens. It is based on a platform driver introduced in an earlier commit. One of the supported machines has GPIO connected LEDs, here we poke GPIO memory directly because pinctrl does not come up. Signed-off-by: Henning Schild <henning.schild@siemens.com> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20211213120502.20661-3-henning.schild@siemens.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-13 13:05:00 +01:00
leds: Use menuconfig objects II - LED Change Kconfig objects from "menu, config" into "menuconfig" so that the user can disable the whole feature without having to enter the menu first. Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
2007-05-10 10:44:11 +01:00