sysfs-interface

linux 内核源代码

		6: Intel PECI
		Not all types are supported by all chips

temp[1-*]_max	Temperature max value.
		Unit: millidegree Celsius (or millivolt, see below)
		RW

temp[1-*]_min	Temperature min value.
		Unit: millidegree Celsius
		RW

temp[1-*]_max_hyst
		Temperature hysteresis value for max limit.
		Unit: millidegree Celsius
		Must be reported as an absolute temperature, NOT a delta
		from the max value.
		RW

temp[1-*]_input Temperature input value.
		Unit: millidegree Celsius
		RO

temp[1-*]_crit	Temperature critical value, typically greater than
		corresponding temp_max values.
		Unit: millidegree Celsius
		RW

temp[1-*]_crit_hyst
		Temperature hysteresis value for critical limit.
		Unit: millidegree Celsius
		Must be reported as an absolute temperature, NOT a delta
		from the critical value.
		RW

temp[1-*]_offset
		Temperature offset which is added to the temperature reading
		by the chip.
		Unit: millidegree Celsius
		Read/Write value.

temp[1-*]_label	Suggested temperature channel label.
		Text string
		Should only be created if the driver has hints about what
		this temperature channel is being used for, and user-space
		doesn't. In all other cases, the label is provided by
		user-space.
		RO

Some chips measure temperature using external thermistors and an ADC, and
report the temperature measurement as a voltage. Converting this voltage
back to a temperature (or the other way around for limits) requires
mathematical functions not available in the kernel, so the conversion
must occur in user space. For these chips, all temp* files described
above should contain values expressed in millivolt instead of millidegree
Celsius. In other words, such temperature channels are handled as voltage
channels by the driver.

Also see the Alarms section for status flags associated with temperatures.


************
* Currents *
************

Note that no known chip provides current measurements as of writing,
so this part is theoretical, so to say.

curr[1-*]_max	Current max value
		Unit: milliampere
		RW

curr[1-*]_min	Current min value.
		Unit: milliampere
		RW

curr[1-*]_input	Current input value
		Unit: milliampere
		RO

*********
* Power *
*********

power[1-*]_average		Average power use
				Unit: microWatt
				RO

power[1-*]_average_highest	Historical average maximum power use
				Unit: microWatt
				RO

power[1-*]_average_lowest	Historical average minimum power use
				Unit: microWatt
				RO

power[1-*]_input		Instantaneous power use
				Unit: microWatt
				RO

power[1-*]_input_highest	Historical maximum power use
				Unit: microWatt
				RO

power[1-*]_input_lowest		Historical minimum power use
				Unit: microWatt
				RO

power[1-*]_reset_history	Reset input_highest, input_lowest,
				average_highest and average_lowest.
				WO

**********
* Alarms *
**********

Each channel or limit may have an associated alarm file, containing a
boolean value. 1 means than an alarm condition exists, 0 means no alarm.

Usually a given chip will either use channel-related alarms, or
limit-related alarms, not both. The driver should just reflect the hardware
implementation.

in[0-*]_alarm
fan[1-*]_alarm
temp[1-*]_alarm
		Channel alarm
		0: no alarm
		1: alarm
		RO

OR

in[0-*]_min_alarm
in[0-*]_max_alarm
fan[1-*]_min_alarm
temp[1-*]_min_alarm
temp[1-*]_max_alarm
temp[1-*]_crit_alarm
		Limit alarm
		0: no alarm
		1: alarm
		RO

Each input channel may have an associated fault file. This can be used
to notify open diodes, unconnected fans etc. where the hardware
supports it. When this boolean has value 1, the measurement for that
channel should not be trusted.

in[0-*]_fault
fan[1-*]_fault
temp[1-*]_fault
		Input fault condition
		0: no fault occured
		1: fault condition
		RO

Some chips also offer the possibility to get beeped when an alarm occurs:

beep_enable	Master beep enable
		0: no beeps
		1: beeps
		RW

in[0-*]_beep
fan[1-*]_beep
temp[1-*]_beep
		Channel beep
		0: disable
		1: enable
		RW

In theory, a chip could provide per-limit beep masking, but no such chip
was seen so far.

Old drivers provided a different, non-standard interface to alarms and
beeps. These interface files are deprecated, but will be kept around
for compatibility reasons:

alarms		Alarm bitmask.
		RO
		Integer representation of one to four bytes.
		A '1' bit means an alarm.
		Chips should be programmed for 'comparator' mode so that
		the alarm will 'come back' after you read the register
		if it is still valid.
		Generally a direct representation of a chip's internal
		alarm registers; there is no standard for the position
		of individual bits. For this reason, the use of this
		interface file for new drivers is discouraged. Use
		individual *_alarm and *_fault files instead.
		Bits are defined in kernel/include/sensors.h.

beep_mask	Bitmask for beep.
		Same format as 'alarms' with the same bit locations,
		use discouraged for the same reason. Use individual
		*_beep files instead.
		RW


sysfs attribute writes interpretation
-------------------------------------

hwmon sysfs attributes always contain numbers, so the first thing to do is to
convert the input to a number, there are 2 ways todo this depending whether
the number can be negative or not:
unsigned long u = simple_strtoul(buf, NULL, 10);
long s = simple_strtol(buf, NULL, 10);

With buf being the buffer with the user input being passed by the kernel.
Notice that we do not use the second argument of strto[u]l, and thus cannot
tell when 0 is returned, if this was really 0 or is caused by invalid input.
This is done deliberately as checking this everywhere would add a lot of
code to the kernel.

Notice that it is important to always store the converted value in an
unsigned long or long, so that no wrap around can happen before any further
checking.

After the input string is converted to an (unsigned) long, the value should be
checked if its acceptable. Be careful with further conversions on the value
before checking it for validity, as these conversions could still cause a wrap
around before the check. For example do not multiply the result, and only
add/subtract if it has been divided before the add/subtract.

What to do if a value is found to be invalid, depends on the type of the
sysfs attribute that is being set. If it is a continuous setting like a
tempX_max or inX_max attribute, then the value should be clamped to its
limits using SENSORS_LIMIT(value, min_limit, max_limit). If it is not
continuous like for example a tempX_type, then when an invalid value is
written, -EINVAL should be returned.

Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees):

	long v = simple_strtol(buf, NULL, 10) / 1000;
	v = SENSORS_LIMIT(v, -128, 127);
	/* write v to register */

Example2, fan divider setting, valid values 2, 4 and 8:

	unsigned long v = simple_strtoul(buf, NULL, 10);

	switch (v) {
	case 2: v = 1; break;
	case 4: v = 2; break;
	case 8: v = 3; break;
	default:
		return -EINVAL;
	}
	/* write v to register */