at v2.6.21 400 lines 12 kB view raw
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 6further information. As of writing this document, libsensors 7(from lm_sensors 2.8.3) is heavily chip-dependent. 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-independent 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-independent 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. If you are writing a new hardware monitoring driver those 43features can't seem to fit in this interface, please contact us with your 44extension proposal. Keep in mind that backward compatibility must be 45preserved. 46 47Each chip gets its own directory in the sysfs /sys/devices tree. To 48find all sensor chips, it is easier to follow the device symlinks from 49/sys/class/hwmon/hwmon*. 50 51All sysfs values are fixed point numbers. 52 53There is only one value per file, unlike the older /proc specification. 54The common scheme for files naming is: <type><number>_<item>. Usual 55types for sensor chips are "in" (voltage), "temp" (temperature) and 56"fan" (fan). Usual items are "input" (measured value), "max" (high 57threshold, "min" (low threshold). Numbering usually starts from 1, 58except for voltages which start from 0 (because most data sheets use 59this). A number is always used for elements that can be present more 60than once, even if there is a single element of the given type on the 61specific chip. Other files do not refer to a specific element, so 62they have a simple name, and no number. 63 64Alarms are direct indications read from the chips. The drivers do NOT 65make comparisons of readings to thresholds. This allows violations 66between readings to be caught and alarmed. The exact definition of an 67alarm (for example, whether a threshold must be met or must be exceeded 68to cause an alarm) is chip-dependent. 69 70 71------------------------------------------------------------------------- 72 73[0-*] denotes any positive number starting from 0 74[1-*] denotes any positive number starting from 1 75RO read only value 76RW read/write value 77 78Read/write values may be read-only for some chips, depending on the 79hardware implementation. 80 81All entries are optional, and should only be created in a given driver 82if the chip has the feature. 83 84************ 85* Voltages * 86************ 87 88in[0-*]_min Voltage min value. 89 Unit: millivolt 90 RW 91 92in[0-*]_max Voltage max value. 93 Unit: millivolt 94 RW 95 96in[0-*]_input Voltage input value. 97 Unit: millivolt 98 RO 99 Voltage measured on the chip pin. 100 Actual voltage depends on the scaling resistors on the 101 motherboard, as recommended in the chip datasheet. 102 This varies by chip and by motherboard. 103 Because of this variation, values are generally NOT scaled 104 by the chip driver, and must be done by the application. 105 However, some drivers (notably lm87 and via686a) 106 do scale, because of internal resistors built into a chip. 107 These drivers will output the actual voltage. 108 109 Typical usage: 110 in0_* CPU #1 voltage (not scaled) 111 in1_* CPU #2 voltage (not scaled) 112 in2_* 3.3V nominal (not scaled) 113 in3_* 5.0V nominal (scaled) 114 in4_* 12.0V nominal (scaled) 115 in5_* -12.0V nominal (scaled) 116 in6_* -5.0V nominal (scaled) 117 in7_* varies 118 in8_* varies 119 120cpu[0-*]_vid CPU core reference voltage. 121 Unit: millivolt 122 RO 123 Not always correct. 124 125vrm Voltage Regulator Module version number. 126 RW (but changing it should no more be necessary) 127 Originally the VRM standard version multiplied by 10, but now 128 an arbitrary number, as not all standards have a version 129 number. 130 Affects the way the driver calculates the CPU core reference 131 voltage from the vid pins. 132 133Also see the Alarms section for status flags associated with voltages. 134 135 136******** 137* Fans * 138******** 139 140fan[1-*]_min Fan minimum value 141 Unit: revolution/min (RPM) 142 RW 143 144fan[1-*]_input Fan input value. 145 Unit: revolution/min (RPM) 146 RO 147 148fan[1-*]_div Fan divisor. 149 Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128). 150 RW 151 Some chips only support values 1, 2, 4 and 8. 152 Note that this is actually an internal clock divisor, which 153 affects the measurable speed range, not the read value. 154 155Also see the Alarms section for status flags associated with fans. 156 157 158******* 159* PWM * 160******* 161 162pwm[1-*] Pulse width modulation fan control. 163 Integer value in the range 0 to 255 164 RW 165 255 is max or 100%. 166 167pwm[1-*]_enable 168 Switch PWM on and off. 169 Not always present even if pwmN is. 170 0: turn off 171 1: turn on in manual mode 172 2+: turn on in automatic mode 173 Check individual chip documentation files for automatic mode 174 details. 175 RW 176 177pwm[1-*]_mode 0: DC mode (direct current) 178 1: PWM mode (pulse-width modulation) 179 RW 180 181pwm[1-*]_freq Base PWM frequency in Hz. 182 Only possibly available when pwmN_mode is PWM, but not always 183 present even then. 184 RW 185 186pwm[1-*]_auto_channels_temp 187 Select which temperature channels affect this PWM output in 188 auto mode. Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc... 189 Which values are possible depend on the chip used. 190 RW 191 192pwm[1-*]_auto_point[1-*]_pwm 193pwm[1-*]_auto_point[1-*]_temp 194pwm[1-*]_auto_point[1-*]_temp_hyst 195 Define the PWM vs temperature curve. Number of trip points is 196 chip-dependent. Use this for chips which associate trip points 197 to PWM output channels. 198 RW 199 200OR 201 202temp[1-*]_auto_point[1-*]_pwm 203temp[1-*]_auto_point[1-*]_temp 204temp[1-*]_auto_point[1-*]_temp_hyst 205 Define the PWM vs temperature curve. Number of trip points is 206 chip-dependent. Use this for chips which associate trip points 207 to temperature channels. 208 RW 209 210 211**************** 212* Temperatures * 213**************** 214 215temp[1-*]_type Sensor type selection. 216 Integers 1 to 6 or thermistor Beta value (typically 3435) 217 RW 218 1: PII/Celeron Diode 219 2: 3904 transistor 220 3: thermal diode 221 4: thermistor (default/unknown Beta) 222 5: AMD AMDSI 223 6: Intel PECI 224 Not all types are supported by all chips 225 226temp[1-*]_max Temperature max value. 227 Unit: millidegree Celsius (or millivolt, see below) 228 RW 229 230temp[1-*]_min Temperature min value. 231 Unit: millidegree Celsius 232 RW 233 234temp[1-*]_max_hyst 235 Temperature hysteresis value for max limit. 236 Unit: millidegree Celsius 237 Must be reported as an absolute temperature, NOT a delta 238 from the max value. 239 RW 240 241temp[1-*]_input Temperature input value. 242 Unit: millidegree Celsius 243 RO 244 245temp[1-*]_crit Temperature critical value, typically greater than 246 corresponding temp_max values. 247 Unit: millidegree Celsius 248 RW 249 250temp[1-*]_crit_hyst 251 Temperature hysteresis value for critical limit. 252 Unit: millidegree Celsius 253 Must be reported as an absolute temperature, NOT a delta 254 from the critical value. 255 RW 256 257temp[1-4]_offset 258 Temperature offset which is added to the temperature reading 259 by the chip. 260 Unit: millidegree Celsius 261 Read/Write value. 262 263 If there are multiple temperature sensors, temp1_* is 264 generally the sensor inside the chip itself, 265 reported as "motherboard temperature". temp2_* to 266 temp4_* are generally sensors external to the chip 267 itself, for example the thermal diode inside the CPU or 268 a thermistor nearby. 269 270Some chips measure temperature using external thermistors and an ADC, and 271report the temperature measurement as a voltage. Converting this voltage 272back to a temperature (or the other way around for limits) requires 273mathematical functions not available in the kernel, so the conversion 274must occur in user space. For these chips, all temp* files described 275above should contain values expressed in millivolt instead of millidegree 276Celsius. In other words, such temperature channels are handled as voltage 277channels by the driver. 278 279Also see the Alarms section for status flags associated with temperatures. 280 281 282************ 283* Currents * 284************ 285 286Note that no known chip provides current measurements as of writing, 287so this part is theoretical, so to say. 288 289curr[1-*]_max Current max value 290 Unit: milliampere 291 RW 292 293curr[1-*]_min Current min value. 294 Unit: milliampere 295 RW 296 297curr[1-*]_input Current input value 298 Unit: milliampere 299 RO 300 301 302********** 303* Alarms * 304********** 305 306Each channel or limit may have an associated alarm file, containing a 307boolean value. 1 means than an alarm condition exists, 0 means no alarm. 308 309Usually a given chip will either use channel-related alarms, or 310limit-related alarms, not both. The driver should just reflect the hardware 311implementation. 312 313in[0-*]_alarm 314fan[1-*]_alarm 315temp[1-*]_alarm 316 Channel alarm 317 0: no alarm 318 1: alarm 319 RO 320 321OR 322 323in[0-*]_min_alarm 324in[0-*]_max_alarm 325fan[1-*]_min_alarm 326temp[1-*]_min_alarm 327temp[1-*]_max_alarm 328temp[1-*]_crit_alarm 329 Limit alarm 330 0: no alarm 331 1: alarm 332 RO 333 334Each input channel may have an associated fault file. This can be used 335to notify open diodes, unconnected fans etc. where the hardware 336supports it. When this boolean has value 1, the measurement for that 337channel should not be trusted. 338 339in[0-*]_input_fault 340fan[1-*]_input_fault 341temp[1-*]_input_fault 342 Input fault condition 343 0: no fault occured 344 1: fault condition 345 RO 346 347Some chips also offer the possibility to get beeped when an alarm occurs: 348 349beep_enable Master beep enable 350 0: no beeps 351 1: beeps 352 RW 353 354in[0-*]_beep 355fan[1-*]_beep 356temp[1-*]_beep 357 Channel beep 358 0: disable 359 1: enable 360 RW 361 362In theory, a chip could provide per-limit beep masking, but no such chip 363was seen so far. 364 365Old drivers provided a different, non-standard interface to alarms and 366beeps. These interface files are deprecated, but will be kept around 367for compatibility reasons: 368 369alarms Alarm bitmask. 370 RO 371 Integer representation of one to four bytes. 372 A '1' bit means an alarm. 373 Chips should be programmed for 'comparator' mode so that 374 the alarm will 'come back' after you read the register 375 if it is still valid. 376 Generally a direct representation of a chip's internal 377 alarm registers; there is no standard for the position 378 of individual bits. For this reason, the use of this 379 interface file for new drivers is discouraged. Use 380 individual *_alarm and *_fault files instead. 381 Bits are defined in kernel/include/sensors.h. 382 383beep_mask Bitmask for beep. 384 Same format as 'alarms' with the same bit locations, 385 use discouraged for the same reason. Use individual 386 *_beep files instead. 387 RW 388 389 390********* 391* Other * 392********* 393 394eeprom Raw EEPROM data in binary form. 395 RO 396 397pec Enable or disable PEC (SMBus only) 398 0: disable 399 1: enable 400 RW