linux-stable.git/drivers/leds/trigger, branch v6.15 Linux kernel stable tree treewide: Switch/rename to timer_delete[_sync]() 2025-04-05T08:30:12+00:00 Thomas Gleixner tglx@linutronix.de 2025-04-05T08:17:26+00:00 8fa7292fee5c5240402371ea89ab285ec856c916 timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree over and remove the historical wrapper inlines. Conversion was done with coccinelle plus manual fixups where necessary. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> 
timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree
over and remove the historical wrapper inlines.

Conversion was done with coccinelle plus manual fixups where necessary.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Merge tag 'leds-next-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds 2025-03-29T21:42:59+00:00 Linus Torvalds torvalds@linux-foundation.org 2025-03-29T21:42:59+00:00 cb9b4c34031f8271cf6d6eedd2606e3c4b5e91ad Pull LED updates from Lee Jones: - pca955x: Add HW blink support, utilizing PWM0. It supports one frequency across all blinking LEDs and falls back to software blink if different frequencies are requested. - trigger: netdev: Allow configuring LED blink interval via .blink_set even when HW offload (.hw_control) is enabled. - led-core: Fix a race condition where a quick LED_OFF followed by another brightness set could leave the LED off incorrectly, especially noticeable after the introduction of the ordered workqueue. - qcom-lpg: Add support for 6-bit PWM resolution alongside the existing 9-bit support. - qcom-lpg: Fix PWM value capping to respect the selected resolution (6-bit or 9-bit) for normal PWMs. - qcom-lpg: Fix PWM value capping to respect the selected resolution for Hi-Res PWMs. - qcom-lpg: Fix calculation of the best period for Hi-Res PWMs to prevent requested duty cycles from exceeding the maximum allowed by the selected resolution. - st1202: Add a check for the error code returned by devm_mutex_init(). - pwm-multicolor: Add a check for the return value of fwnode_property_read_u32(). - st1202: Ensure hardware initialization (st1202_setup) happens before DT node processing (st1202_dt_init). - Kconfig: leds-st1202: Add select LEDS_TRIGGER_PATTERN as it's required by the driver. - lp8860: Drop unneeded explicit assignment to REGCACHE_NONE. - pca955x: Refactor code with helper functions and rename some functions/variables for clarity. - pca955x: Pass driver data pointers instead of the I2C client to helper functions. - pca955x: Optimize probe LED selection logic to reduce I2C operations. - pca955x: Revert the removal of pca95xx_num_led_regs() (renaming it to pca955x_num_led_regs) as it's needed for HW blink support. - st1202: Refactor st1202_led_set() to use the !! operator for boolean conversion. - st1202: Minor spacing and proofreading edits in comments. - Directory Rename: Rename the drivers/leds/simple directory to drivers/leds/simatic as the drivers within are not simple. - mlxcpld: Remove unused include of acpi.h. - nic78bx: Tidy up the ACPI ID table (remove ACPI_PTR, use mod_devicetable.h, remove explicit driver_data initializer). - tlc591xx: Convert text binding to YAML format, add child node constraints, and fix typos/formatting in the example. - qcom-lpg: Document the qcom,pm8937-pwm compatible string as a fallback for qcom,pm8916-pwm. * tag 'leds-next-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (23 commits) leds: nic78bx: Tidy up ACPI ID table leds: mlxcpld: Remove unused ACPI header inclusion leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs leds: rgb: leds-qcom-lpg: Fix pwm resolution max for normal PWMs leds: Rename simple directory to simatic leds: Kconfig: leds-st1202: Add select for required LEDS_TRIGGER_PATTERN leds: leds-st1202: Spacing and proofreading editing leds: leds-st1202: Initialize hardware before DT node child operations leds: pwm-multicolor: Add check for fwnode_property_read_u32 leds: rgb: leds-qcom-lpg: Add support for 6-bit PWM resolution leds: Fix LED_OFF brightness race Revert "leds-pca955x: Remove the unused function pca95xx_num_led_regs()" leds: st1202: Refactor st1202_led_set() to use !! operator for boolean conversion dt-bindings: leds: qcom-lpg: Document PM8937 PWM compatible leds: pca955x: Add HW blink support leds: pca955x: Optimize probe LED selection leds: pca955x: Use pointers to driver data rather than I2C client leds: pca955x: Refactor with helper functions and renaming dt-bindings: leds: Convert leds-tlc591xx.txt to yaml format ... 
Pull LED updates from Lee Jones:

 - pca955x: Add HW blink support, utilizing PWM0. It supports one
   frequency across all blinking LEDs and falls back to software blink
   if different frequencies are requested.

 - trigger: netdev: Allow configuring LED blink interval via .blink_set
   even when HW offload (.hw_control) is enabled.

 - led-core: Fix a race condition where a quick LED_OFF followed by
   another brightness set could leave the LED off incorrectly,
   especially noticeable after the introduction of the ordered
   workqueue.

 - qcom-lpg: Add support for 6-bit PWM resolution alongside the existing
   9-bit support.

 - qcom-lpg: Fix PWM value capping to respect the selected resolution
   (6-bit or 9-bit) for normal PWMs.

 - qcom-lpg: Fix PWM value capping to respect the selected resolution
   for Hi-Res PWMs.

 - qcom-lpg: Fix calculation of the best period for Hi-Res PWMs to
   prevent requested duty cycles from exceeding the maximum allowed by
   the selected resolution.

 - st1202: Add a check for the error code returned by devm_mutex_init().

 - pwm-multicolor: Add a check for the return value of
   fwnode_property_read_u32().

 - st1202: Ensure hardware initialization (st1202_setup) happens before
   DT node processing (st1202_dt_init).

 - Kconfig: leds-st1202: Add select LEDS_TRIGGER_PATTERN as it's
   required by the driver.

 - lp8860: Drop unneeded explicit assignment to REGCACHE_NONE.

 - pca955x: Refactor code with helper functions and rename some
   functions/variables for clarity.

 - pca955x: Pass driver data pointers instead of the I2C client to
   helper functions.

 - pca955x: Optimize probe LED selection logic to reduce I2C operations.

 - pca955x: Revert the removal of pca95xx_num_led_regs() (renaming it to
   pca955x_num_led_regs) as it's needed for HW blink support.

 - st1202: Refactor st1202_led_set() to use the !! operator for boolean
   conversion.

 - st1202: Minor spacing and proofreading edits in comments.

 - Directory Rename: Rename the drivers/leds/simple directory to
   drivers/leds/simatic as the drivers within are not simple.

 - mlxcpld: Remove unused include of acpi.h.

 - nic78bx: Tidy up the ACPI ID table (remove ACPI_PTR, use
   mod_devicetable.h, remove explicit driver_data initializer).

 - tlc591xx: Convert text binding to YAML format, add child node
   constraints, and fix typos/formatting in the example.

 - qcom-lpg: Document the qcom,pm8937-pwm compatible string as a
   fallback for qcom,pm8916-pwm.

