[PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control firmware attributes

[PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control firmware attributes

[Denis Benato]

Hi all,

I was recently reading through the asusctl issue tracker and I found
out that some users have been having troubles with the keyboard RGB control
that was working before since the creation of asus-armoury and subequent
deprecation of old sysfs attributes.

This patch series aims to re-introduce those attributes in asus-armoury
so that userspace tools can still control keyboard RGB lighting
without having to rely on deprecated asus-wmi attributes.

In addition to that, since disabling OOBE is essential for controlling
LEDs on some models and it was incorrectly tied to deprecated attributes,
this patch series also fixes sending OOBE at probe time.

Link: https://gitlab.com/asus-linux/asusctl/-/issues/619

Regards,
Denis

Changelog:
- v1
  - Initial submission
- v2
  - asus-armoury: drivers should be silent on success
  - asus-armoury: make better use of __free annotation
- v3
  - asus-wmi: use GENMASK for flags
  - asus-armoury: fix error handling in keyboard attribute creation
  - asus-armoury: fix logic bug in error path
  - asus-armoury: use proper defines for keyboard state flags
- v4
  - asus-armoury: reorder variable declarations
  - asus-armoury: add bitfields.h include for BIT and FIELD_PREP
  - asus-armoury: reorganize armoury_kbd_state() for clarity

Denis Benato (3):
  platform/x86: asus-wmi: explicitly mark more code with
    CONFIG_ASUS_WMI_DEPRECATED_ATTRS
  platform/x86: asus-wmi: fix sending OOBE at probe
  platform/x86: asus-armoury: add keyboard control firmware attributes

 drivers/platform/x86/asus-armoury.c        | 253 +++++++++++++++++++++
 drivers/platform/x86/asus-wmi.c            |  13 +-
 include/linux/platform_data/x86/asus-wmi.h |  18 ++
 3 files changed, 283 insertions(+), 1 deletion(-)

-- 
2.52.0

[PATCH v4 1/3] platform/x86: asus-wmi: explicitly mark more code with CONFIG_ASUS_WMI_DEPRECATED_ATTRS

[Denis Benato]

Be more explicit in code that will be excluded when compiling
with CONFIG_ASUS_WMI_DEPRECATED_ATTRS disabled.

Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
 drivers/platform/x86/asus-wmi.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 4aec7ec69250..a49447eff4f4 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -302,7 +302,11 @@ struct asus_wmi {
 	u32 nv_temp_target;
 
 	u32 kbd_rgb_dev;
+
+#if IS_ENABLED(CONFIG_ASUS_WMI_DEPRECATED_ATTRS)
 	bool kbd_rgb_state_available;
+#endif /* IS_ENABLED(CONFIG_ASUS_WMI_DEPRECATED_ATTRS) */
+
 	bool oobe_state_available;
 
 	u8 throttle_thermal_policy_mode;
@@ -1060,6 +1064,7 @@ static const struct attribute_group kbd_rgb_mode_group = {
 };
 
 /* TUF Laptop Keyboard RGB State **********************************************/
+#if IS_ENABLED(CONFIG_ASUS_WMI_DEPRECATED_ATTRS)
 static ssize_t kbd_rgb_state_store(struct device *dev,
 				 struct device_attribute *attr,
 				 const char *buf, size_t count)
@@ -1106,6 +1111,8 @@ static const struct attribute_group kbd_rgb_state_group = {
 	.attrs = kbd_rgb_state_attrs,
 };
 
+#endif /* IS_ENABLED(CONFIG_ASUS_WMI_DEPRECATED_ATTRS) */
+
 static const struct attribute_group *kbd_rgb_mode_groups[] = {
 	NULL,
 	NULL,
@@ -1861,8 +1868,11 @@ static int asus_wmi_led_init(struct asus_wmi *asus)
 
 	if (asus->kbd_rgb_dev)
 		kbd_rgb_mode_groups[num_rgb_groups++] = &kbd_rgb_mode_group;
+
+#if IS_ENABLED(CONFIG_ASUS_WMI_DEPRECATED_ATTRS)
 	if (asus->kbd_rgb_state_available)
 		kbd_rgb_mode_groups[num_rgb_groups++] = &kbd_rgb_state_group;
+#endif /* IS_ENABLED(CONFIG_ASUS_WMI_DEPRECATED_ATTRS) */
 
 	asus->led_workqueue = create_singlethread_workqueue("led_workqueue");
 	if (!asus->led_workqueue)
-- 
2.52.0

[PATCH v4 2/3] platform/x86: asus-wmi: fix sending OOBE at probe

[Denis Benato]

Disabling OOBE is an important step to be able to fully control the
hardware in TUF laptops that requires this command, but the command
has been incorrectly tied to deprecated attributes: restore sending
the OOBE exit command.

Fixes: c683651b6791 ("platform/x86: asus-wmi: deprecate bios features")
Signed-off-by: Denis Benato <denis.benato@linux.dev>
---
 drivers/platform/x86/asus-wmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index a49447eff4f4..8dfdde7877a8 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -4899,7 +4899,6 @@ static int asus_wmi_add(struct platform_device *pdev)
 	asus->egpu_enable_available = asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_EGPU);
 	asus->dgpu_disable_available = asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_DGPU);
 	asus->kbd_rgb_state_available = asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_TUF_RGB_STATE);
-	asus->oobe_state_available = asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_OOBE);
 
 	if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_MINI_LED_MODE))
 		asus->mini_led_dev_id = ASUS_WMI_DEVID_MINI_LED_MODE;
