From: Mario Limonciello <mario.limonciello@amd.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
Linux ACPI <linux-acpi@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Subject: Re: [PATCH v1] ACPI: PM: s2idle: Add module parameter for LPS0 constraints checking
Date: Tue, 13 Jan 2026 15:48:37 -0600 [thread overview]
Message-ID: <757e7800-c45f-4d65-a7f5-9b158660277a@amd.com> (raw)
In-Reply-To: <2827214.mvXUDI8C0e@rafael.j.wysocki>
On 1/13/2026 7:36 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Commit 32ece31db4df ("ACPI: PM: s2idle: Only retrieve constraints when
> needed") attempted to avoid useless evaluation of LPS0 _DSM Function 1
> in lps0_device_attach() because pm_debug_messages_on might never be set
> (and that is the case on production systems most of the time), but it
> turns out that LPS0 _DSM Function 1 is generally problematic on some
> platforms and causes suspend issues to occur when pm_debug_messages_on
> is set now.
Any ideas why it's causing problems? AML doing something it shouldn't?
>
> In Linux, LPS0 _DSM Function 1 is only useful for diagnostics and only
> in the cases when the system does not reach the deepest platform idle
> state during suspend-to-idle for some reason. If such diagnostics is
> not necessary, evaluating it is a loss of time, so using it along with
> the other pm_debug_messages_on diagnostics is questionable because the
> latter is expected to be suitable for collecting debug information even
> during production use of system suspend.
>
> For this reason, add a module parameter called check_lps0_constraints
> to control whether or not the list of LPS0 constraints will be checked
> in acpi_s2idle_prepare_late_lps0() and so whether or not to evaluate
> LPS0 _DSM Function 1 (once) in acpi_s2idle_begin_lps0().
>
> Fixes: 32ece31db4df ("ACPI: PM: s2idle: Only retrieve constraints when needed")
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/x86/s2idle.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> --- a/drivers/acpi/x86/s2idle.c
> +++ b/drivers/acpi/x86/s2idle.c
> @@ -28,6 +28,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 check_lps0_constraints __read_mostly;
> +module_param(check_lps0_constraints, bool, 0644);
> +MODULE_PARM_DESC(check_lps0_constraints, "Check LPS0 device constraints");
I'm personally not really a fan of another module parameter for
debugging. I know some other subsystem maintainers are very anti-module
parameters too.
I did like having /sys/power/pm_debug_messages able to be a one stop
shop for debugging messages at runtime.
So I had another idea I wanted to throw around. What if instead we had
a file /sys/kernel/debug/x86/lps0_constraints?
If the file is never accessed never evaluate constraints. If you read
it once then you can get a dump of all the current constraints and any
future suspends during that boot will also include constraints in the
logs (IE call lpi_check_constraints()).
> +
> static const struct acpi_device_id lps0_device_ids[] = {
> {"PNP0D80", },
> {"", },
> @@ -515,7 +519,7 @@ static struct acpi_scan_handler lps0_han
>
> static int acpi_s2idle_begin_lps0(void)
> {
> - if (lps0_device_handle && !sleep_no_lps0 && pm_debug_messages_on &&
> + if (lps0_device_handle && !sleep_no_lps0 && check_lps0_constraints &&
> !lpi_constraints_table) {
> if (acpi_s2idle_vendor_amd())
> lpi_device_get_constraints_amd();
> @@ -540,7 +544,7 @@ static int acpi_s2idle_prepare_late_lps0
> if (!lps0_device_handle || sleep_no_lps0)
> return 0;
>
> - if (pm_debug_messages_on)
> + if (check_lps0_constraints)
> lpi_check_constraints();
>
> /* Screen off */
>
>
>
next prev parent reply other threads:[~2026-01-13 21:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-13 13:36 [PATCH v1] ACPI: PM: s2idle: Add module parameter for LPS0 constraints checking Rafael J. Wysocki
2026-01-13 21:48 ` Mario Limonciello [this message]
2026-01-13 21:57 ` Rafael J. Wysocki
2026-01-13 22:00 ` Mario Limonciello
2026-01-13 22:05 ` Rafael J. Wysocki
2026-01-13 22:06 ` Mario Limonciello (AMD) (kernel.org)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=757e7800-c45f-4d65-a7f5-9b158660277a@amd.com \
--to=mario.limonciello@amd.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox