The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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 */
> 
> 
> 


  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