Naming and data format standards for sysfs files------------------------------------------------ The libsensors library offers an interface to the raw sensors datathrough the sysfs interface. See libsensors documentation and source forfurther information. As of writing this document, libsensors(from lm_sensors 2.8.3) is heavily chip-dependent. Adding or updatingsupport for any given chip requires modifying the library's code.This is because libsensors was written for the procfs interfaceolder kernel modules were using, which wasn't standardized enough.Recent versions of libsensors (from lm_sensors 2.8.2 and later) havesupport for the sysfs interface, though. The new sysfs interface was designed to be as chip-independent aspossible. Note that motherboards vary widely in the connections to sensor chips.There is no standard that ensures, for example, that the secondtemperature sensor is connected to the CPU, or that the second fan is onthe CPU. Also, some values reported by the chips need some computationbefore they make full sense. For example, most chips can only measurevoltages between 0 and +4V. Other voltages are scaled back into thatrange using external resistors. Since the values of these resistorscan change from motherboard to motherboard, the conversions cannot behard 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 willstill require a configuration file (e.g. /etc/sensors.conf) for propervalues conversion, labeling of inputs and hiding of unused inputs. An alternative method that some programs use is to access the sysfsfiles directly. This document briefly describes the standards that thedrivers follow, so that an application program can scan for entries andaccess this data in a simple and consistent way. That said, such programswill have to implement conversion, labeling and hiding of inputs. Forthis reason, it is still not recommended to bypass the library. If you are developing a userspace application please send us feedback onthis standard. Note that this standard isn't completely established yet, so it is subjectto changes. If you are writing a new hardware monitoring driver thosefeatures can't seem to fit in this interface, please contact us with yourextension proposal. Keep in mind that backward compatibility must bepreserved. Each chip gets its own directory in the sysfs /sys/devices tree.  Tofind 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: <type><number>_<item>. Usualtypes for sensor chips are "in" (voltage), "temp" (temperature) and"fan" (fan). Usual items are "input" (measured value), "max" (highthreshold, "min" (low threshold). Numbering usually starts from 1,except for voltages which start from 0 (because most data sheets usethis). A number is always used for elements that can be present morethan once, even if there is a single element of the given type on thespecific chip. Other files do not refer to a specific element, sothey have a simple name, and no number. Alarms are direct indications read from the chips. The drivers do NOTmake comparisons of readings to thresholds. This allows violationsbetween readings to be caught and alarmed. The exact definition of analarm (for example, whether a threshold must be met or must be exceededto cause an alarm) is chip-dependent.  ------------------------------------------------------------------------- [0-*]	denotes any positive number starting from 0[1-*]	denotes any positive number starting from 1RO	read only valueRW	read/write value Read/write values may be read-only for some chips, depending on thehardware implementation. All entries are optional, and should only be created in a given driverif the chip has the feature. ************* 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. 		Typical usage:			in0_*	CPU #1 voltage (not scaled)			in1_*	CPU #2 voltage (not scaled)			in2_*	3.3V nominal (not scaled)			in3_*	5.0V nominal (scaled)			in4_*	12.0V nominal (scaled)			in5_*	-12.0V nominal (scaled)			in6_*	-5.0V nominal (scaled)			in7_*	varies			in8_*	varies 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. 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		Switch PWM on and off.		Not always present even if pwmN is.		0: turn off		1: turn on in manual mode		2+: turn on in automatic mode		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-*]_pwmpwm[1-*]_auto_point[1-*]_temppwm[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-*]_pwmtemp[1-*]_auto_point[1-*]_temptemp[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 or thermistor Beta value (typically 3435)		RW		1: PII/Celeron Diode		2: 3904 transistor		3: thermal diode		4: thermistor (default/unknown Beta)		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-4]_offset		Temperature offset which is added to the temperature reading		by the chip.		Unit: millidegree Celsius		Read/Write value. 		If there are multiple temperature sensors, temp1_* is		generally the sensor inside the chip itself,		reported as "motherboard temperature".  temp2_* to		temp4_* are generally sensors external to the chip		itself, for example the thermal diode inside the CPU or		a thermistor nearby. Some chips measure temperature using external thermistors and an ADC, andreport the temperature measurement as a voltage. Converting this voltageback to a temperature (or the other way around for limits) requiresmathematical functions not available in the kernel, so the conversionmust occur in user space. For these chips, all temp* files describedabove should contain values expressed in millivolt instead of millidegreeCelsius. In other words, such temperature channels are handled as voltagechannels 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  *********** Alarms *********** Each channel or limit may have an associated alarm file, containing aboolean value. 1 means than an alarm condition exists, 0 means no alarm. Usually a given chip will either use channel-related alarms, orlimit-related alarms, not both. The driver should just reflect the hardwareimplementation. in[0-*]_alarmfan[1-*]_alarmtemp[1-*]_alarm		Channel alarm		0: no alarm		1: alarm		RO OR in[0-*]_min_alarmin[0-*]_max_alarmfan[1-*]_min_alarmtemp[1-*]_min_alarmtemp[1-*]_max_alarmtemp[1-*]_crit_alarm		Limit alarm		0: no alarm		1: alarm		RO Each input channel may have an associated fault file. This can be usedto notify open diodes, unconnected fans etc. where the hardwaresupports it. When this boolean has value 1, the measurement for thatchannel should not be trusted. in[0-*]_input_faultfan[1-*]_input_faulttemp[1-*]_input_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-*]_beepfan[1-*]_beeptemp[1-*]_beep		Channel beep		0: disable		1: enable		RW In theory, a chip could provide per-limit beep masking, but no such chipwas seen so far. Old drivers provided a different, non-standard interface to alarms andbeeps. These interface files are deprecated, but will be kept aroundfor 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  ********** Other ********** eeprom		Raw EEPROM data in binary form.		RO pec		Enable or disable PEC (SMBus only)		0: disable		1: enable		RW