doc: Fix double 'the'

Fix double 'the' in all .rst documentation. Signed-off-by: Andrej Butok <[email protected]>
phan-uy-vu · Nov 15, 2023 · 287b30e · 287b30e
1 parent 6bb46c7
commit 287b30e
Show file tree

Hide file tree

Showing 26 changed files with 28 additions and 28 deletions.
diff --git a/boards/arm/96b_aerocore2/doc/index.rst b/boards/arm/96b_aerocore2/doc/index.rst
@@ -330,7 +330,7 @@ Replace :code:`<tty_device>` with the port where the board 96Boards Aerocore2
 can be found. For example, under Linux, :code:`/dev/ttyUSB0`.
 The ``-b`` option sets baud rate ignoring the value from config.
 
-Press the Reset button and you should see the the following message in your
+Press the Reset button and you should see the following message in your
 terminal:
 
 .. code-block:: console

diff --git a/boards/arm/96b_carbon/doc/index.rst b/boards/arm/96b_carbon/doc/index.rst
@@ -318,7 +318,7 @@ Replace :code:`<tty_device>` with the port where the board 96Boards Carbon
 can be found. For example, under Linux, :code:`/dev/ttyUSB0`.
 The ``-b`` option sets baud rate ignoring the value from config.
 
-Press the Reset button and you should see the the following message in your
+Press the Reset button and you should see the following message in your
 terminal:
 
 .. code-block:: console

diff --git a/boards/arm/96b_nitrogen/doc/index.rst b/boards/arm/96b_nitrogen/doc/index.rst
@@ -292,7 +292,7 @@ Replace :code:`<tty_device>` with the port where the board 96Boards Nitrogen
 can be found. For example, under Linux, :code:`/dev/ttyACM0`.
 The ``-b`` option sets baud rate ignoring the value from config.
 
-Press the Reset button and you should see the the following message in your
+Press the Reset button and you should see the following message in your
 terminal:
 
 .. code-block:: console

diff --git a/boards/arm/adafruit_feather_nrf52840/doc/index.rst b/boards/arm/adafruit_feather_nrf52840/doc/index.rst
@@ -129,7 +129,7 @@ Flash the image.
       :goals: flash
       :compact:
 
-You should see the the red LED blink.
+You should see the red LED blink.
 
 References
 **********

diff --git a/boards/arm/arduino_nano_33_ble/doc/index.rst b/boards/arm/arduino_nano_33_ble/doc/index.rst
@@ -126,7 +126,7 @@ and there should be a pulsing orange LED near the USB port.
 
 Then, you can flash the image using the above script.
 
-You should see the the red LED blink.
+You should see the red LED blink.
 
 Debugging
 =========

diff --git a/boards/arm/bl5340_dvk/doc/index.rst b/boards/arm/bl5340_dvk/doc/index.rst
@@ -290,7 +290,7 @@ described below.
 
 .. note::
 
-   By default the the Secure image for BL5340's application core is
+   By default the Secure image for BL5340's application core is
    built using TF-M.
 
 Building the Secure firmware with TF-M

diff --git a/boards/arm/cc1352p1_launchxl/doc/index.rst b/boards/arm/cc1352p1_launchxl/doc/index.rst
@@ -133,7 +133,7 @@ Programming and Debugging
 *************************
 
 Before flashing or debugging ensure the RESET, TMS, TCK, TDO, and TDI jumpers
-are in place. Also place jumpers on the the TXD and RXD signals for a serial
+are in place. Also place jumpers on the TXD and RXD signals for a serial
 console using the XDS110 application serial port.
 
 Prerequisites:

diff --git a/boards/arm/cc1352r1_launchxl/doc/index.rst b/boards/arm/cc1352r1_launchxl/doc/index.rst
@@ -132,7 +132,7 @@ Programming and Debugging
 *************************
 
 Before flashing or debugging ensure the RESET, TMS, TCK, TDO, and TDI jumpers
-are in place. Also place jumpers on the the TXD and RXD signals for a serial
+are in place. Also place jumpers on the TXD and RXD signals for a serial
 console using the XDS110 application serial port.
 
 Prerequisites:

diff --git a/boards/arm/cc26x2r1_launchxl/doc/index.rst b/boards/arm/cc26x2r1_launchxl/doc/index.rst
@@ -138,7 +138,7 @@ Programming and Debugging
 *************************
 
 Before flashing or debugging ensure the RESET, TMS, TCK, TDO, and TDI jumpers
-are in place. Also place jumpers on the the TXD and RXD signals for a serial
+are in place. Also place jumpers on the TXD and RXD signals for a serial
 console using the XDS110 application serial port.
 
 Prerequisites:

diff --git a/boards/arm/lpcxpresso11u68/doc/index.rst b/boards/arm/lpcxpresso11u68/doc/index.rst
@@ -107,7 +107,7 @@ Flashing
 The LPCXpresso11U68 board can be flashed by using the on-board LPC-Link2 debug
 probe (based on a NXP LPC43xx MCU). This MCU provides either a CMSIS-DAP or
 a J-Link interface. It depends on the embedded firmware image. The default
