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
