1sensors.conf(5) Linux User's Manual sensors.conf(5)
2
6 sensors.conf - libsensors configuration file
7
10 sensors.conf describes how libsensors, and so all programs using it,
11 should translate the raw readings from the kernel modules to real-world
12 values.
13
16 Comments are introduces by hash marks. A comment continues to the end
17 of the line. Empty lines, and lines containing only whitespace or com‐
18 ments are ignored. Other lines have one of the below forms. There must
19 be whitespace between each element, but the amount of whitespace is
20 unimportant. A line may be continued on the next line by ending it with
21 a backslash; this does not work within a comment, NAME or NUMBER.
22 bus NAME NAME NAME
24 chip NAME-LIST
25 label NAME NAME
26 compute NAME EXPR , EXPR
27 ignore NAME
28 set NAME EXPR
29 A NAME is a string. If it only contains letters, digits and under‐
31 scores, it does not have to quoted; in all other cases, you should use
32 double quotes around it. Within quotes, you can use the normal
33 escape-codes from C.
34 A NAME-LIST is one or more NAME items behind each other, separated by
36 whitespace.
37 A EXPR is of one of the below forms:
39 NUMBER
41 NAME
42 @
43 EXPR + EXPR
44 EXPR - EXPR
45 EXPR * EXPR
46 EXPR / EXPR
47 - EXPR
48 ( EXPR )
49 A NUMBER is a floating-point number. `10', `10.4' and `.4' are examples
51 of valid floating-point numbers; `10.' or `10E4' are not valid.
52
55 This section describes the meaning of each statement. Each statement is
56 accompanied by an example line. Please ignore line wrap-arounds.
57 BUS STATEMENT
60 bus "i2c-0" "SMBus PIIX4 adapter at e800"
61 A bus statement binds the description of an I2C or SMBus adapter to a
63 bus number. This makes it possible to refer to an adapter in the con‐
64 figuration file, independent of the actual correspondence of bus num‐
65 bers and actual adapters (which may change from moment to moment).
66 The first argument is the bus number. It is the literal text i2c-, fol‐
68 lowed by a number. As there is a dash in this argument, it must always
69 be quoted.
70 The second argument is the adapter name, it must match exactly the
72 adapter name as it appears in /proc/bus/i2c (2.4 kernel) or
73 /sys/class/i2c-adapter/i2c-*/device/name (2.6 kernel). It should
74 always be quoted as well as it will most certainly contain spaces or
75 dashes.
76 There used to be a third argument, the algorithm name. For compatibil‐
78 ity reasons, the parser still accepts this third argument, but ignores
79 it.
80 The bus statements may be scattered randomly throughout the configura‐
82 tion file; there is no need to place the bus line before the place
83 where its binding is referred to. Still, as a matter of good style, we
84 suggest you place all bus statements together at the top of your con‐
85 figuration file.
86 The program prog/config/grab_busses.sh in the source distribution can
88 help you generate these lines.
89 CHIP STATEMENT
92 chip "lm78-*" "lm79-*"
93 The chip statement selects for which chips all following configuration
95 statements are meant. The chip selection remains valid until the next
96 chip statement. It does not influence the operation of a bus statement.
97 If a chip matches at least one of the chip descriptions, all following
99 configuration lines are examined for it. If it matches none of the chip
100 descriptions, every non-bus statement is ignored upto the next chip
101 statement.
102 A chip description is built from a couple of elements, separated by
104 dashes. To complicate matters, sometimes an element can also contain
105 dashes. This complicates the parsing algorithm, but is not too confus‐
106 ing for humans (we hope!).
107 The first element is the name of the chip type. Sometimes a single
109 driver implements several chip types, with several names. The driver
110 documentation should tell you. You may substitute the wildcard operator
111 * for this element.
112 The second element is the name of the bus. This is either isa, pci or
114 i2c-N, with N being any number as binded with a bus statement. You may
115 substitute the wildcard operator * for this element, or only for the
116 number of the I2C bus (which means 'any I2C bus').
117 The third element is the hexadecimal address of the chip. The valid
119 range depends on the bus type. You may substitute the wildcard operator
120 * for this element.
121 There are some folding rules for wildcards to make things easier for
123 humans to read. Also, you can't specify the address if you wildcard the
124 complete second element. The following are all valid chip type specifi‐
125 cation based on lm78-i2c-1-2d or lm78-isa-0290:
126 lm78-i2c-1-2d
128 lm78-i2c-1-*
129 lm78-i2c-*-2d
130 lm78-i2c-*-*
131 lm78-isa-0290
132 lm78-isa-*
133 lm78-*
134 *-i2c-1-2d
135 *-i2c-1-*
136 *-i2c-*-2d
137 *-i2c-*-*
138 *-isa-0290
139 *-isa-*
140 *-*
141 *
142 COMPUTE STATEMENT
145 compute in3 ((6.8/10)+1)*@ , @/((6.8/10)+1)
146 The compute statement describes how you should translate a feature's
148 raw value to a real-world value, and how you should translate it back
149 to a raw value again.
150 The first argument is the feature name, which may be the name of a fea‐
152 ture class (see below). The second is an expression which specifies how
153 a raw value must be translated to a real-world value; `@' stands here
154 for the raw value. The third is an expression that specifies how a
155 real-world value should be translated back to a raw value; `@' stands
156 here for the real-world value.
157 You may use the name of other features in these expressions; you should
159 be careful though to avoid circular references, as this may hang the
160 expression evaluator.
161 If at any moment a translation between a raw and a real-world value is
163 called for, but no compute statement applies, a one-on-one translation
164 is used instead.
165 The comma is an unfortunate necessity to stop the statement from becom‐
167 ing ambiguous.
168 IGNORE STATEMENT
171 ignore fan1
172 The ignore statement is a hint that a specific feature should be
174 ignored - probably because it returns bogus values (for example,
175 because a fan or temperature sensor is not connected).
176 The only argument is the feature name, which may be a feature class; in
178 that case the label class is used (see below).
179 LABEL STATEMENT
182 label in3 "+5V"
183 The label statement describes how a feature should be called. Features
185 without a label statement are just called by their feature name. Appli‐
186 cations can use this to label the readings they present (but they don't
187 have to).
188 The first argument is the feature name, which may be a feature class
190 (see below). The second argument is the feature description.
191 SET STATEMENT
194 set in3_min 5 * 0.95
195 The set statement gives an initial value for a feature. Not each fea‐
197 ture can be given a sensible initial value; valid features are usually
198 min/max limits.
199 The first argument is the feature name. The second argument is an
201 expression which determines the initial value. If there is an applying
202 compute statement, this value is fed to its third argument to translate
203 it to a raw value.
204 You may use the name of other features in these expressions; current
206 readings are substituted. You should be careful though to avoid circu‐
207 lar references, as this may hang the expression evaluator. Also, you
208 can't be sure in which order set statements are evaluated, so this can
209 lead to nasty surprises.
210
213 There are two kinds of classes, here called compute and label classes,
214 after the statements for which they are defined. Classes are defined
215 over features: the kind of values that can be read from or set for a
216 specific kind of chip.
217 Each class has a class name, which is usually the same as its most
219 prominent feature. A label or compute statement for the class name fea‐
220 ture forces the same settings for all other class members. A specific
221 statement for a class member feature always overrides the general class
222 setting, though. This means that you can't override the class name fea‐
223 ture explicitly.
224 A simple example will explain this better. The fan1 label class of the
226 lm78 chip contains three members: fan1 itself, fan1_min and fan1_div.
227 The last feature sets the number by which readings are divided (to give
228 the fan less resolution, but a larger field of operation). The follow‐
229 ing line will set the name of all these features to describe the fan:
230 label fan1 "Processor 1 FAN"
231 Now we happen to know that, due to the type of fan we use, all readings
232 are always off by a factor of two (some fans only return one 'tick'
233 each rotation, others return two):
234 compute fan1 @/2 , @*2
235 It will be clear that this should be done for the fan1_min feature too,
236 but not for the fan1_div feature! Fortunately, the fan1 compute class
237 contains fan1_min, but not fan1_div, so this works out right.
238
241 If more than one statement of the same kind applies at a certain
242 moment, the last one in the configuration file is used. So usually, you
243 should put more genereal chip statements at the top, so you can over‐
244 rule them below.
245 There is one exception to this rule: if a statement only applies
247 because the feature is in the same class as the feature the statement
248 contains, and there is anywhere else a statement for this specific
249 class member, that one takes always precedence.
250
253 lm_sensors-2.x
254
256 libsensors(3)
257
260 Frodo Looijaard and the lm_sensors group http://www.lm-sensors.org/
261 April 2007 sensors.conf(5)