[PATCH] docs: Fix spelling and grammatical issues

[PATCH] docs: Fix spelling and grammatical issues

[Purva Yeshi]

Fix several spelling and grammatical errors across multiple
documentation files.

Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
---
 Documentation/hid/hiddev.rst                | 4 ++--
 Documentation/hid/intel-ish-hid.rst         | 2 +-
 Documentation/hid/uhid.rst                  | 2 +-
 Documentation/hwmon/abituguru-datasheet.rst | 8 ++++----
 Documentation/hwmon/abituguru.rst           | 2 +-
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
index 9b82c7f896aa..073485f84793 100644
--- a/Documentation/hid/hiddev.rst
+++ b/Documentation/hid/hiddev.rst
@@ -15,10 +15,10 @@ To support these disparate requirements, the Linux USB system provides
 HID events to two separate interfaces:
 * the input subsystem, which converts HID events into normal input
 device interfaces (such as keyboard, mouse and joystick) and a
-normalised event interface - see Documentation/input/input.rst
+normalized event interface - see Documentation/input/input.rst
 * the hiddev interface, which provides fairly raw HID events
 
-The data flow for a HID event produced by a device is something like
+The data flow for an HID event produced by a device is something like
 the following::
 
  usb.c ---> hid-core.c  ----> hid-input.c ----> [keyboard/mouse/joystick/event]
diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst
index 2adc174fb576..fdabf6ec60db 100644
--- a/Documentation/hid/intel-ish-hid.rst
+++ b/Documentation/hid/intel-ish-hid.rst
@@ -21,7 +21,7 @@ mainly use HID over I2C or USB. But ISH doesn't use either I2C or USB.
 Overview
 ========
 
-Using a analogy with a usbhid implementation, the ISH follows a similar model
+Using an analogy with a usbhid implementation, the ISH follows a similar model
 for a very high speed communication::
 
 	-----------------		----------------------
diff --git a/Documentation/hid/uhid.rst b/Documentation/hid/uhid.rst
index 2243a6b75914..2681038cd526 100644
--- a/Documentation/hid/uhid.rst
+++ b/Documentation/hid/uhid.rst
@@ -106,7 +106,7 @@ UHID_INPUT2:
 
 UHID_GET_REPORT_REPLY:
   If you receive a UHID_GET_REPORT request you must answer with this request.
-  You  must copy the "id" field from the request into the answer. Set the "err"
+  You must copy the "id" field from the request into the answer. Set the "err"
   field to 0 if no error occurred or to EIO if an I/O error occurred.
   If "err" is 0 then you should fill the buffer of the answer with the results
   of the GET_REPORT request and set "size" correspondingly.
diff --git a/Documentation/hwmon/abituguru-datasheet.rst b/Documentation/hwmon/abituguru-datasheet.rst
index 0cd61471d2a2..8c55874061d4 100644
--- a/Documentation/hwmon/abituguru-datasheet.rst
+++ b/Documentation/hwmon/abituguru-datasheet.rst
@@ -6,9 +6,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 really just an microprocessor (uC) created by
+Abit, as they claim it to be. It's really just a microprocessor (uC) created by
 Winbond (W83L950D). And no, reading the manual for this specific uC or
-mailing  Windbond for help won't give any useful data about uGuru, as it is
+mailing  Winbond 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
@@ -35,7 +35,7 @@ As far as known the uGuru is always placed at and using the (ISA) I/O-ports
 ports are holding for detection. We will refer to 0xE0 as CMD (command-port)
 and 0xE4 as DATA because Abit refers to them with these names.
 
-If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC an uGuru could be
+If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC a uGuru could be
 present. We have to check for two different values at data-port, because
 after a reboot uGuru will hold 0x00 here, but if the driver is removed and
 later on attached again data-port will hold 0x08, more about this later.
@@ -46,7 +46,7 @@ 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!
 
-To be really sure an uGuru is present a test read of one or more register
+To be really sure a uGuru is present a test read of one or more register
 sets should be done.
 
 
