platform_profile: power-saver lost on Panther Lake when SoC Power Slider and dell-pc are both bound (low-power vs quiet)

platform_profile: power-saver lost on Panther Lake when SoC Power Slider and dell-pc are both bound (low-power vs quiet)

[verazimmerman1987]

Hi,

On a Dell XPS 14 (2026, Panther Lake, Core Ultra X7 358H) two platform
profile handlers are registered, and their choices have no common
low-power option, so the legacy /sys/firmware/acpi/platform_profile
interface exposes only "balanced performance". As a result
power-profiles-daemon cannot select a low-power firmware mode in
power-saver.

Handlers:

  platform-profile-0  name: SoC Power Slider
                      choices: low-power balanced performance
  platform-profile-1  name: dell-pc
                      choices: cool quiet balanced performance

  /sys/firmware/acpi/platform_profile_choices: balanced performance

Effect: power-saver in power-profiles-daemon leaves both handlers at
"balanced". The Dell firmware stays in its "optimized" mode, so
thermald --adaptive keeps applying the optimized DTT table (PL1
19-25 W) instead of the quiet/cool tables (PL1 15-19 W, lower skin
temperature targets). Setting the handlers individually
(dell-pc=quiet, SoC slider=low-power) works and thermald picks the
"quiet" target, but the legacy file then reports "custom" and
power-profiles-daemon falls back to "balanced", so there is no
consistent way to use it.

