[10/35] Documentation: hid: correct spelling

Message ID 20230127064005.1558-11-rdunlap@infradead.org
State New
Headers
Series Documentation: correct lots of spelling errors (series 1) |

Commit Message

Randy Dunlap Jan. 27, 2023, 6:39 a.m. UTC
  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
---
 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(-)
  

Comments

srinivas pandruvada Jan. 27, 2023, 4:20 p.m. UTC | #1
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,
  
Benjamin Tissoires Feb. 6, 2023, 2:01 p.m. UTC | #2
On Thu, 26 Jan 2023 22:39:40 -0800, Randy Dunlap wrote:
> Correct spelling problems for Documentation/hid/ as reported
> by codespell.
> 
> 

Applied to hid/hid.git (for-6.3/hid-bpf), thanks!

[10/35] Documentation: hid: correct spelling
        https://git.kernel.org/hid/hid/c/2f7f4efb9411

Cheers,
  

Patch

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,