@@ -4912,6 +4911,8 @@ static int asus_wmi_add(struct platform_device *pdev)
 		asus->gpu_mux_dev = ASUS_WMI_DEVID_GPU_MUX_VIVO;
 #endif /* IS_ENABLED(CONFIG_ASUS_WMI_DEPRECATED_ATTRS) */
 
+	asus->oobe_state_available = asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_OOBE);
+
 	if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_THROTTLE_THERMAL_POLICY))
 		asus->throttle_thermal_policy_dev = ASUS_WMI_DEVID_THROTTLE_THERMAL_POLICY;
 	else if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_THROTTLE_THERMAL_POLICY_VIVO))
-- 
2.52.0

[PATCH v4 3/3] platform/x86: asus-armoury: add keyboard control firmware attributes

[Denis Benato]

Implement keyboard status firmware attributes in asus-armoury after
deprecating those attribute(s) in asus-wmi to avoid losing the ability
to control LEDs status.

Signed-off-by: Denis Benato <denis.benato@linux.dev>
Tested-by: Merthan Karakaş <m3rthn.k@gmail.com>
---
 drivers/platform/x86/asus-armoury.c        | 253 +++++++++++++++++++++
 include/linux/platform_data/x86/asus-wmi.h |  18 ++
 2 files changed, 271 insertions(+)

diff --git a/drivers/platform/x86/asus-armoury.c b/drivers/platform/x86/asus-armoury.c
index 9c1a9ad42bc4..be803faa1ece 100644
--- a/drivers/platform/x86/asus-armoury.c
+++ b/drivers/platform/x86/asus-armoury.c
@@ -76,10 +76,22 @@ struct rog_tunables {
 	u32 nv_tgp;
 };
 
