linux-stable.git/drivers/leds, branch v6.18.2

leds: rgb: leds-qcom-lpg: Don't enable TRILED when configuring PWM

2025-12-18T13:03:08+00:00

[ Upstream commit 072cd5f458d76b9e15d89ebdaea8b5cb1312eeef ]

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 
Reviewed-by: Bjorn Andersson 
Link: https://patch.msgid.link/20251119-lpg_triled_fix-v3-2-84b6dbdc774a@oss.qualcomm.com
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

leds: netxbig: Fix GPIO descriptor leak in error paths

2025-12-18T13:02:58+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: upboard: Fix module alias

2025-12-18T13:02:38+00:00

[ Upstream commit c06a017439110debd335b6864bc2d69835624235 ]

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 
Reviewed-by: Krzysztof Kozlowski 
Link: https://patch.msgid.link/20251020-leds-upboard-fix-module-alias-v2-1-84ac5c3a1a81@bootlin.com
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin

leds: led-class: Add Device Tree support to led_get()

2025-09-16T15:49:28+00:00

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 
Reviewed-by: Linus Walleij 
Signed-off-by: Hans de Goede 
Signed-off-by: Aleksandrs Vinarskis 
Link: https://lore.kernel.org/r/20250910-leds-v5-3-bb90a0f897d5@vinarskis.com
Signed-off-by: Lee Jones

leds: is31fl319x: Use devm_mutex_init()

2025-09-11T15:18:13+00:00

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 
Link: https://lore.kernel.org/r/267aba6eab12be67c297fcd52fcf45a0856338bb.1757240150.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones

leds: leds-lp55xx: Use correct address for memory programming

2025-09-02T12:26:25+00:00

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 
Link: https://lore.kernel.org/r/20250820-lp5562-prog-mem-address-v1-1-8569647fa71d@anton-paar.com
Signed-off-by: Lee Jones

leds: qnap-mcu: Add support for the red and green status LEDs

2025-09-02T07:54:46+00:00

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 
Link: https://lore.kernel.org/r/20250804114949.3127417-3-heiko@sntech.de
Signed-off-by: Lee Jones

leds: qnap-mcu: Fix state numbering for USB LED

2025-09-02T07:54:02+00:00

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 
Link: https://lore.kernel.org/r/20250804114949.3127417-2-heiko@sntech.de
Signed-off-by: Lee Jones

leds: flash: leds-qcom-flash: Add a separate register map for PMI8998

2025-08-18T08:49:12+00:00

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 
Reviewed-by: Konrad Dybcio 
Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-2-9b83816437a3@oss.qualcomm.com
Signed-off-by: Lee Jones

leds: flash: leds-qcom-flash: Update torch current clamp setting

2025-08-18T08:49:11+00:00

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 
Reviewed-by: Konrad Dybcio 
Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-1-9b83816437a3@oss.qualcomm.com
Signed-off-by: Lee Jones