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]
Date:   Sun, 10 Oct 2021 07:56:00 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Thomas Weißschuh <thomas@...ch.de>
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 10/10/21 7:10 AM, Thomas Weißschuh wrote:
> 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?
> 

Is it ? I don't recall the reason why it was added to drivers/platform/x86
in the first place. I see other single-use wmi drivers in that directory
as well (eg xiaomi-wmi, which should be in input). Is there some unwritten
rule stating that all wmi drivers shall reside in drivers/platform/x86,
no matter what subsystem they touch ?

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

Sure, but that is unrelated to the driver location, and the opposite argument
can be made as well (that drivers implementing subsystem code should be reviewed
by subsystem maintainers). That is a much stronger argument in my opinion.

Guenter

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