unexptect ACPI GPE wakeup on Lenovo platforms

unexptect ACPI GPE wakeup on Lenovo platforms

[Baochen Qiang]

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

Re: unexptect ACPI GPE wakeup on Lenovo platforms

[Mario Limonciello]

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

Re: unexptect ACPI GPE wakeup on Lenovo platforms

[Baochen Qiang]

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
[  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:

[ 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

Re: unexptect ACPI GPE wakeup on Lenovo platforms

[Mario Limonciello]

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.

Re: unexptect ACPI GPE wakeup on Lenovo platforms

[Baochen Qiang]

On 9/25/2024 1:55 AM, Mario Limonciello wrote:
> 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.
seems GPP6 is notified, does this mean GPIO18 is NOT bound to WLAN wakeup pin? but instead it is bound to the PCIe root port?

Scope (\_SB.GPIO)
{
    Method (_AEI, 0, NotSerialized)  // _AEI: ACPI Event Interrupts
    {
        Name (BUF0, ResourceTemplate ()
        {
		...
            	GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
                	"\\_SB.GPIO", 0x00, ResourceConsumer, ,)
                {   	// Pin list
                    	0x0012
                }
		...
	})
        Name (BUF1, ResourceTemplate ()
	{
		...
		GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
			"\\_SB.GPIO", 0x00, ResourceConsumer, ,)
		{   	// Pin list
			0x0012
		}
		...
			
	})
	If ((\_SB.PCI0.LPC0.EC0.WWDT != 0x0F))
	{
		Return (BUF0) /* \_SB_.GPIO._AEI.BUF0 */
	}
	Else
	{
		Return (BUF1) /* \_SB_.GPIO._AEI.BUF1 */
	}
    }
	
    Method (_EVT, 1, Serialized)  // _EVT: Event
    {
        M460 ("  OEM-ASL-\\_SB.GPIO._EVT-Start Case %d\n", ToInteger (Arg0), 0x00, 0x00, 0x00, 0x00, 0x00)
        Switch (ToInteger (Arg0))
	{
		...
            	Case (0x12)
            	{
                	M000 (0x3912)
                	M460 ("    Notify (\\_SB.PCI0.GPP6, 0x02)\n", 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
                	Notify (\_SB.PCI0.GPP6, 0x02) // Device Wake
            	}
		...
        }

        M460 ("  OEM-ASL-\\_SB.GPIO._EVT-End Case %d\n", ToInteger (Arg0), 0x00, 0x00, 0x00, 0x00, 0x00)
    }
}

> 
>> [  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?
not possible, it is soldered, not a M.2 module
> 
>>
>> [ 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 is hard to me -- for the GPIO I need the schematic which is not available, and for the PCIe analyzer we need hardware rework for that, but I will try.

> 
> It sounds to me that most likely what's going on is PME being asserted from WLAN controller.
But I don;t see a PME interrupt fired on the root port:

$ cat /proc/interrupts
  36:          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0  IR-PCI-MSI-0000:00:02.2    0-edge      PCIe PME

$ lspci -tv
-[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 14e8
	   ...
           +-02.2-[03]----00.0  Qualcomm Technologies, Inc QCNFA765 Wireless Network Adapter


> 

Re: unexptect ACPI GPE wakeup on Lenovo platforms

[Mario Limonciello]

On 9/24/2024 21:18, Baochen Qiang wrote:
>>
>> 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.
> seems GPP6 is notified, does this mean GPIO18 is NOT bound to WLAN wakeup pin? but instead it is bound to the PCIe root port?

There is a concept in AMD machines called "GPIO mirroring" where the 
status of a GPIO pin is mirrored into a GPE.

Particularly GPE 0xE is often mirroring AMD GPIO 18.  This can be 
changed by BIOS though, so Lenovo would have to confirm it is the case 
or not.

But it could explain why you see GPE 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?
> not possible, it is soldered, not a M.2 module

Ah this makes it a lot harder for a debugging.  Is there option in BIOS 
to disable it?

>>
>>>
>>> [ 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 is hard to me -- for the GPIO I need the schematic which is not available, and for the PCIe analyzer we need hardware rework for that, but I will try.

At least from WLAN perspective, it should be well known pin for GPIO 
even without board schematic, right?  So should be relatively easy to 
look at with a scope.

> 
>>
>> It sounds to me that most likely what's going on is PME being asserted from WLAN controller.
> But I don;t see a PME interrupt fired on the root port:

Hmm.  I think then understanding what is happening to that GPIO over 
this suspend cycle when and how that maps to your expectations from the 
driver and firmware will be key.

Re: unexptect ACPI GPE wakeup on Lenovo platforms

[Baochen Qiang]

On 9/25/2024 11:46 AM, Mario Limonciello wrote:
> On 9/24/2024 21:18, Baochen Qiang wrote:
>>>
>>> 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.
>> seems GPP6 is notified, does this mean GPIO18 is NOT bound to WLAN wakeup pin? but instead it is bound to the PCIe root port?
> 
> There is a concept in AMD machines called "GPIO mirroring" where the status of a GPIO pin is mirrored into a GPE.
> 
> Particularly GPE 0xE is often mirroring AMD GPIO 18.  This can be changed by BIOS though, so Lenovo would have to confirm it is the case or not.
this does not make sense to me because in the test where ath11k kernel module is removed, the GPE 0xE is active but GPIO 18 is not. if GPE 0xE mirrors GPIO 18, should I expect GPIO 18 and GPE 0xE to be in same status? I mean both active or both inactive?

> 
> But it could explain why you see GPE 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?
>> not possible, it is soldered, not a M.2 module
> 
> Ah this makes it a lot harder for a debugging.  Is there option in BIOS to disable it?
I will check that. But to make it clear, by 'disable' you are meaning disable wakeup function of WLAN?

> 
>>>
>>>>
>>>> [ 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 is hard to me -- for the GPIO I need the schematic which is not available, and for the PCIe analyzer we need hardware rework for that, but I will try.
> 
> At least from WLAN perspective, it should be well known pin for GPIO even without board schematic, right?  So should be relatively easy to look at with a scope.
Ah, you remind me. We can check it with WLAN wakeup pin.

> 
>>
>>>
>>> It sounds to me that most likely what's going on is PME being asserted from WLAN controller.
>> But I don;t see a PME interrupt fired on the root port:
> 
> Hmm.  I think then understanding what is happening to that GPIO over this suspend cycle when and how that maps to your expectations from the driver and firmware will be key.
OK, so seems I have no option but to scope the GPIO.

> 
> 

Re: unexptect ACPI GPE wakeup on Lenovo platforms

[Mario Limonciello]

On 9/24/2024 23:02, Baochen Qiang wrote:
> 
> 
> On 9/25/2024 11:46 AM, Mario Limonciello wrote:
>> On 9/24/2024 21:18, Baochen Qiang wrote:
>>>>
>>>> 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.
>>> seems GPP6 is notified, does this mean GPIO18 is NOT bound to WLAN wakeup pin? but instead it is bound to the PCIe root port?
>>
>> There is a concept in AMD machines called "GPIO mirroring" where the status of a GPIO pin is mirrored into a GPE.
>>
>> Particularly GPE 0xE is often mirroring AMD GPIO 18.  This can be changed by BIOS though, so Lenovo would have to confirm it is the case or not.
> this does not make sense to me because in the test where ath11k kernel module is removed, the GPE 0xE is active but GPIO 18 is not. if GPE 0xE mirrors GPIO 18, should I expect GPIO 18 and GPE 0xE to be in same status? I mean both active or both inactive?
> 

Hmm, good point.  🤷 for now.

>>
>> But it could explain why you see GPE 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?
>>> not possible, it is soldered, not a M.2 module
>>
>> Ah this makes it a lot harder for a debugging.  Is there option in BIOS to disable it?
> I will check that. But to make it clear, by 'disable' you are meaning disable wakeup function of WLAN?

I'm meaning disable WLAN all together from BIOS.  It will drop off PCI bus.

I don't know if Lenovo BIOS exposes this, I've seen it on some platforms.

> 
>>
>>>>
>>>>>
>>>>> [ 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 is hard to me -- for the GPIO I need the schematic which is not available, and for the PCIe analyzer we need hardware rework for that, but I will try.
>>
>> At least from WLAN perspective, it should be well known pin for GPIO even without board schematic, right?  So should be relatively easy to look at with a scope.
> Ah, you remind me. We can check it with WLAN wakeup pin.
> OK, so seems I have no option but to scope the GPIO.

Yeah; unless some other guys on this D/L have any ideas here.

Re: unexptect ACPI GPE wakeup on Lenovo platforms

[Baochen Qiang]

On 9/25/2024 12:08 PM, Mario Limonciello wrote:
> On 9/24/2024 23:02, Baochen Qiang wrote:
>>
>>
>> On 9/25/2024 11:46 AM, Mario Limonciello wrote:
>>> On 9/24/2024 21:18, Baochen Qiang wrote:
>>>>>
>>>>> 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.
>>>> seems GPP6 is notified, does this mean GPIO18 is NOT bound to WLAN wakeup pin? but instead it is bound to the PCIe root port?
>>>
>>> There is a concept in AMD machines called "GPIO mirroring" where the status of a GPIO pin is mirrored into a GPE.
>>>
>>> Particularly GPE 0xE is often mirroring AMD GPIO 18.  This can be changed by BIOS though, so Lenovo would have to confirm it is the case or not.
>> this does not make sense to me because in the test where ath11k kernel module is removed, the GPE 0xE is active but GPIO 18 is not. if GPE 0xE mirrors GPIO 18, should I expect GPIO 18 and GPE 0xE to be in same status? I mean both active or both inactive?
>>
> 
> Hmm, good point.  🤷 for now.
> 
>>>
>>> But it could explain why you see GPE 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?
>>>> not possible, it is soldered, not a M.2 module
>>>
>>> Ah this makes it a lot harder for a debugging.  Is there option in BIOS to disable it?
>> I will check that. But to make it clear, by 'disable' you are meaning disable wakeup function of WLAN?
> 
> I'm meaning disable WLAN all together from BIOS.  It will drop off PCI bus.
> 
> I don't know if Lenovo BIOS exposes this, I've seen it on some platforms.
I manged to disable WLAN from BIOS. Now even with lspci I can not see the WLAN device and the PCI bridge to which WLAN is attached. and the GPP6 wakeup functionality is disabled:

# cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
...
GPP6      S4    *disabled
...

Now the issue is gone and I don't see any GPE 0xe or GPIO 18 active events during suspend cycle.

> 
>>
>>>
>>>>>
>>>>>>
>>>>>> [ 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 is hard to me -- for the GPIO I need the schematic which is not available, and for the PCIe analyzer we need hardware rework for that, but I will try.
>>>
>>> At least from WLAN perspective, it should be well known pin for GPIO even without board schematic, right?  So should be relatively easy to look at with a scope.
>> Ah, you remind me. We can check it with WLAN wakeup pin.
>> OK, so seems I have no option but to scope the GPIO.
> 
> Yeah; unless some other guys on this D/L have any ideas here.