Created attachment 301775 [details] dmesg The GPE of TBT's power resource gets toggled: [ 186.866656] PM: suspend-to-idle [ 186.866772] ACPI: EC: ACPI EC GPE status set [ 186.866802] ACPI: PM: Rearming ACPI SCI for wakeup [ 192.934925] Timekeeping suspended for 5.659 seconds [ 192.935494] ACPI: PM: ACPI non-EC GPE wakeup [ 192.935513] PM: resume from suspend-to-idle
Created attachment 301776 [details] lspci -vvnn
Preferably Linux should have a "wakeup reason" so the kernel can decide to go back to sleep again, but it may not be feasible with current suspend flow, so maybe a firmware tweak at TBT host is more plausible.
Hi, Will you let us know the behavior you saw in : 1. ADL vs TGL 2. Linux vs Windows With same device and OS configuration.
The wakeup in TGL-H when unplugging a device in s2idle (or Modern Standby in Windows terms) is a platform feature. So this is not a bug.
In the ADL-P. the system doesn't wake up after unplug TBT devices. but the TGL-U/H, we can see the wake up. Do you have such document can share the feature details for reference? and Windows is wakeup by power source changed. but in Linux, it's not an AC power wake and wake by TBT. The GPE of TBT's power resource gets toggled: [ 186.866656] PM: suspend-to-idle [ 186.866772] ACPI: EC: ACPI EC GPE status set [ 186.866802] ACPI: PM: Rearming ACPI SCI for wakeup [ 192.934925] Timekeeping suspended for 5.659 seconds [ 192.935494] ACPI: PM: ACPI non-EC GPE wakeup [ 192.935513] PM: resume from suspend-to-idle
It could be due to SW_CM (ADL) vs FM_CM (TGL) result the different configurations. > but in Linux, it's not an AC power wake and wake by TBT. Yes, it's control by TBT FW.
That's make sense, will you debug the TBT CM FW to fix the issue?
As it's a platform feature, there is no plan to fix or change the behavior.
Do you have any TA or documents can share about the behavior?