From 9cab0217f3f35bd618363842576867badb72ca4b Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sun, 15 Jul 2007 10:36:06 +0200 Subject: hwmon: (f71805f) List the F71806F/FG as supported The Fintek F71806F/FG is compatible with the F71872F/FG, so it is already supported by the f71805f hardware monitoring driver. In fact, both chips have the same chip ID, so the driver can't even differentiate between them. Signed-off-by: Jean Delvare Acked-by: Hans de Goede Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/f71805f | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/f71805f b/Documentation/hwmon/f71805f index 94e0d2cbd3d2..f0d55976740a 100644 --- a/Documentation/hwmon/f71805f +++ b/Documentation/hwmon/f71805f @@ -6,6 +6,10 @@ Supported chips: Prefix: 'f71805f' Addresses scanned: none, address read from Super I/O config space Datasheet: Available from the Fintek website + * Fintek F71806F/FG + Prefix: 'f71872f' + Addresses scanned: none, address read from Super I/O config space + Datasheet: Available from the Fintek website * Fintek F71872F/FG Prefix: 'f71872f' Addresses scanned: none, address read from Super I/O config space @@ -38,6 +42,9 @@ The Fintek F71872F/FG Super I/O chip is almost the same, with two additional internal voltages monitored (VSB and battery). It also features 6 VID inputs. The VID inputs are not yet supported by this driver. +The Fintek F71806F/FG Super-I/O chip is essentially the same as the +F71872F/FG, and is undistinguishable therefrom. + The driver assumes that no more than one chip is present, which seems reasonable. -- cgit v1.2.3 From b26f93309282bdfebb3edb8939e022a4bbe56dfe Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 16 Aug 2007 14:30:01 +0200 Subject: hwmon: Don't export thermistor beta Deprecate the use of thermistor beta values as thermal sensor types. No driver supports changing the beta value anyway. Signed-off-by: Jean Delvare Acked-by: Hans de Goede Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/sysfs-interface | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index b3a9e1b9dbda..331fa7a1d7d5 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -219,12 +219,12 @@ temp[1-*]_auto_point[1-*]_temp_hyst **************** temp[1-*]_type Sensor type selection. - Integers 1 to 6 or thermistor Beta value (typically 3435) + Integers 1 to 6 RW 1: PII/Celeron Diode 2: 3904 transistor 3: thermal diode - 4: thermistor (default/unknown Beta) + 4: thermistor 5: AMD AMDSI 6: Intel PECI Not all types are supported by all chips -- cgit v1.2.3 From 471c606827394f59117cf45c808afd8fe638f902 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 16 Aug 2007 14:48:49 +0200 Subject: hwmon: (lm93) Documentation fixes * Drop documentation of generic module parameters. * Drop redundant section "Driver Description". * Drop sample configuration section, it belongs to sensors.conf.eg. * Random spelling and punctuation fixes. Signed-off-by: Jean Delvare Acked-by: Hans J. Koch Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/lm93 | 126 +++-------------------------------------------- 1 file changed, 8 insertions(+), 118 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm93 b/Documentation/hwmon/lm93 index 4e4a1dc1d2da..ac711f357faf 100644 --- a/Documentation/hwmon/lm93 +++ b/Documentation/hwmon/lm93 @@ -7,7 +7,7 @@ Supported chips: Addresses scanned: I2C 0x2c-0x2e Datasheet: http://www.national.com/ds.cgi/LM/LM93.pdf -Author: +Authors: Mark M. Hoffman Ported to 2.6 by Eric J. Bowersox Adapted to 2.6.20 by Carsten Emde @@ -16,7 +16,6 @@ Author: Module Parameters ----------------- -(specific to LM93) * init: integer Set to non-zero to force some initializations (default is 0). * disable_block: integer @@ -37,30 +36,13 @@ Module Parameters I.e. this parameter controls the VID pin input thresholds; if your VID inputs are not working, try changing this. The default value is "0". -(common among sensor drivers) -* force: short array (min = 1, max = 48) - List of adapter,address pairs to assume to be present. Autodetection - of the target device will still be attempted. Use one of the more - specific force directives below if this doesn't detect the device. -* force_lm93: short array (min = 1, max = 48) - List of adapter,address pairs which are unquestionably assumed to contain - a 'lm93' chip -* ignore: short array (min = 1, max = 48) - List of adapter,address pairs not to scan -* ignore_range: short array (min = 1, max = 48) - List of adapter,start-addr,end-addr triples not to scan -* probe: short array (min = 1, max = 48) - List of adapter,address pairs to scan additionally -* probe_range: short array (min = 1, max = 48) - List of adapter,start-addr,end-addr triples to scan additionally - Hardware Description -------------------- (from the datasheet) -The LM93, hardware monitor, has a two wire digital interface compatible with +The LM93 hardware monitor has a two wire digital interface compatible with SMBus 2.0. Using an 8-bit ADC, the LM93 measures the temperature of two remote diode connected transistors as well as its own die and 16 power supply voltages. To set fan speed, the LM93 has two PWM outputs that are each @@ -69,18 +51,12 @@ table based. The LM93 includes a digital filter that can be invoked to smooth temperature readings for better control of fan speed. The LM93 has four tachometer inputs to measure fan speed. Limit and status registers for all measured values are included. The LM93 builds upon the functionality of -previous motherboard management ASICs and uses some of the LM85 s features +previous motherboard management ASICs and uses some of the LM85's features (i.e. smart tachometer mode). It also adds measurement and control support for dynamic Vccp monitoring and PROCHOT. It is designed to monitor a dual processor Xeon class motherboard with a minimum of external components. -Driver Description ------------------- - -This driver implements support for the National Semiconductor LM93. - - User Interface -------------- @@ -101,7 +77,7 @@ These intervals can be found in the sysfs files prochot1_interval and prochot2_interval. The values in these files specify the intervals for #P1_PROCHOT and #P2_PROCHOT, respectively. Selecting a value not in this list will cause the driver to use the next largest interval. The available -intervals are: +intervals are (in seconds): #PROCHOT intervals: 0.73, 1.46, 2.9, 5.8, 11.7, 23.3, 46.6, 93.2, 186, 372 @@ -111,12 +87,12 @@ assert #P2_PROCHOT, and vice-versa. This mode is enabled by writing a non-zero integer to the sysfs file prochot_short. The LM93 can also override the #PROCHOT pins by driving a PWM signal onto -one or both of them. When overridden, the signal has a period of 3.56 mS, +one or both of them. When overridden, the signal has a period of 3.56 ms, a minimum pulse width of 5 clocks (at 22.5kHz => 6.25% duty cycle), and a maximum pulse width of 80 clocks (at 22.5kHz => 99.88% duty cycle). The sysfs files prochot1_override and prochot2_override contain boolean -intgers which enable or disable the override function for #P1_PROCHOT and +integers which enable or disable the override function for #P1_PROCHOT and #P2_PROCHOT, respectively. The sysfs file prochot_override_duty_cycle contains a value controlling the duty cycle for the PWM signal used when the override function is enabled. This value ranges from 0 to 15, with 0 @@ -166,7 +142,7 @@ frequency values are constrained by the hardware. Selecting a value which is not available will cause the driver to use the next largest value. Also note that this parameter has implications for the Smart Tach Mode (see above). -PWM Output Frequencies: 12, 36, 48, 60, 72, 84, 96, 22500 (h/w default) +PWM Output Frequencies (in Hz): 12, 36, 48, 60, 72, 84, 96, 22500 (default) Automatic PWM: @@ -178,7 +154,7 @@ individual control sources to which the PWM output is bound. The eight control sources are: temp1-temp4 (aka "zones" in the datasheet), #PROCHOT 1 & 2, and #VRDHOT 1 & 2. The bindings are expressed as a bitmask in the sysfs files pwm_auto_channels, where a "1" enables the binding, and - a "0" disables it. The h/w default is 0x0f (all temperatures bound). +a "0" disables it. The h/w default is 0x0f (all temperatures bound). 0x01 - Temp 1 0x02 - Temp 2 @@ -324,89 +300,3 @@ LM93 Unique sysfs Files gpio input state of 8 GPIO pins; read-only - -Sample Configuration File -------------------------- - -Here is a sample LM93 chip config for sensors.conf: - ----------- cut here ---------- -chip "lm93-*" - -# VOLTAGE INPUTS - - # labels and scaling based on datasheet recommendations - label in1 "+12V1" - compute in1 @ * 12.945, @ / 12.945 - set in1_min 12 * 0.90 - set in1_max 12 * 1.10 - - label in2 "+12V2" - compute in2 @ * 12.945, @ / 12.945 - set in2_min 12 * 0.90 - set in2_max 12 * 1.10 - - label in3 "+12V3" - compute in3 @ * 12.945, @ / 12.945 - set in3_min 12 * 0.90 - set in3_max 12 * 1.10 - - label in4 "FSB_Vtt" - - label in5 "3GIO" - - label in6 "ICH_Core" - - label in7 "Vccp1" - - label in8 "Vccp2" - - label in9 "+3.3V" - set in9_min 3.3 * 0.90 - set in9_max 3.3 * 1.10 - - label in10 "+5V" - set in10_min 5.0 * 0.90 - set in10_max 5.0 * 1.10 - - label in11 "SCSI_Core" - - label in12 "Mem_Core" - - label in13 "Mem_Vtt" - - label in14 "Gbit_Core" - - # Assuming R1/R2 = 4.1143, and 3.3V reference - # -12V = (4.1143 + 1) * (@ - 3.3) + 3.3 - label in15 "-12V" - compute in15 @ * 5.1143 - 13.57719, (@ + 13.57719) / 5.1143 - set in15_min -12 * 0.90 - set in15_max -12 * 1.10 - - label in16 "+3.3VSB" - set in16_min 3.3 * 0.90 - set in16_max 3.3 * 1.10 - -# TEMPERATURE INPUTS - - label temp1 "CPU1" - label temp2 "CPU2" - label temp3 "LM93" - -# TACHOMETER INPUTS - - label fan1 "Fan1" - set fan1_min 3000 - label fan2 "Fan2" - set fan2_min 3000 - label fan3 "Fan3" - set fan3_min 3000 - label fan4 "Fan4" - set fan4_min 3000 - -# PWM OUTPUTS - - label pwm1 "CPU1" - label pwm2 "CPU2" - -- cgit v1.2.3 From 176544dc55b0a912a2e1bacb9f48ccbd4aabd55f Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Mon, 20 Aug 2007 16:44:44 +0200 Subject: hwmon: Update the sysfs interface documentation * Document the name attribute. * Document the *_label attributes. * Drop "typical usage" lists, they no longer match the reality. * Drop non hardware-monitoring related entries. Signed-off-by: Jean Delvare Acked-by: Hans de Goede Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/sysfs-interface | 75 ++++++++++++++++++++----------------- 1 file changed, 41 insertions(+), 34 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index 331fa7a1d7d5..db7bb4a659c4 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -78,8 +78,21 @@ RW read/write value Read/write values may be read-only for some chips, depending on the hardware implementation. -All entries are optional, and should only be created in a given driver -if the chip has the feature. +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 * @@ -104,18 +117,17 @@ in[0-*]_input Voltage input value. 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 + 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 @@ -159,6 +171,13 @@ fan[1-*]_target 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. @@ -260,18 +279,19 @@ temp[1-*]_crit_hyst from the critical value. RW -temp[1-4]_offset +temp[1-*]_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. +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 @@ -391,16 +411,3 @@ beep_mask Bitmask for beep. 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 -- cgit v1.2.3 From 6438312367523b26bd628b60cfd16f25a7a6f7ae Mon Sep 17 00:00:00 2001 From: Charles Spirakis Date: Tue, 4 Sep 2007 13:31:56 -0700 Subject: hwmon: (w83791d) new sysfs beep/alarm methodology Add new sysfs alarm methodology to w83791d driver Signed-off-by: Charles Spirakis Acked-by: Jean Delvare Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/w83791d | 96 +++++++++++++++++++++++++++------------------ 1 file changed, 57 insertions(+), 39 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d index db9881df88a5..f153b2f6d62c 100644 --- a/Documentation/hwmon/w83791d +++ b/Documentation/hwmon/w83791d @@ -75,46 +75,64 @@ Voltage sensors (also known as IN sensors) report their values in millivolts. An alarm is triggered if the voltage has crossed a programmable minimum or maximum limit. -The bit ordering for the alarm "realtime status register" and the -"beep enable registers" are different. - -in0 (VCORE) : alarms: 0x000001 beep_enable: 0x000001 -in1 (VINR0) : alarms: 0x000002 beep_enable: 0x002000 <== mismatch -in2 (+3.3VIN): alarms: 0x000004 beep_enable: 0x000004 -in3 (5VDD) : alarms: 0x000008 beep_enable: 0x000008 -in4 (+12VIN) : alarms: 0x000100 beep_enable: 0x000100 -in5 (-12VIN) : alarms: 0x000200 beep_enable: 0x000200 -in6 (-5VIN) : alarms: 0x000400 beep_enable: 0x000400 -in7 (VSB) : alarms: 0x080000 beep_enable: 0x010000 <== mismatch -in8 (VBAT) : alarms: 0x100000 beep_enable: 0x020000 <== mismatch -in9 (VINR1) : alarms: 0x004000 beep_enable: 0x004000 -temp1 : alarms: 0x000010 beep_enable: 0x000010 -temp2 : alarms: 0x000020 beep_enable: 0x000020 -temp3 : alarms: 0x002000 beep_enable: 0x000002 <== mismatch -fan1 : alarms: 0x000040 beep_enable: 0x000040 -fan2 : alarms: 0x000080 beep_enable: 0x000080 -fan3 : alarms: 0x000800 beep_enable: 0x000800 -fan4 : alarms: 0x200000 beep_enable: 0x200000 -fan5 : alarms: 0x400000 beep_enable: 0x400000 -tart1 : alarms: 0x010000 beep_enable: 0x040000 <== mismatch -tart2 : alarms: 0x020000 beep_enable: 0x080000 <== mismatch -tart3 : alarms: 0x040000 beep_enable: 0x100000 <== mismatch -case_open : alarms: 0x001000 beep_enable: 0x001000 -user_enable : alarms: -------- beep_enable: 0x800000 - -*** NOTE: It is the responsibility of user-space code to handle the fact -that the beep enable and alarm bits are in different positions when using that -feature of the chip. - -When an alarm goes off, you can be warned by a beeping signal through your -computer speaker. It is possible to enable all beeping globally, or only -the beeping for some alarms. - -The driver only reads the chip values each 3 seconds; reading them more -often will do no harm, but will return 'old' values. +The w83791d has a global bit used to enable beeping from the speaker when an +alarm is triggered as well as a bitmask to enable or disable the beep for +specific alarms. You need both the global beep enable bit and the +corresponding beep bit to be on for a triggered alarm to sound a beep. + +The sysfs interface to the gloabal enable is via the sysfs beep_enable file. +This file is used for both legacy and new code. + +The sysfs interface to the beep bitmask has migrated from the original legacy +method of a single sysfs beep_mask file to a newer method using multiple +*_beep files as described in .../Documentation/hwmon/sysfs-interface. + +A similar change has occured for the bitmap corresponding to the alarms. The +original legacy method used a single sysfs alarms file containing a bitmap +of triggered alarms. The newer method uses multiple sysfs *_alarm files +(again following the pattern described in sysfs-interface). + +Since both methods read and write the underlying hardware, they can be used +interchangeably and changes in one will automatically be reflected by +the other. If you use the legacy bitmask method, your user-space code is +responsible for handling the fact that the alarms and beep_mask bitmaps +are not the same (see the table below). + +NOTE: All new code should be written to use the newer sysfs-interface +specification as that avoids bitmap problems and is the preferred interface +going forward. + +The driver reads the hardware chip values at most once every three seconds. +User mode code requesting values more often will receive cached values. + +Alarms bitmap vs. beep_mask bitmask +------------------------------------ +For legacy code using the alarms and beep_mask files: + +in0 (VCORE) : alarms: 0x000001 beep_mask: 0x000001 +in1 (VINR0) : alarms: 0x000002 beep_mask: 0x002000 <== mismatch +in2 (+3.3VIN): alarms: 0x000004 beep_mask: 0x000004 +in3 (5VDD) : alarms: 0x000008 beep_mask: 0x000008 +in4 (+12VIN) : alarms: 0x000100 beep_mask: 0x000100 +in5 (-12VIN) : alarms: 0x000200 beep_mask: 0x000200 +in6 (-5VIN) : alarms: 0x000400 beep_mask: 0x000400 +in7 (VSB) : alarms: 0x080000 beep_mask: 0x010000 <== mismatch +in8 (VBAT) : alarms: 0x100000 beep_mask: 0x020000 <== mismatch +in9 (VINR1) : alarms: 0x004000 beep_mask: 0x004000 +temp1 : alarms: 0x000010 beep_mask: 0x000010 +temp2 : alarms: 0x000020 beep_mask: 0x000020 +temp3 : alarms: 0x002000 beep_mask: 0x000002 <== mismatch +fan1 : alarms: 0x000040 beep_mask: 0x000040 +fan2 : alarms: 0x000080 beep_mask: 0x000080 +fan3 : alarms: 0x000800 beep_mask: 0x000800 +fan4 : alarms: 0x200000 beep_mask: 0x200000 +fan5 : alarms: 0x400000 beep_mask: 0x400000 +tart1 : alarms: 0x010000 beep_mask: 0x040000 <== mismatch +tart2 : alarms: 0x020000 beep_mask: 0x080000 <== mismatch +tart3 : alarms: 0x040000 beep_mask: 0x100000 <== mismatch +case_open : alarms: 0x001000 beep_mask: 0x001000 +global_enable: alarms: -------- beep_mask: 0x800000 (modified via beep_enable) W83791D TODO: --------------- -Provide a patch for per-file alarms and beep enables as defined in the hwmon - documentation (Documentation/hwmon/sysfs-interface) Provide a patch for smart-fan control (still need appropriate motherboard/fans) -- cgit v1.2.3 From c7f1f7166a83f8f5607cc03c7a6c5f936cde6b0d Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Mon, 3 Sep 2007 17:11:46 +0200 Subject: hwmon: (it87) Add support for fan4 and fan5 Add support for the IT8716F and IT8718F fan4 and fan5. The late revisions of the IT8712F have these too but support is harder to add and nobody asked for it yet, so I didn't include it. Signed-off-by: Jean Delvare Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/it87 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 81ecc7e41c50..5b704a40256b 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -90,7 +90,8 @@ upper VID bits share their pins with voltage inputs (in5 and in6) so you can't have both on a given board. The IT8716F, IT8718F and later IT8712F revisions have support for -2 additional fans. They are not yet supported by the driver. +2 additional fans. They are supported by the driver for the IT8716F and +IT8718F but not for the IT8712F The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional 16-bit tachometer counters for fans 1 to 3. This is better (no more fan -- cgit v1.2.3 From 428a7039c5717695935b946af9413e59f68928a4 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Tue, 4 Sep 2007 23:25:33 +0200 Subject: hwmon: (lm78) Add individual alarm files Add individual alarm files to the lm78 driver, these are needed by the next version of libsensors. Signed-off-by: Jean Delvare Acked-by: Hans de Goede Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/lm78 | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm78 b/Documentation/hwmon/lm78 index fd5dc7a19f0e..dfc318a60fd4 100644 --- a/Documentation/hwmon/lm78 +++ b/Documentation/hwmon/lm78 @@ -56,16 +56,6 @@ should work with. This is hardcoded by the mainboard and/or processor itself. It is a value in volts. When it is unconnected, you will often find the value 3.50 V here. -In addition to the alarms described above, there are a couple of additional -ones. There is a BTI alarm, which gets triggered when an external chip has -crossed its limits. Usually, this is connected to all LM75 chips; if at -least one crosses its limits, this bit gets set. The CHAS alarm triggers -if your computer case is open. The FIFO alarms should never trigger; it -indicates an internal error. The SMI_IN alarm indicates some other chip -has triggered an SMI interrupt. As we do not use SMI interrupts at all, -this condition usually indicates there is a problem with some other -device. - If an alarm triggers, it will remain triggered until the hardware register is read at least once. This means that the cause for the alarm may already have disappeared! Note that in the current implementation, all -- cgit v1.2.3 From 2ed4263308971af3a7a0f20bef6b2257ea230a71 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Fri, 21 Sep 2007 17:03:32 +0200 Subject: hwmon: update sysfs interface document - error handling Here is a patch adding some text to the sysfs interface documentation on how settings written to sysfs attributes should be handled, focussing mainly on error handling. This version incorperates Jean's latest comments. Signed-off-by: Hans de Goede Acked-by: Jean Delvare Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/sysfs-interface | 58 +++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index db7bb4a659c4..a2153c4616ad 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -67,6 +67,10 @@ 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. ------------------------------------------------------------------------- @@ -411,3 +415,57 @@ beep_mask Bitmask for beep. 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): +--- begin code --- +long v = simple_strtol(buf, NULL, 10) / 1000; +SENSORS_LIMIT(v, -128, 127); +/* write v to register */ +--- end code --- + +Example2, fan divider setting, valid values 2, 4 and 8: +--- begin code --- +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 */ +--- end code --- -- cgit v1.2.3 From 5fbea518dab712af63076aed897fce89cd7faec3 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sun, 7 Oct 2007 22:44:33 +0200 Subject: hwmon: Fix the code examples in documentation Fix a bug in the code examples, make them comply with CodingStyle, and indent them for a better redability. Signed-off-by: Jean Delvare Acked-by: Hans de Goede Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/sysfs-interface | 32 +++++++++++++++----------------- 1 file changed, 15 insertions(+), 17 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index a2153c4616ad..a17b692d2679 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -450,22 +450,20 @@ 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): ---- begin code --- -long v = simple_strtol(buf, NULL, 10) / 1000; -SENSORS_LIMIT(v, -128, 127); -/* write v to register */ ---- end code --- + + 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: ---- begin code --- -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 */ ---- end code --- + + 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 */ -- cgit v1.2.3 From c940336b4403540c498fceb102c7142799252129 Mon Sep 17 00:00:00 2001 From: Rudolf Marek Date: Sun, 7 Oct 2007 13:42:09 +0200 Subject: hwmon: (coretemp) Add support for Celeron 4xx This patch adds support for the Celeron 4xx based on Core 2 core. Signed-off-by: Rudolf Marek Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/coretemp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index 870cda9416e9..170bf862437b 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp @@ -4,7 +4,7 @@ Kernel driver coretemp Supported chips: * All Intel Core family Prefix: 'coretemp' - CPUID: family 0x6, models 0xe, 0xf + CPUID: family 0x6, models 0xe, 0xf, 0x16 Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide -- cgit v1.2.3 From e95c237d78c0dc8fc0ae1207cec87af7a37dd366 Mon Sep 17 00:00:00 2001 From: Juerg Haefliger Date: Sun, 7 Oct 2007 21:27:35 -0700 Subject: hwmon: (dme1737) Add sch311x support This patch adds support for the SMSC SCH3112, SCH3114, and SCH3116 Super-I/O chips. These chips feature identical hardware monitoring capabilites with the expection that some of the fan inputs and pmw outputs don't exist. The hardware monitoring features of the SCH311x chips can only be accessed via the ISA bus. The driver therefore registers as a platform driver, if such a chip is detected. Signed-off-by: Juerg Haefliger Acked-by: Jean Delvare Signed-off-by: Mark M. Hoffman --- Documentation/hwmon/dme1737 | 33 +++++++++++++++++++++++---------- 1 file changed, 23 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/dme1737 b/Documentation/hwmon/dme1737 index 1a0f3d64ab80..8f446070e64a 100644 --- a/Documentation/hwmon/dme1737 +++ b/Documentation/hwmon/dme1737 @@ -6,6 +6,10 @@ Supported chips: Prefix: 'dme1737' Addresses scanned: I2C 0x2c, 0x2d, 0x2e Datasheet: Provided by SMSC upon request and under NDA + * SMSC SCH3112, SCH3114, SCH3116 + Prefix: 'sch311x' + Addresses scanned: none, address read from Super-I/O config space + Datasheet: http://www.nuhorizons.com/FeaturedProducts/Volume1/SMSC/311x.pdf Authors: Juerg Haefliger @@ -27,16 +31,25 @@ Description ----------- This driver implements support for the hardware monitoring capabilities of the -SMSC DME1737 and Asus A8000 (which are the same) Super-I/O chips. This chip -features monitoring of 3 temp sensors temp[1-3] (2 remote diodes and 1 -internal), 7 voltages in[0-6] (6 external and 1 internal) and 6 fan speeds -fan[1-6]. Additionally, the chip implements 5 PWM outputs pwm[1-3,5-6] for -controlling fan speeds both manually and automatically. - -Fan[3-6] and pwm[3,5-6] are optional features and their availability is -dependent on the configuration of the chip. The driver will detect which -features are present during initialization and create the sysfs attributes -accordingly. +SMSC DME1737 and Asus A8000 (which are the same) and SMSC SCH311x Super-I/O +chips. These chips feature monitoring of 3 temp sensors temp[1-3] (2 remote +diodes and 1 internal), 7 voltages in[0-6] (6 external and 1 internal) and up +to 6 fan speeds fan[1-6]. Additionally, the chips implement up to 5 PWM +outputs pwm[1-3,5-6] for controlling fan speeds both manually and +automatically. + +For the DME1737 and A8000, fan[1-2] and pwm[1-2] are always present. Fan[3-6] +and pwm[3,5-6] are optional features and their availability depends on the +configuration of the chip. The driver will detect which features are present +during initialization and create the sysfs attributes accordingly. + +For the SCH311x, fan[1-3] and pwm[1-3] are always present and fan[4-6] and +pwm[5-6] don't exist. + +The hardware monitoring features of the DME1737 and A8000 are only accessible +via SMBus, while the SCH311x only provides access via the ISA bus. The driver +will therefore register itself as an I2C client driver if it detects a DME1737 +or A8000 and as a platform driver if it detects a SCH311x chip. Voltage Monitoring -- cgit v1.2.3