+struct asus_armoury_kbd_status {
+	bool boot;
+	bool awake;
+	bool sleep;
+	bool shutdown;
+};
+
 struct asus_armoury_priv {
 	struct device *fw_attr_dev;
 	struct kset *fw_attr_kset;
 
+	struct mutex keyboard_mutex;
+
+	/* Current TUF keyboard RGB state tracking */
+	struct asus_armoury_kbd_status *kbd_state;
+
 	/*
 	 * Mutex to protect eGPU activation/deactivation
 	 * sequences and dGPU connection status:
@@ -97,6 +109,7 @@ struct asus_armoury_priv {
 
 static struct asus_armoury_priv asus_armoury = {
 	.egpu_mutex = __MUTEX_INITIALIZER(asus_armoury.egpu_mutex),
+	.keyboard_mutex = __MUTEX_INITIALIZER(asus_armoury.keyboard_mutex),
 };
 
 struct fw_attrs_group {
@@ -433,6 +446,164 @@ static ssize_t mini_led_mode_possible_values_show(struct kobject *kobj,
 }
 ASUS_ATTR_GROUP_ENUM(mini_led_mode, "mini_led_mode", "Set the mini-LED backlight mode");
 
+/* Keyboard power management **************************************************/
+
+static int armoury_kbd_state(struct kobj_attribute *attr,
+			     const struct asus_armoury_kbd_status *status)
+{
+	u32 kbd_state = ASUS_WMI_DEVID_TUF_RGB_STATE_EN | ASUS_WMI_DEVID_TUF_RGB_STATE_CMD;
+
+	kbd_state |= FIELD_PREP(ASUS_WMI_DEVID_TUF_RGB_STATE_BOOT, status->boot ? 1 : 0);
+	kbd_state |= FIELD_PREP(ASUS_WMI_DEVID_TUF_RGB_STATE_AWAKE, status->awake ? 1 : 0);
+	kbd_state |= FIELD_PREP(ASUS_WMI_DEVID_TUF_RGB_STATE_SLEEP, status->sleep ? 1 : 0);
+	kbd_state |= FIELD_PREP(ASUS_WMI_DEVID_TUF_RGB_STATE_SHUTDOWN, status->shutdown ? 1 : 0);
+
+	return armoury_set_devstate(attr, kbd_state, NULL, ASUS_WMI_DEVID_TUF_RGB_STATE);
+}
+
+enum asus_armoury_kbd_state_field {
+	ASUS_ARMOURY_KBD_STATE_BOOT,
+	ASUS_ARMOURY_KBD_STATE_AWAKE,
+	ASUS_ARMOURY_KBD_STATE_SLEEP,
+	ASUS_ARMOURY_KBD_STATE_SHUTDOWN,
+};
+
+static ssize_t armoury_kbd_state_write(struct kobject *kobj, struct kobj_attribute *attr,
+				       const char *buf, size_t count,
+				       enum asus_armoury_kbd_state_field field)
+{
+	struct asus_armoury_kbd_status kbd_status;
+	bool enable;
+	ssize_t err;
+
+	err = kstrtobool(buf, &enable);
+	if (err)
+		return err;
+
+	scoped_guard(mutex, &asus_armoury.keyboard_mutex) {
+		memcpy(&kbd_status, asus_armoury.kbd_state, sizeof(kbd_status));
+
+		switch (field) {
+		case ASUS_ARMOURY_KBD_STATE_BOOT:
+			kbd_status.boot = enable;
+			break;
+		case ASUS_ARMOURY_KBD_STATE_AWAKE:
+			kbd_status.awake = enable;
+			break;
+		case ASUS_ARMOURY_KBD_STATE_SLEEP:
+			kbd_status.sleep = enable;
+			break;
+		case ASUS_ARMOURY_KBD_STATE_SHUTDOWN:
+			kbd_status.shutdown = enable;
+			break;
+		default:
+			return -EINVAL;
+		}
+
+		err = armoury_kbd_state(attr, &kbd_status);
+		if (err)
+			return err;
+
+		memcpy(asus_armoury.kbd_state, &kbd_status, sizeof(kbd_status));
+	}
+
+	sysfs_notify(kobj, NULL, attr->attr.name);
+
+	return count;
+}
+
+static ssize_t armoury_kbd_state_read(struct kobject *kobj, struct kobj_attribute *attr,
+				      char *buf, enum asus_armoury_kbd_state_field field)
+{
+	bool *field_ptr, field_enabled;
+
+	switch (field) {
+	case ASUS_ARMOURY_KBD_STATE_AWAKE:
+		field_ptr = &asus_armoury.kbd_state->awake;
+		break;
+	case ASUS_ARMOURY_KBD_STATE_SLEEP:
+		field_ptr = &asus_armoury.kbd_state->sleep;
+		break;
+	case ASUS_ARMOURY_KBD_STATE_BOOT:
+		field_ptr = &asus_armoury.kbd_state->boot;
+		break;
+	case ASUS_ARMOURY_KBD_STATE_SHUTDOWN:
+		field_ptr = &asus_armoury.kbd_state->shutdown;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	scoped_guard(mutex, &asus_armoury.keyboard_mutex)
+		field_enabled = *field_ptr;
+
+	return sysfs_emit(buf, field_enabled ? "1\n" : "0\n");
+}
+
+static ssize_t kbd_leds_sleep_current_value_store(struct kobject *kobj,
+						  struct kobj_attribute *attr,
+						  const char *buf, size_t count)
+{
+	return armoury_kbd_state_write(kobj, attr, buf, count, ASUS_ARMOURY_KBD_STATE_SLEEP);
+}
+
+static ssize_t kbd_leds_sleep_current_value_show(struct kobject *kobj,
+						 struct kobj_attribute *attr, char *buf)
+{
+	return armoury_kbd_state_read(kobj, attr, buf, ASUS_ARMOURY_KBD_STATE_SLEEP);
+}
+
+ASUS_ATTR_GROUP_BOOL(kbd_leds_sleep, "kbd_leds_sleep",
+		     "Keyboard backlight while system is sleeping");
+
+static ssize_t kbd_leds_boot_current_value_store(struct kobject *kobj,
+						 struct kobj_attribute *attr,
+						 const char *buf, size_t count)
+{
+	return armoury_kbd_state_write(kobj, attr, buf, count, ASUS_ARMOURY_KBD_STATE_BOOT);
+}
+
+static ssize_t kbd_leds_boot_current_value_show(struct kobject *kobj,
+						struct kobj_attribute *attr, char *buf)
+{
+	return armoury_kbd_state_read(kobj, attr, buf, ASUS_ARMOURY_KBD_STATE_BOOT);
+}
+
+ASUS_ATTR_GROUP_BOOL(kbd_leds_boot, "kbd_leds_boot",
+		     "Keyboard backlight while system is booting");
+
+static ssize_t kbd_leds_awake_current_value_store(struct kobject *kobj,
+						  struct kobj_attribute *attr,
+						  const char *buf, size_t count)
+{
+	return armoury_kbd_state_write(kobj, attr, buf, count, ASUS_ARMOURY_KBD_STATE_AWAKE);
+}
+
+static ssize_t kbd_leds_awake_current_value_show(struct kobject *kobj,
+						 struct kobj_attribute *attr, char *buf)
+{
+	return armoury_kbd_state_read(kobj, attr, buf, ASUS_ARMOURY_KBD_STATE_AWAKE);
+}
+
+ASUS_ATTR_GROUP_BOOL(kbd_leds_awake, "kbd_leds_awake",
+		     "Keyboard backlight while system is awake");
+
+static ssize_t kbd_leds_shutdown_current_value_store(struct kobject *kobj,
+						     struct kobj_attribute *attr,
+						     const char *buf, size_t count)
+{
+	return armoury_kbd_state_write(kobj, attr, buf, count, ASUS_ARMOURY_KBD_STATE_SHUTDOWN);
+}
+
+static ssize_t kbd_leds_shutdown_current_value_show(struct kobject *kobj,
+						    struct kobj_attribute *attr, char *buf)
+{
+	return armoury_kbd_state_read(kobj, attr, buf, ASUS_ARMOURY_KBD_STATE_SHUTDOWN);
+}
+
+ASUS_ATTR_GROUP_BOOL(kbd_leds_shutdown, "kbd_leds_shutdown",
+		     "Keyboard backlight while system is shutdown");
+
 static ssize_t gpu_mux_mode_current_value_store(struct kobject *kobj,
 						struct kobj_attribute *attr,
 						const char *buf, size_t count)
@@ -867,6 +1038,32 @@ static bool has_valid_limit(const char *name, const struct power_limits *limits)
 	return limit_value > 0;
 }
 
+static struct asus_armoury_kbd_status *asus_init_kbd_state(void)
+{
+	u32 kbd_status;
+	int err;
+
+	err = armoury_get_devstate(NULL, &kbd_status, ASUS_WMI_DEVID_TUF_RGB_STATE);
+	if (err) {
+		pr_debug("ACPI does not support keyboard power control: %d\n", err);
+		return ERR_PTR(-ENODEV);
+	}
+
+	struct asus_armoury_kbd_status *kbd_state __free(kfree) =
+		kzalloc(sizeof(*kbd_state), GFP_KERNEL);
+	if (!kbd_state)
+		return ERR_PTR(-ENODEV);
+
+	/*
+	 * By default leds are off for all states (to spare power)
+	 * except for when laptop is awake, where leds color and
+	 * brightness are controllable by userspace.
+	 */
+	kbd_state->awake = true;
+
+	return_ptr(kbd_state);
+}
+
 static int asus_fw_attr_add(void)
 {
 	const struct rog_tunables *const ac_rog_tunables =
@@ -955,8 +1152,64 @@ static int asus_fw_attr_add(void)
 		}
 	}
 
