On Thu, 16 Oct 2025, Antheas Kapenekakis wrote: > On Thu, 16 Oct 2025 at 17:09, Ilpo Järvinen > > On Thu, 16 Oct 2025, Antheas Kapenekakis wrote: > > > On Thu, 16 Oct 2025 at 13:57, Denis Benato wrote: > > > > On 10/13/25 22:15, Antheas Kapenekakis wrote: > > > > > This is a two part series which does the following: > > > > > - Clean-up init sequence > > > > > - Unify backlight handling to happen under asus-wmi so that all Aura > > > > > devices have synced brightness controls and the backlight button works > > > > > properly when it is on a USB laptop keyboard instead of one w/ WMI. > > > > > > > > > > For more context, see cover letter of V1. Since V5, I removed some patches > > > > > to make this easier to merge. > > > > > > > > > > All comments with these patches had been addressed since V4. > > > > I have loaded this patchset for users of asus-linux project to try out. > > > > > > > > One of them opened a bug report about a kernel bug that happens > > > > consistently when closing the lid of his laptop [1]. > > > > > > > > He also sent another piece of kernel log, but didn't specify anything more > > > > about this [2]. > > > > > > > > [1] https://pastebin.com/akZx1w10 > > > > [2] https://pastebin.com/sKdczPgf > > > > > > Can you provide a link to the bug report? [2] seems unrelated. > > > > > > As for [1], it looks like a trace that stems from a sysfs write to > > > brightness stemming from userspace that follows the same chain it > > > would on a stock kernel and times out. Is it present on a stock > > > kernel? > > > > > > Ilpo should know more about this, could the spinlock be interfering? > > > > [1] certainly seems to do schedule() from do_kbd_led_set() so it's not > > possible to use spinlock there. > > > > So we're back to what requires the spinlock? And what the spinlock > > protects? > > For that invocation, since it is coming from the cdev device owned by > asus_wmi, it protects asus_ref.listeners under do_kbd_led_set. > asus_wmi is protected by the fact it is owned by that device. Spinlock > is not required in this invocation due to not being an IRQ. > > Under asus_hid_event (second to last patch), which is called from an > IRQ, a spinlock is required for protecting both listeners and the > asus_ref.asus, and I suspect that scheduling from an IRQ is not > allowed either. Is that correct? Yes, it's not allowed either. hid-asus seems to already use workqueue (though include for it is missing) likely to workaround a similar challenge. -- i.