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