aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/hwmon
diff options
context:
space:
mode:
authorLucas De Marchi <lucas.demarchi@profusion.mobi>2011-03-30 21:57:33 -0400
committerLucas De Marchi <lucas.demarchi@profusion.mobi>2011-03-31 10:26:23 -0400
commit25985edcedea6396277003854657b5f3cb31a628 (patch)
treef026e810210a2ee7290caeb737c23cb6472b7c38 /Documentation/hwmon
parent6aba74f2791287ec407e0f92487a725a25908067 (diff)
Fix common misspellings
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Diffstat (limited to 'Documentation/hwmon')
-rw-r--r--Documentation/hwmon/abituguru2
-rw-r--r--Documentation/hwmon/abituguru-datasheet8
-rw-r--r--Documentation/hwmon/abituguru32
-rw-r--r--Documentation/hwmon/pmbus6
-rw-r--r--Documentation/hwmon/sysfs-interface2
-rw-r--r--Documentation/hwmon/w83781d2
-rw-r--r--Documentation/hwmon/w83791d2
7 files changed, 12 insertions, 12 deletions
diff --git a/Documentation/hwmon/abituguru b/Documentation/hwmon/abituguru
index 5eb3b9d5f0d..915f32063a2 100644
--- a/Documentation/hwmon/abituguru
+++ b/Documentation/hwmon/abituguru
@@ -78,7 +78,7 @@ motherboards (most modern Abit motherboards).
78 78
79The first and second revision of the uGuru chip in reality is a Winbond 79The first and second revision of the uGuru chip in reality is a Winbond
80W83L950D in disguise (despite Abit claiming it is "a new microprocessor 80W83L950D in disguise (despite Abit claiming it is "a new microprocessor
81designed by the ABIT Engineers"). Unfortunatly this doesn't help since the 81designed by the ABIT Engineers"). Unfortunately this doesn't help since the
82W83L950D is a generic microcontroller with a custom Abit application running 82W83L950D is a generic microcontroller with a custom Abit application running
83on it. 83on it.
84 84
diff --git a/Documentation/hwmon/abituguru-datasheet b/Documentation/hwmon/abituguru-datasheet
index d9251efdcec..8d2be8a0b1e 100644
--- a/Documentation/hwmon/abituguru-datasheet
+++ b/Documentation/hwmon/abituguru-datasheet
@@ -5,9 +5,9 @@ First of all, what I know about uGuru is no fact based on any help, hints or
5datasheet from Abit. The data I have got on uGuru have I assembled through 5datasheet from Abit. The data I have got on uGuru have I assembled through
6my weak knowledge in "backwards engineering". 6my weak knowledge in "backwards engineering".
7And just for the record, you may have noticed uGuru isn't a chip developed by 7And just for the record, you may have noticed uGuru isn't a chip developed by
8Abit, as they claim it to be. It's realy just an microprocessor (uC) created by 8Abit, as they claim it to be. It's really just an microprocessor (uC) created by
9Winbond (W83L950D). And no, reading the manual for this specific uC or 9Winbond (W83L950D). And no, reading the manual for this specific uC or
10mailing Windbond for help won't give any usefull data about uGuru, as it is 10mailing Windbond for help won't give any useful data about uGuru, as it is
11the program inside the uC that is responding to calls. 11the program inside the uC that is responding to calls.
12 12
13Olle Sandberg <ollebull@gmail.com>, 2005-05-25 13Olle Sandberg <ollebull@gmail.com>, 2005-05-25
@@ -41,7 +41,7 @@ later on attached again data-port will hold 0x08, more about this later.
41 41
42After wider testing of the Linux kernel driver some variants of the uGuru have 42After wider testing of the Linux kernel driver some variants of the uGuru have
43turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also 43turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also
44have to test CMD for two different values. On these uGuru's DATA will initally 44have to test CMD for two different values. On these uGuru's DATA will initially
45hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read 45hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read
46first! 46first!
47 47
@@ -308,5 +308,5 @@ the voltage / clock programming out, I tried reading and only reading banks
308resulted in a _permanent_ reprogramming of the voltages, luckily I had the 308resulted in a _permanent_ reprogramming of the voltages, luckily I had the
309sensors part configured so that it would shutdown my system on any out of spec 309sensors part configured so that it would shutdown my system on any out of spec
310voltages which proprably safed my computer (after a reboot I managed to 310voltages which proprably safed my computer (after a reboot I managed to
311immediatly enter the bios and reload the defaults). This probably means that 311immediately enter the bios and reload the defaults). This probably means that
312the read/write cycle for the non sensor part is different from the sensor part. 312the read/write cycle for the non sensor part is different from the sensor part.
diff --git a/Documentation/hwmon/abituguru3 b/Documentation/hwmon/abituguru3
index fa598aac22f..a6ccfe4bb6a 100644
--- a/Documentation/hwmon/abituguru3
+++ b/Documentation/hwmon/abituguru3
@@ -47,7 +47,7 @@ This driver supports the hardware monitoring features of the third revision of
47the Abit uGuru chip, found on recent Abit uGuru featuring motherboards. 47the Abit uGuru chip, found on recent Abit uGuru featuring motherboards.
48 48
49The 3rd revision of the uGuru chip in reality is a Winbond W83L951G. 49The 3rd revision of the uGuru chip in reality is a Winbond W83L951G.
50Unfortunatly this doesn't help since the W83L951G is a generic microcontroller 50Unfortunately this doesn't help since the W83L951G is a generic microcontroller
51with a custom Abit application running on it. 51with a custom Abit application running on it.
52 52
53Despite Abit not releasing any information regarding the uGuru revision 3, 53Despite Abit not releasing any information regarding the uGuru revision 3,
diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus
index f2d42e8bdf4..dc4933e9634 100644
--- a/Documentation/hwmon/pmbus
+++ b/Documentation/hwmon/pmbus
@@ -150,11 +150,11 @@ The following attributes are supported. Limits are read-write; all other
150attributes are read-only. 150attributes are read-only.
151 151
152inX_input Measured voltage. From READ_VIN or READ_VOUT register. 152inX_input Measured voltage. From READ_VIN or READ_VOUT register.
153inX_min Minumum Voltage. 153inX_min Minimum Voltage.
154 From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register. 154 From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register.
155inX_max Maximum voltage. 155inX_max Maximum voltage.
156 From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register. 156 From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register.
157inX_lcrit Critical minumum Voltage. 157inX_lcrit Critical minimum Voltage.
158 From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register. 158 From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register.
159inX_crit Critical maximum voltage. 159inX_crit Critical maximum voltage.
160 From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register. 160 From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register.
@@ -169,7 +169,7 @@ inX_label "vin", "vcap", or "voutY"
169currX_input Measured current. From READ_IIN or READ_IOUT register. 169currX_input Measured current. From READ_IIN or READ_IOUT register.
170currX_max Maximum current. 170currX_max Maximum current.
171 From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register. 171 From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register.
172currX_lcrit Critical minumum output current. 172currX_lcrit Critical minimum output current.
173 From IOUT_UC_FAULT_LIMIT register. 173 From IOUT_UC_FAULT_LIMIT register.
174currX_crit Critical maximum current. 174currX_crit Critical maximum current.
175 From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register. 175 From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register.
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index 83a698773ad..8f63c244f1a 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -579,7 +579,7 @@ channel should not be trusted.
579fan[1-*]_fault 579fan[1-*]_fault
580temp[1-*]_fault 580temp[1-*]_fault
581 Input fault condition 581 Input fault condition
582 0: no fault occured 582 0: no fault occurred
583 1: fault condition 583 1: fault condition
584 RO 584 RO
585 585
diff --git a/Documentation/hwmon/w83781d b/Documentation/hwmon/w83781d
index ecbc1e4574b..129b0a3b555 100644
--- a/Documentation/hwmon/w83781d
+++ b/Documentation/hwmon/w83781d
@@ -403,7 +403,7 @@ found out the following values do work as a form of coarse pwm:
403 403
4040x80 - seems to turn fans off after some time(1-2 minutes)... might be 4040x80 - seems to turn fans off after some time(1-2 minutes)... might be
405some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an 405some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an
406old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attemp at Qfan 406old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attempt at Qfan
407that was dropped at the BIOS) 407that was dropped at the BIOS)
4080x81 - off 4080x81 - off
4090x82 - slightly "on-ner" than off, but my fans do not get to move. I can 4090x82 - slightly "on-ner" than off, but my fans do not get to move. I can
diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d
index 5663e491655..90387c3540f 100644
--- a/Documentation/hwmon/w83791d
+++ b/Documentation/hwmon/w83791d
@@ -93,7 +93,7 @@ The sysfs interface to the beep bitmask has migrated from the original legacy
93method of a single sysfs beep_mask file to a newer method using multiple 93method of a single sysfs beep_mask file to a newer method using multiple
94*_beep files as described in .../Documentation/hwmon/sysfs-interface. 94*_beep files as described in .../Documentation/hwmon/sysfs-interface.
95 95
96A similar change has occured for the bitmap corresponding to the alarms. The 96A similar change has occurred for the bitmap corresponding to the alarms. The
97original legacy method used a single sysfs alarms file containing a bitmap 97original legacy method used a single sysfs alarms file containing a bitmap
98of triggered alarms. The newer method uses multiple sysfs *_alarm files 98of triggered alarms. The newer method uses multiple sysfs *_alarm files
99(again following the pattern described in sysfs-interface). 99(again following the pattern described in sysfs-interface).