hp_wmi: Unknown EC layout for board 8C9C

hp_wmi: Unknown EC layout for board 8C9C

[Julien ROBIN]

Hi there, I got the following message into my dmesg log:

hp_wmi: Unknown EC layout for board 8C9C. Thermal profile readback will be disabled. Please report this to platform-driver-x86@vger.kernel.org

I may help a little bit here, as two years ago I did the initial work to get fan speed reading and setting, and thermal profiles for the HP Victus 16s-1034nf (8C9C) which I'm still using. Nice to see new people added new things above this! I hope the "victus_s" naming scheme I introduced to differentiate from previous driver behavior when adding support to the Victus 16s-1034nf didn't turn to be inconsistent with added models names using the same behavior since then.

With nbfc-linux and ec_probe monitor command, I managed to check again EC offsets/registers meaning for this 8C9C laptop (currently running BIOS F.17 11/18/2025). 

0xAE offset is related to thermal profile, it shows 3 possible values:
 - 0x00 when in performance mode (while HP_VICTUS_S_THERMAL_PROFILE_PERFORMANCE = 0x01)
 - 0x01 when placed in balanced or low-power modes,
 - 0x02 when the laptop CPU power limits are back to default / fallback state: turns out this happens when an HPWMI_FAN_COUNT_GET_QUERY hasn't been played during the last 120 seconds. See hp_wmi_get_fan_count_userdefine_trigger() function.

However when the 0xAE register value is at 0x02, playing an HPWMI_FAN_COUNT_GET_QUERY makes the 0xAE register back to its previous mode (and CPU power limits are set accordingly). So when value is 0x02, the previous value is kept (and may be restored from) somewhere else, but it doesn't seem to be from any other EC register. Even worse, when going to performance mode, HPWMI_SET_PERFORMANCE_MODE command is applying HP_VICTUS_S_THERMAL_PROFILE_PERFORMANCE = 0x01 which cause the 0xAE register to go to 0x00, so the logic of this EC register is different from what existed for others models (where the EC register value was the same as the one provided by the HPWMI_SET_PERFORMANCE_MODE query).

Because of these sudden changes about EC registers behavior, I wasn't sure insisting on direct reading into EC registers was still going to be a sustainable approach for reading back thermal profile on this new kind of laptop. Facing BIOS updates, or tiny changes between similar models, may even cause such approach to break without warnings. It would also need people adding similar laptops to ensure 0xAE is still the right EC register to read, and double check the values are behaving the same. Which is why at startup, I preferred the mode to be initially set to balanced: to both cleanly ensure and say back which mode is enabled, without relying on risky tricks.

But despite this personal opinion, for the 8C9C, playing an HPWMI_FAN_COUNT_GET_QUERY, and guessing the current mode is performance mode (0x01) when 0xAE register says 0x00, and differentiating balanced and low-power modes when 0xAE register value is 0x01, may probably be done by looking at victus_s_gpu_thermal_profile_get(), as prepared into platform_profile_victus_s_get_ec(): I see that Krishna Chomal had this idea. As I'm a beginner into kernel development I prefer let you decide whether it's reliable enough, and/or worth the effort.

In case you need me to do some tests and gather more information feel free to ask me!
Adding Cc to Suryansh Singh as I see recent related work to this EC reading offset of thermal profile on another Victus laptop, in case it helps having a better overview on this.

Best regards,
Julien ROBIN

PS:
Others identified EC offsets for my 8C9C by the way:

 - 0x8F register value is 0x00 unless performance mode has been enabled. It may be related to GPU gpu_ctgp_enable being set to true, in which case the register value goes to 0x04.
As opposed to 0xAE register, which may fallback to its default value when hp-wmi driver isn't active for more than 120 seconds, 0x8F register keeps its value. This may be tested more deeply if needed.

 - 0x8A, 0x8B and 0xFF registers are reflecting CPU power limits. 0x8B and 0xFF registers show the same values which are equal to "PPT LIMIT SLOW" from RyzenAdj, while 0x8A register show the value that appears in both "PPT LIMIT FAST" and "STAPM LIMIT" from RyzenAdj.

 - 0xB0 register is showing CPU temperature in celsius, 0xB4 is showing GPU temperature celsius, 0xB2 and 0xA7 registers also seems to give measured temperatures in celsius but it doesn't seem to be CPU nor GPU.

 - 0x11 and 0x14 register are linked to target fan speed; values are 0x12 at default fan speed mode (with "fan always on" enabled into the BIOS, otherwise 0x00), and values are 0x3A when maximum fan speed is enabled. It's not showing actual measured values, as during fan speed acceleration or deceleration, values aren't moving at all.

Re: hp_wmi: Unknown EC layout for board 8C9C

[Krishna Chomal]

On Sun, Oct 04, 2026 at 12:45:58AM +0200, Julien ROBIN wrote:
>Hi there, I got the following message into my dmesg log:
>
>hp_wmi: Unknown EC layout for board 8C9C. Thermal profile readback will be disabled. Please report this to platform-driver-x86@vger.kernel.org

Hi,

Thanks for reporting.

>I may help a little bit here, as two years ago I did the initial work to get fan speed reading and setting, and thermal profiles for the HP Victus 16s-1034nf (8C9C) which I'm still using. Nice to see new people added new things above this! I hope the "victus_s" naming scheme I introduced to differentiate from previous driver behavior when adding support to the Victus 16s-1034nf didn't turn to be inconsistent with added models names using the same behavior since then.

First of all, thank you for sending those patches. A lot of the current
infrastructure (fan controls/gpu power modes/etc) are built on top of
that.

