[Bug 218305] Ryzen 7 7840HS gets stuck at 544MHz frequency after resuming after unplugging the power cord during sleep

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=218305

Mario Limonciello (AMD) (mario.limonciello@amd.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #121 from Mario Limonciello (AMD) (mario.limonciello@amd.com) ---
> I never tested removing the patch
> (https://github.com/torvalds/linux/commit/4dbd11796f3a8eb95647507befc41995458a4023).
>  Is that something I should do?  I'm happy to do additional testing for a
> permanent solution.

If the quirk patch works for you; I don't see a need to do that.

> So just curious, what are the next steps?  Is this going to be pushed to the
> mainline?

Let me re-open this so we can talk about what to do about it.

The OEM's EC is an opaque black box.
This /seems/ to be a race condition with the Linux kernel and the EC.

* Upstreaming the quirk is one possibility.
This means that every time we see this we add to the quirk list.

* Adding a delay for all hardware is another possibility.  
This seems relatively unfair to other hardware not affected by this issue.

* Look into whether there is anything different in what's sent to the EC in the
delay vs no delay case.  I thought that there shouldn't be anything different
since we're in the s2idle loop, but you can double check this by:

1) Turning on dynamic debug messages for drivers/acpi/ec.c.
2) Run sequence to reproduce issue on unpatched kernel.
3) Run sequence to reproduce issue on patched kernel.
4) Compare the sequences and see if there are any extra events in the patched
kernel.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.