2022-09-12 17:27:20

by Mario Limonciello

[permalink] [raw]
Subject: [PATCH v2 0/6] Fixups for s2idle on various Rembrandt laptops

It was reported that an ASUS Rembrandt laptop has problems with seemingly
unrelated ACPI events after resuming from s2idle. Debugging the issue
proved it's because ASUS has ASL that is only called when using the
Microsoft GUID, not the AMD GUID.

This is a bug from ASUS firmware but this series reworks the s2idle
handling for AMD to allow accounting for this in a quirk.

Additionally as this is a problem that may pop up again on other models
add a module parameter that can be used to try the Microsoft GUID on a
given system.

This module parameter intentionally applies to both Intel and AMD systems
as the same problem could potentially exist on Intel systems that support
both the Intel GUID or the Microsoft GUID.

v1->v2:
* Add two more systems that are reported to be helped by this series.

Mario Limonciello (6):
acpi/x86: s2idle: Move _HID handling for AMD systems into structures
acpi/x86: s2idle: If a new AMD _HID is missing assume Rembrandt
acpi/x86: s2idle: Add module parameter to prefer Microsoft GUID
acpi/x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE
acpi/x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14
acpi/x86: s2idle: Add a quirk for Lenovo Slim 7 Pro 14ARH7

drivers/acpi/x86/s2idle.c | 124 ++++++++++++++++++++++++++++++--------
1 file changed, 100 insertions(+), 24 deletions(-)

--
2.34.1


2022-09-12 17:29:17

by Mario Limonciello

[permalink] [raw]
Subject: [PATCH v2 5/6] acpi/x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14

ASUS ROG Zephyrus G14 is affected by the same BIOS bug as ASUS TUF
Gaming A17 where important ASL is not called in the AMD code path.
Use the Microsoft codepath instead.

Reported-and-suggested-by: Philipp Zabel <[email protected]>
Signed-off-by: Mario Limonciello <[email protected]>
---
v1->v2:
* New patch
---
drivers/acpi/x86/s2idle.c | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index 9ee734e0c3c5..4bdc7133d2ea 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -420,6 +420,14 @@ static const struct dmi_system_id s2idle_dmi_table[] __initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "ASUS TUF Gaming A17"),
},
},
+ {
+ /* ASUS ROG Zephyrus G14 (2022) */
+ .callback = lps0_prefer_microsoft,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ROG Zephyrus G14 GA402"),
+ },
+ },
{}
};

--
2.34.1

2022-09-12 17:40:56

by Mario Limonciello

[permalink] [raw]
Subject: [PATCH v2 6/6] acpi/x86: s2idle: Add a quirk for Lenovo Slim 7 Pro 14ARH7

Lenovo Slim 7 Pro 14ARH7 has a sporadically non-functional keyboard
when resuming from s2idle. This is caused by some missing calls to the
EC that don't occur in the AMD codepath but only in the Microsoft codepath.

Add the system to the quirk list to force Microsoft codepath.

Reported-by: Travis Glenn Hansen <[email protected]>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216473
Signed-off-by: Mario Limonciello <[email protected]>
---
v1->v2:
* New patch
---
drivers/acpi/x86/s2idle.c | 11 +++++++++++
1 file changed, 11 insertions(+)

diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index 4bdc7133d2ea..8475a3915812 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -428,6 +428,17 @@ static const struct dmi_system_id s2idle_dmi_table[] __initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "ROG Zephyrus G14 GA402"),
},
},
+ {
+ /*
+ * Lenovo Slim 7 Pro X 14ARH7
+ * https://bugzilla.kernel.org/show_bug.cgi?id=216473
+ */
+ .callback = lps0_prefer_microsoft,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "82V2"),
+ },
+ },
{}
};

--
2.34.1

2022-09-12 17:44:27

by Mario Limonciello

[permalink] [raw]
Subject: [PATCH v2 1/6] acpi/x86: s2idle: Move _HID handling for AMD systems into structures

Right now the information about which cases to use for what are in a
comment, but this is error prone. Instead move all information into
a dedicated structure.

