lkml.org 
[lkml]   [2008]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Intel Management Engine Interface
Andrew Morton wrote:

> On Mon, 19 May 2008 20:11:54 -0400
> Anas Nashif <nashif@linux.intel.com> wrote:
>
>> We have addressed more issues raised on lkml after initial submission,
>> especially the legacy device support issue which was removed in this
>> patch.
>>
>> The Intel Management Engine Interface (aka HECI: Host Embedded
>> Controller Interface ) enables communication between the host OS and
>> the Management Engine firmware. MEI is bi-directional, and either the
>> host or Intel AMT firmware can initiate transactions.
>>
>> The core hardware architecture of Intel Active Management Technology
>> (Intel AMT) is resident in firmware. The micro-controller within the
>> chipset's graphics and memory controller (GMCH) hub houses the
>> Management Engine (ME) firmware, which implements various services
>> on behalf of management applications.
>>
>> Some of the ME subsystems that can be access via MEI driver:
>>
>> - Intel(R) Quiet System Technology (QST) is implemented as a firmware
>> subsystem that runs in the ME. Programs that wish to expose the
>> health monitoring and fan speed control capabilities of Intel(R) QST
>> will need to use the MEI driver to communicate with the ME sub-system.
>> - ASF is the "Alert Standard Format" which is an DMTF manageability
>> standard. It is implemented in the PC's hardware and firmware, and is
>> managed from a remote console.
>>
>> Most recent Intel desktop chipsets have one or more of the above ME
>> services. The MEI driver will make it possible to support the above
>> features on Linux and provides applications access to the ME and it's
>> features.
>
> What a lot of code.
>
> It'd be nice if the changelog were to describe the proposed and
> all-important kernel<->userspace interface, please. From a five-second
> peek it looks like a miscdev with ioctls? Ah, and there's read and
> write too.
>
> What is the payload for those system calls, and the meanings of their
> return values, etc, etc?
>
> Does it make sense for this driver to be available on all
> architectures?

This patch is against what tree / kernel version ?

Won't compile on current kernels cause it still uses class_device_* so I guess it is based on 2.6.22/23 ?

Also in drivers/char/Makefile $(CONFIG_HECI) should be $(CONFIG_INTEL_MEI)


Gabriel


\
 
 \ /
  Last update: 2008-05-20 21:05    [W:0.331 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site