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>
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 <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/267aba6eab12be67c297fcd52fcf45a0856338bb.1757240150.git.christophe.jaillet@wanadoo.fr
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>
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 <fenglin.wu@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-2-9b83816437a3@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
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: 96a2e242a5 ("leds: flash: Add driver to support flash LED module in QCOM PMICs")
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250729-fix-torch-clamp-issue-v2-1-9b83816437a3@oss.qualcomm.com
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>
Also add an additional and optional control register for setting the
output PWM frequency to 22kHz. The default is 3kHz and this option puts
the operational frequency outside of the audible range.
Signed-off-by: Pawel Zalewski <pzalewski@thegoodpenguin.co.uk>
Link: https://lore.kernel.org/r/20250723-leds-is31fl3236a-v6-3-210328058625@thegoodpenguin.co.uk
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>
- Improvements & Fixes
* A fix has been implemented in 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.
* A Kconfig dependency on between TPS6131x and V4L2_FLASH_LED_CLASS has been
added to prevent a build failure when the driver is built-in and the V4L2
flash infrastructure is a loadable module.
* A potential buffer overflow warning in PCA955x was reported by older GCC
versions has been fixed by using a more precise format specifier when
creating the default LED label.
- Cleanups & Refactoring
* The MAINTAINERS file entry for the TPS6131X flash LED driver has been
corrected to point to the correct device tree binding file name.
* A comment in the Flash Class for the flash_timeout setter has been
corrected 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
* The commit to configure LED blink intervals for hardware offload in the
Netdev Trigger has been reverted. This change was found to break existing
PHY drivers by putting their LEDs into a permanent, unconditional blinking
state.
- Device Tree Bindings Updates
* The binding for LP50xx has been updated to document that the child reg
property is the index within the LED bank. The example was also updated to
use correct values.
* The JNCP5623 binding has been updated to add 0x39 as a valid I2C address,
as it is used by the NCP5623C variant.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmiKNSgACgkQUa+KL4f8
d2GwyA//QyWJVRmx3iK64MWnMVHZxuFdXcilYXtYFGPdQNj/aqB51X8XeUDlpfDR
9YU9m+MZZJv4ku+BJNWMmilsOZmCSd2L0SjNcvg4EBagE7uCRGlc/zhSYQT99f4H
VvVTNRLaiY2JS4cLt5hQFccWSFFuVpHaDDr8lU6MnogPoUWm31PLP9oyjQZdw/3s
cEsSge6xhjQ48HLudp8t4o+OYt7SsiwGwua5dgLm65Cihiv2jI3c6xpTXsvk23Go
oIXpYRsUnPOh2FBhiBQYtwY4mtbfPL2EjfRBXoH8wPelVF+rqufwClp4GxolcbwR
VH9Xy1MtzW4Qe9SCV8t1UtsjzmGz1J+rO3NMCnGfYpCCwlrW0664P1tU90UDz7Uf
W8b5brD7tbJkW+29qfbxeCZE6hSYHqDh+0p+BLvQiN3Onv7xqozW1ODdVpAEjhLe
0okvY3WCkf0+dn08FVkQYuAmXQwYmKM2ylqr8LOlL/ESOK9vipEf48wRwPwm42VA
kDqdgy0J9N00sSD/iHXBHj6DjXVjjtrfJiOVLicfmRgTCPpm3UasPA9K7sVj5hZ3
TjDPPSY0MrTazMFf5AX7Q0nLEe/K7ZXK44xIn0pWw+loycmhrHNbFrcxS6D/BYV+
zkauHl/SKprLiVXWLYvyWjxLweHDO3LhKFjUQ6cOn+YZRdz5rSY=
=+8ND
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.17' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
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
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)
Signed-off-by: Ingo Molnar <mingo@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEBpT5eoXrXCwVQwEKEnMQ0APhK1gFAmiIbzURHG1pbmdvQGtl
cm5lbC5vcmcACgkQEnMQ0APhK1gxlRAAsnrbMN1yUbGbOh2fr7eQh69nn4VLZhvQ
n/Q2+ZpvgBQiPhUnYub4n0B03pO6lQO+taiAQ9WTK6VHi7kzIKIx0MPWP5KV9FCY
NQKQCmRccese0mmWVYccLPjyk6GW8l5gIhRK1vuEYANtLf/XLBYB/ygvE6a8ywNz
dmt7IzYOIknCuEtapDzcJLBZFHG9mVTT8Kk2A5aqn+XCrxNnKrYyVOH0qw395uBw
ulVKPJT7FGQ4qLkxfYguNWH5V1ZneN53tJouwqcM7Xpc+ookQFAZel0xlfWpVu+A
Q2WF3W8GOrS7ER9RzjG0SQF4qYBq60yKPZr3przmjCJFRgFdvEkMEIDvbirl0Gfv
Y04hMIcovsnh8x0iLTYxkrRxlZB/7jm5uLVJ1B6E19iYBXq1HCPkM51XugDQFxwz
fDSLblpRZLf9OoWT9NPiiQXpoSLigwOiFdiGimIMQHRbPKCujF2T9w4XpKLLECN4
UbYGMx/yAGdkTXelSStyru0ZLYhvxP2XMAaUJoMBrjI1ReL2e58Vmp2MqQcuhiuU
PV5NEt0qhBAjilUrP+vuM/27UihPxcBrVgvriT+wDVrrPiy1t5iJVOKxFcrkbMto
B+XHFA7z1EglkwGD7HCdoOFU8V3PM6+GNDMqvs5Ey3tifqampEssmYcP3YA6QYBt
eO7imScWtII=
=RExf
-----END PGP SIGNATURE-----
Merge tag 'locking-core-2025-07-29' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
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 reverts commit c629c972b3.
While .led_blink_set() would previously put an LED into an unconditional
permanently blinking state, the offending commit now uses same operation
to (also?) set the blink timing of the netdev trigger when offloading.
This breaks many if not all of the existing PHY drivers which offer
offloading LED operations, as those drivers would just put the LED into
blinking state after .led_blink_set() has been called.
Unfortunately the change even made it into stable kernels for unknown
reasons, so it should be reverted there as well.
Fixes: c629c972b3 ("leds: trigger: netdev: Configure LED blink interval for HW offload")
Link: https://lore.kernel.org/linux-leds/c6134e26-2e45-4121-aa15-58aaef327201@lunn.ch/T/#m9d6fe81bbcb273e59f12bbedbd633edd32118387
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/6dcc77ee1c9676891d6250d8994850f521426a0f.1752334655.git.daniel@makrotopia.org
Signed-off-by: Lee Jones <lee@kernel.org>
devm_mutex_init() can fail. With CONFIG_DEBUG_MUTEXES=y the mutex will be
marked as unusable and trigger errors on usage.
Add the missed check.
Fixes: 87a59548af ("leds: lp8860: Use new mutex guards to cleanup function exits")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Andrew Davis <afd@ti.com>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/r/20250617-must_check-devm_mutex_init-v7-2-d9e449f4d224@weissschuh.net
GCC compiler v8.5.0 is not happy about printing
into a too short buffer (when build with `make W=1`):
drivers/leds/leds-pca955x.c:696:5: note: 'snprintf' output between 2 and 11 bytes into a destination of size 8
Unfortunately this is a false positive from the old GCC versions,
but we may still improve the code by using '%hhu' format specifier
and reduce buffer size by 4 bytes.
Fixes: bd3d149329 ("leds: pca955x: Avoid potential overflow when filling default_label")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202506282159.TXfvorYl-lkp@intel.com/
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20250630093906.1715800-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
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>
Driver in probe() updates each of 'reg_field' with 'reg_base':
for (i = 0; i < REG_MAX_COUNT; i++)
regs[i].reg += reg_base;
'reg_field' array (under variable 'regs' above) is statically allocated,
thus each re-bind would add another 'reg_base' leading to bogus
register addresses. Constify the local 'reg_field' array and duplicate
it in probe to solve this.
Fixes: 96a2e242a5 ("leds: flash: Add driver to support flash LED module in QCOM PMICs")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250529063335.8785-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Move this API to the canonical timer_*() namespace.
[ tglx: Redone against pre rc1 ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com
* 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
* Qualcomm WLED Backlight:
* Added a NULL check after `devm_kasprintf()` in `wled_configure()` to prevent a
potential NULL pointer dereference if memory allocation fails
* Framebuffer Subsystem (fbdev):
* `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
* 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
* Framebuffer Subsystem (fbdev):
* Removed the definitions for the unused fbdev event constants
`FB_EVENT_MODE_CHANGE` and `FB_EVENT_BLANK` from the header file
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmg+xqwACgkQUa+KL4f8
d2EIgA//SGigE46rNLd1+s87V4latrf672BtTs+2sioAGY7f9nzEdntMjk7o9/2G
U//hJXP2Qr5WLdPVUQOi2ZZUMCks7sMgVx0KfCFiiYW8W0Vwhvl+17ZF3HLOqCCf
JdQ9m69B1ubdAuyxD91ad84lofZtYEjDw/gK95gNrTaLhx4s/T5G9MrDU+qlZs3y
npDhrnoQCclFcawSSDDhTUjiRcJFs3V1h3jUGi0Pz8PL1K/maR4fwgvw4ovkDjsR
5on6cBjpuQoxz1KqlauuSc6OKWZUq8OHrFl7T9YIbn5ACuq2z47XBO0uluCJjrip
MLvDCpxb7BcDRwcKDMZff6PWJMm4czVnNMgeGlQIUeIvZ/oD4CLCbas9BRYLiDpG
jIzQOk7TSLiZaPwZFNoxRMJFKdC63K9+dLmncpKuAGf9Lh7fYdDv2Ch605zy1Zxf
wumU9Bw2rj32iLaIUrsQHN6liIj41tHocRJHOUDkKb2fqzxq17+6NAe2qriRMHoS
n4Mp+FmKUeBothw5bgRUKRZP4ff8stM0mCDL7ChKxNqJi4Wal8ok+hg3jhNZfW+O
8ulSwrhJW/hjLrW29RyQIyB2Bz19H4/ZKdRjxfHgWgUdXQZLH5zBhtE0IISbdrBC
FiRtrDyeWN1btvatEp4CKeKi6gEO+ZktxsFr5Zi7IYIN685iyug=
=jhYi
-----END PGP SIGNATURE-----
Merge tag 'backlight-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight
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>
Remove the stray space between the '.' and the 'data' field name in
the PCA995x device-tree match table.
Signed-off-by: Jesse Karjalainen <jesse@ponkila.com>
Link: https://lore.kernel.org/r/20250426020454.47059-1-jesse@ponkila.com
Signed-off-by: Lee Jones <lee@kernel.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-4-2f42d8fbb525@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-3-2f42d8fbb525@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-2-2f42d8fbb525@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-1-2f42d8fbb525@linaro.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>
Locking is a single register write, so no need to have the unlock
function also lock. This removes the need to pass in the option
and reduces the nesting level in the function.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250407183555.409687-5-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
This allows the regulator to be optional which is the same as
done here with all the checks for NULL. This also disables
on remove for us, so remove the manual disabling.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250407183555.409687-4-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
If we are not using regmap caches, then the value will be read
in every time, having a default value does not change anything in
that case. Remove the unused defaults.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250407183555.409687-3-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
Use scoped mutex guards to simplify return paths. While here use
devm_mutex_init() to register the muxex so it also is cleaned
up automatically.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250407183555.409687-2-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>
When writing to the multi_intensity file, don't unconditionally call
led_set_brightness. By only doing this if blinking is inactive we
prevent blinking from stopping if the blinking is in its off phase while
the file is written.
Instead, if blinking is active, the changed intensity values are applied
upon the next blink. This is consistent with changing the brightness on
monochrome LEDs with active blinking.
Suggested-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Tobias Deiminger <tobias.deiminger@linutronix.de>
Tested-by: Sven Schuchmann <schuchmann@schleissheimer.de>
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
Link: https://lore.kernel.org/r/20250404184043.227116-1-sven@svenschwermer.de
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>
Move the handling of blank-state updates into a separate helper,
so that is can be called without the fbdev event. No functional
changes.
v2:
- rename helper to avoid renaming in a later patch (Lee)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Link: https://lore.kernel.org/r/20250321095517.313713-10-tzimmermann@suse.de
Signed-off-by: Lee Jones <lee@kernel.org>
Hans de Goede