+	asus_armoury.kbd_state = NULL;
+	if (armoury_has_devstate(ASUS_WMI_DEVID_TUF_RGB_STATE)) {
+		asus_armoury.kbd_state = asus_init_kbd_state();
+		if (IS_ERR(asus_armoury.kbd_state)) {
+			asus_armoury.kbd_state = NULL;
+			err = PTR_ERR(asus_armoury.kbd_state);
+			pr_err("Failed to get keyboard status: %d\n", err);
+			goto err_remove_groups;
+		}
+
+		err = sysfs_create_group(&asus_armoury.fw_attr_kset->kobj, &kbd_leds_sleep_attr_group);
+		if (err) {
+			pr_err("Failed to create sysfs-group for keyboard backlight sleep state: %d\n", err);
+			goto err_kbd_state;
+		}
+
+		err = sysfs_create_group(&asus_armoury.fw_attr_kset->kobj, &kbd_leds_boot_attr_group);
+		if (err) {
+			pr_err("Failed to create sysfs-group for keyboard backlight boot state: %d\n", err);
+			goto err_remove_kbd_sleep_attr;
+		}
+
+		err = sysfs_create_group(&asus_armoury.fw_attr_kset->kobj, &kbd_leds_awake_attr_group);
+		if (err) {
+			pr_err("Failed to create sysfs-group for keyboard backlight awake state: %d\n", err);
+			goto err_remove_kbd_boot_attr;
+		}
+
+		err = sysfs_create_group(&asus_armoury.fw_attr_kset->kobj, &kbd_leds_shutdown_attr_group);
+		if (err) {
+			pr_err("Failed to create sysfs-group for keyboard backlight shutdown state: %d\n", err);
+			goto err_remove_kbd_awake_attr;
+		}
+
+		/*
+		 * The attribute is write-only and for the state to be coherent
+		 * a default state has to written: userspace is expected to
+		 * modify it based on user preference.
+		 */
+		err = armoury_kbd_state(&attr_kbd_leds_awake_current_value, asus_armoury.kbd_state);
+		if (err) {
+			pr_err("Failed to initialize keyboard backlight states: %d\n", err);
+			goto err_remove_kbd_shutdown_attr;
+		}
+	}
+
 	return 0;
 