-OpenOCD configuration supports the the CMSIS-DAP interface. If you want to
+OpenOCD configuration supports the CMSIS-DAP interface. If you want to
 switch to J-Link, then you need to edit the
 ``boards/arm/lpcxpresso11u68/support/openocd.cfg`` file and to replace::
 

diff --git a/boards/arm/nrf9160_innblue21/doc/index.rst b/boards/arm/nrf9160_innblue21/doc/index.rst
@@ -95,7 +95,7 @@ Building Secure/Non-Secure Zephyr applications
 The process requires the following steps:
 
 1. Build the Secure Zephyr application using ``-DBOARD=nrf9160_innblue21`` and
-   ``CONFIG_TRUSTED_EXECUTION_SECURE=y`` in the the application project configuration file.
+   ``CONFIG_TRUSTED_EXECUTION_SECURE=y`` in the application project configuration file.
 2. Build the Non-Secure Zephyr application using ``-DBOARD=nrf9160_innblue21_ns``.
 3. Merge the two binaries together.
 

diff --git a/boards/arm/nrf9160_innblue22/doc/index.rst b/boards/arm/nrf9160_innblue22/doc/index.rst
@@ -95,7 +95,7 @@ Building Secure/Non-Secure Zephyr applications
 The process requires the following steps:
 
 1. Build the Secure Zephyr application using ``-DBOARD=nrf9160_innblue22`` and
-   ``CONFIG_TRUSTED_EXECUTION_SECURE=y`` in the the application project configuration file.
+   ``CONFIG_TRUSTED_EXECUTION_SECURE=y`` in the application project configuration file.
 2. Build the Non-Secure Zephyr application using ``-DBOARD=nrf9160_innblue22_ns``.
 3. Merge the two binaries together.
 

diff --git a/boards/arm/olimex_lora_stm32wl_devkit/doc/olimex_lora_stm32wl_devkit.rst b/boards/arm/olimex_lora_stm32wl_devkit/doc/olimex_lora_stm32wl_devkit.rst
@@ -126,7 +126,7 @@ CON1 pin header.
    :goals: build flash
 
 Run a serial terminal to connect with your board. By default, ``usart1`` is
-accessible via the the built-in USB to UART converter.
+accessible via the built-in USB to UART converter.
 
 .. code-block:: console
 

diff --git a/boards/posix/doc/arch_soc.rst b/boards/posix/doc/arch_soc.rst
@@ -323,7 +323,7 @@ SOC and board layers
    This description applies to all current POSIX arch based boards on tree,
    but it is not a requirement for another board to follow what is described here.
 
