Skip to contentSkip to conversation

I2C sysfs interface documentation

PATCH New Jean Delvare 3 participants 5 messages May 19, 2005 I2C

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 I2C sysfs interface documentation

Quoted 5 lines

Documentation/i2c/sysfs-interface.lm83

Quoted 3 lines
Documentation/i2c/sysfs-interface.lm83 renamed from Documentation/i2c/sysfs-interface +0 -0

Should I still apply this patch?

Actually, no, don't apply it. The new patch to sysfs-interface (below) includes it. I did it that way because both sets of changes modify a common part of the file and the second patch might have been rejected because of that.

Summary of what the patch does:
1* No more current hysteresis value. I don't think we ever saw a chip
which monitors current, and if we ever do, I would be very, very surprised if it would have an hysteresis value.
2* Temperature input and max can have 4 values. [from the previous
patch]
3* Split temperature min and hysteresis into two separate files. 4* New file temp_crit. [from previous patch]

The new file temp_crit is subject to change later as we decide more precisely how we want to handle values that are common to more than one temperature channels.

A patch to chipset drivers follows.

Documentation/i2c/sysfs-interface renamed from Documentation/i2c/sysfs-interface.orig +22 -11
@@ -68,9 +68,7 @@
 		Fixed point XXXXX, divide by 1000 to get Amps.
 		Read/Write.
 
-curr_min[1-n]	Current min or hysteresis value.
-		Preferably a hysteresis value, reported as a absolute
-		current, NOT a delta from the max value.
+curr_min[1-n]	Current min value.
 		Fixed point XXXXX, divide by 1000 to get Amps.
 		Read/Write.
 
@@ -144,25 +142,38 @@
 		Integers 1,2,3, or thermistor Beta value (3435)
 		Read/Write.
 
-temp_max[1-3]	Temperature max value.
+temp_max[1-4]	Temperature max value.
 		Fixed point value in form XXXXX and should be divided by
 		1000 to get degrees Celsius.
 		Read/Write value.
 
-temp_min[1-3]	Temperature min or hysteresis value.
+temp_min[1-3]	Temperature min value.
 		Fixed point value in form XXXXX and should be divided by
-		1000 to get degrees Celsius.  This is preferably a
-		hysteresis value, reported as a absolute temperature,
-		NOT a delta from the max value.
+		1000 to get degrees Celsius.
 		Read/Write value.
 
-temp_input[1-3] Temperature input value.
+temp_hyst[1-3]	Temperature hysteresis value.
+		Fixed point value in form XXXXX and should be divided by
+		1000 to get degrees Celsius.  Must be reported as an
+		absolute temperature, NOT a delta from the max value.
+		Read/Write value.
+
+temp_input[1-4] Temperature input value.
+		Fixed point value in form XXXXX and should be divided by
+		1000 to get degrees Celsius.
 		Read only value.
 
+temp_crit	Temperature critical value, typically greater than all
+		temp_max values.
+		Fixed point value in form XXXXX and should be divided by
+		1000 to get degrees Celsius.
+		Common to all temperature channels.
+		Read/Write value.
+
 		If there are multiple temperature sensors, temp_*1 is
 		generally the sensor inside the chip itself, generally
-		reported as "motherboard temperature".  temp_*2 and
-		temp_*3 are generally sensors external to the chip
+		reported as "motherboard temperature".  temp_*2 to
+		temp_*4 are generally sensors external to the chip
 		itself, for example the thermal diode inside the CPU or
 		a thermistor nearby.
 
Signature · 2 lines
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
#1 lore raw

PATCH 1/1 I2C sysfs interface documentation

Quoted 4 lines

current is in there because the IPMI spec includes current sensors so I added support to bmcsensors.
Never had a report of a BMC that actually measures current, though...

Took a look at that document, it specifies hysteresis values for all sensor types. It even specifies two values (one for negative-going thresholds, one for positive-going thresholds).

BMC isn't in 2.6 yet anyway, so we can safely remove references to current hysteresis for now.

