All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Simon J. Rowe" <srowe@mose.org.uk>
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] RFC: Intel QST driver
Date: Mon, 24 Dec 2012 08:37:57 +0000	[thread overview]
Message-ID: <50D81465.9060802@mose.org.uk> (raw)

I've written a driver for the Intel Quiet System Technology (QST)
function of the Management Engine Interface found on recent Intel
chipsets.

The git repo can be found here:

     http://mose.dyndns.org/mei.git

A few questions / observations,

1) The code was developed and tested on 2.6.39. I would hope it
compiles and runs on 3.x but I haven't tried it.

2) The main hwmon code is in qst-hwmon.c. This implements QST v1, I
don't have access to hardware that supports v2. I would imagine that
implementing v2 would result in a new module (qst2-hwmon) which would
be almost identical.

3) I've gone a bit overboard with preprocessor macros but it does mean
that the amount of duplicated code is kept to a minimum.

3) I've not implemented any PWM methods yet.

4) I don't believe the MEI (HECI) implementation that Intel have
already submitted to the mainline kernel is usable by other kernel
modules. I have re-implemented it in a way that is accessible to
either the kernel or userspace.

5) I had to patch libsensors to work with a new bus type

diff -ur lm_sensors-3.3.1.org//lib/sysfs.c lm_sensors-3.3.1/lib/sysfs.c
--- lm_sensors-3.3.1.org//lib/sysfs.c   2011-03-04 20:37:43.000000000 +0000
+++ lm_sensors-3.3.1/lib/sysfs.c        2012-11-14 21:48:52.144860375 +0000
@@ -701,6 +701,12 @@
                 /* As of kernel 2.6.32, the hid device names don't look 
good */
                 entry.chip.bus.nr = bus;
                 entry.chip.addr = id;
+       } else
+       if (subsys && !strcmp(subsys, "intel-mei") &&
+           sscanf(dev_name, "mei%d:%d", &bus, &fn) = 2) {
+               entry.chip.bus.type = SENSORS_BUS_TYPE_PCI;
+               entry.chip.bus.nr = bus;
+               entry.chip.addr = fn;
         } else {
                 /* Ignore unknown device */
                 err = 0;

surely this sort of knowledge belongs in the driver not userspace?
Could drivers not provide another set of sysfs attributes which expose
bus type, number, addr etc?

Please let me know if there's any changes or improvements I can make
to it.

Simon

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

             reply	other threads:[~2012-12-24  8:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-24  8:37 Simon J. Rowe [this message]
2012-12-24 19:30 ` [lm-sensors] RFC: Intel QST driver Guenter Roeck
2012-12-24 19:30   ` Guenter Roeck
2012-12-26  7:56   ` Tomas Winkler
2012-12-26  7:56     ` Tomas Winkler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50D81465.9060802@mose.org.uk \
    --to=srowe@mose.org.uk \
    --cc=lm-sensors@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.