diff --git a/Documentation/hwmon/abituguru.rst b/Documentation/hwmon/abituguru.rst
index cfda60b757ce..4a5ee16b1048 100644
--- a/Documentation/hwmon/abituguru.rst
+++ b/Documentation/hwmon/abituguru.rst
@@ -40,7 +40,7 @@ Supported chips:
 
 .. [2]  There is a separate abituguru3 driver for these motherboards,
 	the abituguru (without the 3 !) driver will not work on these
-	motherboards (and visa versa)!
+	motherboards (and vice versa)!
 
 Authors:
 	- Hans de Goede <j.w.r.degoede@hhs.nl>,
-- 
2.34.1

Re: [PATCH] docs: Fix spelling and grammatical issues

[Greg KH]

On Tue, Feb 04, 2025 at 07:18:06PM +0530, Purva Yeshi wrote:
> Fix several spelling and grammatical errors across multiple
> documentation files.
> 
> Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch did many different things all at once, making it difficult
  to review.  All Linux kernel patches need to only do one thing at a
  time.  If you need to do multiple things (such as clean up all coding
  style issues in a file/driver), do it in a sequence of patches, each
  one doing only one thing.  This will make it easier to review the
  patches to ensure that they are correct, and to help alleviate any
  merge issues that larger patches can cause.


If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [PATCH] docs: Fix spelling and grammatical issues

[Purva Yeshi]

On 04/02/25 19:37, Greg KH wrote:
> On Tue, Feb 04, 2025 at 07:18:06PM +0530, Purva Yeshi wrote:
>> Fix several spelling and grammatical errors across multiple
>> documentation files.
>>
>> Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
> 
> Hi,
> 
> This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
> a patch that has triggered this response.  He used to manually respond
> to these common problems, but in order to save his sanity (he kept
> writing the same thing over and over, yet to different people), I was
> created.  Hopefully you will not take offence and will fix the problem
> in your patch and resubmit it so that it can be accepted into the Linux
> kernel tree.
> 
> You are receiving this message because of the following common error(s)
> as indicated below:
> 
> - Your patch did many different things all at once, making it difficult
>    to review.  All Linux kernel patches need to only do one thing at a
>    time.  If you need to do multiple things (such as clean up all coding
>    style issues in a file/driver), do it in a sequence of patches, each
>    one doing only one thing.  This will make it easier to review the
>    patches to ensure that they are correct, and to help alleviate any
>    merge issues that larger patches can cause.
> 
> 
> If you wish to discuss this problem further, or you have questions about
> how to resolve this issue, please feel free to respond to this email and
> Greg will reply once he has dug out from the pending patches received
> from other developers.
> 
> thanks,
> 
> greg k-h's patch email bot

I understand and will split my patch into smaller, logically grouped 
changes to make the review process easier. I will resend the patches 
accordingly.

Re: [PATCH] docs: Fix spelling and grammatical issues

[Guenter Roeck]

On 2/4/25 05:48, Purva Yeshi wrote:
> Fix several spelling and grammatical errors across multiple
> documentation files.
> 
> Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
> ---
>   Documentation/hid/hiddev.rst                | 4 ++--
>   Documentation/hid/intel-ish-hid.rst         | 2 +-
>   Documentation/hid/uhid.rst                  | 2 +-
>   Documentation/hwmon/abituguru-datasheet.rst | 8 ++++----
>   Documentation/hwmon/abituguru.rst           | 2 +-
>   5 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
> index 9b82c7f896aa..073485f84793 100644
> --- a/Documentation/hid/hiddev.rst
> +++ b/Documentation/hid/hiddev.rst
> @@ -15,10 +15,10 @@ To support these disparate requirements, the Linux USB system provides
>   HID events to two separate interfaces:
>   * the input subsystem, which converts HID events into normal input
>   device interfaces (such as keyboard, mouse and joystick) and a
> -normalised event interface - see Documentation/input/input.rst
> +normalized event interface - see Documentation/input/input.rst

Is US spelling now mandated in the Linux kernel ?

