summaryrefslogtreecommitdiff
path: root/drivers/leds
AgeCommit message (Collapse)Author
2026-08-13leds: aw200xx: add support for "all" in pattern LED selectionMartin Kurbanov
Currently, users must explicitly specify each LED, which is cumbersome for devices with a large number of channels. Add support for a special "all" keyword to both select_leds and clear_leds sysfs attributes. Signed-off-by: Martin Kurbanov <mmkurbanov@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13leds: aw200xx: Share framebuffer's leds with patternsGeorge Stark
Allow to use framebuffer's leds in patterns only if framebuffer is not opened and dont allow to open framebuffer if its leds are used in patterns. Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13leds: aw200xx: Support for hw pattern controllersMartin Kurbanov
This led-controller supports 3 pattern controllers for auto breathing or group dimming control. Each pattern controller can work in auto breathing or manual control mode. All breathing parameters including rising/falling slope, on/off time, repeat times, min/max brightness and so on are configurable. Signed-off-by: Martin Kurbanov <mmkurbanov@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13drivers/leds: Add framebuffer and backlight dependencies for AW200XXGeorge Stark
Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13leds: aw200xx: Add support for framebuffer interfaceGeorge Stark
LEDs subset or all LEDs can be accessed thru framebuffer interface. Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13leds: aw200xx: Update led states thru delayed work queueGeorge Stark
This feature allows multiple LED clients (e.g., a single-LED user and a framebuffer user) to operate at the same time. Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13leds: aw200xx: Introduce separate internal aw200xx_dim_fill()George Stark
This function is useful for future store queue operation support. Signed-off-by: George Stark <george.stark@mailbox.org> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13leds: aw200xx: Support default-state DT propertyGeorge Stark
Support DT property default-state's values: on, off, keep. Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13leds: aw200xx: Fully initialize chip before registering LEDsGeorge Stark
Since all the required information is ready before creating LED objects then chip can be fully initialized in the first place and locking the mutex becomes unnecessary. Also it's unnecessary to handle devm_led_classdev_register_ext() return value, because we register all leds which we can. Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13leds: aw200xx: Redesign driver's probing stageGeorge Stark
Split aw200xx_probe_fw() into two steps. At the first step aw200xx_probe_dt_leds() reads all information from DT about LEDs configuration to temporary array at early stage of probe. It'll allow to have all details before initializing the chip thus simplify it. At the second step aw200xx_probe_register_leds() solely creates leds objects. Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13leds: aw200xx: Fix calculating display_rowsGeorge Stark
aw200xx_probe_get_display_rows() returns error if max found reg value is 0 but actually it's a valid situation if a single LED is connected to row 0 and column 0. Fixes: 2b8db5729d10 ("leds: aw200xx: Calculate dts property display_rows in the driver") Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-08-13leds: aw200xx: Drop manual aw200xx_disable() if probe failedGeorge Stark
Since aw200xx_disable() schedulled earlier thru devm_add_action() it's no need to call aw200xx_disable() manually at the probe error section. Fixes: a59d8824d730 ("leds: aw200xx: Use devm API to cleanup module's resources") Signed-off-by: George Stark <gnstark@salutedevices.com> Signed-off-by: Dmitry Rokosov <rockosov@rulkc.org>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-16Merge tag 'leds-next-6.20' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds Pull LED updates from Lee Jones: "New Support & Features: - Add support for the TI LP5812 4x3 matrix RGB LED driver, including autonomous animation engine control and extensive scan multiplexing modes - Add a new driver for the ams Osram AS3668 4-channel I2C LED controller - Extend the is31fl32xx driver to support the is31fl3293 variant, which features 3 channels and 12-bit PWM resolution Improvements & Fixes: - Prevent the ExpressWire KTD2801 chip from entering an undefined state by disabling interrupts during time-sensitive communication - Ensure the Qualcomm LPG driver detects hardware write failures by checking the return value of regmap_bulk_write() during LUT programming - Fix kernel-doc warnings in the lm3692x driver by documenting missing struct members and standardizing the comment style - Update the ExpressWire library to use fsleep() and unexport internal-only functions - Improve the is31fl32xx driver by reordering code to eliminate unnecessary forward declarations Cleanups & Refactoring: - Simplify the LP55XX common LED driver by utilizing the for_each_available_child_of_node_scoped() macro for more concise node iteration Device Tree Bindings Updates: - Add new YAML bindings for the TI LP5860 and LP5812 LED controllers, and the ams Osram AS3668 - Convert the TI LM3697 white LED driver binding to DT schema format - Allow multicolor LED nodes to be named with numeric suffixes (e.g., multi-led-0) to handle multiple instances without unit addresses - Document support for the PMH0101 variant in the Qualcomm LPG PWM and SPMI Flash LED bindings - Add the issi,is31fl3293 compatible string to the is31fl32xx binding" * tag 'leds-next-6.20' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: dt-bindings: leds: Convert ti,lm3697 to DT schema leds: as3668: Driver for the ams Osram 4-channel i2c LED driver dt-bindings: leds: Add new as3668 support docs: leds: Document TI LP5812 LED driver leds: Add basic support for TI/National Semiconductor LP5812 LED Driver leds: qcom-lpg: Check the return value of regmap_bulk_write() dt-bindings: leds: qcom,spmi-flash-led: Add PMH0101 compatible dt-bindings: leds: leds-qcom-lpg: Add support for PMH0101 PWM dt-bindings: leds: Allow differently named multicolor LEDs leds: lp55xx: Simplify with scoped for each OF child loop dt-bindings: leds: add TI/National Semiconductor LP5812 LED Driver leds: is31f132xx: Add support for is31fl3293 leds: is31f132xx: Re-order code to remove forward declarations dt-bindings: leds: Add issi,is31fl3293 to leds-is31fl32xx leds: expresswire: Fix chip state breakage dt-bindings: leds: Add LP5860 LED controller leds: lm3692x: Fix kernel-doc for struct lm3692x_led
2026-02-04leds: as3668: Driver for the ams Osram 4-channel i2c LED driverLukas Timmermann
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-02-04leds: Add basic support for TI/National Semiconductor LP5812 LED DriverNam Tran
The LP5812 is a 4x3 matrix RGB LED driver with an autonomous animation engine and time-cross-multiplexing (TCM) support for up to 12 LEDs or 4 RGB LEDs. Each LED can be configured through the related registers to realize vivid and fancy lighting effects. This patch adds minimal driver support for the LP5812, implementing only the essential functionality: I2C communication with the device, LED registration, brightness control in manual mode, and basic sysfs interfaces for LED configuration and fault monitoring. Signed-off-by: Nam Tran <trannamatk@gmail.com> Link: https://patch.msgid.link/20260115161013.40706-2-trannamatk@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-02-04leds: qcom-lpg: Check the return value of regmap_bulk_write()Haotian Zhang
The lpg_lut_store() function currently ignores the return value of regmap_bulk_write() and always returns 0. This can cause hardware write failures to go undetected, leading the caller to believe LUT programming succeeded when it may have failed. Check the return value of regmap_bulk_write() in lpg_lut_store and return the error to the caller on failure. Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Link: https://patch.msgid.link/20260108175133.638-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones <lee@kernel.org>
2026-02-04leds: lp55xx: Simplify with scoped for each OF child loopKrzysztof Kozlowski
Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20251224124521.208635-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-02-04leds: is31f132xx: Add support for is31fl3293Daniel Mack
This chip supports 3 LED channels with 4096 possible PWM values. Extend the driver to support this variant: * Make brightness steps configurable per device type * Handle dual-register brightness updates * Allow to specify values to write into the PWM update register * Add custom init and shutdown function for 3293 variant * Init registers after parsing DT properties Signed-off-by: Daniel Mack <daniel@zonque.org> Link: https://patch.msgid.link/20251219154521.643312-4-daniel@zonque.org Signed-off-by: Lee Jones <lee@kernel.org>
2026-02-04leds: is31f132xx: Re-order code to remove forward declarationsDaniel Mack
Move the chipdef structs after the functions they reference so that forward declarations become unnecessary. Signed-off-by: Daniel Mack <daniel@zonque.org> Link: https://patch.msgid.link/20251219154521.643312-3-daniel@zonque.org Signed-off-by: Lee Jones <lee@kernel.org>
2026-02-04leds: expresswire: Fix chip state breakageDuje Mihanović
It is possible to put the KTD2801 chip in an unknown/undefined state by changing the brightness very rapidly (for example, with a brightness slider). When this happens, the brightness is stuck on max and cannot be changed until the chip is power cycled. Fix this by disabling interrupts while talking to the chip. While at it, make expresswire_power_off() use fsleep() and also unexport some functions meant to be internal. Fixes: 1368d06dd2c9 ("leds: Introduce ExpressWire library") Tested-by: Karel Balej <balejk@matfyz.cz> Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz> Link: https://patch.msgid.link/20251217-expresswire-fix-v2-1-4a02b10acd96@dujemihanovic.xyz Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-20leds: led-class: Only Add LED to leds_list when it is fully readyHans de Goede
Before this change the LED was added to leds_list before led_init_core() gets called adding it the list before led_classdev.set_brightness_work gets initialized. This leaves a window where led_trigger_register() of a LED's default trigger will call led_trigger_set() which calls led_set_brightness() which in turn will end up queueing the *uninitialized* led_classdev.set_brightness_work. This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by snd_ctl_led.ko in quick succession. The first led_classdev_register() causes an async modprobe of snd_ctl_led to run and that async modprobe manages to exactly hit the window where the second LED is on the leds_list without led_init_core() being called for it, resulting in: ------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Close the race window by moving the adding of the LED to leds_list to after the led_init_core() call. Cc: stable@vger.kernel.org Fixes: d23a22a74fde ("leds: delay led_set_brightness if stopping soft-blink") Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Reviewed-by: Sebastian Reichel <sre@kernel.org> Link: https://patch.msgid.link/20251211163727.366441-1-johannes.goede@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-08leds: lm3692x: Fix kernel-doc for struct lm3692x_ledVivek BalachandharTN
Building with W=1 reports several kernel-doc warnings in drivers/leds/leds-lm3692x.c: Warning: leds-lm3692x.c:122 struct member 'boost_ctrl' not described in 'lm3692x_led' Warning: leds-lm3692x.c:122 struct member 'brightness_ctrl' not described in 'lm3692x_led' Warning: leds-lm3692x.c:122 struct member 'enabled' not described in 'lm3692x_led' These fields were added to struct lm3692x_led but the corresponding kernel-doc comment was not updated. Convert the kernel-doc block to use the "@member: description" style consistently and document the boost_ctrl, brightness_ctrl and enabled fields. This keeps the documentation in sync with the implementation and silences the W=1 warnings. Signed-off-by: Vivek BalachandharTN <vivek.balachandhar@gmail.com> Link: https://patch.msgid.link/20251201042612.2099239-1-vivek.balachandhar@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-12-05Merge tag 'soc-drivers-6.19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull SoC driver updates from Arnd Bergmann: "This is the first half of the driver changes: - A treewide interface change to the "syscore" operations for power management, as a preparation for future Tegra specific changes - Reset controller updates with added drivers for LAN969x, eic770 and RZ/G3S SoCs - Protection of system controller registers on Renesas and Google SoCs, to prevent trivially triggering a system crash from e.g. debugfs access - soc_device identification updates on Nvidia, Exynos and Mediatek - debugfs support in the ST STM32 firewall driver - Minor updates for SoC drivers on AMD/Xilinx, Renesas, Allwinner, TI - Cleanups for memory controller support on Nvidia and Renesas" * tag 'soc-drivers-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (114 commits) memory: tegra186-emc: Fix missing put_bpmp Documentation: reset: Remove reset_controller_add_lookup() reset: fix BIT macro reference reset: rzg2l-usbphy-ctrl: Fix a NULL vs IS_ERR() bug in probe reset: th1520: Support reset controllers in more subsystems reset: th1520: Prepare for supporting multiple controllers dt-bindings: reset: thead,th1520-reset: Add controllers for more subsys dt-bindings: reset: thead,th1520-reset: Remove non-VO-subsystem resets reset: remove legacy reset lookup code clk: davinci: psc: drop unused reset lookup reset: rzg2l-usbphy-ctrl: Add support for RZ/G3S SoC reset: rzg2l-usbphy-ctrl: Add support for USB PWRRDY dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3S support reset: eswin: Add eic7700 reset driver dt-bindings: reset: eswin: Documentation for eic7700 SoC reset: sparx5: add LAN969x support dt-bindings: reset: microchip: Add LAN969x support soc: rockchip: grf: Add select correct PWM implementation on RK3368 soc/tegra: pmc: Add USB wake events for Tegra234 amba: tegra-ahb: Fix device leak on SMMU enable ...
2025-11-20leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWMFenglin Wu
The PWM signal from the LPG channel can be routed to PMIC GPIOs with proper GPIO configuration, and it is not necessary to enable the TRILED channel in that case. This also applies to the LPG channels that mapped to TRILED channels. Additionally, enabling the TRILED channel unnecessarily would cause a voltage increase in its power supply. Hence remove it. Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG") Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Link: https://patch.msgid.link/20251119-lpg_triled_fix-v3-2-84b6dbdc774a@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-20leds: rgb: leds-qcom-lpg: Allow LED_COLOR_ID_MULTIKonrad Dybcio
There's nothing special about RGB multi-led instances. Allow any color combinations by simply extending the "if _RGB" checks. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: David Heidelberg <david@ixit.cz> Link: https://patch.msgid.link/20251117-topic-lpg_multi-v1-1-05604374a2dd@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-20leds: pwm: Reorder include files to alphabetic orderLI Qingwu
Reorder include files to alphabetic order to simplify maintenance No functional change. Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn> Link: https://patch.msgid.link/20251117054511.730246-3-Qing-wu.Li@leica-geosystems.com.cn Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-20leds: pwm: Add optional GPIO enable pin supportLI Qingwu
Add support for optional GPIO-based enable pin control to PWM LED driver. Some PWM LED driver chips like TPS92380 and LT3743 require a separate enable signal in addition to PWM control. Implement support for such GPIO control through the "enable-gpios" device tree property, activating the pin when LED brightness is non-zero and deactivating it when off. Tested on i.MX8MP EVK with TPS92380 LED driver chip Signed-off-by: LI Qingwu <Qing-wu.Li@leica-geosystems.com.cn> Link: https://patch.msgid.link/20251117054511.730246-2-Qing-wu.Li@leica-geosystems.com.cn Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-14syscore: Pass context data to callbacksThierry Reding
Several drivers can benefit from registering per-instance data along with the syscore operations. To achieve this, move the modifiable fields out of the syscore_ops structure and into a separate struct syscore that can be registered with the framework. Add a void * driver data field for drivers to store contextual data that will be passed to the syscore ops. Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-11-13leds: trigger: Replace use of system_wq() with system_percpu_wq()Marco Crivellari
Currently if a user enqueues a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistency cannot be addressed without refactoring the API. This patch continues the effort to refactor worqueue APIs, which has begun with the change introducing new workqueues and a new alloc_workqueue flag: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") system_wq should be the per-cpu workqueue, yet in this name nothing makes that clear, so replace system_wq with system_percpu_wq. The old wq (system_wq) will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20251105111924.141555-1-marco.crivellari@suse.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-13leds: led-class: Replace sprintf() with sysfs_emit() in sysfs show functionsThorsten Blum
Replace sprintf() with sysfs_emit() in sysfs show functions. sysfs_emit() is preferred to format sysfs output as it provides better bounds checking. No functional changes. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20251103120809.32834-1-thorsten.blum@linux.dev Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-13leds: netxbig: Fix GPIO descriptor leak in error pathsHaotian Zhang
The function netxbig_gpio_ext_get() acquires GPIO descriptors but fails to release them when errors occur mid-way through initialization. The cleanup callback registered by devm_add_action_or_reset() only runs on success, leaving acquired GPIOs leaked on error paths. Add goto-based error handling to release all acquired GPIOs before returning errors. Fixes: 9af512e81964 ("leds: netxbig: Convert to use GPIO descriptors") Suggested-by: Markus Elfring <Markus.Elfring@web.de> Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Link: https://patch.msgid.link/20251031021620.781-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-13leds: leds-lp50xx: Enable chip before any communicationChristian Hitz
If a GPIO is used to control the chip's enable pin, it needs to be pulled high before any i2c communication is attempted. Currently, the enable GPIO handling is not correct. Assume the enable GPIO is low when the probe function is entered. In this case the device is in SHUTDOWN mode and does not react to i2c commands. During probe the following sequence happens: 1. The call to lp50xx_reset() on line 548 has no effect as i2c is not possible yet. 2. Then - on line 552 - lp50xx_enable_disable() is called. As "priv->enable_gpio“ has not yet been initialized, setting the GPIO has no effect. Also the i2c enable command is not executed as the device is still in SHUTDOWN. 3. On line 556 the call to lp50xx_probe_dt() finally parses the rest of the DT and the configured priv->enable_gpio is set up. As a result the device is still in SHUTDOWN mode and not ready for operation. Split lp50xx_enable_disable() into distinct enable and disable functions to enforce correct ordering between enable_gpio manipulations and i2c commands. Read enable_gpio configuration from DT before attempting to manipulate enable_gpio. Add delays to observe correct wait timing after manipulating enable_gpio and before any i2c communication. Cc: stable@vger.kernel.org Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") Signed-off-by: Christian Hitz <christian.hitz@bbv.ch> Link: https://patch.msgid.link/20251028155141.1603193-1-christian@klarinett.li Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-06leds: Drop duplicate LEDS_EXPRESSWIRE configDuje Mihanović
While moving said config symbol out of the "if NEW_LEDS" block, I accidentally left a copy inside that block. Remove it. Reported-by: Randy Dunlap <rdunlap@infradead.org> Closes: https://lore.kernel.org/all/b6c481bb-e854-405e-a428-90301789fe20@infradead.org/ Fixes: 2cd0d1db31e7 ("leds: expresswire: Don't depend on NEW_LEDS") Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz> Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20250729-expresswire-dep-fix-v1-1-635cd4cc746b@dujemihanovic.xyz Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-06leds: leds-cros_ec: Skip LEDs without color componentsThomas Weißschuh
A user reports that on their Lenovo Corsola Magneton with EC firmware steelix-15194.270.0 the driver probe fails with EINVAL. It turns out that the power LED does not contain any color components as indicated by the following "ectool led power query" output: Brightness range for LED 1: red : 0x0 green : 0x0 blue : 0x0 yellow : 0x0 white : 0x0 amber : 0x0 The LED also does not react to commands sent manually through ectool and is generally non-functional. Instead of failing the probe for all LEDs managed by the EC when one without color components is encountered, silently skip those. Cc: stable@vger.kernel.org Fixes: 8d6ce6f3ec9d ("leds: Add ChromeOS EC driver") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://patch.msgid.link/20251028-cros_ec-leds-no-colors-v1-1-ebe13a02022a@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2025-11-06leds: leds-lp50xx: LP5009 supports 3 modules for a total of 9 LEDsChristian Hitz
LP5009 supports 9 LED outputs that are grouped into 3 modules. Cc: stable@vger.kernel.org Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") Signed-off-by: Christian Hitz <christian.hitz@bbv.ch> Link: https://patch.msgid.link/20251022063305.972190-1-christian@klarinett.li Signed-off-by: Lee Jones <lee@kernel.org>
2025-10-25leds: upboard: Fix module aliasThomas Richard
The module alias does not match the cell name defined in the MFD driver, preventing automatic loading when the driver is built as a module. So fix the module alias to ensure proper module auto-loading. Fixes: 0ef2929a0181 ("leds: Add AAEON UP board LED driver") Signed-off-by: Thomas Richard <thomas.richard@bootlin.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20251020-leds-upboard-fix-module-alias-v2-1-84ac5c3a1a81@bootlin.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-10-23leds: leds-lp50xx: Allow LED 0 to be added to module bankChristian Hitz
led_banks contains LED module number(s) that should be grouped into the module bank. led_banks is 0-initialized. By checking the led_banks entries for 0, un-set entries are detected. But a 0-entry also indicates that LED module 0 should be grouped into the module bank. By only iterating over the available entries no check for unused entries is required and LED module 0 can be added to bank. Cc: stable@vger.kernel.org Fixes: 242b81170fb8 ("leds: lp50xx: Add the LP50XX family of the RGB LED driver") Signed-off-by: Christian Hitz <christian.hitz@bbv.ch> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Link: https://patch.msgid.link/20251008123222.1117331-1-christian@klarinett.li Signed-off-by: Lee Jones <lee@kernel.org>
2025-10-21leds: lp55xx_common: Enable use without FW_LOADER_USER_HELPERSicelo A. Mhlongo
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-21leds: flash: Use fwnode_get_next_child_node() insteadSakari Ailus
fwnode_get_next_child_node() is now the same as fwnode_get_next_available_child_node() on all backends (OF, ACPI and swnode). In order to remove the available variants, switch the uses to non-available variants (device_get_next_child_node() in this case). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Lee Jones <lee@kernel.org>
2025-10-21leds: Use fwnode_for_each_child_node() insteadSakari Ailus
fwnode_for_each_child_node() is now the same as fwnode_for_each_available_child_node() on all backends (OF, ACPI and swnode). In order to remove the available variants, switch the uses to non-available variants. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-16leds: led-class: Add Device Tree support to led_get()Hans de Goede
Add 'name' argument to of_led_get() such that it can lookup LEDs in devicetree by either name or index. And use this modified function to add devicetree support to the generic (non devicetree specific) [devm_]led_get() function. This uses the standard devicetree pattern of adding a -names string array to map names to the indexes for an array of resources. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com> Link: https://lore.kernel.org/r/20250910-leds-v5-3-bb90a0f897d5@vinarskis.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-11leds: is31fl319x: Use devm_mutex_init()Christophe JAILLET
Use devm_mutex_init() instead of hand-writing it. This saves some LoC, improves readability and saves some space in the generated .o file. Before: ====== text data bss dec hex filename 20011 6752 128 26891 690b drivers/leds/leds-is31fl319x.o After: ===== text data bss dec hex filename 19715 6680 128 26523 679b drivers/leds/leds-is31fl319x.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/267aba6eab12be67c297fcd52fcf45a0856338bb.1757240150.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-02leds: leds-lp55xx: Use correct address for memory programmingAndrei Lalaev
Memory programming doesn't work for devices without page support. For example, LP5562 has 3 engines but doesn't support pages, the start address is changed depending on engine number. According to datasheet [1], the PROG MEM register addresses for each engine are as follows: Engine 1: 0x10 Engine 2: 0x30 Engine 3: 0x50 However, the current implementation incorrectly calculates the address of PROG MEM register using the engine index starting from 1: prog_mem_base = 0x10 LP55xx_BYTES_PER_PAGE = 0x20 Engine 1: 0x10 + 0x20 * 1 = 0x30 Engine 2: 0x10 + 0x20 * 2 = 0x50 Engine 3: 0x10 + 0x20 * 3 = 0x70 This results in writing to the wrong engine memory, causing pattern programming to fail. To correct it, the engine index should be decreased: Engine 1: 0x10 + 0x20 * 0 = 0x10 Engine 2: 0x10 + 0x20 * 1 = 0x30 Engine 3: 0x10 + 0x20 * 2 = 0x50 1 - https://www.ti.com/lit/ds/symlink/lp5562.pdf Fixes: 31379a57cf2f ("leds: leds-lp55xx: Generalize update_program_memory function") Signed-off-by: Andrei Lalaev <andrei.lalaev@anton-paar.com> Link: https://lore.kernel.org/r/20250820-lp5562-prog-mem-address-v1-1-8569647fa71d@anton-paar.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-02leds: qnap-mcu: Add support for the red and green status LEDsHeiko Stuebner
There is one more set of two LEDs on the qnap devices to indicate status. One LED is green, the other is red and while they occupy the same space on the front panel, they cannot be enabled at the same time. But they can interact via blink functions, the MCU can flash them alternately, going red -> green -> red -> ... either in 500ms or 1s intervals. They can of course also blink individually. Add specific LED functions for them and register them on probe. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250804114949.3127417-3-heiko@sntech.de Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-02leds: qnap-mcu: Fix state numbering for USB LEDHeiko Stuebner
The "@Cx" commands span a number of different functions, from the status and USB LEDs to the buzzer and power button. So change the USB-LED enum to start at 0 and adapt the offset accordingly to not suggest @CD would relate to the USB-LED - while in fact "@CD" is a state of the status LED. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250804114949.3127417-2-heiko@sntech.de Signed-off-by: Lee Jones <lee@kernel.org>
2025-08-18leds: flash: leds-qcom-flash: Add a separate register map for PMI8998Fenglin Wu
The 3-channel flash module in PMI8998 has several registers different than the others, such as: torch_clamp. Add different register fields for it. Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-2-9b83816437a3@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-08-18leds: flash: leds-qcom-flash: Update torch current clamp settingFenglin Wu
There is a register to clamp the flash current per LED channel when safety timer is disabled. It needs to be updated according to the maximum torch LED current setting to ensure the torch current won't be clamped unexpectedly. Fixes: 96a2e242a5dc ("leds: flash: Add driver to support flash LED module in QCOM PMICs") Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-1-9b83816437a3@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-08-18leds: max77705: Function return instead of variable assignmentLen Bao
Coverity noticed that assigning value -EINVAL to 'ret' in the if statement is useless because 'ret' is overwritten a few lines later. However, after inspect the code, this warning reveals that we need to return -EINVAL instead of the variable assignment. So, fix it. Coverity-id: 1646104 Fixes: aebb5fc9a0d8 ("leds: max77705: Add LEDs support") Signed-off-by: Len Bao <len.bao@gmx.us> Link: https://lore.kernel.org/r/20250727075649.34496-1-len.bao@gmx.us Signed-off-by: Lee Jones <lee@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-08 07:09:42 +0000