That quick look at the IPMI specification once again raised the question of what file naming convention to choose for storing hysteresis values in sysfs. The fact that IPMI provides space for two hysteresis values per sensor proves that names like "temp_hyst1" (as I did in the patch I just sent to Greg) won't be sufficent to handle all cases. I'm still in favor of storing hysteresis as a values linked to another limit, and not as a limit per se. That is, temp_max1 and temp_max1_hyst (or temp_max_hyst1, or even temp_hyst_max1, whatever fits better with the current logic). Following Mark Hoffman's views, value in these files would be an absolute temperature, regardless of how the chipset actually handles it.

I would like everyone to comment on that if needed. If we can agree on a clean, logic naming convention, I volunteer to update the documentation accordingly and modify existing drivers.

Signature · 2 lines
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
#2 lore raw

PATCH 1/1 I2C sysfs interface documentation

In reply to Jean Delvare
Quoted 7 lines · Jean Delvare

Summary of what the patch does:
1* No more current hysteresis value. I don't think we ever saw a chip
which monitors current, and if we ever do, I would be very, very surprised if it would have an hysteresis value.

current is in there because the IPMI spec includes current sensors so I added support to bmcsensors.
Never had a report of a BMC that actually measures current, though...

#3 lore raw

PATCH 1/1 I2C sysfs interface documentation

In reply to Jean Delvare

If you do want to go all the way, IPMI supports 8 limits per sensor. Critical, non-critical, non-recoverable, and hysteresis, each for both high and low.

I suppose IPMI is a good guideline for the ultimate in possibilities, should you wish to refer to it in the sysfs design. Although I think a sophisticated BMC manager would access the BMC directly rather than through /proc or /sys.
So don't be overly concerned with /sys limiting the IPMI information.

What I do in bmcsensors is pick the best two of those 8 and present them to the user.

IPMI defines hysteresis as a delta from the limit. I subtract one from the other and present that through /proc as absolute values. I think we should continue to do that
(i.e. I agree with Mark Hoffman).

Quoted 31 lines · Jean Delvare
Quoted 4 lines

current is in there because the IPMI spec includes current sensors so I added support to bmcsensors.
Never had a report of a BMC that actually measures current, though...

Took a look at that document, it specifies hysteresis values for all sensor types. It even specifies two values (one for negative-going thresholds, one for positive-going thresholds).

BMC isn't in 2.6 yet anyway, so we can safely remove references to current hysteresis for now.

That quick look at the IPMI specification once again raised the question of what file naming convention to choose for storing hysteresis values in sysfs. The fact that IPMI provides space for two hysteresis values per sensor proves that names like "temp_hyst1" (as I did in the patch I just sent to Greg) won't be sufficent to handle all cases. I'm still in favor of storing hysteresis as a values linked to another limit, and not as a limit per se. That is, temp_max1 and temp_max1_hyst (or temp_max_hyst1, or even temp_hyst_max1, whatever fits better with the current logic). Following Mark Hoffman's views, value in these files would be an absolute temperature, regardless of how the chipset actually handles it.

I would like everyone to comment on that if needed. If we can agree on a clean, logic naming convention, I volunteer to update the documentation accordingly and modify existing drivers.

--
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Applied
#4 lore raw

PATCH 1/1 I2C sysfs interface documentation

In reply to Jean Delvare
Quoted 20 lines · Jean Delvare
Quoted 5 lines

Documentation/i2c/sysfs-interface.lm83

Quoted 3 lines
Documentation/i2c/sysfs-interface.lm83 renamed from Documentation/i2c/sysfs-interface +0 -0

Should I still apply this patch?

Actually, no, don't apply it. The new patch to sysfs-interface (below) includes it. I did it that way because both sets of changes modify a common part of the file and the second patch might have been rejected because of that.

Summary of what the patch does:
1* No more current hysteresis value. I don't think we ever saw a chip
which monitors current, and if we ever do, I would be very, very surprised if it would have an hysteresis value.
2* Temperature input and max can have 4 values. [from the previous
patch]
3* Split temperature min and hysteresis into two separate files. 4* New file temp_crit. [from previous patch]

Quoted 5 lines

The new file temp_crit is subject to change later as we decide more precisely how we want to handle values that are common to more than one temperature channels.

A patch to chipset drivers follows.

Applied, thanks.

greg k-h