Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755258AbdDMRpO (ORCPT ); Thu, 13 Apr 2017 13:45:14 -0400 Received: from esa6.dell-outbound.iphmx.com ([68.232.149.229]:64127 "EHLO esa6.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754864AbdDMRpM (ORCPT ); Thu, 13 Apr 2017 13:45:12 -0400 From: X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.37,195,1488866400"; d="scan'208";a="977140365" To: , CC: , , , , , , , , Subject: RE: RFC: WMI Enhancements Thread-Topic: RFC: WMI Enhancements Thread-Index: AQHSs+HFfWGz3Na/pUazu2XvXvLesqHDPEIAgACGNAD//7EgQIAAaAKAgAAIZ4D//663YA== Date: Thu, 13 Apr 2017 17:45:08 +0000 Message-ID: References: <20170412230854.GA11963@fury> <20170413073228.GB1462@ozzy.nask.waw.pl> <20170413170245.GE2064@fury> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.208.86.26] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v3DHjKfB030326 Content-Length: 6889 Lines: 139 > -----Original Message----- > From: Andy Lutomirski [mailto:luto@kernel.org] > Sent: Thursday, April 13, 2017 12:33 PM > To: Darren Hart > Cc: Limonciello, Mario ; Andrew Lutomirski > ; Michał Kępień ; Rafael J. Wysocki > ; Len Brown ; Pali Rohár > ; Corentin Chary ; Andy > Shevchenko ; linux-kernel@vger.kernel.org; > platform-driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > On Thu, Apr 13, 2017 at 10:02 AM, Darren Hart wrote: > > On Thu, Apr 13, 2017 at 03:55:01PM +0000, Mario.Limonciello@dell.com wrote: > >> > >> > >> > -----Original Message----- > >> > From: Andy Lutomirski [mailto:luto@kernel.org] > >> > Sent: Thursday, April 13, 2017 10:33 AM > >> > To: Michał Kępień > >> > Cc: Darren Hart ; Rafael Wysocki > ; > >> > Len Brown ; Pali Rohár ; > Corentin > >> > Chary ; Limonciello, Mario > >> > ; Andy Lutomirski ; Andy > >> > Shevchenko ; LKML >> > kernel@vger.kernel.org>; platform-driver-x86@vger.kernel.org; linux- > >> > pm@vger.kernel.org > >> > Subject: Re: RFC: WMI Enhancements > >> > > >> > On Thu, Apr 13, 2017 at 12:32 AM, Michał Kępień > wrote: > >> > >> Hi All, > >> > >> > >> > >> There are a few parallel efforts involving the Windows Management > >> > >> Instrumentation (WMI)[1] and dependent/related drivers. I'd like to > >> > >> have a round of discussion among those of you that have been involved > >> > >> in this space before we decide on a direction. > >> > >> > >> > >> The WMI support in the kernel today fairly narrowly supports a > >> > >> handful of systems. Andy L. has a work-in-progress series [2] which > >> > >> converts wmi into a platform device and a proper bus, providing > >> > >> devices for dependent drivers to bind to, and a mechanism for sibling > devices to > >> > communicate with each other. > >> > >> I've reviewed the series and feel like the approach is sound, I plan > >> > >> to carry this series forward and merge it (with Andy L's permission). > >> > >> > >> > >> Are there any objections to this? > >> > > > >> > > Back in January 2016, I sent Andy a few minor comments about this > >> > > series. A year later, I offered to iron out the remaining issues and > >> > > resubmit the series in Andy's name when I find the time. Sadly, > >> > > things have changed a bit for me since that time and it is unlikely > >> > > that I will be able to deliver, for which I am sorry. > >> > > > >> > > However, browsing Andy's branch I see that most issues have been > >> > > resolved, though I think some of my remarks [1] have either been > >> > > missed or silently refuted :) > >> > > > >> > > Anyway, I also like this approach and I think this series is a > >> > > valuable cleanup. > >> > > >> > Me too :) > >> > > >> > >> In Windows, applications interact with WMI more or less directly. We > >> > >> don't do this in Linux currently, although it has been discussed in > >> > >> the past [3]. Some vendors will work around this by performing > >> > >> SMI/SMM, which is inefficient at best. Exposing WMI methods to > >> > >> userspace would bring parity to WMI for Linux and Windows. > >> > >> > >> > >> There are two principal concerns I'd appreciate your thoughts on: > >> > >> > >> > >> a) As an undiscoverable interface (you need to know the method > >> > >> signatures ahead of time), universally exposing every WMI "device" to > >> > >> userspace seems like "a bad idea" from a security and stability > >> > >> perspective. While access would certainly be privileged, it seems > >> > >> more prudent to make this exposure opt-in. We also handle some of > >> > >> this with kernel drivers and exposing those "devices" to userspace > >> > >> would enable userspace and the kernel to fight over control. So - if > >> > >> we expose WMI devices to userspace, I believe this should be done on > >> > >> a case by case basis, opting in, and not by default as part of the > >> > >> WMI driver (although it can provide the mechanism for a sub-driver to use), > and > >> > possibly a devmode to do so by default. > >> > > >> > I agree. I don't want too see gnome-whatever-widget talking directly to WMI > and > >> > confusing the kernel driver for the same thing. > >> > >> So there are plenty of other things that can be done by WMI that don't > >> really make sense to live in the kernel, particularly on what Dell exposes via > >> WMI. > >> > >> If the desire of this group ends up being to not expose WMI by default, > >> I'd like to at least propose it be exposed for the GUID's Dell is using. > >> > > > > What I'm thinking is an explicit list of GUIDs within the drivers which are to > > be exposed to user space. The rationale being: > > > > * GUIDs which are managed by kernel drivers (LEDs, hotkeys, etc.) should not be > > exposed to userspace. > > > > * Management GUIDs should not change frequently > > > > * Management GUIDs are a trivial add, equivalent to adding a DEVICE ID to an > > existing driver. This means minimal review time to get upstream, and the > > ability to include in stable backports as needed. I haven't confirmed > > this with Greg KH, but I think I can make the case, especially after > > Andy L's WMI-as-a-bus patches. > > Would this be a class driver that would expose a chardev for each > bound GUID? I agree that this makes a lot more sense than trying to > shoehorn it into sysfs. Especially since we'd want closing the > chardev to disable any "expensive" collections that have been enabled > by ioctl on that chardev. Exposing Dell's smbios entry point through > this type of device seems reasonable to me. > > If we go this route, then I think that exposing the MOF through sysfs > would make sense -- after all, someone might actually want to parse > the thing for production purposes. I agree. > > On a sort-of-on-topic note, there's one platform feature that we > complete fail to handle in the kernel that might be nice to add before > it gets kludged into lots of userspace code: battery charge controls. > Thinkpads expose charge thresholds using abominable interfaces, but I > think they've all been reverse-engineered. Dell probably has them, > and I bet that Mario would consider telling us how to use them if we > asked nicely. It might be nice to expose these generically through > sysfs somewhere. > Sure. They're part of the token interface. https://github.com/dell/libsmbios/blob/master/doc/token_list.csv#L834