Subversion Repositories test_project

Naming and data format standards for sysfs files

------------------------------------------------

The libsensors library offers an interface to the raw sensors data

through the sysfs interface. See libsensors documentation and source for

further information. As of writing this document, libsensors

(from lm_sensors 2.8.3) is heavily chip-dependent. Adding or updating

support for any given chip requires modifying the library's code.

This is because libsensors was written for the procfs interface

older kernel modules were using, which wasn't standardized enough.

Recent versions of libsensors (from lm_sensors 2.8.2 and later) have

support for the sysfs interface, though.

The new sysfs interface was designed to be as chip-independent as

possible.

Note that motherboards vary widely in the connections to sensor chips.

There is no standard that ensures, for example, that the second

temperature sensor is connected to the CPU, or that the second fan is on

the CPU. Also, some values reported by the chips need some computation

before they make full sense. For example, most chips can only measure

voltages between 0 and +4V. Other voltages are scaled back into that

range using external resistors. Since the values of these resistors

can change from motherboard to motherboard, the conversions cannot be

hard coded into the driver and have to be done in user space.

For this reason, even if we aim at a chip-independent libsensors, it will

still require a configuration file (e.g. /etc/sensors.conf) for proper

values conversion, labeling of inputs and hiding of unused inputs.

An alternative method that some programs use is to access the sysfs

files directly. This document briefly describes the standards that the

drivers follow, so that an application program can scan for entries and

access this data in a simple and consistent way. That said, such programs

will have to implement conversion, labeling and hiding of inputs. For

this reason, it is still not recommended to bypass the library.

If you are developing a userspace application please send us feedback on

this standard.

Note that this standard isn't completely established yet, so it is subject

to changes. If you are writing a new hardware monitoring driver those

features can't seem to fit in this interface, please contact us with your

extension proposal. Keep in mind that backward compatibility must be

preserved.

Each chip gets its own directory in the sysfs /sys/devices tree.  To

find all sensor chips, it is easier to follow the device symlinks from

/sys/class/hwmon/hwmon*.

All sysfs values are fixed point numbers.

There is only one value per file, unlike the older /proc specification.

The common scheme for files naming is: _. Usual

types for sensor chips are "in" (voltage), "temp" (temperature) and

