Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754381AbdDNTEY (ORCPT ); Fri, 14 Apr 2017 15:04:24 -0400 Received: from esa4.dell-outbound.iphmx.com ([68.232.149.214]:24525 "EHLO esa4.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751687AbdDNTEU (ORCPT ); Fri, 14 Apr 2017 15:04:20 -0400 From: X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="5.37,199,1488866400"; d="scan'208";a="6537956" To: CC: , , , , , , , , Subject: RE: RFC: WMI Enhancements Thread-Topic: RFC: WMI Enhancements Thread-Index: AQHSs+HFfWGz3Na/pUazu2XvXvLesqHDPJeAgACdVQD//+SO8IAAjzKAgADVHYCAAGLcgP//sIbw Date: Fri, 14 Apr 2017 19:04:12 +0000 Message-ID: <6be8765f968a47b79f6408cc8ddef7f1@ausx13mpc120.AMER.DELL.COM> References: <20170412230854.GA11963@fury> <20170413073339.GH3090@pali> <20170413165646.GD2064@fury> <20170413235103.GB11189@fury> <20170414182739.GA25356@fury> In-Reply-To: <20170414182739.GA25356@fury> 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="us-ascii" 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 quoted-printable to 8bit by mail.home.local id v3EJ4ctq019894 Content-Length: 5849 Lines: 131 > -----Original Message----- > From: Darren Hart [mailto:dvhart@infradead.org] > Sent: Friday, April 14, 2017 1:28 PM > To: Limonciello, Mario > Cc: pali.rohar@gmail.com; rjw@rjwysocki.net; len.brown@intel.com; > corentin.chary@gmail.com; luto@kernel.org; andriy.shevchenko@linux.intel.com; > linux-kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org; linux- > pm@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > On Fri, Apr 14, 2017 at 05:42:03PM +0000, Mario.Limonciello@dell.com wrote: > > > > > > > -----Original Message----- > > > From: Darren Hart [mailto:dvhart@infradead.org] > > > Sent: Thursday, April 13, 2017 6:51 PM > > > To: Limonciello, Mario > > > Cc: pali.rohar@gmail.com; rjw@rjwysocki.net; len.brown@intel.com; > > > corentin.chary@gmail.com; luto@kernel.org; > andriy.shevchenko@linux.intel.com; > > > 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 08:38:28PM +0000, Mario.Limonciello@dell.com > wrote: > > > > Earlier question from Andy. I had some discussion with the right people about > > > this. > > > > > > > > > Is it just the "call SMBIOS" GUID or are there other things? > > > > > > > > Today - it's just the SMBIOS calling GUID. There are plans (not yet concrete) > for > > > > splitting up data access and organization of that data access classes across > > > multiple > > > > other GUID/method pairs in the future. > > > > > > > > Ideally this could be done without needing kernel patches every time a new > GUID > > > > would (essentially) need to be whitelisted. > > > > > > > > > I am a strong supporter of the following philosophy with respect to > supporting > > > > > innovation: > > > > > "Enable them to enable themselves and get out of their way" > > > > > > > > > > I've followed this approach over the years to encourage upstream first > software > > > > > development, open-first policy toward specifications and documentation, > > > proper > > > > > license selection, and development of new mechanisms in existing > standards, > > > like > > > > > ACPI _DSD. All of these serve to support innovation by removing bottlenecks > > > and > > > > > enabling developers to be independent. > > > > > > > > > > What I don't want to see is the Linux kernel becoming a bottleneck to feature > > > > > parity with Windows (or to becoming the lead vehicle for new features). > When a > > > > > vendor has a feature they want to expose which they determine to be a > value > > > > > proposition for their product, I don't want the lack of a class driver to get in > > > > > the way. Exposing specific GUIDs is a minimal and easy to upstream change > > > which > > > > > would enable rapid feature enabling. > > > > > > > > > > Perhaps I should have led with this :-) > > > > > > > > > > > > > So considering future plans, I'd really like if it's possible to expose all the > GUID's > > > the > > > > GUID's the same as Windows does today. > > > > > > A bit of trouble parsing... to be clear, your preference would be that for the > > > PNP0C14 on whitelisted platforms (either DMI matches, or possibly via the ACPI > > > Device UID?) we expose every GUID (Method, Event, and Data) for that device to > > > userspace? > > > > My preference would be to expose everything found in _WDG across platforms so > it > > doesn't have to be a whitelist. DMI matching could work if it was done > specifically > > on the manufacturer rather than individual system. > > > > If you compare to how it's done with the other OS, everything mentioned in the > MOF > > is accessible from userspace. The only reason the MOF exists is to match up > > what's in _WDG. Linux can make this actually easier in that you just don't use the > > MOF at all. > > > > > > > > The concern raised here is that for systems using dell-wmi, the two GUIDs used > > > by the kernel would also be exposed to userspace. Is this correct? > > OK, rather than whitelisting specific GUIDs to be exported, what if we matched > on a vendor and exported all of them except for the ones that any kernel drivers > have already bound to? For example, dell-wmi currently binds to: > > #define DELL_EVENT_GUID "9DBB5994-A997-11DA-B012-B622A1EF5492" > #define DELL_DESCRIPTOR_GUID "8D9DDCBC-A997-11DA-B012-B622A1EF5492" > > Perhaps a set of mof and $vendor-mof drivers could be created which would do > what > Andy L's patch does, but match on DMI Vendor or WMI PNP UID and export all > interfaces. When another kernel driver binds to a WMI GUID, that GUID will > either not be exported, or it will be "locked" from a userspace perspective. > > This of course is dependent on whether or not the WMI GUIDs are granular enough > or if the same GUID is needed by the userpsace application AND by the kernel > driver to perform different functions - this would be really unfortunate. > > That said, from what I've learned about WMI, it was designed to provide access > to firmware from userspace. The approach we take in Linux currently was > expedient, but not consistent with the intent of the mechanism. > For $FUTURE GUIDs that approach could potentially work depending upon how the different GUID's are segmented. There's a few different approaches being discussed. It unfortunately wouldn't work with the "current" stuff though if we go forward with the proposal to adjust dell-smbios to use the WMI calls too. The SMBIOS GUID(A80593CE-A997-11DA-B012-B622A1EF5492) would get taken by dell-smbios and hence not available to userspace. It would be fine to restrict the event one (9DBB5994-A997-11DA-B012-B622A1EF5492). The one the kernel sees as DESCRIPTOR_GUID can be used to provide static Info, I don't think that's needed by userspace either.