From: Krishna Chomal <krishna.chomal108@gmail.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Hans de Goede <hansg@kernel.org>, platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH] platform/x86: hp-wmi: fix platform profile values for Omen 16-wf1xxx
Date: Tue, 16 Dec 2025 15:50:27 +0530 [thread overview]
Message-ID: <aUEty81BD-FaT0Mj@archlinux> (raw)
In-Reply-To: <6ae912bf-ceb9-b8cf-5e9b-831c91135a59@linux.intel.com>
Hi Ilpo,
On Mon, Dec 15, 2025 at 04:25:17PM +0200, Ilpo Järvinen wrote:
>Thank you for the patch but it looks this approach to add mappings using
>if()s to handle variations should be replaced with something better.
Thank you for the feedback. I agree that stacking if/else statements for
board variations is not a scalable idea.
For V2, I plan to refactor this driver to use DMI system ID table's
driver_data field to handle the profile mapping (at least for
victus_s_thermal_profile_boards in this patch).
The implementation will introduce a `struct thermal_profile_params` to
hold the specific thermal values (Performance/Balanced/Low-Power). Then
I can convert victus_s_thermal_profile_boards from a simple string
array to a `struct dmi_system_id[]` array, where each entry maps a DMI
Board Name to its specific thermal_profile_params via driver_data.
Then platform_profile_victus_s_set_ec can simply retrieve the correct
parameters via dmi_first_match(), removing the need for nested if()s.
I feel this restructuring makes the code much cleaner and makes the
thermal profile choice for new boards explicit. Does this plan look like
the right direction for V2?
next prev parent reply other threads:[~2025-12-16 10:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-13 18:51 [PATCH] platform/x86: hp-wmi: fix platform profile values for Omen 16-wf1xxx Krishna Chomal
2025-12-15 14:25 ` Ilpo Järvinen
2025-12-16 10:20 ` Krishna Chomal [this message]
2025-12-16 10:33 ` Ilpo Järvinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aUEty81BD-FaT0Mj@archlinux \
--to=krishna.chomal108@gmail.com \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.