* tag 'leds-next-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (23 commits)
  leds: nic78bx: Tidy up ACPI ID table
  leds: mlxcpld: Remove unused ACPI header inclusion
  leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs
  leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs
  leds: rgb: leds-qcom-lpg: Fix pwm resolution max for normal PWMs
  leds: Rename simple directory to simatic
  leds: Kconfig: leds-st1202: Add select for required LEDS_TRIGGER_PATTERN
  leds: leds-st1202: Spacing and proofreading editing
  leds: leds-st1202: Initialize hardware before DT node child operations
  leds: pwm-multicolor: Add check for fwnode_property_read_u32
  leds: rgb: leds-qcom-lpg: Add support for 6-bit PWM resolution
  leds: Fix LED_OFF brightness race
  Revert "leds-pca955x: Remove the unused function pca95xx_num_led_regs()"
  leds: st1202: Refactor st1202_led_set() to use !! operator for boolean conversion
  dt-bindings: leds: qcom-lpg: Document PM8937 PWM compatible
  leds: pca955x: Add HW blink support
  leds: pca955x: Optimize probe LED selection
  leds: pca955x: Use pointers to driver data rather than I2C client
  leds: pca955x: Refactor with helper functions and renaming
  dt-bindings: leds: Convert leds-tlc591xx.txt to yaml format
  ...
