Re: [BUG] MECHREVO Yilong15Pro GM5HG7A: lid switch causing unwanted s2idle wakeups

[Mario Limonciello <superm1@kernel.org>]

On 9/4/25 2:38 AM, aprilgrimoire wrote:
>> Got it - so it sounds like that IRQ1 quirk is probably enabled as well.
>> Feel free to send a patch for that and CC me (as you already proved it
>> helps remove IRQ1 from spurious wakeups for your system).
>>
>> Make sure you base it off this branch because I know this was touched
>> recently for another system too.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=fixes
> 
> Hi, Mario!
> Sorry for bothering you again.
> 
> I didn't do enough testing, and it turned out that this laptop does need the quirk to stop lid from waking up. The unwanted wakes aren't triggered every time.
> 
> However, this quirk comes with a significant side effect: now I'm completely unable to wake it up with components builtin on the laptop. Maybe usb events can still wake it up though, but I don't have any around me. Shall I still submit a patch for this?

The Linux kernel will break from the s2dile loop when a device asserts 
to wake the system.

If IRQ1 triggers when the keyboard isn't pressed that is absolutely a 
firmware bug.  We can work around it with a quirk entry for 
pmc-quirks.c.  The obvious trade off is that the keyboard can't be used 
as a wake source either, but if you don't disable IRQ1 then another even 
that normally wouldn't wake the system "will wake the system".

For example if you plug in the power adapter the EC will assert the SCI 
and will notify the APU to wake up from hardware sleep.  Normally the 
kernel will process the EC events and go back to sleep.

But if IRQ1 is spuriously active during this time then it will wake the 
system when you plug in the power adapter.  So I think it's the lesser 
evil to add that quirk.  That being said we need to figure out what GPIO 
0 is tied to for your system.  Because maybe the better solution is to 
disable GPIO 0 and just "rely" upon the spurious IRQ1.

With GPIO 0 enabled, can you check when it gets triggered besides the 
lid event?  Try these:

* Suspend on battery / power adapter plug in
* Suspend on AC /  power adapter plug out
* Press power button
* Click touchpad

Ideally GPIO 0 is only used for the lid, but given the ASL notifies the 
PWRB device I don't have high hopes.