kernel/git/stable/linux.git/drivers/leds, branch linux-5.10.y

leds: pca9532: Fix phantom device registration on missing hardware

2026-09-14T11:19:03+00:00

[ Upstream commit 8d6b6c05b8e33d11e3fb3203309385e1a9cceecd ] The initial PWM and PSC register writes in pca9532_configure() do not check the return values of i2c_smbus_write_byte_data(). If the I2C device is physically absent from the bus, the write fails with -ENXIO. However, the driver ignores this error and allows probe() to complete successfully. This results in the registration of phantom LED class devices and gpiochips backed by non-existent hardware. Subsequent GPIO reads from these phantom chips return bogus values (due to -ENXIO being truncated to an unsigned char in pca9532_gpio_get_value()), silently corrupting hardware state tracking in userspace. Propagate the I2C write failures back to probe() so the driver core can gracefully abort binding and release devres-managed resources. Fixes: e14fa82439d3 ("leds: Add pca9532 led driver") Signed-off-by: Cosmo Chou Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260715080747.1638097-1-chou.cosmo@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

leds: pca9532: Fix inverted GPIO output polarity

2026-09-14T11:18:57+00:00

[ Upstream commit 65a38a28a0b04af19a5e1fbf3869051412eeac96 ] The pca9532_gpio_set_value() function incorrectly mapped the requested value to PCA9532_ON and PCA9532_OFF, inverting the GPIO output polarity. A requested logical high (val=1) incorrectly enabled the LED output driver, which on this open-drain device pulls the pin low, while a requested logical low (val=0) released the pin. Correct the mapping so that val=1 yields PCA9532_OFF (pin released / high-impedance) and val=0 yields PCA9532_ON (pin driven low). pca9532_gpio_direction_input() is also updated to pass val=1 to pca9532_gpio_set_value() to align with the corrected polarity mapping, ensuring the pin remains not driven when configured as an input. Fixes: 3c1ab50d0a31 ("drivers/leds/leds-pca9532.c: add gpio capability") Signed-off-by: Cosmo Chou Reviewed-by: Bartosz Golaszewski Link: https://patch.msgid.link/20260703014201.69829-1-chou.cosmo@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

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

2026-07-24T13:49:22+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:49:22+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:49:10+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: led-class: Only Add LED to leds_list when it is fully ready

2026-02-06T15:40:06+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: Enable chip before any communication

2026-01-19T12:12:07+00:00

[ Upstream commit 434959618c47efe9e5f2e20f4a850caac4f6b823 ] 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 Link: https://patch.msgid.link/20251028155141.1603193-1-christian@klarinett.li Signed-off-by: Lee Jones Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

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

2026-01-19T12:12:07+00:00

[ Upstream commit 73bce575ed90c752eaa4b2b9a70860481d58d240 ] 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 stk3310_set_state() 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. Signed-off-by: Uwe Kleine-König Signed-off-by: Pavel Machek Stable-dep-of: 434959618c47 ("leds: leds-lp50xx: Enable chip before any communication") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

leds: lp50xx: Get rid of redundant check in lp50xx_enable_disable()

2026-01-19T12:12:07+00:00

[ Upstream commit 5d2bfb3fb95b2d448c0fbcaa2c58b215b2fa87fc ] Since GPIO is optional the API is NULL aware and will check descriptor anyway. Remove duplicate redundant check in lp50xx_enable_disable(). Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Stable-dep-of: 434959618c47 ("leds: leds-lp50xx: Enable chip before any communication") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

leds: lp50xx: Reduce level of dereferences

2026-01-19T12:12:07+00:00

[ Upstream commit 556f15fe023ec1d9f9cd2781ba6cd14bda650d22 ] The priv->dev is effectively the same as &priv->client->dev. So, drop the latter for the former. Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Stable-dep-of: 434959618c47 ("leds: leds-lp50xx: Enable chip before any communication") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman