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 <>
To:     Guenter Roeck <>
Cc:     Denis Pauk <>,,, Ed Brindley <>,
        Jean Delvare <>,
        Jonathan Corbet <>,,,
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 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)


Powered by blists - more mailing lists