[lm-sensors] How do you make lm_sensors see a hwmon device?

[lm-sensors] How do you make lm_sensors see a hwmon device?

[Adam Nielsen]

Hi all,

I've written a driver for a USB device that has a number of sensors on it
(it's a PC power supply with a USB cable for voltage/current monitoring) and
the device appears in the hwmon class.

Unfortunately I can't figure out how to make lm_sensors "see" it (when I run
"sensors" it isn't displayed, and programs like gkrellm that use lm_sensors
don't see the device or its sensors.)  The files all seem to be in the same
place as other devices which work, and I'm running a fairly recent version of
lm_sensors (3.0.3.)

Any ideas how to make my device appear to lm_sensors?

$ ls /sys/class/hwmon/hwmon[45]/device/name
-r--r--r-- 1 root root 4.0K 2009-10-11 22:55 /sys/class/hwmon/hwmon4/device/name
-r--r--r-- 1 root root 4.0K 2009-10-11 23:24 /sys/class/hwmon/hwmon5/device/name

$ cat /sys/class/hwmon/hwmon[45]/device/name
coretemp
odin

$ cat /sys/class/hwmon/hwmon[45]/device/temp1_input
50000
39000

Many thanks,
Adam.

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

Re: [lm-sensors] How do you make lm_sensors see a hwmon device?

[Jean Delvare]

Hi Adam,

On Sun, 11 Oct 2009 23:44:43 +1000, Adam Nielsen wrote:
> I've written a driver for a USB device that has a number of sensors on it
> (it's a PC power supply with a USB cable for voltage/current monitoring) and
> the device appears in the hwmon class.
> 
> Unfortunately I can't figure out how to make lm_sensors "see" it (when I run
> "sensors" it isn't displayed, and programs like gkrellm that use lm_sensors
> don't see the device or its sensors.)  The files all seem to be in the same
> place as other devices which work, and I'm running a fairly recent version of
> lm_sensors (3.0.3.)
> 
> Any ideas how to make my device appear to lm_sensors?
> 
> $ ls /sys/class/hwmon/hwmon[45]/device/name
> -r--r--r-- 1 root root 4.0K 2009-10-11 22:55 /sys/class/hwmon/hwmon4/device/name
> -r--r--r-- 1 root root 4.0K 2009-10-11 23:24 /sys/class/hwmon/hwmon5/device/name
> 
> $ cat /sys/class/hwmon/hwmon[45]/device/name
> coretemp
> odin
> 
> $ cat /sys/class/hwmon/hwmon[45]/device/temp1_input
> 50000
> 39000

Looks good so far. What are the underlying device types for your
devices (what does their "subsystem" link point to)? libsensors names
devices uniquely, partly based on the device type. If it doesn't know
the type, it ignores the device. In particular we don't have support
for USB yet... that could be the problem.

It might be difficult to come up with a device numbering convention for
USB devices that will fit in what libsensors expectes, given to the
unlimited nature of USB daisy-chaining. But hopefully we can come up
with something good enough for the most common cases.

-- 
Jean Delvare

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

Re: [lm-sensors] How do you make lm_sensors see a hwmon device?

[Jean Delvare]

On Sun, 11 Oct 2009 16:24:12 +0200, Jean Delvare wrote:
> Hi Adam,
> 
> On Sun, 11 Oct 2009 23:44:43 +1000, Adam Nielsen wrote:
> > I've written a driver for a USB device that has a number of sensors on it
> > (it's a PC power supply with a USB cable for voltage/current monitoring) and
> > the device appears in the hwmon class.
> > 
> > Unfortunately I can't figure out how to make lm_sensors "see" it (when I run
> > "sensors" it isn't displayed, and programs like gkrellm that use lm_sensors
> > don't see the device or its sensors.)  The files all seem to be in the same
> > place as other devices which work, and I'm running a fairly recent version of
> > lm_sensors (3.0.3.)
> > 
> > Any ideas how to make my device appear to lm_sensors?
> > 
> > $ ls /sys/class/hwmon/hwmon[45]/device/name
> > -r--r--r-- 1 root root 4.0K 2009-10-11 22:55 /sys/class/hwmon/hwmon4/device/name
> > -r--r--r-- 1 root root 4.0K 2009-10-11 23:24 /sys/class/hwmon/hwmon5/device/name
> > 
> > $ cat /sys/class/hwmon/hwmon[45]/device/name
> > coretemp
> > odin
> > 
> > $ cat /sys/class/hwmon/hwmon[45]/device/temp1_input
> > 50000
> > 39000
> 
> Looks good so far. What are the underlying device types for your
> devices (what does their "subsystem" link point to)? libsensors names
> devices uniquely, partly based on the device type. If it doesn't know
> the type, it ignores the device. In particular we don't have support
> for USB yet... that could be the problem.
> 
> It might be difficult to come up with a device numbering convention for
> USB devices that will fit in what libsensors expectes, given to the
> unlimited nature of USB daisy-chaining. But hopefully we can come up
> with something good enough for the most common cases.

Oh, please also send the output of: 
$ ls -l /sys/class/hwmon/hwmon*/device
and
$ ls -l /sys/class/hwmon/hwmon[45]/device/

And I am curious about your USB device and what sensors it has. If
these are I2C sensor chips and there's an I2C bus inside the device, it
may make more sense to write a bus drivers for that I2C segment, and
use regular I2C sensor chip drivers on top of it. But of course it
depends whether you have all the needed technical information to do
this or not (if the hardware design allows it at all.)

-- 
Jean Delvare

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

Re: [lm-sensors] How do you make lm_sensors see a hwmon device?

[Adam Nielsen]

>> Looks good so far. What are the underlying device types for your
>> devices (what does their "subsystem" link point to)? libsensors names
>> devices uniquely, partly based on the device type. If it doesn't know
>> the type, it ignores the device. In particular we don't have support
>> for USB yet... that could be the problem.
>>
>> It might be difficult to come up with a device numbering convention for
>> USB devices that will fit in what libsensors expectes, given to the
>> unlimited nature of USB daisy-chaining. But hopefully we can come up
>> with something good enough for the most common cases.

Although the underlying device is USB, the device appears in the relatively
new "hid" class, as it is a standard USB HID device (I imagine so it doesn't
require kernel drivers to be installed under Windows.)

> Oh, please also send the output of: 
> $ ls -l /sys/class/hwmon/hwmon*/device

lrwxrwxrwx 1 root root 0 2009-10-11 22:55 /sys/class/hwmon/hwmon0/device ->
../../../devices/platform/it87.656
lrwxrwxrwx 1 root root 0 2009-10-11 21:28 /sys/class/hwmon/hwmon1/device ->
../../../devices/platform/coretemp.0
lrwxrwxrwx 1 root root 0 2009-10-11 21:28 /sys/class/hwmon/hwmon2/device ->
../../../devices/platform/coretemp.1
lrwxrwxrwx 1 root root 0 2009-10-11 21:28 /sys/class/hwmon/hwmon3/device ->
../../../devices/platform/coretemp.2
lrwxrwxrwx 1 root root 0 2009-10-11 21:28 /sys/class/hwmon/hwmon4/device ->
../../../devices/platform/coretemp.3
lrwxrwxrwx 1 root root 0 2009-10-11 23:40 /sys/class/hwmon/hwmon5/device ->
../../../devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/0003:1044:4001.0012

> and
> $ ls -l /sys/class/hwmon/hwmon[45]/device/

/sys/class/hwmon/hwmon4/device/:
total 0
drwxr-xr-x  3 root root    0 2009-09-30 13:00 .
drwxr-xr-x 15 root root    0 2009-10-08 10:22 ..
lrwxrwxrwx  1 root root    0 2009-10-11 22:55 bus -> ../../../bus/platform
lrwxrwxrwx  1 root root    0 2009-10-11 22:55 driver ->
../../../bus/platform/drivers/coretemp
lrwxrwxrwx  1 root root    0 2009-10-11 23:26 hwmon:hwmon4 ->
../../../class/hwmon/hwmon4
-r--r--r--  1 root root 4.0K 2009-10-11 23:26 modalias
-r--r--r--  1 root root 4.0K 2009-10-11 22:55 name
drwxr-xr-x  2 root root    0 2009-10-11 23:26 power
lrwxrwxrwx  1 root root    0 2009-10-11 22:55 subsystem -> ../../../bus/platform
-r--r--r--  1 root root 4.0K 2009-10-11 22:55 temp1_crit
-r--r--r--  1 root root 4.0K 2009-10-11 22:55 temp1_crit_alarm
-r--r--r--  1 root root 4.0K 2009-09-30 13:00 temp1_input
-r--r--r--  1 root root 4.0K 2009-10-11 22:55 temp1_label
-r--r--r--  1 root root 4.0K 2009-10-11 23:04 temp1_max
-rw-r--r--  1 root root 4.0K 2009-10-11 23:26 uevent

/sys/class/hwmon/hwmon5/device/:
total 0
drwxr-xr-x 3 root root    0 2009-10-11 23:40 .
drwxr-xr-x 4 root root    0 2009-10-11 23:40 ..
lrwxrwxrwx 1 root root    0 2009-10-11 22:55 bus -> ../../../../../../../bus/hid
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr0_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr0_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr1_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr1_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr2_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr2_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr3_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr3_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr4_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr4_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr5_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr5_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr6_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr6_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr7_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 curr7_label
lrwxrwxrwx 1 root root    0 2009-10-12 08:00 driver ->
../../../../../../../bus/hid/drivers/gbt-odin
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 fan1_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 fan1_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 fan2_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 fan2_label
lrwxrwxrwx 1 root root    0 2009-10-12 08:00 hidraw:hidraw4 ->
../../../../../../../class/hidraw/hidraw4
lrwxrwxrwx 1 root root    0 2009-10-12 08:00 hwmon:hwmon5 ->
../../../../../../../class/hwmon/hwmon5
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in0_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in0_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in1_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in1_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in2_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in2_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in3_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in3_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in4_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in4_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in5_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in5_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in6_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in6_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in7_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 in7_label
lrwxrwxrwx 1 root root    0 2009-10-12 08:00 leds:gbt-odin:blue:fan ->
../../../../../../../class/leds/gbt-odin:blue:fan
-r--r--r-- 1 root root 4.0K 2009-10-11 23:40 name
drwxr-xr-x 2 root root    0 2009-10-11 22:56 power
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power0_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power0_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power1_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power1_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power3_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power3_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power4_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power4_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power5_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power5_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power6_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power6_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power8_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 power8_label
lrwxrwxrwx 1 root root    0 2009-10-11 22:55 subsystem ->
../../../../../../../bus/hid
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 temp1_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 temp1_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 temp2_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 temp2_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 temp3_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 temp3_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 temp4_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 temp4_label
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 temp5_input
-r--r--r-- 1 root root 4.0K 2009-10-12 08:00 temp5_label
-rw-r--r-- 1 root root 4.0K 2009-10-11 22:55 uevent

> And I am curious about your USB device and what sensors it has. If
> these are I2C sensor chips and there's an I2C bus inside the device, it
> may make more sense to write a bus drivers for that I2C segment, and
> use regular I2C sensor chip drivers on top of it. But of course it
> depends whether you have all the needed technical information to do
> this or not (if the hardware design allows it at all.)

I am unsure what type of chips are inside the device, but whatever they are
the HID protocol abstracts it away so you never get direct access.
Essentially you send a number to the device and it responds with a few bytes,
to which you apply a formula and obtain the sensor reading.

If it would help I can post a gadgetfs userspace program I wrote to emulate
the device.  When you run this - assuming you have gadgetfs support in your
kernel set up with the "dummy" device - you will see a new USB device appear
on your system which behaves the same as the real device.  You can then load
my driver and it will talk to the "fake" device.  (Just as a bit of background
this proved extremely useful for reverse engineering the device - I was able
to tell my fake device what data to respond with, and using VirtualBox, see
which sensors changed in the manufacturer's Windows program as the fake device
responded with different values.)

Cheers,
Adam.

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

Re: [lm-sensors] How do you make lm_sensors see a hwmon device?

[Jean Delvare]

Hi Adam,

On Mon, 12 Oct 2009 08:32:02 +1000, Adam Nielsen wrote:
> Although the underlying device is USB, the device appears in the relatively
> new "hid" class, as it is a standard USB HID device (I imagine so it doesn't
> require kernel drivers to be installed under Windows.)
> 
> > Oh, please also send the output of: 
> > $ ls -l /sys/class/hwmon/hwmon*/device
> 
> lrwxrwxrwx 1 root root 0 2009-10-11 22:55 /sys/class/hwmon/hwmon0/device ->
> ../../../devices/platform/it87.656
> lrwxrwxrwx 1 root root 0 2009-10-11 21:28 /sys/class/hwmon/hwmon1/device ->
> ../../../devices/platform/coretemp.0
> lrwxrwxrwx 1 root root 0 2009-10-11 21:28 /sys/class/hwmon/hwmon2/device ->
> ../../../devices/platform/coretemp.1
> lrwxrwxrwx 1 root root 0 2009-10-11 21:28 /sys/class/hwmon/hwmon3/device ->
> ../../../devices/platform/coretemp.2
> lrwxrwxrwx 1 root root 0 2009-10-11 21:28 /sys/class/hwmon/hwmon4/device ->
> ../../../devices/platform/coretemp.3
> lrwxrwxrwx 1 root root 0 2009-10-11 23:40 /sys/class/hwmon/hwmon5/device ->
> ../../../devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/0003:1044:4001.0012

Ouch. This bus ID format is pretty nasty. It includes vendor and
product IDs, which really do not belong there. And the last part is an
auto-incremented counter, so it isn't stable.

I've done what I could to make it fit in what libsensors expects, but
this is less than perfect. And I expect this bus ID format to evolve
over time, because I can't be the only one thinking it sucks. So we may
have to update libsensors for future kernels.

For now, can you please send me the output of:
$ ls -l /sys/bus/hid/devices

> > And I am curious about your USB device and what sensors it has. If
> > these are I2C sensor chips and there's an I2C bus inside the device, it
> > may make more sense to write a bus drivers for that I2C segment, and
> > use regular I2C sensor chip drivers on top of it. But of course it
> > depends whether you have all the needed technical information to do
> > this or not (if the hardware design allows it at all.)
> 
> I am unsure what type of chips are inside the device, but whatever they are
> the HID protocol abstracts it away so you never get direct access.
> Essentially you send a number to the device and it responds with a few bytes,
> to which you apply a formula and obtain the sensor reading.

OK, let's handle it as a HID device then. Experimental libsensors patch
at the end of this message, please give it a try and report. I couldn't
test it so there might be some rough edges left.

This power supply unit you're working on seems pretty cool. Is this
something one can buy for his/her PC, or only meant for high end server
racks or something? Care to tell us the brand and model name? I would
love to have a monitorable PSU.

> If it would help I can post a gadgetfs userspace program I wrote to emulate
> the device.  When you run this - assuming you have gadgetfs support in your
> kernel set up with the "dummy" device - you will see a new USB device appear
> on your system which behaves the same as the real device.  You can then load
> my driver and it will talk to the "fake" device.  (Just as a bit of background
> this proved extremely useful for reverse engineering the device - I was able
> to tell my fake device what data to respond with, and using VirtualBox, see
> which sensors changed in the manufacturer's Windows program as the fake device
> responded with different values.)

Yes, please post it together with explanations how to use it. If I can
emulate the device and test my libsensors patches myself, this should
be much faster.

Here's the patch:

Index: lib/sensors.h
=================================--- lib/sensors.h	(révision 5780)
+++ lib/sensors.h	(copie de travail)
@@ -43,6 +43,7 @@
 #define SENSORS_BUS_TYPE_SPI		3
 #define SENSORS_BUS_TYPE_VIRTUAL	4
 #define SENSORS_BUS_TYPE_ACPI		5
+#define SENSORS_BUS_TYPE_HID		6
 #define SENSORS_BUS_NR_ANY		(-1)
 #define SENSORS_BUS_NR_IGNORE		(-2)
 
Index: lib/access.c
=================================--- lib/access.c	(révision 5780)
+++ lib/access.c	(copie de travail)
@@ -363,6 +363,10 @@
 		return "Virtual device";
 	case SENSORS_BUS_TYPE_ACPI:
 		return "ACPI interface";
+	/* HID should probably not be there either, but I don't know if
+	   HID buses have a name nor where to find it. */
+	case SENSORS_BUS_TYPE_HID:
+		return "HID adapter";
 	}
 
 	/* bus types with several instances */
Index: lib/sysfs.c
=================================--- lib/sysfs.c	(révision 5780)
+++ lib/sysfs.c	(copie de travail)
@@ -518,7 +518,7 @@
 				       const char *dev_name,
 				       const char *hwmon_path)
 {
-	int domain, bus, slot, fn;
+	int domain, bus, slot, fn, vendor, product, id;
 	int err = -SENSORS_ERR_KERNEL;
 	char *bus_attr;
 	char bus_path[NAME_MAX];
@@ -612,6 +612,13 @@
 		/* For now we assume that acpi devices are unique */
 		entry.chip.bus.nr = 0;
 		entry.chip.addr = 0;
+	} else
+	if (subsys && !strcmp(subsys, "hid") &&
+	    sscanf(dev_name, "%x:%x:%x.%x", &bus, &vendor, &product, &id) = 4) {
+		entry.chip.bus.type = SENSORS_BUS_TYPE_HID;
+		/* As of kernel 2.6.32, the hid device names don't look good */
+		entry.chip.bus.nr = bus;
+		entry.chip.addr = id;
 	} else {
 		/* Ignore unknown device */
 		err = 0;
Index: lib/data.c
=================================--- lib/data.c	(révision 5780)
+++ lib/data.c	(copie de travail)
@@ -121,6 +121,8 @@
 		res->bus.type = SENSORS_BUS_TYPE_VIRTUAL;
 	else if (!strncmp(name, "acpi", dash - name))
 		res->bus.type = SENSORS_BUS_TYPE_ACPI;
+	else if (!strncmp(name, "hid", dash - name))
+		res->bus.type = SENSORS_BUS_TYPE_HID;
 	else
 		goto ERROR;
 	name = dash + 1;
@@ -131,6 +133,7 @@
 	switch (res->bus.type) {
 	case SENSORS_BUS_TYPE_I2C:
 	case SENSORS_BUS_TYPE_SPI:
+	case SENSORS_BUS_TYPE_HID:
 		if (!strncmp(name, "*-", 2)) {
 			res->bus.nr = SENSORS_BUS_NR_ANY;
 			name += 2;
@@ -187,6 +190,9 @@
 	case SENSORS_BUS_TYPE_ACPI:
 		return snprintf(str, size, "%s-acpi-%x", chip->prefix,
 				chip->addr);
+	case SENSORS_BUS_TYPE_HID:
+		return snprintf(str, size, "%s-hid-%hd-%x", chip->prefix,
+				chip->bus.nr, chip->addr);
 	}
 
 	return -SENSORS_ERR_CHIP_NAME;


-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

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

Re: [lm-sensors] How do you make lm_sensors see a hwmon device?

[Adam Nielsen]

> Ouch. This bus ID format is pretty nasty. It includes vendor and
> product IDs, which really do not belong there. And the last part is an
> auto-incremented counter, so it isn't stable.
> 
> I've done what I could to make it fit in what libsensors expects, but
> this is less than perfect. And I expect this bus ID format to evolve
> over time, because I can't be the only one thinking it sucks. So we may
> have to update libsensors for future kernels.

Well if you need a unique per-device ID (unique if you connect multiple
devices) then the USB bus number and the device ID you have chosen would seem
to be the most appropriate.  If you need a value that is unique across reboots
then I imagine the USB vendor/device ID would be the only option - this device
doesn't seem to have a unique serial number as many USB devices do.

> For now, can you please send me the output of:
> $ ls -l /sys/bus/hid/devices

total 0
drwxr-xr-x 2 root root 0 2009-10-12 22:35 .
drwxr-xr-x 4 root root 0 2009-10-12 22:35 ..
lrwxrwxrwx 1 root root 0 2009-10-12 22:35 0003:046D:C226.0001 ->
../../../devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/0003:046D:C226.0001
lrwxrwxrwx 1 root root 0 2009-10-12 22:35 0003:046D:C226.0002 ->
../../../devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.1/0003:046D:C226.0002
lrwxrwxrwx 1 root root 0 2009-10-12 22:35 0003:046D:C525.0003 ->
../../../devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.2/3-2.2:1.0/0003:046D:C525.0003
lrwxrwxrwx 1 root root 0 2009-10-12 22:35 0003:046D:C525.0004 ->
../../../devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.2/3-2.2:1.1/0003:046D:C525.0004
lrwxrwxrwx 1 root root 0 2009-10-12 22:35 0003:1044:4001.0012 ->
../../../devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/0003:1044:4001.0012

> OK, let's handle it as a HID device then. Experimental libsensors patch
> at the end of this message, please give it a try and report. I couldn't
> test it so there might be some rough edges left.

Ha, it worked perfectly:

$ ./sensors
...
odin-hid-3-12
Adapter: HID adapter
3.3V:        +3.40 V
5V:          +5.14 V
5VSB:        +5.13 V
12V1:       +12.11 V
12V2:       +12.16 V
12V3:       +12.15 V
12V4:       +12.07 V
-12V:       -12.25 V
PSU Fan:    1095 RPM
System Fan:  700 RPM
Internal:    +40.0°C
External 1:   +0.0°C
External 2:   +0.0°C
External 3:   +0.0°C
External 4:   +0.0°C
5V:          27.01 W
12V1:        11.40 W
12V2:        11.68 W
12V3:        16.59 W
12V4:        13.83 W
Total:       91.45 W
5V:          +5.25 A
5VSB:        +1.25 A
12V1:        +0.94 A
12V2:        +0.96 A
12V3:        +1.37 A
12V4:        +1.15 A
-12V:        +0.00 A

> This power supply unit you're working on seems pretty cool. Is this
> something one can buy for his/her PC, or only meant for high end server
> racks or something? Care to tell us the brand and model name? I would
> love to have a monitorable PSU.

Sure, it's a standard ATX power supply, comes in 550W and 800W versions.  Same
USB ID/driver for both.  It's manufactured by Gigabyte, and it's called an
Odin GT.  Manufacturer web page is here:
http://www.gigabyte.com.tw/Products/PowerSupply/Products_Spec.aspx?ProductID$90

If you buy one, be sure to let Gigabyte know you bought it because of the
Linux support - they didn't want to give out any specs because they were
worried it might send them out of business...

>> If it would help I can post a gadgetfs userspace program I wrote to emulate
>> the device.
> 
> Yes, please post it together with explanations how to use it. If I can
> emulate the device and test my libsensors patches myself, this should
> be much faster.

Okay, I'll tidy it up and get it ready.  In order to run it you will need the
following options enabled in your kernel (I have them all as modules):

USB_GADGET (Device drivers, USB support, USB Gadget Support)
USB_GADGET_DUMMY_HCD (USB Gadget Support, USB Peripheral Controller, Dummy HCD)
USB_GADGETFS (USB Gadget Support, USB Gadget Drivers, Gadget Filesystem)

I'll post instructions on what to do once the modules are loaded when I post
the code shortly.

Cheers,
Adam.

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

Re: [lm-sensors] How do you make lm_sensors see a hwmon device?

[Jean Delvare]

Hi Adam,

On Mon, 12 Oct 2009 22:49:17 +1000, Adam Nielsen wrote:
> > Ouch. This bus ID format is pretty nasty. It includes vendor and
> > product IDs, which really do not belong there. And the last part is an
> > auto-incremented counter, so it isn't stable.
> > 
> > I've done what I could to make it fit in what libsensors expects, but
> > this is less than perfect. And I expect this bus ID format to evolve
> > over time, because I can't be the only one thinking it sucks. So we may
> > have to update libsensors for future kernels.
> 
> Well if you need a unique per-device ID (unique if you connect multiple
> devices) then the USB bus number and the device ID you have chosen would seem
> to be the most appropriate.

Yes, that's what we want. Having to find out the parent device would
add some complexity to libsensors, but can certainly be done. OTOH I
guess HID devices aren't all USB-backed, so it might be hard to come up
with naming convention. Unless we give up on HID entirely and go with
odin-usb-something as the name. I admit I'm not sure yet. This device
of yours is really the first or its kind as far as the Linux kernel and
lm-sensors are concerned.

> If you need a value that is unique across reboots
> then I imagine the USB vendor/device ID would be the only option - this device
> doesn't seem to have a unique serial number as many USB devices do.

No, we already know that we can't get this in the real world.

> > For now, can you please send me the output of:
> > $ ls -l /sys/bus/hid/devices
> 
> total 0
> drwxr-xr-x 2 root root 0 2009-10-12 22:35 .
> drwxr-xr-x 4 root root 0 2009-10-12 22:35 ..
> lrwxrwxrwx 1 root root 0 2009-10-12 22:35 0003:046D:C226.0001 ->
> ../../../devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.0/0003:046D:C226.0001
> lrwxrwxrwx 1 root root 0 2009-10-12 22:35 0003:046D:C226.0002 ->
> ../../../devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.1/3-2.1:1.1/0003:046D:C226.0002
> lrwxrwxrwx 1 root root 0 2009-10-12 22:35 0003:046D:C525.0003 ->
> ../../../devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.2/3-2.2:1.0/0003:046D:C525.0003
> lrwxrwxrwx 1 root root 0 2009-10-12 22:35 0003:046D:C525.0004 ->
> ../../../devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2.2/3-2.2:1.1/0003:046D:C525.0004
> lrwxrwxrwx 1 root root 0 2009-10-12 22:35 0003:1044:4001.0012 ->
> ../../../devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/0003:1044:4001.0012

Huu. Ugly.

> > OK, let's handle it as a HID device then. Experimental libsensors patch
> > at the end of this message, please give it a try and report. I couldn't
> > test it so there might be some rough edges left.
> 
> Ha, it worked perfectly:
> 
> $ ./sensors
> ...
> odin-hid-3-12
> Adapter: HID adapter
> 3.3V:        +3.40 V
> 5V:          +5.14 V
> 5VSB:        +5.13 V
> 12V1:       +12.11 V
> 12V2:       +12.16 V
> 12V3:       +12.15 V
> 12V4:       +12.07 V
> -12V:       -12.25 V
> PSU Fan:    1095 RPM
> System Fan:  700 RPM
> Internal:    +40.0°C
> External 1:   +0.0°C
> External 2:   +0.0°C
> External 3:   +0.0°C
> External 4:   +0.0°C
> 5V:          27.01 W
> 12V1:        11.40 W
> 12V2:        11.68 W
> 12V3:        16.59 W
> 12V4:        13.83 W
> Total:       91.45 W
> 5V:          +5.25 A
> 5VSB:        +1.25 A
> 12V1:        +0.94 A
> 12V2:        +0.96 A
> 12V3:        +1.37 A
> 12V4:        +1.15 A
> -12V:        +0.00 A

Hey, very nice :) I'm waiting to see where the HID device names are
going, and then I'll commit the code change.

> > This power supply unit you're working on seems pretty cool. Is this
> > something one can buy for his/her PC, or only meant for high end server
> > racks or something? Care to tell us the brand and model name? I would
> > love to have a monitorable PSU.
> 
> Sure, it's a standard ATX power supply, comes in 550W and 800W versions.  Same
> USB ID/driver for both.  It's manufactured by Gigabyte, and it's called an
> Odin GT.  Manufacturer web page is here:
> http://www.gigabyte.com.tw/Products/PowerSupply/Products_Spec.aspx?ProductID$90

I didn't know Gigabyte had joined the PSU business. So far I haven't
been impressed by their motherboards, I wonder how good their PSUs will
be. Relatively expensive models, but I'm convinced for a long time now
that good PSUs are worth the money.

It's a long time since I last bought a PSU, but I lost one - with the
motherboard it was feeding :( - a few months ago, so I might have to
buy a new one soon. Apparently there have been a number of improvements
in this area lately... "modular" PSUs seems like a very good idea to
me. And passively-cooled PSUs are now at an affordable price, although
I don't know how reliable they are these days. Time for me to read some
articles and reviews...

> If you buy one, be sure to let Gigabyte know you bought it because of the
> Linux support - they didn't want to give out any specs because they were
> worried it might send them out of business...

OK, if I buy it I'll let them know. How much Linux support do you have
at the moment? Just the monitoring shown above, or also control, e.g.
of the fan speed?

I see a huge potential for this type of PSU for the hardware monitoring
support area. We usually have a hard time figuring out wirings and
scaling factors for motherboard sensors. Now if we know what values we
should find, because the PSU is reporting them already, that would be
much easier.

We can also imagine that voltage sensors will disappear from
motherboards in the future. After all, monitoring the PSU voltages
directly makes a lot more sense, and if standardized properly, it could
be done with a single driver and all the scaling / mapping issues would
be solved. Dreaming :) Time will how (and where) it all goes.

> >> If it would help I can post a gadgetfs userspace program I wrote to emulate
> >> the device.
> > 
> > Yes, please post it together with explanations how to use it. If I can
> > emulate the device and test my libsensors patches myself, this should
> > be much faster.
> 
> Okay, I'll tidy it up and get it ready.  In order to run it you will need the
> following options enabled in your kernel (I have them all as modules):
> 
> USB_GADGET (Device drivers, USB support, USB Gadget Support)
> USB_GADGET_DUMMY_HCD (USB Gadget Support, USB Peripheral Controller, Dummy HCD)
> USB_GADGETFS (USB Gadget Support, USB Gadget Drivers, Gadget Filesystem)

Building :)

> I'll post instructions on what to do once the modules are loaded when I post
> the code shortly.

Great, thanks.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

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

Re: [lm-sensors] How do you make lm_sensors see a hwmon device?

[Adam Nielsen]

>> If you need a value that is unique across reboots
>> then I imagine the USB vendor/device ID would be the only option - this device
>> doesn't seem to have a unique serial number as many USB devices do.
> 
> No, we already know that we can't get this in the real world.

How do you mean?  I was thinking along the lines of a new sysfs file that
could hold this value, similar to how the "name" currently holds a value used
by lm_sensors.  Then it would be up to the driver to provide some sort of
consistent ID (although I recall somewhere that IDs must be unique across the
whole system, so perhaps that wouldn't be so manageable.)

> Hey, very nice :) I'm waiting to see where the HID device names are
> going, and then I'll commit the code change.

Great!  Thanks for getting this working so quickly.

> I didn't know Gigabyte had joined the PSU business. So far I haven't
> been impressed by their motherboards, I wonder how good their PSUs will
> be. Relatively expensive models, but I'm convinced for a long time now
> that good PSUs are worth the money.

Well speaking personally I've found Gigabyte hardware in general to be rock
solid...providing you get something that works properly in the first place :-)
 Their devices seem good, but QA could use some work.  So far the PSU is fine,
