Great ! Thanks for following up on this. 
Any chance to get a public list of issues identified and being worked on ? I understand there may be security sensitive issues sometimes but having a public list of functional issues like this one in the firmware or elsewhere in the stack (kernel…) would be useful.
Great question. Internal tickets are just that, internal by design. Some stuff however, ends up on Github when appropriate.
FYI I went back to 11th gen, and if you suspend and then plug in the charger, the system will wake.
Similarly on windows, if you suspend and then close the lid, the system will wake up to process the event and then go back to sleep again.
This is expected behavior because we have to send a SCI event to the APU to notify the OS that the system is now on AC. This needs to wake the OS so the OS sleep policy can change from AC->DC.
For example if you start sleeping on DC, the system will hibernate after some time on windows, but after you plug in AC, the system can stay in modern standby indefinitely.
On windows the OS will wake up to process the event, and then go back to sleep after a few seconds.
Then that could be an issue with Linux distros. Personally, on Arch Linux with KDE, if I close the lid on my laptop, sending it to hybrid sleep, and then plug it in to charge, it will wake up and stay awake, as I discovered last night. It doesn’t seem to process the lid being closed and simply goes awake because it’s been awoken by the firmware. Even worse with the behaviour of cutting AC when fully charged and letting the battery discharge to go back on AC for a moment; This behaviour seems to just keep my laptop awake.
Edit: This behaviour does not happen if my laptop went to hibernation. Since I use hybrid sleep unless the battery is low, it can sometimes wake up and behave in all the ways I’ve described.
Hmm, I wonder how this can be handled similarly in Linux. A kernel module? I was already thinking of writing one to handle this after seeing a framework kernel module on the Discord that was reading from the EC somehow.
Or maybe a service that runs on resume, checks if the lid is closed and re-suspends?
And I mean, what you’re saying makes sense but I’ve not seen this behavior before. Is this behavior some new standard behavior? Still, the ability to disable to disable wakes would be cool.
There are plenty of options for running a script of your choice on power and lid events, so this shouldn’t be hard to accomplish, yeah, no kernel programming needed.
The hard part is not conflicting with everybody else who thinks they should drive the computer: if systemd thinks it owns power events, and GNOME thinks it owns power events, and acpid thinks it owns power events… it’s a mess, especially if e.g. you want things to work both on a kernel console and in a desktop environment—or maybe even in more than one.
At some point my old laptop would occasionally wake up and immediately go back to sleep again, because two services were racing to put it in suspend and one of them winning did not kill the other. Then it stopped doing that. And I had to give up on figuring what part of the GNOME monolith was responsible for that mess. (At this rate, I’m going to have to give up on GNOME itself because of all this opaqueness, but I don’t wanna…) And I could never get it to wake up reliably if I closed the lid and opened it back again too quickly.
Fundamentally, the problem seems to be that lid, power, etc. events are edge- rather than level-triggered, that is, the question is not “the lid is currently closed, what state do we want the system to be in?”, but “the lid just closed, what do we do?” That’s just a bad approach in general, but other systems can get away with it because they have much less software diversity than the Linux ecosystem (which obtains most of its value from that diversity).
Sorry for the rant. TL;DR is you should be able to patch this over with a script, but the most reliable approach is likely to be figuring out what responds to lid and power events on your system, then tracking down its developers and slapping them with this bug (gently) until they fix it. Or at this point you might as well fix it yourself.
ACPI is a very messy affair. This wakeup is coming from the EC and I haven’t been able to disable it through /proc/acpi/wakeup. Based on my light research, it needs to be read from the EC through the so I’m not going to bet on any universal solution being picked up for quirks like this.cros module
Scratch that, I’m making some process on disabling wakeups using udev
Ah, I might’ve misunderstood which solution you wanted. My first idea was to make the system suspend back again if it’s woken up with the lid closed, because from @Kieran_Levin’s description it sounded like the firmware waking the OS when the laptop’s plugged or unplugged is just the new normal in this S3-less world we’re now in, and is not actually Framework-specific. So deal with the spurious wakeup rather than trying to make it not happen. But now I’m not sure.
Spurious wakeup is rather problematic. Given that the system can cycle the AC-DC state when you’re fully charged, your system never sleeps if left on the charge. That means you should just shutdown or hibernate if you’ll leave it to charge. Almost makes me not want to use sleep at all and just make my system hibernate the moment the lid is closed just to have a predictable behaviour.
I just was discussing this with our friends at AMD. One thought they had is that when the system wakes up from a lid open or ac adapter event, these will be happened by the kernel s2idle loop.
As part of the wakeup process, they thought there may be a second interrupt that is triggered. For example a GPIO event that also transitions as part of the S0i3->S0 which may cause linux to stay awake.
This may be a good exploration direction.
I don’t have a laptop in hand yet to try this with, but I bet you could use this indicator with a systemd timer that runs say, every 30s. If the lid is closed for two consecutive events, you put the system to sleep.
Hacky, but workable 
Alright, here’s the deal. I disabled the Lid Switch /sys/*/power/wakeup, but that didn’t do it. Me and a friend did some more testing and found out that when you close the lid, it sends two wake-ups, one from the Lid Switch and another is a wake-up from the keyboard! When you plug in the AC, it also sends a keyboard wake-up! I’ll post some udev rules soon to disable this soon!
Isn’t that controlled by a BIOS setting on the 11 gen? On this 11 gen system for example (Fedora 38 with BIOS 3.17 and the that wake on AC option disabled), I’ve never seen this behavior.
Editing: I hadn’t used the power on when AC attached option and had mis-remembered what it does. It doesn’t apply to resuming.
Anyway, just for posterity, the steps below are the same, so resume-on-AC-attach does not appear to be a thing on 11th gen (and more recent comments below suggest it can be traced to AMD-specific EC source code anyway - so, misunderstanding corrected).
Just tested now:
(Suspend is configured to s2idle on this machine)
Just out of curiosity, what does /proc/acpi/wakeup look like on the AMD system?
FWIW I use this, run from a systemd unit, to disable wakeups from my external keyboard on a gen 11 system:
#!/usr/bin/bash
for device in `tail -n +2 /proc/acpi/wakeup |egrep -v 'PWRB|PXSX' |grep enabled |cut -f 1`; do
echo "disabling $device"
sh -c "echo $device > /proc/acpi/wakeup"
done
Disabling everything in /proc/acpi/wakeup didn’t fix the lid issue but here’s the print out
> enzi@ultraportable: ~/projects/ec-patches
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
GPP0 S4 *disabled
GPP1 S4 *disabled
GPP2 S4 *disabled
GPP5 S4 *disabled
GPP6 S4 *enabled pci:0000:00:02.2
GPP7 S4 *disabled
GP11 S4 *enabled pci:0000:00:03.1
SWUS S4 *disabled
GP12 S4 *enabled pci:0000:00:04.1
SWUS S4 *disabled
XHC0 S3 *enabled pci:0000:c1:00.3
XHC1 S3 *enabled pci:0000:c1:00.4
XHC2 S3 *enabled pci:0000:c3:00.0
NHI0 S4 *enabled pci:0000:c3:00.5
XHC3 S3 *enabled pci:0000:c3:00.3
NHI1 S4 *enabled pci:0000:c3:00.6
XHC4 S3 *enabled pci:0000:c3:00.4
One theory I have is that this code in the EC may be causing an additional interrupt to the host on wake:
When we go from S0i3 to S0ix, the EC will send some dummy key presses to the host so the keyboard will keep working. This may cause the host to wake up to screen on, and stay there.
I think you’re right! I fixed most of my issues with the wakeups using the following rules that I put in the /dev/rules.d/ folder:
/etc/udev/rules.d/20-suspend-fixes.rules
ACTION=="add", SUBSYSTEM=="acpi", DRIVERS=="button", ATTRS{hid}=="PNP0C0D", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled
The second line disables the keyboard from waking the PC, which fixes the lid waking the machine (along with the first line) AND the AC being plugged in (which sends a keyboard wakeup as well). You lose the keyboard wake-ups but the touchpad and everything else work fine.
I noticed you linked to your GitHub. Is there a guide for consumers to customize and flash their own EC? I haven’t done the research yet.
Seems like it kills lid open wake up too for me.
Try removing the first line and see if it disables wake-on-close but not wake-on-open.
As an aside, how did you track down the particular identifiers to use for the rules? Especially PNP0C0D for the lid?