Provided by: lm-sensors_2.9.2-5ubuntu3_i386 bug


       sensors.conf - libsensors configuration file


       sensors.conf  describes  how  libsensors, and so all programs using it,
       should translate the raw readings from the kernel modules to real-world


       Comments  are  introduces by hash marks. A comment continues to the end
       of the line. Empty lines,  and  lines  containing  only  whitespace  or
       comments  are  ignored.  Other lines have one of the below forms. There
       should be whitespace between each element, but the amount of whitespace
       is  unimportant.  A line may be continued on the next line by ending it
       with a backslash; this does not work within a comment, NAME or  NUMBER.

              bus NAME NAME NAME
              chip NAME-LIST
              label NAME NAME
              compute NAME EXPR , EXPR
              ignore NAME
              set NAME EXPR

       A   NAME  is  a  string.  If  it  only  contains  letters,  digits  and
       underscores, it does not have to quoted; in all other cases, you should
       use  double  quotes  around  it.  Within quotes, you can use the normal
       escape-codes from C.

       A NAME-LIST is one or more NAME items behind each other,  separated  by

       A EXPR is of one of the below forms:

              EXPR + EXPR
              EXPR - EXPR
              EXPR * EXPR
              EXPR / EXPR
              - EXPR
              ( EXPR )

       A NUMBER is a floating-point number. ‘10’, ‘10.4’ and ‘.4’ are examples
       of valid floating-point numbers; ‘10.’ or ‘10E4’ are not valid.


       This section describes the meaning of each statement. Each statement is
       accompanied by an example line. Please ignore line wrap-arounds.

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

       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/ 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

       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  *

       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:


              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.


       There are two kinds of classes, here called compute and label  classes,
       after  the  statements  for which they are defined. Classes are defined
       over features: the kind of values that can be read from or  set  for  a
       specific kind of chip.

       Each  class  has  a  class  name, which is usually the same as its most
       prominent feature. A label or compute  statement  for  the  class  name
       feature  forces  the  same  settings  for  all  other  class members. A
       specific statement for a class  member  feature  always  overrides  the
       general  class  setting, though. This means that you can’t override the
       class name feature explicitly.

       A simple example will explain this better. The fan1 label class of  the
       lm78  chip  contains three members: fan1 itself, fan1_min and fan1_div.
       The last feature sets the number by which readings are divided (to give
       the  fan  less  resolution,  but  a  larger  field  of  operation). The
       following line will set the name of all these features to describe  the
              label fan1 "Processor 1 FAN"
       Now we happen to know that, due to the type of fan we use, all readings
       are always off by a factor of two (some fans  only  return  one  ’tick’
       each rotation, others return two):
              compute fan1 @/2 , @*2
       It will be clear that this should be done for the fan1_min feature too,
       but not for the fan1_div feature! Fortunately, the fan1  compute  class
       contains fan1_min, but not fan1_div, so this works out right.


       If  more  than  one  statement  of  the  same kind applies at a certain
       moment, the last one in the configuration file is used. So usually, you
       should  put  more  genereal  chip  statements  at  the  top, so you can
       overrule them below.

       There is one exception to  this  rule:  if  a  statement  only  applies
       because  the  feature is in the same class as the feature the statement
       contains, and there is anywhere else  a  statement  for  this  specific
       class member, that one takes always precedence.






       Frodo Looijaard and the lm_sensors group

                               February 8, 1999                sensors.conf(5)