but it's only been two years - I'll know for sure once it goes past the normal
three year warranty window ;-)

> It's a long time since I last bought a PSU, but I lost one - with the
> motherboard it was feeding :( - a few months ago, so I might have to
> buy a new one soon. Apparently there have been a number of improvements
> in this area lately... "modular" PSUs seems like a very good idea to
> me. And passively-cooled PSUs are now at an affordable price, although
> I don't know how reliable they are these days. Time for me to read some
> articles and reviews...

Modular PSUs are pretty good, and this one is pretty quiet too, even with the
fan.  My hard drives are still the noisiest part of my system.

> OK, if I buy it I'll let them know. How much Linux support do you have
> at the moment? Just the monitoring shown above, or also control, e.g.
> of the fan speed?

At the moment just the monitoring (only started reverse engineering a week ago
though) but I don't recall the fan speed being controllable - I think it's
automatic based on the temperature, and I can't remember if you can change it
(I do recall seeing some graphs in the Windows app that could've been temp vs
fan speed though.)  I do however intend to support everything you can do
through Windows, which includes the ability to adjust the voltages.  I don't
think I'll be testing that too thoroughly though, I like my PC when it's not
on fire :-)

> I see a huge potential for this type of PSU for the hardware monitoring
> support area. We usually have a hard time figuring out wirings and
> scaling factors for motherboard sensors. Now if we know what values we
> should find, because the PSU is reporting them already, that would be
> much easier.