Either case, this should be  multiple patches, at least one per subsystem
or even better one per driver.

Guenter

Re: [PATCH] docs: Fix spelling and grammatical issues

[Jonathan Corbet]

Guenter Roeck <linux@roeck-us.net> writes:

> On 2/4/25 05:48, Purva Yeshi wrote:
>> Fix several spelling and grammatical errors across multiple
>> documentation files.
>> 
>> Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
>> ---
>>   Documentation/hid/hiddev.rst                | 4 ++--
>>   Documentation/hid/intel-ish-hid.rst         | 2 +-
>>   Documentation/hid/uhid.rst                  | 2 +-
>>   Documentation/hwmon/abituguru-datasheet.rst | 8 ++++----
>>   Documentation/hwmon/abituguru.rst           | 2 +-
>>   5 files changed, 9 insertions(+), 9 deletions(-)
>> 
>> diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
>> index 9b82c7f896aa..073485f84793 100644
>> --- a/Documentation/hid/hiddev.rst
>> +++ b/Documentation/hid/hiddev.rst
>> @@ -15,10 +15,10 @@ To support these disparate requirements, the Linux USB system provides
>>   HID events to two separate interfaces:
>>   * the input subsystem, which converts HID events into normal input
>>   device interfaces (such as keyboard, mouse and joystick) and a
>> -normalised event interface - see Documentation/input/input.rst
>> +normalized event interface - see Documentation/input/input.rst
>
> Is US spelling now mandated in the Linux kernel ?

No, from Documentation/doc-guide/contributing.rst:

> Both American and British English spellings are allowed within the
> kernel documentation.  There is no need to fix one by replacing it with
> the other.

Thanks,

jon

Re: [PATCH] docs: Fix spelling and grammatical issues

[Purva Yeshi]

On 04/02/25 20:47, Jonathan Corbet wrote:
> Guenter Roeck <linux@roeck-us.net> writes:
> 
>> On 2/4/25 05:48, Purva Yeshi wrote:
>>> Fix several spelling and grammatical errors across multiple
>>> documentation files.
>>>
>>> Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
>>> ---
>>>    Documentation/hid/hiddev.rst                | 4 ++--
>>>    Documentation/hid/intel-ish-hid.rst         | 2 +-
>>>    Documentation/hid/uhid.rst                  | 2 +-
>>>    Documentation/hwmon/abituguru-datasheet.rst | 8 ++++----
>>>    Documentation/hwmon/abituguru.rst           | 2 +-
>>>    5 files changed, 9 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
>>> index 9b82c7f896aa..073485f84793 100644
>>> --- a/Documentation/hid/hiddev.rst
>>> +++ b/Documentation/hid/hiddev.rst
>>> @@ -15,10 +15,10 @@ To support these disparate requirements, the Linux USB system provides
>>>    HID events to two separate interfaces:
>>>    * the input subsystem, which converts HID events into normal input
>>>    device interfaces (such as keyboard, mouse and joystick) and a
>>> -normalised event interface - see Documentation/input/input.rst
>>> +normalized event interface - see Documentation/input/input.rst
>>
>> Is US spelling now mandated in the Linux kernel ?
> 
> No, from Documentation/doc-guide/contributing.rst:

Thank you for the clarification. I'll leave the spelling changes as they 
are.

> 
>> Both American and British English spellings are allowed within the
>> kernel documentation.  There is no need to fix one by replacing it with
>> the other.
> 
> Thanks,
> 
> jon

Re: [PATCH] docs: Fix spelling and grammatical issues

[Purva Yeshi]

