user/sven/linux.git/drivers/leds, branch v6.16.1

leds: pca955x: Avoid potential overflow when filling default_label (take 2)

2025-08-15T14:39:03Z

[ Upstream commit 239afba8b9f3b0fcfd464d5ffeaed0ed4441c5a4 ] 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: bd3d14932923 ("leds: pca955x: Avoid potential overflow when filling default_label") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202506282159.TXfvorYl-lkp@intel.com/ Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20250630093906.1715800-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

leds: tps6131x: Add V4L2_FLASH_LED_CLASS dependency

2025-08-15T14:39:03Z

[ Upstream commit c3c38e80016548685e439b23999b4f0bd0ad7e05 ] 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: b338a2ae9b31 ("leds: tps6131x: Add support for Texas Instruments TPS6131X flash LED driver") Signed-off-by: Arnd Bergmann Reviewed-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://lore.kernel.org/r/20250620114440.4080938-1-arnd@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

leds: lp8860: Check return value of devm_mutex_init()

2025-08-15T14:38:46Z

[ Upstream commit 3b07bb900af7f43f13f9ff398b4c6ca1dee217cd ] 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: 87a59548af95 ("leds: lp8860: Use new mutex guards to cleanup function exits") Signed-off-by: Thomas Weißschuh Acked-by: Andrew Davis Acked-by: Lee Jones Signed-off-by: Boqun Feng Link: https://lore.kernel.org/r/20250617-must_check-devm_mutex_init-v7-2-d9e449f4d224@weissschuh.net Signed-off-by: Sasha Levin

treewide, timers: Rename from_timer() to timer_container_of()

2025-06-08T07:07:37Z

Move this API to the canonical timer_*() namespace. [ tglx: Redone against pre rc1 ] Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/all/aB2X0jCKQO56WdMt@gmail.com

Merge tag 'backlight-next-6.16' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight

2025-06-03T19:52:25Z

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()

leds: tps6131x: Add support for Texas Instruments TPS6131X flash LED driver

2025-05-22T08:24:51Z

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 Link: https://lore.kernel.org/r/20250514-leds-tps6131x-v5-2-a4fb9e7f2c47@emfend.at Signed-off-by: Lee Jones

leds: flash: Add support for flash/strobe duration

2025-05-14T08:25:09Z

Add support for the new V4L2_CID_FLASH_DURATION control to the LEDs driver. Signed-off-by: Richard Leitner Link: https://lore.kernel.org/r/20250507-ov9282-flash-strobe-v4-2-72b299c1b7c9@linux.dev Signed-off-by: Lee Jones

leds: rgb: leds-mt6370-rgb: Improve definition of some struct linear_range

2025-05-14T08:25:08Z

Use LINEAR_RANGE() instead of hand-writing it. It is more robust, should the layout of the structure change one day. Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/1ce4245107e0a51dce502a007a69899bda018d5f.1746197460.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones

leds: led-test: Provide tests for the lookup and get infrastructure

2025-05-14T08:25:07Z

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

leds: led-test: Fill out the registration test to cover more test cases

2025-05-14T08:25:06Z

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