]> bbs.cooldavid.org Git - net-next-2.6.git/blame - Documentation/hwmon/sysfs-interface
[PATCH] hwmon: Sysfs interface documentation update, 1 of 2
[net-next-2.6.git] / Documentation / hwmon / sysfs-interface
CommitLineData
1da177e4
LT
1Naming and data format standards for sysfs files
2------------------------------------------------
3
4The libsensors library offers an interface to the raw sensors data
5through the sysfs interface. See libsensors documentation and source for
6more further information. As of writing this document, libsensors
7(from lm_sensors 2.8.3) is heavily chip-dependant. Adding or updating
8support for any given chip requires modifying the library's code.
9This is because libsensors was written for the procfs interface
10older kernel modules were using, which wasn't standardized enough.
11Recent versions of libsensors (from lm_sensors 2.8.2 and later) have
12support for the sysfs interface, though.
13
14The new sysfs interface was designed to be as chip-independant as
15possible.
16
17Note that motherboards vary widely in the connections to sensor chips.
18There is no standard that ensures, for example, that the second
19temperature sensor is connected to the CPU, or that the second fan is on
20the CPU. Also, some values reported by the chips need some computation
21before they make full sense. For example, most chips can only measure
22voltages between 0 and +4V. Other voltages are scaled back into that
23range using external resistors. Since the values of these resistors
24can change from motherboard to motherboard, the conversions cannot be
25hard coded into the driver and have to be done in user space.
26
27For this reason, even if we aim at a chip-independant libsensors, it will
28still require a configuration file (e.g. /etc/sensors.conf) for proper
29values conversion, labeling of inputs and hiding of unused inputs.
30
31An alternative method that some programs use is to access the sysfs
32files directly. This document briefly describes the standards that the
33drivers follow, so that an application program can scan for entries and
34access this data in a simple and consistent way. That said, such programs
35will have to implement conversion, labeling and hiding of inputs. For
36this reason, it is still not recommended to bypass the library.
37
38If you are developing a userspace application please send us feedback on
39this standard.
40
41Note that this standard isn't completely established yet, so it is subject
42to changes, even important ones. One more reason to use the library instead
43of accessing sysfs files directly.
44
45Each chip gets its own directory in the sysfs /sys/devices tree. To
46find all sensor chips, it is easier to follow the symlinks from
47/sys/i2c/devices/
48
49All sysfs values are fixed point numbers. To get the true value of some
50of the values, you should divide by the specified value.
51
52There is only one value per file, unlike the older /proc specification.
53The common scheme for files naming is: <type><number>_<item>. Usual
54types for sensor chips are "in" (voltage), "temp" (temperature) and
55"fan" (fan). Usual items are "input" (measured value), "max" (high
56threshold, "min" (low threshold). Numbering usually starts from 1,
57except for voltages which start from 0 (because most data sheets use
58this). A number is always used for elements that can be present more
59than once, even if there is a single element of the given type on the
60specific chip. Other files do not refer to a specific element, so
61they have a simple name, and no number.
62
63Alarms are direct indications read from the chips. The drivers do NOT
64make comparisons of readings to thresholds. This allows violations
65between readings to be caught and alarmed. The exact definition of an
66alarm (for example, whether a threshold must be met or must be exceeded
67to cause an alarm) is chip-dependent.
68
69
70-------------------------------------------------------------------------
71
057bc350
RM
72[0-*] denotes any positive number starting from 0
73[1-*] denotes any positive number starting from 1
74RO read only value
75RW read/write value
76
77Read/write values may be read-only for some chips, depending on the
78hardware implementation.
79
1da177e4
LT
80************
81* Voltages *
82************
83
057bc350 84in[0-*]_min Voltage min value.
1da177e4 85 Unit: millivolt
057bc350 86 RW
1da177e4 87
057bc350 88in[0-*]_max Voltage max value.
1da177e4 89 Unit: millivolt
057bc350 90 RW
1da177e4 91
057bc350 92in[0-*]_input Voltage input value.
1da177e4 93 Unit: millivolt
057bc350
RM
94 RO
95 Voltage measured on the chip pin.
1da177e4
LT
96 Actual voltage depends on the scaling resistors on the
97 motherboard, as recommended in the chip datasheet.
98 This varies by chip and by motherboard.
99 Because of this variation, values are generally NOT scaled
100 by the chip driver, and must be done by the application.
101 However, some drivers (notably lm87 and via686a)
057bc350 102 do scale, because of internal resistors built into a chip.
1da177e4
LT
103 These drivers will output the actual voltage.
104
105 Typical usage:
106 in0_* CPU #1 voltage (not scaled)
107 in1_* CPU #2 voltage (not scaled)
108 in2_* 3.3V nominal (not scaled)
109 in3_* 5.0V nominal (scaled)
110 in4_* 12.0V nominal (scaled)
111 in5_* -12.0V nominal (scaled)
112 in6_* -5.0V nominal (scaled)
113 in7_* varies
114 in8_* varies
115
057bc350 116cpu[0-*]_vid CPU core reference voltage.
1da177e4 117 Unit: millivolt
057bc350 118 RO
1da177e4
LT
119 Not always correct.
120
121vrm Voltage Regulator Module version number.
057bc350
RM
122 RW (but changing it should no more be necessary)
123 Originally the VRM standard version multiplied by 10, but now
124 an arbitrary number, as not all standards have a version
125 number.
1da177e4
LT
126 Affects the way the driver calculates the CPU core reference
127 voltage from the vid pins.
128
057bc350
RM
129Also see the Alarms section for status flags associated with voltages.
130
1da177e4
LT
131
132********
133* Fans *
134********
135
057bc350 136fan[1-*]_min Fan minimum value
1da177e4 137 Unit: revolution/min (RPM)
057bc350 138 RW
1da177e4 139
057bc350 140fan[1-*]_input Fan input value.
1da177e4 141 Unit: revolution/min (RPM)
057bc350 142 RO
1da177e4 143
057bc350 144fan[1-*]_div Fan divisor.
1da177e4 145 Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128).
057bc350 146 RW
1da177e4
LT
147 Some chips only support values 1, 2, 4 and 8.
148 Note that this is actually an internal clock divisor, which
149 affects the measurable speed range, not the read value.
150
057bc350
RM
151Also see the Alarms section for status flags associated with fans.
152
153
1da177e4
LT
154*******
155* PWM *
156*******
157
057bc350 158pwm[1-*] Pulse width modulation fan control.
1da177e4 159 Integer value in the range 0 to 255
057bc350 160 RW
1da177e4
LT
161 255 is max or 100%.
162
057bc350 163pwm[1-*]_enable
1da177e4
LT
164 Switch PWM on and off.
165 Not always present even if fan*_pwm is.
057bc350
RM
166 0: turn off
167 1: turn on in manual mode
168 2+: turn on in automatic mode
169 Check individual chip documentation files for automatic mode details.
170 RW
171
172pwm[1-*]_mode
173 0: DC mode
174 1: PWM mode
175 RW
1da177e4
LT
176
177pwm[1-*]_auto_channels_temp
178 Select which temperature channels affect this PWM output in
179 auto mode. Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc...
180 Which values are possible depend on the chip used.
057bc350 181 RW
1da177e4
LT
182
183pwm[1-*]_auto_point[1-*]_pwm
184pwm[1-*]_auto_point[1-*]_temp
185pwm[1-*]_auto_point[1-*]_temp_hyst
186 Define the PWM vs temperature curve. Number of trip points is
187 chip-dependent. Use this for chips which associate trip points
188 to PWM output channels.
057bc350 189 RW
1da177e4
LT
190
191OR
192
193temp[1-*]_auto_point[1-*]_pwm
194temp[1-*]_auto_point[1-*]_temp
195temp[1-*]_auto_point[1-*]_temp_hyst
196 Define the PWM vs temperature curve. Number of trip points is
197 chip-dependent. Use this for chips which associate trip points
198 to temperature channels.
057bc350 199 RW
1da177e4
LT
200
201
202****************
203* Temperatures *
204****************
205
057bc350 206temp[1-*]_type Sensor type selection.
e53004e2 207 Integers 1 to 4 or thermistor Beta value (typically 3435)
057bc350 208 RW
1da177e4
LT
209 1: PII/Celeron Diode
210 2: 3904 transistor
211 3: thermal diode
e53004e2 212 4: thermistor (default/unknown Beta)
1da177e4
LT
213 Not all types are supported by all chips
214
057bc350 215temp[1-*]_max Temperature max value.
1da177e4 216 Unit: millidegree Celcius
057bc350 217 RW
1da177e4 218
057bc350 219temp[1-*]_min Temperature min value.
1da177e4 220 Unit: millidegree Celcius
057bc350 221 RW
1da177e4 222
057bc350 223temp[1-*]_max_hyst
1da177e4
LT
224 Temperature hysteresis value for max limit.
225 Unit: millidegree Celcius
226 Must be reported as an absolute temperature, NOT a delta
227 from the max value.
057bc350 228 RW
1da177e4 229
057bc350 230temp[1-*]_input Temperature input value.
1da177e4 231 Unit: millidegree Celcius
057bc350 232 RO
1da177e4 233
057bc350 234temp[1-*]_crit Temperature critical value, typically greater than
1da177e4
LT
235 corresponding temp_max values.
236 Unit: millidegree Celcius
057bc350 237 RW
1da177e4 238
057bc350 239temp[1-*]_crit_hyst
1da177e4
LT
240 Temperature hysteresis value for critical limit.
241 Unit: millidegree Celcius
242 Must be reported as an absolute temperature, NOT a delta
243 from the critical value.
057bc350 244 RW
1da177e4 245
59ac8367
HR
246temp[1-4]_offset
247 Temperature offset which is added to the temperature reading
248 by the chip.
249 Unit: millidegree Celsius
250 Read/Write value.
251
1da177e4
LT
252 If there are multiple temperature sensors, temp1_* is
253 generally the sensor inside the chip itself,
254 reported as "motherboard temperature". temp2_* to
255 temp4_* are generally sensors external to the chip
256 itself, for example the thermal diode inside the CPU or
257 a thermistor nearby.
258
057bc350
RM
259Also see the Alarms section for status flags associated with temperatures.
260
1da177e4
LT
261
262************
263* Currents *
264************
265
266Note that no known chip provides current measurements as of writing,
267so this part is theoretical, so to say.
268
057bc350 269curr[1-*]_max Current max value
1da177e4 270 Unit: milliampere
057bc350 271 RW
1da177e4 272
057bc350 273curr[1-*]_min Current min value.
1da177e4 274 Unit: milliampere
057bc350 275 RW
1da177e4 276
057bc350 277curr[1-*]_input Current input value
1da177e4 278 Unit: milliampere
057bc350 279 RO
1da177e4
LT
280
281
400b48ec
JD
282**********
283* Alarms *
284**********
285
286Each channel or limit may have an associated alarm file, containing a
287boolean value. 1 means than an alarm condition exists, 0 means no alarm.
288
289Usually a given chip will either use channel-related alarms, or
290limit-related alarms, not both. The driver should just reflect the hardware
291implementation.
292
057bc350
RM
293in[0-*]_alarm
294fan[1-*]_alarm
295temp[1-*]_alarm
400b48ec 296 Channel alarm
057bc350
RM
297 0: no alarm
298 1: alarm
299 RO
400b48ec
JD
300
301OR
302
057bc350
RM
303in[0-*]_min_alarm
304in[0-*]_max_alarm
305fan[1-*]_min_alarm
306temp[1-*]_min_alarm
307temp[1-*]_max_alarm
308temp[1-*]_crit_alarm
400b48ec 309 Limit alarm
057bc350
RM
310 0: no alarm
311 1: alarm
312 RO
400b48ec
JD
313
314Each input channel may have an associated fault file. This can be used
315to notify open diodes, unconnected fans etc. where the hardware
316supports it. When this boolean has value 1, the measurement for that
317channel should not be trusted.
318
057bc350
RM
319in[0-*]_input_fault
320fan[1-*]_input_fault
321temp[1-*]_input_fault
400b48ec 322 Input fault condition
057bc350
RM
323 0: no fault occured
324 1: fault condition
325 RO
400b48ec
JD
326
327Some chips also offer the possibility to get beeped when an alarm occurs:
328
329beep_enable Master beep enable
057bc350
RM
330 0: no beeps
331 1: beeps
332 RW
400b48ec 333
057bc350
RM
334in[0-*]_beep
335fan[1-*]_beep
336temp[1-*]_beep
400b48ec 337 Channel beep
057bc350
RM
338 0: disable
339 1: enable
340 RW
400b48ec
JD
341
342In theory, a chip could provide per-limit beep masking, but no such chip
343was seen so far.
344
345Old drivers provided a different, non-standard interface to alarms and
346beeps. These interface files are deprecated, but will be kept around
347for compatibility reasons:
1da177e4
LT
348
349alarms Alarm bitmask.
057bc350 350 RO
1da177e4
LT
351 Integer representation of one to four bytes.
352 A '1' bit means an alarm.
353 Chips should be programmed for 'comparator' mode so that
354 the alarm will 'come back' after you read the register
355 if it is still valid.
356 Generally a direct representation of a chip's internal
357 alarm registers; there is no standard for the position
400b48ec
JD
358 of individual bits. For this reason, the use of this
359 interface file for new drivers is discouraged. Use
360 individual *_alarm and *_fault files instead.
1da177e4
LT
361 Bits are defined in kernel/include/sensors.h.
362
1da177e4 363beep_mask Bitmask for beep.
400b48ec
JD
364 Same format as 'alarms' with the same bit locations,
365 use discouraged for the same reason. Use individual
366 *_beep files instead.
057bc350 367 RW
1da177e4 368
400b48ec
JD
369
370*********
371* Other *
372*********
373
1da177e4 374eeprom Raw EEPROM data in binary form.
057bc350 375 RO
c3df5806
JD
376
377pec Enable or disable PEC (SMBus only)
057bc350
RM
378 0: disable
379 1: enable
380 RW