linux.git/drivers/leds/trigger, branch master Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git leds: trigger: netdev: Add support for tx_err and rx_err notification with LEDs 2024-08-01T12:40:01+00:00 Lukasz Majewski lukma@denx.de 2024-07-10T10:06:51+00:00 6b08d07cac64c0dcf1dbb4584bdf95d0f789a520 This patch provides support for enabling blinking of LEDs when RX or TX errors are detected. Approach taken in this patch is similar to one for TX or RX data transmission indication (i.e. TRIGGER_NETDEV_TX/RX attribute). One can inspect transmission errors with: ip -s link show eth0 Example LED configuration: cd /sys/devices/platform/amba_pl@0/a001a000.leds/leds/ echo netdev > mode:blue/trigger && \ echo eth0 > mode:blue/device_name && \ echo 1 > mode:blue/tx_err Signed-off-by: Lukasz Majewski <lukma@denx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240710100651.4059887-1-lukma@denx.de Signed-off-by: Lee Jones <lee@kernel.org> 
This patch provides support for enabling blinking of LEDs when RX or TX
errors are detected.

Approach taken in this patch is similar to one for TX or RX data
transmission indication (i.e. TRIGGER_NETDEV_TX/RX attribute).

One can inspect transmission errors with:
ip -s link show eth0

Example LED configuration:
cd /sys/devices/platform/amba_pl@0/a001a000.leds/leds/
echo netdev > mode:blue/trigger && \
echo eth0 > mode:blue/device_name && \
echo 1 > mode:blue/tx_err

Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240710100651.4059887-1-lukma@denx.de
Signed-off-by: Lee Jones <lee@kernel.org>
leds: trigger: input-events: Rewrite to fix a serious locking issue 2024-06-26T15:56:12+00:00 Hans de Goede hdegoede@redhat.com 2024-06-02T16:02:03+00:00 a031c814976012c7ab50a41165f3fdca524341a8 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> 
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>
leds: triggers: Flush pending brightness before activating trigger 2024-06-26T15:56:07+00:00 Thomas Weißschuh linux@weissschuh.net 2024-06-13T15:24:51+00:00 ab477b766edd3bfb6321a6e3df4c790612613fae 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> 
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>
leds: trigger: Add new LED Input events trigger 2024-06-21T10:57:17+00:00 Hans de Goede hdegoede@redhat.com 2024-05-31T13:59:10+00:00 6f963a20eed72b9abb54754cc935ce546b66b451 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> 
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>
leds: trigger: pattern: Add support for hrtimer 2024-05-02T16:32:01+00:00 Martin Kurbanov mmkurbanov@salutedevices.com 2024-04-16T20:18:05+00:00 aa172ba73948e2152e258ead7e9ddbd806e809b0 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> 
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>
leds: trigger: netdev: Remove not needed call to led_set_brightness in deactivate 2024-04-12T08:47:14+00:00 Heiner Kallweit hkallweit1@gmail.com 2024-04-05T20:53:08+00:00 1fe4f1bf60fdd2110480e8be8b084fcb2b1df656 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> 
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>
leds: trigger: audio: Remove this trigger 2024-03-28T10:40:24+00:00 Heiner Kallweit hkallweit1@gmail.com 2024-03-04T20:59:47+00:00 ab2ab9e69ef9734b875ce6d43fe3f9f90135daae Now that the audio trigger is fully integrated in sound/core/control_led.c, we can remove it here. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/1e339779-6d04-4392-8ea2-5592c0fd1aa2@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> 
Now that the audio trigger is fully integrated in
sound/core/control_led.c, we can remove it here.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/1e339779-6d04-4392-8ea2-5592c0fd1aa2@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
ALSA: control-led: Integrate mute led trigger 2024-03-28T10:39:50+00:00 Heiner Kallweit hkallweit1@gmail.com 2024-03-04T20:58:46+00:00 a24de38de8046c075777bd6b8a291ae1ee56f71c This driver is the only one calling ledtrig_audio_set(), therefore the LED audio trigger isn't usable standalone. So it makes sense to fully integrate LED audio triger handling here. The module aliases ensure that the driver is auto-loaded (if built as module) if a LED device has one of the two audio triggers as default trigger. In addition disable building the old audio mute LED trigger. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/107634e6-d9ad-4a9f-881d-1eb72ea1a5a7@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> 
This driver is the only one calling ledtrig_audio_set(), therefore
the LED audio trigger isn't usable standalone. So it makes sense
to fully integrate LED audio triger handling here.

The module aliases ensure that the driver is auto-loaded (if built
as module) if a LED device has one of the two audio triggers as
default trigger.

In addition disable building the old audio mute LED trigger.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/107634e6-d9ad-4a9f-881d-1eb72ea1a5a7@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
leds: trigger: netdev: Fix kernel panic on interface rename trig notify 2024-03-07T08:48:08+00:00 Christian Marangi ansuelsmth@gmail.com 2024-02-03T23:54:01+00:00 415798bc07dd1c1ae3a656aa026580816e0b9fe8 Commit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") in the various changes, reworked the way to set the LINKUP mode in commit cee4bd16c319 ("leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function. This changed the logic where, in the previous implementation the dev from the trigger event was used to check if the carrier was ok, but in the new implementation with the generic function, the dev in trigger_data is used instead. This is problematic and cause a possible kernel panic due to the fact that the dev in the trigger_data still reference the old one as the new one (passed from the trigger event) still has to be hold and saved in the trigger_data struct (done in the NETDEV_REGISTER case). On calling of get_device_state(), an invalid net_dev is used and this cause a kernel panic. To handle this correctly, move the call to get_device_state() after the new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER case) and correctly parse the new dev. Fixes: d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240203235413.1146-1-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> 
Commit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link
speed mode") in the various changes, reworked the way to set the LINKUP
mode in commit cee4bd16c319 ("leds: trigger: netdev: Recheck
NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function.

This changed the logic where, in the previous implementation the dev
from the trigger event was used to check if the carrier was ok, but in
the new implementation with the generic function, the dev in
trigger_data is used instead.

This is problematic and cause a possible kernel panic due to the fact
that the dev in the trigger_data still reference the old one as the
new one (passed from the trigger event) still has to be hold and saved
in the trigger_data struct (done in the NETDEV_REGISTER case).

On calling of get_device_state(), an invalid net_dev is used and this
cause a kernel panic.

To handle this correctly, move the call to get_device_state() after the
new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER
case) and correctly parse the new dev.

Fixes: d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240203235413.1146-1-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
leds: trigger: panic: Simplify led_trigger_set_panic 2024-03-07T08:48:01+00:00 Heiner Kallweit hkallweit1@gmail.com 2023-12-09T22:54:51+00:00 7eef64da0b0ad8e90409fc4aa80eb69c1b4bdd2c I don't see why we iterate over all triggers to find the panic trigger. We *are* the panic trigger. Therefore we also know that the panic trigger doesn't have an activate() hook. So we can simplify the code significantly. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Link: https://lore.kernel.org/r/84c0fa67-2f03-4474-aa75-914d65d88dd0@gmail.com Signed-off-by: Lee Jones <lee@kernel.org> 
I don't see why we iterate over all triggers to find the panic trigger.
We *are* the panic trigger. Therefore we also know that the panic
trigger doesn't have an activate() hook. So we can simplify the code
significantly.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Link: https://lore.kernel.org/r/84c0fa67-2f03-4474-aa75-914d65d88dd0@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>