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

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] [day] [month] [year] [list]

Message-ID: <2e1f5ce5-3647-4dff-b67e-327b0c1cb12e@linux.dev>
Date: Tue, 13 Jan 2026 22:53:49 +0100
From: Denis Benato <denis.benato@...ux.dev>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: LKML <linux-kernel@...r.kernel.org>, platform-driver-x86@...r.kernel.org,
 Hans de Goede <hansg@...nel.org>, "Luke D . Jones" <luke@...nes.dev>,
 Mateusz Schyboll <dragonn@...pl>, Denis Benato <benato.denis96@...il.com>
Subject: Re: [PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control
 firmware attributes


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!