linux-kernel - Re: [PATCH v5 2/2] platform/x86: hp-wmi: Add EC offsets to read Victus S thermal profile

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXCnMsxMJ5Nio0Tr@archlinux>
Date: Wed, 21 Jan 2026 16:00:07 +0530
From: Krishna Chomal <krishna.chomal108@...il.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: Hans de Goede <hansg@...nel.org>, platform-driver-x86@...r.kernel.org, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 2/2] platform/x86: hp-wmi: Add EC offsets to read
 Victus S thermal profile

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!