Re: unexptect ACPI GPE wakeup on Lenovo platforms

[Mario Limonciello <mario.limonciello@amd.com>]

On 9/24/2024 00:52, Baochen Qiang wrote:
> 
> 
> On 9/23/2024 9:37 PM, Mario Limonciello wrote:
>> On 9/23/2024 05:07, Baochen Qiang wrote:
>>> Hi,
>>>
>>> recently it is reported that on some Lenovo machines (P16v, Z13 etc.) unexpected ACPI event wakeup is seen with kernel 6.10 [1][2]. To summary, the unexpected wakeup is triggered by simply unplug AC power or close lid of the laptop. Regression test shows this is caused by below commit, and with that reverted the issue is gone:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/wireless/ath/ath11k?id=166a490f59ac10340ee5330e51c15188ce2a7f8f
>>>
>>> Well what confuses me is that this commit basically resets WLAN hardware before going to suspend. that said, WLAN target maintains limited functionality (PCIe link handling etc...) during system suspend and is thus not expected to wakeup system.
>>>
>>> kernel log shows this is an ACPI GPE event wakeup:
>>>
>>> Sep 22 22:34:32 fedora kernel: PM: Triggering wakeup from IRQ 9
>>> Sep 22 22:34:32 fedora kernel: ACPI: PM: ACPI non-EC GPE wakeup
>>> ...
>>> Sep 22 22:34:32 fedora kernel: PM: noirq resume of devices complete after 693.757 msecs
>>> Sep 22 22:34:32 fedora kernel: ACPI: GPE event 0x07
>>> Sep 22 22:34:32 fedora kernel: ACPI: GPE event 0x0e
>>>
>>> Consulting ACPI tables show GPE 0x07 is used by the EC and GPE 0x0e is used by GPP6 device:
>>>
>>> Scope (\_SB.PCI0.GPP6)
>>> {
>>>       ...
>>>       Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
>>>       {
>>>           M460 ("PLA-ASL-\\_SB.PCI0.GPP6._PRW Return GPRW (0xE, 0x4)\n", 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
>>>           Return (Package (0x02)
>>>           {
>>>               0x0E,
>>>               0x04
>>>           })
>>>       }
>>>       ...
>>> }
>>>
>>> while GPP6 is the PCI bridge (the PCIe root port in this case) to which WLAN target is attached to:
>>>
>>> Device (GPP6)
>>> {
>>>       Name (_ADR, 0x00020002)  // _ADR: Address
>>>       ...
>>> }
>>>
>>> Scope (_SB.PCI0.GPP6)
>>> {
>>>       Device (WLAN)
>>>       {
>>>           ...
>>>       }
>>>       ...
>>> }
>>>
>>> and lspci also shows such relationship:
>>>
>>> $ lspci -vt
>>> -[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14e8
>>>              ...
>>>              +-02.2-[03]----00.0  Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter
>>>              ....
>>>
>>> Based on above info:
>>> #1 is that valid to get the conclusion that this unexpected wakeup is triggered directly by PCIe bridge?
>>> #2 if this is related to WLAN (seems so based on the regression test), is it the WLAN wake pin (a GPIO pin?) that originally triggers this? and how does it affect the bridge?
>>> #3 quick tests show that with GPP6 wakeup disabled this issue is gone. so a workaround is to disable GPP6 wakeup before going to suspend and enable it back after resume. But is it safe to do so?
>>>
>>>
>>>
>>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=219196
>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2301921
>>>
>>
>> With pinctrl-amd there is an extra debugging message present [1] that is activated when you enable '/sys/power/pm_debug_messages' which will tell you if a GPIO is active during the suspend cycle.  That can help you to rule out whether this is the WoWLAN GPIO pin causing the behavior.
>>
>> [1] https://github.com/torvalds/linux/blob/v6.11/drivers/pinctrl/pinctrl-amd.c#L626
> Thanks for the reminder, Mario.
> 
> I do notice that some reporters mentioned about this [1]. and I can also see this on my P16v machine:
> 
> [  881.799289] PM: suspend entry (s2idle)
> ...
> [  897.491440] PM: Triggering wakeup from IRQ 9
> [  897.491714] ACPI: PM: ACPI non-EC GPE wakeup
> [  897.491720] PM: resume from suspend-to-idle
> ...
> [  898.153259] PM: noirq resume of devices complete after 556.675 msecs
> [  898.153443] ACPI: GPE event 0x07
> [  898.153502] ACPI: GPE event 0x0e //GPE 0x0e triggered for the 1st time
> ...
> [  898.314804] mhi mhi0: Requested to power ON //WLAN begin to reinitialize
> [  898.314841] mhi mhi0: Power on setup success
> [  898.694562] mhi mhi0: Wait for device to enter SBL or Mission mode
> [  899.305898] GPIO 18 is active: 0x10157a00 //I guess this is the WoWLAN GPIO pin

Yeah that's what it looks like to me too.  The easiest way to confirm 
this (without a schematic that is) is to look at the _AEI / _EVT in the 
SSDT and see what is notified when this is active.

> [  899.306089] ACPI: GPE event 0x0e //GPE 0x0e triggered for the 2nd time
> [  899.333158] ath11k_pci 0000:03:00.0: chip_id 0x12 chip_family 0xb board_id 0xff soc_id 0x400c1211
> [  899.333190] ath11k_pci 0000:03:00.0: fw_version 0x1106196e fw_build_timestamp 2024-01-12 11:30 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.37
> ...
> [  899.826378] PM: suspend exit
> 
> 
> But I don;t think it is the wakeup source, it is just toggled during WLAN reinitialize AFTER system wakeup. actually even with ath11k module removed I can also see this GPE wakeup, but without GPIO 18 toggled:

I don't believe that just removing the kernel module is enough.  Can you 
physically remove the hardware?

> 
> [ 2640.849342] PM: suspend entry (s2idle)
> ...
> [ 2650.806234] PM: Triggering wakeup from IRQ 9
> ...
> [ 2651.467653] PM: noirq resume of devices complete after 558.943 msecs
> [ 2651.467880] ACPI: GPE event 0x07
> [ 2651.467961] ACPI: GPE event 0x0e
> ...
> [ 2651.848848] PM: suspend exit
> 
> 
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=219286
> 

Is it possible for you to put a scope on the GPIO and/or PCIe analzyer 
on the bus?

It sounds to me that most likely what's going on is PME being asserted 
from WLAN controller.