Message-ID: <dba648c4-416d-4c36-b93c-8a52f44be313@gmail.com>
Date: Wed, 5 Feb 2025 02:10:33 +0530
From: Purva Yeshi <purvayeshi550@...il.com>
To: Randy Dunlap <rdunlap@...radead.org>, jikos@...nel.org,
 bentiss@...nel.org, corbet@....net, jdelvare@...e.com, linux@...ck-us.net
Cc: skhan@...uxfoundation.org, linux-usb@...r.kernel.org,
 linux-input@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-hwmon@...r.kernel.org
Subject: Re: [PATCH] docs: Fix spelling and grammatical issues

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@...il.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@...il.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@....nl>,
> 

Powered by blists - more mailing lists