[PATCH 2.6] I2C sysfs interface documentation

[PATCH 2.6] I2C sysfs interface documentation

[Jean Delvare]

> > --- linux-2.6.0-test9/Documentation/i2c/sysfs-interface
> > +++ linux-2.6.0-test9/Documentation/i2c/sysfs-interface.lm83
> 
> 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.

--- linux-2.6.0-test9/Documentation/i2c/sysfs-interface.orig	Sun Nov 16 19:51:12 2003
+++ linux-2.6.0-test9/Documentation/i2c/sysfs-interface	Sun Nov 16 19:57:41 2003
@@ -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.
 


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

[PATCH 2.6] I2C sysfs interface documentation

[Mark Studebaker]

Jean Delvare wrote:
> 
>
> 
> 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...

[PATCH 2.6] I2C sysfs interface documentation

[Jean Delvare]

> 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/

[PATCH 2.6] I2C sysfs interface documentation

[Mark Studebaker]

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).



Jean Delvare wrote:
> 
> > 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/

[PATCH 2.6] I2C sysfs interface documentation

[Greg KH]

On Sun, Nov 16, 2003 at 08:32:50PM +0100, Jean Delvare wrote:
> 
> > > --- linux-2.6.0-test9/Documentation/i2c/sysfs-interface
> > > +++ linux-2.6.0-test9/Documentation/i2c/sysfs-interface.lm83
> > 
> > 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.

Applied, thanks.

greg k-h