On 04/02/25 20:09, Guenter Roeck wrote:
> On 2/4/25 05:48, Purva Yeshi wrote:
>> Fix several spelling and grammatical errors across multiple
>> documentation files.
>>
>> Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
>> ---
>>   Documentation/hid/hiddev.rst                | 4 ++--
>>   Documentation/hid/intel-ish-hid.rst         | 2 +-
>>   Documentation/hid/uhid.rst                  | 2 +-
>>   Documentation/hwmon/abituguru-datasheet.rst | 8 ++++----
>>   Documentation/hwmon/abituguru.rst           | 2 +-
>>   5 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
>> index 9b82c7f896aa..073485f84793 100644
>> --- a/Documentation/hid/hiddev.rst
>> +++ b/Documentation/hid/hiddev.rst
>> @@ -15,10 +15,10 @@ To support these disparate requirements, the Linux 
>> USB system provides
>>   HID events to two separate interfaces:
>>   * the input subsystem, which converts HID events into normal input
>>   device interfaces (such as keyboard, mouse and joystick) and a
>> -normalised event interface - see Documentation/input/input.rst
>> +normalized event interface - see Documentation/input/input.rst
> 
> Is US spelling now mandated in the Linux kernel ?
> 
> Either case, this should be  multiple patches, at least one per subsystem
> or even better one per driver.
> 
> Guenter
> 

Thank you for the feedback. I'll split the changes per driver and resend 
them as separate patches.

Re: [PATCH] docs: Fix spelling and grammatical issues

[Randy Dunlap]

On 2/4/25 5:48 AM, Purva Yeshi wrote:
> Fix several spelling and grammatical errors across multiple
> documentation files.
> 
> Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
> ---
>  Documentation/hid/hiddev.rst                | 4 ++--
>  Documentation/hid/intel-ish-hid.rst         | 2 +-
>  Documentation/hid/uhid.rst                  | 2 +-
>  Documentation/hwmon/abituguru-datasheet.rst | 8 ++++----
>  Documentation/hwmon/abituguru.rst           | 2 +-
>  5 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
> index 9b82c7f896aa..073485f84793 100644
> --- a/Documentation/hid/hiddev.rst
> +++ b/Documentation/hid/hiddev.rst
> @@ -15,10 +15,10 @@ To support these disparate requirements, the Linux USB system provides
>  HID events to two separate interfaces:
>  * the input subsystem, which converts HID events into normal input
>  device interfaces (such as keyboard, mouse and joystick) and a
> -normalised event interface - see Documentation/input/input.rst
> +normalized event interface - see Documentation/input/input.rst
>  * the hiddev interface, which provides fairly raw HID events
>  
> -The data flow for a HID event produced by a device is something like
> +The data flow for an HID event produced by a device is something like

Not needed IMO, since I think ("say") the word "hid" when I see HID.

>  the following::
>  
>   usb.c ---> hid-core.c  ----> hid-input.c ----> [keyboard/mouse/joystick/event]
> diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst
> index 2adc174fb576..fdabf6ec60db 100644
> --- a/Documentation/hid/intel-ish-hid.rst
> +++ b/Documentation/hid/intel-ish-hid.rst
> @@ -21,7 +21,7 @@ mainly use HID over I2C or USB. But ISH doesn't use either I2C or USB.
>  Overview
>  ========
>  
> -Using a analogy with a usbhid implementation, the ISH follows a similar model
> +Using an analogy with a usbhid implementation, the ISH follows a similar model
>  for a very high speed communication::
>  
>  	-----------------		----------------------
> diff --git a/Documentation/hid/uhid.rst b/Documentation/hid/uhid.rst
> index 2243a6b75914..2681038cd526 100644
> --- a/Documentation/hid/uhid.rst
> +++ b/Documentation/hid/uhid.rst
> @@ -106,7 +106,7 @@ UHID_INPUT2:
>  
>  UHID_GET_REPORT_REPLY:
>    If you receive a UHID_GET_REPORT request you must answer with this request.
> -  You  must copy the "id" field from the request into the answer. Set the "err"
> +  You must copy the "id" field from the request into the answer. Set the "err"

That part of the patch is OK but just not worth the effort IMHO.

