On Thu, Oct 05, 2017 at 09:09:48PM +0200, Greg KH wrote:
> On Thu, Oct 05, 2017 at 07:03:24PM +, mario.limoncie...@dell.com wrote:
...
> > It's up to firmware to block the crazy stuff that you can put in a buffer.
>
> So userspace can pass any blob it wants to the firmware through this
>
On Thu, Oct 05, 2017 at 09:09:48PM +0200, Greg KH wrote:
> On Thu, Oct 05, 2017 at 07:03:24PM +, mario.limoncie...@dell.com wrote:
...
> > It's up to firmware to block the crazy stuff that you can put in a buffer.
>
> So userspace can pass any blob it wants to the firmware through this
>
On Thu, Oct 05, 2017 at 07:03:24PM +, mario.limoncie...@dell.com wrote:
> >
> > And how _exactly_ is this interface exposed in Windows? Is it ad-hoc
> > with custom kernel drivers written by each vendor? Or does the OS
> > provide a "sane" interface for it?
>
> On Windows it's a
On Thu, Oct 05, 2017 at 07:03:24PM +, mario.limoncie...@dell.com wrote:
> >
> > And how _exactly_ is this interface exposed in Windows? Is it ad-hoc
> > with custom kernel drivers written by each vendor? Or does the OS
> > provide a "sane" interface for it?
>
> On Windows it's a
rnel@vger.kernel.org; platform-driver-
> x...@vger.kernel.org; l...@kernel.org; quasi...@google.com;
> r...@rjwysocki.net; mj...@google.com; h...@lst.de
> Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when
> requested by drivers
>
> Hi Greg! I would ans
..@vger.kernel.org; l...@kernel.org; quasi...@google.com;
> r...@rjwysocki.net; mj...@google.com; h...@lst.de
> Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when
> requested by drivers
>
> Hi Greg! I would answer some of your question...
>
> On Thurs
nel.org; platform-driver-...@vger.kernel.org;
> l...@kernel.org; quasi...@google.com; r...@rjwysocki.net;
> mj...@google.com; h...@lst.de
> Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when
> requested by drivers
>
> On Thu, Oct 05, 2017 at 07:03:24
er.kernel.org;
> l...@kernel.org; quasi...@google.com; r...@rjwysocki.net;
> mj...@google.com; h...@lst.de
> Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when
> requested by drivers
>
> On Thu, Oct 05, 2017 at 07:03:24PM +, mario.limoncie...@dell.co
Hi Greg! I would answer some of your question...
On Thursday 05 October 2017 21:09:48 Greg KH wrote:
> On Thu, Oct 05, 2017 at 07:03:24PM +, mario.limoncie...@dell.com wrote:
> > On Windows it's a driver-less solution. Vendors don't do anything other
> > than provide the MOF (which describes
Hi Greg! I would answer some of your question...
On Thursday 05 October 2017 21:09:48 Greg KH wrote:
> On Thu, Oct 05, 2017 at 07:03:24PM +, mario.limoncie...@dell.com wrote:
> > On Windows it's a driver-less solution. Vendors don't do anything other
> > than provide the MOF (which describes
li.ro...@gmail.com>; Limonciello, Mario
> > <mario_limoncie...@dell.com>; andy.shevche...@gmail.com; linux-
> > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org;
> > l...@kernel.org;
> > quasi...@google.com; r...@rjwysocki.net; mj...@google.com; h...@lst.
; ; andy.shevche...@gmail.com; linux-
> > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org;
> > l...@kernel.org;
> > quasi...@google.com; r...@rjwysocki.net; mj...@google.com; h...@lst.de
> > Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices
>
y.shevche...@gmail.com; linux-
> ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; l...@kernel.org;
> quasi...@google.com; r...@rjwysocki.net; mj...@google.com; h...@lst.de
> Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when
> requested by drivers
>
>
.@kernel.org;
> quasi...@google.com; r...@rjwysocki.net; mj...@google.com; h...@lst.de
> Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when
> requested by drivers
>
> On Thu, Oct 05, 2017 at 10:39:25AM -0700, Darren Hart wrote:
> > > It does, thank
On Thu, Oct 05, 2017 at 10:39:25AM -0700, Darren Hart wrote:
> > It does, thanks. And as we now understand it (I'm guessing it had to be
> > semi-understood in the older wmi drivers already), validating it
> > properly seems to be the key for creating an interface that we "know" to
> > be safe.
>
On Thu, Oct 05, 2017 at 10:39:25AM -0700, Darren Hart wrote:
> > It does, thanks. And as we now understand it (I'm guessing it had to be
> > semi-understood in the older wmi drivers already), validating it
> > properly seems to be the key for creating an interface that we "know" to
> > be safe.
>
On Thu, Oct 05, 2017 at 06:26:28PM +0200, Greg KH wrote:
> On Thu, Oct 05, 2017 at 05:51:56PM +0200, Pali Rohár wrote:
> > On Thursday 05 October 2017 17:42:14 Greg KH wrote:
> > > > > > --- /dev/null
> > > > > > +++ b/include/uapi/linux/wmi.h
> > > > > > @@ -0,0 +1,10 @@
> > > > > > +#ifndef
On Thu, Oct 05, 2017 at 06:26:28PM +0200, Greg KH wrote:
> On Thu, Oct 05, 2017 at 05:51:56PM +0200, Pali Rohár wrote:
> > On Thursday 05 October 2017 17:42:14 Greg KH wrote:
> > > > > > --- /dev/null
> > > > > > +++ b/include/uapi/linux/wmi.h
> > > > > > @@ -0,0 +1,10 @@
> > > > > > +#ifndef
On Thu, Oct 05, 2017 at 05:51:56PM +0200, Pali Rohár wrote:
> On Thursday 05 October 2017 17:42:14 Greg KH wrote:
> > > > > --- /dev/null
> > > > > +++ b/include/uapi/linux/wmi.h
> > > > > @@ -0,0 +1,10 @@
> > > > > +#ifndef _UAPI_LINUX_WMI_H
> > > > > +#define _UAPI_LINUX_WMI_H
> > > > > +
> > >
On Thu, Oct 05, 2017 at 05:51:56PM +0200, Pali Rohár wrote:
> On Thursday 05 October 2017 17:42:14 Greg KH wrote:
> > > > > --- /dev/null
> > > > > +++ b/include/uapi/linux/wmi.h
> > > > > @@ -0,0 +1,10 @@
> > > > > +#ifndef _UAPI_LINUX_WMI_H
> > > > > +#define _UAPI_LINUX_WMI_H
> > > > > +
> > >
On Thursday 05 October 2017 17:42:14 Greg KH wrote:
> > > > --- /dev/null
> > > > +++ b/include/uapi/linux/wmi.h
> > > > @@ -0,0 +1,10 @@
> > > > +#ifndef _UAPI_LINUX_WMI_H
> > > > +#define _UAPI_LINUX_WMI_H
> > > > +
> > > > +#define WMI_IOC 'W'
> > > > +#define WMI_IO(instance)
On Thursday 05 October 2017 17:42:14 Greg KH wrote:
> > > > --- /dev/null
> > > > +++ b/include/uapi/linux/wmi.h
> > > > @@ -0,0 +1,10 @@
> > > > +#ifndef _UAPI_LINUX_WMI_H
> > > > +#define _UAPI_LINUX_WMI_H
> > > > +
> > > > +#define WMI_IOC 'W'
> > > > +#define WMI_IO(instance)
On Thu, Oct 05, 2017 at 02:35:43PM +, mario.limoncie...@dell.com wrote:
> >
> > > + strcpy(buf, "wmi/");
> > > + strcpy(buf + 4, wdriver->driver.name);
> > > + wblock->misc_dev.minor = MISC_DYNAMIC_MINOR;
> > > + wblock->misc_dev.name = buf;
> > > +
On Thu, Oct 05, 2017 at 02:35:43PM +, mario.limoncie...@dell.com wrote:
> >
> > > + strcpy(buf, "wmi/");
> > > + strcpy(buf + 4, wdriver->driver.name);
> > > + wblock->misc_dev.minor = MISC_DYNAMIC_MINOR;
> > > + wblock->misc_dev.name = buf;
> > > +
vger.kernel.org>; platform-driver-...@vger.kernel.org;
> Andy Lutomirski <l...@kernel.org>; quasi...@google.com;
> pali.ro...@gmail.com; r...@rjwysocki.net; mj...@google.com; h...@lst.de
> Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when
> requested by
pali.ro...@gmail.com; r...@rjwysocki.net; mj...@google.com; h...@lst.de
> Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when
> requested by drivers
>
> On Wed, Oct 04, 2017 at 05:48:38PM -0500, Mario Limonciello wrote:
> > For WMI operations that
On Wed, Oct 04, 2017 at 05:48:38PM -0500, Mario Limonciello wrote:
> For WMI operations that are only Set or Query read or write sysfs
> attributes created by WMI vendor drivers make sense.
>
> For other WMI operations that are run on Method, there needs to be a
> way to guarantee to userspace
On Wed, Oct 04, 2017 at 05:48:38PM -0500, Mario Limonciello wrote:
> For WMI operations that are only Set or Query read or write sysfs
> attributes created by WMI vendor drivers make sense.
>
> For other WMI operations that are run on Method, there needs to be a
> way to guarantee to userspace
On Wed, Oct 04, 2017 at 05:48:38PM -0500, Mario Limonciello wrote:
> For WMI operations that are only Set or Query read or write sysfs
> attributes created by WMI vendor drivers make sense.
>
> For other WMI operations that are run on Method, there needs to be a
> way to guarantee to userspace
On Wed, Oct 04, 2017 at 05:48:38PM -0500, Mario Limonciello wrote:
> For WMI operations that are only Set or Query read or write sysfs
> attributes created by WMI vendor drivers make sense.
>
> For other WMI operations that are run on Method, there needs to be a
> way to guarantee to userspace
For WMI operations that are only Set or Query read or write sysfs
attributes created by WMI vendor drivers make sense.
For other WMI operations that are run on Method, there needs to be a
way to guarantee to userspace that the results from the method call
belong to the data request to the method
For WMI operations that are only Set or Query read or write sysfs
attributes created by WMI vendor drivers make sense.
For other WMI operations that are run on Method, there needs to be a
way to guarantee to userspace that the results from the method call
belong to the data request to the method
32 matches
Mail list logo