summaryrefslogtreecommitdiff
path: root/drivers/leds
AgeCommit message (Collapse)AuthorFilesLines
2024-06-26leds: pca9532: Explicitly disable hardware blink when PWM1 is unavailableBastien Curutchet1-0/+9
When a LED is used to drive a beeper, it uses PWM1. This can cause conflicts if an other LED want to use PWM1 for blinking. Disable use of hardware for blinking when one or more LEDs are used to drive beepers. Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com> Link: https://lore.kernel.org/r/20240617143910.154546-4-bastien.curutchet@bootlin.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: pca9532: Use PWM1 for hardware blinkingBastien Curutchet1-10/+43
PSC0/PWM0 are used by all LEDs for brightness and blinking. This causes conflicts when you set a brightness of a new LED while an other one is already using PWM0 for blinking. Use PSC1/PWM1 for blinking. Check that no other LED is already blinking with a different PSC1/PWM1 configuration to avoid conflict. Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com> Link: https://lore.kernel.org/r/20240617143910.154546-3-bastien.curutchet@bootlin.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: pca9532: Use defines to select PWM instanceBastien Curutchet1-9/+12
Two tables are used to configure the PWM and PSC registers of the two PWM available in the pca9532. Magic numbers are used to access this table instead of defines. Add defines PCA9532_PWM_ID_0 and PCA9532_PWM_ID_1 and use them in place of these magic numbers. Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com> Link: https://lore.kernel.org/r/20240617143910.154546-2-bastien.curutchet@bootlin.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: trigger: input-events: Rewrite to fix a serious locking issueHans de Goede1-102/+34
The input subsystem registers LEDs with default triggers while holding the input_lock and input_register_handler() takes the input_lock this means that a triggers activate method cannot directly call input_register_handler() as the old ledtrig-input-events code is doing. The initial implementation of the input-events trigger mainly did not use the simple LED trigger mechanism because that mechanism had an issue with the initial state of a newly activated LED not matching the last led_trigger_event() call for the trigger. This issue has been fixed in commit 822c91e72eac ("leds: trigger: Store brightness set by led_trigger_event()"). Rewrite the "input-events" trigger to use the simple LED trigger mechanism, registering a single input_handler at module_init() time and using led_trigger_event() to set the brightness for all LEDs controlled by this trigger. Compared to the old code this looses the ability for the user to configure a different brightness for the on state then LED_FULL, this is standard for simple LED triggers and since this trigger is only in for-leds-next ATM losing that functionality is not a regression. This also changes the configurability of the LED off timeout from a per LED setting to a global setting (runtime modifiable module-parameter). Switching to registering a single input_handler at module_init() time fixes the following locking issue reported by lockdep: [ 2840.220145] usb 1-1.3: new low-speed USB device number 3 using xhci_hcd [ 2840.307172] usb 1-1.3: New USB device found, idVendor=0603, idProduct=0002, bcdDevice= 2.21 [ 2840.307375] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2840.307423] usb 1-1.3: Product: USB Composite Device [ 2840.307456] usb 1-1.3: Manufacturer: SINO WEALTH [ 2840.333985] input: SINO WEALTH USB Composite Device as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:0603:0002.0007/input/input19 [ 2840.386545] ====================================================== [ 2840.386549] WARNING: possible circular locking dependency detected [ 2840.386554] 6.10.0-rc1+ #97 Tainted: G C E [ 2840.386558] ------------------------------------------------------ [ 2840.386562] kworker/1:1/52 is trying to acquire lock: [ 2840.386566] ffff98fcf1629300 (&led_cdev->led_access){+.+.}-{3:3}, at: led_classdev_register_ext+0x1c6/0x380 [ 2840.386590] but task is already holding lock: [ 2840.386593] ffffffff88130cc8 (input_mutex){+.+.}-{3:3}, at: input_register_device.cold+0x47/0x150 [ 2840.386608] which lock already depends on the new lock. [ 2840.386611] the existing dependency chain (in reverse order) is: [ 2840.386615] -> #3 (input_mutex){+.+.}-{3:3}: [ 2840.386624] __mutex_lock+0x8c/0xc10 [ 2840.386634] input_register_handler+0x1c/0xf0 [ 2840.386641] 0xffffffffc142c437 [ 2840.386655] led_trigger_set+0x1e1/0x2e0 [ 2840.386661] led_trigger_register+0x170/0x1b0 [ 2840.386666] do_one_initcall+0x5e/0x3a0 [ 2840.386675] do_init_module+0x60/0x220 [ 2840.386683] __do_sys_init_module+0x15f/0x190 [ 2840.386689] do_syscall_64+0x93/0x180 [ 2840.386696] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 2840.386705] -> #2 (&led_cdev->trigger_lock){+.+.}-{3:3}: [ 2840.386714] down_write+0x3b/0xd0 [ 2840.386720] led_trigger_register+0x12c/0x1b0 [ 2840.386725] rfkill_register+0xec/0x340 [rfkill] [ 2840.386739] wiphy_register+0x82a/0x930 [cfg80211] [ 2840.386907] brcmf_cfg80211_attach+0xcbd/0x1430 [brcmfmac] [ 2840.386952] brcmf_attach+0x1ba/0x4c0 [brcmfmac] [ 2840.386991] brcmf_pcie_setup+0x899/0xc70 [brcmfmac] [ 2840.387030] brcmf_fw_request_done+0x13b/0x180 [brcmfmac] [ 2840.387070] request_firmware_work_func+0x3b/0x70 [ 2840.387078] process_one_work+0x21a/0x590 [ 2840.387085] worker_thread+0x1d1/0x3e0 [ 2840.387090] kthread+0xee/0x120 [ 2840.387096] ret_from_fork+0x30/0x50 [ 2840.387105] ret_from_fork_asm+0x1a/0x30 [ 2840.387112] -> #1 (leds_list_lock){++++}-{3:3}: [ 2840.387123] down_write+0x3b/0xd0 [ 2840.387129] led_classdev_register_ext+0x29e/0x380 [ 2840.387134] 0xffffffffc0e6b74c [ 2840.387143] platform_probe+0x40/0xa0 [ 2840.387151] really_probe+0xde/0x340 [ 2840.387157] __driver_probe_device+0x78/0x110 [ 2840.387162] driver_probe_device+0x1f/0xa0 [ 2840.387168] __driver_attach+0xba/0x1c0 [ 2840.387173] bus_for_each_dev+0x6b/0xb0 [ 2840.387180] bus_add_driver+0x111/0x1f0 [ 2840.387185] driver_register+0x6e/0xc0 [ 2840.387191] do_one_initcall+0x5e/0x3a0 [ 2840.387197] do_init_module+0x60/0x220 [ 2840.387204] __do_sys_init_module+0x15f/0x190 [ 2840.387210] do_syscall_64+0x93/0x180 [ 2840.387217] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 2840.387224] -> #0 (&led_cdev->led_access){+.+.}-{3:3}: [ 2840.387233] __lock_acquire+0x11c6/0x1f20 [ 2840.387239] lock_acquire+0xc8/0x2b0 [ 2840.387244] __mutex_lock+0x8c/0xc10 [ 2840.387251] led_classdev_register_ext+0x1c6/0x380 [ 2840.387256] input_leds_connect+0x139/0x260 [ 2840.387262] input_attach_handler.isra.0+0x75/0x90 [ 2840.387268] input_register_device.cold+0xa1/0x150 [ 2840.387274] hidinput_connect+0x848/0xb00 [ 2840.387280] hid_connect+0x567/0x5a0 [ 2840.387288] hid_hw_start+0x3f/0x60 [ 2840.387294] hid_device_probe+0x10d/0x190 [ 2840.387298] really_probe+0xde/0x340 [ 2840.387304] __driver_probe_device+0x78/0x110 [ 2840.387309] driver_probe_device+0x1f/0xa0 [ 2840.387314] __device_attach_driver+0x85/0x110 [ 2840.387320] bus_for_each_drv+0x78/0xc0 [ 2840.387326] __device_attach+0xb0/0x1b0 [ 2840.387332] bus_probe_device+0x94/0xb0 [ 2840.387337] device_add+0x64a/0x860 [ 2840.387343] hid_add_device+0xe5/0x240 [ 2840.387349] usbhid_probe+0x4bb/0x600 [ 2840.387356] usb_probe_interface+0xea/0x2b0 [ 2840.387363] really_probe+0xde/0x340 [ 2840.387368] __driver_probe_device+0x78/0x110 [ 2840.387373] driver_probe_device+0x1f/0xa0 [ 2840.387378] __device_attach_driver+0x85/0x110 [ 2840.387383] bus_for_each_drv+0x78/0xc0 [ 2840.387390] __device_attach+0xb0/0x1b0 [ 2840.387395] bus_probe_device+0x94/0xb0 [ 2840.387400] device_add+0x64a/0x860 [ 2840.387405] usb_set_configuration+0x5e8/0x880 [ 2840.387411] usb_generic_driver_probe+0x3e/0x60 [ 2840.387418] usb_probe_device+0x3d/0x120 [ 2840.387423] really_probe+0xde/0x340 [ 2840.387428] __driver_probe_device+0x78/0x110 [ 2840.387434] driver_probe_device+0x1f/0xa0 [ 2840.387439] __device_attach_driver+0x85/0x110 [ 2840.387444] bus_for_each_drv+0x78/0xc0 [ 2840.387451] __device_attach+0xb0/0x1b0 [ 2840.387456] bus_probe_device+0x94/0xb0 [ 2840.387461] device_add+0x64a/0x860 [ 2840.387466] usb_new_device.cold+0x141/0x38f [ 2840.387473] hub_event+0x1166/0x1980 [ 2840.387479] process_one_work+0x21a/0x590 [ 2840.387484] worker_thread+0x1d1/0x3e0 [ 2840.387488] kthread+0xee/0x120 [ 2840.387493] ret_from_fork+0x30/0x50 [ 2840.387500] ret_from_fork_asm+0x1a/0x30 [ 2840.387506] other info that might help us debug this: [ 2840.387509] Chain exists of: &led_cdev->led_access --> &led_cdev->trigger_lock --> input_mutex [ 2840.387520] Possible unsafe locking scenario: [ 2840.387523] CPU0 CPU1 [ 2840.387526] ---- ---- [ 2840.387529] lock(input_mutex); [ 2840.387534] lock(&led_cdev->trigger_lock); [ 2840.387540] lock(input_mutex); [ 2840.387545] lock(&led_cdev->led_access); [ 2840.387550] *** DEADLOCK *** [ 2840.387552] 7 locks held by kworker/1:1/52: [ 2840.387557] #0: ffff98fcc1d07148 ((wq_completion)usb_hub_wq){+.+.}-{0:0}, at: process_one_work+0x4af/0x590 [ 2840.387570] #1: ffffb67e00213e60 ((work_completion)(&hub->events)){+.+.}-{0:0}, at: process_one_work+0x1d5/0x590 [ 2840.387583] #2: ffff98fcc6582190 (&dev->mutex){....}-{3:3}, at: hub_event+0x57/0x1980 [ 2840.387596] #3: ffff98fccb3c6990 (&dev->mutex){....}-{3:3}, at: __device_attach+0x26/0x1b0 [ 2840.387610] #4: ffff98fcc5260960 (&dev->mutex){....}-{3:3}, at: __device_attach+0x26/0x1b0 [ 2840.387622] #5: ffff98fce3999a20 (&dev->mutex){....}-{3:3}, at: __device_attach+0x26/0x1b0 [ 2840.387635] #6: ffffffff88130cc8 (input_mutex){+.+.}-{3:3}, at: input_register_device.cold+0x47/0x150 [ 2840.387649] stack backtrace: [ 2840.387653] CPU: 1 PID: 52 Comm: kworker/1:1 Tainted: G C E 6.10.0-rc1+ #97 [ 2840.387659] Hardware name: Xiaomi Inc Mipad2/Mipad, BIOS MIPad-P4.X64.0043.R03.1603071414 03/07/2016 [ 2840.387665] Workqueue: usb_hub_wq hub_event [ 2840.387674] Call Trace: [ 2840.387681] <TASK> [ 2840.387689] dump_stack_lvl+0x68/0x90 [ 2840.387700] check_noncircular+0x10d/0x120 [ 2840.387710] ? register_lock_class+0x38/0x480 [ 2840.387717] ? check_noncircular+0x74/0x120 [ 2840.387727] __lock_acquire+0x11c6/0x1f20 [ 2840.387736] lock_acquire+0xc8/0x2b0 [ 2840.387743] ? led_classdev_register_ext+0x1c6/0x380 [ 2840.387753] __mutex_lock+0x8c/0xc10 [ 2840.387760] ? led_classdev_register_ext+0x1c6/0x380 [ 2840.387766] ? _raw_spin_unlock_irqrestore+0x35/0x60 [ 2840.387773] ? klist_next+0x158/0x160 [ 2840.387781] ? led_classdev_register_ext+0x1c6/0x380 [ 2840.387787] ? lockdep_init_map_type+0x58/0x250 [ 2840.387796] ? led_classdev_register_ext+0x1c6/0x380 [ 2840.387802] led_classdev_register_ext+0x1c6/0x380 [ 2840.387810] ? kvasprintf+0x70/0xb0 [ 2840.387820] ? kasprintf+0x3e/0x50 [ 2840.387829] input_leds_connect+0x139/0x260 [ 2840.387838] input_attach_handler.isra.0+0x75/0x90 [ 2840.387846] input_register_device.cold+0xa1/0x150 [ 2840.387854] hidinput_connect+0x848/0xb00 [ 2840.387862] ? usbhid_start+0x45b/0x7b0 [ 2840.387870] hid_connect+0x567/0x5a0 [ 2840.387878] ? __mutex_unlock_slowpath+0x2d/0x260 [ 2840.387891] hid_hw_start+0x3f/0x60 [ 2840.387899] hid_device_probe+0x10d/0x190 [ 2840.387906] ? __pfx___device_attach_driver+0x10/0x10 [ 2840.387913] really_probe+0xde/0x340 [ 2840.387919] ? pm_runtime_barrier+0x50/0x90 [ 2840.387927] __driver_probe_device+0x78/0x110 [ 2840.387934] driver_probe_device+0x1f/0xa0 [ 2840.387941] __device_attach_driver+0x85/0x110 [ 2840.387949] bus_for_each_drv+0x78/0xc0 [ 2840.387959] __device_attach+0xb0/0x1b0 [ 2840.387967] bus_probe_device+0x94/0xb0 [ 2840.387974] device_add+0x64a/0x860 [ 2840.387982] ? __debugfs_create_file+0x14a/0x1c0 [ 2840.387993] hid_add_device+0xe5/0x240 [ 2840.388002] usbhid_probe+0x4bb/0x600 [ 2840.388013] usb_probe_interface+0xea/0x2b0 [ 2840.388021] ? __pfx___device_attach_driver+0x10/0x10 [ 2840.388028] really_probe+0xde/0x340 [ 2840.388034] ? pm_runtime_barrier+0x50/0x90 [ 2840.388040] __driver_probe_device+0x78/0x110 [ 2840.388048] driver_probe_device+0x1f/0xa0 [ 2840.388055] __device_attach_driver+0x85/0x110 [ 2840.388062] bus_for_each_drv+0x78/0xc0 [ 2840.388071] __device_attach+0xb0/0x1b0 [ 2840.388079] bus_probe_device+0x94/0xb0 [ 2840.388086] device_add+0x64a/0x860 [ 2840.388094] ? __mutex_unlock_slowpath+0x2d/0x260 [ 2840.388103] usb_set_configuration+0x5e8/0x880 [ 2840.388114] ? __pfx___device_attach_driver+0x10/0x10 [ 2840.388121] usb_generic_driver_probe+0x3e/0x60 [ 2840.388129] usb_probe_device+0x3d/0x120 [ 2840.388137] really_probe+0xde/0x340 [ 2840.388142] ? pm_runtime_barrier+0x50/0x90 [ 2840.388149] __driver_probe_device+0x78/0x110 [ 2840.388156] driver_probe_device+0x1f/0xa0 [ 2840.388163] __device_attach_driver+0x85/0x110 [ 2840.388171] bus_for_each_drv+0x78/0xc0 [ 2840.388180] __device_attach+0xb0/0x1b0 [ 2840.388188] bus_probe_device+0x94/0xb0 [ 2840.388195] device_add+0x64a/0x860 [ 2840.388202] ? lockdep_hardirqs_on+0x78/0x100 [ 2840.388210] ? _raw_spin_unlock_irqrestore+0x35/0x60 [ 2840.388219] usb_new_device.cold+0x141/0x38f [ 2840.388227] hub_event+0x1166/0x1980 [ 2840.388242] process_one_work+0x21a/0x590 [ 2840.388249] ? move_linked_works+0x70/0xa0 [ 2840.388260] worker_thread+0x1d1/0x3e0 [ 2840.388268] ? __pfx_worker_thread+0x10/0x10 [ 2840.388273] kthread+0xee/0x120 [ 2840.388279] ? __pfx_kthread+0x10/0x10 [ 2840.388287] ret_from_fork+0x30/0x50 [ 2840.388294] ? __pfx_kthread+0x10/0x10 [ 2840.388301] ret_from_fork_asm+0x1a/0x30 [ 2840.388315] </TASK> [ 2840.415630] hid-generic 0003:0603:0002.0007: input,hidraw6: USB HID v1.10 Keyboard [SINO WEALTH USB Composite Device] on usb-0000:00:14.0-1.3/input0 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240602160203.27339-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: powernv: Replace of_node_put to __freeMarileneGarcia1-19/+9
Use __free for device_node values, and thus drop calls to of_node_put. The variable attribute __free adds a scope based cleanup to the device node. The goal is to reduce memory management issues in the kernel code. The of_node_put calls were removed, and the for_each_available_child_of_node was replaced to the equivalent for_each_available_child_of_node_scoped which use the __free. Suggested-by: Julia Lawall <julia.lawall@inria.fr> Signed-off-by: MarileneGarcia <marilene.agarcia@gmail.com> Link: https://lore.kernel.org/r/20240601031713.1307859-1-marilene.agarcia@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: mt6360: Fix memory leak in mt6360_init_isnk_properties()Javier Carrasco1-1/+4
The fwnode_for_each_child_node() loop requires manual intervention to decrement the child refcount in case of an early return. Add the missing calls to fwnode_handle_put(child) to avoid memory leaks in the error paths. Cc: stable@vger.kernel.org Fixes: 679f8652064b ("leds: Add mt6360 driver") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20240611-leds-mt6360-memleak-v1-1-93642eb5011e@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: tlc591xx: Replace of_node_put to __freeMarilene A Garcia1-11/+7
Use __free() for device_node values, and thus drop calls to of_node_put(). The variable attribute __free() adds a scope based cleanup to the device node. The goal is to reduce memory management issues in the kernel code. The for_each_available_child_of_node() was replaced to the equivalent for_each_available_child_of_node_scoped() which uses the __free(). Suggested-by: Julia Lawall <julia.lawall@inria.fr> Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com> Link: https://lore.kernel.org/r/20240611001740.10490-1-marilene.agarcia@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: rgb: leds-qcom-lpg: Add PPG check for setting/clearing PBS triggersAnjelique Melendez1-1/+7
Currently, all LED LPG devices will call lpg_{set,clear}_pbs_trigger() when setting brightness regardless of if they support PPG and have PBS triggers. Check if device supports PPG before setting/clearing PBS triggers. Fixes: 6ab1f766a80a ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM") Fixes: 5e9ff626861a ("leds: rgb: leds-qcom-lpg: Include support for PPG with dedicated LUT SDAM") Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20240607005250.4047135-1-quic_amelende@quicinc.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: triggers: Flush pending brightness before activating triggerThomas Weißschuh2-5/+6
The race fixed in timer_trig_activate() between a blocking set_brightness() call and trigger->activate() can affect any trigger. So move the call to flush_work() into led_trigger_set() where it can avoid the race for all triggers. Fixes: 0db37915d912 ("leds: avoid races with workqueue") Fixes: 8c0f693c6eff ("leds: avoid flush_work in atomic context") Cc: stable@vger.kernel.org Tested-by: Dustin L. Howett <dustin@howett.net> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-led-trigger-flush-v2-1-f4f970799d77@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: spi-byte: Move OF ID table closer to their userAndy Shevchenko1-7/+6
There is no code that uses ID table directly, except the struct device_driver at the end of the file. Hence, move table closer to its user. It's always possible to access them via a pointer. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240606173037.3091598-7-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: spi-byte: Use devm_mutex_init() for mutex initializationAndy Shevchenko1-20/+6
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240606173037.3091598-6-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: spi-byte: Utilise temporary variable for struct deviceAndy Shevchenko1-1/+1
We have a temporary variable to keep a pointer to struct device. Utilise it where it makes sense. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240606173037.3091598-5-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: spi-byte: Make use of device propertiesAndy Shevchenko2-9/+7
Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. Add mod_devicetable.h include. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240606173037.3091598-4-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: spi-byte: Get rid of custom led_init_default_state_get()Andy Shevchenko1-12/+5
LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240606173037.3091598-3-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: spi-byte: Call of_node_put() on error pathAndy Shevchenko1-1/+5
Add a missing call to of_node_put(np) on error. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240606173037.3091598-2-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: ncp5623: Use common error handling code in ncp5623_probe()Markus Elfring1-8/+8
Add a label so that a bit of exception handling can be better reused at the end of this function implementation. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Link: https://lore.kernel.org/r/5faec5de-fc36-4b38-abcb-c61954a824cd@web.de Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-26leds: core: Omit set_brightness error message for a LED supporting hw ↵Lee Jones1-6/+13
trigger only If both set_brightness functions return -ENOTSUPP, then the LED doesn't support setting a fixed brightness value, and the error message isn't helpful. This can be the case e.g. for LEDs supporting a specific hw trigger only. Pinched the subject line and commit message from Heiner: Link: https://lore.kernel.org/all/44177e37-9512-4044-8991-bb23b184bf37@gmail.com/ Reworked the function to provide Heiner's required semantics whilst simultaneously increasing readability and flow. Cc: Pavel Machek <pavel@ucw.cz> Cc: linux-leds@vger.kernel.org Suggested-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: trigger: Add new LED Input events triggerHans de Goede3-0/+250
Add a new trigger which turns LEDs on when there is input (/dev/input/event*) activity and turns them back off again after there has been no activity for 5 seconds. This is primarily intended to control LED devices which are a backlight for capacitive touch-buttons, such as e.g. the menu / home / back buttons found on the bottom bezel of many somewhat older smartphones and tablets. This can also be used to turn on the keyboard backlight LED on input events and turn the keyboard backlight off again when idle. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240531135910.168965-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: ss4200: Convert PCIBIOS_* return codes to errnosIlpo Järvinen1-2/+5
ich7_lpc_probe() uses pci_read_config_dword() that returns PCIBIOS_* codes. The error handling code assumes incorrectly it's a normal errno and checks for < 0. The return code is returned from the probe function as is but probe functions should return normal errnos. Remove < 0 from the check and convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal errno before returning it. Fixes: a328e95b82c1 ("leds: LED driver for Intel NAS SS4200 series (v5)") Cc: <stable@vger.kernel.org> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20240527132700.14260-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: bcm63138: Add MODULE_DESCRIPTION()Jeff Johnson1-0/+1
Fix the 'make W=1" issue: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/blink/leds-bcm63138.o Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240517-md-leds-bcm63138-v1-1-247b7302edb6@quicinc.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: simatic-ipc-leds: Add missing MODULE_DESCRIPTION() macrosJeff Johnson5-0/+5
Fix the 'make W=1' issues: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-apollolake.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-core.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-elkhartlake.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-f7188x.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds.o Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240517-md-simatic-ipc-v1-1-bbbd199262b8@quicinc.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: rt4505: Add MODULE_DESCRIPTION()Jeff Johnson1-0/+1
Fix the 'make W=1" issue: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/flash/leds-rt4505.o Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240517-md-leds-rt4505-v1-1-2f388ff6b672@quicinc.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: Drop explicit initialization of struct i2c_device_id::driver_data to 0Uwe Kleine-König15-17/+17
These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. While add it, also remove commas after the sentinel entries. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240522165358.62238-2-u.kleine-koenig@pengutronix.de Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: trigger: Call synchronize_rcu() before calling trig->activate()Hans de Goede1-0/+7
Some triggers call led_trigger_event() from their activate() callback to initialize the brightness of the LED for which the trigger is being activated. In order for the LED's initial state to be set correctly this requires that the led_trigger_event() call uses the new version of trigger->led_cdevs, which has the new LED. AFAICT led_trigger_event() will always use the new version when it is running on the same CPU as where the list_add_tail_rcu() call was made, which is why the missing synchronize_rcu() has not lead to bug reports. But if activate() is pre-empted, sleeps or uses a worker then the led_trigger_event() call may run on another CPU which may still use the old trigger->led_cdevs list. Add a synchronize_rcu() call to ensure that any led_trigger_event() calls done from activate() always use the new list. Triggers using led_trigger_event() from their activate() callback are: net/bluetooth/leds.c, net/rfkill/core.c and drivers/tty/vt/keyboard.c. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240531120124.75662-1-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: trigger: Unregister sysfs attributes before calling deactivate()Hans de Goede1-1/+1
Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback. Calling device_remove_groups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data. Move the device_remove_groups() call to before deactivate() to close this race window. This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling device_add_groups(). Fixes: a7e7a3156300 ("leds: triggers: add device attribute support") Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240504162533.76780-1-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: is31fl319x: Constify struct regmap_configChristophe JAILLET1-2/+2
'is31fl3190_regmap_config' and 'is31fl3196_regmap_config' are not modified in this diver and are only used as a const struct regmap_config. Constifying these structures moves some data to a read-only section, so increase overall security. On a x86_64, with allmodconfig: Before: text data bss dec hex filename 13827 2002 32 15861 3df5 drivers/leds/leds-is31fl319x.o After: text data bss dec hex filename 14467 1370 32 15869 3dfd drivers/leds/leds-is31fl319x.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/82a5cb26ff8af1865a790286bdbc3c4a2bd149f1.1714892598.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21Merge branches 'ib-leds-mfd-6.11', 'ib-leds-platform-power-6.11' and ↵Lee Jones6-39/+103
'ib-mfd-leds-platform-6.11' into ibs-for-leds-merged
2024-06-21leds: Add ChromeOS EC driverThomas Weißschuh3-0/+293
The ChromeOS Embedded Controller exposes an LED control command. Expose its functionality through the leds subsystem. The LEDs are exposed as multicolor devices. A hardware trigger, which is active by default, is provided to let the EC itself take over control over the LED. The driver is designed to be probed via the cros_ec mfd device. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-4-500b50f41e0f@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: core: Unexport led_colors[] arrayThomas Weißschuh2-3/+1
There are no external users left, make the array static. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-3-500b50f41e0f@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: multicolor: Use led_get_color_name() functionThomas Weißschuh1-1/+1
led_get_color_name() is a safer alternative to led_colors. led-class-multicolor.c is the only external user of led_colors and its removal allows unexporting the array. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-2-500b50f41e0f@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: core: Introduce led_get_color_name() functionThomas Weißschuh1-0/+9
This is similar to the existing led_colors[] array but is safer to use and usable by everyone. Getting string representations of color ids is useful for drivers which are handling color IDs anyways, for example for the multicolor API. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-1-500b50f41e0f@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-16leds: class: Revert: "If no default trigger is given, make hw_control ↵Hans de Goede1-6/+0
trigger the default trigger" Commit 66601a29bb23 ("leds: class: If no default trigger is given, make hw_control trigger the default trigger") causes ledtrig-netdev to get set as default trigger on various network LEDs. This causes users to hit a pre-existing AB-BA deadlock issue in ledtrig-netdev between the LED-trigger locks and the rtnl mutex, resulting in hung tasks in kernels >= 6.9. Solving the deadlock is non trivial, so for now revert the change to set the hw_control trigger as default trigger, so that ledtrig-netdev no longer gets activated automatically for various network LEDs. The netdev trigger is not needed because the network LEDs are usually under hw-control and the netdev trigger tries to leave things that way so setting it as the active trigger for the LED class device is a no-op. Fixes: 66601a29bb23 ("leds: class: If no default trigger is given, make hw_control trigger the default trigger") Reported-by: Genes Lists <lists@sapience.com> Closes: https://lore.kernel.org/all/9d189ec329cfe68ed68699f314e191a10d4b5eda.camel@sapience.com/ Reported-by: Johannes Wüller <johanneswueller@gmail.com> Closes: https://lore.kernel.org/lkml/e441605c-eaf2-4c2d-872b-d8e541f4cf60@gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-06-14leds: class: Add flag to avoid automatic renaming of LED devicesThomas Weißschuh1-0/+2
Add a mechanism for drivers to opt-out of the automatic device renaming on conflicts. Those drivers will provide their own conflict resolution. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240526-cros_ec-kbd-led-framework-v3-2-ee577415a521@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-14leds: class: Warn about name collisions earlierThomas Weißschuh1-4/+3
Other warnings refer to the name after renaming, which is clearer when that name is mentioned first. It is also clearer where "ret" comes from. While at it, also add the necessary newline to the message and fix the parameter alignment. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240526-cros_ec-kbd-led-framework-v3-1-ee577415a521@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-31leds: trigger: Add led_mc_trigger_event() functionHans de Goede1-0/+20
Add a new led_mc_trigger_event() function for triggers which want to change the color of a multi-color LED based on their trigger conditions. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531114124.45346-6-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-31leds: core: Add led_mc_set_brightness() functionHans de Goede2-0/+32
Add a new led_mc_set_brightness() function for in kernel color/brightness changing of multi-color LEDs. led-class-multicolor can be build as a module and led_mc_set_brightness() will have the builtin callers, so put led_mc_set_brightness() inside led-core instead, just like how led_set_brightness() is part of the core and not of the led-class object. This also adds a new LED_MULTI_COLOR led_classdev flag to allow led_mc_set_brightness() to verify that it is operating on a multi-color LED classdev, avoiding casting the passed in LED classdev to a multi-color LED classdev, when it actually is not a multi-color LED. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531114124.45346-5-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-31leds: rgb: leds-ktd202x: Initialize mutex earlierHans de Goede1-4/+4
The mutex must be initialized before the LED class device is registered otherwise there is a race where it may get used before it is initialized: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 2 PID: 2045 at kernel/locking/mutex.c:587 __mutex_lock ... RIP: 0010:__mutex_lock+0x7db/0xc10 ... set_brightness_delayed_set_brightness.part.0+0x17/0x60 set_brightness_delayed+0xf1/0x100 process_one_work+0x222/0x5a0 Move the mutex_init() call earlier to avoid this race condition and switch to devm_mutex_init() to avoid the need to add error-exit cleanup to probe() if probe() fails later on. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531114124.45346-4-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-31leds: rgb: leds-ktd202x: I2C ID tables for KTD2026 and 2027Kate Hsuan1-0/+8
Add an i2c_device_id id_table to match manually instantiated (non device-tree / ACPI instantiated) KTD202x controllers as found on some x86 boards. This table shows the maximum support LED channel for KTD2026 (three LEDs) and KTD-2027 (4 LEDs). Link: https://www.kinet-ic.com/uploads/KTD2026-7-04h.pdf Signed-off-by: Kate Hsuan <hpa@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240531114124.45346-3-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-31leds: rgb: leds-ktd202x: Get device properties through fwnode to support ACPIKate Hsuan2-31/+34
This LED controller is installed on a Xiaomi pad2 and it is an x86 platform. The original driver is based on the device tree and can't be used for this ACPI based system. This patch migrated the driver to use fwnode to access the properties. Moreover, the fwnode API supports the device tree so this work won't affect the original implementations. Signed-off-by: Kate Hsuan <hpa@redhat.com> Tested-by: André Apitzsch <git@apitzsch.eu> # on BQ Aquaris M5 Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240531114124.45346-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: mt6370: Remove unused field 'reg_cfgs' from 'struct mt6370_priv'Christophe JAILLET1-1/+0
In 'struct mt6370_priv', the 'reg_cfgs' field is unused. Moreover 'struct reg_cfg' isn't defined anywhere, so remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/e389be5e1012dc05fc2641123883ca3b0747525a.1714328839.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: lp50xx: Remove unused field 'num_of_banked_leds' from 'struct lp50xx'Christophe JAILLET1-4/+0
In 'struct lp50xx', the 'num_of_banked_leds' field is only written and is never used. Moreover, storing such an information in the 'priv' structure looks pointless, so remove it. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/a0d472ff587d13a2b91ec32c8776061019caab6a.1714324500.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: lp50xx: Remove unused field 'bank_modules' from 'struct lp50xx_led'Christophe JAILLET1-1/+0
In 'struct lp50xx_led', the 'bank_modules' field is unused. Remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/bc2e5e57b93ca0a33bcc84e9bdc89f26fc8f6d57.1714324500.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: aat1290: Remove unused field 'torch_brightness' from 'struct aat1290_led'Christophe JAILLET1-2/+0
In 'struct aat1290_led', the 'torch_brightness' field is unused. Remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/f7c8c22242544b11e95d9a77d7d0ea17f5a24fd5.1714318454.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: sun50i-a100: Use match_string() helper to simplify the codeAndy Shevchenko1-8/+6
match_string() returns the array index of a matching string. Use it instead of the open-coded implementation. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20240426152515.872917-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: pwm: Disable PWM when going to suspendUwe Kleine-König1-1/+7
On stm32mp1xx based machines (and others) a PWM consumer has to disable the PWM because an enabled PWM refuses to suspend. So check the LED_SUSPENDED flag and depending on that set the .enabled property. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218559 Fixes: 76fe464c8e64 ("leds: pwm: Don't disable the PWM when the LED should be off") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240417153846.271751-2-u.kleine-koenig@pengutronix.de Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: trigger: pattern: Add support for hrtimerMartin Kurbanov1-23/+103
Currently, led pattern trigger uses timer_list to schedule brightness changing. As we know from timer_list API [1], it's not accurate to milliseconds and depends on HZ granularity. Example: "0 10 0 0 50 10 50 0 100 10 100 0 150 10 150 0 200 10 200 0 250 10 250 0", we expect it to be 60ms long, but it can actually be up to ~120ms (add ~10ms for each pattern when HZ == 100). But sometimes, userspace needs time accurate led patterns to make sure that pattern will be executed during expected time slot. To achieve this goal the patch introduces optional hrtimer usage for led trigger pattern, because hrtimer is microseconds accurate timer. [1]: kernel/time/timer.c#L104 Signed-off-by: Martin Kurbanov <mmkurbanov@salutedevices.com> Link: https://lore.kernel.org/r/20240416201847.357099-1-mmkurbanov@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-12leds: mt6360: Fix the second LED can not enable torch mode by V4L2ChiaEn Wu1-1/+11
V4L2 will disable strobe mode of the LED device when enable torch mode, but this logic will conflict with the "priv->fled_torch_used" in "mt6360_strobe_set()". So after enabling torch mode of the first LED, the second LED will not be able to enable torch mode correctly. Therefore, at the beginning of "mt6360_strobe_set()", check whether the state of the upcoming change and the current LED device state are the same, so as to avoid the above problem. Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> Link: https://lore.kernel.org/r/28FE6F1712799128000.chiaen_wu@richtek.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-12leds: qcom-lpg: Add support for PMI8950 PWMGianluca Boiano1-0/+8
The PMI8950 PMIC contains 1 PWM channel Signed-off-by: Gianluca Boiano <morf3089@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240402-pmi8950-pwm-support-v1-1-1a66899eeeb3@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-12leds: apu: Remove duplicate DMI lookup dataArnd Bergmann1-2/+1
Building with W=1 shows a warning about an unused dmi_system_id table: drivers/leds/leds-apu.c:85:35: error: 'apu_led_dmi_table' defined but not used [-Werror=unused-const-variable=] 85 | static const struct dmi_system_id apu_led_dmi_table[] __initconst = { Since the current version doesn't even do anything about the different implementations but only checks the type of system, just drop the custom lookup logic and call dmi_check_system() using the table itself. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240403080702.3509288-16-arnd@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-12leds: trigger: netdev: Remove not needed call to led_set_brightness in ↵Heiner Kallweit1-2/+0
deactivate led_trigger_set() is the only caller of the deactivate() callback, and it calls led_set_brightness(LED_OFF) anyway after deactivate(). So we can remove the call here. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/8dc929e7-8e14-4c85-aa28-9c5fe2620f52@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-29 00:27:00 +0300