Fix common misspellings

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>

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).