As for the victus_s naming scheme, we did stick with it for a while, but
recently there have been some efforts in removing the inconsistent
naming [1].

>With nbfc-linux and ec_probe monitor command, I managed to check again EC offsets/registers meaning for this 8C9C laptop (currently running BIOS F.17 11/18/2025).
>
>0xAE offset is related to thermal profile, it shows 3 possible values:
> - 0x00 when in performance mode (while HP_VICTUS_S_THERMAL_PROFILE_PERFORMANCE = 0x01)
> - 0x01 when placed in balanced or low-power modes,
> - 0x02 when the laptop CPU power limits are back to default / fallback state: turns out this happens when an HPWMI_FAN_COUNT_GET_QUERY hasn't been played during the last 120 seconds. See hp_wmi_get_fan_count_userdefine_trigger() function.
>
>However when the 0xAE register value is at 0x02, playing an HPWMI_FAN_COUNT_GET_QUERY makes the 0xAE register back to its previous mode (and CPU power limits are set accordingly). So when value is 0x02, the previous value is kept (and may be restored from) somewhere else, but it doesn't seem to be from any other EC register. Even worse, when going to performance mode, HPWMI_SET_PERFORMANCE_MODE command is applying HP_VICTUS_S_THERMAL_PROFILE_PERFORMANCE = 0x01 which cause the 0xAE register to go to 0x00, so the logic of this EC register is different from what existed for others models (where the EC register value was the same as the one provided by the HPWMI_SET_PERFORMANCE_MODE query).

Correct, this is an important limitation in our current approach where
we reverse map EC read values to thermal profile parameters (provided
by the HPWMI_SET_PERFORMANCE_MODE query), and that doesn't always cover
it fully on all boards.

>Because of these sudden changes about EC registers behavior, I wasn't sure insisting on direct reading into EC registers was still going to be a sustainable approach for reading back thermal profile on this new kind of laptop. Facing BIOS updates, or tiny changes between similar models, may even cause such approach to break without warnings. It would also need people adding similar laptops to ensure 0xAE is still the right EC register to read, and double check the values are behaving the same. Which is why at startup, I preferred the mode to be initially set to balanced: to both cleanly ensure and say back which mode is enabled, without relying on risky tricks.

I am not sure how the current approach would be "risky" because we only
derive real platform profile state from EC when we have explicitly
identified the relevant offsets. For unknown boards, it still defaults
to balanced for a clean start.

That being said, I fully agree that with BIOS updates, the offsets *may*
shift leading to potential regressions and we should avoid this method.

>But despite this personal opinion, for the 8C9C, playing an HPWMI_FAN_COUNT_GET_QUERY, and guessing the current mode is performance mode (0x01) when 0xAE register says 0x00, and differentiating balanced and low-power modes when 0xAE register value is 0x01, may probably be done by looking at victus_s_gpu_thermal_profile_get(), as prepared into platform_profile_victus_s_get_ec(): I see that Krishna Chomal had this idea. As I'm a beginner into kernel development I prefer let you decide whether it's reliable enough, and/or worth the effort.

So, I was working on a series to fix this very issue, but now that you
have brought it up, I think its a good time to ask you and Ilpo Järvinen
if removing **ALL** EC offsets from this driver and relying on only WMI
queries would be a good idea.

Currently, the following four EC registers have been identified in this
driver:
1. HP_VICTUS_S_EC_THERMAL_PROFILE_OFFSET (0x59) [READ-ONLY]:
    Used in platform_profile_victus_s_get_ec() from params->ec_tp_offset
    Used to reverse map the thermal profile parameter and derive the real
    hardware state.

    platform_profile_victus_s_get_ec() itself is used in two places:
    a. thermal_profile_setup() during driver init to re-apply hardware
       state.
       We can remove the call here and default to Balanced
       mode like Julien had done in an earlier commit. [2]
       I think this is fair because the official Omen Gaming Hub software
       on Windows does the same when re-installed.
    b. victus_s_powersource_event() - to derive actual_profile. This
       Julien needs to confirm - if we can avoid doing an EC read by
       directly taking active_platform_profile, since in my opinion,
       it should be same.

2. HP_OMEN_EC_THERMAL_PROFILE_OFFSET (0x95) [READ_ONLY]:
    Used in three places:
    a. platform_profile_victus_s_get_ec(): Already mentioned above.
    b. platform_profile_omen_get_ec()
    c. platform_profile_victus_get_ec()

    (b) and (c) are both used in omen_powersource_event() for the same
        reason as victus_s line as mentioned above. I think here also
        we can fallback on the cached active_platform_profile (please
        let me know if otherwise).

3. HP_OMEN_EC_THERMAL_PROFILE_FLAGS_OFFSET (0x62) [WRITE-ONLY]
4. HP_OMEN_EC_THERMAL_PROFILE_TIMER_OFFSET (0x63) [WRITE-ONLY]

(3) and (4) are both used during set_ec path of the legacy Omen line.
However, since I do not own this type of device, I can't comment if it
is entirely needed or not. Interesting though, this is used in only
three devices: omen_timed_thermal_profile_boards[]. But anyway, I will
try to contact someone who sent these patches and see if I can get their
acpidump for more info. I have a feeling that at least *_TIMER_OFFSET
can be removed since the delayed_workqueue would cover its use-case,
and obviously because (afaik) the official Omen Gaming Hub does not
document/use any EC registers and relies on WMI queries only.

>In case you need me to do some tests and gather more information feel free to ask me!

Would it be possible for you to share your acpidump here? Not that we
need it, but I was just curious why 8C9C needs manual triggering of CPU
limits during power source change.

Thanks.