-When the executable process is started (that is the the board
+When the executable process is started (that is the board
 :c:func:`main`, which is the linux executable C :c:func:`main`),
 first, early initialization steps are taken care of
 (command line argument parsing, initialization of the HW models, etc).

diff --git a/boards/riscv/rv32m1_vega/doc/index.rst b/boards/riscv/rv32m1_vega/doc/index.rst
@@ -126,7 +126,7 @@ BLE Software Link Layer experimental support
 ==================================================
 This is an experimental feature supported on the Zephyr's RI5CY
 configuration, ``rv32m1_vega_ri5cy``. It  uses the Software Link Layer
-framework by Nordic Semi to enable the the on-SoC radio and transceiver for
+framework by Nordic Semi to enable the on-SoC radio and transceiver for
 implementing a software defined BLE controller. By using both the controller
 and the host stack available in Zephyr, the following BLE samples can be used
 with this board:

diff --git a/boards/x86/common/net_boot.rst b/boards/x86/common/net_boot.rst
@@ -69,7 +69,7 @@ Booting the board
    .. note::
       Use a baud rate of 115200.
 
-#. Power on the the board.
+#. Power on the board.
 
 #. Verify that the board got an IP address. Run from the Linux host:
 

diff --git a/doc/connectivity/networking/overview.rst b/doc/connectivity/networking/overview.rst
@@ -56,7 +56,7 @@ can be disabled if not needed.
 
 * **TCP** Transmission Control Protocol
   (`RFC 793 <https://tools.ietf.org/html/rfc793>`_) is supported. Both server
-  and client roles can be used the the application. The amount of TCP sockets
+  and client roles can be used the application. The amount of TCP sockets
   that are available to applications can be configured at build time.
 
 * **BSD Sockets API** Support for a subset of a

diff --git a/doc/contribute/guidelines.rst b/doc/contribute/guidelines.rst
@@ -316,7 +316,7 @@ Pull Requests and Issues
 
 Before starting on a patch, first check in our issues `Zephyr Project Issues`_
 system to see what's been reported on the issue you'd like to address.  Have a
-conversation on the `Zephyr devel mailing list`_ (or the the `Zephyr Discord
+conversation on the `Zephyr devel mailing list`_ (or the `Zephyr Discord
 Server`_) to see what others think of your issue (and proposed solution).  You
 may find others that have encountered the issue you're finding, or that have
 similar ideas for changes or additions.  Send a message to the `Zephyr devel
@@ -360,7 +360,7 @@ gitlint
 
 When you submit a pull request to the project, a series of checks are
 performed to verify your commit messages meet the requirements. The same step
-done during the CI process can be performed locally using the the ``gitlint``
+done during the CI process can be performed locally using the ``gitlint``
 command.
 
 Run ``gitlint`` locally in your tree and branch where your patches have been

diff --git a/doc/develop/manifest/index.rst b/doc/develop/manifest/index.rst
@@ -30,7 +30,7 @@ Inactive and Optional Projects/Modules
 
 
 The projects below are optional and will not be downloaded when you
-call `west update`. You can add any of the the projects or modules listed below
+call `west update`. You can add any of the projects or modules listed below
 and use them to write application code and extend your workspace with the added
 functionality.
 

diff --git a/doc/develop/modules.rst b/doc/develop/modules.rst
@@ -818,7 +818,7 @@ to the path containing the CMake file.
 To include a module's Kconfig file, set the variable ``ZEPHYR_<MODULE_NAME>_KCONFIG``
 to the path to the Kconfig file.
 
-The following is an example on how to add support the the ``FOO`` module.
+The following is an example on how to add support the ``FOO`` module.
 
 Create the following structure
 

diff --git a/doc/develop/test/twister.rst b/doc/develop/test/twister.rst
@@ -1050,7 +1050,7 @@ example:
       id: 000683290670
       notes: An nrf5340dk_nrf5340 is detected as an nrf52840dk_nrf52840 with no serial
         port, and three serial ports with an unknown platform.  The board id of the serial
-        ports is not the same as the board id of the the development kit.  If you regenerate
+        ports is not the same as the board id of the development kit.  If you regenerate
         this file you will need to update serial to reference the third port, and platform
         to nrf5340dk_nrf5340_cpuapp or another supported board target.
       platform: nrf52840dk_nrf52840

diff --git a/doc/develop/west/manifest.rst b/doc/develop/west/manifest.rst
@@ -248,7 +248,7 @@ next.
        remote Git repository.
 
        If the project has neither, the ``defaults`` section must specify a
-       ``remote``, which will be used as the the project's remote. Otherwise,
+       ``remote``, which will be used as the project's remote. Otherwise,
        the manifest is invalid.
 
    * - ``repo-path``
@@ -2049,7 +2049,7 @@ The ultimate outcomes of resolving manifest imports are:
 - a ``projects`` list, which is produced by combining the ``projects`` defined
   in the top-level file with those defined in imported files
 
-- a set of extension commands, which are drawn from the the ``west-commands``
+- a set of extension commands, which are drawn from the ``west-commands``
   keys in in the top-level file and any imported files
 
 - a ``group-filter`` list, which is produced by combining the top-level and any

diff --git a/doc/glossary.rst b/doc/glossary.rst
@@ -51,7 +51,7 @@ Glossary of Terms
 
    device runtime power management
       Device Runtime Power Management (PM) refers the capability of devices to
-      save energy independently of the the system power state. Devices will keep
+      save energy independently of the system power state. Devices will keep
       reference of their usage and will automatically be suspended or resumed.
       This feature is enabled via the :kconfig:option:`CONFIG_PM_DEVICE_RUNTIME`
       Kconfig option.

diff --git a/doc/kernel/data_structures/rbtree.rst b/doc/kernel/data_structures/rbtree.rst
@@ -27,7 +27,7 @@ the algorithm to work correctly.
 
 As with the slist and dlist containers, nodes within an rbtree are
 represented as a :c:struct:`rbnode` structure which exists in
-user-managed memory, typically embedded within the the data structure
+user-managed memory, typically embedded within the data structure
 being tracked in the tree.  Unlike the list code, the data within an
 rbnode is entirely opaque.  It is not possible for the user to extract
 the binary tree topology and "manually" traverse the tree as it is for

diff --git a/doc/releases/release-notes-3.2.rst b/doc/releases/release-notes-3.2.rst
@@ -335,7 +335,7 @@ Bluetooth
     payload updates with the Resolvable Private Address (RPA) rotations when
     the :kconfig:option:`CONFIG_BT_PRIVACY` is enabled.
   * Added a new :c:func:`bt_le_set_rpa_timeout()` API call to dynamically change
-    the the Resolvable Private Address (RPA) timeout when the
+    the Resolvable Private Address (RPA) timeout when the
     :kconfig:option:`CONFIG_BT_RPA_TIMEOUT_DYNAMIC` is enabled.
   * Added :c:func:`bt_conn_auth_cb_overlay` to overlay authentication callbacks
     for a Bluetooth LE connection.

diff --git a/doc/releases/release-notes-3.3.rst b/doc/releases/release-notes-3.3.rst
@@ -811,7 +811,7 @@ Drivers and Sensors
 
   * Added new API :c:func:`pcie_scan` to scan for devices.
 
-    * This iterates through the the buses and devices which are expected to
+    * This iterates through the buses and devices which are expected to
       exist. The old method was to try all possible combination of buses
       and devices to determine if there is a device there.
       :c:func:`pci_init` and :c:func:`pcie_bdf_lookup` have been updated to