summaryrefslogtreecommitdiff
path: root/drivers/leds
AgeCommit message (Collapse)Author
2026-04-09leds: class: Make led_remove_lookup() NULL-awareAndy Shevchenko
It is a usual pattern in the kernel to make releasing functions be NULL-aware so they become a no-op. This helps reducing unneeded checks in the code where the given resource is optional. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260327102729.797254-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-31leds: led-class: Switch to using class_find_device_by_fwnode()Dmitry Torokhov
In preparation to class_find_device_by_of_node() going away switch to using class_find_device_by_fwnode(). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://patch.msgid.link/20260322-remove-device-find-by-of-node-v1-5-b72eb22a1215@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-26leds: Kconfig: Drop unneeded dependency on OF_GPIOBartosz Golaszewski
OF_GPIO is selected automatically on all OF systems. Any symbols it controls also provide stubs so there's really no reason to select it explicitly. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Link: https://patch.msgid.link/20260316-gpio-of-kconfig-v2-4-de2f4b00a0e4@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-26leds: lm3642: Use guard to simplify lockingRichard Lyu
The mutex_lock()/mutex_unlock() pattern requires explicitly pairing lock and unlock calls. Use guard(mutex) instead so the lock is automatically released when the scope exits. Convert to guard(mutex) in lm3642_torch_brightness_set(), lm3642_strobe_brightness_set(), and lm3642_indicator_brightness_set(). Add #include <linux/cleanup.h> to support scoped guards. Signed-off-by: Richard Lyu <richard.lyu@suse.com> Link: https://patch.msgid.link/20260320035451.31071-1-richard.lyu@suse.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-26leds: core: Fix formatting issuesDmitry Torokhov
Fix formatting issues reported by checkpatch.pl, such as extra empty lines, lack of braces on some branches, and misaligned function arguments. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://patch.msgid.link/20260311-led-swnode-name-v1-2-798a49e041c6@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-26leds: core: Implement fallback to software node name for LED namesDmitry Torokhov
If a software node defining an LED is missing explicit 'label', 'color', or 'function' properties, led_compose_name() currently fails with -EINVAL, because fallback to using node name in place of LED name/label is only implemented for OF nodes. Implement similar fallback for software nodes. Unlike OF nodes, which use the short 'name' attribute of the device tree node to avoid including the address block, use fwnode_get_name() directly since swnodes do not include an address block and always have a valid name. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Link: https://patch.msgid.link/20260311-led-swnode-name-v1-1-798a49e041c6@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-25leds: lgm-sso: Fix typo in macro for src offsetLukas Kraft
Replace unused argument pinc with used argument pin. Signed-off-by: Lukas Kraft <rebootrequired42@gmail.com> Link: https://patch.msgid.link/20260312210958.48467-1-rebootrequired42@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: Prefer IS_ERR_OR_NULL over manual NULL checkPhilipp Hahn
Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL check. Change generated with coccinelle. Signed-off-by: Philipp Hahn <phahn-oss@avm.de> Link: https://patch.msgid.link/20260310-b4-is_err_or_null-v1-51-bd63b656022d@avm.de Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: lp8860: Do not always program EEPROM on probeAndrew Davis
The EEPROM has limited writes and the contents might have factory set values that should not be changed. The values currently written by this driver are just one example of values, but might not be correct for many use-cases. Do not overwrite the EEPROM with these example values every probe. At some point it would be better to populate the content of the EEPROM based on a configuration provided by the user and check that the values in EEPROM are not already the same to avoid unneeded write cycles. That configuration would depend on how the device is used on the board to which it is attached, for that Device Tree might be the right way. Until a method can be devised, gate the EEPROM writing behind a module param. Reported-by: David Owens <daowens01@gmail.com> Signed-off-by: Andrew Davis <afd@ti.com> Link: https://patch.msgid.link/20260305203706.841384-5-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: lp8860: Remove unused read of STATUS registerAndrew Davis
This register is read but the contents are never checked, remove the read until we add status checking. While here add an error message should the preceding fault check fail. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://patch.msgid.link/20260305203706.841384-4-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: lp8860: Hold lock for all of EEPROM programmingAndrew Davis
The lock is taken while unlocking the EEPROM but then released, it should instead be held for the whole EEPROM programming process. To do this merge in the lp8860_unlock_eeprom() function to the only call site in the lp8860_init() function. This way we hold the lock for all steps. While here, rename this function to lp8860_program_eeprom() to better represent what it really does. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://patch.msgid.link/20260305203706.841384-3-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: lp8860: Return directly from lp8860_initAndrew Davis
No need to use goto to jump to a label that also just returns, return directly in the if statements. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://patch.msgid.link/20260305203706.841384-2-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: lp8860: Use a single regmap tableAndrew Davis
Instead of a regmap table each for the normal registers and the EEPROM registers, make one table and use an access table to prevent read/write to/from the registers between the two ranges. Slightly simplifies the code. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://patch.msgid.link/20260305203706.841384-1-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: lgm-sso: Remove duplicate assignments for priv->mmapChen Ni
Remove duplicate assignment of priv->mmap in intel_sso_led_probe(). Fixes: fba8a6f2263b ("leds: lgm-sso: Fix clock handling") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Link: https://patch.msgid.link/20260226033048.3715915-1-nichen@iscas.ac.cn Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: qcom-lpg: Check for array overflow when selecting the high resolutionGreg Kroah-Hartman
When selecting the high resolution values from the array, FIELD_GET() is used to pull from a 3 bit register, yet the array being indexed has only 5 values in it. Odds are the hardware is sane, but just to be safe, properly check before just overflowing and reading random data and then setting up chip values based on that. Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/2026021934-nearby-playroom-036b@gregkh Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: ktd2692: Make ktd2692_timing variable staticKrzysztof Kozlowski
File-scope 'ktd2692_timing' is not used outside of this unit, so make it static to silence sparse warning: leds-ktd2692.c:62:33: warning: symbol 'ktd2692_timing' was not declared. Should it be static? Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260216110441.160155-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: lp5569: Use sysfs_emit instead of sprintf()Neel Bullywon
Replace sprintf() with sysfs_emit(), which is the modern standard for formatting sysfs output. This change aligng with the kernel's best practices and ensures usage of the most up to date API. Signed-off-by: Neel Bullywon <neelb2403@gmail.com> Link: https://patch.msgid.link/20260207181825.13481-1-neelb2403@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-10leds: multicolor: Change intensity_value to unsigned intMichael Tretter
Using min to compare the intensity_value with led_dev->max_brightness causes a signedness error: drivers/leds/led-class-multicolor.c: In function 'multi_intensity_store': ././include/linux/compiler_types.h:630:45: error: call to '__compiletime_assert_195' declared with attribute error: min(intensity_value[i], led_cdev->max_brightness) signedness error Change the type of intensity_value to unsigned int to fix the signedness error. intensity_value is used to set mcled_cdev->subled_info[i].intensity, which is unsigned int, too. Fixes: 129f82752bce ("leds: multicolor: Limit intensity to max_brightness of LED") Signed-off-by: Michael Tretter <m.tretter@pengutronix.de> Link: https://patch.msgid.link/20260206-leds-multicolor-fix-signedness-error-v1-1-48a00ed33c07@pengutronix.de Signed-off-by: Lee Jones <lee@kernel.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>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-21 09:21:36 +0000