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