The current implementation for Victus S thermal profiles only supports
setting the profile. The driver was missing the logic to read the
hardware state, meaning it would default to "Balanced" on driver load,
overriding the currently active profile. Furthermore, the driver could
not detect if the firmware reset the profile on a power source change.

Add platform_profile_victus_s_get_ec() to read the current thermal
profile state directly from EC offset 0x59. Since both Balanced and
Low-Power profiles share the same thermal profile value, differentiate
them by querying the GPU CTGP and PPAB states via existing functions.
Additionally, update the power source event notifier to use the actual
hardware state when re-trigger CPU power limits actualization.

Testing on HP Omen 16-wf1xxx (board ID 8C78) confirmed that the thermal
profile is now persistent across driver loads and power source change
events.

Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com>
---
Changes in v5:
- Improved platform_profile_victus_s_get_ec() to support multiple EC
  layouts by iteratively probing offsets.
Changes in v4:
- Fixed platform_profile_victus_s_get_ec() to use both
  victus_s_thermal_params and omen_v1_thermal_params instead of
  active_thermal_params to fix regression caused in v3.
- Handle err after calling victus_s_gpu_thermal_profile_get().
- Fixed a wrong function call in victus_s_powersource_event().
Changes in v3:
- New patch in this series
---
 drivers/platform/x86/hp/hp-wmi.c | 100 +++++++++++++++++++++++++++----
 1 file changed, 89 insertions(+), 11 deletions(-)

diff --git a/drivers/platform/x86/hp/hp-wmi.c b/drivers/platform/x86/hp/hp-wmi.c
index 24d065ddfc6a..ed52c697d2ea 100644
--- a/drivers/platform/x86/hp/hp-wmi.c
+++ b/drivers/platform/x86/hp/hp-wmi.c
@@ -13,6 +13,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include <linux/array_size.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/init.h>
@@ -44,6 +45,7 @@ MODULE_ALIAS("wmi:5FB7F034-2C63-45E9-BE91-3D44E2C707E4");
 #define HP_OMEN_EC_THERMAL_PROFILE_FLAGS_OFFSET 0x62
 #define HP_OMEN_EC_THERMAL_PROFILE_TIMER_OFFSET 0x63
 #define HP_OMEN_EC_THERMAL_PROFILE_OFFSET 0x95
+#define HP_VICTUS_S_EC_THERMAL_PROFILE_OFFSET 0x59
 
 #define HP_FAN_SPEED_AUTOMATIC	 0x00
 #define HP_POWER_LIMIT_DEFAULT	 0x00
@@ -640,6 +642,12 @@ static bool is_omen_thermal_profile(void)
 			    board_name) >= 0;
 }
 
+static bool is_victus_s_thermal_profile(void)
+{
+	/* Initialised in driver init, hence safe to use here */
+	return is_victus_s_board;
+}
+
 static int omen_get_thermal_policy_version(void)
 {
 	unsigned char buffer[8] = { 0 };
@@ -1631,12 +1639,6 @@ static int platform_profile_victus_set_ec(enum platform_profile_option profile)
 	return 0;
 }
 
-static bool is_victus_s_thermal_profile(void)
-{
-	/* Initialised in driver init, hence safe to use here */
-	return is_victus_s_board;
-}
-
 static int victus_s_gpu_thermal_profile_get(bool *ctgp_enable,
 					    bool *ppab_enable,
 					    u8 *dstate,
@@ -1715,6 +1717,68 @@ static int victus_s_set_cpu_pl1_pl2(u8 pl1, u8 pl2)
 	return ret;
 }
 