That's a very good point.  One thing I discovered with the gadgetfs driver
though is that the formula used to calculate the current draw is different for
each rail - including the four 12V rails, each uses a different formula.  I
was only able to generate an accurate formula by feeding in very large and
small numbers to the fake device, and watching what the Windows app would
report.  I wouldn't have known this if the values had stayed fairly constant
as they do in normal use.

I imagine it would be a fairly large undertaking, but making a dummy I2C
device available to a guest OS like Windows (perhaps by modifying QEMU for
instance) might yield a similar result - a tweakable interface that lets you
feed in values and compare them with the manufacturer's own Windows application.

> We can also imagine that voltage sensors will disappear from
> motherboards in the future. After all, monitoring the PSU voltages
> directly makes a lot more sense, and if standardized properly, it could
> be done with a single driver and all the scaling / mapping issues would
> be solved. Dreaming :) Time will how (and where) it all goes.

Well actually I had nVidia's ESA pointed out to me the other day, and it seems
like they want to head in this direction too:
http://www.nvidia.com/object/nvidia_esa.html

It looks like they intend to use USB HID devices too, only unlike Gigabyte,
properly.  Like the Power spec for UPS devices, they appear to be defining
some standard sensor elements in part of the HID space that will allow
standard drivers to report on various elements of the system.

