linux-kernel - Re: [PATCH v3 2/2] hwmon: (asus_wmi

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 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]

Date:   Sun, 10 Oct 2021 16:10:43 +0200
From:   Thomas Weißschuh <thomas@...ch.de>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Denis Pauk <pauk.denis@...il.com>, eugene.shalygin@...il.com,
        andy.shevchenko@...il.com, Ed Brindley <kernel@...davale.org>,
        Jean Delvare <jdelvare@...e.com>,
        Jonathan Corbet <corbet@....net>, linux-hwmon@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] hwmon: (asus_wmi_sensors) Support X370 Asus WMI.

On 2021-10-10T06:38-0700, Guenter Roeck wrote:
> On 10/10/21 3:20 AM, Thomas Weißschuh wrote:
> > Hi,
> > 
> > for WMI drivers the list platform-driver-x86@...r.kernel.org should probably be
> > on CC too.
> > Also all other WMI drivers, even for hwmon stuff are located in
> > drivers/platform/x86 so it may be better to put it there, too.
> > 
> 
> Not really. If any of those other drivers are pure hwmon drivers, they
> should reside in drivers/hwmon instead. And, yes, that really includes
> the gigabyte-wmi driver. We don't have arbitrary drivers in drivers/pci
> either just because they are drivers for pci devices.

Fair enough.
I suppose it would be too much churn to move gigabyte-wmi to
hwmon now though, correct?

Having the platform-driver-x86 on Cc would still be useful as they can provide
guidance about using the ACPI/WMI/platform APIs.

For example by using the WMI bus as mentioned in my other mail would allow
to completely remove the manually maintained DMI list and instead directly bind
to the WMI GUID for any device that supports this GUID.
(This is possible as this WMI API seems to be self-describing, so all
specific parameters can be discovered by the driver)

Thomas