>    field to 0 if no error occurred or to EIO if an I/O error occurred.
>    If "err" is 0 then you should fill the buffer of the answer with the results
>    of the GET_REPORT request and set "size" correspondingly.
> diff --git a/Documentation/hwmon/abituguru-datasheet.rst b/Documentation/hwmon/abituguru-datasheet.rst
> index 0cd61471d2a2..8c55874061d4 100644
> --- a/Documentation/hwmon/abituguru-datasheet.rst
> +++ b/Documentation/hwmon/abituguru-datasheet.rst
> @@ -6,9 +6,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 really just an microprocessor (uC) created by
> +Abit, as they claim it to be. It's really just a microprocessor (uC) created by
>  Winbond (W83L950D). And no, reading the manual for this specific uC or
> -mailing  Windbond for help won't give any useful data about uGuru, as it is
> +mailing  Winbond for help won't give any useful data about uGuru, as it is

          ^^ 2 spaces there also.

>  the program inside the uC that is responding to calls.
>  
>  Olle Sandberg <ollebull@gmail.com>, 2005-05-25
> @@ -35,7 +35,7 @@ As far as known the uGuru is always placed at and using the (ISA) I/O-ports
>  ports are holding for detection. We will refer to 0xE0 as CMD (command-port)
>  and 0xE4 as DATA because Abit refers to them with these names.
>  
> -If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC an uGuru could be
> +If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC a uGuru could be
>  present. We have to check for two different values at data-port, because
>  after a reboot uGuru will hold 0x00 here, but if the driver is removed and
>  later on attached again data-port will hold 0x08, more about this later.
> @@ -46,7 +46,7 @@ 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!
>  
> -To be really sure an uGuru is present a test read of one or more register
> +To be really sure a uGuru is present a test read of one or more register
>  sets should be done.
>  
>  
> diff --git a/Documentation/hwmon/abituguru.rst b/Documentation/hwmon/abituguru.rst
> index cfda60b757ce..4a5ee16b1048 100644
> --- a/Documentation/hwmon/abituguru.rst
> +++ b/Documentation/hwmon/abituguru.rst
> @@ -40,7 +40,7 @@ Supported chips:
>  
>  .. [2]  There is a separate abituguru3 driver for these motherboards,
>  	the abituguru (without the 3 !) driver will not work on these
> -	motherboards (and visa versa)!
> +	motherboards (and vice versa)!

Ack.

>  
>  Authors:
>  	- Hans de Goede <j.w.r.degoede@hhs.nl>,

-- 
~Randy

Re: [PATCH] docs: Fix spelling and grammatical issues

[Purva Yeshi]

On 04/02/25 23:41, Randy Dunlap wrote:
> 
> 
> On 2/4/25 5:48 AM, Purva Yeshi wrote:
>> Fix several spelling and grammatical errors across multiple
>> documentation files.
>>
>> Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
>> ---
>>   Documentation/hid/hiddev.rst                | 4 ++--
>>   Documentation/hid/intel-ish-hid.rst         | 2 +-
>>   Documentation/hid/uhid.rst                  | 2 +-
>>   Documentation/hwmon/abituguru-datasheet.rst | 8 ++++----
>>   Documentation/hwmon/abituguru.rst           | 2 +-
>>   5 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
>> index 9b82c7f896aa..073485f84793 100644
>> --- a/Documentation/hid/hiddev.rst
>> +++ b/Documentation/hid/hiddev.rst
>> @@ -15,10 +15,10 @@ To support these disparate requirements, the Linux USB system provides
>>   HID events to two separate interfaces:
>>   * the input subsystem, which converts HID events into normal input
>>   device interfaces (such as keyboard, mouse and joystick) and a
>> -normalised event interface - see Documentation/input/input.rst
>> +normalized event interface - see Documentation/input/input.rst
>>   * the hiddev interface, which provides fairly raw HID events
>>   
>> -The data flow for a HID event produced by a device is something like
>> +The data flow for an HID event produced by a device is something like
> 
> Not needed IMO, since I think ("say") the word "hid" when I see HID.

Thank you for your feedback! I’ll revise the patch accordingly and keep 
it unchanged in the next version.