Perhaps adding HID bus support to lm_sensors is quite timely...!

Cheers,
Adam.


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

Re: [lm-sensors] How do you make lm_sensors see a hwmon device?

[Jean Delvare]

Hi Adam,

On Mon, 12 Oct 2009 15:36:39 +0200, Jean Delvare wrote:
> On Mon, 12 Oct 2009 22:49:17 +1000, Adam Nielsen wrote:
> > Ha, it worked perfectly:
> > 
> > $ ./sensors
> > ...
> > odin-hid-3-12
> > Adapter: HID adapter
> > 3.3V:        +3.40 V
> > 5V:          +5.14 V
> > 5VSB:        +5.13 V
> > 12V1:       +12.11 V
> > 12V2:       +12.16 V
> > 12V3:       +12.15 V
> > 12V4:       +12.07 V
> > -12V:       -12.25 V
> > PSU Fan:    1095 RPM
> > System Fan:  700 RPM
> > Internal:    +40.0°C
> > External 1:   +0.0°C
> > External 2:   +0.0°C
> > External 3:   +0.0°C
> > External 4:   +0.0°C
> > 5V:          27.01 W
> > 12V1:        11.40 W
> > 12V2:        11.68 W
> > 12V3:        16.59 W
> > 12V4:        13.83 W
> > Total:       91.45 W
> > 5V:          +5.25 A
> > 5VSB:        +1.25 A
> > 12V1:        +0.94 A
> > 12V2:        +0.96 A
> > 12V3:        +1.37 A
> > 12V4:        +1.15 A
> > -12V:        +0.00 A
> 
> Hey, very nice :) I'm waiting to see where the HID device names are
> going, and then I'll commit the code change.