leds: trigger: pattern: Switch to use hrtimer_setup() 2025-02-18T10:19:05+00:00 Nam Cao namcao@linutronix.de 2025-02-05T10:46:13+00:00 a9d0ac739658f9a7c27d3430475aa3a00948ab1f hrtimer_setup() takes the callback function pointer as argument and initializes the timer completely. Replace hrtimer_init() and the open coded initialization of hrtimer::function with the new setup mechanism. Patch was created by using Coccinelle. Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://lore.kernel.org/all/76fa1cc9777a99a48f49f949abadc1c10af1bc64.1738746904.git.namcao@linutronix.de 
hrtimer_setup() takes the callback function pointer as argument and
initializes the timer completely.

Replace hrtimer_init() and the open coded initialization of
hrtimer::function with the new setup mechanism.

Patch was created by using Coccinelle.

Signed-off-by: Nam Cao <namcao@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Zack Rusin <zack.rusin@broadcom.com>
Link: https://lore.kernel.org/all/76fa1cc9777a99a48f49f949abadc1c10af1bc64.1738746904.git.namcao@linutronix.de
leds: trigger: netdev: Configure LED blink interval for HW offload 2025-02-10T16:56:53+00:00 Marek Vasut marex@denx.de 2025-01-20T11:36:53+00:00 c629c972b310af41e9e072febb6dae9a299edde6 In case a PHY LED implements .blink_set callback to set LED blink interval, call it even if .hw_control is already set, as that LED blink interval likely controls the blink rate of that HW offloaded LED. For PHY LEDs, that can be their activity blinking interval. The software blinking is not affected by this change. With this change, the LED interval setting looks something like this: $ echo netdev > /sys/class/leds/led:green:lan/trigger $ echo 1 > /sys/class/leds/led:green:lan/brightness $ echo 250 > /sys/class/leds/led:green:lan/interval Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20250120113740.91807-1-marex@denx.de Signed-off-by: Lee Jones <lee@kernel.org> 
In case a PHY LED implements .blink_set callback to set LED blink
interval, call it even if .hw_control is already set, as that LED
blink interval likely controls the blink rate of that HW offloaded
LED. For PHY LEDs, that can be their activity blinking interval.

The software blinking is not affected by this change.

With this change, the LED interval setting looks something like this:
$ echo netdev > /sys/class/leds/led:green:lan/trigger
$ echo 1 > /sys/class/leds/led:green:lan/brightness
$ echo 250 > /sys/class/leds/led:green:lan/interval

Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20250120113740.91807-1-marex@denx.de
Signed-off-by: Lee Jones <lee@kernel.org>
leds: trigger: netdev: Check offload ability on interface up 2024-12-17T13:10:48+00:00 Marek Vasut marex@denx.de 2024-12-16T10:48:22+00:00 0dfda50988c6805e8ab432e99866a021ea6ec46d The trigger_data->hw_control indicates whether the LED is controlled by HW offload, i.e. the PHY. The trigger_data->hw_control = can_hw_control() is currently called only from netdev_led_attr_store(), i.e. when writing any sysfs attribute of the netdev trigger instance associated with a PHY LED. The can_hw_control() calls validate_net_dev() which internally calls led_cdev->hw_control_get_device(), which is phy_led_hw_control_get_device() for PHY LEDs. The phy_led_hw_control_get_device() returns NULL if the PHY is not attached. At least in case of DWMAC (STM32MP, iMX8M, ...), the PHY device is attached only when the interface is brought up and is detached again when the interface is brought down. In case e.g. udev rules configure the netdev LED trigger sysfs attributes before the interface is brought up, then when the interface is brought up, the LEDs are not blinking. This is because trigger_data->hw_control = can_hw_control() was called when udev wrote the sysfs attribute files, before the interface was up, so can_hw_control() resp. validate_net_dev() returned false, and the trigger_data->hw_control = can_hw_control() was never called again to update the trigger_data->hw_control content and let the offload take over the LED blinking. Call data->hw_control = can_hw_control() from netdev_trig_notify() to update the offload capability of the LED when the UP notification arrives. This makes the LEDs blink after the interface is brought up. On STM32MP13xx with RTL8211F, it is enough to have the following udev rule in place, boot the machine with cable plugged in, and the LEDs won't work without this patch once the interface is brought up, even if they should: " ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:green:wan", ATTR{trigger}="netdev", ATTR{link_10}="1", ATTR{link_100}="1", ATTR{link_1000}="1", ATTR{device_name}="end0" ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:yellow:wan", ATTR{trigger}="netdev", ATTR{rx}="1", ATTR{tx}="1", ATTR{device_name}="end0" " Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20241216104826.6946-1-marex@denx.de Signed-off-by: Lee Jones <lee@kernel.org> 
The trigger_data->hw_control indicates whether the LED is controlled by HW
offload, i.e. the PHY. The trigger_data->hw_control = can_hw_control() is
currently called only from netdev_led_attr_store(), i.e. when writing any
sysfs attribute of the netdev trigger instance associated with a PHY LED.

