]> git.proxmox.com Git - mirror_ubuntu-hirsute-kernel.git/blob - Documentation/hwmon/sysfs-interface
docs: hwmon: convert remaining files to ReST format
[mirror_ubuntu-hirsute-kernel.git] / Documentation / hwmon / sysfs-interface
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 ======= ===========================================
71 `[0-*]` denotes any positive number starting from 0
72 `[1-*]` denotes any positive number starting from 1
73 RO read only value
74 WO write only value
75 RW read/write value
76 ======= ===========================================
77
78 Read/write values may be read-only for some chips, depending on the
79 hardware implementation.
80
81 All entries (except name) are optional, and should only be created in a
82 given driver if the chip has the feature.
83
84
85 *****************
86 Global attributes
87 *****************
88
89 `name`
90 The chip name.
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
94 mandatory attribute.
95 I2C devices get this attribute created automatically.
96
97 RO
98
99 `update_interval`
100 The interval at which the chip will update readings.
101 Unit: millisecond
102
103 RW
104
105 Some devices have a variable update rate or interval.
106 This attribute can be used to change it to the desired value.
107
108
109 ********
110 Voltages
111 ********
112
113 `in[0-*]_min`
114 Voltage min value.
115
116 Unit: millivolt
117
118 RW
119
120 `in[0-*]_lcrit`
121 Voltage critical min value.
122
123 Unit: millivolt
124
125 RW
126
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.
130
131 `in[0-*]_max`
132 Voltage max value.
133
134 Unit: millivolt
135
136 RW
137
138 `in[0-*]_crit`
139 Voltage critical max value.
140
141 Unit: millivolt
142
143 RW
144
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.
148
149 `in[0-*]_input`
150 Voltage input value.
151
152 Unit: millivolt
153
154 RO
155
156 Voltage measured on the chip pin.
157
158 Actual voltage depends on the scaling resistors on the
159 motherboard, as recommended in the chip datasheet.
160
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
168 "pins" of the chip.
169
170 `in[0-*]_average`
171 Average voltage
172
173 Unit: millivolt
174
175 RO
176
177 `in[0-*]_lowest`
178 Historical minimum voltage
179
180 Unit: millivolt
181
182 RO
183
184 `in[0-*]_highest`
185 Historical maximum voltage
186
187 Unit: millivolt
188
189 RO
190
191 `in[0-*]_reset_history`
192 Reset inX_lowest and inX_highest
193
194 WO
195
196 `in_reset_history`
197 Reset inX_lowest and inX_highest for all sensors
198
199 WO
200
201 `in[0-*]_label`
202 Suggested voltage channel label.
203
204 Text string
205
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
209 user-space.
210
211 RO
212
213 `in[0-*]_enable`
214 Enable or disable the sensors.
215
216 When disabled the sensor read will return -ENODATA.
217
218 - 1: Enable
219 - 0: Disable
220
221 RW
222
223 `cpu[0-*]_vid`
224 CPU core reference voltage.
225
226 Unit: millivolt
227
228 RO
229
230 Not always correct.
231
232 `vrm`
233 Voltage Regulator Module version number.
234
235 RW (but changing it should no more be necessary)
236
237 Originally the VRM standard version multiplied by 10, but now
238 an arbitrary number, as not all standards have a version
239 number.
240
241 Affects the way the driver calculates the CPU core reference
242 voltage from the vid pins.
243
244 Also see the Alarms section for status flags associated with voltages.
245
246
247 ****
248 Fans
249 ****
250
251 `fan[1-*]_min`
252 Fan minimum value
253
254 Unit: revolution/min (RPM)
255
256 RW
257
258 `fan[1-*]_max`
259 Fan maximum value
260
261 Unit: revolution/min (RPM)
262
263 Only rarely supported by the hardware.
264 RW
265
266 `fan[1-*]_input`
267 Fan input value.
268
269 Unit: revolution/min (RPM)
270
271 RO
272
273 `fan[1-*]_div`
274 Fan divisor.
275
276 Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128).
277
278 RW
279
280 Some chips only support values 1, 2, 4 and 8.
281 Note that this is actually an internal clock divisor, which
282 affects the measurable speed range, not the read value.
283
284 `fan[1-*]_pulses`
285 Number of tachometer pulses per fan revolution.
286
287 Integer value, typically between 1 and 4.
288
289 RW
290
291 This value is a characteristic of the fan connected to the
292 device's input, so it has to be set in accordance with the fan
293 model.
294
295 Should only be created if the chip has a register to configure
296 the number of pulses. In the absence of such a register (and
297 thus attribute) the value assumed by all devices is 2 pulses
298 per fan revolution.
299
300 `fan[1-*]_target`
301 Desired fan speed
302
303 Unit: revolution/min (RPM)
304
305 RW
306
307 Only makes sense if the chip supports closed-loop fan speed
308 control based on the measured fan speed.
309
310 `fan[1-*]_label`
311 Suggested fan channel label.
312
313 Text string
314
315 Should only be created if the driver has hints about what
316 this fan channel is being used for, and user-space doesn't.
317 In all other cases, the label is provided by user-space.
318
319 RO
320
321 `fan[1-*]_enable`
322 Enable or disable the sensors.
323
324 When disabled the sensor read will return -ENODATA.
325
326 - 1: Enable
327 - 0: Disable
328
329 RW
330
331 Also see the Alarms section for status flags associated with fans.
332
333
334 ***
335 PWM
336 ***
337
338 `pwm[1-*]`
339 Pulse width modulation fan control.
340
341 Integer value in the range 0 to 255
342
343 RW
344
345 255 is max or 100%.
346
347 `pwm[1-*]_enable`
348 Fan speed control method:
349
350 - 0: no fan speed control (i.e. fan at full speed)
351 - 1: manual fan speed control enabled (using `pwm[1-*]`)
352 - 2+: automatic fan speed control enabled
353
354 Check individual chip documentation files for automatic mode
355 details.
356
357 RW
358
359 `pwm[1-*]_mode`
360 - 0: DC mode (direct current)
361 - 1: PWM mode (pulse-width modulation)
362
363 RW
364
365 `pwm[1-*]_freq`
366 Base PWM frequency in Hz.
367
368 Only possibly available when pwmN_mode is PWM, but not always
369 present even then.
370
371 RW
372
373 `pwm[1-*]_auto_channels_temp`
374 Select which temperature channels affect this PWM output in
375 auto mode.
376
377 Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc...
378 Which values are possible depend on the chip used.
379
380 RW
381
382 `pwm[1-*]_auto_point[1-*]_pwm` / `pwm[1-*]_auto_point[1-*]_temp` / `pwm[1-*]_auto_point[1-*]_temp_hyst`
383 Define the PWM vs temperature curve.
384
385 Number of trip points is chip-dependent. Use this for chips
386 which associate trip points to PWM output channels.
387
388 RW
389
390 `temp[1-*]_auto_point[1-*]_pwm` / `temp[1-*]_auto_point[1-*]_temp` / `temp[1-*]_auto_point[1-*]_temp_hyst`
391 Define the PWM vs temperature curve.
392
393 Number of trip points is chip-dependent. Use this for chips
394 which associate trip points to temperature channels.
395
396 RW
397
398 There is a third case where trip points are associated to both PWM output
399 channels and temperature channels: the PWM values are associated to PWM
400 output channels while the temperature values are associated to temperature
401 channels. In that case, the result is determined by the mapping between
402 temperature inputs and PWM outputs. When several temperature inputs are
403 mapped to a given PWM output, this leads to several candidate PWM values.
404 The actual result is up to the chip, but in general the highest candidate
405 value (fastest fan speed) wins.
406
407
408 ************
409 Temperatures
410 ************
411
412 `temp[1-*]_type`
413 Sensor type selection.
414
415 Integers 1 to 6
416
417 RW
418
419 - 1: CPU embedded diode
420 - 2: 3904 transistor
421 - 3: thermal diode
422 - 4: thermistor
423 - 5: AMD AMDSI
424 - 6: Intel PECI
425
426 Not all types are supported by all chips
427
428 `temp[1-*]_max`
429 Temperature max value.
430
431 Unit: millidegree Celsius (or millivolt, see below)
432
433 RW
434
435 `temp[1-*]_min`
436 Temperature min value.
437
438 Unit: millidegree Celsius
439
440 RW
441
442 `temp[1-*]_max_hyst`
443 Temperature hysteresis value for max limit.
444
445 Unit: millidegree Celsius
446
447 Must be reported as an absolute temperature, NOT a delta
448 from the max value.
449
450 RW
451
452 `temp[1-*]_min_hyst`
453 Temperature hysteresis value for min limit.
454 Unit: millidegree Celsius
455
456 Must be reported as an absolute temperature, NOT a delta
457 from the min value.
458
459 RW
460
461 `temp[1-*]_input`
462 Temperature input value.
463
464 Unit: millidegree Celsius
465
466 RO
467
468 `temp[1-*]_crit`
469 Temperature critical max value, typically greater than
470 corresponding temp_max values.
471
472 Unit: millidegree Celsius
473
474 RW
475
476 `temp[1-*]_crit_hyst`
477 Temperature hysteresis value for critical limit.
478
479 Unit: millidegree Celsius
480
481 Must be reported as an absolute temperature, NOT a delta
482 from the critical value.
483
484 RW
485
486 `temp[1-*]_emergency`
487 Temperature emergency max value, for chips supporting more than
488 two upper temperature limits. Must be equal or greater than
489 corresponding temp_crit values.
490
491 Unit: millidegree Celsius
492
493 RW
494
495 `temp[1-*]_emergency_hyst`
496 Temperature hysteresis value for emergency limit.
497
498 Unit: millidegree Celsius
499
500 Must be reported as an absolute temperature, NOT a delta
501 from the emergency value.
502
503 RW
504
505 `temp[1-*]_lcrit`
506 Temperature critical min value, typically lower than
507 corresponding temp_min values.
508
509 Unit: millidegree Celsius
510
511 RW
512
513 `temp[1-*]_lcrit_hyst`
514 Temperature hysteresis value for critical min limit.
515
516 Unit: millidegree Celsius
517
518 Must be reported as an absolute temperature, NOT a delta
519 from the critical min value.
520
521 RW
522
523 `temp[1-*]_offset`
524 Temperature offset which is added to the temperature reading
525 by the chip.
526
527 Unit: millidegree Celsius
528
529 Read/Write value.
530
531 `temp[1-*]_label`
532 Suggested temperature channel label.
533
534 Text string
535
536 Should only be created if the driver has hints about what
537 this temperature channel is being used for, and user-space
538 doesn't. In all other cases, the label is provided by
539 user-space.
540
541 RO
542
543 `temp[1-*]_lowest`
544 Historical minimum temperature
545
546 Unit: millidegree Celsius
547
548 RO
549
550 `temp[1-*]_highest`
551 Historical maximum temperature
552
553 Unit: millidegree Celsius
554
555 RO
556
557 `temp[1-*]_reset_history`
558 Reset temp_lowest and temp_highest
559
560 WO
561
562 `temp_reset_history`
563 Reset temp_lowest and temp_highest for all sensors
564
565 WO
566
567 `temp[1-*]_enable`
568 Enable or disable the sensors.
569
570 When disabled the sensor read will return -ENODATA.
571
572 - 1: Enable
573 - 0: Disable
574
575 RW
576
577 Some chips measure temperature using external thermistors and an ADC, and
578 report the temperature measurement as a voltage. Converting this voltage
579 back to a temperature (or the other way around for limits) requires
580 mathematical functions not available in the kernel, so the conversion
581 must occur in user space. For these chips, all temp* files described
582 above should contain values expressed in millivolt instead of millidegree
583 Celsius. In other words, such temperature channels are handled as voltage
584 channels by the driver.
585
586 Also see the Alarms section for status flags associated with temperatures.
587
588
589 ********
590 Currents
591 ********
592
593 `curr[1-*]_max`
594 Current max value
595
596 Unit: milliampere
597
598 RW
599
600 `curr[1-*]_min`
601 Current min value.
602
603 Unit: milliampere
604
605 RW
606
607 `curr[1-*]_lcrit`
608 Current critical low value
609
610 Unit: milliampere
611
612 RW
613
614 `curr[1-*]_crit`
615 Current critical high value.
616
617 Unit: milliampere
618
619 RW
620
621 `curr[1-*]_input`
622 Current input value
623
624 Unit: milliampere
625
626 RO
627
628 `curr[1-*]_average`
629 Average current use
630
631 Unit: milliampere
632
633 RO
634
635 `curr[1-*]_lowest`
636 Historical minimum current
637
638 Unit: milliampere
639
640 RO
641
642 `curr[1-*]_highest`
643 Historical maximum current
644 Unit: milliampere
645 RO
646
647 `curr[1-*]_reset_history`
648 Reset currX_lowest and currX_highest
649
650 WO
651
652 `curr_reset_history`
653 Reset currX_lowest and currX_highest for all sensors
654
655 WO
656
657 `curr[1-*]_enable`
658 Enable or disable the sensors.
659
660 When disabled the sensor read will return -ENODATA.
661
662 - 1: Enable
663 - 0: Disable
664
665 RW
666
667 Also see the Alarms section for status flags associated with currents.
668
669 *****
670 Power
671 *****
672
673 `power[1-*]_average`
674 Average power use
675
676 Unit: microWatt
677
678 RO
679
680 `power[1-*]_average_interval`
681 Power use averaging interval. A poll
682 notification is sent to this file if the
683 hardware changes the averaging interval.
684
685 Unit: milliseconds
686
687 RW
688
689 `power[1-*]_average_interval_max`
690 Maximum power use averaging interval
691
692 Unit: milliseconds
693
694 RO
695
696 `power[1-*]_average_interval_min`
697 Minimum power use averaging interval
698
699 Unit: milliseconds
700
701 RO
702
703 `power[1-*]_average_highest`
704 Historical average maximum power use
705
706 Unit: microWatt
707
708 RO
709
710 `power[1-*]_average_lowest`
711 Historical average minimum power use
712
713 Unit: microWatt
714
715 RO
716
717 `power[1-*]_average_max`
718 A poll notification is sent to
719 `power[1-*]_average` when power use
720 rises above this value.
721
722 Unit: microWatt
723
724 RW
725
726 `power[1-*]_average_min`
727 A poll notification is sent to
728 `power[1-*]_average` when power use
729 sinks below this value.
730
731 Unit: microWatt
732
733 RW
734
735 `power[1-*]_input`
736 Instantaneous power use
737
738 Unit: microWatt
739
740 RO
741
742 `power[1-*]_input_highest`
743 Historical maximum power use
744
745 Unit: microWatt
746
747 RO
748
749 `power[1-*]_input_lowest`
750 Historical minimum power use
751
752 Unit: microWatt
753
754 RO
755
756 `power[1-*]_reset_history`
757 Reset input_highest, input_lowest,
758 average_highest and average_lowest.
759
760 WO
761
762 `power[1-*]_accuracy`
763 Accuracy of the power meter.
764
765 Unit: Percent
766
767 RO
768
769 `power[1-*]_cap`
770 If power use rises above this limit, the
771 system should take action to reduce power use.
772 A poll notification is sent to this file if the
773 cap is changed by the hardware. The `*_cap`
774 files only appear if the cap is known to be
775 enforced by hardware.
776
777 Unit: microWatt
778
779 RW
780
781 `power[1-*]_cap_hyst`
782 Margin of hysteresis built around capping and
783 notification.
784
785 Unit: microWatt
786
787 RW
788
789 `power[1-*]_cap_max`
790 Maximum cap that can be set.
791
792 Unit: microWatt
793
794 RO
795
796 `power[1-*]_cap_min`
797 Minimum cap that can be set.
798
799 Unit: microWatt
800
801 RO
802
803 `power[1-*]_max`
804 Maximum power.
805
806 Unit: microWatt
807
808 RW
809
810 `power[1-*]_crit`
811 Critical maximum power.
812
813 If power rises to or above this limit, the
814 system is expected take drastic action to reduce
815 power consumption, such as a system shutdown or
816 a forced powerdown of some devices.
817
818 Unit: microWatt
819
820 RW
821
822 `power[1-*]_enable`
823 Enable or disable the sensors.
824
825 When disabled the sensor read will return
826 -ENODATA.
827
828 - 1: Enable
829 - 0: Disable
830
831 RW
832
833 Also see the Alarms section for status flags associated with power readings.
834
835 ******
836 Energy
837 ******
838
839 `energy[1-*]_input`
840 Cumulative energy use
841
842 Unit: microJoule
843
844 RO
845
846 `energy[1-*]_enable`
847 Enable or disable the sensors.
848
849 When disabled the sensor read will return
850 -ENODATA.
851
852 - 1: Enable
853 - 0: Disable
854
855 RW
856
857 ********
858 Humidity
859 ********
860
861 `humidity[1-*]_input`
862 Humidity
863
864 Unit: milli-percent (per cent mille, pcm)
865
866 RO
867
868
869 `humidity[1-*]_enable`
870 Enable or disable the sensors
871
872 When disabled the sensor read will return
873 -ENODATA.
874
875 - 1: Enable
876 - 0: Disable
877
878 RW
879
880 ******
881 Alarms
882 ******
883
884 Each channel or limit may have an associated alarm file, containing a
885 boolean value. 1 means than an alarm condition exists, 0 means no alarm.
886
887 Usually a given chip will either use channel-related alarms, or
888 limit-related alarms, not both. The driver should just reflect the hardware
889 implementation.
890
891 +-------------------------------+-----------------------+
892 | **`in[0-*]_alarm`, | Channel alarm |
893 | `curr[1-*]_alarm`, | |
894 | `power[1-*]_alarm`, | - 0: no alarm |
895 | `fan[1-*]_alarm`, | - 1: alarm |
896 | `temp[1-*]_alarm`** | |
897 | | RO |
898 +-------------------------------+-----------------------+
899
900 **OR**
901
902 +-------------------------------+-----------------------+
903 | **`in[0-*]_min_alarm`, | Limit alarm |
904 | `in[0-*]_max_alarm`, | |
905 | `in[0-*]_lcrit_alarm`, | - 0: no alarm |
906 | `in[0-*]_crit_alarm`, | - 1: alarm |
907 | `curr[1-*]_min_alarm`, | |
908 | `curr[1-*]_max_alarm`, | RO |
909 | `curr[1-*]_lcrit_alarm`, | |
910 | `curr[1-*]_crit_alarm`, | |
911 | `power[1-*]_cap_alarm`, | |
912 | `power[1-*]_max_alarm`, | |
913 | `power[1-*]_crit_alarm`, | |
914 | `fan[1-*]_min_alarm`, | |
915 | `fan[1-*]_max_alarm`, | |
916 | `temp[1-*]_min_alarm`, | |
917 | `temp[1-*]_max_alarm`, | |
918 | `temp[1-*]_lcrit_alarm`, | |
919 | `temp[1-*]_crit_alarm`, | |
920 | `temp[1-*]_emergency_alarm`** | |
921 +-------------------------------+-----------------------+
922
923 Each input channel may have an associated fault file. This can be used
924 to notify open diodes, unconnected fans etc. where the hardware
925 supports it. When this boolean has value 1, the measurement for that
926 channel should not be trusted.
927
928 `fan[1-*]_fault` / `temp[1-*]_fault`
929 Input fault condition
930
931 - 0: no fault occurred
932 - 1: fault condition
933
934 RO
935
936 Some chips also offer the possibility to get beeped when an alarm occurs:
937
938 `beep_enable`
939 Master beep enable
940
941 - 0: no beeps
942 - 1: beeps
943
944 RW
945
946 `in[0-*]_beep`, `curr[1-*]_beep`, `fan[1-*]_beep`, `temp[1-*]_beep`,
947 Channel beep
948
949 - 0: disable
950 - 1: enable
951
952 RW
953
954 In theory, a chip could provide per-limit beep masking, but no such chip
955 was seen so far.
956
957 Old drivers provided a different, non-standard interface to alarms and
958 beeps. These interface files are deprecated, but will be kept around
959 for compatibility reasons:
960
961 `alarms`
962 Alarm bitmask.
963
964 RO
965
966 Integer representation of one to four bytes.
967
968 A '1' bit means an alarm.
969
970 Chips should be programmed for 'comparator' mode so that
971 the alarm will 'come back' after you read the register
972 if it is still valid.
973
974 Generally a direct representation of a chip's internal
975 alarm registers; there is no standard for the position
976 of individual bits. For this reason, the use of this
977 interface file for new drivers is discouraged. Use
978 `individual *_alarm` and `*_fault` files instead.
979 Bits are defined in kernel/include/sensors.h.
980
981 `beep_mask`
982 Bitmask for beep.
983 Same format as 'alarms' with the same bit locations,
984 use discouraged for the same reason. Use individual
985 `*_beep` files instead.
986 RW
987
988
989 *******************
990 Intrusion detection
991 *******************
992
993 `intrusion[0-*]_alarm`
994 Chassis intrusion detection
995
996 - 0: OK
997 - 1: intrusion detected
998
999 RW
1000
1001 Contrary to regular alarm flags which clear themselves
1002 automatically when read, this one sticks until cleared by
1003 the user. This is done by writing 0 to the file. Writing
1004 other values is unsupported.
1005
1006 `intrusion[0-*]_beep`
1007 Chassis intrusion beep
1008
1009 0: disable
1010 1: enable
1011
1012 RW
1013
1014 ****************************
1015 Average sample configuration
1016 ****************************
1017
1018 Devices allowing for reading {in,power,curr,temp}_average values may export
1019 attributes for controlling number of samples used to compute average.
1020
1021 +--------------+---------------------------------------------------------------+
1022 | samples | Sets number of average samples for all types of measurements. |
1023 | | |
1024 | | RW |
1025 +--------------+---------------------------------------------------------------+
1026 | in_samples | Sets number of average samples for specific type of |
1027 | power_samples| measurements. |
1028 | curr_samples | |
1029 | temp_samples | Note that on some devices it won't be possible to set all of |
1030 | | them to different values so changing one might also change |
1031 | | some others. |
1032 | | |
1033 | | RW |
1034 +--------------+---------------------------------------------------------------+
1035
1036 sysfs attribute writes interpretation
1037 -------------------------------------
1038
1039 hwmon sysfs attributes always contain numbers, so the first thing to do is to
1040 convert the input to a number, there are 2 ways todo this depending whether
1041 the number can be negative or not::
1042
1043 unsigned long u = simple_strtoul(buf, NULL, 10);
1044 long s = simple_strtol(buf, NULL, 10);
1045
1046 With buf being the buffer with the user input being passed by the kernel.
1047 Notice that we do not use the second argument of strto[u]l, and thus cannot
1048 tell when 0 is returned, if this was really 0 or is caused by invalid input.
1049 This is done deliberately as checking this everywhere would add a lot of
1050 code to the kernel.
1051
1052 Notice that it is important to always store the converted value in an
1053 unsigned long or long, so that no wrap around can happen before any further
1054 checking.
1055
1056 After the input string is converted to an (unsigned) long, the value should be
1057 checked if its acceptable. Be careful with further conversions on the value
1058 before checking it for validity, as these conversions could still cause a wrap
1059 around before the check. For example do not multiply the result, and only
1060 add/subtract if it has been divided before the add/subtract.
1061
1062 What to do if a value is found to be invalid, depends on the type of the
1063 sysfs attribute that is being set. If it is a continuous setting like a
1064 tempX_max or inX_max attribute, then the value should be clamped to its
1065 limits using clamp_val(value, min_limit, max_limit). If it is not continuous
1066 like for example a tempX_type, then when an invalid value is written,
1067 -EINVAL should be returned.
1068
1069 Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees)::
1070
1071 long v = simple_strtol(buf, NULL, 10) / 1000;
1072 v = clamp_val(v, -128, 127);
1073 /* write v to register */
1074
1075 Example2, fan divider setting, valid values 2, 4 and 8::
1076
1077 unsigned long v = simple_strtoul(buf, NULL, 10);
1078
1079 switch (v) {
1080 case 2: v = 1; break;
1081 case 4: v = 2; break;
1082 case 8: v = 3; break;
1083 default:
1084 return -EINVAL;
1085 }
1086 /* write v to register */