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

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

[aprilgrimoire]

Hi!
Opening or closing the lid causes my laptop Yilong15Pro GM5HG7A to wake up from s2idle, similar to the symptom described in

https://community.frame.work/t/tracking-waking-from-sleep-when-plugged-in-amd-k-ubuntu-22-04/44168

This issue for Framework 13 has been fixed in

https://lore.kernel.org/platform-driver-x86/20231212045006.97581-5-mario.limonciello@amd.com/

For me specifically, two interrupts appear on such unwanted wakeups: IRQ1 and IRQ7. IRQ1 is the lid switch, with DRIVER==button. IRQ7 has SUBSYSTEM==serio and DRIVER==amd_gpio. I tried some workarounds and got to disable IRQ1, but IRQ7 doesn't support disabling and the issue persists.

I did some modifications to the kernel code:

----- drivers/platform/x86/amd/pmc/pmc.c

static int amd_pmc_wa_irq1(struct amd_pmc_dev *pdev)
{
        ...
        if (device_may_wakeup(d)) {
                dev_info_once(d, "Disabling IRQ1 wakeup source to avoid platform firmware bug\n");
                disable_irq_wake(1);
                dev_warn(d, "Also disabling IRQ7!!! This is bad practice!!! Remove after testing IMMEDIATELY!!!");
                disable_irq_wake(7);
                device_set_wakeup_enable(d, false);
        }
        ...
}

----- drivers/platform/x86/amd/pmc/pmc-quirks.c
        ...
        {
                .ident = "MECHREVO Yilong15Pro Series GM5HG7A",
                .driver_data = &quirk_spurious_8042,
                .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "MECHREVO"),
                        DMI_MATCH(DMI_PRODUCT_NAME, "Yilong15Pro Series GM5HG7A"),
                        /* Not matching BIOS version: MECHREVO doesn't support Linux officially, so no expectation of them fixing the bios. */
                }
        },
        ...

But IRC7 cannot be disabled:

(base) ➜  ~ echo disabled | sudo tee /sys/kernel/irq/7/wakeup
Password:
tee: /sys/kernel/irq/7/wakeup: Permission denied

In dsdt.dsl, I also nuked some code about the lid state and changed all SharedAndWake to Shared, however it didn't work either.

Mechrevo officially only supports Windows, and this lid issue doesn't appear on Windows. Does this indicate this issue can be workaround in the driver level? What can be done next?

Thanks!

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

[Mario Limonciello]

On 9/3/25 11:23 AM, aprilgrimoire wrote:
> Hi!
> Opening or closing the lid causes my laptop Yilong15Pro GM5HG7A to wake up from s2idle, similar to the symptom described in
> 
> https://community.frame.work/t/tracking-waking-from-sleep-when-plugged-in-amd-k-ubuntu-22-04/44168
> 
> This issue for Framework 13 has been fixed in
> 
> https://lore.kernel.org/platform-driver-x86/20231212045006.97581-5-mario.limonciello@amd.com/
> 
> For me specifically, two interrupts appear on such unwanted wakeups: IRQ1 and IRQ7. IRQ1 is the lid switch, with DRIVER==button. IRQ7 has SUBSYSTEM==serio and DRIVER==amd_gpio. I tried some workarounds and got to disable IRQ1, but IRQ7 doesn't support disabling and the issue persists.
> 
> I did some modifications to the kernel code:
> 
> ----- drivers/platform/x86/amd/pmc/pmc.c
> 
> static int amd_pmc_wa_irq1(struct amd_pmc_dev *pdev)
> {
>          ...
>          if (device_may_wakeup(d)) {
>                  dev_info_once(d, "Disabling IRQ1 wakeup source to avoid platform firmware bug\n");
>                  disable_irq_wake(1);
>                  dev_warn(d, "Also disabling IRQ7!!! This is bad practice!!! Remove after testing IMMEDIATELY!!!");
>                  disable_irq_wake(7);
>                  device_set_wakeup_enable(d, false);
>          }
>          ...
> }
> 
> ----- drivers/platform/x86/amd/pmc/pmc-quirks.c
>          ...
>          {
>                  .ident = "MECHREVO Yilong15Pro Series GM5HG7A",
>                  .driver_data = &quirk_spurious_8042,
>                  .matches = {
>                          DMI_MATCH(DMI_SYS_VENDOR, "MECHREVO"),
>                          DMI_MATCH(DMI_PRODUCT_NAME, "Yilong15Pro Series GM5HG7A"),
>                          /* Not matching BIOS version: MECHREVO doesn't support Linux officially, so no expectation of them fixing the bios. */
>                  }
>          },
>          ...
> 
> But IRC7 cannot be disabled:
> 
> (base) ➜  ~ echo disabled | sudo tee /sys/kernel/irq/7/wakeup
> Password:
> tee: /sys/kernel/irq/7/wakeup: Permission denied
> 
> In dsdt.dsl, I also nuked some code about the lid state and changed all SharedAndWake to Shared, however it didn't work either.
> 
> Mechrevo officially only supports Windows, and this lid issue doesn't appear on Windows. Does this indicate this issue can be workaround in the driver level? What can be done next?
> 
> Thanks!