As there doesn't seem to be any change planned in the immediate future,
I've committed my code as is. If the name format changes upstream,
we'll have to update libsensors accordingly.

> > Okay, I'll tidy it up and get it ready.  In order to run it you will need the
> > following options enabled in your kernel (I have them all as modules):
> > 
> > USB_GADGET (Device drivers, USB support, USB Gadget Support)
> > USB_GADGET_DUMMY_HCD (USB Gadget Support, USB Peripheral Controller, Dummy HCD)
> > USB_GADGETFS (USB Gadget Support, USB Gadget Drivers, Gadget Filesystem)
> 
> Building :)
> 
> > I'll post instructions on what to do once the modules are loaded when I post
> > the code shortly.
> 
> Great, thanks.

Unfortunately I can't seem to find the time to test it, sorry.

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

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

Re: [lm-sensors] How do you make lm_sensors see a hwmon device?

[Adam Nielsen]

> As there doesn't seem to be any change planned in the immediate future,
> I've committed my code as is. If the name format changes upstream,
> we'll have to update libsensors accordingly.

No worries, I'll keep an eye on it.  Thanks again for your help getting it
working!

>>> I'll post instructions on what to do once the modules are loaded when I post
>>> the code shortly.
>> Great, thanks.
> 
> Unfortunately I can't seem to find the time to test it, sorry.

No problem, it's there if you ever need to verify your HID code is working
properly.

By the way, if you are still looking at buying a PSU with sensors in it, there
are a few alternatives to the Gigabyte that support nVidia's ESA:
http://www.nvidia.com/object/nvidia_certified_products.html

Of course there is no Linux support that I am aware of as yet, but as ESA is
supposed to be an open standard I wouldn't imagine it would take too long
(still waiting to hear back with specs though.)

Cheers,
Adam.


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