1 Naming and data format standards for sysfs files
2 ================================================
4 The libsensors library offers an interface to the raw sensors data
5 through the sysfs interface. Since lm-sensors 3.0.0, libsensors is
6 completely chip-independent. It assumes that all the kernel drivers
7 implement the standard sysfs interface described in this document.
8 This makes adding or updating support for any given chip very easy, as
9 libsensors, and applications using it, do not need to be modified.
10 This is a major improvement compared to lm-sensors 2.
12 Note that motherboards vary widely in the connections to sensor chips.
13 There is no standard that ensures, for example, that the second
14 temperature sensor is connected to the CPU, or that the second fan is on
15 the CPU. Also, some values reported by the chips need some computation
16 before they make full sense. For example, most chips can only measure
17 voltages between 0 and +4V. Other voltages are scaled back into that
18 range using external resistors. Since the values of these resistors
19 can change from motherboard to motherboard, the conversions cannot be
20 hard coded into the driver and have to be done in user space.
22 For this reason, even if we aim at a chip-independent libsensors, it will
23 still require a configuration file (e.g. /etc/sensors.conf) for proper
24 values conversion, labeling of inputs and hiding of unused inputs.
26 An alternative method that some programs use is to access the sysfs
27 files directly. This document briefly describes the standards that the
28 drivers follow, so that an application program can scan for entries and
29 access this data in a simple and consistent way. That said, such programs
30 will have to implement conversion, labeling and hiding of inputs. For
31 this reason, it is still not recommended to bypass the library.
33 Each chip gets its own directory in the sysfs /sys/devices tree. To
34 find all sensor chips, it is easier to follow the device symlinks from
35 `/sys/class/hwmon/hwmon*`.
37 Up to lm-sensors 3.0.0, libsensors looks for hardware monitoring attributes
38 in the "physical" device directory. Since lm-sensors 3.0.1, attributes found
39 in the hwmon "class" device directory are also supported. Complex drivers
40 (e.g. drivers for multifunction chips) may want to use this possibility to
41 avoid namespace pollution. The only drawback will be that older versions of
42 libsensors won't support the driver in question.
44 All sysfs values are fixed point numbers.
46 There is only one value per file, unlike the older /proc specification.
47 The common scheme for files naming is: <type><number>_<item>. Usual
48 types for sensor chips are "in" (voltage), "temp" (temperature) and
49 "fan" (fan). Usual items are "input" (measured value), "max" (high
50 threshold, "min" (low threshold). Numbering usually starts from 1,
51 except for voltages which start from 0 (because most data sheets use
52 this). A number is always used for elements that can be present more
53 than once, even if there is a single element of the given type on the
54 specific chip. Other files do not refer to a specific element, so
55 they have a simple name, and no number.
57 Alarms are direct indications read from the chips. The drivers do NOT
58 make comparisons of readings to thresholds. This allows violations
59 between readings to be caught and alarmed. The exact definition of an
60 alarm (for example, whether a threshold must be met or must be exceeded
61 to cause an alarm) is chip-dependent.
63 When setting values of hwmon sysfs attributes, the string representation of
64 the desired value must be written, note that strings which are not a number
65 are interpreted as 0! For more on how written strings are interpreted see the
66 "sysfs attribute writes interpretation" section at the end of this file.
68 -------------------------------------------------------------------------
70 ======= ===========================================
71 `[0-*]` denotes any positive number starting from 0
72 `[1-*]` denotes any positive number starting from 1
76 ======= ===========================================
78 Read/write values may be read-only for some chips, depending on the
79 hardware implementation.
81 All entries (except name) are optional, and should only be created in a
82 given driver if the chip has the feature.
91 This should be a short, lowercase string, not containing
92 whitespace, dashes, or the wildcard character '*'.
93 This attribute represents the chip name. It is the only
95 I2C devices get this attribute created automatically.
100 The interval at which the chip will update readings.
105 Some devices have a variable update rate or interval.
106 This attribute can be used to change it to the desired value.
121 Voltage critical min value.
127 If voltage drops to or below this limit, the system may
128 take drastic action such as power down or reset. At the very
129 least, it should report a fault.
139 Voltage critical max value.
145 If voltage reaches or exceeds this limit, the system may
146 take drastic action such as power down or reset. At the very
147 least, it should report a fault.
156 Voltage measured on the chip pin.
158 Actual voltage depends on the scaling resistors on the
159 motherboard, as recommended in the chip datasheet.
161 This varies by chip and by motherboard.
162 Because of this variation, values are generally NOT scaled
163 by the chip driver, and must be done by the application.
164 However, some drivers (notably lm87 and via686a)
165 do scale, because of internal resistors built into a chip.
166 These drivers will output the actual voltage. Rule of
167 thumb: drivers should report the voltage values at the
178 Historical minimum voltage
185 Historical maximum voltage
191 `in[0-*]_reset_history`
192 Reset inX_lowest and inX_highest
197 Reset inX_lowest and inX_highest for all sensors
202 Suggested voltage channel label.
206 Should only be created if the driver has hints about what
207 this voltage channel is being used for, and user-space
208 doesn't. In all other cases, the label is provided by
214 Enable or disable the sensors.
216 When disabled the sensor read will return -ENODATA.
224 CPU core reference voltage.
233 Voltage Regulator Module version number.
235 RW (but changing it should no more be necessary)
237 Originally the VRM standard version multiplied by 10, but now
238 an arbitrary number, as not all standards have a version
241 Affects the way the driver calculates the CPU core reference
242 voltage from the vid pins.
245 Minimum rated voltage.
252 Maximum rated voltage.
258 Also see the Alarms section for status flags associated with voltages.
268 Unit: revolution/min (RPM)
275 Unit: revolution/min (RPM)
277 Only rarely supported by the hardware.
283 Unit: revolution/min (RPM)
290 Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128).
294 Some chips only support values 1, 2, 4 and 8.
295 Note that this is actually an internal clock divisor, which
296 affects the measurable speed range, not the read value.
299 Number of tachometer pulses per fan revolution.
301 Integer value, typically between 1 and 4.
305 This value is a characteristic of the fan connected to the
306 device's input, so it has to be set in accordance with the fan
309 Should only be created if the chip has a register to configure
310 the number of pulses. In the absence of such a register (and
311 thus attribute) the value assumed by all devices is 2 pulses
317 Unit: revolution/min (RPM)
321 Only makes sense if the chip supports closed-loop fan speed
322 control based on the measured fan speed.
325 Suggested fan channel label.
329 Should only be created if the driver has hints about what
330 this fan channel is being used for, and user-space doesn't.
331 In all other cases, the label is provided by user-space.
336 Enable or disable the sensors.
338 When disabled the sensor read will return -ENODATA.
345 Also see the Alarms section for status flags associated with fans.
353 Pulse width modulation fan control.
355 Integer value in the range 0 to 255
362 Fan speed control method:
364 - 0: no fan speed control (i.e. fan at full speed)
365 - 1: manual fan speed control enabled (using `pwm[1-*]`)
366 - 2+: automatic fan speed control enabled
368 Check individual chip documentation files for automatic mode
374 - 0: DC mode (direct current)
375 - 1: PWM mode (pulse-width modulation)
380 Base PWM frequency in Hz.
382 Only possibly available when pwmN_mode is PWM, but not always
387 `pwm[1-*]_auto_channels_temp`
388 Select which temperature channels affect this PWM output in
391 Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc...
392 Which values are possible depend on the chip used.
396 `pwm[1-*]_auto_point[1-*]_pwm` / `pwm[1-*]_auto_point[1-*]_temp` / `pwm[1-*]_auto_point[1-*]_temp_hyst`
397 Define the PWM vs temperature curve.
399 Number of trip points is chip-dependent. Use this for chips
400 which associate trip points to PWM output channels.
404 `temp[1-*]_auto_point[1-*]_pwm` / `temp[1-*]_auto_point[1-*]_temp` / `temp[1-*]_auto_point[1-*]_temp_hyst`
405 Define the PWM vs temperature curve.
407 Number of trip points is chip-dependent. Use this for chips
408 which associate trip points to temperature channels.
412 There is a third case where trip points are associated to both PWM output
413 channels and temperature channels: the PWM values are associated to PWM
414 output channels while the temperature values are associated to temperature
415 channels. In that case, the result is determined by the mapping between
416 temperature inputs and PWM outputs. When several temperature inputs are
417 mapped to a given PWM output, this leads to several candidate PWM values.
418 The actual result is up to the chip, but in general the highest candidate
419 value (fastest fan speed) wins.
427 Sensor type selection.
433 - 1: CPU embedded diode
440 Not all types are supported by all chips
443 Temperature max value.
445 Unit: millidegree Celsius (or millivolt, see below)
450 Temperature min value.
452 Unit: millidegree Celsius
457 Temperature hysteresis value for max limit.
459 Unit: millidegree Celsius
461 Must be reported as an absolute temperature, NOT a delta
467 Temperature hysteresis value for min limit.
468 Unit: millidegree Celsius
470 Must be reported as an absolute temperature, NOT a delta
476 Temperature input value.
478 Unit: millidegree Celsius
483 Temperature critical max value, typically greater than
484 corresponding temp_max values.
486 Unit: millidegree Celsius
490 `temp[1-*]_crit_hyst`
491 Temperature hysteresis value for critical limit.
493 Unit: millidegree Celsius
495 Must be reported as an absolute temperature, NOT a delta
496 from the critical value.
500 `temp[1-*]_emergency`
501 Temperature emergency max value, for chips supporting more than
502 two upper temperature limits. Must be equal or greater than
503 corresponding temp_crit values.
505 Unit: millidegree Celsius
509 `temp[1-*]_emergency_hyst`
510 Temperature hysteresis value for emergency limit.
512 Unit: millidegree Celsius
514 Must be reported as an absolute temperature, NOT a delta
515 from the emergency value.
520 Temperature critical min value, typically lower than
521 corresponding temp_min values.
523 Unit: millidegree Celsius
527 `temp[1-*]_lcrit_hyst`
528 Temperature hysteresis value for critical min limit.
530 Unit: millidegree Celsius
532 Must be reported as an absolute temperature, NOT a delta
533 from the critical min value.
538 Temperature offset which is added to the temperature reading
541 Unit: millidegree Celsius
546 Suggested temperature channel label.
550 Should only be created if the driver has hints about what
551 this temperature channel is being used for, and user-space
552 doesn't. In all other cases, the label is provided by
558 Historical minimum temperature
560 Unit: millidegree Celsius
565 Historical maximum temperature
567 Unit: millidegree Celsius
571 `temp[1-*]_reset_history`
572 Reset temp_lowest and temp_highest
577 Reset temp_lowest and temp_highest for all sensors
582 Enable or disable the sensors.
584 When disabled the sensor read will return -ENODATA.
591 `temp[1-*]_rated_min`
592 Minimum rated temperature.
594 Unit: millidegree Celsius
598 `temp[1-*]_rated_max`
599 Maximum rated temperature.
601 Unit: millidegree Celsius
605 Some chips measure temperature using external thermistors and an ADC, and
606 report the temperature measurement as a voltage. Converting this voltage
607 back to a temperature (or the other way around for limits) requires
608 mathematical functions not available in the kernel, so the conversion
609 must occur in user space. For these chips, all temp* files described
610 above should contain values expressed in millivolt instead of millidegree
611 Celsius. In other words, such temperature channels are handled as voltage
612 channels by the driver.
614 Also see the Alarms section for status flags associated with temperatures.
636 Current critical low value
643 Current critical high value.
664 Historical minimum current
671 Historical maximum current
675 `curr[1-*]_reset_history`
676 Reset currX_lowest and currX_highest
681 Reset currX_lowest and currX_highest for all sensors
686 Enable or disable the sensors.
688 When disabled the sensor read will return -ENODATA.
695 `curr[1-*]_rated_min`
696 Minimum rated current.
702 `curr[1-*]_rated_max`
703 Maximum rated current.
709 Also see the Alarms section for status flags associated with currents.
722 `power[1-*]_average_interval`
723 Power use averaging interval. A poll
724 notification is sent to this file if the
725 hardware changes the averaging interval.
731 `power[1-*]_average_interval_max`
732 Maximum power use averaging interval
738 `power[1-*]_average_interval_min`
739 Minimum power use averaging interval
745 `power[1-*]_average_highest`
746 Historical average maximum power use
752 `power[1-*]_average_lowest`
753 Historical average minimum power use
759 `power[1-*]_average_max`
760 A poll notification is sent to
761 `power[1-*]_average` when power use
762 rises above this value.
768 `power[1-*]_average_min`
769 A poll notification is sent to
770 `power[1-*]_average` when power use
771 sinks below this value.
778 Instantaneous power use
784 `power[1-*]_input_highest`
785 Historical maximum power use
791 `power[1-*]_input_lowest`
792 Historical minimum power use
798 `power[1-*]_reset_history`
799 Reset input_highest, input_lowest,
800 average_highest and average_lowest.
804 `power[1-*]_accuracy`
805 Accuracy of the power meter.
812 If power use rises above this limit, the
813 system should take action to reduce power use.
814 A poll notification is sent to this file if the
815 cap is changed by the hardware. The `*_cap`
816 files only appear if the cap is known to be
817 enforced by hardware.
823 `power[1-*]_cap_hyst`
824 Margin of hysteresis built around capping and
832 Maximum cap that can be set.
839 Minimum cap that can be set.
853 Critical maximum power.
855 If power rises to or above this limit, the
856 system is expected take drastic action to reduce
857 power consumption, such as a system shutdown or
858 a forced powerdown of some devices.
865 Enable or disable the sensors.
867 When disabled the sensor read will return
875 `power[1-*]_rated_min`
882 `power[1-*]_rated_max`
889 Also see the Alarms section for status flags associated with power readings.
896 Cumulative energy use
903 Enable or disable the sensors.
905 When disabled the sensor read will return
917 `humidity[1-*]_input`
920 Unit: milli-percent (per cent mille, pcm)
925 `humidity[1-*]_enable`
926 Enable or disable the sensors
928 When disabled the sensor read will return
936 `humidity[1-*]_rated_min`
937 Minimum rated humidity.
939 Unit: milli-percent (per cent mille, pcm)
943 `humidity[1-*]_rated_max`
944 Maximum rated humidity.
946 Unit: milli-percent (per cent mille, pcm)
954 Each channel or limit may have an associated alarm file, containing a
955 boolean value. 1 means than an alarm condition exists, 0 means no alarm.
957 Usually a given chip will either use channel-related alarms, or
958 limit-related alarms, not both. The driver should just reflect the hardware
961 +-------------------------------+-----------------------+
962 | **`in[0-*]_alarm`, | Channel alarm |
963 | `curr[1-*]_alarm`, | |
964 | `power[1-*]_alarm`, | - 0: no alarm |
965 | `fan[1-*]_alarm`, | - 1: alarm |
966 | `temp[1-*]_alarm`** | |
968 +-------------------------------+-----------------------+
972 +-------------------------------+-----------------------+
973 | **`in[0-*]_min_alarm`, | Limit alarm |
974 | `in[0-*]_max_alarm`, | |
975 | `in[0-*]_lcrit_alarm`, | - 0: no alarm |
976 | `in[0-*]_crit_alarm`, | - 1: alarm |
977 | `curr[1-*]_min_alarm`, | |
978 | `curr[1-*]_max_alarm`, | RO |
979 | `curr[1-*]_lcrit_alarm`, | |
980 | `curr[1-*]_crit_alarm`, | |
981 | `power[1-*]_cap_alarm`, | |
982 | `power[1-*]_max_alarm`, | |
983 | `power[1-*]_crit_alarm`, | |
984 | `fan[1-*]_min_alarm`, | |
985 | `fan[1-*]_max_alarm`, | |
986 | `temp[1-*]_min_alarm`, | |
987 | `temp[1-*]_max_alarm`, | |
988 | `temp[1-*]_lcrit_alarm`, | |
989 | `temp[1-*]_crit_alarm`, | |
990 | `temp[1-*]_emergency_alarm`** | |
991 +-------------------------------+-----------------------+
993 Each input channel may have an associated fault file. This can be used
994 to notify open diodes, unconnected fans etc. where the hardware
995 supports it. When this boolean has value 1, the measurement for that
996 channel should not be trusted.
998 `fan[1-*]_fault` / `temp[1-*]_fault`
999 Input fault condition
1001 - 0: no fault occurred
1002 - 1: fault condition
1006 Some chips also offer the possibility to get beeped when an alarm occurs:
1016 `in[0-*]_beep`, `curr[1-*]_beep`, `fan[1-*]_beep`, `temp[1-*]_beep`,
1024 In theory, a chip could provide per-limit beep masking, but no such chip
1027 Old drivers provided a different, non-standard interface to alarms and
1028 beeps. These interface files are deprecated, but will be kept around
1029 for compatibility reasons:
1036 Integer representation of one to four bytes.
1038 A '1' bit means an alarm.
1040 Chips should be programmed for 'comparator' mode so that
1041 the alarm will 'come back' after you read the register
1042 if it is still valid.
1044 Generally a direct representation of a chip's internal
1045 alarm registers; there is no standard for the position
1046 of individual bits. For this reason, the use of this
1047 interface file for new drivers is discouraged. Use
1048 `individual *_alarm` and `*_fault` files instead.
1049 Bits are defined in kernel/include/sensors.h.
1053 Same format as 'alarms' with the same bit locations,
1054 use discouraged for the same reason. Use individual
1055 `*_beep` files instead.
1063 `intrusion[0-*]_alarm`
1064 Chassis intrusion detection
1067 - 1: intrusion detected
1071 Contrary to regular alarm flags which clear themselves
1072 automatically when read, this one sticks until cleared by
1073 the user. This is done by writing 0 to the file. Writing
1074 other values is unsupported.
1076 `intrusion[0-*]_beep`
1077 Chassis intrusion beep
1084 ****************************
1085 Average sample configuration
1086 ****************************
1088 Devices allowing for reading {in,power,curr,temp}_average values may export
1089 attributes for controlling number of samples used to compute average.
1091 +--------------+---------------------------------------------------------------+
1092 | samples | Sets number of average samples for all types of measurements. |
1095 +--------------+---------------------------------------------------------------+
1096 | in_samples | Sets number of average samples for specific type of |
1097 | power_samples| measurements. |
1099 | temp_samples | Note that on some devices it won't be possible to set all of |
1100 | | them to different values so changing one might also change |
1104 +--------------+---------------------------------------------------------------+
1106 sysfs attribute writes interpretation
1107 -------------------------------------
1109 hwmon sysfs attributes always contain numbers, so the first thing to do is to
1110 convert the input to a number, there are 2 ways todo this depending whether
1111 the number can be negative or not::
1113 unsigned long u = simple_strtoul(buf, NULL, 10);
1114 long s = simple_strtol(buf, NULL, 10);
1116 With buf being the buffer with the user input being passed by the kernel.
1117 Notice that we do not use the second argument of strto[u]l, and thus cannot
1118 tell when 0 is returned, if this was really 0 or is caused by invalid input.
1119 This is done deliberately as checking this everywhere would add a lot of
1122 Notice that it is important to always store the converted value in an
1123 unsigned long or long, so that no wrap around can happen before any further
1126 After the input string is converted to an (unsigned) long, the value should be
1127 checked if its acceptable. Be careful with further conversions on the value
1128 before checking it for validity, as these conversions could still cause a wrap
1129 around before the check. For example do not multiply the result, and only
1130 add/subtract if it has been divided before the add/subtract.
1132 What to do if a value is found to be invalid, depends on the type of the
1133 sysfs attribute that is being set. If it is a continuous setting like a
1134 tempX_max or inX_max attribute, then the value should be clamped to its
1135 limits using clamp_val(value, min_limit, max_limit). If it is not continuous
1136 like for example a tempX_type, then when an invalid value is written,
1137 -EINVAL should be returned.
1139 Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees)::
1141 long v = simple_strtol(buf, NULL, 10) / 1000;
1142 v = clamp_val(v, -128, 127);
1143 /* write v to register */
1145 Example2, fan divider setting, valid values 2, 4 and 8::
1147 unsigned long v = simple_strtoul(buf, NULL, 10);
1150 case 2: v = 1; break;
1151 case 4: v = 2; break;
1152 case 8: v = 3; break;
1156 /* write v to register */