Hi,

Can you please reproduce the issue using 'amd-s2idle' from 
https://pypi.org/project/amd-debug-tools/ ?

Basically install the wheel, run 'amd-s2idle test'.  When prompted how 
long, set it for ~20 seconds.  Then wait for the LED to flash and close 
the lid and it should wake up and generate a report.

This will capture a lot of artifacts about the problem in the report and 
we can go from there on next steps.  Ideally if you can put the report 
on a new issue here and tag me (@superm1): 
https://gitlab.freedesktop.org/drm/amd/-/issues
We can iterate back and forth on it to come up with the best solution.

Thanks,

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

[aprilgrimoire]

> Hi,
> 
> Can you please reproduce the issue using 'amd-s2idle' from
> https://pypi.org/project/amd-debug-tools/ ?
> 
> Basically install the wheel, run 'amd-s2idle test'. When prompted how
> long, set it for ~20 seconds. Then wait for the LED to flash and close
> the lid and it should wake up and generate a report.
> 
> This will capture a lot of artifacts about the problem in the report and
> we can go from there on next steps. Ideally if you can put the report
> on a new issue here and tag me (@superm1):
> https://gitlab.freedesktop.org/drm/amd/-/issues
> We can iterate back and forth on it to come up with the best solution.
> 
> Thanks,

Hi! Here's the output:

https://paste.gentoo.zip/mpV8dQcl

I disabled the patched dsdt since with it amd-s2idle would think ASPM Policy is set to power-saving and refuse to run.

It's late here and I'll probably return tomorrow. Thanks!

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

[Mario Limonciello]

On 9/3/25 12:13 PM, aprilgrimoire wrote:
> 
>> Hi,
>>
>> Can you please reproduce the issue using 'amd-s2idle' from
>> https://pypi.org/project/amd-debug-tools/ ?
>>
>> Basically install the wheel, run 'amd-s2idle test'. When prompted how
>> long, set it for ~20 seconds. Then wait for the LED to flash and close
>> the lid and it should wake up and generate a report.
>>
>> This will capture a lot of artifacts about the problem in the report and
>> we can go from there on next steps. Ideally if you can put the report
>> on a new issue here and tag me (@superm1):
>> https://gitlab.freedesktop.org/drm/amd/-/issues
>> We can iterate back and forth on it to come up with the best solution.
>>
>> Thanks,
> 
> Hi! Here's the output:
> 
> https://paste.gentoo.zip/mpV8dQcl
> 
> I disabled the patched dsdt since with it amd-s2idle would think ASPM Policy is set to power-saving and refuse to run.
> 
> It's late here and I'll probably return tomorrow. Thanks!

IRQ1 doesn't show up in this report, so this is not a problem with the 
keyboard wakeup.

There's a few things that stand out to me.

1) There are ACPI errors with the PEP _DSM; specificially the screen on 
action.  This isn't likely the cause of this issue but it's most 
definitely a BIOS bug.

     ACPI BIOS Error (bug): Could not resolve symbol [\_SB.ACDC.RTAC], 
AE_NOT_FOUND (20250404/psargs-332)
     ACPI Error: Aborting method \_SB.PEP._DSM due to previous error 
(AE_NOT_FOUND) (20250404/psparse-529)
     ACPI: \_SB_.PEP_: Failed to transitioned to state screen on

2) The wakeup is from IRQ 7 (like you said) which is the GPIO controller.
     PM: Triggering wakeup from IRQ 7
     Woke up from IRQ 7 (IR-IO-APIC 7-fasteoi pinctrl_amd)

The GPIO controller wakes up the system when any of the pins that are 
marked as wake pins are triggered.  In your case this is GPIO 0.
     GPIO 0 is active: 0x38157800