[1]: https://lore.kernel.org/platform-driver-x86/20260615091034.987029-2-radheykalra901@gmail.com
[2]: https://lore.kernel.org/all/1c00f906-8500-41d5-be80-f9092b6a49f1@free.fr

>Adding Cc to Suryansh Singh as I see recent related work to this EC reading offset of thermal profile on another Victus laptop, in case it helps having a better overview on this.
>
>Best regards,
>Julien ROBIN
>
>PS:
>Others identified EC offsets for my 8C9C by the way:
>
> - 0x8F register value is 0x00 unless performance mode has been enabled. It may be related to GPU gpu_ctgp_enable being set to true, in which case the register value goes to 0x04.
>As opposed to 0xAE register, which may fallback to its default value when hp-wmi driver isn't active for more than 120 seconds, 0x8F register keeps its value. This may be tested more deeply if needed.
>
> - 0x8A, 0x8B and 0xFF registers are reflecting CPU power limits. 0x8B and 0xFF registers show the same values which are equal to "PPT LIMIT SLOW" from RyzenAdj, while 0x8A register show the value that appears in both "PPT LIMIT FAST" and "STAPM LIMIT" from RyzenAdj.
>
> - 0xB0 register is showing CPU temperature in celsius, 0xB4 is showing GPU temperature celsius, 0xB2 and 0xA7 registers also seems to give measured temperatures in celsius but it doesn't seem to be CPU nor GPU.
>
> - 0x11 and 0x14 register are linked to target fan speed; values are 0x12 at default fan speed mode (with "fan always on" enabled into the BIOS, otherwise 0x00), and values are 0x3A when maximum fan speed is enabled. It's not showing actual measured values, as during fan speed acceleration or deceleration, values aren't moving at all.

Re: hp_wmi: Unknown EC layout for board 8C9C

[Julien ROBIN]

On 10/5/26 10:00 PM, Krishna Chomal wrote:
> On Sun, Oct 04, 2026 at 12:45:58AM +0200, Julien ROBIN wrote:
>> Hi there, I got the following message into my dmesg log:
>>
>> hp_wmi: Unknown EC layout for board 8C9C. Thermal profile readback will be disabled. Please report this to platform-driver-x86@vger.kernel.org
> 
> Hi,
> 
> Thanks for reporting.
> 
>> I may help a little bit here, as two years ago I did the initial work to get fan speed reading and setting, and thermal profiles for the HP Victus 16s-1034nf (8C9C) which I'm still using. Nice to see new people added new things above this! I hope the "victus_s" naming scheme I introduced to differentiate from previous driver behavior when adding support to the Victus 16s-1034nf didn't turn to be inconsistent with added models names using the same behavior since then.
> 
> First of all, thank you for sending those patches. A lot of the current
> infrastructure (fan controls/gpu power modes/etc) are built on top of
> that.
> 
> As for the victus_s naming scheme, we did stick with it for a while, but
> recently there have been some efforts in removing the inconsistent
> naming [1].
>

Thanks for the information, yes knowing the names of added models to stick the "victus_s" code parts, this naming may of course be updated and improved as soon as a clever and cleaner new behavior naming scheme is found to better differenciate them. In case behavior differences aren't due to being omen or victus laptops, but are based on clearly spotted others details (generation, CPU brand or anything else) this may help getting more inspired and less confusing names for all of these rival behaviors.
>> With nbfc-linux and ec_probe monitor command, I managed to check again EC offsets/registers meaning for this 8C9C laptop (currently running BIOS F.17 11/18/2025).
>>
>> 0xAE offset is related to thermal profile, it shows 3 possible values:
>> - 0x00 when in performance mode (while HP_VICTUS_S_THERMAL_PROFILE_PERFORMANCE = 0x01)
>> - 0x01 when placed in balanced or low-power modes,
>> - 0x02 when the laptop CPU power limits are back to default / fallback state: turns out this happens when an HPWMI_FAN_COUNT_GET_QUERY hasn't been played during the last 120 seconds. See hp_wmi_get_fan_count_userdefine_trigger() function.
>>
>> However when the 0xAE register value is at 0x02, playing an HPWMI_FAN_COUNT_GET_QUERY makes the 0xAE register back to its previous mode (and CPU power limits are set accordingly). So when value is 0x02, the previous value is kept (and may be restored from) somewhere else, but it doesn't seem to be from any other EC register. Even worse, when going to performance mode, HPWMI_SET_PERFORMANCE_MODE command is applying HP_VICTUS_S_THERMAL_PROFILE_PERFORMANCE = 0x01 which cause the 0xAE register to go to 0x00, so the logic of this EC register is different from what existed for others models (where the EC register value was the same as the one provided by the HPWMI_SET_PERFORMANCE_MODE query).
> 
> Correct, this is an important limitation in our current approach where
> we reverse map EC read values to thermal profile parameters (provided
> by the HPWMI_SET_PERFORMANCE_MODE query), and that doesn't always cover
> it fully on all boards.
> 
>> Because of these sudden changes about EC registers behavior, I wasn't sure insisting on direct reading into EC registers was still going to be a sustainable approach for reading back thermal profile on this new kind of laptop. Facing BIOS updates, or tiny changes between similar models, may even cause such approach to break without warnings. It would also need people adding similar laptops to ensure 0xAE is still the right EC register to read, and double check the values are behaving the same. Which is why at startup, I preferred the mode to be initially set to balanced: to both cleanly ensure and say back which mode is enabled, without relying on risky tricks.
> 
> I am not sure how the current approach would be "risky" because we only
> derive real platform profile state from EC when we have explicitly
> identified the relevant offsets. For unknown boards, it still defaults
> to balanced for a clean start.
> 
> That being said, I fully agree that with BIOS updates, the offsets *may*
> shift leading to potential regressions and we should avoid this method.
> 
>> But despite this personal opinion, for the 8C9C, playing an HPWMI_FAN_COUNT_GET_QUERY, and guessing the current mode is performance mode (0x01) when 0xAE register says 0x00, and differentiating balanced and low-power modes when 0xAE register value is 0x01, may probably be done by looking at victus_s_gpu_thermal_profile_get(), as prepared into platform_profile_victus_s_get_ec(): I see that Krishna Chomal had this idea. As I'm a beginner into kernel development I prefer let you decide whether it's reliable enough, and/or worth the effort.
> 
> So, I was working on a series to fix this very issue, but now that you
> have brought it up, I think its a good time to ask you and Ilpo Järvinen
> if removing **ALL** EC offsets from this driver and relying on only WMI
> queries would be a good idea.

Personnaly I wouldn't dare removing the work from previous contributors from the kernel 😅 but if (and only if) having the laptops automatically set to balanced mode at startup is fine for everyone (so that no ones deplores not being able to recover the previous mode on startup, and calls it a regression), it sure simplifies the driver, and future work on it.

> Currently, the following four EC registers have been identified in this
> driver:
> 1. HP_VICTUS_S_EC_THERMAL_PROFILE_OFFSET (0x59) [READ-ONLY]:
>    Used in platform_profile_victus_s_get_ec() from params->ec_tp_offset
>    Used to reverse map the thermal profile parameter and derive the real
>    hardware state.
> 
>    platform_profile_victus_s_get_ec() itself is used in two places:
>    a. thermal_profile_setup() during driver init to re-apply hardware
>       state.
>       We can remove the call here and default to Balanced
>       mode like Julien had done in an earlier commit. [2]
>       I think this is fair because the official Omen Gaming Hub software
>       on Windows does the same when re-installed.
>    b. victus_s_powersource_event() - to derive actual_profile. This
>       Julien needs to confirm - if we can avoid doing an EC read by
>       directly taking active_platform_profile, since in my opinion,
>       it should be same.
> 
> 2. HP_OMEN_EC_THERMAL_PROFILE_OFFSET (0x95) [READ_ONLY]:
>    Used in three places:
>    a. platform_profile_victus_s_get_ec(): Already mentioned above.
>    b. platform_profile_omen_get_ec()
>    c. platform_profile_victus_get_ec()
> 
>    (b) and (c) are both used in omen_powersource_event() for the same
>        reason as victus_s line as mentioned above. I think here also
>        we can fallback on the cached active_platform_profile (please
>        let me know if otherwise).

This is what I thought too, when realizing I wasn't quite able to read it by EC at that time. If platform_profile is applied and kept cached before going to sleep or changing power source, then being able to re-apply it when needed seemed fine to me.
I guess some OS settings and user defined preferences may automatically ask for a platform profile change under user defined circumstances (going on battery, after some fixed idle time, or anything), but I came to the conclusion that it's not causing troubles here, assuming the driver is able keep its own mode as long as not asked to change, and able to apply when a mode change is requested.

> 
> 3. HP_OMEN_EC_THERMAL_PROFILE_FLAGS_OFFSET (0x62) [WRITE-ONLY]
> 4. HP_OMEN_EC_THERMAL_PROFILE_TIMER_OFFSET (0x63) [WRITE-ONLY]
> 
> (3) and (4) are both used during set_ec path of the legacy Omen line.
> However, since I do not own this type of device, I can't comment if it
> is entirely needed or not. Interesting though, this is used in only
> three devices: omen_timed_thermal_profile_boards[]. But anyway, I will
> try to contact someone who sent these patches and see if I can get their
> acpidump for more info. I have a feeling that at least *_TIMER_OFFSET
> can be removed since the delayed_workqueue would cover its use-case,
> and obviously because (afaik) the official Omen Gaming Hub does not
> document/use any EC registers and relies on WMI queries only.
> 

When I looked at it at that time, I didn't find any EC register showing such behavior into my device (but of course I assumed people who implemented that on others laptops were right, their laptop were just different from mine). However if it turns out writes to these EC registers can be replaced by new WMI queries approach currently used for newer devices, it would be a win!

I saw these new calls to mod_delayed_work() which have been added when setting manual or max fan speed, so that in the end, hp_wmi_get_fan_count_userdefine_trigger() get called periodically. This approach is pretty cool! And may be generalized to thermal profiles too (as it turns out, when letting fan speed to automatic, and not doing anything with platform_profiles for more than 120 seconds, CPU power limits are back to fallback until something calls hp_wmi_get_fan_count_userdefine_trigger again). Nothing urgent as (in my case) CPU power limits are just reducing a little bit after 120 seconds when not asking for max fan speed: turns out to be safe. Wasn't sure at that time if/how this device specific thing had to be settled from the hp-wmi driver, but delayed_workqueue seems to be the right way to go.

>> In case you need me to do some tests and gather more information feel free to ask me!
> 
> Would it be possible for you to share your acpidump here? Not that we
> need it, but I was just curious why 8C9C needs manual triggering of CPU
> limits during power source change.
> 
> Thanks.
> 
> [1]: https://lore.kernel.org/platform-driver-x86/20260615091034.987029-2-radheykalra901@gmail.com
> [2]: https://lore.kernel.org/all/1c00f906-8500-41d5-be80-f9092b6a49f1@free.fr

Here is the acpidump of my device (hex and bin format)
 - https://pix-server-sorel.luoss.fr/Manual/Linux/HP-WMI/HP-Victus-16-s1034nf-8C9C-BIOS-F18-2026-10-06.hex
 - https://pix-server-sorel.luoss.fr/Manual/Linux/HP-WMI/HP-Victus-16-s1034nf-8C9C-BIOS-F18-2026-10-06.tar