Tested-by: [email protected]
Signed-off-by: Mario Limonciello <[email protected]>
---
drivers/acpi/x86/s2idle.c | 63 ++++++++++++++++++++++++++++-----------
1 file changed, 46 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index f9ac12b778e6..a7757551f750 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -363,6 +363,39 @@ static int validate_dsm(acpi_handle handle, const char *uuid, int rev, guid_t *d
return ret;
}

+struct amd_lps0_hid_device_data {
+ const unsigned int rev_id;
+ const bool check_off_by_one;
+ const bool prefer_amd_guid;
+};
+
+static const struct amd_lps0_hid_device_data amd_picasso = {
+ .rev_id = 0,
+ .check_off_by_one = true,
+ .prefer_amd_guid = false,
+};
+
+static const struct amd_lps0_hid_device_data amd_cezanne = {
+ .rev_id = 0,
+ .check_off_by_one = false,
+ .prefer_amd_guid = false,
+};
+
+static const struct amd_lps0_hid_device_data amd_rembrandt = {
+ .rev_id = 2,
+ .check_off_by_one = false,
+ .prefer_amd_guid = true,
+};
+
+static const struct acpi_device_id amd_hid_ids[] = {
+ {"AMD0004", (kernel_ulong_t)&amd_picasso, },
+ {"AMD0005", (kernel_ulong_t)&amd_picasso, },
+ {"AMDI0005", (kernel_ulong_t)&amd_picasso, },
+ {"AMDI0006", (kernel_ulong_t)&amd_cezanne, },
+ {"AMDI0007", (kernel_ulong_t)&amd_rembrandt, },
+ {}
+};
+
static int lps0_device_attach(struct acpi_device *adev,
const struct acpi_device_id *not_used)
{
@@ -370,31 +403,27 @@ static int lps0_device_attach(struct acpi_device *adev,
return 0;

if (acpi_s2idle_vendor_amd()) {
- /* AMD0004, AMD0005, AMDI0005:
- * - Should use rev_id 0x0
- * - function mask > 0x3: Should use AMD method, but has off by one bug
- * - function mask = 0x3: Should use Microsoft method
- * AMDI0006:
- * - should use rev_id 0x0
- * - function mask = 0x3: Should use Microsoft method
- * AMDI0007:
- * - Should use rev_id 0x2
- * - Should only use AMD method
- */
- const char *hid = acpi_device_hid(adev);
- rev_id = strcmp(hid, "AMDI0007") ? 0 : 2;
+ static const struct acpi_device_id *dev_id;
+ const struct amd_lps0_hid_device_data *data;
+
+ for (dev_id = &amd_hid_ids[0]; dev_id->id[0]; dev_id++)
+ if (acpi_dev_hid_uid_match(adev, dev_id->id, NULL))
+ break;
+ if (dev_id != NULL)
+ data = (const struct amd_lps0_hid_device_data *) dev_id->driver_data;
+ else
+ return 0;
+ rev_id = data->rev_id;
lps0_dsm_func_mask = validate_dsm(adev->handle,
ACPI_LPS0_DSM_UUID_AMD, rev_id, &lps0_dsm_guid);
lps0_dsm_func_mask_microsoft = validate_dsm(adev->handle,
ACPI_LPS0_DSM_UUID_MICROSOFT, 0,
&lps0_dsm_guid_microsoft);
- if (lps0_dsm_func_mask > 0x3 && (!strcmp(hid, "AMD0004") ||
- !strcmp(hid, "AMD0005") ||
- !strcmp(hid, "AMDI0005"))) {
+ if (lps0_dsm_func_mask > 0x3 && data->check_off_by_one) {
lps0_dsm_func_mask = (lps0_dsm_func_mask << 1) | 0x1;
acpi_handle_debug(adev->handle, "_DSM UUID %s: Adjusted function mask: 0x%x\n",
ACPI_LPS0_DSM_UUID_AMD, lps0_dsm_func_mask);
- } else if (lps0_dsm_func_mask_microsoft > 0 &&
+ } else if (lps0_dsm_func_mask_microsoft > 0 && data->prefer_amd_guid &&
(!strcmp(hid, "AMDI0007") ||
!strcmp(hid, "AMDI0008"))) {
lps0_dsm_func_mask_microsoft = -EINVAL;
--
2.34.1

2022-09-12 17:51:37

by Mario Limonciello

[permalink] [raw]
Subject: [PATCH v2 2/6] acpi/x86: s2idle: If a new AMD _HID is missing assume Rembrandt

A mistake was made that only AMDI0007 was set to rev of "2", but
it should have been also set for AMDI008. If an ID is missing from
the _HID table, then assume it matches Rembrandt behavior.

This implicitly means that if any other behavior changes happen
in the future missing IDs must be added to that table.

Tested-by: [email protected]
Signed-off-by: Mario Limonciello <[email protected]>
---
drivers/acpi/x86/s2idle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index a7757551f750..a8256e5a0e8a 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -412,7 +412,7 @@ static int lps0_device_attach(struct acpi_device *adev,
if (dev_id != NULL)
data = (const struct amd_lps0_hid_device_data *) dev_id->driver_data;
else
- return 0;
+ data = &amd_rembrandt;
rev_id = data->rev_id;
lps0_dsm_func_mask = validate_dsm(adev->handle,
ACPI_LPS0_DSM_UUID_AMD, rev_id, &lps0_dsm_guid);
--
2.34.1

2022-09-12 17:51:43

by Mario Limonciello

[permalink] [raw]
Subject: [PATCH v2 3/6] acpi/x86: s2idle: Add module parameter to prefer Microsoft GUID

OEMs have made some mistakes in the past for the AMD GUID support
and not populated the method properly. To add an escape hatch for
this problem introduce a module parameter that can force using
the Microsoft GUID.

This is intentionally introduced to both Intel and AMD codepaths
to allow using the parameter as a debugging tactic on either.

Signed-off-by: Mario Limonciello <[email protected]>
---
drivers/acpi/x86/s2idle.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index a8256e5a0e8a..a9b0f2b54a1c 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -27,6 +27,10 @@ static bool sleep_no_lps0 __read_mostly;
module_param(sleep_no_lps0, bool, 0644);
MODULE_PARM_DESC(sleep_no_lps0, "Do not use the special LPS0 device interface");

+static bool prefer_microsoft_guid __read_mostly;
+module_param(prefer_microsoft_guid, bool, 0644);
+MODULE_PARM_DESC(prefer_microsoft_guid, "Prefer selecting Microsoft GUID for LPS0 device");
+
static const struct acpi_device_id lps0_device_ids[] = {
{"PNP0D80", },
{"", },
@@ -402,6 +406,9 @@ static int lps0_device_attach(struct acpi_device *adev,
if (lps0_device_handle)
return 0;

+ lps0_dsm_func_mask_microsoft = validate_dsm(adev->handle,
+ ACPI_LPS0_DSM_UUID_MICROSOFT, 0,
+ &lps0_dsm_guid_microsoft);
if (acpi_s2idle_vendor_amd()) {
static const struct acpi_device_id *dev_id;
const struct amd_lps0_hid_device_data *data;
@@ -416,16 +423,12 @@ static int lps0_device_attach(struct acpi_device *adev,
rev_id = data->rev_id;
lps0_dsm_func_mask = validate_dsm(adev->handle,
ACPI_LPS0_DSM_UUID_AMD, rev_id, &lps0_dsm_guid);
- lps0_dsm_func_mask_microsoft = validate_dsm(adev->handle,
- ACPI_LPS0_DSM_UUID_MICROSOFT, 0,
- &lps0_dsm_guid_microsoft);
if (lps0_dsm_func_mask > 0x3 && data->check_off_by_one) {
lps0_dsm_func_mask = (lps0_dsm_func_mask << 1) | 0x1;
acpi_handle_debug(adev->handle, "_DSM UUID %s: Adjusted function mask: 0x%x\n",
ACPI_LPS0_DSM_UUID_AMD, lps0_dsm_func_mask);
} else if (lps0_dsm_func_mask_microsoft > 0 && data->prefer_amd_guid &&
- (!strcmp(hid, "AMDI0007") ||
- !strcmp(hid, "AMDI0008"))) {
+ !prefer_microsoft_guid) {
lps0_dsm_func_mask_microsoft = -EINVAL;
acpi_handle_debug(adev->handle, "_DSM Using AMD method\n");
}
@@ -433,7 +436,8 @@ static int lps0_device_attach(struct acpi_device *adev,
rev_id = 1;
lps0_dsm_func_mask = validate_dsm(adev->handle,
ACPI_LPS0_DSM_UUID, rev_id, &lps0_dsm_guid);
- lps0_dsm_func_mask_microsoft = -EINVAL;
+ if (!prefer_microsoft_guid)
+ lps0_dsm_func_mask_microsoft = -EINVAL;
}

if (lps0_dsm_func_mask < 0 && lps0_dsm_func_mask_microsoft < 0)
--
2.34.1

2022-09-12 17:52:05

by Mario Limonciello

[permalink] [raw]
Subject: [PATCH v2 4/6] acpi/x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE

ASUS TUF Gaming A17 FA707RE has problems with ACPI events after
s2idle resume. It's from a missing call to an ASL method in AMD
the s2idle calling path. Force the system to use the Microsoft
Modern Standby calling path instead.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=216101
Reported-and-tested-by: [email protected]
Signed-off-by: Mario Limonciello <[email protected]>
---
v1->v2:
* Fixup for __init
---
drivers/acpi/x86/s2idle.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
index a9b0f2b54a1c..9ee734e0c3c5 100644
--- a/drivers/acpi/x86/s2idle.c
+++ b/drivers/acpi/x86/s2idle.c
@@ -17,6 +17,7 @@

#include <linux/acpi.h>
#include <linux/device.h>
+#include <linux/dmi.h>
#include <linux/suspend.h>

#include "../sleep.h"
@@ -400,6 +401,28 @@ static const struct acpi_device_id amd_hid_ids[] = {
{}
};

+static int lps0_prefer_microsoft(const struct dmi_system_id *id)
+{
+ pr_debug("Preferring Microsoft GUID.\n");
+ prefer_microsoft_guid = true;
+ return 0;
+}
+
+static const struct dmi_system_id s2idle_dmi_table[] __initconst = {
+ {
+ /*
+ * ASUS TUF Gaming A17 FA707RE
+ * https://bugzilla.kernel.org/show_bug.cgi?id=216101
+ */
+ .callback = lps0_prefer_microsoft,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "ASUS TUF Gaming A17"),
+ },
+ },
+ {}
+};
+
static int lps0_device_attach(struct acpi_device *adev,
const struct acpi_device_id *not_used)
{
@@ -566,8 +589,9 @@ static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
.end = acpi_s2idle_end,
};

-void acpi_s2idle_setup(void)
+void __init acpi_s2idle_setup(void)
{
+ dmi_check_system(s2idle_dmi_table);
acpi_scan_add_handler(&lps0_handler);
s2idle_set_ops(&acpi_s2idle_ops_lps0);
}
--
2.34.1

2022-09-13 17:58:32

by Philipp Zabel

[permalink] [raw]
Subject: Re: [PATCH v2 1/6] acpi/x86: s2idle: Move _HID handling for AMD systems into structures

Am Mon, Sep 12, 2022 at 12:23:55PM -0500 schrieb Mario Limonciello:
> Right now the information about which cases to use for what are in a
> comment, but this is error prone. Instead move all information into
> a dedicated structure.
>
> Tested-by: [email protected]
> Signed-off-by: Mario Limonciello <[email protected]>
> ---
> drivers/acpi/x86/s2idle.c | 63 ++++++++++++++++++++++++++++-----------
> 1 file changed, 46 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
> index f9ac12b778e6..a7757551f750 100644
> --- a/drivers/acpi/x86/s2idle.c
> +++ b/drivers/acpi/x86/s2idle.c
> @@ -363,6 +363,39 @@ static int validate_dsm(acpi_handle handle, const char *uuid, int rev, guid_t *d
> return ret;
> }
>
> +struct amd_lps0_hid_device_data {
> + const unsigned int rev_id;
> + const bool check_off_by_one;
> + const bool prefer_amd_guid;
> +};
> +
> +static const struct amd_lps0_hid_device_data amd_picasso = {
> + .rev_id = 0,
> + .check_off_by_one = true,
> + .prefer_amd_guid = false,
> +};
> +
> +static const struct amd_lps0_hid_device_data amd_cezanne = {
> + .rev_id = 0,
> + .check_off_by_one = false,
> + .prefer_amd_guid = false,
> +};
> +
> +static const struct amd_lps0_hid_device_data amd_rembrandt = {
> + .rev_id = 2,
> + .check_off_by_one = false,
> + .prefer_amd_guid = true,
> +};
> +
> +static const struct acpi_device_id amd_hid_ids[] = {
> + {"AMD0004", (kernel_ulong_t)&amd_picasso, },
> + {"AMD0005", (kernel_ulong_t)&amd_picasso, },
> + {"AMDI0005", (kernel_ulong_t)&amd_picasso, },
> + {"AMDI0006", (kernel_ulong_t)&amd_cezanne, },
> + {"AMDI0007", (kernel_ulong_t)&amd_rembrandt, },
> + {}
> +};
> +
> static int lps0_device_attach(struct acpi_device *adev,
> const struct acpi_device_id *not_used)
> {
> @@ -370,31 +403,27 @@ static int lps0_device_attach(struct acpi_device *adev,
> return 0;
>
> if (acpi_s2idle_vendor_amd()) {
> - /* AMD0004, AMD0005, AMDI0005:
> - * - Should use rev_id 0x0
> - * - function mask > 0x3: Should use AMD method, but has off by one bug
> - * - function mask = 0x3: Should use Microsoft method
> - * AMDI0006:
> - * - should use rev_id 0x0
> - * - function mask = 0x3: Should use Microsoft method
> - * AMDI0007:
> - * - Should use rev_id 0x2
> - * - Should only use AMD method
> - */
> - const char *hid = acpi_device_hid(adev);
> - rev_id = strcmp(hid, "AMDI0007") ? 0 : 2;
> + static const struct acpi_device_id *dev_id;
> + const struct amd_lps0_hid_device_data *data;
> +
> + for (dev_id = &amd_hid_ids[0]; dev_id->id[0]; dev_id++)
> + if (acpi_dev_hid_uid_match(adev, dev_id->id, NULL))
> + break;
> + if (dev_id != NULL)
> + data = (const struct amd_lps0_hid_device_data *) dev_id->driver_data;
> + else
> + return 0;

The "!= NULL" seems unnecessary, I would change this to:

+ if (!dev_id)
+ return 0;
+ data = (const struct amd_lps0_hid_device_data *) dev_id->driver_data;

But either way,

Reviewed-by: Philipp Zabel <[email protected]>
Tested-by: Philipp Zabel <[email protected]> # GA402RJ

regards
Philipp

2022-09-13 17:59:53

by Philipp Zabel

[permalink] [raw]
Subject: Re: [PATCH v2 2/6] acpi/x86: s2idle: If a new AMD _HID is missing assume Rembrandt

Am Mon, Sep 12, 2022 at 12:23:56PM -0500 schrieb Mario Limonciello:
> A mistake was made that only AMDI0007 was set to rev of "2", but
> it should have been also set for AMDI008. If an ID is missing from
> the _HID table, then assume it matches Rembrandt behavior.
>
> This implicitly means that if any other behavior changes happen
> in the future missing IDs must be added to that table.
>
> Tested-by: [email protected]
> Signed-off-by: Mario Limonciello <[email protected]>
> ---
> drivers/acpi/x86/s2idle.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
> index a7757551f750..a8256e5a0e8a 100644
> --- a/drivers/acpi/x86/s2idle.c
> +++ b/drivers/acpi/x86/s2idle.c
> @@ -412,7 +412,7 @@ static int lps0_device_attach(struct acpi_device *adev,
> if (dev_id != NULL)
> data = (const struct amd_lps0_hid_device_data *) dev_id->driver_data;
> else
> - return 0;
> + data = &amd_rembrandt;

Ah, please disregard my suggestion in the previous patch. I'd still use:

if (dev_id)

Reviewed-by: Philipp Zabel <[email protected]>
Tested-by: Philipp Zabel <[email protected]> # GA402RJ

regards
Philipp

2022-09-13 17:59:53

by Philipp Zabel

[permalink] [raw]
Subject: Re: [PATCH v2 3/6] acpi/x86: s2idle: Add module parameter to prefer Microsoft GUID

Am Mon, Sep 12, 2022 at 12:23:57PM -0500 schrieb Mario Limonciello:
> OEMs have made some mistakes in the past for the AMD GUID support
> and not populated the method properly. To add an escape hatch for
> this problem introduce a module parameter that can force using
> the Microsoft GUID.
>
> This is intentionally introduced to both Intel and AMD codepaths
> to allow using the parameter as a debugging tactic on either.
>
> Signed-off-by: Mario Limonciello <[email protected]>

Reviewed-by: Philipp Zabel <[email protected]>
Tested-by: Philipp Zabel <[email protected]> # GA402RJ

regards
Philipp

2022-09-13 18:08:51

by Philipp Zabel

[permalink] [raw]
Subject: Re: [PATCH v2 4/6] acpi/x86: s2idle: Add a quirk for ASUS TUF Gaming A17 FA707RE

Am Mon, Sep 12, 2022 at 12:23:58PM -0500 schrieb Mario Limonciello:
> ASUS TUF Gaming A17 FA707RE has problems with ACPI events after
> s2idle resume. It's from a missing call to an ASL method in AMD
> the s2idle calling path. Force the system to use the Microsoft
> Modern Standby calling path instead.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=216101
> Reported-and-tested-by: [email protected]
> Signed-off-by: Mario Limonciello <[email protected]>
> ---
> v1->v2:
> * Fixup for __init
> ---
> drivers/acpi/x86/s2idle.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
> index a9b0f2b54a1c..9ee734e0c3c5 100644
> --- a/drivers/acpi/x86/s2idle.c
> +++ b/drivers/acpi/x86/s2idle.c
> @@ -17,6 +17,7 @@
>
> #include <linux/acpi.h>
> #include <linux/device.h>
> +#include <linux/dmi.h>
> #include <linux/suspend.h>
>
> #include "../sleep.h"
> @@ -400,6 +401,28 @@ static const struct acpi_device_id amd_hid_ids[] = {
> {}
> };
>
> +static int lps0_prefer_microsoft(const struct dmi_system_id *id)
> +{
> + pr_debug("Preferring Microsoft GUID.\n");
> + prefer_microsoft_guid = true;
> + return 0;
> +}
> +
> +static const struct dmi_system_id s2idle_dmi_table[] __initconst = {
> + {
> + /*
> + * ASUS TUF Gaming A17 FA707RE
> + * https://bugzilla.kernel.org/show_bug.cgi?id=216101
> + */
> + .callback = lps0_prefer_microsoft,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "ASUS TUF Gaming A17"),
> + },
> + },
> + {}
> +};
> +
> static int lps0_device_attach(struct acpi_device *adev,
> const struct acpi_device_id *not_used)
> {
> @@ -566,8 +589,9 @@ static const struct platform_s2idle_ops acpi_s2idle_ops_lps0 = {
> .end = acpi_s2idle_end,
> };
>
> -void acpi_s2idle_setup(void)
> +void __init acpi_s2idle_setup(void)

Reviewed-by: Philipp Zabel <[email protected]>
Tested-by: Philipp Zabel <[email protected]> # GA402RJ

regards
Philipp

2022-09-13 18:29:18

by Philipp Zabel

[permalink] [raw]
Subject: Re: [PATCH v2 5/6] acpi/x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14

Am Mon, Sep 12, 2022 at 12:23:59PM -0500 schrieb Mario Limonciello:
> ASUS ROG Zephyrus G14 is affected by the same BIOS bug as ASUS TUF
> Gaming A17 where important ASL is not called in the AMD code path.
> Use the Microsoft codepath instead.
>
> Reported-and-suggested-by: Philipp Zabel <[email protected]>
> Signed-off-by: Mario Limonciello <[email protected]>
> ---
> v1->v2:
> * New patch
> ---
> drivers/acpi/x86/s2idle.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
> index 9ee734e0c3c5..4bdc7133d2ea 100644
> --- a/drivers/acpi/x86/s2idle.c
> +++ b/drivers/acpi/x86/s2idle.c
> @@ -420,6 +420,14 @@ static const struct dmi_system_id s2idle_dmi_table[] __initconst = {
> DMI_MATCH(DMI_PRODUCT_NAME, "ASUS TUF Gaming A17"),
> },
> },
> + {
> + /* ASUS ROG Zephyrus G14 (2022) */
> + .callback = lps0_prefer_microsoft,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "ROG Zephyrus G14 GA402"),
> + },
> + },

Tested-by: Philipp Zabel <[email protected]>

regards
Philipp

2022-09-15 03:34:51

by Matthew Anderson

[permalink] [raw]
Subject: Re: [PATCH v2 5/6] acpi/x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14

Tested and confirmed working on my Zephyus G14 laptop.

On 9/13/22 11:50 AM, Philipp Zabel wrote:
> Am Mon, Sep 12, 2022 at 12:23:59PM -0500 schrieb Mario Limonciello:
>> ASUS ROG Zephyrus G14 is affected by the same BIOS bug as ASUS TUF
>> Gaming A17 where important ASL is not called in the AMD code path.
>> Use the Microsoft codepath instead.
>>
>> Reported-and-suggested-by: Philipp Zabel <[email protected]>
>> Signed-off-by: Mario Limonciello <[email protected]>
>> ---
>> v1->v2:
>> * New patch
>> ---
>> drivers/acpi/x86/s2idle.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
>> index 9ee734e0c3c5..4bdc7133d2ea 100644
>> --- a/drivers/acpi/x86/s2idle.c
>> +++ b/drivers/acpi/x86/s2idle.c
>> @@ -420,6 +420,14 @@ static const struct dmi_system_id s2idle_dmi_table[] __initconst = {
>> DMI_MATCH(DMI_PRODUCT_NAME, "ASUS TUF Gaming A17"),
>> },
>> },
>> + {
>> + /* ASUS ROG Zephyrus G14 (2022) */
>> + .callback = lps0_prefer_microsoft,
>> + .matches = {
>> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "ROG Zephyrus G14 GA402"),
>> + },
>> + },
> Tested-by: Philipp Zabel <[email protected]>
>
> regards
> Philipp
>
>

2022-09-15 04:04:40

by Matthew Anderson

[permalink] [raw]
Subject: Re: [PATCH v2 5/6] acpi/x86: s2idle: Add a quirk for ASUS ROG Zephyrus G14


On 9/12/22 12:23 PM, Mario Limonciello wrote:
> ASUS ROG Zephyrus G14 is affected by the same BIOS bug as ASUS TUF
> Gaming A17 where important ASL is not called in the AMD code path.
> Use the Microsoft codepath instead.
>
> Reported-and-suggested-by: Philipp Zabel <[email protected]>
> Signed-off-by: Mario Limonciello <[email protected]>
> ---
> v1->v2:
> * New patch
> ---
> drivers/acpi/x86/s2idle.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/acpi/x86/s2idle.c b/drivers/acpi/x86/s2idle.c
> index 9ee734e0c3c5..4bdc7133d2ea 100644
> --- a/drivers/acpi/x86/s2idle.c
> +++ b/drivers/acpi/x86/s2idle.c
> @@ -420,6 +420,14 @@ static const struct dmi_system_id s2idle_dmi_table[] __initconst = {
> DMI_MATCH(DMI_PRODUCT_NAME, "ASUS TUF Gaming A17"),
> },
> },
> + {
> + /* ASUS ROG Zephyrus G14 (2022) */
> + .callback = lps0_prefer_microsoft,
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "ROG Zephyrus G14 GA402"),
> + },
> + },
> {}
> };
>

Tested-by: Matthew Anderson <[email protected]>

Apologies for my troubles, I'm new to submitting to public emails.