According to the SSDT _EVT handler this notifies the _PWRB ACPI object.

                     Case (Zero)
                     {
                         M000 (0x3900)
                         Notify (\_SB.PWRB, 0x80) // Status Change
                     }

We can see that notify happened here:
     Dispatching Notify on [PWRB] (Device) Value 0x80 (Status Change)

So based on above what it looks like is going on to me is that the lid 
is likely indirectly tied to GPIO 0 in this design.  It's not clear if 
it's a mux, directly connected or if the EC drives that GPIO or what not.

It's worth noting that we did have a Linux kernel change to turn off 
debounce for all GPIOs recently at suspend time [1].  You can see in 
your log this message associated with it.

     Clearing debounce for GPIO #0 during suspend.

I don't expect it's the cause of your issue, but you could try to revert 
it to confirm.

Instead I think what's going on is that they have their design expecting 
that Windows does a "dark screen wakeup".  This is where it exits a 
hardware sleep state but doesn't fully wake the system.  If no input 
activity happens then it goes back to hardware sleep.

This is something that common userspace (systemd on most systems) 
doesn't support today.

One option for you is to try to set this GPIO not to be a wake source by 
gpiolib_acpi.ignore_wake=AMDI0030:00@0.

If this helps, please also check whether this breaks power button wakeup 
though.  If it does we might be trading one wakeup source for another if 
they're muxed.

[1] 
https://github.com/torvalds/linux/commit/8ff4fb276e2384a87ae7f65f3c28e1e139dbb3fe

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

[aprilgrimoire]

Sent with Proton Mail secure email.

------- Forwarded Message -------
From: aprilgrimoire <aprilgrimoire@proton.me>
Date: On Thursday, September 4th, 2025 at 2:07 PM
Subject: Re: [BUG] MECHREVO Yilong15Pro GM5HG7A: lid switch causing unwanted s2idle wakeups
To: Mario Limonciello <superm1@kernel.org>


> > IRQ1 doesn't show up in this report, so this is not a problem with the
> > keyboard wakeup.
> > 
> > There's a few things that stand out to me.
> > 
> > 1) There are ACPI errors with the PEP _DSM; specificially the screen on
> > action. This isn't likely the cause of this issue but it's most
> > definitely a BIOS bug.
> > 
> > ACPI BIOS Error (bug): Could not resolve symbol [\_SB.ACDC.RTAC],
> > AE_NOT_FOUND (20250404/psargs-332)
> > ACPI Error: Aborting method \_SB.PEP.DSM due to previous error
> > (AE_NOT_FOUND) (20250404/psparse-529)
> > ACPI: \SB.PEP: Failed to transitioned to state screen on
> > 
> > 2) The wakeup is from IRQ 7 (like you said) which is the GPIO controller.
> > PM: Triggering wakeup from IRQ 7
> > Woke up from IRQ 7 (IR-IO-APIC 7-fasteoi pinctrl_amd)
> > 
> > The GPIO controller wakes up the system when any of the pins that are
> > marked as wake pins are triggered. In your case this is GPIO 0.
> > GPIO 0 is active: 0x38157800
> > 
> > According to the SSDT _EVT handler this notifies the _PWRB ACPI object.
> > 
> > Case (Zero)
> > {
> > M000 (0x3900)
> > Notify (\_SB.PWRB, 0x80) // Status Change
> > }
> > 
> > We can see that notify happened here:
> > Dispatching Notify on [PWRB] (Device) Value 0x80 (Status Change)
> > 
> > So based on above what it looks like is going on to me is that the lid
> > is likely indirectly tied to GPIO 0 in this design. It's not clear if
> > it's a mux, directly connected or if the EC drives that GPIO or what not.
> > 
> > It's worth noting that we did have a Linux kernel change to turn off
> > debounce for all GPIOs recently at suspend time [1]. You can see in
> > your log this message associated with it.
> > 
> > Clearing debounce for GPIO #0 during suspend.
> > 
> > I don't expect it's the cause of your issue, but you could try to revert
> > it to confirm.
> > 
> > Instead I think what's going on is that they have their design expecting
> > that Windows does a "dark screen wakeup". This is where it exits a
> > hardware sleep state but doesn't fully wake the system. If no input
> > activity happens then it goes back to hardware sleep.
> > 
> > This is something that common userspace (systemd on most systems)
> > doesn't support today.
> > 
> > One option for you is to try to set this GPIO not to be a wake source by
> > gpiolib_acpi.ignore_wake=AMDI0030:00@0.
> > 
> > If this helps, please also check whether this breaks power button wakeup
> > though. If it does we might be trading one wakeup source for another if
> > they're muxed.
> > 
> > [1]
> > https://github.com/torvalds/linux/commit/8ff4fb276e2384a87ae7f65f3c28e1e139dbb3fe
> 
> 
> Hi, Mario!
> 
> I tested clearing debounce, and it didn't make a difference.
> 
> The gpiolib_acpi.ignore_wake option worked!
> 
> It seemed that IRQ 1 is just a regular device, with wake up settable via udev. Even without the kernel modification, gpiolib_acpi.ignore_wake alone could stop the lid from waking the system up.
> 
> It seems this quirk should not be applied here: The lid triggers two events, one from IRQ1 and another from IRQ7. The kernel cmdline option can disable the IRQ7 signal from waking the system up, and the IRQ1 event can be disabled by either
> 
> 1. Enabling the quirk
> 2. Setting ACTION=="add", SUBSYSTEM=="input", ATTR{name}=="Lid Switch", ATTR{inhibited}="1"
> in udev
> 
> The problem is, the quirk also stops other on-laptop methods from waking the system up: builtin keyboard, builtin touchpad and power button, none of those would work with the quirk enabled. With the udev workaround, the lid event can be disabled, and I can still wake up with the builtin keyboard.
> 
> Thanks!

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

[aprilgrimoire]

> 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?

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

[Mario Limonciello]

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.

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

[aprilgrimoire]

 > 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.

Hi, Mario!

I tried these events, and I am highly affirmative (on the patched kernel, with GPIO 0 disabled, these events don't trigger wakeups) that:
* Press power button and keyboard triggers GPIO 0
* Plugging / Unplugging the PD100W adapter doesn't trigger GPIO 0
  (The model also supports 240W round-pin unknown-protocol adapters, but I don't have one here.)
* Clicking touchpad doesn't trigger GPIO 0

I think it isn't feasible to rely on the spurious IRQ1, unless some efficient re-suspend mechanism is implemented. As mentioned in 

https://community.frame.work/t/tracking-framework-amd-ryzen-7040-series-lid-wakeup-behavior-feedback/39128/10?u=aprilgrimoire

> I have pulled scalding hot laptops with a nearly dead battery out of my bag because the laptop didn’t go to sleep correctly and stayed on when I closed the lid.

When put in bags, the lid could move slightly upon shaken, and I am worried that IRQ1 would trigger without me knowing.

Or am I misunderstanding your suggestion on how to use the spurious IRQ1?

Thanks!

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

[Mario Limonciello]

On 9/4/25 11:34 AM, aprilgrimoire wrote:
> 
> 
>   > 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.
> 
> Hi, Mario!
> 
> I tried these events, and I am highly affirmative (on the patched kernel, with GPIO 0 disabled, these events don't trigger wakeups) that:
> * Press power button and keyboard triggers GPIO 0
> * Plugging / Unplugging the PD100W adapter doesn't trigger GPIO 0
>    (The model also supports 240W round-pin unknown-protocol adapters, but I don't have one here.)
> * Clicking touchpad doesn't trigger GPIO 0

 From what you've said it sounds like GPIO0 is basically an EC output 
pin that is overloaded to cover power button, lid, and keyboard.  That's 
a bit unusual for keyboard.

> 
> I think it isn't feasible to rely on the spurious IRQ1, unless some efficient re-suspend mechanism is implemented. As mentioned in

Yeah I don't think you should rely upon IRQ1.

> 
> https://community.frame.work/t/tracking-framework-amd-ryzen-7040-series-lid-wakeup-behavior-feedback/39128/10?u=aprilgrimoire
> 

I wouldn't read too much into the Framework issue - this was purely a 
polarity issue in their firmware.  It was fixed in a combination of 
their EC and BIOS.

>> I have pulled scalding hot laptops with a nearly dead battery out of my bag because the laptop didn’t go to sleep correctly and stayed on when I closed the lid.
> 
> When put in bags, the lid could move slightly upon shaken, and I am worried that IRQ1 would trigger without me knowing.
> 
> Or am I misunderstanding your suggestion on how to use the spurious IRQ1?
> 
> Thanks!

Can you double-confirm that with IRQ1 disabled that you still get GPIO0 
for keyboard wakeup specifically?