+err_remove_kbd_shutdown_attr:
+	sysfs_remove_group(&asus_armoury.fw_attr_kset->kobj, &kbd_leds_shutdown_attr_group);
+err_remove_kbd_awake_attr:
+	sysfs_remove_group(&asus_armoury.fw_attr_kset->kobj, &kbd_leds_awake_attr_group);
+err_remove_kbd_boot_attr:
+	sysfs_remove_group(&asus_armoury.fw_attr_kset->kobj, &kbd_leds_boot_attr_group);
+err_remove_kbd_sleep_attr:
+	sysfs_remove_group(&asus_armoury.fw_attr_kset->kobj, &kbd_leds_sleep_attr_group);
+err_kbd_state:
+	kfree(asus_armoury.kbd_state);
 err_remove_groups:
 	while (i--) {
 		if (armoury_has_devstate(armoury_attr_groups[i].wmi_devid))
diff --git a/include/linux/platform_data/x86/asus-wmi.h b/include/linux/platform_data/x86/asus-wmi.h
index 419491d4abca..275933e0d79e 100644
--- a/include/linux/platform_data/x86/asus-wmi.h
+++ b/include/linux/platform_data/x86/asus-wmi.h
@@ -2,6 +2,7 @@
 #ifndef __PLATFORM_DATA_X86_ASUS_WMI_H
 #define __PLATFORM_DATA_X86_ASUS_WMI_H
 
+#include <linux/bitfield.h>
 #include <linux/errno.h>
 #include <linux/types.h>
 
@@ -153,6 +154,23 @@
 /* TUF laptop RGB power/state */
 #define ASUS_WMI_DEVID_TUF_RGB_STATE	0x00100057
 
+#define ASUS_WMI_DEVID_TUF_RGB_STATE_EN 0xBD
+
+#define ASUS_WMI_DEVID_TUF_RGB_STATE_CMD BIT(10)
+
+/*
+ * Flags for TUF RGB state to be used with ASUS_WMI_DEVID_TUF_RGB_STATE:
+ * flags | ASUS_WMI_DEVID_TUF_RGB_STATE_CMD | ASUS_WMI_DEVID_TUF_RGB_STATE_EN
+ *
+ * where ASUS_WMI_DEVID_TUF_RGB_STATE_EN is required for the method call
+ * to not be discarded, ASUS_WMI_DEVID_TUF_RGB_STATE_EN specifies this is
+ * a command and flags is a combination of one or more of the following flags.
+ */
+#define ASUS_WMI_DEVID_TUF_RGB_STATE_BOOT		GENMASK(17, 17)
+#define ASUS_WMI_DEVID_TUF_RGB_STATE_AWAKE		GENMASK(19, 19)
+#define ASUS_WMI_DEVID_TUF_RGB_STATE_SLEEP		GENMASK(21, 21)
+#define ASUS_WMI_DEVID_TUF_RGB_STATE_SHUTDOWN	GENMASK(23, 23)
+
 /* Bootup sound control */
 #define ASUS_WMI_DEVID_BOOT_SOUND	0x00130022
 
-- 
2.52.0

Re: [PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control firmware attributes

[Denis Benato]

On 1/3/26 00:43, Denis Benato wrote:
> Hi all,
>
> I was recently reading through the asusctl issue tracker and I found
> out that some users have been having troubles with the keyboard RGB control
> that was working before since the creation of asus-armoury and subequent
> deprecation of old sysfs attributes.
>
> This patch series aims to re-introduce those attributes in asus-armoury
> so that userspace tools can still control keyboard RGB lighting
> without having to rely on deprecated asus-wmi attributes.
>
> In addition to that, since disabling OOBE is essential for controlling
> LEDs on some models and it was incorrectly tied to deprecated attributes,
> this patch series also fixes sending OOBE at probe time.
>
> Link: https://gitlab.com/asus-linux/asusctl/-/issues/619
>
> Regards,
> Denis
Hi Ilpo,

I see no comments on this revision, did I sent it at wrong time?
Should I resend some other time?

Sorry for the question but I don't know if something went wrong,
and if so what exactly.

Thanks,
Denis
> Changelog:
> - v1
>   - Initial submission
> - v2
>   - asus-armoury: drivers should be silent on success
>   - asus-armoury: make better use of __free annotation
> - v3
>   - asus-wmi: use GENMASK for flags
>   - asus-armoury: fix error handling in keyboard attribute creation
>   - asus-armoury: fix logic bug in error path
>   - asus-armoury: use proper defines for keyboard state flags
> - v4
>   - asus-armoury: reorder variable declarations
>   - asus-armoury: add bitfields.h include for BIT and FIELD_PREP
>   - asus-armoury: reorganize armoury_kbd_state() for clarity
>
> Denis Benato (3):
>   platform/x86: asus-wmi: explicitly mark more code with
>     CONFIG_ASUS_WMI_DEPRECATED_ATTRS
>   platform/x86: asus-wmi: fix sending OOBE at probe
>   platform/x86: asus-armoury: add keyboard control firmware attributes
>
>  drivers/platform/x86/asus-armoury.c        | 253 +++++++++++++++++++++
>  drivers/platform/x86/asus-wmi.c            |  13 +-
>  include/linux/platform_data/x86/asus-wmi.h |  18 ++
>  3 files changed, 283 insertions(+), 1 deletion(-)
>

Re: [PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control firmware attributes

[Ilpo Järvinen]

On Mon, 12 Jan 2026, Denis Benato wrote:
> On 1/3/26 00:43, Denis Benato wrote:
> >
> > I was recently reading through the asusctl issue tracker and I found
> > out that some users have been having troubles with the keyboard RGB control
> > that was working before since the creation of asus-armoury and subequent
> > deprecation of old sysfs attributes.
> >
> > This patch series aims to re-introduce those attributes in asus-armoury
> > so that userspace tools can still control keyboard RGB lighting
> > without having to rely on deprecated asus-wmi attributes.
> >
> > In addition to that, since disabling OOBE is essential for controlling
> > LEDs on some models and it was incorrectly tied to deprecated attributes,
> > this patch series also fixes sending OOBE at probe time.
> >
> > Link: https://gitlab.com/asus-linux/asusctl/-/issues/619
> >
> > Regards,
> > Denis
> Hi Ilpo,
> 
> I see no comments on this revision, did I sent it at wrong time?
> Should I resend some other time?
> 
> Sorry for the question but I don't know if something went wrong,
> and if so what exactly.

Hi,

Nothing is wrong, I've just had to spend time on finally processing 
some larger next series which were even older than yours. And we're only 1 
week past a holiday period which tend to add to delay.

Patchwork keeps track of pdx86 patches:

https://patchwork.kernel.org/project/platform-driver-x86/list/

If your patch is listed there, there's no need to ping as I'll get it it 
eventually (and it won't get forgotten).

There's no "wrong time" to send a patch to pdx86, only that when the 
merge window is open, I might do processing of any patches during that 
time. But unlike some other subsystems, we don't disallow sending patches 
during merge window or any other time.

-- 
 i.

> > Changelog:
> > - v1
> >   - Initial submission
> > - v2
> >   - asus-armoury: drivers should be silent on success
> >   - asus-armoury: make better use of __free annotation
> > - v3
> >   - asus-wmi: use GENMASK for flags
> >   - asus-armoury: fix error handling in keyboard attribute creation
> >   - asus-armoury: fix logic bug in error path
> >   - asus-armoury: use proper defines for keyboard state flags
> > - v4
> >   - asus-armoury: reorder variable declarations
> >   - asus-armoury: add bitfields.h include for BIT and FIELD_PREP
> >   - asus-armoury: reorganize armoury_kbd_state() for clarity
> >
> > Denis Benato (3):
> >   platform/x86: asus-wmi: explicitly mark more code with
> >     CONFIG_ASUS_WMI_DEPRECATED_ATTRS
> >   platform/x86: asus-wmi: fix sending OOBE at probe
> >   platform/x86: asus-armoury: add keyboard control firmware attributes
> >
> >  drivers/platform/x86/asus-armoury.c        | 253 +++++++++++++++++++++
> >  drivers/platform/x86/asus-wmi.c            |  13 +-
> >  include/linux/platform_data/x86/asus-wmi.h |  18 ++
> >  3 files changed, 283 insertions(+), 1 deletion(-)

Re: [PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control firmware attributes

[Denis Benato]

On 1/13/26 15:02, Ilpo Järvinen wrote:
> On Mon, 12 Jan 2026, Denis Benato wrote:
>> On 1/3/26 00:43, Denis Benato wrote:
>>> I was recently reading through the asusctl issue tracker and I found
>>> out that some users have been having troubles with the keyboard RGB control
>>> that was working before since the creation of asus-armoury and subequent
>>> deprecation of old sysfs attributes.
>>>
>>> This patch series aims to re-introduce those attributes in asus-armoury
>>> so that userspace tools can still control keyboard RGB lighting
>>> without having to rely on deprecated asus-wmi attributes.
>>>
>>> In addition to that, since disabling OOBE is essential for controlling
>>> LEDs on some models and it was incorrectly tied to deprecated attributes,
>>> this patch series also fixes sending OOBE at probe time.
>>>
>>> Link: https://gitlab.com/asus-linux/asusctl/-/issues/619
>>>
>>> Regards,
>>> Denis
>> Hi Ilpo,
>>
>> I see no comments on this revision, did I sent it at wrong time?
>> Should I resend some other time?
>>
>> Sorry for the question but I don't know if something went wrong,
>> and if so what exactly.
> Hi,
>
> Nothing is wrong, I've just had to spend time on finally processing 
> some larger next series which were even older than yours. And we're only 1 
> week past a holiday period which tend to add to delay.
Oh okay, thank you for letting me know! I feared I repeated the error
I made on the netdev list :)
> Patchwork keeps track of pdx86 patches:
>
> https://patchwork.kernel.org/project/platform-driver-x86/list/
>
> If your patch is listed there, there's no need to ping as I'll get it it 
> eventually (and it won't get forgotten).
Understood! Sorry for the inconvenient :D
> There's no "wrong time" to send a patch to pdx86, only that when the 
> merge window is open, I might do processing of any patches during that 
> time. But unlike some other subsystems, we don't disallow sending patches 
> during merge window or any other time.
>
That's very good to know. Thank you very much, always very informative!

Re: [PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control firmware attributes

[Ilpo Järvinen]

[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]

On Tue, 13 Jan 2026, Denis Benato wrote:

> 
> On 1/13/26 15:02, Ilpo Järvinen wrote:
> > On Mon, 12 Jan 2026, Denis Benato wrote:
> >> On 1/3/26 00:43, Denis Benato wrote:
> >>> I was recently reading through the asusctl issue tracker and I found
> >>> out that some users have been having troubles with the keyboard RGB control
> >>> that was working before since the creation of asus-armoury and subequent
> >>> deprecation of old sysfs attributes.
> >>>
> >>> This patch series aims to re-introduce those attributes in asus-armoury
> >>> so that userspace tools can still control keyboard RGB lighting
> >>> without having to rely on deprecated asus-wmi attributes.
> >>>
> >>> In addition to that, since disabling OOBE is essential for controlling
> >>> LEDs on some models and it was incorrectly tied to deprecated attributes,
> >>> this patch series also fixes sending OOBE at probe time.
> >>>
> >>> Link: https://gitlab.com/asus-linux/asusctl/-/issues/619
> >>>
> >>> Regards,
> >>> Denis
> >> Hi Ilpo,
> >>
> >> I see no comments on this revision, did I sent it at wrong time?
> >> Should I resend some other time?
> >>
> >> Sorry for the question but I don't know if something went wrong,
> >> and if so what exactly.
> > Hi,
> >
> > Nothing is wrong, I've just had to spend time on finally processing 
> > some larger next series which were even older than yours. And we're only 1 
> > week past a holiday period which tend to add to delay.
> Oh okay, thank you for letting me know! I feared I repeated the error
> I made on the netdev list :)
> > Patchwork keeps track of pdx86 patches:
> >
> > https://patchwork.kernel.org/project/platform-driver-x86/list/
> >
> > If your patch is listed there, there's no need to ping as I'll get it it 
> > eventually (and it won't get forgotten).
> Understood! Sorry for the inconvenient :D
> > There's no "wrong time" to send a patch to pdx86, only that when the 
> > merge window is open, I might do processing of any patches during that 

In case it wasn't obvious, I meant: I might not do processing of any 
patches during the merge window.

> > time. But unlike some other subsystems, we don't disallow sending patches 
> > during merge window or any other time.
> >
> That's very good to know. Thank you very much, always very informative!
> 

-- 
 i.

Re: [PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control firmware attributes

[Denis Benato]

On 1/14/26 10:04, Ilpo Järvinen wrote:
> On Tue, 13 Jan 2026, Denis Benato wrote:
>
>> On 1/13/26 15:02, Ilpo Järvinen wrote:
>>> On Mon, 12 Jan 2026, Denis Benato wrote:
>>>> On 1/3/26 00:43, Denis Benato wrote:
>>>>> I was recently reading through the asusctl issue tracker and I found
>>>>> out that some users have been having troubles with the keyboard RGB control
>>>>> that was working before since the creation of asus-armoury and subequent
>>>>> deprecation of old sysfs attributes.
>>>>>
>>>>> This patch series aims to re-introduce those attributes in asus-armoury
>>>>> so that userspace tools can still control keyboard RGB lighting
>>>>> without having to rely on deprecated asus-wmi attributes.
>>>>>
>>>>> In addition to that, since disabling OOBE is essential for controlling
>>>>> LEDs on some models and it was incorrectly tied to deprecated attributes,
>>>>> this patch series also fixes sending OOBE at probe time.
>>>>>
>>>>> Link: https://gitlab.com/asus-linux/asusctl/-/issues/619
>>>>>
>>>>> Regards,
>>>>> Denis
>>>> Hi Ilpo,
>>>>
>>>> I see no comments on this revision, did I sent it at wrong time?
>>>> Should I resend some other time?
>>>>
>>>> Sorry for the question but I don't know if something went wrong,
>>>> and if so what exactly.
>>> Hi,
>>>
>>> Nothing is wrong, I've just had to spend time on finally processing 
>>> some larger next series which were even older than yours. And we're only 1 
>>> week past a holiday period which tend to add to delay.
>> Oh okay, thank you for letting me know! I feared I repeated the error
>> I made on the netdev list :)
>>> Patchwork keeps track of pdx86 patches:
>>>
>>> https://patchwork.kernel.org/project/platform-driver-x86/list/
>>>
>>> If your patch is listed there, there's no need to ping as I'll get it it 
>>> eventually (and it won't get forgotten).
>> Understood! Sorry for the inconvenient :D
>>> There's no "wrong time" to send a patch to pdx86, only that when the 
>>> merge window is open, I might do processing of any patches during that 
> In case it wasn't obvious, I meant: I might not do processing of any 
> patches during the merge window.
Sure! Don't worry I was just attempting to avoid ending in a place where
everyone forgot these patches as this feature in particular has been
forgotten already once XD
>>> time. But unlike some other subsystems, we don't disallow sending patches 
>>> during merge window or any other time.
>>>
>> That's very good to know. Thank you very much, always very informative!
>>

Re: [PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control firmware attributes

[Denis Benato]

On 1/3/26 00:43, Denis Benato wrote:
> Hi all,
>
> I was recently reading through the asusctl issue tracker and I found
> out that some users have been having troubles with the keyboard RGB control
> that was working before since the creation of asus-armoury and subequent
> deprecation of old sysfs attributes.
>
> This patch series aims to re-introduce those attributes in asus-armoury
> so that userspace tools can still control keyboard RGB lighting
> without having to rely on deprecated asus-wmi attributes.
>
> In addition to that, since disabling OOBE is essential for controlling
> LEDs on some models and it was incorrectly tied to deprecated attributes,
> this patch series also fixes sending OOBE at probe time.
>
> Link: https://gitlab.com/asus-linux/asusctl/-/issues/619
Hi Ilpo, please disregard everything in this patch series except the OOBE fix:
that fix is important and I see it has been picked up.

It's probably much better not to touch keyboard modes without a rework
of the associated RGB interface: it doesn't make sense to move only the
power state and I already saw there have been reported problems
with TUFs.

The original problem I was trying to solve is better solved another way
via userspace saving the last setting with the interface already provided.

Thanks,
Denis
> Regards,
> Denis
>
> Changelog:
> - v1
>   - Initial submission
> - v2
>   - asus-armoury: drivers should be silent on success
>   - asus-armoury: make better use of __free annotation
> - v3
>   - asus-wmi: use GENMASK for flags
>   - asus-armoury: fix error handling in keyboard attribute creation
>   - asus-armoury: fix logic bug in error path
>   - asus-armoury: use proper defines for keyboard state flags
> - v4
>   - asus-armoury: reorder variable declarations
>   - asus-armoury: add bitfields.h include for BIT and FIELD_PREP
>   - asus-armoury: reorganize armoury_kbd_state() for clarity
>
> Denis Benato (3):
>   platform/x86: asus-wmi: explicitly mark more code with
>     CONFIG_ASUS_WMI_DEPRECATED_ATTRS
>   platform/x86: asus-wmi: fix sending OOBE at probe
>   platform/x86: asus-armoury: add keyboard control firmware attributes
>
>  drivers/platform/x86/asus-armoury.c        | 253 +++++++++++++++++++++
>  drivers/platform/x86/asus-wmi.c            |  13 +-
>  include/linux/platform_data/x86/asus-wmi.h |  18 ++
>  3 files changed, 283 insertions(+), 1 deletion(-)
>

Re: [PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control firmware attributes

[Ilpo Järvinen]

On Mon, 26 Jan 2026, Denis Benato wrote:
> On 1/3/26 00:43, Denis Benato wrote:
> >
> > I was recently reading through the asusctl issue tracker and I found
> > out that some users have been having troubles with the keyboard RGB control
> > that was working before since the creation of asus-armoury and subequent
> > deprecation of old sysfs attributes.
> >
> > This patch series aims to re-introduce those attributes in asus-armoury
> > so that userspace tools can still control keyboard RGB lighting
> > without having to rely on deprecated asus-wmi attributes.
> >
> > In addition to that, since disabling OOBE is essential for controlling
> > LEDs on some models and it was incorrectly tied to deprecated attributes,
> > this patch series also fixes sending OOBE at probe time.
> >
> > Link: https://gitlab.com/asus-linux/asusctl/-/issues/619
> Hi Ilpo, please disregard everything in this patch series except the OOBE fix:
> that fix is important and I see it has been picked up.
> 
> It's probably much better not to touch keyboard modes without a rework
> of the associated RGB interface: it doesn't make sense to move only the
> power state and I already saw there have been reported problems
> with TUFs.
> 
> The original problem I was trying to solve is better solved another way
> via userspace saving the last setting with the interface already provided.

Yes, OOBE fix is now in Linus' tree.

The other 2 patches eliminated from the patchwork queue, thanks.

-- 
 i.