I have an older (F.11) BIOS version acpidump here, format seems to change a little bit, but it's hex 
 - https://pix-server-sorel.luoss.fr/Manual/Linux/HP-WMI/Bug-Report-2024-12-12/fwts-output/acpidump.log

About victus_s_powersource_event() to manually trigger CPU power limits change, I remember the problem only existed when performance mode was active, it was only about CPU power limits (not GPU) and didn't exist with any of the others modes (balanced, low-power or fallback). Maximum/excessive power limits were kept despite going from AC to battery, and I believe they also weren't restored correctly when going back on AC. On Windows with Omen Gaming Hub this seemed to be addressed by rewriting power limits on power source change. As I updated BIOS to F.18 I'll check if anything evolved about this.

I'll do the tests tonight: Unloading hp-wmi driver and looking at RyzenAdj allows testing what happens when nothing is done by hp-wmi driver. But I need physical access to the device to unplug the cord, and also to put it to sleep mode, waking it up.
I'll keep you informed of the results.

> 
>> Adding Cc to Suryansh Singh as I see recent related work to this EC reading offset of thermal profile on another Victus laptop, in case it helps having a better overview on this.
>>
>> Best regards,
>> Julien ROBIN
>>
>> PS:
>> Others identified EC offsets for my 8C9C by the way:
>>
>> - 0x8F register value is 0x00 unless performance mode has been enabled. It may be related to GPU gpu_ctgp_enable being set to true, in which case the register value goes to 0x04.
>> As opposed to 0xAE register, which may fallback to its default value when hp-wmi driver isn't active for more than 120 seconds, 0x8F register keeps its value. This may be tested more deeply if needed.
>>
>> - 0x8A, 0x8B and 0xFF registers are reflecting CPU power limits. 0x8B and 0xFF registers show the same values which are equal to "PPT LIMIT SLOW" from RyzenAdj, while 0x8A register show the value that appears in both "PPT LIMIT FAST" and "STAPM LIMIT" from RyzenAdj.
>>
>> - 0xB0 register is showing CPU temperature in celsius, 0xB4 is showing GPU temperature celsius, 0xB2 and 0xA7 registers also seems to give measured temperatures in celsius but it doesn't seem to be CPU nor GPU.
>>
>> - 0x11 and 0x14 register are linked to target fan speed; values are 0x12 at default fan speed mode (with "fan always on" enabled into the BIOS, otherwise 0x00), and values are 0x3A when maximum fan speed is enabled. It's not showing actual measured values, as during fan speed acceleration or deceleration, values aren't moving at all.

Re: hp_wmi: Unknown EC layout for board 8C9C

[Julien ROBIN]

> About victus_s_powersource_event() to manually trigger CPU power limits change, I remember the problem only existed when performance mode was active, it was only about CPU power limits (not GPU) and didn't exist with any of the others modes (balanced, low-power or fallback). Maximum/excessive power limits were kept despite going from AC to battery, and I believe they also weren't restored correctly when going back on AC. On Windows with Omen Gaming Hub this seemed to be addressed by rewriting power limits on power source change. As I updated BIOS to F.18 I'll check if anything evolved about this.
> 
> I'll do the tests tonight: Unloading hp-wmi driver and looking at RyzenAdj allows testing what happens when nothing is done by hp-wmi driver. But I need physical access to the device to unplug the cord, and also to put it to sleep mode, waking it up.
> I'll keep you informed of the results.

Hi back, to complete my feedback from few hours ago: having physical access to the laptop I did the complete tests again on BIOS F.18, same behavior as BIOS F.11

About going to suspend / waking up the computer from sleep:
 - When the computer is placed to suspend mode while performance mode is active, and hp-wmi unloaded, when resuming, it's still in performance mode without having to ask for it again (even if asleep for more than 120 seconds)
 - About the 120 seconds delay before going to fallback mode, this delay is only elapsing when the computer is running. When resuming, 120 seconds are available again (even if only few seconds were left when entering suspend mode)
 - However when the computer is placed to suspend mode while max fan speed is active, when resuming the fan isn't max speed anymore.

About power source changes:
 - When the laptop is running on performance mode, unloading the hp-wmi driver and disconnecting the power plug let the CPU stuck to maximum/excessive power limits (60/65W in my case instead of expected reduction to 25/30W when running on battery).
 - Same thing in the other way, when the laptop is running on battery, on performance mode and CPU power limits to 25/30W, unloading hp-wmi driver and connecting the power plug let the CPU stuck to low power limits (instead of rising to 60/65W).
 - However if the power source change occurs while the computer is suspended, then when waking up, the CPU power limits are set to the right ones by the laptop itself.
 - Also, in every others modes (balanced, low-power, or fallback after 120 seconds without hp-wmi interaction), on power source changes, CPU power limits are automatically adjusted by the laptop itself.

So the laptop forgetting to adjust CPU power limits on power source change, only occurs in performance mode while the computer isn't suspended.
In any other circumstance the laptop behave fine. Would be interesting to see if this strange quirk I found out by extensive testing also occurs to some others models.

As always, I keep available if anything more is needed!
Thanks again for the work

Best regards,
Julien

Re: hp_wmi: Unknown EC layout for board 8C9C

[Krishna Chomal]

