Re: Backport using Microsoft GUID for s2idle on AMD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/5/2023 01:45, Greg KH wrote:
On Wed, Jan 04, 2023 at 07:46:58PM +0000, Limonciello, Mario wrote:
[Public]

Hi,

At *least* 9 models of laptops across manufacturers have problems with suspend that are root caused
to the firmware not properly implementing an AMD specific codepath, but that did implement a
Microsoft specific one properly. To fix the suspend issues on Linux, a number of commits have been
worked out over the last few kernel releases.

We have eventually landed at we're going to just use the Microsoft codepath in Linux.

That is the correct solution as that is the only codepath that vendors
test.  And it's what we do for the rest of ACPI, and have done, for
decades now.  Odd that it wasn't the way this was done originally.

Yup :/


All the patches to accomplish this are now landed in 6.2-rc1, and also in 6.1.3.

Now that have this all working satisfactorily I'd like to bring those fixes into 6.0.y and 5.15.y as well.

Here is the series of commits for 6.0.y:

100a57379380 ACPI: x86: s2idle: Move _HID handling for AMD systems into structures
fd894f05cf30 ACPI: x86: s2idle: If a new AMD _HID is missing assume Rembrandt
a0bc002393d4 ACPI: x86: s2idle: Add module parameter to prefer Microsoft GUID
d0f61e89f08d ACPI: x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE
ddeea2c3cb88 ACPI: x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14
888ca9c7955e ACPI: x86: s2idle: Add a quirk for Lenovo Slim 7 Pro 14ARH7
631b54519e8e ACPI: x86: s2idle: Add a quirk for ASUSTeK COMPUTER INC. ROG Flow X13
39f81776c680 ACPI: x86: s2idle: Fix a NULL pointer dereference
54bd1e548701 ACPI: x86: s2idle: Add another ID to s2idle_dmi_table
577821f756cf ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP Elitebook 865
e6d180a35bc0 ACPI: x86: s2idle: Stop using AMD specific codepath for Rembrandt+

6.0 is about to go end-of-life in a few days, so this isn't needed.

Got it; thanks.


Here is the series of commits for 5.15.y:

ed470febf837 ACPI: PM: s2idle: Add support for upcoming AMD uPEP HID AMDI008
1a2dcab517cb ACPI: PM: s2idle: Use LPS0 idle if ACPI_FADT_LOW_POWER_S0 is unset
100a57379380 ACPI: x86: s2idle: Move _HID handling for AMD systems into structures
fd894f05cf30 ACPI: x86: s2idle: If a new AMD _HID is missing assume Rembrandt
a0bc002393d4 ACPI: x86: s2idle: Add module parameter to prefer Microsoft GUID
d0f61e89f08d ACPI: x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE
ddeea2c3cb88 ACPI: x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14
888ca9c7955e ACPI: x86: s2idle: Add a quirk for Lenovo Slim 7 Pro 14ARH7
631b54519e8e ACPI: x86: s2idle: Add a quirk for ASUSTeK COMPUTER INC. ROG Flow X13
39f81776c680 ACPI: x86: s2idle: Fix a NULL pointer dereference
54bd1e548701 ACPI: x86: s2idle: Add another ID to s2idle_dmi_table
577821f756cf ACPI: x86: s2idle: Force AMD GUID/_REV 2 on HP Elitebook 865
e6d180a35bc0 ACPI: x86: s2idle: Stop using AMD specific codepath for Rembrandt+

Can you please backport these for a future stable release?

That's adding new features for an old kernel, what's keeping people with
this hardware from using the 6.1 kernel instead?  What distros are
insisting that this needs to be in 5.15.y?

thanks,

greg k-h

I don't believe it's a new feature..

The Microsoft GUID was already available and usable in 5.15.y, but the policy was set for AMDI0007 (which is used for Rembrandt) to pick the AMD GUID. This helps Rembrandt laptops that otherwise work well with 5.15.y.

Ubuntu 22.04 and Ubuntu 20.04 both track 5.15.y still.

But you prompted me to realize a MUCH easier solution for 5.15.y.
Just revert this commit:

f0c6225531e4 ("ACPI: PM: Add support for upcoming AMD uPEP HID AMDI007")

That will effectively line up Rembrandt with what is in 6.1.y and 6.2 already without needing that bigger list of patches.



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux