documentation: Fix several typos

deining · carlescufi · commit 571f8591b9ad · 2023-08-07T13:07:50.000+02:00
Correcting typos in various documentation files

Signed-off-by: Andreas Deininger &lt;andreas@deininger.net&gt;
diff --git a/doc/connectivity/bluetooth/api/cap.rst b/doc/connectivity/bluetooth/api/cap.rst
@@ -1,7 +1,7 @@
 .. _bluetooth_cap:
 
-Commmon Audio Profile
-#####################
+Common Audio Profile
+####################
 
 
 API Reference
diff --git a/doc/connectivity/bluetooth/api/mesh/shell.rst b/doc/connectivity/bluetooth/api/mesh/shell.rst
@@ -473,7 +473,7 @@ The Configuration Client uses general message parameters set by ``mesh target ds
 
 	Get or set the default TTL value.
 
-	* ``TTL``: If present, sets the new default TTL value. Leagal TTL values are 0x00 and 0x02-0x7f. If omitted, the current default TTL value is printed.
+	* ``TTL``: If present, sets the new default TTL value. Legal TTL values are 0x00 and 0x02-0x7f. If omitted, the current default TTL value is printed.
 
 
 ``mesh models cfg friend [Val(off, on)]``
@@ -1229,7 +1229,7 @@ To use these commands, a Firmware Distribution Server must be instantiated by th
 	Get a list of info about firmware receivers.
 
 	* ``First``: Index of the first receiver to get from the receiver list.
-	* ``Count``: The number of recievers for which to get info.
+	* ``Count``: The number of receivers for which to get info.
 
 ``mesh models dfd capabilities-get``
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/doc/connectivity/bluetooth/api/shell/mcp.rst b/doc/connectivity/bluetooth/api/shell/mcp.rst
@@ -435,7 +435,7 @@ track" command:
 
 
 Some server commands are available. These commands force
-notifications of the various characterstics, for testing that the
+notifications of the various characteristics, for testing that the
 client receives notifications. The values sent in the notifications
 caused by these testing commands are independent of the media player,
 so they do not correspond the actual values of the characteristics nor
diff --git a/doc/connectivity/bluetooth/bluetooth-ctlr-arch.rst b/doc/connectivity/bluetooth/bluetooth-ctlr-arch.rst
@@ -308,7 +308,7 @@ requires the following hardware peripherals.
 .. [i] General Purpose Input Output (GPIO)
 .. [j] GPIO tasks and events (GPIOTE)
 .. [k] Temperature sensor (TEMP)
-.. [l] Universal Asynchronous Receiver Transmiter (UART)
+.. [l] Universal Asynchronous Receiver Transmitter (UART)
 .. [m] Interprocess Communication peripheral (IPC)
 
 
diff --git a/doc/connectivity/usb/pd/ucds.rst b/doc/connectivity/usb/pd/ucds.rst
@@ -27,7 +27,7 @@ The configuration of a USB-C Device is done in the stack layer and devicetree.
 The following devicetree, structures and callbacks need to be defined:
 
 * Devicetree usb-c-connector node referencing a TCPC
-* Devicetree vbus node referencing a VBUS measurment device
+* Devicetree vbus node referencing a VBUS measurement device
 * User defined structure that encapsulates application specific data
 * Policy callbacks
 
@@ -117,7 +117,7 @@ The configuration of a USB-C Device is done in the stack layer and devicetree.
 Define the following devicetree, structures and callbacks:
 
 * Devicetree ``usb-c-connector`` node referencing a TCPC
-* Devicetree ``vbus`` node referencing a VBUS measurment device
+* Devicetree ``vbus`` node referencing a VBUS measurement device
 * User defined structure that encapsulates application specific data
 * Policy callbacks
 
diff --git a/doc/develop/flash_debug/host-tools.rst b/doc/develop/flash_debug/host-tools.rst
@@ -184,8 +184,8 @@ As a quick reference, see these three board documentation pages:
 Enabling BOSSAC on Windows Native [Experimental]
 ------------------------------------------------
 
-Zephyr SDK´s bossac is only currenty support on Linux and macOS. Windows support
-can be achieved by using the bossac version from `BOSSA oficial releases`_.
+Zephyr SDK´s bossac is currently supported on Linux and macOS only. Windows support
+can be achieved by using the bossac version from `BOSSA official releases`_.
 After installing using default options, the :file:`bossac.exe` must be added to
 Windows PATH. A specific bossac executable can be used by passing the
 ``--bossac`` option, as follows:
@@ -403,5 +403,5 @@ To enable Zephyr RTOS awareness follow the steps described in
 .. _Lauterbach TRACE32 Zephyr OS Awareness Manual:
 	https://www2.lauterbach.com/pdf/rtos_zephyr.pdf
 
-.. _BOSSA oficial releases:
+.. _BOSSA official releases:
 	https://github.com/shumatech/BOSSA/releases
diff --git a/doc/develop/test/twister.rst b/doc/develop/test/twister.rst
@@ -561,7 +561,7 @@ filter: <expression>
     Twister will first evaluate the expression to find if a "limited" cmake call, i.e. using package_helper cmake script,
     can be done. Existence of "dt_*" entries indicates devicetree is needed.
     Existence of "CONFIG*" entries indicates kconfig is needed.
-    If there are no other types of entries in the expression a filtration can be done wihout creating a complete build system.
+    If there are no other types of entries in the expression a filtration can be done without creating a complete build system.
     If there are entries of other types a full cmake is required.
 
     The grammar for the expression language is as follows:
@@ -1080,9 +1080,9 @@ locally. As of now, those options are available:
   CI)
 - Option to specify your own list of default platforms overriding what
   upstream defines.
-- Ability to override `build_onl_all` options used in some testscases.
+- Ability to override `build_onl_all` options used in some testcases.
   This will treat tests or sample as any other just build for default
-  platforms you specify in the configuation file or on the command line.
+  platforms you specify in the configuration file or on the command line.
 - Ignore some logic in twister to expand platform coverage in cases where
   default platforms are not in scope.
 
@@ -1139,7 +1139,7 @@ And example test level configuration::
 Combined configuration
 ======================
 
-To mix the Platform and level confgiuration, you can take an example as below:
+To mix the Platform and level configuration, you can take an example as below:
 
 And example platforms plus level configuration::
 
diff --git a/doc/develop/west/release-notes.rst b/doc/develop/west/release-notes.rst
@@ -361,7 +361,7 @@ New features:
 Bug fixes:
 
 - West now checks that the manifest schema version is one of the explicitly
-  allowed vlaues documented in :ref:`west-manifest-schema-version`. The old
+  allowed values documented in :ref:`west-manifest-schema-version`. The old
   behavior was just to check that the schema version was newer than the west
   version where the ``manifest: version:`` key was introduced. This incorrectly
   allowed invalid schema versions, like ``0.8.2``.
diff --git a/doc/services/device_mgmt/ec_host_cmd.rst b/doc/services/device_mgmt/ec_host_cmd.rst
@@ -29,7 +29,7 @@ called.
 .. image:: ec_host_cmd.png
    :align: center
 
-SHI (Serial Host Interface) is different to this because it is used olny for communication with a
+SHI (Serial Host Interface) is different to this because it is used only for communication with a
 host. SHI does not have API itself, thus the backend and peripheral driver layers are combined into
 one backend layer.
 
diff --git a/doc/services/ipc/ipc_service/ipc_service.rst b/doc/services/ipc/ipc_service/ipc_service.rst
@@ -161,7 +161,7 @@ See the following example:
 Backends
 ********
 
-The requirements needed for implementating backends give flexibility to the IPC
+The requirements needed for implementing backends give flexibility to the IPC
 service. These allow for the addition of dedicated backends having only a
 subsets of features for specific use cases.
 