> 
>>   the following::
>>   
>>    usb.c ---> hid-core.c  ----> hid-input.c ----> [keyboard/mouse/joystick/event]
>> diff --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst
>> index 2adc174fb576..fdabf6ec60db 100644
>> --- a/Documentation/hid/intel-ish-hid.rst
>> +++ b/Documentation/hid/intel-ish-hid.rst
>> @@ -21,7 +21,7 @@ mainly use HID over I2C or USB. But ISH doesn't use either I2C or USB.
>>   Overview
>>   ========
>>   
>> -Using a analogy with a usbhid implementation, the ISH follows a similar model
>> +Using an analogy with a usbhid implementation, the ISH follows a similar model
>>   for a very high speed communication::
>>   
>>   	-----------------		----------------------
>> diff --git a/Documentation/hid/uhid.rst b/Documentation/hid/uhid.rst
>> index 2243a6b75914..2681038cd526 100644
>> --- a/Documentation/hid/uhid.rst
>> +++ b/Documentation/hid/uhid.rst
>> @@ -106,7 +106,7 @@ UHID_INPUT2:
>>   
>>   UHID_GET_REPORT_REPLY:
>>     If you receive a UHID_GET_REPORT request you must answer with this request.
>> -  You  must copy the "id" field from the request into the answer. Set the "err"
>> +  You must copy the "id" field from the request into the answer. Set the "err"
> 
> That part of the patch is OK but just not worth the effort IMHO.

I will revise the patch and exclude the change in uhid.rst

> 
>>     field to 0 if no error occurred or to EIO if an I/O error occurred.
>>     If "err" is 0 then you should fill the buffer of the answer with the results
>>     of the GET_REPORT request and set "size" correspondingly.
>> diff --git a/Documentation/hwmon/abituguru-datasheet.rst b/Documentation/hwmon/abituguru-datasheet.rst
>> index 0cd61471d2a2..8c55874061d4 100644
>> --- a/Documentation/hwmon/abituguru-datasheet.rst
>> +++ b/Documentation/hwmon/abituguru-datasheet.rst
>> @@ -6,9 +6,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 really just an microprocessor (uC) created by
>> +Abit, as they claim it to be. It's really just a microprocessor (uC) created by
>>   Winbond (W83L950D). And no, reading the manual for this specific uC or
>> -mailing  Windbond for help won't give any useful data about uGuru, as it is
>> +mailing  Winbond for help won't give any useful data about uGuru, as it is
> 
>            ^^ 2 spaces there also.
> 
>>   the program inside the uC that is responding to calls.
>>   
>>   Olle Sandberg <ollebull@gmail.com>, 2005-05-25
>> @@ -35,7 +35,7 @@ As far as known the uGuru is always placed at and using the (ISA) I/O-ports
>>   ports are holding for detection. We will refer to 0xE0 as CMD (command-port)
>>   and 0xE4 as DATA because Abit refers to them with these names.
>>   
>> -If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC an uGuru could be
>> +If DATA holds 0x00 or 0x08 and CMD holds 0x00 or 0xAC a uGuru could be
>>   present. We have to check for two different values at data-port, because
>>   after a reboot uGuru will hold 0x00 here, but if the driver is removed and
>>   later on attached again data-port will hold 0x08, more about this later.
>> @@ -46,7 +46,7 @@ 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!
>>   
>> -To be really sure an uGuru is present a test read of one or more register
>> +To be really sure a uGuru is present a test read of one or more register
>>   sets should be done.
>>   
>>   
>> diff --git a/Documentation/hwmon/abituguru.rst b/Documentation/hwmon/abituguru.rst
>> index cfda60b757ce..4a5ee16b1048 100644
>> --- a/Documentation/hwmon/abituguru.rst
>> +++ b/Documentation/hwmon/abituguru.rst
>> @@ -40,7 +40,7 @@ Supported chips:
>>   
>>   .. [2]  There is a separate abituguru3 driver for these motherboards,
>>   	the abituguru (without the 3 !) driver will not work on these
>> -	motherboards (and visa versa)!
>> +	motherboards (and vice versa)!
> 
> Ack.
> 
>>   
>>   Authors:
>>   	- Hans de Goede <j.w.r.degoede@hhs.nl>,
>