aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/hwmon/abituguru
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--Documentation/hwmon/abituguru2
-rw-r--r--Documentation/hwmon/abituguru-datasheet8
-rw-r--r--Documentation/hwmon/abituguru32
3 files changed, 6 insertions, 6 deletions
diff --git a/Documentation/hwmon/abituguru b/Documentation/hwmon/abituguru
index 5eb3b9d5f0d5..915f32063a26 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 d9251efdcec7..8d2be8a0b1e3 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 fa598aac22fa..a6ccfe4bb6aa 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,