Hi luyuantao, On Thu, Nov 14, 2024 at 10:13:10AM +0800, luyuantao01 wrote: > From: luyuantao <luyuantao@xxxxxxxxxx> > > Hi Dmitry > I'm sorry for the inconvenience caused to you. After reproducing the > problem and conducting a thorough analysis, I found that the previous > patch description was incorrect. Therefore, resubmit the patch > > There is an i8402 keyboard and mouse device on the > ThinkPad P15 laptop.When conducting a wakeup > test on S3, it was found that: > > 1. Using the keyboard directly can wake up S3. > 2. The system failed to wake up using the mouse button first, > and when using the keyboard to wake up again, the system > cannot be woken up and can only be shut down by pressing > the power button. > > This issue is that i8042_start() only enables wakeup for the > keyboard. During the i8042_pm_suspend() phase, the aux device > will not enable irq wakeup. However, when suspend_device_irqs() > traversing irq without wakeup capability, __disable_irq() did > not truly disable aux interrupts, only setting the IRQS_SUSPEND > flag, resulting in aux interrupts still being generated. > > When an interrupt is triggered, irqd_irq_isabled returns the > true execution mask irq. The mask_iopic_irq callback function > of the IR-IO-APIC chip will disable all IRQ pins, resulting > in keyboard interrupts being disabled and no longer responding So this sounds like a bug in the irqchip implementation that is does not properly handle interrupts that are wakeup capable but not enabled for the interrupt because of policy. The i8042 driver correctly marks both KBD and AUX interrupts as capable of waking up the system but only enables KBD as a wakeup source for suspend-to-idle case. If a different policy is desired on a system it can be adjusted form userspace vis sysfs. Thanks. -- Dmitry
