From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-08.mail-europe.com (mail-08.mail-europe.com [57.129.93.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C898B3B52E2 for ; Sun, 17 May 2026 18:30:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=57.129.93.249 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779042637; cv=none; b=s6UikdYK/8SXKE5N99t5pvVr4X3c6Qojehw9D9epTCZMEf1Lm06TXCIXqbeiMY9/Jzmz7YraWvvwkyOt5fB0xk9ePt3Kq/0hERpuolLNF8ySKbg87mzBSvKTCP69ZWBQURe0MSt3J3OGAt32E+jnOpE4aHZmtImJJQtModP9hAU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779042637; c=relaxed/simple; bh=ouF+4HwZ7jpEwU92f7hcfbu0MRmlC+gUU51wFobtCe4=; h=Date:To:From:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=ozqchRbLftkpAhXv6A5Z1Glw0w+9uttWbVpuEg7LDEFUHKcgRI4vaESBLVHjzIbgJTkeTHeH1mYXxba5SGNi8UlZclh/JPzdvociHtiVgcfEY5BakwdCadw87vd56mai+Dqdypm/1O4Hzp0I+xPazLch1txaGhwV4vJ0dZChjQg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ghoul.dev; spf=pass smtp.mailfrom=ghoul.dev; dkim=pass (2048-bit key) header.d=ghoul.dev header.i=@ghoul.dev header.b=Y9jE65Po; arc=none smtp.client-ip=57.129.93.249 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ghoul.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ghoul.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ghoul.dev header.i=@ghoul.dev header.b="Y9jE65Po" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghoul.dev; s=protonmail; t=1779042617; x=1779301817; bh=sNN9uH6YYrjidO1MTd5BcvC2Ek7w5V5g0O9KimcNTog=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=Y9jE65PoHYkdk0LiJHJNHiwtjWBjKrJHzW6HV4C9ZOFk7imr1bXC+oS8g4UA4AX9q s0Q6Uf4yQpa+bbpTJjrqFhkNljfiqG5Wm45QB9ge2DNzSmzvZTgQgTQPG2Gv+wnKLu qwsdQuz1ohjwsUV2Gfttad2ss7iENmDcMl1A2FCWnCmfypCtxVpxAKFrwuNIXnGpuT kxEmAofNMllVYa1YEQWHfGO0aWe10Q3ThNNFhiRXwkQ6wXafcpmvxJUQeRrN0HLKbn sYupnCHD2oMqv4bVxE/dSt7Hav2RylZ73eD2wLZHnVJpGMTTGmBXVJnUr2gPOR0xX7 ls2haFRbUtA0Q== Date: Sun, 17 May 2026 18:30:11 +0000 To: Corentin Chary , "Luke D . Jones" , Denis Benato , Hans de Goede , =?utf-8?Q?Ilpo_J=C3=A4rvinen?= From: Ahmed Yaseen Cc: platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org, Ahmed Yaseen Subject: [PATCH] platform/x86: asus-armoury: fix mini-LED mode get/set on MODE2 devices Message-ID: <20260517182957.11069-1-yaseen@ghoul.dev> Feedback-ID: 177610485:user:proton X-Pm-Message-ID: cbc532239b26216d50ec58563df95edde7d3e95e Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The mini-LED current_value attribute does not work on devices that use ASUS_WMI_DEVID_MINI_LED_MODE2 (2024 and newer models). Reading is broken: mini_led_mode_current_value_show() fetches the mode from the device but then decodes a literal 0 instead of the value it just read: mode =3D FIELD_GET(ASUS_MINI_LED_MODE_MASK, 0); So mode is always 0, and the attribute always reports the same thing regardless of the real hardware state. Writing is broken too. The number a user writes is an index; the value the firmware actually wants is looked up from that index in mini_led_mode_map[]. mini_led_mode_current_value_store() skips that lookup and passes the raw index straight to armoury_attr_uint_store(). On 2024 devices the firmware numbers its modes differently from the index, so some writes are rejected with -EINVAL and the rest send the wrong mode to the hardware. Fix both paths: decode the value actually read from the device when reading, and look up the firmware value before sending it when writing. Older (MODE1) devices were unaffected because there the index and the firmware value are the same. Fixes: f99eb098090e ("platform/x86: asus-armoury: move existing tunings to = asus-armoury module") Signed-off-by: Ahmed Yaseen --- drivers/platform/x86/asus-armoury.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/platform/x86/asus-armoury.c b/drivers/platform/x86/asu= s-armoury.c index 5b0987ccc270..495dc1e31d40 100644 --- a/drivers/platform/x86/asus-armoury.c +++ b/drivers/platform/x86/asus-armoury.c @@ -370,7 +370,7 @@ static ssize_t mini_led_mode_current_value_show(struct = kobject *kobj, =09if (err) =09=09return err; =20 -=09mode =3D FIELD_GET(ASUS_MINI_LED_MODE_MASK, 0); +=09mode =3D FIELD_GET(ASUS_MINI_LED_MODE_MASK, mode); =20 =09for (i =3D 0; i < mini_led_mode_map_size; i++) =09=09if (mode =3D=3D mini_led_mode_map[i]) @@ -386,6 +386,7 @@ static ssize_t mini_led_mode_current_value_store(struct= kobject *kobj, { =09u32 *mini_led_mode_map; =09size_t mini_led_mode_map_size; +=09char mapped_value[12]; =09u32 mode; =09int err; =20 @@ -414,9 +415,16 @@ static ssize_t mini_led_mode_current_value_store(struc= t kobject *kobj, =09=09return -ENODEV; =09} =20 -=09return armoury_attr_uint_store(kobj, attr, buf, count, -=09=09=09=09 0, mini_led_mode_map[mode], -=09=09=09=09 NULL, asus_armoury.mini_led_dev_id); +=09/* +=09 * armoury_attr_uint_store() parses and sends the value from the +=09 * passed buffer; hand it the mapped firmware value so the device +=09 * receives the translated mode instead of the raw index. +=09 */ +=09snprintf(mapped_value, sizeof(mapped_value), "%u", mini_led_mode_map[mo= de]); + +=09return armoury_attr_uint_store(kobj, attr, mapped_value, count, 0, +=09=09=09=09 mini_led_mode_map[mode], NULL, +=09=09=09=09 asus_armoury.mini_led_dev_id); } =20 static ssize_t mini_led_mode_possible_values_show(struct kobject *kobj, --=20 2.54.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2DF643E8C6F for ; Fri, 12 Jun 2026 11:56:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781265404; cv=none; b=Qylc9Ob1ukhFSvpU8k2ufpxwieWfZjPzUsEv8Cuzyqfij+479WO2Ecdhkd2UgaRbGtluPAgO5tgjj7jbUTsibZ6RGHGDDqpUMFkJbsfHKzudC6XST3d+spjxjjT7PAzpRHnoXFBuxqOUTwXAnE7zjdEf4E8yRM2uo112pBNdMJY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781265404; c=relaxed/simple; bh=xiival7uhdbaGiPJI0zULwu+M3Fe9RI8H0YYOPSb9gg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QzUzlyLI7KWu1Dp8Ej8Z2NyuWopOaftHL0QAvr3qMFW3Ru1tYRzSfuD63+mPo1uEXo3MMhw9jaSwBWXhJ9vdT8r5woRPOYL3g+UlLFo5NcL4kJMHUL7gsLhwXvnQDmRSrC/J5shGLuL7v+r35iUxWQ6XwSSkmfdzNh3/IES3DdM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=NRYZUTDY; arc=none smtp.client-ip=91.218.175.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="NRYZUTDY" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781265398; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dKysJoAO23DeyckwwNnzhIfQDe8Fqj2abpdf4RWyHKs=; b=NRYZUTDYsMFr207BY1rxl7BFi5f14Byt1y0Ss6qi1LyHkMLdVQR7bqy+rwRyZSMNmpmE0h 9+0CYKLZ1wBdvKJWFSvptltnsxAhA/HA9FfwrX4byID56+MpnwOD1oWRitZMA52vszLBlV StbZLWraUBiVM97l5q6wtlIhw7vtJhw= From: Denis Benato To: linux-kernel@vger.kernel.org, "Corentin Chary" , "Luke D . Jones" , "Denis Benato" , "Hans de Goede" , =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Cc: platform-driver-x86@vger.kernel.org, "Mateusz Schyboll" , "Denis Benato" , Ahmed Yaseen Subject: [PATCH] platform/x86: asus-armoury: fix mini-LED mode get/set on MODE2 devices Date: Fri, 12 Jun 2026 11:56:28 +0000 Message-ID: <20260517182957.11069-1-yaseen@ghoul.dev> (raw) In-Reply-To: <20260612115628.964152-1-denis.benato@linux.dev> References: <20260612115628.964152-1-denis.benato@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT Message-ID: <20260612115628.c--jv-S8NsMMI9quu3EIZK09J0XkZtTNsRIltpRCYFg@z> From: Ahmed Yaseen The mini-LED current_value attribute does not work on devices that use ASUS_WMI_DEVID_MINI_LED_MODE2 (2024 and newer models). Reading is broken: mini_led_mode_current_value_show() fetches the mode from the device but then decodes a literal 0 instead of the value it just read: mode = FIELD_GET(ASUS_MINI_LED_MODE_MASK, 0); So mode is always 0, and the attribute always reports the same thing regardless of the real hardware state. Writing is broken too. The number a user writes is an index; the value the firmware actually wants is looked up from that index in mini_led_mode_map[]. mini_led_mode_current_value_store() skips that lookup and passes the raw index straight to armoury_attr_uint_store(). On 2024 devices the firmware numbers its modes differently from the index, so some writes are rejected with -EINVAL and the rest send the wrong mode to the hardware. Fix both paths: decode the value actually read from the device when reading, and look up the firmware value before sending it when writing. Older (MODE1) devices were unaffected because there the index and the firmware value are the same. Fixes: f99eb098090e ("platform/x86: asus-armoury: move existing tunings to asus-armoury module") Signed-off-by: Ahmed Yaseen --- drivers/platform/x86/asus-armoury.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/platform/x86/asus-armoury.c b/drivers/platform/x86/asus-armoury.c index 5b0987ccc270..495dc1e31d40 100644 --- a/drivers/platform/x86/asus-armoury.c +++ b/drivers/platform/x86/asus-armoury.c @@ -370,7 +370,7 @@ static ssize_t mini_led_mode_current_value_show(struct kobject *kobj, if (err) return err; - mode = FIELD_GET(ASUS_MINI_LED_MODE_MASK, 0); + mode = FIELD_GET(ASUS_MINI_LED_MODE_MASK, mode); for (i = 0; i < mini_led_mode_map_size; i++) if (mode == mini_led_mode_map[i]) @@ -386,6 +386,7 @@ static ssize_t mini_led_mode_current_value_store(struct kobject *kobj, { u32 *mini_led_mode_map; size_t mini_led_mode_map_size; + char mapped_value[12]; u32 mode; int err; @@ -414,9 +415,16 @@ static ssize_t mini_led_mode_current_value_store(struct kobject *kobj, return -ENODEV; } - return armoury_attr_uint_store(kobj, attr, buf, count, - 0, mini_led_mode_map[mode], - NULL, asus_armoury.mini_led_dev_id); + /* + * armoury_attr_uint_store() parses and sends the value from the + * passed buffer; hand it the mapped firmware value so the device + * receives the translated mode instead of the raw index. + */ + snprintf(mapped_value, sizeof(mapped_value), "%u", mini_led_mode_map[mode]); + + return armoury_attr_uint_store(kobj, attr, mapped_value, count, 0, + mini_led_mode_map[mode], NULL, + asus_armoury.mini_led_dev_id); } static ssize_t mini_led_mode_possible_values_show(struct kobject *kobj, -- 2.54.0