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

Message-ID: <992b2843-4afa-ede1-d276-8ccaa61b1fee@linux.intel.com>
Date: Tue, 13 Jan 2026 16:02:30 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Denis Benato <denis.benato@...ux.dev>
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 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(-)