bus "i2c-0" "SMBus PIIX4 adapter at e800" "Non-I2C SMBus adapter"

A bus statement binds the description of an I2C or SMBus adapter to a bus number. This makes it possible to refer to an adapter in the configuration file, independent of the actual correspondence of bus numbers and actual adapters (which may change from moment to moment).

The first argument is the bus number. It is the literal text i2c-, followed by a number. As there is a dash in this argument, it must always be quoted.

The second and third arguments are the description texts. They must be exactly match the texts as they appear in /proc/bus/i2c, except for trailing spaces, which are removed both from the /proc entries and the arguments. The adapter description comes first, followed by the algorithm description.

The bus statements may be scattered randomly throughout the configuration file; there is no need to place the bus line before the place where its binding is referred to. Still, as a matter of good style, we suggest you place all bus statements together at the top of your configuration file.

The program prog/config/grab_busses.sh in the source distribution can help you generate these lines.

chip "lm78-*" "*-isa-*" "*-i2c-3"

The chip statement selects for which chips all following configuration statements are meant. The chip selection remains valid until the next chip statement. It does not influence the operation of a bus statement.

If a chip matches at least one of the chip descriptions, all following configuration lines are examined for it. If it matches none of the chip descriptions, every non-bus statement is ignored upto the next chip statement.

A chip description is built from a couple of elements, separated by dashes. To complicate matters, sometimes an element can also contain dashes. This complicates the parsing algorithm, but is not too confusing for humans (we hope!). The chip descriptions are equal to those appearing in /proc/sys/dev/sensors, but may contain the * wildcard.

The first element is the name of the chip type. Sometimes a single driver implements several chip types, with several names. The driver documentation should tell you. You may substitute the wildcard operator * for this element.

The second element is the name of the bus. This is either isa or i2c-N, with N being any number as binded with a bus statement. You may substitute the wildcard operator * for this element, or only for the number of the I2C bus (which means 'any non-ISA bus').

The third element is the hexadecimal address. This is a number between 0 and ffff for the ISA bus, and between 0 and 7f for an I2C bus. You may substitute the wildcard operator * for this element.

There are some folding rules for wildcards to make things easier for humans to read. Also, you can't specify the address if you wildcard the complete second element. The following are all valid chip type specification based on lm78-i2c-10-5e or lm78-isa-10dd:

lm78-i2c-10-5e lm78-i2c-10-* lm78-i2c-*-5e lm78-i2c-*-* lm78-isa-10dd lm78-isa-* lm78-* *-i2c-10-5e *-i2c-10-* *-i2c-*-5e *-i2c-*-* *-isa-10dd *-isa-* *-* *

compute in3 ((6.8/10)+1)*@ , @/((6.8/10)+1)

The compute statement describes how you should translate a feature's raw value to a real-world value, and how you should translate it back to a raw value again.

The first argument is the feature name, which may be the name of a feature class (see below). The second is an expression which specifies how a raw value must be translated to a real-world value; `@' stands here for the raw value. The third is an expression that specifies how a real-world value should be translated back to a raw value; `@' stands here for the real-world value.

You may use the name of other features in these expressions; you should be careful though to avoid circular references, as this may hang the expression evaluator.

If at any moment a translation between a raw and a real-world value is called for, but no compute statement applies, a one-on-one translation is used instead.

The comma is an unfortunate necessity to stop the statement from becoming ambiguous.

ignore fan1

The ignore statement is a hint that a specific feature should be ignored - probably because it returns bogus values (for example, because a fan or temperature sensor is not connected).

The only argument is the feature name, which may be a feature class; in that case the label class is used (see below).

label in3 "+5V"

The label statement describes how a feature should be called. Features without a label statement are just called by their feature name. Applications can use this to label the readings they present (but they don't have to).

The first argument is the feature name, which may be a feature class (see below). The second argument is the feature description.

set in3_min 5 * 0.95

The set statement gives an initial value for a feature. Not each feature can be given a sensible initial value; valid features are usually min/max limits.

The first argument is the feature name. The second argument is an expression which determines the initial value. If there is an applying compute statement, this value is fed to its third argument to translate it to a raw value.

You may use the name of other features in these expressions; current readings are substituted. You should be careful though to avoid circular references, as this may hang the expression evaluator. Also, you can't be sure in which order set statements are evaluated, so this can lead to nasty surprises.