On Wed, Oct 07, 2026 at 03:17:00AM +0200, Julien ROBIN wrote:
>> About victus_s_powersource_event() to manually trigger CPU power limits change, I remember the problem only existed when performance mode was active, it was only about CPU power limits (not GPU) and didn't exist with any of the others modes (balanced, low-power or fallback). Maximum/excessive power limits were kept despite going from AC to battery, and I believe they also weren't restored correctly when going back on AC. On Windows with Omen Gaming Hub this seemed to be addressed by rewriting power limits on power source change. As I updated BIOS to F.18 I'll check if anything evolved about this.
>>
>> I'll do the tests tonight: Unloading hp-wmi driver and looking at RyzenAdj allows testing what happens when nothing is done by hp-wmi driver. But I need physical access to the device to unplug the cord, and also to put it to sleep mode, waking it up.
>> I'll keep you informed of the results.
>
>Hi back, to complete my feedback from few hours ago: having physical access to the laptop I did the complete tests again on BIOS F.18, same behavior as BIOS F.11
>
>About going to suspend / waking up the computer from sleep:
> - When the computer is placed to suspend mode while performance mode is active, and hp-wmi unloaded, when resuming, it's still in performance mode without having to ask for it again (even if asleep for more than 120 seconds)
> - About the 120 seconds delay before going to fallback mode, this delay is only elapsing when the computer is running. When resuming, 120 seconds are available again (even if only few seconds were left when entering suspend mode)
> - However when the computer is placed to suspend mode while max fan speed is active, when resuming the fan isn't max speed anymore.
>
>About power source changes:
> - When the laptop is running on performance mode, unloading the hp-wmi driver and disconnecting the power plug let the CPU stuck to maximum/excessive power limits (60/65W in my case instead of expected reduction to 25/30W when running on battery).
> - Same thing in the other way, when the laptop is running on battery, on performance mode and CPU power limits to 25/30W, unloading hp-wmi driver and connecting the power plug let the CPU stuck to low power limits (instead of rising to 60/65W).
> - However if the power source change occurs while the computer is suspended, then when waking up, the CPU power limits are set to the right ones by the laptop itself.
> - Also, in every others modes (balanced, low-power, or fallback after 120 seconds without hp-wmi interaction), on power source changes, CPU power limits are automatically adjusted by the laptop itself.
>
>So the laptop forgetting to adjust CPU power limits on power source change, only occurs in performance mode while the computer isn't suspended.
>In any other circumstance the laptop behave fine. Would be interesting to see if this strange quirk I found out by extensive testing also occurs to some others models.

I wish I could test it, but unfortunately sleep modes in firmware are
broken for a lot of laptops in the Omen series (including mine) so I
would not be able to wake up from sleep and test the states.

I did test the CPU power limits during power supply change as you
suggested. For me, it looks like the firmware is automatically taking
care of it. But to be fair, it doesn't cost us a lot to enforce limits
during such events, so it is fine if it is applied on all boards.

>As always, I keep available if anything more is needed!
>Thanks again for the work

I will be sure to get my patches tested by you, when I do eventually
start working on this. Thanks a lot for your help.

>Best regards,
>Julien

Re: hp_wmi: Unknown EC layout for board 8C9C

[Krishna Chomal]

On Tue, Oct 06, 2026 at 03:41:48PM +0200, Julien ROBIN wrote:
>On 10/5/26 10:00 PM, Krishna Chomal wrote:
>> On Sun, Oct 04, 2026 at 12:45:58AM +0200, Julien ROBIN wrote:
>>> Hi there, I got the following message into my dmesg log:
>>>
>>> hp_wmi: Unknown EC layout for board 8C9C. Thermal profile readback will be disabled. Please report this to platform-driver-x86@vger.kernel.org
>>
>> Hi,
>>
>> Thanks for reporting.
>>
>>> I may help a little bit here, as two years ago I did the initial work to get fan speed reading and setting, and thermal profiles for the HP Victus 16s-1034nf (8C9C) which I'm still using. Nice to see new people added new things above this! I hope the "victus_s" naming scheme I introduced to differentiate from previous driver behavior when adding support to the Victus 16s-1034nf didn't turn to be inconsistent with added models names using the same behavior since then.
>>
>> First of all, thank you for sending those patches. A lot of the current
>> infrastructure (fan controls/gpu power modes/etc) are built on top of
>> that.
>>
>> As for the victus_s naming scheme, we did stick with it for a while, but
>> recently there have been some efforts in removing the inconsistent
>> naming [1].
>>
>
>Thanks for the information, yes knowing the names of added models to stick the "victus_s" code parts, this naming may of course be updated and improved as soon as a clever and cleaner new behavior naming scheme is found to better differenciate them. In case behavior differences aren't due to being omen or victus laptops, but are based on clearly spotted others details (generation, CPU brand or anything else) this may help getting more inspired and less confusing names for all of these rival behaviors.
>>> With nbfc-linux and ec_probe monitor command, I managed to check again EC offsets/registers meaning for this 8C9C laptop (currently running BIOS F.17 11/18/2025).
>>>
>>> 0xAE offset is related to thermal profile, it shows 3 possible values:
>>> - 0x00 when in performance mode (while HP_VICTUS_S_THERMAL_PROFILE_PERFORMANCE = 0x01)
>>> - 0x01 when placed in balanced or low-power modes,
>>> - 0x02 when the laptop CPU power limits are back to default / fallback state: turns out this happens when an HPWMI_FAN_COUNT_GET_QUERY hasn't been played during the last 120 seconds. See hp_wmi_get_fan_count_userdefine_trigger() function.
>>>
>>> However when the 0xAE register value is at 0x02, playing an HPWMI_FAN_COUNT_GET_QUERY makes the 0xAE register back to its previous mode (and CPU power limits are set accordingly). So when value is 0x02, the previous value is kept (and may be restored from) somewhere else, but it doesn't seem to be from any other EC register. Even worse, when going to performance mode, HPWMI_SET_PERFORMANCE_MODE command is applying HP_VICTUS_S_THERMAL_PROFILE_PERFORMANCE = 0x01 which cause the 0xAE register to go to 0x00, so the logic of this EC register is different from what existed for others models (where the EC register value was the same as the one provided by the HPWMI_SET_PERFORMANCE_MODE query).
>>
>> Correct, this is an important limitation in our current approach where
>> we reverse map EC read values to thermal profile parameters (provided
>> by the HPWMI_SET_PERFORMANCE_MODE query), and that doesn't always cover
>> it fully on all boards.
>>
>>> Because of these sudden changes about EC registers behavior, I wasn't sure insisting on direct reading into EC registers was still going to be a sustainable approach for reading back thermal profile on this new kind of laptop. Facing BIOS updates, or tiny changes between similar models, may even cause such approach to break without warnings. It would also need people adding similar laptops to ensure 0xAE is still the right EC register to read, and double check the values are behaving the same. Which is why at startup, I preferred the mode to be initially set to balanced: to both cleanly ensure and say back which mode is enabled, without relying on risky tricks.
>>
>> I am not sure how the current approach would be "risky" because we only
>> derive real platform profile state from EC when we have explicitly
>> identified the relevant offsets. For unknown boards, it still defaults
>> to balanced for a clean start.
>>
>> That being said, I fully agree that with BIOS updates, the offsets *may*
>> shift leading to potential regressions and we should avoid this method.
>>
>>> But despite this personal opinion, for the 8C9C, playing an HPWMI_FAN_COUNT_GET_QUERY, and guessing the current mode is performance mode (0x01) when 0xAE register says 0x00, and differentiating balanced and low-power modes when 0xAE register value is 0x01, may probably be done by looking at victus_s_gpu_thermal_profile_get(), as prepared into platform_profile_victus_s_get_ec(): I see that Krishna Chomal had this idea. As I'm a beginner into kernel development I prefer let you decide whether it's reliable enough, and/or worth the effort.
>>
>> So, I was working on a series to fix this very issue, but now that you
>> have brought it up, I think its a good time to ask you and Ilpo Järvinen
>> if removing **ALL** EC offsets from this driver and relying on only WMI
>> queries would be a good idea.
>
>Personnaly I wouldn't dare removing the work from previous contributors from the kernel 😅 but if (and only if) having the laptops automatically set to balanced mode at startup is fine for everyone (so that no ones deplores not being able to recover the previous mode on startup, and calls it a regression), it sure simplifies the driver, and future work on it.

