From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 14 21:25:41 2009 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56D8E106568D; Wed, 14 Oct 2009 21:25:41 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 1A8908FC0C; Wed, 14 Oct 2009 21:25:40 +0000 (UTC) Received: from [192.168.1.4] (adsl-154-199-198.ard.bellsouth.net [72.154.199.198]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n9ELPc59026929 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Oct 2009 17:25:38 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Andriy Gapon In-Reply-To: <4AD6067E.2010503@icyb.net.ua> References: <4AD6067E.2010503@icyb.net.ua> Content-Type: text/plain Organization: FreeBSD Date: Wed, 14 Oct 2009 16:25:32 -0500 Message-Id: <1255555532.95374.147.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@FreeBSD.org, freebsd-acpi@FreeBSD.org Subject: Re: heci: a new driver for review and testing X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 21:25:41 -0000 On Wed, 2009-10-14 at 20:12 +0300, Andriy Gapon wrote: > Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: > http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 > > I actually got around to implementing it (in initial/basic form): > http://people.freebsd.org/~avg/heci.tgz Your getting a WITNESS warning from malloc() while holding a lock at like 941 of heci.c mec = (struct me_client *)malloc(sizeof(*mec), M_HECI, M_NOWAIT | M_ZERO); fixes it. It also locked up the machine when I tried to kldunload, but haven't identified a root cause of that. robert. > Other drivers are: > [Linux] http://www.openamt.org/ > [OpenSolaris] > http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/intel/io/heci/ > > An example of what functionality this driver could provide: > http://article.gmane.org/gmane.linux.drivers.sensors/20398 > This actually was my primary motivation for looking into this driver. > > Your hardware may be supported by this driver if pciconf -lv has something like > the following: > none0@pci0:0:3:0: class=0x078000 card=0x50448086 chip=0x29c48086 rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > device = '(Bearlake) HECI Controller' > class = simple comms > > Here's how successful attachment of this driver looks on my system: > heci0: mem > 0xe0426100-0xe042610f irq 16 at device 3.0 on pci0 > heci0: using MSI > heci0: [ITHREAD] > heci0: found ME client at address 0x03: > heci0: status = 0x00 > heci0: protocol_name(guid) = A12FF5CA-FACB-4CB4-A958-19A23B2E6881 > heci0: found ME client at address 0x07: > heci0: status = 0x00 > heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB > heci0: found ME client at address 0x20: > heci0: status = 0x00 > heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327 > heci0: found ME client at address 0x21: > heci0: status = 0x00 > heci0: protocol_name(guid) = 6B5205B9-8185-4519-B889-D98724B58607 > > The driver has many functional and programming shortcomings, but I still would > like to ask for its review and testing. > Please read the following warnings and notices: > 1. right now the driver is provided only as a module. > 2. the driver recognizes only PCI ID of 0x29c48086, which is what I tested it > with; please see hecireg.h for a list of potentially supported IDs and add your ID > to heci_probe(). > 3. heciio.h does not get installed into /usr/include, so for time being you need > to take an extra step to make it available to code that wishes to communicate to heci. > 4. this driver has far less capabilities than Linux and OpenSolaris drivers, so > don't expect every OpenAMT program to work with it (but it does reliably work for > me for the QST thing). > > Now more details about the code: > 1. the code contains some style violations like overly long lines, probably > others; but I still would like to hear your comments on its style. > 2. there are some bad design decisions like using the same mutex+condvar pair for > signaling different events (reception of data from ME, emptying of user buffer); > but I still would like to hear your comments about improving the design. > 3. only a single connection is allowed for a host client > 4. only a single connection is allowed to a ME client (if the client can support > more). > 5. quite an arbitrary timeout is used in all places where we wait for simething to > happen. > 6. no power management supported. > 7. only messages of size less than 512 bytes are supported. > 8. only complete messages are supported, multi-part messages are not. > 9. userland is expected to read or write the whole message in one go. > 10. poll/select functionality is not tested. > 11. non-blocking reads/writes are not supported. > 12. some (probably important) properties and statuses of ME clients are not > interpreted. > 13. no specific support for watchdog and PTHI, only simple HECI/MEI communications. > 14. probably many more... > > I think that ultimately, if complete feature support is needed, it would be easier > to port the driver from either OpenSolaris or Linux than to add all the features > to the presented driver. This is because documentation/description for many > features is severely lacking in public access. I guess that Intel developers that > worked on the OpenAMT driver had much more detailed specifications to work with. > But reverse-engineering some parts of OpenAMT code is very hard. > You can see for yourself, if not for the hacker who decompiled a Windows DLL, > there would be no way of obtaining even GUID of QST client from public sources. > > Thank you very much in advance for any feedback, comments, ideas! > > P.S. > BTW, can/may I drop "alternatively GPL" wording from License block of the files I > borrowed from Intel? I.e. can a dual BSD+GPL licensed file be turned into BSD-only? > Some additional info. The files contain only some data structure/constants > definitions. I guess those are not copyrightable at all? I added a bunch of > comments to those file describing the constants and structs. > -- Robert Noland FreeBSD