Re: Placement of ASUS Aura and platform/x86 ASUS files relocation

["Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>]

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

Hi all,

It seems this thread has went under the radar for me so thanks for the 
pointer in the other thread (this was within the large pile of yet to be 
processed email from the Summer time, I likely won't have time for them 
until the next merge window, if ever...). I'm sorry about that.

On Wed, 26 Aug 2026, Armin Wolf wrote:
> Am 05.08.26 um 14:20 schrieb Denis Benato:
> > On 8/4/26 20:22, Armin Wolf wrote:
> > > Am 04.08.26 um 19:46 schrieb Denis Benato:
> > > 
> > > > Hi all,
> > > > 
> > > > I write this mail to ask a few questions related to the various ASUS
> > > > devices in the kernel both present and futures and how to organize that
> > > > work.
> > > > 
> > > > To understand this mail one needs to know that AURA is the name of the
> > > > lighting ASUS gave to its
> > > > products: each device is divided in one or more zones and each zone
> > > > supports setting an effect like
> > > > static (1 color), strobe (2 colors and speed), rainbow (0 colors), rain
> > > > (0 colors and speed), laser (1 color and direction) and these, to be
> > > > represented in such a way features are not being lost requires a ned
> > > > interface
> > > > that Derek said he wanted to develop as many other hardware would
> > > > benefit from it: I will therefore need
> > > > to specialize it for ASUS things: where is it better to put any .c/.h
> > > > file related to this interface? Is platform-x86 OK?
> > > > 
> > > > The Aura interface has components (all or only certain aspects) working
> > > > via: scsi, (hid) usb + i2c and wmi.
> > > > 
> > > > 1. Liang Haowen has an ASUS nvme enclosure that supports the AURA
> > > > protocol as scsi commands:
> > > > we want those to be in the kernel, but we don't know where to put the
> > > > aura userspace interface (see above).
> > > Hi,
> > > 
> > > it depends on the userspace interface. If you use the LED sysfs API (with
> > > some extensions for the effects), then i suggest
> > > that you place the driver in drivers/leds, because the NVME enclosure is
> > > not a platform device.
> > > 
> > Yeah we will have to bind the LED interface once to the nvme enclosure, up
> > to 8 different interface to the keyboard (one per zone so we can set the
> > physical keyboard in rain and the rear logo in static for example)
> > and also TUFs manage power states via asus-wmi so one interface spawned by
> > i2c will need to be bound
> > to asus-wmi too.
> > 
> > The userspace interface will need to be used by different drivers, in
> > different instances and even more than
> > one driver on the same instance.
> > > I assume you refer to the ROG Arion? If the SCSI commands are used to
> > > issue i2c/smbus requests, then you should also
> > > place the i2c controller driver under /drivers/i2c/busses.
> > > 
> > It is indeed a ROG Arion.
> > > > 2. ASUS has product called "RTX Spark" coming that are arm and will
> > > > support acpi: I have no idea if the asus-wmi
> > > > interface would be reused, but if they decide to do so (and the kernel
> > > > can be made to boot lol) would platform/x86 still be the best place for
> > > > ASUS drivers?
> > > In such a case, moving the affected drivers to drivers/platform/asus/
> > > would be a good idea. There is currently a patch series pending
> > > for enabling ACPI-WMI on arm, so _theoretically_ the asus-wmi driver
> > > should work.
> > > 
> > Splendid news!
> > > > 3. During the upstreaming of asus-armoury Hans de Goede asked if it's
> > > > preferred to have an asus directory containing asus drivers, but the
> > > > discussion died there. Now that I see there is a patchest that will also
> > > > move asus files
> > > > would it be a good time to spawn this discussion?
> > > IMHO having a separate asus directory for all asus-related platform
> > > drivers would indeed be very nice. You could reuse the
> > > drivers/platform/asus directory
> > > for that, and leave the older asus-related drivers inside
> > > drivers/platform/x86 for the time being.
> > > 
> > > Alternatively, you could move all the affected drivers to
> > > drivers/platform/x86/asus, and after that move this directory to
> > > drivers/platform.
> > > 
> > This looks cleaner to me if ASUS will produce ARM products that actually use
> > that interface,
> > but will wait to hear what others think.

Given the information in the recent thread, this is indeed going to happen 
in the near future. Hans' suggestion was to put generic (x86 + arm) WMI 
drivers under drivers/platform/wmi/ (or drivers/platform/wmi/asus/, I 
suppose).

I'm not strictly against drivers/platform/asus/ either, if you prefer that 
and expect it to have something that would not fall well under 
drivers/platform/wmi/.

Anything under drivers/platform/x86/ would not work well for non-x86 
drivers because of Kconfig menu structuring.

Same goes for drivers/platform/wmi/asus/ for non-wmi drivers, Kconfig 
menu structuring would not work for non-WMI drivers placed under there.

So it largely boils down to having a Kconfig structure that makes sense 
(no non-X drivers under drivers/platform/X/).

In any case, if it comes having to move it again, moving entire directory 
is relatively easy so this placement is not a life and dead decision (I 
can probably handle the transition with some sed tricks on the patches 
if there's parallel development).

> > If I do that will platform/x86 still be the correct place to send patches? I
> > don't want to "move" the driver away from platform/x86 mailing list just
> > because the directory changed.
> 
> Sorry for the delay.
> 
> AFAIK as long as the driver is still heavily connected to the x86 platform,
> you can continue to use this mailing list.
> That is what i am doing with the core ACPI-WMI driver.

platform-drivers-x86 has x86 in it's name but in practice the platform 
drivers scope has expanded. Changing the ML name is rather expensive 
operation so we stick with the old name even if it now carries this
baggage. So any platform drivers stuff can be discussed on this list 
regardless where they're under drivers/platform/ and MAINTAINERS entries 
made to point to platform-drivers-x86 ML as is e.g. with Arm64 platform 
drivers already (chrome/, mips/, and raspberrypi/ have own MLs but others 
do use platform-drivers-x86 list).

-- 
 i.