Yes I mean it is valuable information we have collected overtime. But if
involving EC registers in a WMI based driver causes complications rather
than making things easy, we should reconsider if it is needed or not.

Regarding the potential regression you are suggesting, that happens
already. When I put my laptop to "low-power" platform profile mode, it
calls HPWMI_SET_PERFORMANCE_MODE with 0x30 mode (reflected in EC register
0x59 in my case). On next boot (assuming AC power supply connected),
the firmware automatically writes value 0x01 in register 0x59, which is
read in platform_profile_victus_s_get_ec() and after reverse mapping it
returns "performance" mode to userspace. So the previous state is anyway
lost even with the EC based approach.

>> Currently, the following four EC registers have been identified in this
>> driver:
>> 1. HP_VICTUS_S_EC_THERMAL_PROFILE_OFFSET (0x59) [READ-ONLY]:
>>    Used in platform_profile_victus_s_get_ec() from params->ec_tp_offset
>>    Used to reverse map the thermal profile parameter and derive the real
>>    hardware state.
>>
>>    platform_profile_victus_s_get_ec() itself is used in two places:
>>    a. thermal_profile_setup() during driver init to re-apply hardware
>>       state.
>>       We can remove the call here and default to Balanced
>>       mode like Julien had done in an earlier commit. [2]
>>       I think this is fair because the official Omen Gaming Hub software
>>       on Windows does the same when re-installed.
>>    b. victus_s_powersource_event() - to derive actual_profile. This
>>       Julien needs to confirm - if we can avoid doing an EC read by
>>       directly taking active_platform_profile, since in my opinion,
>>       it should be same.
>>
>> 2. HP_OMEN_EC_THERMAL_PROFILE_OFFSET (0x95) [READ_ONLY]:
>>    Used in three places:
>>    a. platform_profile_victus_s_get_ec(): Already mentioned above.
>>    b. platform_profile_omen_get_ec()
>>    c. platform_profile_victus_get_ec()
>>
>>    (b) and (c) are both used in omen_powersource_event() for the same
>>        reason as victus_s line as mentioned above. I think here also
>>        we can fallback on the cached active_platform_profile (please
>>        let me know if otherwise).
>
>This is what I thought too, when realizing I wasn't quite able to read it by EC at that time. If platform_profile is applied and kept cached before going to sleep or changing power source, then being able to re-apply it when needed seemed fine to me.
>I guess some OS settings and user defined preferences may automatically ask for a platform profile change under user defined circumstances (going on battery, after some fixed idle time, or anything), but I came to the conclusion that it's not causing troubles here, assuming the driver is able keep its own mode as long as not asked to change, and able to apply when a mode change is requested.

Yes using the cached state looks good to me too.

