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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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: 24e2d05d1b ("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>
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>
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: 1368d06dd2 ("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>
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: d23a22a74f ("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>
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>
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
...
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: 24e2d05d1b ("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>
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>
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>
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 128ea9f6cc ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566 ("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>
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: 9af512e819 ("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>
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: 242b81170f ("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>
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: 8d6ce6f3ec ("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>
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: 242b81170f ("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>
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>
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>
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>
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>
