Re: hp_wmi: Unknown EC layout for board 8C9C

[Krishna Chomal <krishna.chomal108@gmail.com>]

On Tue, Oct 06, 2026 at 01:30:43AM +0530, Krishna Chomal wrote:
[...]
>>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.

Hi Ilpo,

Gentle ping on this. Can you read this thread and share your opinions on
my proposal to make this driver EC independent?

If we agree on removing platform_profile_victus_s_get_ec(), it would
affect at least these patches:
1. https://lore.kernel.org/all/20261024-hp-wmi-rechargement-v1-1-45d9f8447f41@arnaud-ungaro.fr
2. https://lore.kernel.org/all/20261025034539.4565-1-nonameblank007@gmail.com

>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.
[...]