Messages in this thread | | | Date | Tue, 20 May 2008 21:02:17 +0200 | From | Gabriel C <> | Subject | Re: [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
| |