Re: [PATCH 10/35] Documentation: hid: correct spelling

[srinivas pandruvada <srinivas.pandruvada@linux.intel.com>]

On Thu, 2023-01-26 at 22:39 -0800, Randy Dunlap wrote:
> Correct spelling problems for Documentation/hid/ as reported
> by codespell.
> 
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Cc: linux-input@vger.kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: linux-doc@vger.kernel.org

For Documentation/hid/intel-ish-hid.rst

Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>


> ---
>  Documentation/hid/hid-alps.rst      |    2 +-
>  Documentation/hid/hid-bpf.rst       |    2 +-
>  Documentation/hid/hiddev.rst        |    2 +-
>  Documentation/hid/hidraw.rst        |    2 +-
>  Documentation/hid/intel-ish-hid.rst |    2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff -- a/Documentation/hid/hid-alps.rst b/Documentation/hid/hid-
> alps.rst
> --- a/Documentation/hid/hid-alps.rst
> +++ b/Documentation/hid/hid-alps.rst
> @@ -9,7 +9,7 @@ Currently ALPS HID driver supports U1 To
>  U1 device basic information.
>  
>  ==========     ======
> -Vender ID      0x044E
> +Vendor ID      0x044E
>  Product ID     0x120B
>  Version ID     0x0121
>  ==========     ======
> diff -- a/Documentation/hid/hid-bpf.rst b/Documentation/hid/hid-
> bpf.rst
> --- a/Documentation/hid/hid-bpf.rst
> +++ b/Documentation/hid/hid-bpf.rst
> @@ -307,7 +307,7 @@ sysfs path: ``/sys/bus/hid/devices/xxxx:
>  
>  We can not rely on hidraw to bind a BPF program to a HID device.
> hidraw is an
>  artefact of the processing of the HID device, and is not stable.
> Some drivers
> -even disable it, so that removes the tracing capabilies on those
> devices
> +even disable it, so that removes the tracing capabilities on those
> devices
>  (where it is interesting to get the non-hidraw traces).
>  
>  On the other hand, the ``hid_id`` is stable for the entire life of
> the HID device,
> diff -- a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst
> --- a/Documentation/hid/hiddev.rst
> +++ b/Documentation/hid/hiddev.rst
> @@ -8,7 +8,7 @@ Introduction
>  In addition to the normal input type HID devices, USB also uses the
>  human interface device protocols for things that are not really
> human
>  interfaces, but have similar sorts of communication needs. The two
> big
> -examples for this are power devices (especially uninterruptable
> power
> +examples for this are power devices (especially uninterruptible
> power
>  supplies) and monitor control on higher end monitors.
>  
>  To support these disparate requirements, the Linux USB system
> provides
> diff -- a/Documentation/hid/hidraw.rst b/Documentation/hid/hidraw.rst
> --- a/Documentation/hid/hidraw.rst
> +++ b/Documentation/hid/hidraw.rst
> @@ -163,7 +163,7 @@ HIDIOCGOUTPUT(len):
>         Get an Output Report
>  
>  This ioctl will request an output report from the device using the
> control
> -endpoint.  Typically, this is used to retrive the initial state of
> +endpoint.  Typically, this is used to retrieve the initial state of
>  an output report of a device, before an application updates it as
> necessary either
>  via a HIDIOCSOUTPUT request, or the regular device write()
> interface.  The format
>  of the buffer issued with this report is identical to that of
> HIDIOCGFEATURE.
> diff -- a/Documentation/hid/intel-ish-hid.rst
> b/Documentation/hid/intel-ish-hid.rst
> --- a/Documentation/hid/intel-ish-hid.rst
> +++ b/Documentation/hid/intel-ish-hid.rst
> @@ -199,7 +199,7 @@ the sender that the memory region for th
>  DMA initialization is started with host sending DMA_ALLOC_NOTIFY bus
> message
>  (that includes RX buffer) and FW responds with DMA_ALLOC_NOTIFY_ACK.
>  Additionally to DMA address communication, this sequence checks
> capabilities:
> -if thw host doesn't support DMA, then it won't send DMA allocation,
> so FW can't
> +if the host doesn't support DMA, then it won't send DMA allocation,
> so FW can't
>  send DMA; if FW doesn't support DMA then it won't respond with
>  DMA_ALLOC_NOTIFY_ACK, in which case host will not use DMA transfers.
>  Here ISH acts as busmaster DMA controller. Hence when host sends
> DMA_XFER,