Re: [PATCH] Intel Management Engine Interface

[Gabriel C <nix.or.die@googlemail.com>]

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