From: Randy Dunlap Date: Fri, 27 Jan 2023 06:39:40 +0000 (-0800) Subject: Documentation: hid: correct spelling X-Git-Tag: v6.6.17~5501^2^2 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=2f7f4efb9411770b4ad99eb314d6418e980248b4;p=platform%2Fkernel%2Flinux-rpi.git Documentation: hid: correct spelling Correct spelling problems for Documentation/hid/ as reported by codespell. Signed-off-by: Randy Dunlap Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: Srinivas Pandruvada Cc: linux-input@vger.kernel.org Cc: Jonathan Corbet Cc: linux-doc@vger.kernel.org Acked-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20230127064005.1558-11-rdunlap@infradead.org Signed-off-by: Benjamin Tissoires --- diff --git a/Documentation/hid/hid-alps.rst b/Documentation/hid/hid-alps.rst index 767c96b..94382bb 100644 --- a/Documentation/hid/hid-alps.rst +++ b/Documentation/hid/hid-alps.rst @@ -9,7 +9,7 @@ Currently ALPS HID driver supports U1 Touchpad device. U1 device basic information. ========== ====== -Vender ID 0x044E +Vendor ID 0x044E Product ID 0x120B Version ID 0x0121 ========== ====== diff --git a/Documentation/hid/hid-bpf.rst b/Documentation/hid/hid-bpf.rst index c205f92..4fad83a 100644 --- a/Documentation/hid/hid-bpf.rst +++ b/Documentation/hid/hid-bpf.rst @@ -307,7 +307,7 @@ sysfs path: ``/sys/bus/hid/devices/xxxx:yyyy:zzzz:0000``) 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 --git a/Documentation/hid/hiddev.rst b/Documentation/hid/hiddev.rst index caebc62..9b82c7f 100644 --- 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 --git a/Documentation/hid/hidraw.rst b/Documentation/hid/hidraw.rst index b717ee5..14d0767 100644 --- 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 --git a/Documentation/hid/intel-ish-hid.rst b/Documentation/hid/intel-ish-hid.rst index 7a85125..91b5c52 100644 --- 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 that message may be reused. 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,