From: <Mario.Limonciello@dell.com>
To: <dvhart@infradead.org>
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
Date: Fri, 14 Apr 2017 19:04:12 +0000 [thread overview]
Message-ID: <6be8765f968a47b79f6408cc8ddef7f1@ausx13mpc120.AMER.DELL.COM> (raw)
In-Reply-To: <20170414182739.GA25356@fury>
> -----Original Message-----
> From: Darren Hart [mailto:dvhart@infradead.org]
> Sent: Friday, April 14, 2017 1:28 PM
> To: Limonciello, Mario <Mario_Limonciello@Dell.com>
> 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 <Mario_Limonciello@Dell.com>
> > > 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.
next prev parent reply other threads:[~2017-04-14 19:04 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-12 23:08 RFC: WMI Enhancements Darren Hart
2017-04-13 7:32 ` Michał Kępień
2017-04-13 13:29 ` Mario.Limonciello
2017-04-13 13:51 ` Pali Rohár
2017-04-13 15:34 ` Andy Lutomirski
2017-04-13 15:40 ` Mario.Limonciello
2017-04-13 16:06 ` Darren Hart
2017-04-13 15:40 ` Mario.Limonciello
2017-04-18 7:36 ` Andy Shevchenko
2017-04-18 14:08 ` Mario.Limonciello
2017-04-13 15:32 ` Andy Lutomirski
2017-04-13 15:39 ` Pali Rohár
2017-04-13 15:44 ` Andy Lutomirski
2017-04-13 16:09 ` Darren Hart
2017-04-13 15:55 ` Mario.Limonciello
2017-04-13 15:57 ` Andy Lutomirski
2017-04-13 16:54 ` Mario.Limonciello
2017-04-13 17:06 ` Darren Hart
2017-04-13 17:39 ` Mario.Limonciello
2017-04-13 17:44 ` Andy Lutomirski
2017-04-13 17:49 ` Mario.Limonciello
2017-04-18 7:54 ` Pali Rohár
2017-04-18 16:56 ` Darren Hart
2017-04-18 19:28 ` Pali Rohár
2017-04-13 17:02 ` Darren Hart
2017-04-13 17:32 ` Andy Lutomirski
2017-04-13 17:45 ` Mario.Limonciello
2017-04-13 16:08 ` Darren Hart
2017-04-13 7:33 ` Pali Rohár
2017-04-13 16:56 ` Darren Hart
2017-04-13 20:38 ` Mario.Limonciello
2017-04-13 23:51 ` Darren Hart
2017-04-14 17:42 ` Mario.Limonciello
2017-04-14 18:27 ` Darren Hart
2017-04-14 19:04 ` Mario.Limonciello [this message]
2017-04-14 22:45 ` Rafael J. Wysocki
2017-04-14 23:05 ` Darren Hart
2017-04-17 22:03 ` Andy Lutomirski
2017-04-17 23:10 ` Darren Hart
2017-04-18 13:07 ` Rafael J. Wysocki
2017-04-18 16:33 ` Darren Hart
2017-04-18 19:28 ` Pali Rohár
2017-04-18 22:49 ` Darren Hart
2017-04-19 7:52 ` Pali Rohár
2017-04-19 16:29 ` Mario.Limonciello
2017-04-19 16:54 ` Pali Rohár
2017-04-19 17:24 ` Mario.Limonciello
2017-04-20 13:14 ` Pali Rohár
2017-04-20 20:44 ` Darren Hart
2017-05-05 21:55 ` Mario.Limonciello
2017-05-05 23:44 ` Darren Hart
2017-05-06 0:51 ` Mario.Limonciello
2017-05-06 1:25 ` Andy Lutomirski
2017-05-08 15:29 ` Darren Hart
2017-05-08 15:36 ` Mario.Limonciello
2017-05-08 15:47 ` Darren Hart
2017-05-08 16:00 ` Mario.Limonciello
2017-05-08 16:04 ` Andy Shevchenko
[not found] ` <CAOg5c--wkQgvsmhTynAKyG9iWaHjRWC5Z+MXzVJVw66vxSz4Zw@mail.gmail.com>
2017-05-08 18:26 ` Mario.Limonciello
2017-05-08 19:09 ` Darren Hart
2017-05-08 19:11 ` Mario.Limonciello
2017-05-08 17:17 ` Pali Rohár
2017-05-08 19:21 ` Mario.Limonciello
2017-05-08 20:59 ` Pali Rohár
2017-05-08 21:18 ` Mario.Limonciello
2017-05-08 22:17 ` Pali Rohár
2017-05-09 1:10 ` Mario.Limonciello
2017-05-09 7:29 ` Pali Rohár
2017-05-09 18:10 ` Mario.Limonciello
2017-05-09 19:04 ` Andy Shevchenko
2017-05-09 19:16 ` Mario.Limonciello
2017-05-09 19:26 ` Andy Shevchenko
2017-05-09 22:38 ` Pali Rohár
2017-05-09 19:19 ` Pali Rohár
2017-04-20 14:17 ` Christoph Hellwig
2017-04-18 21:14 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6be8765f968a47b79f6408cc8ddef7f1@ausx13mpc120.AMER.DELL.COM \
--to=mario.limonciello@dell.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=corentin.chary@gmail.com \
--cc=dvhart@infradead.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pali.rohar@gmail.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rjw@rjwysocki.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).