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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Jan 2023 08:20:13 -0800
From:   srinivas pandruvada <srinivas.pandruvada@...ux.intel.com>
To:     Randy Dunlap <rdunlap@...radead.org>, linux-kernel@...r.kernel.org
Cc:     Jiri Kosina <jikos@...nel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        linux-input@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        linux-doc@...r.kernel.org
Subject: Re: [PATCH 10/35] Documentation: hid: correct spelling

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@...radead.org>
> Cc: Jiri Kosina <jikos@...nel.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@...hat.com>
> Cc: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
> Cc: linux-input@...r.kernel.org
> Cc: Jonathan Corbet <corbet@....net>
> Cc: linux-doc@...r.kernel.org

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

Acked-by: Srinivas Pandruvada <srinivas.pandruvada@...ux.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,