+static int platform_profile_victus_s_get_ec(enum platform_profile_option *profile)
+{
+	int ret, i;
+	bool current_ctgp_state, current_ppab_state;
+	u8 current_dstate, current_gpu_slowdown_temp, tp;
+	static const u8 tp_ec_offsets[2] = { HP_OMEN_EC_THERMAL_PROFILE_OFFSET,
+					     HP_VICTUS_S_EC_THERMAL_PROFILE_OFFSET };
+
+	/*
+	 * Victus S devices have more than 1 EC layouts, hence we cannot directly
+	 * call omen_thermal_profile_get() like other platform_profile_*_get_ec()
+	 * variants, since it would only resolve to that 1 type of board. Hence
+	 * we iteratively query a set of candidates: tp_ec_offsets[] until we
+	 * find a valid thermal profile.
+	 */
+	for (i = 0 ; i < ARRAY_SIZE(tp_ec_offsets) ; i++) {
+		ret = ec_read(tp_ec_offsets[i], &tp);
+		if (ret)
+			return ret;
+
+		/*
+		 * We cannot use active_thermal_profile_params here, because boards
+		 * like 8C78 have tp == 0x0 || tp == 0x1 after cold boot, but logically
+		 * it should have tp == 0x30 || tp == 0x31, as corrected by the Omen
+		 * Gaming Hub on windows. Hence accept both of these values.
+		 */
+		if (tp == victus_s_thermal_params.performance ||
+		    tp == omen_v1_thermal_params.performance) {
+			*profile = PLATFORM_PROFILE_PERFORMANCE;
+			return 0;
+		} else if (tp == victus_s_thermal_params.balanced ||
+			   tp == omen_v1_thermal_params.balanced) {
+			/*
+			 * Since both PLATFORM_PROFILE_LOW_POWER and
+			 * PLATFORM_PROFILE_BALANCED share the same thermal
+			 * profile parameter value, hence to differentiate
+			 * between them, we query the GPU CTGP and PPAB states
+			 * and compare based off of that.
+			 */
+			ret = victus_s_gpu_thermal_profile_get(&current_ctgp_state,
+							       &current_ppab_state,
+							       &current_dstate,
+							       &current_gpu_slowdown_temp);
+			if (ret < 0)
+				return ret;
+
+			if (current_ctgp_state == 0 && current_ppab_state == 0) {
+				*profile = PLATFORM_PROFILE_LOW_POWER;
+				return 0;
+			} else if (current_ctgp_state == 0 && current_ppab_state == 1) {
+				*profile = PLATFORM_PROFILE_BALANCED;
+				return 0;
+			} else {
+				return -EINVAL;
+			}
+		}
+	}
+
+	/* Failed to get thermal profile from all EC offsets */
+	return -EINVAL;
+}
+
 static int platform_profile_victus_s_set_ec(enum platform_profile_option profile)
 {
 	struct thermal_profile_params *params;
@@ -1882,6 +1946,7 @@ static int victus_s_powersource_event(struct notifier_block *nb,
 				      void *data)
 {
 	struct acpi_bus_event *event_entry = data;
+	enum platform_profile_option actual_profile;
 	int err;
 
 	if (strcmp(event_entry->device_class, ACPI_AC_CLASS) != 0)
@@ -1889,6 +1954,17 @@ static int victus_s_powersource_event(struct notifier_block *nb,
 
 	pr_debug("Received power source device event\n");
 
+	guard(mutex)(&active_platform_profile_lock);
+	err = platform_profile_victus_s_get_ec(&actual_profile);
+	if (err < 0) {
+		/*
+		 * Although we failed to get the current platform profile, we
+		 * still want the other event consumers to process it.
+		 */
+		pr_warn("Failed to read current platform profile (%d)\n", err);
+		return NOTIFY_DONE;
+	}
+
 	/*
 	 * Switching to battery power source while Performance mode is active
 	 * needs manual triggering of CPU power limits. Same goes when switching
@@ -1897,7 +1973,7 @@ static int victus_s_powersource_event(struct notifier_block *nb,
 	 * Seen on HP 16-s1034nf (board 8C9C) with F.11 and F.13 BIOS versions.
 	 */
 
-	if (active_platform_profile == PLATFORM_PROFILE_PERFORMANCE) {
+	if (actual_profile == PLATFORM_PROFILE_PERFORMANCE) {
 		pr_debug("Triggering CPU PL1/PL2 actualization\n");
 		err = victus_s_set_cpu_pl1_pl2(HP_POWER_LIMIT_DEFAULT,
 					       HP_POWER_LIMIT_DEFAULT);
@@ -2007,12 +2083,14 @@ static int thermal_profile_setup(struct platform_device *device)
 
 		ops = &platform_profile_victus_ops;
 	} else if (is_victus_s_thermal_profile()) {
+		err = platform_profile_victus_s_get_ec(&active_platform_profile);
+		if (err < 0)
+			return err;
+
 		/*
-		 * Being unable to retrieve laptop's current thermal profile,
-		 * during this setup, we set it to Balanced by default.
+		 * call thermal profile write command to ensure that the
+		 * firmware correctly sets the OEM variables
 		 */
-		active_platform_profile = PLATFORM_PROFILE_BALANCED;
-
 		err = platform_profile_victus_s_set_ec(active_platform_profile);
 		if (err < 0)
 			return err;
-- 
2.52.0

On Tue, 13 Jan 2026, Krishna Chomal wrote:

> The current implementation for Victus S thermal profiles only supports
> setting the profile. The driver was missing the logic to read the
> hardware state, meaning it would default to "Balanced" on driver load,
> overriding the currently active profile. Furthermore, the driver could
> not detect if the firmware reset the profile on a power source change.
> 
> Add platform_profile_victus_s_get_ec() to read the current thermal
> profile state directly from EC offset 0x59. Since both Balanced and
> Low-Power profiles share the same thermal profile value, differentiate
> them by querying the GPU CTGP and PPAB states via existing functions.
> Additionally, update the power source event notifier to use the actual
> hardware state when re-trigger CPU power limits actualization.
> 
> Testing on HP Omen 16-wf1xxx (board ID 8C78) confirmed that the thermal
> profile is now persistent across driver loads and power source change
> events.
> 
> Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com>
> ---
> Changes in v5:
> - Improved platform_profile_victus_s_get_ec() to support multiple EC
>   layouts by iteratively probing offsets.
> Changes in v4:
> - Fixed platform_profile_victus_s_get_ec() to use both
>   victus_s_thermal_params and omen_v1_thermal_params instead of
>   active_thermal_params to fix regression caused in v3.
> - Handle err after calling victus_s_gpu_thermal_profile_get().
> - Fixed a wrong function call in victus_s_powersource_event().
> Changes in v3:
> - New patch in this series
> ---
>  drivers/platform/x86/hp/hp-wmi.c | 100 +++++++++++++++++++++++++++----
>  1 file changed, 89 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/platform/x86/hp/hp-wmi.c b/drivers/platform/x86/hp/hp-wmi.c
> index 24d065ddfc6a..ed52c697d2ea 100644
> --- a/drivers/platform/x86/hp/hp-wmi.c
> +++ b/drivers/platform/x86/hp/hp-wmi.c
> @@ -13,6 +13,7 @@
>  
>  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>  
> +#include <linux/array_size.h>
>  #include <linux/kernel.h>
>  #include <linux/module.h>
>  #include <linux/init.h>
> @@ -44,6 +45,7 @@ MODULE_ALIAS("wmi:5FB7F034-2C63-45E9-BE91-3D44E2C707E4");
>  #define HP_OMEN_EC_THERMAL_PROFILE_FLAGS_OFFSET 0x62
>  #define HP_OMEN_EC_THERMAL_PROFILE_TIMER_OFFSET 0x63
>  #define HP_OMEN_EC_THERMAL_PROFILE_OFFSET 0x95
> +#define HP_VICTUS_S_EC_THERMAL_PROFILE_OFFSET 0x59
>  
>  #define HP_FAN_SPEED_AUTOMATIC	 0x00
>  #define HP_POWER_LIMIT_DEFAULT	 0x00
> @@ -640,6 +642,12 @@ static bool is_omen_thermal_profile(void)
>  			    board_name) >= 0;
>  }
>  
> +static bool is_victus_s_thermal_profile(void)
> +{
> +	/* Initialised in driver init, hence safe to use here */
> +	return is_victus_s_board;
> +}
> +
>  static int omen_get_thermal_policy_version(void)
>  {
>  	unsigned char buffer[8] = { 0 };
> @@ -1631,12 +1639,6 @@ static int platform_profile_victus_set_ec(enum platform_profile_option profile)
>  	return 0;
>  }
>  
> -static bool is_victus_s_thermal_profile(void)
> -{
> -	/* Initialised in driver init, hence safe to use here */
> -	return is_victus_s_board;
> -}
> -
>  static int victus_s_gpu_thermal_profile_get(bool *ctgp_enable,
>  					    bool *ppab_enable,
>  					    u8 *dstate,
> @@ -1715,6 +1717,68 @@ static int victus_s_set_cpu_pl1_pl2(u8 pl1, u8 pl2)
>  	return ret;
>  }
>  
> +static int platform_profile_victus_s_get_ec(enum platform_profile_option *profile)
> +{
> +	int ret, i;
> +	bool current_ctgp_state, current_ppab_state;
> +	u8 current_dstate, current_gpu_slowdown_temp, tp;
> +	static const u8 tp_ec_offsets[2] = { HP_OMEN_EC_THERMAL_PROFILE_OFFSET,
> +					     HP_VICTUS_S_EC_THERMAL_PROFILE_OFFSET };
> +
> +	/*
> +	 * Victus S devices have more than 1 EC layouts, hence we cannot directly
> +	 * call omen_thermal_profile_get() like other platform_profile_*_get_ec()
> +	 * variants, since it would only resolve to that 1 type of board. Hence
> +	 * we iteratively query a set of candidates: tp_ec_offsets[] until we
> +	 * find a valid thermal profile.
> +	 */
> +	for (i = 0 ; i < ARRAY_SIZE(tp_ec_offsets) ; i++) {
> +		ret = ec_read(tp_ec_offsets[i], &tp);

I'm not so sure about this. Reading EC offsets and hoping we find the 
correct one doesn't sound the best idea. I'd prefer we store the 
information like we already do for thermal profiles. Unless there's some 
other way to detect which layout it is?

FYI, I took the first patch of this series again into the review-ilpo-next 
branch as it seems uncontested and fixes a problem in the existing code.

-- 
 i.


> +		if (ret)
> +			return ret;
> +
> +		/*
> +		 * We cannot use active_thermal_profile_params here, because boards
> +		 * like 8C78 have tp == 0x0 || tp == 0x1 after cold boot, but logically
> +		 * it should have tp == 0x30 || tp == 0x31, as corrected by the Omen
> +		 * Gaming Hub on windows. Hence accept both of these values.
> +		 */
> +		if (tp == victus_s_thermal_params.performance ||
> +		    tp == omen_v1_thermal_params.performance) {
> +			*profile = PLATFORM_PROFILE_PERFORMANCE;
> +			return 0;
> +		} else if (tp == victus_s_thermal_params.balanced ||
> +			   tp == omen_v1_thermal_params.balanced) {
> +			/*
> +			 * Since both PLATFORM_PROFILE_LOW_POWER and
> +			 * PLATFORM_PROFILE_BALANCED share the same thermal
> +			 * profile parameter value, hence to differentiate
> +			 * between them, we query the GPU CTGP and PPAB states
> +			 * and compare based off of that.
> +			 */
> +			ret = victus_s_gpu_thermal_profile_get(&current_ctgp_state,
> +							       &current_ppab_state,
> +							       &current_dstate,
> +							       &current_gpu_slowdown_temp);
> +			if (ret < 0)
> +				return ret;
> +
> +			if (current_ctgp_state == 0 && current_ppab_state == 0) {
> +				*profile = PLATFORM_PROFILE_LOW_POWER;
> +				return 0;
> +			} else if (current_ctgp_state == 0 && current_ppab_state == 1) {
> +				*profile = PLATFORM_PROFILE_BALANCED;
> +				return 0;
> +			} else {
> +				return -EINVAL;
> +			}
> +		}
> +	}
> +
> +	/* Failed to get thermal profile from all EC offsets */
> +	return -EINVAL;
> +}
> +
>  static int platform_profile_victus_s_set_ec(enum platform_profile_option profile)
>  {
>  	struct thermal_profile_params *params;
> @@ -1882,6 +1946,7 @@ static int victus_s_powersource_event(struct notifier_block *nb,
>  				      void *data)
>  {
>  	struct acpi_bus_event *event_entry = data;
> +	enum platform_profile_option actual_profile;
>  	int err;
>  
>  	if (strcmp(event_entry->device_class, ACPI_AC_CLASS) != 0)
> @@ -1889,6 +1954,17 @@ static int victus_s_powersource_event(struct notifier_block *nb,
>  
>  	pr_debug("Received power source device event\n");
>  
> +	guard(mutex)(&active_platform_profile_lock);
> +	err = platform_profile_victus_s_get_ec(&actual_profile);
> +	if (err < 0) {
> +		/*
> +		 * Although we failed to get the current platform profile, we
> +		 * still want the other event consumers to process it.
> +		 */
> +		pr_warn("Failed to read current platform profile (%d)\n", err);
> +		return NOTIFY_DONE;
> +	}
> +
>  	/*
>  	 * Switching to battery power source while Performance mode is active
>  	 * needs manual triggering of CPU power limits. Same goes when switching
> @@ -1897,7 +1973,7 @@ static int victus_s_powersource_event(struct notifier_block *nb,
>  	 * Seen on HP 16-s1034nf (board 8C9C) with F.11 and F.13 BIOS versions.
>  	 */
>  
> -	if (active_platform_profile == PLATFORM_PROFILE_PERFORMANCE) {
> +	if (actual_profile == PLATFORM_PROFILE_PERFORMANCE) {
>  		pr_debug("Triggering CPU PL1/PL2 actualization\n");
>  		err = victus_s_set_cpu_pl1_pl2(HP_POWER_LIMIT_DEFAULT,
>  					       HP_POWER_LIMIT_DEFAULT);
> @@ -2007,12 +2083,14 @@ static int thermal_profile_setup(struct platform_device *device)
>  
>  		ops = &platform_profile_victus_ops;
>  	} else if (is_victus_s_thermal_profile()) {
> +		err = platform_profile_victus_s_get_ec(&active_platform_profile);
> +		if (err < 0)
> +			return err;
> +
>  		/*
> -		 * Being unable to retrieve laptop's current thermal profile,
> -		 * during this setup, we set it to Balanced by default.
> +		 * call thermal profile write command to ensure that the
> +		 * firmware correctly sets the OEM variables
>  		 */
> -		active_platform_profile = PLATFORM_PROFILE_BALANCED;
> -
>  		err = platform_profile_victus_s_set_ec(active_platform_profile);
>  		if (err < 0)
>  			return err;
>

On Thu, Jan 15, 2026 at 03:26:45PM +0200, Ilpo Järvinen wrote:
[snip]
>> +static int platform_profile_victus_s_get_ec(enum platform_profile_option *profile)
>> +{
>> +	int ret, i;
>> +	bool current_ctgp_state, current_ppab_state;
>> +	u8 current_dstate, current_gpu_slowdown_temp, tp;
>> +	static const u8 tp_ec_offsets[2] = { HP_OMEN_EC_THERMAL_PROFILE_OFFSET,
>> +					     HP_VICTUS_S_EC_THERMAL_PROFILE_OFFSET };
>> +
>> +	/*
>> +	 * Victus S devices have more than 1 EC layouts, hence we cannot directly
>> +	 * call omen_thermal_profile_get() like other platform_profile_*_get_ec()
>> +	 * variants, since it would only resolve to that 1 type of board. Hence
>> +	 * we iteratively query a set of candidates: tp_ec_offsets[] until we
>> +	 * find a valid thermal profile.
>> +	 */
>> +	for (i = 0 ; i < ARRAY_SIZE(tp_ec_offsets) ; i++) {
>> +		ret = ec_read(tp_ec_offsets[i], &tp);
>
>I'm not so sure about this. Reading EC offsets and hoping we find the
>correct one doesn't sound the best idea. I'd prefer we store the
>information like we already do for thermal profiles. Unless there's some
>other way to detect which layout it is?

I explored the Omen Gaming Hub (OGH) behavior on Windows to see if a WMI
query exists for readback. OGH appears to default to "Balanced" on first
run and tracks state via a profile.json file on the disk. Deleting this
file causes the app to lose the current state, suggesting that there is no
official WMI readback query. By implementing EC reads, the driver can
actually remain more consistent with the real hardware state than the
offcial software.

I agree that iterative EC reads are not ideal. However, since these two
offsets (0x95 and 0x59) cover all (or almost all) known Victus/Omen layouts,
the risk of "hoping" is low.

Storing them at compile time in the victus_s array as a part of
.driver_data is indeed the best thing. But since we do not know what EC
layout is followed by the existing boards in the array, we can take a
hybrid approach here:
1. I (and subsequent additions) will store their EC offset in the
    .driver_data field struct.
2. For already existing boards we will perform this iterative probe once
    during init, and store it somewhere common.
3. Then platform_profile_victus_s_get_ec() can simply use this "definite"
    offset to perform the EC read.

>
>FYI, I took the first patch of this series again into the review-ilpo-next
>branch as it seems uncontested and fixes a problem in the existing code.
>
>-- 
> i.
>

Thank you :)

On Fri, 16 Jan 2026, Krishna Chomal wrote:

> On Thu, Jan 15, 2026 at 03:26:45PM +0200, Ilpo Järvinen wrote:
> [snip]
> > > +static int platform_profile_victus_s_get_ec(enum platform_profile_option
> > > *profile)
> > > +{
> > > +	int ret, i;
> > > +	bool current_ctgp_state, current_ppab_state;
> > > +	u8 current_dstate, current_gpu_slowdown_temp, tp;
> > > +	static const u8 tp_ec_offsets[2] = {
> > > HP_OMEN_EC_THERMAL_PROFILE_OFFSET,
> > > +
> > > HP_VICTUS_S_EC_THERMAL_PROFILE_OFFSET };
> > > +
> > > +	/*
> > > +	 * Victus S devices have more than 1 EC layouts, hence we cannot
> > > directly
> > > +	 * call omen_thermal_profile_get() like other
> > > platform_profile_*_get_ec()
> > > +	 * variants, since it would only resolve to that 1 type of board.
> > > Hence
> > > +	 * we iteratively query a set of candidates: tp_ec_offsets[] until we
> > > +	 * find a valid thermal profile.
> > > +	 */
> > > +	for (i = 0 ; i < ARRAY_SIZE(tp_ec_offsets) ; i++) {
> > > +		ret = ec_read(tp_ec_offsets[i], &tp);
> > 
> > I'm not so sure about this. Reading EC offsets and hoping we find the
> > correct one doesn't sound the best idea. I'd prefer we store the
> > information like we already do for thermal profiles. Unless there's some
> > other way to detect which layout it is?
> 
> I explored the Omen Gaming Hub (OGH) behavior on Windows to see if a WMI
> query exists for readback. OGH appears to default to "Balanced" on first
> run and tracks state via a profile.json file on the disk. Deleting this
> file causes the app to lose the current state, suggesting that there is no
> official WMI readback query. By implementing EC reads, the driver can
> actually remain more consistent with the real hardware state than the
> offcial software.
> 
> I agree that iterative EC reads are not ideal. However, since these two
> offsets (0x95 and 0x59) cover all (or almost all) known Victus/Omen layouts,
> the risk of "hoping" is low.
> 
> Storing them at compile time in the victus_s array as a part of
> .driver_data is indeed the best thing. But since we do not know what EC
> layout is followed by the existing boards in the array, we can take a
> hybrid approach here:
> 1. I (and subsequent additions) will store their EC offset in the
>    .driver_data field struct.
> 2. For already existing boards we will perform this iterative probe once
>    during init, and store it somewhere common.
> 3. Then platform_profile_victus_s_get_ec() can simply use this "definite"
>    offset to perform the EC read.

I guess we'll have to settle to that but it likely means we'll never be 
able to source those offsets because things appear "working" and therefore 
cannot get rid of the extra code necessary for the EC offset iteration.

Another alternative would be to add pr_warn() if we don't have the EC 
offset yet for a board and not read anything (and hope somebody who has 
one of those boards will come to us with the information or patch).

-- 
 i.

On Tue, Jan 20, 2026 at 05:10:00PM +0200, Ilpo Järvinen wrote:
[snip]
>> I agree that iterative EC reads are not ideal. However, since these two
>> offsets (0x95 and 0x59) cover all (or almost all) known Victus/Omen layouts,
>> the risk of "hoping" is low.
>>
>> Storing them at compile time in the victus_s array as a part of
>> .driver_data is indeed the best thing. But since we do not know what EC
>> layout is followed by the existing boards in the array, we can take a
>> hybrid approach here:
>> 1. I (and subsequent additions) will store their EC offset in the
>>    .driver_data field struct.
>> 2. For already existing boards we will perform this iterative probe once
>>    during init, and store it somewhere common.
>> 3. Then platform_profile_victus_s_get_ec() can simply use this "definite"
>>    offset to perform the EC read.
>
>I guess we'll have to settle to that but it likely means we'll never be
>able to source those offsets because things appear "working" and therefore
>cannot get rid of the extra code necessary for the EC offset iteration.
>
>Another alternative would be to add pr_warn() if we don't have the EC
>offset yet for a board and not read anything (and hope somebody who has
>one of those boards will come to us with the information or patch).
>
>-- 
> i.

Hi Ilpo,

That is a very fair point, if the driver just works, we would never get
the actual offsets. I have adopted a stricter version for v6:
1. I removed the iterative probing entirely.
2. Added a pr_warn() in setup_active_thermal_profile_params() for
    unknown boards.
3. Known boards (like 8C78) now have their offsets hardcoded in the DMI
    table.

This ensures that thermal profile readback is only enabled when we have
definite hardware data. I will send v6, based on the for-next branch,
shortly after thorough testing.

Thanks for the guidance!