[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6F5C1D715B2DA5498A628E6B9C124F0401CB6A3370@hasmsx504.ger.corp.intel.com>
Date: Thu, 22 Sep 2011 22:06:14 +0300
From: "Winkler, Tomas" <tomas.winkler@...el.com>
To: Greg KH <greg@...ah.com>
CC: "Weil, Oren jer" <oren.jer.weil@...el.com>,
"gregkh@...e.de" <gregkh@...e.de>,
"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] staging: mei: clean the TODO file from done tasks.
> -----Original Message-----
> From: Greg KH [mailto:greg@...ah.com]
> Sent: Thursday, September 22, 2011 9:32 PM
> To: Winkler, Tomas
> Cc: Weil, Oren jer; gregkh@...e.de; devel@...verdev.osuosl.org; linux-
> kernel@...r.kernel.org
> Subject: Re: [PATCH 2/2] staging: mei: clean the TODO file from done tasks.
>
> On Thu, Sep 22, 2011 at 09:12:21PM +0300, Winkler, Tomas wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH [mailto:greg@...ah.com]
> > > Sent: Thursday, September 22, 2011 7:30 PM
> > > To: Weil, Oren jer
> > > Cc: gregkh@...e.de; devel@...verdev.osuosl.org; Winkler, Tomas;
> > > linux- kernel@...r.kernel.org
> > > Subject: Re: [PATCH 2/2] staging: mei: clean the TODO file from done
> tasks.
> > >
> > > On Wed, Sep 21, 2011 at 04:45:31PM +0300, Oren Weil wrote:
> > > > Acked-by: Tomas Winkler <tomas.winkler@...el.com>
> > > > Signed-off-by: Oren Weil <oren.jer.weil@...el.com>
> > > > ---
> > > > drivers/staging/mei/TODO | 10 ----------
> > > > 1 files changed, 0 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/mei/TODO b/drivers/staging/mei/TODO
> > > > index 3b6a667..7d9a13b 100644
> > > > --- a/drivers/staging/mei/TODO
> > > > +++ b/drivers/staging/mei/TODO
> > > > @@ -1,14 +1,4 @@
> > > > TODO:
> > > > - - Create in-kernel Client API. Examples of in-kernel clients are
> > > watchdog and AMTHI.
> > >
> > > Did you really do this?
> > We came to conclusion, this is not really necessary.
>
> Why? Where was that discussion?
You're right about it we did it only internally, yet we also produced this requirement internally. Not sure how to address it in this stage.
>
> > > > - - ME Watchdog Driver to expose standard Linux watchdog interface
> >
> > Yes, this was submitted in the previous batch and it doesn't required
> > really decupling as we previously estimated.
>
> Ok, good.
>
> > > And this?
> > >
> > > > - - Rewrite AMTHI to use in-kernel client interface
> > >
> > > And this?
> > This would be only use case for creating API and in this case it would
> > just bloat the driver for little benefit.
>
> Again, where was that discussion?
>
> > Since this le
>
> ???
>
> > >
> > > > - - Cleanup init and probe functions
> > > > - - Review BUG/BUG_ON usage
> > > > - - Cleanup and reorganize header files
> > > > - - Rewrite client data structure
> > >
> > > And this?
> >
> > This was mostly done, you can judge if this is enough.
>
> Ok, will look at this later.
>
> > > > - - Make state machine more readable
> > > > - - Add mei.txt with driver explanation and it's driver
> > >
> > > You really don't describe the kernel/user api here, that needs to be
> > > well documented as it is a ABI you are creating and we need to know
> > > how it works.
> >
> > The API is described in the mei.txt that is present in the driver folder.
>
> Really? I see no description of the ioctls and the structures used in them, no
> any explaination of any of the sysfs files used in the driver in that file. Please
> fix this up. The proper format for all sysfs files is described in
> Documentation/ABI/README and the ioctls you can also use the same
> format.
We don't really use sysfs anymore this is just legacy named wrappers for adding device class, we should fix that.
We will address the IOCTLs as well.
> > There was also lengthy discussion about it In LKML during our first
> > try to submit the driver. If it is still not clear enough please let
> > us know we would happy to fix it as any other gaps.
>
> It's not clear at all. Where is the userspace tools that interact with this driver
> that allows me to test that the code works properly? That would be a good
> first step as I do have access to this hardware around here to test with. Do
> any distros already have it packaged anywhere?
In the mei.txt file are links to freely available APIs. The user space is usually developed by third parties
yet you can get AMT Configuration Utility from http://software.intel.com/. We will send the patch to mei.txt that add the link.
I personally don't working with distros, but I believe that SUSE has major deployment of iAMT (MEI). Oren may have more info about it.
Thanks
Tomas
> thanks,
>
> greg k-h
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists