From: Denis Benato <benato.denis96@gmail.com>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Mario Limonciello" <superm1@kernel.org>,
"Hans de Goede" <hdegoede@redhat.com>,
"Mark Pearson" <mpearson-lenovo@squebb.ca>,
"Luke D . Jones" <luke@ljones.dev>
Cc: LKML <linux-kernel@vger.kernel.org>,
platform-driver-x86@vger.kernel.org,
Alok Tiwari <alok.a.tiwari@oracle.com>,
Derek John Clark <derekjohn.clark@gmail.com>,
Mateusz Schyboll <dragonn@op.pl>,
porfet828@gmail.com
Subject: Re: [PATCH v14 5/9] platform/x86: asus-armoury: add core count control
Date: Sun, 19 Oct 2025 18:53:01 +0200 [thread overview]
Message-ID: <78f9c831-0c0c-4497-9a77-0380e27cc616@gmail.com> (raw)
In-Reply-To: <25bd0c90-2de0-ef66-c18d-661180b71fd4@linux.intel.com>
On 10/17/25 14:48, Ilpo Järvinen wrote:
> On Wed, 15 Oct 2025, Denis Benato wrote:
>
>> From: "Luke D. Jones" <luke@ljones.dev>
>>
>> Implement Intel core enablement under the asus-armoury module using the
>> fw_attributes class.
>>
>> This allows users to enable or disable preformance or efficiency cores
>> depending on their requirements. After change a reboot is required.
>>
>> Signed-off-by: Denis Benato <benato.denis96@gmail.com>
>> Signed-off-by: Luke D. Jones <luke@ljones.dev>
>> ---
>> drivers/platform/x86/asus-armoury.c | 258 ++++++++++++++++++++-
>> drivers/platform/x86/asus-armoury.h | 28 +++
>> include/linux/platform_data/x86/asus-wmi.h | 5 +
>> 3 files changed, 290 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/platform/x86/asus-armoury.c b/drivers/platform/x86/asus-armoury.c
>> index 3b49a27e397d..3d963025d84e 100644
>> --- a/drivers/platform/x86/asus-armoury.c
>> +++ b/drivers/platform/x86/asus-armoury.c
>> @@ -45,13 +45,49 @@
>> #define ASUS_MINI_LED_2024_STRONG 0x01
>> #define ASUS_MINI_LED_2024_OFF 0x02
>>
>> +#define ASUS_POWER_CORE_MASK GENMASK(15, 8)
>> +#define ASUS_PERF_CORE_MASK GENMASK(7, 0)
>> +
>> +enum cpu_core_type {
>> + CPU_CORE_PERF = 0,
>> + CPU_CORE_POWER,
>> +};
>> +
>> +enum cpu_core_value {
>> + CPU_CORE_DEFAULT = 0,
> This could be mapped in the sysfs _show function as there's no real
> backing value for it.
It is also used in a store function called by both _stores and
I wouldn't like the idea of transforming it in a u32 given
the importance of data to be correct in this specific interface.
The last thing I want is making device unbootable because
I missed a CPU_CORE_PERF vs CPU_CORE_POWER or because
I misremember while changing the code that CORE_PERF means
performance and CORE_POWER means efficiency
(and it took me a minute to get this spelled right in this email).
>> + CPU_CORE_MIN,
>> + CPU_CORE_MAX,
>> + CPU_CORE_CURRENT,
>> +};
>> +
>> +#define CPU_PERF_CORE_COUNT_MIN 4
>> +#define CPU_POWR_CORE_COUNT_MIN 0
>> +
>> +/* Tunables provided by ASUS for gaming laptops */
>> +struct cpu_cores {
>> + u32 cur_perf_cores;
>> + u32 min_perf_cores;
>> + u32 max_perf_cores;
>> + u32 cur_power_cores;
>> + u32 min_power_cores;
>> + u32 max_power_cores;
>> +};
>> +
>> static struct asus_armoury_priv {
>> struct device *fw_attr_dev;
>> struct kset *fw_attr_kset;
>>
>> + struct cpu_cores *cpu_cores;
>> u32 mini_led_dev_id;
>> u32 gpu_mux_dev_id;
>> -} asus_armoury;
>> + /*
>> + * Mutex to prevent big/little core count changes writing to same
>> + * endpoint at the same time. Must lock during attr store.
>> + */
>> + struct mutex cpu_core_mutex;
>> +} asus_armoury = {
>> + .cpu_core_mutex = __MUTEX_INITIALIZER(asus_armoury.cpu_core_mutex)
>> +};
>>
>> struct fw_attrs_group {
>> bool pending_reboot;
>> @@ -93,6 +129,8 @@ static struct kobj_attribute pending_reboot = __ATTR_RO(pending_reboot);
>> static bool asus_bios_requires_reboot(struct kobj_attribute *attr)
>> {
>> return !strcmp(attr->attr.name, "gpu_mux_mode") ||
>> + !strcmp(attr->attr.name, "cores_performance") ||
>> + !strcmp(attr->attr.name, "cores_efficiency") ||
>> !strcmp(attr->attr.name, "panel_hd_mode");
>> }
>>
>> @@ -171,6 +209,12 @@ static ssize_t enum_type_show(struct kobject *kobj, struct kobj_attribute *attr,
>> return sysfs_emit(buf, "enumeration\n");
>> }
>>
>> +static ssize_t int_type_show(struct kobject *kobj, struct kobj_attribute *attr,
>> + char *buf)
>> +{
>> + return sysfs_emit(buf, "integer\n");
>> +}
>> +
>> /* Mini-LED mode **************************************************************/
>> static ssize_t mini_led_mode_current_value_show(struct kobject *kobj,
>> struct kobj_attribute *attr, char *buf)
>> @@ -474,6 +518,207 @@ static ssize_t apu_mem_possible_values_show(struct kobject *kobj, struct kobj_at
>> }
>> ATTR_GROUP_ENUM_CUSTOM(apu_mem, "apu_mem", "Set available system RAM (in GB) for the APU to use");
>>
>> +static int init_max_cpu_cores(void)
>> +{
>> + u32 cores;
>> + int err;
>> +
>> + asus_armoury.cpu_cores = kzalloc(sizeof(struct cpu_cores), GFP_KERNEL);
>> + if (!asus_armoury.cpu_cores)
>> + return -ENOMEM;
>> +
>> + err = asus_wmi_get_devstate_dsts(ASUS_WMI_DEVID_CORES_MAX, &cores);
>> + if (err)
>> + return err;
>> +
>> + if ((cores & ASUS_WMI_DSTS_PRESENCE_BIT) == 0) {
>> + pr_err("ACPI does not support CPU core count control\n");
>> + err = -ENODEV;
>> + goto init_max_cpu_cores_err;
> Please use __free() and return immediately.
>
> Only assign from local variable to asus_armoury.cpu_cores with
> no_free_ptr() at the end.
>
>> + }
>> +
>> + asus_armoury.cpu_cores->max_power_cores = FIELD_GET(ASUS_POWER_CORE_MASK, cores);
>> + asus_armoury.cpu_cores->max_perf_cores = FIELD_GET(ASUS_PERF_CORE_MASK, cores);
>> +
>> + err = asus_wmi_get_devstate_dsts(ASUS_WMI_DEVID_CORES, &cores);
>> + if (err) {
>> + pr_err("Could not get CPU core count: error %d\n", err);
>> + goto init_max_cpu_cores_err;
>> + }
>> +
>> + asus_armoury.cpu_cores->cur_perf_cores = FIELD_GET(ASUS_PERF_CORE_MASK, cores);
>> + asus_armoury.cpu_cores->cur_power_cores = FIELD_GET(ASUS_POWER_CORE_MASK, cores);
>> +
>> + asus_armoury.cpu_cores->min_perf_cores = CPU_PERF_CORE_COUNT_MIN;
>> + asus_armoury.cpu_cores->min_power_cores = CPU_POWR_CORE_COUNT_MIN;
> Should these be bounds checked with max?
>
>> + return 0;
>> +
>> +init_max_cpu_cores_err:
>> + kfree(asus_armoury.cpu_cores);
>> + return err;
>> +}
>> +
>> +static ssize_t cores_value_show(struct kobject *kobj, struct kobj_attribute *attr, char *buf,
>> + enum cpu_core_type core_type, enum cpu_core_value core_value)
>> +{
>> + u32 cores;
>> +
>> + switch (core_value) {
>> + case CPU_CORE_DEFAULT:
>> + case CPU_CORE_MAX:
>> + if (core_type == CPU_CORE_PERF)
>> + return sysfs_emit(buf, "%u\n",
>> + asus_armoury.cpu_cores->max_perf_cores);
>> + else
>> + return sysfs_emit(buf, "%u\n",
>> + asus_armoury.cpu_cores->max_power_cores);
>> + case CPU_CORE_MIN:
>> + if (core_type == CPU_CORE_PERF)
>> + return sysfs_emit(buf, "%u\n",
>> + asus_armoury.cpu_cores->min_perf_cores);
>> + else
>> + return sysfs_emit(buf, "%u\n",
>> + asus_armoury.cpu_cores->min_power_cores);
>> + default:
>> + break;
>> + }
>> +
>> + if (core_type == CPU_CORE_PERF)
>> + cores = asus_armoury.cpu_cores->cur_perf_cores;
>> + else
>> + cores = asus_armoury.cpu_cores->cur_power_cores;
> Why isn't this inside the switch?? The logic in this function looks very
> mixed up.
>
> If I'd be you, I'd consider converting the asus_armoury.cpu_cores to a
> multi-dimensional array. It would make this just bounds checks and one
> line to get the data.
>
>> + return sysfs_emit(buf, "%u\n", cores);
>> +}
>> +
>> +static ssize_t cores_current_value_store(struct kobject *kobj, struct kobj_attribute *attr,
>> + const char *buf, enum cpu_core_type core_type)
>> +{
>> + u32 new_cores, perf_cores, power_cores, out_val, min, max;
>> + int result, err;
>> +
>> + result = kstrtou32(buf, 10, &new_cores);
>> + if (result)
>> + return result;
>> +
>> + scoped_guard(mutex, &asus_armoury.cpu_core_mutex) {
>> + if (core_type == CPU_CORE_PERF) {
>> + perf_cores = new_cores;
>> + power_cores = asus_armoury.cpu_cores->cur_power_cores;
>> + min = asus_armoury.cpu_cores->min_perf_cores;
>> + max = asus_armoury.cpu_cores->max_perf_cores;
>> + } else {
>> + perf_cores = asus_armoury.cpu_cores->cur_perf_cores;
>> + power_cores = new_cores;
>> + min = asus_armoury.cpu_cores->min_power_cores;
>> + max = asus_armoury.cpu_cores->max_power_cores;
>> + }
>> +
>> + if (new_cores < min || new_cores > max)
>> + return -EINVAL;
>> +
>> + out_val = FIELD_PREP(ASUS_PERF_CORE_MASK, perf_cores) |
>> + FIELD_PREP(ASUS_POWER_CORE_MASK, power_cores);
>> +
>> + err = asus_wmi_set_devstate(ASUS_WMI_DEVID_CORES, out_val, &result);
>> + if (err) {
>> + pr_warn("Failed to set CPU core count: %d\n", err);
>> + return err;
>> + }
>> +
>> + if (result > 1) {
>> + pr_warn("Failed to set CPU core count (result): 0x%x\n", result);
>> + return -EIO;
>> + }
>> + }
>> +
>> + pr_info("CPU core count changed, reboot required\n");
> This interface has a problematic behavior. If user wants to adjust both
> core counts one after another (without reboot in between), the new value
> of the first core count will be overwritten on the second store.
>
> You might have to store also the value that will be used after the next
> boot to solve it but how the divergence should be presented to user is
> another question to which I don't have a good answer.
>
> This seems a more general problem, that is, how to represent values which
> are only enacted after booting (current vs to-be-current) as it doesn't
> fit to the current, min, max, possible_values, type model.
>
>
I will propose a possible solution in v15 very soon that will hopefully
satisfy both kernel requirements and safety requirements.
Thank you,
Denis
next prev parent reply other threads:[~2025-10-19 16:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-15 1:47 [PATCH v14 0/9] platform/x86: Add asus-armoury driver Denis Benato
2025-10-15 1:47 ` [PATCH v14 1/9] platform/x86: asus-wmi: export symbols used for read/write WMI Denis Benato
2025-10-15 13:03 ` Ilpo Järvinen
2025-10-15 1:47 ` [PATCH v14 2/9] platform/x86: asus-armoury: move existing tunings to asus-armoury module Denis Benato
2025-10-15 13:56 ` Ilpo Järvinen
2025-10-16 1:28 ` Denis Benato
2025-10-15 1:47 ` [PATCH v14 3/9] platform/x86: asus-armoury: add panel_hd_mode attribute Denis Benato
2025-10-15 1:47 ` [PATCH v14 4/9] platform/x86: asus-armoury: add apu-mem control support Denis Benato
2025-10-17 12:16 ` Ilpo Järvinen
2025-10-18 1:23 ` Denis Benato
2025-10-15 1:47 ` [PATCH v14 5/9] platform/x86: asus-armoury: add core count control Denis Benato
2025-10-15 14:11 ` Ilpo Järvinen
2025-10-17 12:48 ` Ilpo Järvinen
2025-10-18 1:43 ` Denis Benato
2025-10-20 17:15 ` Ilpo Järvinen
2025-10-20 17:37 ` Denis Benato
2025-10-20 18:45 ` Mario Limonciello (AMD) (kernel.org)
2025-10-19 16:53 ` Denis Benato [this message]
2025-10-15 1:47 ` [PATCH v14 6/9] platform/x86: asus-armoury: add screen auto-brightness toggle Denis Benato
2025-10-15 1:47 ` [PATCH v14 7/9] platform/x86: asus-wmi: deprecate bios features Denis Benato
2025-10-17 12:54 ` Ilpo Järvinen
2025-10-15 1:47 ` [PATCH v14 8/9] platform/x86: asus-wmi: rename ASUS_WMI_DEVID_PPT_FPPT Denis Benato
2025-10-17 12:59 ` Ilpo Järvinen
2025-10-15 1:47 ` [PATCH v14 9/9] platform/x86: asus-armoury: add ppt_* and nv_* tuning knobs Denis Benato
2025-10-17 13:09 ` Ilpo Järvinen
2025-10-15 5:13 ` [PATCH v14 0/9] platform/x86: Add asus-armoury driver Mario Limonciello
2025-10-15 9:38 ` Ilpo Järvinen
2025-10-15 12:00 ` Denis Benato
2025-10-15 12:06 ` Ilpo Järvinen
2025-10-15 12:27 ` Denis Benato
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=78f9c831-0c0c-4497-9a77-0380e27cc616@gmail.com \
--to=benato.denis96@gmail.com \
--cc=alok.a.tiwari@oracle.com \
--cc=derekjohn.clark@gmail.com \
--cc=dragonn@op.pl \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luke@ljones.dev \
--cc=mpearson-lenovo@squebb.ca \
--cc=platform-driver-x86@vger.kernel.org \
--cc=porfet828@gmail.com \
--cc=superm1@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox