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

[Randy Dunlap <rdunlap@infradead.org>]

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