diff options
Diffstat (limited to 'Documentation/hwmon')
| -rw-r--r-- | Documentation/hwmon/abituguru | 2 | ||||
| -rw-r--r-- | Documentation/hwmon/abituguru-datasheet | 8 | ||||
| -rw-r--r-- | Documentation/hwmon/abituguru3 | 2 | ||||
| -rw-r--r-- | Documentation/hwmon/pmbus | 6 | ||||
| -rw-r--r-- | Documentation/hwmon/sysfs-interface | 2 | ||||
| -rw-r--r-- | Documentation/hwmon/w83781d | 2 | ||||
| -rw-r--r-- | Documentation/hwmon/w83791d | 2 |
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). The first and second revision of the uGuru chip in reality is a Winbond W83L950D in disguise (despite Abit claiming it is "a new microprocessor -designed by the ABIT Engineers"). Unfortunatly this doesn't help since the +designed by the ABIT Engineers"). Unfortunately this doesn't help since the W83L950D is a generic microcontroller with a custom Abit application running on it. 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 datasheet from Abit. The data I have got on uGuru have I assembled through my weak knowledge in "backwards engineering". And just for the record, you may have noticed uGuru isn't a chip developed by -Abit, as they claim it to be. It's realy just an microprocessor (uC) created by +Abit, as they claim it to be. It's really just an microprocessor (uC) created by Winbond (W83L950D). And no, reading the manual for this specific uC or -mailing Windbond for help won't give any usefull data about uGuru, as it is +mailing Windbond for help won't give any useful data about uGuru, as it is the program inside the uC that is responding to calls. Olle Sandberg <ollebull@gmail.com>, 2005-05-25 @@ -41,7 +41,7 @@ later on attached again data-port will hold 0x08, more about this later. After wider testing of the Linux kernel driver some variants of the uGuru have turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also -have to test CMD for two different values. On these uGuru's DATA will initally +have to test CMD for two different values. On these uGuru's DATA will initially hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read first! @@ -308,5 +308,5 @@ the voltage / clock programming out, I tried reading and only reading banks resulted in a _permanent_ reprogramming of the voltages, luckily I had the sensors part configured so that it would shutdown my system on any out of spec voltages which proprably safed my computer (after a reboot I managed to -immediatly enter the bios and reload the defaults). This probably means that +immediately enter the bios and reload the defaults). This probably means that the 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 the Abit uGuru chip, found on recent Abit uGuru featuring motherboards. The 3rd revision of the uGuru chip in reality is a Winbond W83L951G. -Unfortunatly this doesn't help since the W83L951G is a generic microcontroller +Unfortunately this doesn't help since the W83L951G is a generic microcontroller with a custom Abit application running on it. Despite 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 attributes are read-only. inX_input Measured voltage. From READ_VIN or READ_VOUT register. -inX_min Minumum Voltage. +inX_min Minimum Voltage. From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register. inX_max Maximum voltage. From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register. -inX_lcrit Critical minumum Voltage. +inX_lcrit Critical minimum Voltage. From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register. inX_crit Critical maximum voltage. From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register. @@ -169,7 +169,7 @@ inX_label "vin", "vcap", or "voutY" currX_input Measured current. From READ_IIN or READ_IOUT register. currX_max Maximum current. From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register. -currX_lcrit Critical minumum output current. +currX_lcrit Critical minimum output current. From IOUT_UC_FAULT_LIMIT register. currX_crit Critical maximum current. 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. fan[1-*]_fault temp[1-*]_fault Input fault condition - 0: no fault occured + 0: no fault occurred 1: fault condition RO 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: 0x80 - seems to turn fans off after some time(1-2 minutes)... might be some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an -old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attemp at Qfan +old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attempt at Qfan that was dropped at the BIOS) 0x81 - off 0x82 - 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 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 +A similar change has occurred 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). |