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.
