sudo udevadm info -p -a /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:44/PNP0C09:00/PNP0C0D:00
I found the device by creating a script that tests disabling every result of:
find /sys -wholename "**/power/wakeup"
No clue.
3 Likes
Thank you for this! Using the second rule makes suspend work as expected on Debian Testing. That is, I can close the lid, automatically suspend, unplug and plug power without waking, then open the lid and have the machine wake.
I can also sleep from menu, close the lid and the machine will not wake, just from the second rule. It seems plug/unplug sending keycodes is the problem here.
2 Likes
No such luck here with those udev rules. Plugging in my power adapter still wakes the laptop 
I missed something! There’s a missing quote at the end of the udev rule here and I totally didn’t catch it last night
The full rule is
ACTION=="add", SUBSYSTEM=="acpi", DRIVERS=="button", ATTRS{hid}=="PNP0C0D", ATTR{power/wakeup}="disabled"
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled"
7 Likes
Echoing the success of others in this thread - adding the second udev rule listed above to disable waking by keyboard keeps the laptop from fully waking up from power plug/unplug. Is this function in the EC necessary for all systems, or is it just a workaround for a specific setup? I ask because I think that this side-effect (waking for power events unnecessarily) is undesirable and am curious if it may be properly fixable further down the line so that we don’t have to just disable waking by keyboard (not the end of the world, but I’d rather have it than not).
4 Likes
I can confirm that @Enzious’ approach works
/etc/udev/rules.d/20-suspend-fixes.rules
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled"
fixes the problem for me.
Thanks a lot.
4 Likes
The second udev rule by @Enzious seems to be working around the wake up from plugging/unplugging power as well as waking up by closing the lid when already in standby for me.
udevadm control --reload-rules && udevadm trigger was seemingly not enough to apply it instantly, a reboot did the trick on Arch.
2 Likes
If I may ask — has there been any movement on this fix landing upstream?
I am aware that there is a udev workaround, and a user workaround whereby I don’t suspend the laptop before closing the lid.
The problem for me is that I don’t trust my machines to do that. I’ve used linux for over 10 years, and I have a deep-seated mistrust of suspend just not working properly on lid close.
But I will try to overcome it 
3 Likes
I’ve sent this patch series to the mailing list to add a workaround in the kernel for the EC behavior (at least with BIOS 03.03). I would expect there is no need for a udev rule with this in place.
[PATCH 0/4] Add a workaround for Framework 13 spurious IRQ1 (kernel.org)
If you prefer the old behavior (which allows “real” wake from keyboard to work) and have this patch, there is a module parameter you can put on your kernel command line amd_pmc.disable_workarounds=1.
16 Likes
I received and installed my new AMD mainboard/RAM/Wificard, and lid closing going to suspend seemed to work fine until today I think. Fedora 39, might be the new kernel? Either way, not a huge deal to suspend then close the lid, but still.
Turns out when swapping mainboards I broke the little latch for the audio board (thankfully on that site and not the mainboard) so I ordered a new one. I bet that’ll fix it, since I think the lid sensor is on that lil board.
EDIT: And it was. New audioboard fixed it.
2 Likes
This is now in 6.7-rc7 and I can confirm it works for me, thanks!
1 Like
I have a brand new 7640U with the 3.03 BIOS, Fedora 39.
When I set the max charge to 80% in the BIOS, have the laptop plugged, close the lid, it is going to sleep without issue. But when it reaches 80% it is waking up.
If I set the max charge to 90 or 100%, I don´t have the issue and it keeps sleeping when it reaches the max charge.
It will also wake up when it is sleeping without being connected to the mains and if I connect the charger to an USB-C port.
If you reproduce the behavior with the s2idle script you can confirm what the wake source is when this happens. Just program the script for longer than it takes to charge up and suspend with script instead of lid.
My guess is this is either an EC bug or it’s a manifestation of the keyboard wakeup bug.
You can manually turn off keyboard wakeup in sysfs or update to 6.7-rc7 or later to pick up the kernel workaround for the keyboard wakeup issue.
1 Like
Strange, I am now unable to reproduce the problem anymore.
I will try more test and come back here to report if I find something.
Udev workaround is set to a one liner in the docs; looks for the file, if there, stops. If not, creates and appends the needed bits. Ubuntu team has been notified as well.
1 Like
Uhm, is there a tutorial to curb all this aggressive wake up behavior? I hoped for 3.05 to fix these annoyances but unfortunately there was no improvement in this department.
The framework constantly wakes up when interacting with it. Closing the lid of a sleeping FW wakes it, plugging in a charger wakes it (even when the lid is closed)… Worst is when you want to use the laptop a few days later only to discover that the battery is empty.
I expected some teething issue for early adopters of the AMD framework and BIOS fixes in due time but its been half a year now with next to no progress. 
Yes, you can fix this by adding a udev rule. You just need to copy the rule in this post to /etc/udev/rules.d/20-suspend-fixes.rules and reboot.
3 Likes
@Ceremony, from @Mario_Limonciello’s post, it seems this issue should be fixed in Kernel 6.7+. I had the Suspend with lid while attached to power workaround in place until Kernel 6.7 (or later, I can’t remember exactly). But, currently I’m on Kernel 6.8.6-200.fc39.x86_64 (Fedora 39) and have not experienced this issue without the workaround for many weeks now.
If you’re still running into the lid wakeup issue, you could upgrade to the latest kernel. Or, if that’s not an option, apply the workaround until you can upgrade to Kernel 6.7+.
1 Like
That “fix” was just a work-around, that they didn’t want to be stuck with forever, so they made it apply only for firmware 3.03, assuming the next firmware would fix the real bug (in the firmware). But it didn’t, so in a later kernel patch release they’ll have to update it to also apply to 3.05
2 Likes