The can_hw_control() calls validate_net_dev() which internally calls
led_cdev->hw_control_get_device(), which is phy_led_hw_control_get_device()
for PHY LEDs. The phy_led_hw_control_get_device() returns NULL if the PHY
is not attached.

At least in case of DWMAC (STM32MP, iMX8M, ...), the PHY device is attached
only when the interface is brought up and is detached again when the
interface is brought down. In case e.g. udev rules configure the netdev
LED trigger sysfs attributes before the interface is brought up, then when
the interface is brought up, the LEDs are not blinking.

This is because trigger_data->hw_control = can_hw_control() was called
when udev wrote the sysfs attribute files, before the interface was up,
so can_hw_control() resp. validate_net_dev() returned false, and the
trigger_data->hw_control = can_hw_control() was never called again to
update the trigger_data->hw_control content and let the offload take
over the LED blinking.

Call data->hw_control = can_hw_control() from netdev_trig_notify() to
update the offload capability of the LED when the UP notification arrives.
This makes the LEDs blink after the interface is brought up.

On STM32MP13xx with RTL8211F, it is enough to have the following udev rule
in place, boot the machine with cable plugged in, and the LEDs won't work
without this patch once the interface is brought up, even if they should:
"
ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:green:wan", ATTR{trigger}="netdev", ATTR{link_10}="1", ATTR{link_100}="1", ATTR{link_1000}="1", ATTR{device_name}="end0"
ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:yellow:wan", ATTR{trigger}="netdev", ATTR{rx}="1", ATTR{tx}="1", ATTR{device_name}="end0"
"

Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20241216104826.6946-1-marex@denx.de
Signed-off-by: Lee Jones <lee@kernel.org>
leds: ledtrig-activity: Fix the wrong format specifier 2024-12-12T17:28:27+00:00 Zhu Jun zhujun2@cmss.chinamobile.com 2024-11-22T06:46:26+00:00 6fcafd33d2f85f0ffc1fc64e2b1ea607d0e75037 The format specifier of "signed int" in sprintf() should be "%d", not "%u". Signed-off-by: Zhu Jun <zhujun2@cmss.chinamobile.com> Link: https://lore.kernel.org/r/20241122064626.4680-1-zhujun2@cmss.chinamobile.com Signed-off-by: Lee Jones <lee@kernel.org> 
The format specifier of "signed int" in sprintf() should be "%d", not
"%u".

Signed-off-by: Zhu Jun <zhujun2@cmss.chinamobile.com>
Link: https://lore.kernel.org/r/20241122064626.4680-1-zhujun2@cmss.chinamobile.com
Signed-off-by: Lee Jones <lee@kernel.org>
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>