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@xxxxxxxxx>
> ---
> 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@xxxxxxxxx>, 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@xxxxxx>,
--
~Randy
