summaryrefslogtreecommitdiff
path: root/drivers/leds
AgeCommit message (Collapse)Author
2025-09-16leds: led-class: Add Device Tree support to led_get()Hans de Goede
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>
2025-09-11leds: is31fl319x: Use devm_mutex_init()Christophe JAILLET
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>
2025-09-02leds: leds-lp55xx: Use correct address for memory programmingAndrei Lalaev
Memory programming doesn't work for devices without page support. For example, LP5562 has 3 engines but doesn't support pages, the start address is changed depending on engine number. According to datasheet [1], the PROG MEM register addresses for each engine are as follows: Engine 1: 0x10 Engine 2: 0x30 Engine 3: 0x50 However, the current implementation incorrectly calculates the address of PROG MEM register using the engine index starting from 1: prog_mem_base = 0x10 LP55xx_BYTES_PER_PAGE = 0x20 Engine 1: 0x10 + 0x20 * 1 = 0x30 Engine 2: 0x10 + 0x20 * 2 = 0x50 Engine 3: 0x10 + 0x20 * 3 = 0x70 This results in writing to the wrong engine memory, causing pattern programming to fail. To correct it, the engine index should be decreased: Engine 1: 0x10 + 0x20 * 0 = 0x10 Engine 2: 0x10 + 0x20 * 1 = 0x30 Engine 3: 0x10 + 0x20 * 2 = 0x50 1 - https://www.ti.com/lit/ds/symlink/lp5562.pdf Fixes: 31379a57cf2f ("leds: leds-lp55xx: Generalize update_program_memory function") Signed-off-by: Andrei Lalaev <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>
2025-09-02leds: qnap-mcu: Add support for the red and green status LEDsHeiko Stuebner
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>
2025-09-02leds: qnap-mcu: Fix state numbering for USB LEDHeiko Stuebner
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>
2025-08-18leds: flash: leds-qcom-flash: Add a separate register map for PMI8998Fenglin Wu
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>
2025-08-18leds: flash: leds-qcom-flash: Update torch current clamp settingFenglin Wu
There is a register to clamp the flash current per LED channel when safety timer is disabled. It needs to be updated according to the maximum torch LED current setting to ensure the torch current won't be clamped unexpectedly. Fixes: 96a2e242a5dc ("leds: flash: Add driver to support flash LED module in QCOM PMICs") Signed-off-by: Fenglin Wu <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>
2025-08-18leds: max77705: Function return instead of variable assignmentLen Bao
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: aebb5fc9a0d8 ("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>
2025-08-18leds: Kconfig: Fix spelling mistake "limitiation" -> "limitation"Colin Ian King
There is a spelling mistake in the LEDS_BD2606MVV config. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20250724112030.142121-1-colin.i.king@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-08-18leds: leds-is31fl32xx: Add support for is31fl3236aPawel Zalewski
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>
2025-08-07treewide: rename GPIO set callbacks back to their original namesBartosz Golaszewski
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>
2025-07-31Merge tag 'leds-next-6.17' of ↵Linus Torvalds
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
2025-07-29Merge tag 'locking-core-2025-07-29' of ↵Linus Torvalds
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
2025-07-18Revert "leds: trigger: netdev: Configure LED blink interval for HW offload"Daniel Golle
This reverts commit c629c972b310af41e9e072febb6dae9a299edde6. 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: c629c972b310a ("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>
2025-07-11leds: lp8860: Check return value of devm_mutex_init()Thomas Weißschuh
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 <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
2025-07-02leds: pca955x: Avoid potential overflow when filling default_label (take 2)Andy Shevchenko
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 <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>
2025-07-02leds: Unexport of_led_get()Andy Shevchenko
There are no users outside the module. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250630092639.1574860-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-01leds: tps6131x: Add V4L2_FLASH_LED_CLASS dependencyArnd Bergmann
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 <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>
2025-06-27leds: leds-lp50xx: Handle reg to get correct multi_indexJohan Adolfsson
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>
2025-06-17sysfs: treewide: switch back to attribute_group::bin_attrsThomas Weißschuh
The normal bin_attrs field can now handle const pointers. This makes the _new variant unnecessary. Switch all users back. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20250530-sysfs-const-bin_attr-final-v3-4-724bfcf05b99@weissschuh.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-13leds: flash: leds-qcom-flash: Fix registry access after re-bindKrzysztof Kozlowski
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: 96a2e242a5dc ("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>
2025-06-08treewide, timers: Rename from_timer() to timer_container_of()Ingo Molnar
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
2025-06-03Merge tag 'backlight-next-6.16' of ↵Linus Torvalds
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()
2025-05-22leds: tps6131x: Add support for Texas Instruments TPS6131X flash LED driverMatthias Fend
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>
2025-05-14leds: flash: Add support for flash/strobe durationRichard Leitner
Add support for the new V4L2_CID_FLASH_DURATION control to the LEDs driver. Signed-off-by: Richard Leitner <richard.leitner@linux.dev> Link: https://lore.kernel.org/r/20250507-ov9282-flash-strobe-v4-2-72b299c1b7c9@linux.dev Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: rgb: leds-mt6370-rgb: Improve definition of some struct linear_rangeChristophe JAILLET
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 <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/1ce4245107e0a51dce502a007a69899bda018d5f.1746197460.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: led-test: Provide tests for the lookup and get infrastructureLee Jones
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>
2025-05-14leds: led-test: Fill out the registration test to cover more test casesLee Jones
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>
2025-05-14leds: led-test: Remove standard error checking after KUNIT_ASSERT_*()Lee Jones
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>
2025-05-14leds: pca995x: Fix typo in pca995x_of_match's of_device_id entryJesse Karjalainen
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>
2025-05-14leds: Provide skeleton KUnit testing for the LEDs frameworkLee Jones
Apply a very basic implementation of KUnit LED testing. More tests / use-cases will be added steadily over time. CMD: tools/testing/kunit/kunit.py run --kunitconfig drivers/leds OUTPUT: [15:34:19] Configuring KUnit Kernel ... [15:34:19] 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 [15:34:22] Starting KUnit Kernel (1/1)... [15:34:22] ============================================================ Running tests with: $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt [15:34:23] ===================== led (1 subtest) ====================== [15:34:23] [PASSED] led_test_class_register [15:34:23] ======================= [PASSED] led ======================= [15:34:23] ============================================================ [15:34:23] Testing complete. Ran 1 tests: passed: 1 [15:34:23] Elapsed time: 4.268s total, 0.001s configuring, 3.048s building, 1.214s running Link: https://lore.kernel.org/r/20250424144544.1438584-1-lee@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: tca6507: Use new GPIO line value setter callbacksBartosz Golaszewski
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>
2025-05-14leds: pca9532: Use new GPIO line value setter callbacksBartosz Golaszewski
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>
2025-05-14leds: pca955x: Use new GPIO line value setter callbacksBartosz Golaszewski
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>
2025-05-14leds: lgm-sso: Use new GPIO line value setter callbacksBartosz Golaszewski
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>
2025-05-14leds: Do not enable by default during compile testingKrzysztof Kozlowski
Enabling the compile test should not cause automatic enabling of all drivers, but only allow to choose to compile them. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250417074656.81626-1-krzysztof.kozlowski@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: turris-omnia: Drop commas in the terminator entriesMarek Behún
Drop commas in terminator entries of `struct attribute` array and `struct of_device_id` array. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20250417070507.24929-1-kabel@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: lp8860: Disable GPIO with devm actionAndrew Davis
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>
2025-05-14leds: lp8860: Only unlock in lp8860_unlock_eeprom()Andrew Davis
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>
2025-05-14leds: lp8860: Enable regulator using enable_optional helperAndrew Davis
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>
2025-05-14leds: lp8860: Remove default regs when not cachingAndrew Davis
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>
2025-05-14leds: lp8860: Use new mutex guards to cleanup function exitsAndrew Davis
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>
2025-05-14leds: lp8860: Use regmap_multi_reg_write for EEPROM writesAndrew Davis
This helper does the same thing as manual looping, use it instead. Signed-off-by: Andrew Davis <afd@ti.com> Link: https://lore.kernel.org/r/20250407183555.409687-1-afd@ti.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-14leds: pca955x: Avoid potential overflow when filling default_labelAndy Shevchenko
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>
2025-05-14leds: multicolor: Fix intensity setting while SW blinkingSven Schwermer
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>
2025-04-15leds: leds-cros_ec: Avoid -Wflex-array-member-not-at-end warningGustavo A. R. Silva
-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>
2025-04-15leds: core: Bail out when composed name can't fit the bufferAndy Shevchenko
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>
2025-04-15leds: led-triggers: Improvements for default triggerCraig McQueen
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>
2025-04-10leds: backlight trigger: Replace fb events with a dedicated function callThomas Zimmermann
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>
2025-04-10leds: backlight trigger: Move blank-state handling into helperThomas Zimmermann
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>
generated by cgit v1.2.3 (git 2.46.0) at 2025-10-06 14:58:52 +0000