kernel/linux.git/drivers/leds, branch v5.15.212

leds: lm3601x: Improve error reporting for problems during .remove()

2026-07-24T13:52:01+00:00

[ Upstream commit 22a23436891886a66d21af3619f4a4e8809f0e0a ] Returning an error value in an i2c remove callback results in a generic error message being emitted by the i2c core, but otherwise it doesn't make a difference. The device goes away anyhow and the devm cleanups are called. So instead of triggering the generic i2c error message, emit a more helpful message if a problem occurs and return 0 to suppress the generic message. This patch is a preparation for making i2c remove callbacks return void. Acked-by: Pavel Machek Signed-off-by: Uwe Kleine-König Signed-off-by: Wolfram Sang Stable-dep-of: 1f0bdc2884b6 ("usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

leds: lm3697: Remove duplicated error reporting in .remove()

2026-07-24T13:52:01+00:00

[ Upstream commit af89fa11fae1cee4e07453f780e6e5573ef0f477 ] Returning an error value from an i2c remove callback results in an error message being emitted by the i2c core, but otherwise it doesn't make a difference. The device goes away anyhow and the devm cleanups are called. As lm3697_remove() already emits an error message on failure and the additional error message by the i2c core doesn't add any useful information, don't pass the error value up the stack. Instead continue to clean up and return 0. This patch is a preparation for making i2c remove callbacks return void. Acked-by: Pavel Machek Signed-off-by: Uwe Kleine-König Signed-off-by: Wolfram Sang Stable-dep-of: 1f0bdc2884b6 ("usb: typec: ucsi: ccg: Fix use-after-free of ucsi on remove") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

leds: uleds: Fix potential buffer overread

2026-07-24T13:51:47+00:00

commit c19fe864f667afc49d1391d764e20b66555bcf7a upstream. The name string supplied by userspace is not guaranteed to be null-terminated, so using strchr() on it might result in a buffer overread. The same thing will happen when said string is used by the LED class device. Fix this by using strnchr() instead and explicitly check that the name string is properly null-terminated. Cc: stable@vger.kernel.org Fixes: e381322b0190 ("leds: Introduce userspace LED class driver") Signed-off-by: Armin Wolf Link: https://patch.msgid.link/20260524235553.189134-1-W_Armin@gmx.de Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman

leds: lgm-sso: Remove duplicate assignments for priv->mmap

2026-06-01T15:35:35+00:00

[ Upstream commit 7186d0330c3f3e86de577687a82f4ebd96dcb5ac ] Remove duplicate assignment of priv->mmap in intel_sso_led_probe(). Fixes: fba8a6f2263b ("leds: lgm-sso: Fix clock handling") Signed-off-by: Chen Ni Link: https://patch.msgid.link/20260226033048.3715915-1-nichen@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

leds: led-class: Only Add LED to leds_list when it is fully ready

2026-02-06T15:41:56+00:00

commit d1883cefd31752f0504b94c3bcfa1f6d511d6e87 upstream. 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 Reviewed-by: Sebastian Reichel Link: https://patch.msgid.link/20251211163727.366441-1-johannes.goede@oss.qualcomm.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman

leds: leds-lp50xx: LP5009 supports 3 modules for a total of 9 LEDs

2026-01-19T12:10:00+00:00

commit 5246e3673eeeccb4f5bf4f42375dd495d465ac15 upstream. 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 Link: https://patch.msgid.link/20251022063305.972190-1-christian@klarinett.li Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman

leds: leds-lp50xx: Allow LED 0 to be added to module bank

2026-01-19T12:10:00+00:00

commit 26fe74d598c32e7bc6f150edfc4aa43e1bee55db upstream. 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 Reviewed-by: Jacek Anaszewski Link: https://patch.msgid.link/20251008123222.1117331-1-christian@klarinett.li Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman

leds: netxbig: Fix GPIO descriptor leak in error paths

2026-01-19T12:09:29+00:00

[ Upstream commit 03865dd8af52eb16c38062df2ed30a91b604780e ] 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 Signed-off-by: Haotian Zhang Link: https://patch.msgid.link/20251031021620.781-1-vulab@iscas.ac.cn Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

leds: spi-byte: Use devm_led_classdev_register_ext()

2026-01-19T12:09:19+00:00

[ Upstream commit ccc35ff2fd2911986b716a87fe65e03fac2312c9 ] Use extended classdev registration to generate generic device names from color and function enums instead of reading only the label from the device tree. Signed-off-by: Stefan Kalscheuer Link: https://lore.kernel.org/r/20240204150726.29783-1-stefan@stklcode.de Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

leds: Replace all non-returning strlcpy with strscpy

2026-01-19T12:09:19+00:00

[ Upstream commit bf4a35e9201d30b63a8d276797d6ecfaa596ccd3 ] strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89 Signed-off-by: Azeem Shaikh Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20230523021451.2406362-1-azeemshaikh38@gmail.com Signed-off-by: Lee Jones Stable-dep-of: ccc35ff2fd29 ("leds: spi-byte: Use devm_led_classdev_register_ext()") Signed-off-by: Sasha Levin