Hi Lee, et. al., So approx. 24 hours after you merged my input-events trigger I have found a rather nasty locking issue with it after plugging a USB keyboard into a tablet which uses this new trigger. Sorry about the bad timing. Patch 2/2 of this series tries to fix this and it fixes my reproducer. But I was worried about the deactivate path, so I gave that a try with the patch in place and this resulted in a new lockdep warning (now on deactivate). So I need a different approach. I have a plan how to fix this differently and I plan to write a patch on top of for-leds-next in the next couple of days. But I guess you could also drop the "leds: trigger: Add new LED Input events trigger" from for-leds-next for now. I thought it would be still good to post this patch as it shows the complex problem of LEDs or LED triggers getting registered by subsystems while holding a global lock from that subsystem vs the activate / deactivate method of the trigger calling functions of that same subsystem which require that same global lock. Basically this is the same LED trigger problem as this 6.9+ regression: https://lore.kernel.org/regressions/42d498fc-c95b-4441-b81a-aee4237d1c0d@xxxxxxxxxxxxx/ Regards, Hans Hans de Goede (2): leds: trigger: input-events: Replace led_on with a flags field leds: trigger: input-events: Fix locking issues of input_lock vs led-trigger locks drivers/leds/trigger/ledtrig-input-events.c | 53 ++++++++++++++------- 1 file changed, 35 insertions(+), 18 deletions(-) -- 2.45.1
