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>
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: 31379a57cf ("leds: leds-lp55xx: Generalize update_program_memory function")
Signed-off-by: Andrei Lalaev <andrei.lalaev@anton-paar.com>
Link: https://lore.kernel.org/r/20250820-lp5562-prog-mem-address-v1-1-8569647fa71d@anton-paar.com
Signed-off-by: Lee Jones <lee@kernel.org>
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 <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250804114949.3127417-3-heiko@sntech.de
Signed-off-by: Lee Jones <lee@kernel.org>
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 <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250804114949.3127417-2-heiko@sntech.de
Signed-off-by: Lee Jones <lee@kernel.org>
Coverity noticed that assigning value -EINVAL to 'ret' in the if
statement is useless because 'ret' is overwritten a few lines later.
However, after inspect the code, this warning reveals that we need to
return -EINVAL instead of the variable assignment. So, fix it.
Coverity-id: 1646104
Fixes: aebb5fc9a0 ("leds: max77705: Add LEDs support")
Signed-off-by: Len Bao <len.bao@gmx.us>
Link: https://lore.kernel.org/r/20250727075649.34496-1-len.bao@gmx.us
Signed-off-by: Lee Jones <lee@kernel.org>
The conversion of all GPIO drivers to using the .set_rv() and
.set_multiple_rv() callbacks from struct gpio_chip (which - unlike their
predecessors - return an integer and allow the controller drivers to
indicate failures to users) is now complete and the legacy ones have
been removed. Rename the new callbacks back to their original names in
one sweeping change.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Pull LED updates from Lee Jones:
"Improvements & Fixes:
- A fix for QCOM Flash to prevent incorrect register access when the
driver is re-bound. This is solved by duplicating a static register
array during the probe function, which prevents register addresses
from being miscalculated after multiple binds
- The LP50xx driver now correctly handles the 'reg' property in
device tree child nodes to ensure the multi_index is set correctly.
This prevents issues where LEDs could be controlled incorrectly if
the device tree nodes were processed in a different order. An error
is returned if the reg property is missing or out of range
- Add a Kconfig dependency on between TPS6131x and
V4L2_FLASH_LED_CLASS to prevent a build failure when the driver is
built-in and the V4L2 flash infrastructure is a loadable module
- Fix a potential buffer overflow warning in PCA955x reported by
older GCC versions by using a more precise format specifier when
creating the default LED label.
Cleanups & Refactoring:
- Correct the MAINTAINERS file entry for the TPS6131X flash LED
driver to point to the correct device tree binding file name
- Fix a comment in the Flash Class for the flash_timeout setter to
"flash timeout" from "flash duration" for accuracy
- The of_led_get() function is no longer exported as it has no users
outside of its own module.
Removals:
- Revert the commit to configure LED blink intervals for hardware
offload in the Netdev Trigger. This change was found to break
existing PHY drivers by putting their LEDs into a permanent,
unconditional blinking state.
Device Tree Bindings Updates:
- Update the binding for LP50xx to document that the child reg
property is the index within the LED bank. The example was also
updated to use correct values
- Update the JNCP5623 binding to add 0x39 as a valid I2C address, as
it is used by the NCP5623C variant"
* tag 'leds-next-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds:
dt-bindings: leds: ncp5623: Add 0x39 as a valid I2C address
Revert "leds: trigger: netdev: Configure LED blink interval for HW offload"
leds: pca955x: Avoid potential overflow when filling default_label (take 2)
leds: Unexport of_led_get()
leds: tps6131x: Add V4L2_FLASH_LED_CLASS dependency
dt-bindings: leds: lp50xx: Document child reg, fix example
leds: leds-lp50xx: Handle reg to get correct multi_index
leds: led-class-flash:: Fix flash_timeout comment
MAINTAINERS: Adjust file entry in TPS6131X FLASH LED DRIVER
leds: flash: leds-qcom-flash: Fix registry access after re-bind
Pull locking updates from Ingo Molnar:
"Locking primitives:
- Mark devm_mutex_init() as __must_check and fix drivers that didn't
check the return code (Thomas Weißschuh)
- Reorganize <linux/local_lock.h> to better expose the internal APIs
to local variables (Sebastian Andrzej Siewior)
- Remove OWNER_SPINNABLE in rwsem (Jinliang Zheng)
- Remove redundant #ifdefs in the mutex code (Ran Xiaokai)
Lockdep:
- Avoid returning struct in lock_stats() (Arnd Bergmann)
- Change `static const` into enum for LOCKF_*_IRQ_* (Arnd Bergmann)
- Temporarily use synchronize_rcu_expedited() in
lockdep_unregister_key() to speed things up. (Breno Leitao)
Rust runtime:
- Add #[must_use] to Lock::try_lock() (Jason Devers)"
* tag 'locking-core-2025-07-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
lockdep: Speed up lockdep_unregister_key() with expedited RCU synchronization
locking/mutex: Remove redundant #ifdefs
locking/lockdep: Change 'static const' variables to enum values
locking/lockdep: Avoid struct return in lock_stats()
locking/rwsem: Use OWNER_NONSPINNABLE directly instead of OWNER_SPINNABLE
rust: sync: Add #[must_use] to Lock::try_lock()
locking/mutex: Mark devm_mutex_init() as __must_check
leds: lp8860: Check return value of devm_mutex_init()
spi: spi-nxp-fspi: Check return value of devm_mutex_init()
local_lock: Move this_cpu_ptr() notation from internal to main header
This driver can optionally use the v4l2_flash infrastructure, but fails to
link built=in if that is in a loadable module:
ld.lld-21: error: undefined symbol: v4l2_flash_release
>>> referenced by leds-tps6131x.c:792 (drivers/leds/flash/leds-tps6131x.c:792)
Add the usual Kconfig dependency for it, still allowing it to be built when
CONFIG_V4L2_FLASH_LED_CLASS is disabled.
Fixes: b338a2ae9b ("leds: tps6131x: Add support for Texas Instruments TPS6131X flash LED driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20250620114440.4080938-1-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
mc_subled used for multi_index needs well defined array indexes,
to guarantee the desired result, use reg for that.
If devicetree child nodes is processed in random or reverse order
you may end up with multi_index "blue green red" instead of the expected
"red green blue".
If user space apps uses multi_index to deduce how to control the leds
they would most likely be broken without this patch if devicetree
processing is reversed (which it appears to be).
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-fuji.dts has reg set
but I don't see how it can have worked without this change.
If reg is not set, an error is returned,
If reg is out of range, an error is returned.
reg within led child nodes starts with 0, to map to the iout in each bank.
Signed-off-by: Johan Adolfsson <johan.adolfsson@axis.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Link: https://lore.kernel.org/r/20250617-led-fix-v7-1-cdbe8efc88fa@axis.com
Signed-off-by: Lee Jones <lee@kernel.org>
Pull backlight updates from Lee Jones:
"Framebuffer Subsystem (fbdev):
- The display's blanking status is now tracked in 'struct fb_info'
- 'framebuffer_alloc()' initializes the blank state to FB_BLANK_UNBLANK
- 'register_framebuffer()' sets the state to 'FB_BLANK_POWERDOWN' if
an 'fb_blank' callback exists, ensuring 'FB_EVENT_BLANK' listeners
correctly see the display being turned on during the first modeset
- The 'FB_EVENT_BLANK' event data now includes both the new and the
old blank states
- 'fb_blank()' has been reworked to return early on errors, without
functional changes, in preparation for further state tracking
improvements
- Fbdev now calls dedicated functions in the backlight subsystems to
notify them of blank state changes, instead of relying on fbdev
event notifiers
- For LCDs, fbdev also calls a dedicated function to notify of mode
changes
- Removed the definitions for the unused fbdev event constants
'FB_EVENT_MODE_CHANGE' and 'FB_EVENT_BLANK' from the header file
Backlight Subsystem:
- Implemented fbdev blank state tracking using the (newly enhanced)
blank state information provided directly by 'FB_EVENT_BLANK'
- Removed internal blank state tracking fields ('fb_bl_on') from
'struct backlight_device'
- Moved the handling of blank-state updates into a separate internal
helper function, 'backlight_notify_blank()'
- Removed support for fbdev events and replaced it with a dedicated
function call interface ('backlight_notify_blank()' and
'backlight_notify_blank_all()') for display drivers to update
backlight status
LCD Subsystem:
- Moved the handling of display updates (blank events and mode
changes) from fbdev event notifiers to separate internal helper
functions ('lcd_notify_blank',
'lcd_notify_mode_change')
- Removed support for fbdev events and replaced it with dedicated
function call interfaces ('lcd_notify_blank_all()',
'lcd_notify_mode_change_all()')
- The LCD subsystem now maintains its own internal list of LCD
devices instead of relying on fbdev notifiers
LED Backlight Trigger:
- Moved the handling of blank-state updates into a separate internal
helper, 'ledtrig_backlight_notify_blank()'
- Removed support for fbdev events and replaced it with a dedicated
function call, 'ledtrig_backlight_blank()', for fbdev to notify
trigger of blank state changes
- The LED backlight trigger now maintains its own internal list of
triggers instead of relying on fbdev notifiers
Qualcomm WLED Backlight:
- Added a NULL check after 'devm_kasprintf()' in 'wled_configure()'
to prevent a potential NULL pointer dereference if memory
allocation fails"
* tag 'backlight-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight:
backlight: pm8941: Add NULL check in wled_configure()
fbdev: Remove constants of unused events
leds: backlight trigger: Replace fb events with a dedicated function call
leds: backlight trigger: Move blank-state handling into helper
backlight: lcd: Replace fb events with a dedicated function call
backlight: lcd: Move event handling into helpers
backlight: Replace fb events with a dedicated function call
backlight: Move blank-state handling into helper
backlight: Implement fbdev tracking with blank state from event
fbdev: Send old blank state in FB_EVENT_BLANK
fbdev: Track display blanking state
fbdev: Rework fb_blank()
The TPS61310/TPS61311 is a flash LED driver with I2C interface. Its power
stage is capable of supplying a maximum total current of roughly 1500mA.
The TPS6131x provides three constant-current sinks, capable of sinking up
to 2 x 400mA (LED1 and LED3) and 800mA (LED2) in flash mode. In torch mode
each sink (LED1, LED2, LED3) supports currents up to 175mA.
Signed-off-by: Matthias Fend <matthias.fend@emfend.at>
Link: https://lore.kernel.org/r/20250514-leds-tps6131x-v5-2-a4fb9e7f2c47@emfend.at
Signed-off-by: Lee Jones <lee@kernel.org>
This API allows providers to offer an specific LED to be looked-up by a
consumer. Consumers are then able to describe the aforementioned LED
and take a reference on it.
For convenience, we're testing both sides of the API in just one test
function here. In reality, both the provider and the consumer would be
logistically orthogonal.
CMD:
tools/testing/kunit/kunit.py run --kunitconfig drivers/leds
RESULTS:
[16:38:57] Configuring KUnit Kernel ...
[16:38:57] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=20
[16:39:02] Starting KUnit Kernel (1/1)...
[16:39:02] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[16:39:03] ===================== led (2 subtests) =====================
[16:39:03] [PASSED] led_test_class_register
[16:39:03] [PASSED] led_test_class_add_lookup_and_get
[16:39:03] ======================= [PASSED] led =======================
[16:39:03] ============================================================
[16:39:03] Testing complete. Ran 2 tests: passed: 2
[16:39:03] Elapsed time: 6.255s total, 0.001s configuring, 5.131s building, 1.106s running
Link: https://lore.kernel.org/r/20250501081918.3621432-3-lee@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Upon successful LED class device registration, it is expected that
certain attributes are filled out in pre-defined ways. For instance, if
provided, the .brightness_get() call-back should be called to populate
the class device 'brightness' attribute, 'max_brightness' should be
initialised as LED_FULL (at least until we can rid these pesky enums)
and the sysfs group should be created with the class device name
supplied by the caller.
If subsequent registrations take place that would result in name
conflicts, various outcomes are expected depending on which flags are
set. If LED_REJECT_NAME_CONFLICT is disabled, registration should
succeed resulting in an iteration on the provided name. Conversely, if
it's enabled, then registration is expected to fail outright.
We test for all of these scenarios here.
Link: https://lore.kernel.org/r/20250501081918.3621432-2-lee@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
If a KUNIT_ASSERT_*() call ends up in an assertion, the test is marked
as a failure and the subsequent error checking is never executed, making
it superfluous. Remove it for simplicity and to avoid confusion.
Link: https://lore.kernel.org/r/20250501081918.3621432-1-lee@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
This helps prevent mistakes like disable out of order in cleanup functions
and forgetting to free on error paths (as was done here).
This was the last thing the .remove() function did, so remove that too.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250407183555.409687-6-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
GCC compiler (Debian 14.2.0-17) is not happy about printing
into a too short buffer (when build with `make W=1`):
drivers/leds/leds-pca955x.c:554:33: note: ‘snprintf’ output between 2 and 12 bytes into a destination of size 8
Indeed, the buffer size is chosen based on some assumptions,
while in general the assigned value might not fit (GCC can't
prove it does).
Fix this by changing the bits field in the struct pca955x_chipdef to u8,
with a positive side effect of the better memory footprint, and convert
loop iterator to be unsigned. With that done, update format specifiers
accordingly.
In one case join back string literal as it improves the grepping over the code
based on the message and remove duplicating information (the driver name is
printed as pert of the dev_*() output [1]) as we touch the same line anyway.
Link: https://lore.kernel.org/r/4ac527f2-c59e-70a2-efd4-da52370ea557@dave.eu/ [1]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20250407151441.706378-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Replace an on-stack definition of a flexible structure with a call
to utility function cros_ec_cmd().
So, with these changes, fix the following warning:
drivers/leds/leds-cros_ec.c:70:40: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/Z-rKcgFjsyKvd58q@kspp
Signed-off-by: Lee Jones <lee@kernel.org>
GCC compiler complains about snprintf() calls that may potentially cut
the output:
drivers/leds/led-core.c:551:78: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
drivers/leds/led-core.c:554:78: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
...
Fix these by checking for the potential overflow. This requires
to align all the branches to use the same callee, i.e. snprintf(),
otherwise the code will be blown up and return different error codes
for the different branches.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20250318160524.2979982-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Accept "default" written to sysfs trigger attr.
If the text "default" is written to the LED's sysfs 'trigger' attr, then
call led_trigger_set_default() to set the LED to its default trigger.
If the default trigger is set to "none", then led_trigger_set_default()
will remove a trigger. This is in contrast to the default trigger being
unset, in which case led_trigger_set_default() does nothing.
Signed-off-by: Craig McQueen <craig@mcqueen.au>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Link: https://lore.kernel.org/r/20250317022630.424015-1-craig@mcqueen.au
Signed-off-by: Lee Jones <lee@kernel.org>
Remove support for fb events from the led backlight trigger. Provide
the helper ledtrig_backlight_blank() instead. Call it from fbdev to
inform the trigger of changes to a display's blank state.
Fbdev maintains a list of all installed notifiers. Instead of the fbdev
notifiers, maintain an internal list of led backlight triggers.
v3:
- export ledtrig_backlight_blank()
v2:
- maintain global list of led backlight triggers (Lee)
- avoid IS_REACHABLE() in source file (Lee)
- notify on changes to blank state instead of display state
- use lock guards
- initialize led list and list mutex
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://lore.kernel.org/r/20250321095517.313713-11-tzimmermann@suse.de
Signed-off-by: Lee Jones <lee@kernel.org>
