| 1 | Naming and data format standards for sysfs files |
| 2 | ------------------------------------------------ |
| 3 | |
| 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. |
| 11 | |
| 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. |
| 21 | |
| 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. |
| 25 | |
| 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. |
| 32 | |
| 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*. |
| 36 | |
| 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. |
| 43 | |
| 44 | All sysfs values are fixed point numbers. |
| 45 | |
| 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. |
| 56 | |
| 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. |
| 62 | |
| 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. |
| 67 | |
| 68 | ------------------------------------------------------------------------- |
| 69 | |
| 70 | [0-*] denotes any positive number starting from 0 |
| 71 | [1-*] denotes any positive number starting from 1 |
| 72 | RO read only value |
| 73 | WO write only value |
| 74 | RW read/write value |
| 75 | |
| 76 | Read/write values may be read-only for some chips, depending on the |
| 77 | hardware implementation. |
| 78 | |
| 79 | All entries (except name) are optional, and should only be created in a |
| 80 | given driver if the chip has the feature. |
| 81 | |
| 82 | |
| 83 | ********************* |
| 84 | * Global attributes * |
| 85 | ********************* |
| 86 | |
| 87 | name The chip name. |
| 88 | This should be a short, lowercase string, not containing |
| 89 | spaces nor dashes, representing the chip name. This is |
| 90 | the only mandatory attribute. |
| 91 | I2C devices get this attribute created automatically. |
| 92 | RO |
| 93 | |
| 94 | update_rate The rate at which the chip will update readings. |
| 95 | Unit: millisecond |
| 96 | RW |
| 97 | Some devices have a variable update rate. This attribute |
| 98 | can be used to change the update rate to the desired |
| 99 | frequency. |
| 100 | |
| 101 | |
| 102 | ************ |
| 103 | * Voltages * |
| 104 | ************ |
| 105 | |
| 106 | in[0-*]_min Voltage min value. |
| 107 | Unit: millivolt |
| 108 | RW |
| 109 | |
| 110 | in[0-*]_max Voltage max value. |
| 111 | Unit: millivolt |
| 112 | RW |
| 113 | |
| 114 | in[0-*]_input Voltage input value. |
| 115 | Unit: millivolt |
| 116 | RO |
| 117 | Voltage measured on the chip pin. |
| 118 | Actual voltage depends on the scaling resistors on the |
| 119 | motherboard, as recommended in the chip datasheet. |
| 120 | This varies by chip and by motherboard. |
| 121 | Because of this variation, values are generally NOT scaled |
| 122 | by the chip driver, and must be done by the application. |
| 123 | However, some drivers (notably lm87 and via686a) |
| 124 | do scale, because of internal resistors built into a chip. |
| 125 | These drivers will output the actual voltage. Rule of |
| 126 | thumb: drivers should report the voltage values at the |
| 127 | "pins" of the chip. |
| 128 | |
| 129 | in[0-*]_label Suggested voltage channel label. |
| 130 | Text string |
| 131 | Should only be created if the driver has hints about what |
| 132 | this voltage channel is being used for, and user-space |
| 133 | doesn't. In all other cases, the label is provided by |
| 134 | user-space. |
| 135 | RO |
| 136 | |
| 137 | cpu[0-*]_vid CPU core reference voltage. |
| 138 | Unit: millivolt |
| 139 | RO |
| 140 | Not always correct. |
| 141 | |
| 142 | vrm Voltage Regulator Module version number. |
| 143 | RW (but changing it should no more be necessary) |
| 144 | Originally the VRM standard version multiplied by 10, but now |
| 145 | an arbitrary number, as not all standards have a version |
| 146 | number. |
| 147 | Affects the way the driver calculates the CPU core reference |
| 148 | voltage from the vid pins. |
| 149 | |
| 150 | Also see the Alarms section for status flags associated with voltages. |
| 151 | |
| 152 | |
| 153 | ******** |
| 154 | * Fans * |
| 155 | ******** |
| 156 | |
| 157 | fan[1-*]_min Fan minimum value |
| 158 | Unit: revolution/min (RPM) |
| 159 | RW |
| 160 | |
| 161 | fan[1-*]_max Fan maximum value |
| 162 | Unit: revolution/min (RPM) |
| 163 | Only rarely supported by the hardware. |
| 164 | RW |
| 165 | |
| 166 | fan[1-*]_input Fan input value. |
| 167 | Unit: revolution/min (RPM) |
| 168 | RO |
| 169 | |
| 170 | fan[1-*]_div Fan divisor. |
| 171 | Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128). |
| 172 | RW |
| 173 | Some chips only support values 1, 2, 4 and 8. |
| 174 | Note that this is actually an internal clock divisor, which |
| 175 | affects the measurable speed range, not the read value. |
| 176 | |
| 177 | fan[1-*]_target |
| 178 | Desired fan speed |
| 179 | Unit: revolution/min (RPM) |
| 180 | RW |
| 181 | Only makes sense if the chip supports closed-loop fan speed |
| 182 | control based on the measured fan speed. |
| 183 | |
| 184 | fan[1-*]_label Suggested fan channel label. |
| 185 | Text string |
| 186 | Should only be created if the driver has hints about what |
| 187 | this fan channel is being used for, and user-space doesn't. |
| 188 | In all other cases, the label is provided by user-space. |
| 189 | RO |
| 190 | |
| 191 | Also see the Alarms section for status flags associated with fans. |
| 192 | |
| 193 | |
| 194 | ******* |
| 195 | * PWM * |
| 196 | ******* |
| 197 | |
| 198 | pwm[1-*] Pulse width modulation fan control. |
| 199 | Integer value in the range 0 to 255 |
| 200 | RW |
| 201 | 255 is max or 100%. |
| 202 | |
| 203 | pwm[1-*]_enable |
| 204 | Fan speed control method: |
| 205 | 0: no fan speed control (i.e. fan at full speed) |
| 206 | 1: manual fan speed control enabled (using pwm[1-*]) |
| 207 | 2+: automatic fan speed control enabled |
| 208 | Check individual chip documentation files for automatic mode |
| 209 | details. |
| 210 | RW |
| 211 | |
| 212 | pwm[1-*]_mode 0: DC mode (direct current) |
| 213 | 1: PWM mode (pulse-width modulation) |
| 214 | RW |
| 215 | |
| 216 | pwm[1-*]_freq Base PWM frequency in Hz. |
| 217 | Only possibly available when pwmN_mode is PWM, but not always |
| 218 | present even then. |
| 219 | RW |
| 220 | |
| 221 | pwm[1-*]_auto_channels_temp |
| 222 | Select which temperature channels affect this PWM output in |
| 223 | auto mode. Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc... |
| 224 | Which values are possible depend on the chip used. |
| 225 | RW |
| 226 | |
| 227 | pwm[1-*]_auto_point[1-*]_pwm |
| 228 | pwm[1-*]_auto_point[1-*]_temp |
| 229 | pwm[1-*]_auto_point[1-*]_temp_hyst |
| 230 | Define the PWM vs temperature curve. Number of trip points is |
| 231 | chip-dependent. Use this for chips which associate trip points |
| 232 | to PWM output channels. |
| 233 | RW |
| 234 | |
| 235 | temp[1-*]_auto_point[1-*]_pwm |
| 236 | temp[1-*]_auto_point[1-*]_temp |
| 237 | temp[1-*]_auto_point[1-*]_temp_hyst |
| 238 | Define the PWM vs temperature curve. Number of trip points is |
| 239 | chip-dependent. Use this for chips which associate trip points |
| 240 | to temperature channels. |
| 241 | RW |
| 242 | |
| 243 | There is a third case where trip points are associated to both PWM output |
| 244 | channels and temperature channels: the PWM values are associated to PWM |
| 245 | output channels while the temperature values are associated to temperature |
| 246 | channels. In that case, the result is determined by the mapping between |
| 247 | temperature inputs and PWM outputs. When several temperature inputs are |
| 248 | mapped to a given PWM output, this leads to several candidate PWM values. |
| 249 | The actual result is up to the chip, but in general the highest candidate |
| 250 | value (fastest fan speed) wins. |
| 251 | |
| 252 | |
| 253 | **************** |
| 254 | * Temperatures * |
| 255 | **************** |
| 256 | |
| 257 | temp[1-*]_type Sensor type selection. |
| 258 | Integers 1 to 6 |
| 259 | RW |
| 260 | 1: PII/Celeron Diode |
| 261 | 2: 3904 transistor |
| 262 | 3: thermal diode |
| 263 | 4: thermistor |
| 264 | 5: AMD AMDSI |
| 265 | 6: Intel PECI |
| 266 | Not all types are supported by all chips |
| 267 | |
| 268 | temp[1-*]_max Temperature max value. |
| 269 | Unit: millidegree Celsius (or millivolt, see below) |
| 270 | RW |
| 271 | |
| 272 | temp[1-*]_min Temperature min value. |
| 273 | Unit: millidegree Celsius |
| 274 | RW |
| 275 | |
| 276 | temp[1-*]_max_hyst |
| 277 | Temperature hysteresis value for max limit. |
| 278 | Unit: millidegree Celsius |
| 279 | Must be reported as an absolute temperature, NOT a delta |
| 280 | from the max value. |
| 281 | RW |
| 282 | |
| 283 | temp[1-*]_input Temperature input value. |
| 284 | Unit: millidegree Celsius |
| 285 | RO |
| 286 | |
| 287 | temp[1-*]_crit Temperature critical value, typically greater than |
| 288 | corresponding temp_max values. |
| 289 | Unit: millidegree Celsius |
| 290 | RW |
| 291 | |
| 292 | temp[1-*]_crit_hyst |
| 293 | Temperature hysteresis value for critical limit. |
| 294 | Unit: millidegree Celsius |
| 295 | Must be reported as an absolute temperature, NOT a delta |
| 296 | from the critical value. |
| 297 | RW |
| 298 | |
| 299 | temp[1-*]_offset |
| 300 | Temperature offset which is added to the temperature reading |
| 301 | by the chip. |
| 302 | Unit: millidegree Celsius |
| 303 | Read/Write value. |
| 304 | |
| 305 | temp[1-*]_label Suggested temperature channel label. |
| 306 | Text string |
| 307 | Should only be created if the driver has hints about what |
| 308 | this temperature channel is being used for, and user-space |
| 309 | doesn't. In all other cases, the label is provided by |
| 310 | user-space. |
| 311 | RO |
| 312 | |
| 313 | temp[1-*]_lowest |
| 314 | Historical minimum temperature |
| 315 | Unit: millidegree Celsius |
| 316 | RO |
| 317 | |
| 318 | temp[1-*]_highest |
| 319 | Historical maximum temperature |
| 320 | Unit: millidegree Celsius |
| 321 | RO |
| 322 | |
| 323 | temp[1-*]_reset_history |
| 324 | Reset temp_lowest and temp_highest |
| 325 | WO |
| 326 | |
| 327 | temp_reset_history |
| 328 | Reset temp_lowest and temp_highest for all sensors |
| 329 | WO |
| 330 | |
| 331 | Some chips measure temperature using external thermistors and an ADC, and |
| 332 | report the temperature measurement as a voltage. Converting this voltage |
| 333 | back to a temperature (or the other way around for limits) requires |
| 334 | mathematical functions not available in the kernel, so the conversion |
| 335 | must occur in user space. For these chips, all temp* files described |
| 336 | above should contain values expressed in millivolt instead of millidegree |
| 337 | Celsius. In other words, such temperature channels are handled as voltage |
| 338 | channels by the driver. |
| 339 | |
| 340 | Also see the Alarms section for status flags associated with temperatures. |
| 341 | |
| 342 | |
| 343 | ************ |
| 344 | * Currents * |
| 345 | ************ |
| 346 | |
| 347 | Note that no known chip provides current measurements as of writing, |
| 348 | so this part is theoretical, so to say. |
| 349 | |
| 350 | curr[1-*]_max Current max value |
| 351 | Unit: milliampere |
| 352 | RW |
| 353 | |
| 354 | curr[1-*]_min Current min value. |
| 355 | Unit: milliampere |
| 356 | RW |
| 357 | |
| 358 | curr[1-*]_input Current input value |
| 359 | Unit: milliampere |
| 360 | RO |
| 361 | |
| 362 | ********* |
| 363 | * Power * |
| 364 | ********* |
| 365 | |
| 366 | power[1-*]_average Average power use |
| 367 | Unit: microWatt |
| 368 | RO |
| 369 | |
| 370 | power[1-*]_average_interval Power use averaging interval. A poll |
| 371 | notification is sent to this file if the |
| 372 | hardware changes the averaging interval. |
| 373 | Unit: milliseconds |
| 374 | RW |
| 375 | |
| 376 | power[1-*]_average_interval_max Maximum power use averaging interval |
| 377 | Unit: milliseconds |
| 378 | RO |
| 379 | |
| 380 | power[1-*]_average_interval_min Minimum power use averaging interval |
| 381 | Unit: milliseconds |
| 382 | RO |
| 383 | |
| 384 | power[1-*]_average_highest Historical average maximum power use |
| 385 | Unit: microWatt |
| 386 | RO |
| 387 | |
| 388 | power[1-*]_average_lowest Historical average minimum power use |
| 389 | Unit: microWatt |
| 390 | RO |
| 391 | |
| 392 | power[1-*]_average_max A poll notification is sent to |
| 393 | power[1-*]_average when power use |
| 394 | rises above this value. |
| 395 | Unit: microWatt |
| 396 | RW |
| 397 | |
| 398 | power[1-*]_average_min A poll notification is sent to |
| 399 | power[1-*]_average when power use |
| 400 | sinks below this value. |
| 401 | Unit: microWatt |
| 402 | RW |
| 403 | |
| 404 | power[1-*]_input Instantaneous power use |
| 405 | Unit: microWatt |
| 406 | RO |
| 407 | |
| 408 | power[1-*]_input_highest Historical maximum power use |
| 409 | Unit: microWatt |
| 410 | RO |
| 411 | |
| 412 | power[1-*]_input_lowest Historical minimum power use |
| 413 | Unit: microWatt |
| 414 | RO |
| 415 | |
| 416 | power[1-*]_reset_history Reset input_highest, input_lowest, |
| 417 | average_highest and average_lowest. |
| 418 | WO |
| 419 | |
| 420 | power[1-*]_accuracy Accuracy of the power meter. |
| 421 | Unit: Percent |
| 422 | RO |
| 423 | |
| 424 | power[1-*]_alarm 1 if the system is drawing more power than the |
| 425 | cap allows; 0 otherwise. A poll notification is |
| 426 | sent to this file when the power use exceeds the |
| 427 | cap. This file only appears if the cap is known |
| 428 | to be enforced by hardware. |
| 429 | RO |
| 430 | |
| 431 | power[1-*]_cap If power use rises above this limit, the |
| 432 | system should take action to reduce power use. |
| 433 | A poll notification is sent to this file if the |
| 434 | cap is changed by the hardware. The *_cap |
| 435 | files only appear if the cap is known to be |
| 436 | enforced by hardware. |
| 437 | Unit: microWatt |
| 438 | RW |
| 439 | |
| 440 | power[1-*]_cap_hyst Margin of hysteresis built around capping and |
| 441 | notification. |
| 442 | Unit: microWatt |
| 443 | RW |
| 444 | |
| 445 | power[1-*]_cap_max Maximum cap that can be set. |
| 446 | Unit: microWatt |
| 447 | RO |
| 448 | |
| 449 | power[1-*]_cap_min Minimum cap that can be set. |
| 450 | Unit: microWatt |
| 451 | RO |
| 452 | |
| 453 | ********** |
| 454 | * Energy * |
| 455 | ********** |
| 456 | |
| 457 | energy[1-*]_input Cumulative energy use |
| 458 | Unit: microJoule |
| 459 | RO |
| 460 | |
| 461 | |
| 462 | ********** |
| 463 | * Alarms * |
| 464 | ********** |
| 465 | |
| 466 | Each channel or limit may have an associated alarm file, containing a |
| 467 | boolean value. 1 means than an alarm condition exists, 0 means no alarm. |
| 468 | |
| 469 | Usually a given chip will either use channel-related alarms, or |
| 470 | limit-related alarms, not both. The driver should just reflect the hardware |
| 471 | implementation. |
| 472 | |
| 473 | in[0-*]_alarm |
| 474 | fan[1-*]_alarm |
| 475 | temp[1-*]_alarm |
| 476 | Channel alarm |
| 477 | 0: no alarm |
| 478 | 1: alarm |
| 479 | RO |
| 480 | |
| 481 | OR |
| 482 | |
| 483 | in[0-*]_min_alarm |
| 484 | in[0-*]_max_alarm |
| 485 | fan[1-*]_min_alarm |
| 486 | fan[1-*]_max_alarm |
| 487 | temp[1-*]_min_alarm |
| 488 | temp[1-*]_max_alarm |
| 489 | temp[1-*]_crit_alarm |
| 490 | Limit alarm |
| 491 | 0: no alarm |
| 492 | 1: alarm |
| 493 | RO |
| 494 | |
| 495 | Each input channel may have an associated fault file. This can be used |
| 496 | to notify open diodes, unconnected fans etc. where the hardware |
| 497 | supports it. When this boolean has value 1, the measurement for that |
| 498 | channel should not be trusted. |
| 499 | |
| 500 | in[0-*]_fault |
| 501 | fan[1-*]_fault |
| 502 | temp[1-*]_fault |
| 503 | Input fault condition |
| 504 | 0: no fault occured |
| 505 | 1: fault condition |
| 506 | RO |
| 507 | |
| 508 | Some chips also offer the possibility to get beeped when an alarm occurs: |
| 509 | |
| 510 | beep_enable Master beep enable |
| 511 | 0: no beeps |
| 512 | 1: beeps |
| 513 | RW |
| 514 | |
| 515 | in[0-*]_beep |
| 516 | fan[1-*]_beep |
| 517 | temp[1-*]_beep |
| 518 | Channel beep |
| 519 | 0: disable |
| 520 | 1: enable |
| 521 | RW |
| 522 | |
| 523 | In theory, a chip could provide per-limit beep masking, but no such chip |
| 524 | was seen so far. |
| 525 | |
| 526 | Old drivers provided a different, non-standard interface to alarms and |
| 527 | beeps. These interface files are deprecated, but will be kept around |
| 528 | for compatibility reasons: |
| 529 | |
| 530 | alarms Alarm bitmask. |
| 531 | RO |
| 532 | Integer representation of one to four bytes. |
| 533 | A '1' bit means an alarm. |
| 534 | Chips should be programmed for 'comparator' mode so that |
| 535 | the alarm will 'come back' after you read the register |
| 536 | if it is still valid. |
| 537 | Generally a direct representation of a chip's internal |
| 538 | alarm registers; there is no standard for the position |
| 539 | of individual bits. For this reason, the use of this |
| 540 | interface file for new drivers is discouraged. Use |
| 541 | individual *_alarm and *_fault files instead. |
| 542 | Bits are defined in kernel/include/sensors.h. |
| 543 | |
| 544 | beep_mask Bitmask for beep. |
| 545 | Same format as 'alarms' with the same bit locations, |
| 546 | use discouraged for the same reason. Use individual |
| 547 | *_beep files instead. |
| 548 | RW |
| 549 | |
| 550 | |
| 551 | *********************** |
| 552 | * Intrusion detection * |
| 553 | *********************** |
| 554 | |
| 555 | intrusion[0-*]_alarm |
| 556 | Chassis intrusion detection |
| 557 | 0: OK |
| 558 | 1: intrusion detected |
| 559 | RW |
| 560 | Contrary to regular alarm flags which clear themselves |
| 561 | automatically when read, this one sticks until cleared by |
| 562 | the user. This is done by writing 0 to the file. Writing |
| 563 | other values is unsupported. |
| 564 | |
| 565 | intrusion[0-*]_beep |
| 566 | Chassis intrusion beep |
| 567 | 0: disable |
| 568 | 1: enable |
| 569 | RW |
| 570 | |
| 571 | |
| 572 | sysfs attribute writes interpretation |
| 573 | ------------------------------------- |
| 574 | |
| 575 | hwmon sysfs attributes always contain numbers, so the first thing to do is to |
| 576 | convert the input to a number, there are 2 ways todo this depending whether |
| 577 | the number can be negative or not: |
| 578 | unsigned long u = simple_strtoul(buf, NULL, 10); |
| 579 | long s = simple_strtol(buf, NULL, 10); |
| 580 | |
| 581 | With buf being the buffer with the user input being passed by the kernel. |
| 582 | Notice that we do not use the second argument of strto[u]l, and thus cannot |
| 583 | tell when 0 is returned, if this was really 0 or is caused by invalid input. |
| 584 | This is done deliberately as checking this everywhere would add a lot of |
| 585 | code to the kernel. |
| 586 | |
| 587 | Notice that it is important to always store the converted value in an |
| 588 | unsigned long or long, so that no wrap around can happen before any further |
| 589 | checking. |
| 590 | |
| 591 | After the input string is converted to an (unsigned) long, the value should be |
| 592 | checked if its acceptable. Be careful with further conversions on the value |
| 593 | before checking it for validity, as these conversions could still cause a wrap |
| 594 | around before the check. For example do not multiply the result, and only |
| 595 | add/subtract if it has been divided before the add/subtract. |
| 596 | |
| 597 | What to do if a value is found to be invalid, depends on the type of the |
| 598 | sysfs attribute that is being set. If it is a continuous setting like a |
| 599 | tempX_max or inX_max attribute, then the value should be clamped to its |
| 600 | limits using SENSORS_LIMIT(value, min_limit, max_limit). If it is not |
| 601 | continuous like for example a tempX_type, then when an invalid value is |
| 602 | written, -EINVAL should be returned. |
| 603 | |
| 604 | Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees): |
| 605 | |
| 606 | long v = simple_strtol(buf, NULL, 10) / 1000; |
| 607 | v = SENSORS_LIMIT(v, -128, 127); |
| 608 | /* write v to register */ |
| 609 | |
| 610 | Example2, fan divider setting, valid values 2, 4 and 8: |
| 611 | |
| 612 | unsigned long v = simple_strtoul(buf, NULL, 10); |
| 613 | |
| 614 | switch (v) { |
| 615 | case 2: v = 1; break; |
| 616 | case 4: v = 2; break; |
| 617 | case 8: v = 3; break; |
| 618 | default: |
| 619 | return -EINVAL; |
| 620 | } |
| 621 | /* write v to register */ |