"fan" (fan). Usual items are "input" (measured value), "max" (high

threshold, "min" (low threshold). Numbering usually starts from 1,

except for voltages which start from 0 (because most data sheets use

this). A number is always used for elements that can be present more

than once, even if there is a single element of the given type on the

specific chip. Other files do not refer to a specific element, so

they have a simple name, and no number.

Alarms are direct indications read from the chips. The drivers do NOT

make comparisons of readings to thresholds. This allows violations

between readings to be caught and alarmed. The exact definition of an

alarm (for example, whether a threshold must be met or must be exceeded

to cause an alarm) is chip-dependent.

When setting values of hwmon sysfs attributes, the string representation of

the desired value must be written, note that strings which are not a number

are interpreted as 0! For more on how written strings are interpreted see the

"sysfs attribute writes interpretation" section at the end of this file.

-------------------------------------------------------------------------

[0-*]   denotes any positive number starting from 0

[1-*]   denotes any positive number starting from 1

RO      read only value

RW      read/write value

Read/write values may be read-only for some chips, depending on the

hardware implementation.

All entries (except name) are optional, and should only be created in a

given driver if the chip has the feature.

********

* Name *

********

name            The chip name.

                This should be a short, lowercase string, not containing

                spaces nor dashes, representing the chip name. This is

                the only mandatory attribute.

                I2C devices get this attribute created automatically.

                RO

************

* Voltages *

************

in[0-*]_min     Voltage min value.

                Unit: millivolt

                RW

in[0-*]_max     Voltage max value.

                Unit: millivolt

                RW

in[0-*]_input   Voltage input value.

                Unit: millivolt

                RO

                Voltage measured on the chip pin.

                Actual voltage depends on the scaling resistors on the

                motherboard, as recommended in the chip datasheet.

                This varies by chip and by motherboard.

                Because of this variation, values are generally NOT scaled

                by the chip driver, and must be done by the application.

                However, some drivers (notably lm87 and via686a)

                do scale, because of internal resistors built into a chip.

                These drivers will output the actual voltage. Rule of

                thumb: drivers should report the voltage values at the

                "pins" of the chip.

in[0-*]_label   Suggested voltage channel label.

                Text string

                Should only be created if the driver has hints about what

                this voltage channel is being used for, and user-space

                doesn't. In all other cases, the label is provided by

                user-space.

                RO

cpu[0-*]_vid    CPU core reference voltage.

                Unit: millivolt

                RO

                Not always correct.

vrm             Voltage Regulator Module version number.

                RW (but changing it should no more be necessary)

                Originally the VRM standard version multiplied by 10, but now

                an arbitrary number, as not all standards have a version

                number.

                Affects the way the driver calculates the CPU core reference

                voltage from the vid pins.

Also see the Alarms section for status flags associated with voltages.

********

* Fans *

********

fan[1-*]_min    Fan minimum value

                Unit: revolution/min (RPM)

                RW

fan[1-*]_input  Fan input value.

                Unit: revolution/min (RPM)

                RO

fan[1-*]_div    Fan divisor.

                Integer value in powers of two (1, 2, 4, 8, 16, 32, 64, 128).

                RW

                Some chips only support values 1, 2, 4 and 8.

                Note that this is actually an internal clock divisor, which

                affects the measurable speed range, not the read value.

fan[1-*]_target

                Desired fan speed

                Unit: revolution/min (RPM)

                RW

                Only makes sense if the chip supports closed-loop fan speed

                control based on the measured fan speed.

fan[1-*]_label  Suggested fan channel label.

                Text string

                Should only be created if the driver has hints about what

                this fan channel is being used for, and user-space doesn't.

                In all other cases, the label is provided by user-space.

                RO

Also see the Alarms section for status flags associated with fans.

*******

* PWM *

*******

pwm[1-*]        Pulse width modulation fan control.

                Integer value in the range 0 to 255

                RW

                255 is max or 100%.

pwm[1-*]_enable

                Fan speed control method:

                0: no fan speed control (i.e. fan at full speed)

                1: manual fan speed control enabled (using pwm[1-*])

                2+: automatic fan speed control enabled

                Check individual chip documentation files for automatic mode

                details.

                RW

pwm[1-*]_mode   0: DC mode (direct current)

                1: PWM mode (pulse-width modulation)

                RW

pwm[1-*]_freq   Base PWM frequency in Hz.

                Only possibly available when pwmN_mode is PWM, but not always

                present even then.

                RW

pwm[1-*]_auto_channels_temp

                Select which temperature channels affect this PWM output in

                auto mode. Bitfield, 1 is temp1, 2 is temp2, 4 is temp3 etc...

                Which values are possible depend on the chip used.

                RW

pwm[1-*]_auto_point[1-*]_pwm

pwm[1-*]_auto_point[1-*]_temp

pwm[1-*]_auto_point[1-*]_temp_hyst

                Define the PWM vs temperature curve. Number of trip points is

                chip-dependent. Use this for chips which associate trip points

                to PWM output channels.

                RW

OR

temp[1-*]_auto_point[1-*]_pwm

temp[1-*]_auto_point[1-*]_temp

temp[1-*]_auto_point[1-*]_temp_hyst

                Define the PWM vs temperature curve. Number of trip points is

                chip-dependent. Use this for chips which associate trip points

                to temperature channels.

                RW

****************

* Temperatures *

****************

temp[1-*]_type  Sensor type selection.

                Integers 1 to 6

                RW

                1: PII/Celeron Diode

                2: 3904 transistor

                3: thermal diode

                4: thermistor

                5: AMD AMDSI

                6: Intel PECI

                Not all types are supported by all chips

temp[1-*]_max   Temperature max value.

                Unit: millidegree Celsius (or millivolt, see below)

                RW

temp[1-*]_min   Temperature min value.

                Unit: millidegree Celsius

                RW

temp[1-*]_max_hyst

                Temperature hysteresis value for max limit.

                Unit: millidegree Celsius

                Must be reported as an absolute temperature, NOT a delta

                from the max value.

                RW

temp[1-*]_input Temperature input value.

                Unit: millidegree Celsius

                RO

temp[1-*]_crit  Temperature critical value, typically greater than

                corresponding temp_max values.

                Unit: millidegree Celsius

                RW

temp[1-*]_crit_hyst

                Temperature hysteresis value for critical limit.

                Unit: millidegree Celsius

                Must be reported as an absolute temperature, NOT a delta

                from the critical value.

                RW

temp[1-*]_offset

                Temperature offset which is added to the temperature reading

                by the chip.

                Unit: millidegree Celsius

                Read/Write value.

temp[1-*]_label Suggested temperature channel label.

                Text string

                Should only be created if the driver has hints about what

                this temperature channel is being used for, and user-space

                doesn't. In all other cases, the label is provided by

                user-space.

                RO

Some chips measure temperature using external thermistors and an ADC, and

report the temperature measurement as a voltage. Converting this voltage

back to a temperature (or the other way around for limits) requires

mathematical functions not available in the kernel, so the conversion

must occur in user space. For these chips, all temp* files described

above should contain values expressed in millivolt instead of millidegree

Celsius. In other words, such temperature channels are handled as voltage

channels by the driver.

Also see the Alarms section for status flags associated with temperatures.

************

* Currents *

************

Note that no known chip provides current measurements as of writing,

so this part is theoretical, so to say.

curr[1-*]_max   Current max value

                Unit: milliampere

                RW

curr[1-*]_min   Current min value.

                Unit: milliampere

                RW

curr[1-*]_input Current input value

                Unit: milliampere

                RO

*********

* Power *

*********

power[1-*]_average              Average power use

                                Unit: microWatt

                                RO

power[1-*]_average_highest      Historical average maximum power use

                                Unit: microWatt

                                RO

power[1-*]_average_lowest       Historical average minimum power use

                                Unit: microWatt

                                RO

power[1-*]_input                Instantaneous power use

                                Unit: microWatt

                                RO

power[1-*]_input_highest        Historical maximum power use

                                Unit: microWatt

                                RO

power[1-*]_input_lowest         Historical minimum power use

                                Unit: microWatt

                                RO

power[1-*]_reset_history        Reset input_highest, input_lowest,

                                average_highest and average_lowest.

                                WO

**********

* Alarms *

**********

Each channel or limit may have an associated alarm file, containing a

boolean value. 1 means than an alarm condition exists, 0 means no alarm.

Usually a given chip will either use channel-related alarms, or

limit-related alarms, not both. The driver should just reflect the hardware

implementation.

in[0-*]_alarm

fan[1-*]_alarm

temp[1-*]_alarm

                Channel alarm

                0: no alarm

                1: alarm

                RO

OR

in[0-*]_min_alarm

in[0-*]_max_alarm

fan[1-*]_min_alarm

temp[1-*]_min_alarm

temp[1-*]_max_alarm

temp[1-*]_crit_alarm

                Limit alarm

                0: no alarm

                1: alarm

                RO

Each input channel may have an associated fault file. This can be used

to notify open diodes, unconnected fans etc. where the hardware

supports it. When this boolean has value 1, the measurement for that

channel should not be trusted.

in[0-*]_fault

fan[1-*]_fault

temp[1-*]_fault

                Input fault condition

                0: no fault occured

                1: fault condition

                RO

Some chips also offer the possibility to get beeped when an alarm occurs:

beep_enable     Master beep enable

                0: no beeps

                1: beeps

                RW

in[0-*]_beep

fan[1-*]_beep

temp[1-*]_beep

                Channel beep

                0: disable

                1: enable

                RW

In theory, a chip could provide per-limit beep masking, but no such chip

was seen so far.

Old drivers provided a different, non-standard interface to alarms and

beeps. These interface files are deprecated, but will be kept around

for compatibility reasons:

alarms          Alarm bitmask.

                RO

                Integer representation of one to four bytes.

                A '1' bit means an alarm.

                Chips should be programmed for 'comparator' mode so that

                the alarm will 'come back' after you read the register

                if it is still valid.

                Generally a direct representation of a chip's internal

                alarm registers; there is no standard for the position

                of individual bits. For this reason, the use of this

                interface file for new drivers is discouraged. Use

                individual *_alarm and *_fault files instead.

                Bits are defined in kernel/include/sensors.h.

beep_mask       Bitmask for beep.

                Same format as 'alarms' with the same bit locations,

                use discouraged for the same reason. Use individual

                *_beep files instead.

                RW

sysfs attribute writes interpretation

-------------------------------------

hwmon sysfs attributes always contain numbers, so the first thing to do is to

convert the input to a number, there are 2 ways todo this depending whether

the number can be negative or not:

unsigned long u = simple_strtoul(buf, NULL, 10);

long s = simple_strtol(buf, NULL, 10);

With buf being the buffer with the user input being passed by the kernel.

Notice that we do not use the second argument of strto[u]l, and thus cannot

tell when 0 is returned, if this was really 0 or is caused by invalid input.

This is done deliberately as checking this everywhere would add a lot of

code to the kernel.

Notice that it is important to always store the converted value in an

unsigned long or long, so that no wrap around can happen before any further

checking.

After the input string is converted to an (unsigned) long, the value should be

checked if its acceptable. Be careful with further conversions on the value

before checking it for validity, as these conversions could still cause a wrap

around before the check. For example do not multiply the result, and only

add/subtract if it has been divided before the add/subtract.

What to do if a value is found to be invalid, depends on the type of the

sysfs attribute that is being set. If it is a continuous setting like a

tempX_max or inX_max attribute, then the value should be clamped to its

limits using SENSORS_LIMIT(value, min_limit, max_limit). If it is not

continuous like for example a tempX_type, then when an invalid value is

written, -EINVAL should be returned.

Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees):

        long v = simple_strtol(buf, NULL, 10) / 1000;

        v = SENSORS_LIMIT(v, -128, 127);

        /* write v to register */

Example2, fan divider setting, valid values 2, 4 and 8:

        unsigned long v = simple_strtoul(buf, NULL, 10);

        switch (v) {

        case 2: v = 1; break;

        case 4: v = 2; break;

        case 8: v = 3; break;

        default:

                return -EINVAL;

        }

        /* write v to register */