This looks like the same class of problem as amd-pmf + asus-wmi,
which was solved by adding "quiet" as a hidden choice in amd-pmf
(commit 44e94fece517, "platform/x86/amd: pmf: Add 'quiet' to hidden
choices"). Would a similar hidden "quiet" (and perhaps "cool") choice
for the Intel SoC Power Slider, mapped to its low-power setting, be
acceptable? I'm happy to test patches.

System:
  Kernel: 7.2.9-arch1-1
  DMI: Dell Inc. XPS 14 DA14260, BIOS 1.11.0
  power-profiles-daemon: 0.30-1
  thermald: 2:2.5.13-1

Thanks,
Vera

Re: platform_profile: power-saver lost on Panther Lake when SoC Power Slider and dell-pc are both bound (low-power vs quiet)

[Lyndon Sanche]

Hello, thank you for reporting this.

To me there are a number of ways we could handle this.

On Fri Oct 16, 2026 at 1:10 PM EDT, verazimmerman1987 wrote:
> This looks like the same class of problem as amd-pmf + asus-wmi,
> which was solved by adding "quiet" as a hidden choice in amd-pmf
> (commit 44e94fece517, "platform/x86/amd: pmf: Add 'quiet' to hidden
> choices"). Would a similar hidden "quiet" (and perhaps "cool") choice
> for the Intel SoC Power Slider, mapped to its low-power setting, be
> acceptable? I'm happy to test patches.

This certainly would fix the immediate issue: platform_profile providing
consistent choices across handlers to allow selecting a range of
profiles exposed by the system. I feel like there is a better way to
handle this besides adding hidden profiles.

What if platform_profile itself was changed to separate the user/system
choice: the "desired" profile, from the "actual" profile(s)? In this
scenario, different drivers expose different possible profiles, the
system tries to apply the closest possible profile per-driver to the
user's choice. The possible profiles would have an index to indicate
where on a linear scale it lays. If I request quiet (2), but the Intel
SoC slider only implements power-saver (3), the system chooses 3 for
that driver.

I am only thinking out loud and would find comments on this to be
useful. I realize the behaviour of some profiles do not exactly fall on
a linear scale so this would need consideration as well.

Thanks,

Lyndon

Re: platform_profile: power-saver lost on Panther Lake when SoC Power Slider and dell-pc are both bound (low-power vs quiet)

[verazimmerman1987]

Hi Lyndon,

Thanks for looking at this.

> What if platform_profile itself was changed to separate the user/system
> choice: the "desired" profile, from the "actual" profile(s)?

From the user side this sounds right, and it matches what I would
expect as a user: I pick one profile, each driver does the closest
thing it can. A few observations from testing on this machine:

1. The legacy /sys/firmware/acpi/platform_profile is where it actually
   breaks today. When I set dell-pc=quiet and the SoC slider=low-power
   by hand, the legacy file reports "custom", and power-profiles-daemon
   treats that as an external change and falls back to "balanced". If
   the legacy file reported the desired profile instead of "custom",
   the main userspace consumer would keep working.

2. On the ordering: low-power / quiet / balanced / performance fit a
   linear scale well. "cool" is less clear. On this Dell its DTT table
   has the same PL1 range as quiet (15-19 W) but a lower skin
   temperature target (40 vs 42 C), so it is more of a thermal
   preference than a power level. Placing it next to quiet, or letting
   drivers declare it as an alias of the nearest level, would probably
   be good enough.

3. Ties and gaps: when a driver has no exact match, rounding towards
   the lower-power side seems the safer default (e.g. desired quiet ->
   low-power on the SoC slider rather than balanced).

As an interim step, the hidden-choice approach would fix power-saver
on current Panther Lake Dell systems with a small, backportable
change. Another user on the same model (XPS 14 DA14260) hit the same
power-saver -> balanced fallback independently:
https://github.com/omacom/omarchy/issues/14174

I'm happy to test either approach on this hardware.

Thanks,
Vera

-------- Original Message --------
On Monday, 10/19/26 at 15:21 Lyndon Sanche <lsanche@lyndeno.ca> wrote:
Hello, thank you for reporting this.

To me there are a number of ways we could handle this.

On Fri Oct 16, 2026 at 1:10 PM EDT, verazimmerman1987 wrote:
> This looks like the same class of problem as amd-pmf + asus-wmi,
> which was solved by adding "quiet" as a hidden choice in amd-pmf
> (commit 44e94fece517, "platform/x86/amd: pmf: Add 'quiet' to hidden
> choices"). Would a similar hidden "quiet" (and perhaps "cool") choice
> for the Intel SoC Power Slider, mapped to its low-power setting, be
> acceptable? I'm happy to test patches.

This certainly would fix the immediate issue: platform_profile providing
consistent choices across handlers to allow selecting a range of
profiles exposed by the system. I feel like there is a better way to
handle this besides adding hidden profiles.

What if platform_profile itself was changed to separate the user/system
choice: the "desired" profile, from the "actual" profile(s)? In this
scenario, different drivers expose different possible profiles, the
system tries to apply the closest possible profile per-driver to the
user's choice. The possible profiles would have an index to indicate
where on a linear scale it lays. If I request quiet (2), but the Intel
SoC slider only implements power-saver (3), the system chooses 3 for
that driver.

I am only thinking out loud and would find comments on this to be
useful. I realize the behaviour of some profiles do not exactly fall on
a linear scale so this would need consideration as well.

Thanks,

Lyndon

Re: platform_profile: power-saver lost on Panther Lake when SoC Power Slider and dell-pc are both bound (low-power vs quiet)

[srinivas pandruvada]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

Hi Vera,

Please test the attached patch.

I need with first and last name with email address to add Reported-by
and Tested-by.

Thanks,
Srinivas

On Fri, 2026-10-16 at 17:10 +0000, verazimmerman1987 wrote:
> Hi,
> 
> On a Dell XPS 14 (2026, Panther Lake, Core Ultra X7 358H) two
> platform
> profile handlers are registered, and their choices have no common
> low-power option, so the legacy /sys/firmware/acpi/platform_profile
> interface exposes only "balanced performance". As a result
> power-profiles-daemon cannot select a low-power firmware mode in
> power-saver.
> 
> Handlers:
> 
>   platform-profile-0  name: SoC Power Slider
>                       choices: low-power balanced performance
>   platform-profile-1  name: dell-pc
>                       choices: cool quiet balanced performance
> 
>   /sys/firmware/acpi/platform_profile_choices: balanced performance
> 
> Effect: power-saver in power-profiles-daemon leaves both handlers at
> "balanced". The Dell firmware stays in its "optimized" mode, so
> thermald --adaptive keeps applying the optimized DTT table (PL1
> 19-25 W) instead of the quiet/cool tables (PL1 15-19 W, lower skin
> temperature targets). Setting the handlers individually
> (dell-pc=quiet, SoC slider=low-power) works and thermald picks the
> "quiet" target, but the legacy file then reports "custom" and
> power-profiles-daemon falls back to "balanced", so there is no
> consistent way to use it.
> 
> This looks like the same class of problem as amd-pmf + asus-wmi,
> which was solved by adding "quiet" as a hidden choice in amd-pmf
> (commit 44e94fece517, "platform/x86/amd: pmf: Add 'quiet' to hidden
> choices"). Would a similar hidden "quiet" (and perhaps "cool") choice
> for the Intel SoC Power Slider, mapped to its low-power setting, be
> acceptable? I'm happy to test patches.
> 
> System:
>   Kernel: 7.2.9-arch1-1
>   DMI: Dell Inc. XPS 14 DA14260, BIOS 1.11.0
>   power-profiles-daemon: 0.30-1
>   thermald: 2:2.5.13-1
> 
> Thanks,
> Vera

[-- Attachment #2: 0001-thermal-intel-int340x-Add-quiet-to-hidden-choices-of.patch --]
[-- Type: text/x-patch, Size: 4142 bytes --]

From 4c8bf94d4fa7d808ee9ebd45d5388a12b8cbe577 Mon Sep 17 00:00:00 2001
From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Date: Fri, 30 Oct 2026 09:48:37 -0700
Subject: [PATCH] thermal: intel: int340x: Add 'quiet' to hidden choices of SoC
 power slider

On Panther Lake systems, the SoC Power Slider registers a platform
profile handler alongside the vendor platform profile driver. The two
handlers share no low-power choice, so the legacy
/sys/firmware/acpi/platform_profile interface, which only exposes the
intersection of all handlers' choices, offers only "balanced
performance".

For example, on ASUS GU606AW (also reported on GU606AX):

  SoC Power Slider: low-power balanced performance
  asus-wmi:         quiet balanced performance

and on Dell XPS 14 (2026, Core Ultra X7 358H):

  SoC Power Slider: low-power balanced performance
  dell-pc:          cool quiet balanced performance

As a result, the Quiet mode can't be selected through asusctl or the Fn
key on ASUS systems. power-profiles-daemon can't select a low-power
firmware mode in power-saver either.

Follow the same approach as commit 44e94fece517 ("platform/x86/amd: pmf:
Add 'quiet' to hidden choices") and add 'quiet' as a hidden choice that
maps to the same slider value as 'low-power'. With this, the legacy
choices become "quiet balanced performance" on both systems.

Unlike amd-pmf, this driver derives the current profile from the
hardware slider value. So remember the last requested profile, so that
'quiet' is reported back. Otherwise the legacy interface would show
"custom".

Fixes: 0d50f4d6ec5a ("thermal: intel: int340x: Add support for power slider")
Closes: https://github.com/OpenGamingCollective/asusctl/issues/387
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
---
 .../processor_thermal_soc_slider.c            | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c b/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c
index 91f291627132..daa26ff4723c 100644
--- a/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c
+++ b/drivers/thermal/intel/int340x_thermal/processor_thermal_soc_slider.c
@@ -132,11 +132,18 @@ static const struct kernel_param_ops slider_offset_ops = {
 module_param_cb(slider_offset, &slider_offset_ops, NULL, 0644);
 MODULE_PARM_DESC(slider_offset, "Set slider offset");
 
+/*
+ * Last profile requested via platform profile. Used to report back "quiet"
+ * hidden choice, which maps to the same slider value as "low-power".
+ */
+static enum platform_profile_option slider_cur_profile = PLATFORM_PROFILE_BALANCED;
+
 /* Convert from platform power profile option to SoC slider value */
 static int convert_profile_to_power_slider(enum platform_profile_option profile)
 {
 	switch (profile) {
 	case PLATFORM_PROFILE_LOW_POWER:
+	case PLATFORM_PROFILE_QUIET:
 		return slider_values[SOC_POWER_SLIDER_POWERSAVE];
 	case PLATFORM_PROFILE_BALANCED:
 		return slider_values[SOC_POWER_SLIDER_BALANCE];
@@ -216,6 +223,7 @@ static int power_slider_platform_profile_set(struct device *dev,
 		return slider;
 
 	set_soc_power_profile(proc_priv, slider);
+	slider_cur_profile = profile;
 
 	return 0;
 }
@@ -238,6 +246,9 @@ static int power_slider_platform_profile_get(struct device *dev,
 	if (ret < 0)
 		return ret;
 
+	if (ret == PLATFORM_PROFILE_LOW_POWER && slider_cur_profile == PLATFORM_PROFILE_QUIET)
+		ret = PLATFORM_PROFILE_QUIET;
+
 	*profile = ret;
 
 	return 0;
@@ -252,8 +263,16 @@ static int power_slider_platform_profile_probe(void *drvdata, unsigned long *cho
 	return 0;
 }
 
+static int power_slider_platform_profile_hidden_choices(void *drvdata, unsigned long *choices)
+{
+	set_bit(PLATFORM_PROFILE_QUIET, choices);
+
+	return 0;
+}
+
 static const struct platform_profile_ops power_slider_platform_profile_ops = {
 	.probe = power_slider_platform_profile_probe,
+	.hidden_choices = power_slider_platform_profile_hidden_choices,
 	.profile_get = power_slider_platform_profile_get,
 	.profile_set = power_slider_platform_profile_set,
 };
-- 
2.56.0