>>
>> 3. HP_OMEN_EC_THERMAL_PROFILE_FLAGS_OFFSET (0x62) [WRITE-ONLY]
>> 4. HP_OMEN_EC_THERMAL_PROFILE_TIMER_OFFSET (0x63) [WRITE-ONLY]
>>
>> (3) and (4) are both used during set_ec path of the legacy Omen line.
>> However, since I do not own this type of device, I can't comment if it
>> is entirely needed or not. Interesting though, this is used in only
>> three devices: omen_timed_thermal_profile_boards[]. But anyway, I will
>> try to contact someone who sent these patches and see if I can get their
>> acpidump for more info. I have a feeling that at least *_TIMER_OFFSET
>> can be removed since the delayed_workqueue would cover its use-case,
>> and obviously because (afaik) the official Omen Gaming Hub does not
>> document/use any EC registers and relies on WMI queries only.
>>
>
>When I looked at it at that time, I didn't find any EC register showing such behavior into my device (but of course I assumed people who implemented that on others laptops were right, their laptop were just different from mine). However if it turns out writes to these EC registers can be replaced by new WMI queries approach currently used for newer devices, it would be a win!

Yes your EC layout may be slightly different. Unfortunately, there are a
lot of variations in EC layouts across these devices which complicates
things.

>I saw these new calls to mod_delayed_work() which have been added when setting manual or max fan speed, so that in the end, hp_wmi_get_fan_count_userdefine_trigger() get called periodically. This approach is pretty cool! And may be generalized to thermal profiles too (as it turns out, when letting fan speed to automatic, and not doing anything with platform_profiles for more than 120 seconds, CPU power limits are back to fallback until something calls hp_wmi_get_fan_count_userdefine_trigger again). Nothing urgent as (in my case) CPU power limits are just reducing a little bit after 120 seconds when not asking for max fan speed: turns out to be safe. Wasn't sure at that time if/how this device specific thing had to be settled from the hp-wmi driver, but delayed_workqueue seems to be the right way to go.

When I originally added schedule_delayed_work() to fix the 120s
timeout without relying on EC offsets, I thought fan modes were the
only thing being affected by timeout (because GPU limit does not drop
down automatically) and I did not test CPU power limits, which is why it
became scoped to only hwmon device. This in fact, was also reported by
someone on bugzilla to which I suggested the same thing: extend dwork
to cover both hwmon + platform_profile, sadly I never got time to work
on it and I have lost that thread somewhere.

>>> In case you need me to do some tests and gather more information feel free to ask me!
>>
>> Would it be possible for you to share your acpidump here? Not that we
>> need it, but I was just curious why 8C9C needs manual triggering of CPU
>> limits during power source change.
>>
>> Thanks.
>>
>> [1]: https://lore.kernel.org/platform-driver-x86/20260615091034.987029-2-radheykalra901@gmail.com
>> [2]: https://lore.kernel.org/all/1c00f906-8500-41d5-be80-f9092b6a49f1@free.fr
>
>Here is the acpidump of my device (hex and bin format)
> - https://pix-server-sorel.luoss.fr/Manual/Linux/HP-WMI/HP-Victus-16-s1034nf-8C9C-BIOS-F18-2026-10-06.hex
> - https://pix-server-sorel.luoss.fr/Manual/Linux/HP-WMI/HP-Victus-16-s1034nf-8C9C-BIOS-F18-2026-10-06.tar
>
>I have an older (F.11) BIOS version acpidump here, format seems to change a little bit, but it's hex
> - https://pix-server-sorel.luoss.fr/Manual/Linux/HP-WMI/Bug-Report-2024-12-12/fwts-output/acpidump.log

Thanks a lot!

>About victus_s_powersource_event() to manually trigger CPU power limits change, I remember the problem only existed when performance mode was active, it was only about CPU power limits (not GPU) and didn't exist with any of the others modes (balanced, low-power or fallback). Maximum/excessive power limits were kept despite going from AC to battery, and I believe they also weren't restored correctly when going back on AC. On Windows with Omen Gaming Hub this seemed to be addressed by rewriting power limits on power source change. As I updated BIOS to F.18 I'll check if anything evolved about this.
>
>I'll do the tests tonight: Unloading hp-wmi driver and looking at RyzenAdj allows testing what happens when nothing is done by hp-wmi driver. But I need physical access to the device to unplug the cord, and also to put it to sleep mode, waking it up.
>I'll keep you informed of the results.
>
>>
>>> Adding Cc to Suryansh Singh as I see recent related work to this EC reading offset of thermal profile on another Victus laptop, in case it helps having a better overview on this.
>>>
>>> Best regards,
>>> Julien ROBIN
>>>
>>> PS:
>>> Others identified EC offsets for my 8C9C by the way:
>>>
>>> - 0x8F register value is 0x00 unless performance mode has been enabled. It may be related to GPU gpu_ctgp_enable being set to true, in which case the register value goes to 0x04.
>>> As opposed to 0xAE register, which may fallback to its default value when hp-wmi driver isn't active for more than 120 seconds, 0x8F register keeps its value. This may be tested more deeply if needed.
>>>
>>> - 0x8A, 0x8B and 0xFF registers are reflecting CPU power limits. 0x8B and 0xFF registers show the same values which are equal to "PPT LIMIT SLOW" from RyzenAdj, while 0x8A register show the value that appears in both "PPT LIMIT FAST" and "STAPM LIMIT" from RyzenAdj.
>>>
>>> - 0xB0 register is showing CPU temperature in celsius, 0xB4 is showing GPU temperature celsius, 0xB2 and 0xA7 registers also seems to give measured temperatures in celsius but it doesn't seem to be CPU nor GPU.
>>>
>>> - 0x11 and 0x14 register are linked to target fan speed; values are 0x12 at default fan speed mode (with "fan always on" enabled into the BIOS, otherwise 0x00), and values are 0x3A when maximum fan speed is enabled. It's not showing actual measured values, as during fan speed acceleration or deceleration, values aren't moving at all.
>