style: Fix "the the" typo across the codebase.

Fix 269 occurrences of duplicate "the" word typo found in 209 files
across source code, header files, and configuration.

Signed-off-by: Huang Qi <huangqi3@xiaomi.com>

Documentation/applications/boot/nxboot/index.rst

@@ -41,7 +41,7 @@ a reserved space for a pointer to it.
 The image compatible with nxboot bootloader can be uploaded both directly
 to the primary area via physical programmer as STlink or JTAG and to the
 update partition via some external application (over Ethernet, USB, CAN, etc.).
-The update and recovery slots can be located in the the primary flash as
+The update and recovery slots can be located in the primary flash as
 well, but this halts the program execution during write operations, so it is
 not recommended if external flash can be used. The uploaded image is detected
 by the bootloader during the next boot and update occurs.

Documentation/applications/examples/nxterm/index.rst

@@ -199,7 +199,7 @@ See, for an example, ``apps/graphics/nxwm/src/cnxterm.cxx``.  In this case, the
 behavior will change, depending on the selection of ``CONFIG_NXTERM_NXKBDIN``:
 If ``CONFIG_NXTERM_NXKBDIN`` is not selected, then the behavior will be similar
 to ``apps/examples/nxterm``; stdin will not be redirected an keyboard input will
-come directly from the the system console.
+come directly from the system console.
 
 But is ``CONFIG_NXTERM_NXKBDIN`` is select, NSH's stdin will be re-redirected to
 the to the NxTerm character driver. Keyboard input will arrive on stdin from the

Documentation/applications/graphics/twm4nx/index.rst

@@ -104,7 +104,7 @@ Main Menu
   - Twm4Nx Icom Manager. De-iconify and/or raise the Icon Manager to the top of
     the display.
   - Calibration. Perform touchscreen re-calibration.
-  - Clock. Start and instance of clock in the window. The uses the the retro,
+  - Clock. Start and instance of clock in the window. The uses the retro,
     LCD emulation of ``apps/graphics/slcd``.
   - NuttShell. Start and instance of NSH running in an NxTerm.
 
@@ -340,7 +340,7 @@ The ``createWindow()`` method requires four parameters:
 
 1. The name of the window. This is the name that is show in the window toolbar
     and may be the same name as was used in the Main Menu entry.
-2. A reference to the the Icon image associated with the window. This is the
+2. A reference to the Icon image associated with the window. This is the
     image that is show on the desktop when the window is iconified. It is of
     type ``NXWidgets::SRlePaletteBitmap``.
 3. A pointer to the Icon Manager instance that this window belongs with. This

Documentation/applications/nsh/commands.rst

@@ -1074,7 +1074,7 @@ select either the FAT12 or FAT16 format. For historical reasons,
 if you want the FAT32 format, it must be explicitly specified on
 the command line.
 
-The ``-r`` option may be specified to select the the number of
+The ``-r`` option may be specified to select the number of
 entries in the root directory for FAT12 and FAT16 file systems.
 Typical values for small volumes would be 112 or 224; 512 should
 be used for large volumes, such as hard disks or very large SD
@@ -1640,7 +1640,7 @@ automatically started in ``nsh_main.c``. The exception is when
 enabled at initialization but rather must be enabled from the NSH
 command line or via other applications.
 
-In that case, when ``nsh_telnetstart()`` is called before the the
+In that case, when ``nsh_telnetstart()`` is called before the
 network is initialized, it will fail.
 
 .. _cmdtime:

Documentation/applications/system/zmodem/index.rst

@@ -50,7 +50,7 @@ On NuttX you will have to use hardware flow control in most cases.
 
 The ``XON`` / ``XOFF`` controls built into ZModem could be used if you enabled
 software flow control in the host. But that would only work in one direction: If
-would prevent the host from overrunning the the target Rx buffering. So you
+would prevent the host from overrunning the target Rx buffering. So you
 should be able to do host-to-target software flow control. But there would still
 be no target-to-host flow control. That might not be an issue because the host
 is usually so much faster than the target.

Documentation/components/drivers/special/segger.rst

@@ -24,7 +24,7 @@ Segger SystemView
 
    :menuselection:`CONFIG_ARCH_PERF_EVENTS=y`
 
-   In that case, the the architecture logic must initialize the perf counter
+   In that case, the architecture logic must initialize the perf counter
    with ``up_perf_init()``.
 
 #. Enable instrumentation support:

Documentation/components/filesystem/cromfs.rst

@@ -5,7 +5,7 @@ CROMFS
 Overview
 ========
 
-This directory contains the the CROMFS file system.  This is an in-memory
+This directory contains the CROMFS file system.  This is an in-memory
 (meaning no block driver), read-only (meaning that can lie in FLASH) file
 system.  It uses LZF decompression on data only (meta data is not
 compressed).
@@ -140,7 +140,7 @@ system are presented by other types of nodes:  hard links, directories, and
 files.  These nodes are all described in fs/cromfs/cromfs.h.
 
 In addition to general volume information, the volume node provides an
-offset to the the "root directory".  The root directory, like all other
+offset to the "root directory".  The root directory, like all other
 CROMFS directories is simply a singly linked list of other nodes:  hard link
 nodes, directory nodes, and files.  This list is managed by "peer offsets":
 Each node in the directory contains an offset to its peer in the same

Documentation/components/nxgraphics/nx.rst

@@ -122,7 +122,7 @@ start this daemon. There are two ways that this can be done:
 
 #. The NX server may be started in your board startup logic by simply
    calling the function ``nxmu_start()``. The board startup logic
-   usually resides the the ``boards/arch/chip/board/src`` directory. The
+   usually resides the ``boards/arch/chip/board/src`` directory. The
    board startup logic can run automatically during the early system if
    ``CONFIG_BOARD_LATE_INITIALIZE`` is defined in the configuration. Or,
    the board startup logic can execute under control of the application

Documentation/contributing/coding_style.rst

@@ -1996,7 +1996,7 @@ different.
    brace of the ``if``-``else`` must be followed by a blank line in most
    cases (the exception given below). This may be the final brace of the
    ``if`` compound statement if the ``else`` keyword is not present. Or
-   it may be the the final brace of the ``else`` compound statement if
+   it may be the final brace of the ``else`` compound statement if
    present. A blank line never follows the right brace closing the
    ``if`` compound statement if the ``else`` keyword is present. Use of
    braces must follow all other standard rules for `braces and

Documentation/guides/armv7m_runtimestackcheck.rst

@@ -43,7 +43,7 @@ function call can then corrupt the memory below the stack bottom, restores the
 stack pointer and returns to the caller without actually overwriting the 
 coloring at the base of the stack.
 
-This brings us the the next method of stack checking.
+This brings us the next method of stack checking.
 
 
 Per function Call

Documentation/guides/include_files_board_h.rst

@@ -68,6 +68,6 @@ The only way to avoid this header file inclusion trap is:
 
 * Never include architecture-specific header files in the ``board.h`` header file. 
   Instead,
-* Include the header files needed by the the ``board.h`` header file in the C file 
+* Include the header files needed by the ``board.h`` header file in the C file 
   that includes ``board.h``
 * Make sure that ``board.h`` is the last header file included.

Documentation/guides/porting-case-studies/bcm2711-rpi4b.rst

@@ -169,7 +169,7 @@ multimeter and confirm that the GPIO did get set, so I knew that the ``arm64_ear
 called. Something was wrong with my UART configuration.
 
 I then tried directly manipulating registers to put the text "hi" in the UART FIFO. When I booted again, this printed,
-but then was followed by some garbled output. It appeared that the the ``char *`` pointer passed to the print function
+but then was followed by some garbled output. It appeared that the ``char *`` pointer passed to the print function
 was getting garbled. After troubleshooting by printing characters directly by calling my ``arm64_lowputc`` in the
 assembly boot script, I discovered that I could print a string from the C definition if I declared the string as static.
 I also investigated the elf generated by building and confirmed the string was located in ``.rodata``. I was suspicious

Documentation/guides/smaller_vector_tables.rst

@@ -44,7 +44,7 @@ to filter those out and reduce the size to the number of
 supported interrupts.
 
 For example, if the actual number of interrupts used were 
-20, the the above requirement would go from 800 bytes to 
+20, the above requirement would go from 800 bytes to 
 160 bytes.
 
 Software IRQ Remapping

Documentation/guides/stm32ccm.rst

@@ -43,7 +43,7 @@ NOTE: In order to use the CCM memory allocator functions, you must first call
 ``ccm_initialize()`` somewhere in your early boot-up logic.
 
 With these interfaces you have a (nearly) standard way to manage memory from a
-heap that consists of the the CCM SRAM. And, since the CCM memory is no longer
+heap that consists of the CCM SRAM. And, since the CCM memory is no longer
 a part of the normal heap, all allocated I/O buffers will be DMA-able (unless you
 have included other non-DMA-able memory regions in the stack).
 

Documentation/guides/stm32nullpointer.rst

@@ -27,7 +27,7 @@ STM32 Memory Aliasing
 The STMicro STM32 family of Cortex-M3/4 MCUs do things a little differently.
 FLASH is physically addressed at address 0x0800:0000; the STM32 vector table
 is then physically located at 0x0800:0000 instead of 0x0000:0000. If the STM32
-hardware is configured to boot from FLASH, then the the STM32 will remap the
+hardware is configured to boot from FLASH, then the STM32 will remap the
 FLASH memory so that is aliased at address 0x0000:00000. In that way, the STM32
 can boot from FLASH or external memory or any other memory region that it is
 capable of mapping.

Documentation/implementation/critical_sections.rst

@@ -405,7 +405,7 @@ IRQ Monitor is beyond the scope of this page. Suffice it to say:
   interrupt handler until exit from the interrupt handler.
 
 From this information we can calculate the worst case response time from
-interrupt request until a task runs that can process the the interrupt.
+interrupt request until a task runs that can process the interrupt.
 That worst cast response time, ``Tresp``, is given by:
 
 * ``Tresp1 = Tcrit + Tintr + C1``

Documentation/implementation/device_drivers.rst

@@ -59,7 +59,7 @@ The I2C Tool
 ------------
 
 Of course, like most rules, there are lots of violations. I2C is another bus and
-the the I2C "driver" is another transport similar in many ways to SPI. For I2C,
+the I2C "driver" is another transport similar in many ways to SPI. For I2C,
 there is an application at ``apps/system/i2c`` called the "I2C tool" that will allow
 you access I2C devices from the command line. This is not really just a test tool
 and not a real part of an application.

Documentation/implementation/drivers_design.rst

@@ -102,7 +102,7 @@ For the upper half driver:
 
 And for the lower half driver:
 
-* The lower-half side of the interface to the the upper-half driver, and
+* The lower-half side of the interface to the upper-half driver, and
 
 * The low-level interface to the hardware that is managed by the lower half
   device driver.

Documentation/implementation/interrupt_controls.rst

@@ -27,7 +27,7 @@ A context switch works just like setjmp (save a set of registers) and longjmp
 (restore a set of registers), except that more registers are saved and restored.
 
 
-For the the ARMv7-M, as an example, you can see the set of registers that are
+For the ARMv7-M, as an example, you can see the set of registers that are
 stored in ``arch/arm/include/armv7-m/irq.h``
 
 Among those registers are saved and restore are the register(s) that determine if

Documentation/implementation/make_build_system.rst

@@ -81,9 +81,9 @@ arch, chip and board files.
 
 The ``Make`` build system refers the needed subsystems using *generic* naming:
 
-- The *current* architecture is refered as ``arch``
-- The *current* chip is refered as ``chip``
-- The *current* board is refered as ``board``
+- The *current* architecture is referred as ``arch``
+- The *current* chip is referred as ``chip``
+- The *current* board is referred as ``board``
 
 These *generic* names are mapped to the *actual* names by symlinks:
 
@@ -93,7 +93,7 @@ These *generic* names are mapped to the *actual* names by symlinks:
 
 The board config is stored as ``defconfig`` file, which is a minimal config,
 storing only the configs that differs from default config values.
-Due to NuttX's particularity of strict dependance to the ``app``
+Due to NuttX's particularity of strict dependence on the ``app``
 directory, the ``.config`` file is not generated by either ``kconfiglib`` or
 ``kconfig-frontends``, but rather by the an in-tree ``tools/process_config.sh``
 script. This script takes a "base" input file (the boards ``defconfig`` file),
@@ -206,7 +206,7 @@ After compiling libraries defined by the ``$(USERLIBS)`` and ``$(NUTTXLIBS)`` at
 the ``make`` build system will ``install`` them at a special ``staging/`` directory, residing at the
 root of the NuttX tree.
 
-These libraries are passed to the the final target rule (``$(BIN)``).
+These libraries are passed to the final target rule (``$(BIN)``).
 
 .. code-block:: makefile
 

Documentation/legacy_README.md

@@ -273,7 +273,7 @@ Perhaps a minimum set would be those packages listed below for the
 Cygwin configuration:
 
    1. After starting the Cygwin installer, keep the recommended
-      packages that are pre-selected in the default configuration.
+      packages that are preselected in the default configuration.
 
    2. Using the installation tools, add the following packages:
 
@@ -1258,7 +1258,7 @@ settings, you should run the following after configuring:
 
     make olddefconfig
 
-That will restore the the missing defaulted values.
+That will restore the missing defaulted values.
 
 Using this command after configuring is generally a good practice anyway:
 Even if the `defconfig` files are not "compressed" in this fashion, the
@@ -1331,7 +1331,7 @@ damage your configuration (see
   <http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html>
 
   The configuration steps of the most recent versions of NuttX require the
-  `kconfig-tweak` tool that is not not available in the the above.  However,
+  `kconfig-tweak` tool that is not not available in the above.  However,
   there has been an update to this `Kconfig` Windows tools that does include
   `kconfig-tweak`:  http://reclonelabs.com/more-kconfig-awesomeness-for-windows/
 

Documentation/platforms/arm/lc823450/index.rst

@@ -23,7 +23,7 @@ and for ON Semiconductor's **LC823450XGEVK board**:
    it is applicable to portable audio markets such as Wireless headsets
    and will show high performance.
 
-Further information about the LC823450XGEVK is available on from the the
+Further information about the LC823450XGEVK is available on from the
 `ON
 Semiconductor <http://www.onsemi.com/PowerSolutions/evalBoard.do?id=LC823450XGEVK>`__
 website as are LC823450 `related technical

Documentation/platforms/arm/lpc54xx/boards/lpcxpresso-lpc54628/README.txt

@@ -541,7 +541,7 @@ Configurations
     are just some issues/topics unique to the LPCXpresso-LPC54628 and/or
     this configuration.
 
-    1. There is a responsive-ness issue the the FT5x06 touchscreen controller.
+    1. There is a responsive-ness issue the FT5x06 touchscreen controller.
        The pin selected by the board designers will not support interrupts.
        Therefore, a fall-back polled mode is use.  This polled mode has
        significant inherent delays that effect the user experience when

Documentation/platforms/arm/sam34/boards/sam3u-ek/index.rst

@@ -28,7 +28,7 @@ You can use AtmelStudio6.1 to load and debug code.
 LEDs
 ====
 
-The SAM3U-EK board has four LEDs labeled LD1, LD2, LD3 and LD4 on the the board.
+The SAM3U-EK board has four LEDs labeled LD1, LD2, LD3 and LD4 on the board.
 Usage of these LEDs is defined in ``include/board.h`` and ``src/up_leds.c``. They are
 encoded as follows:
 

Documentation/platforms/arm/samd5e5/boards/metro-m4/README.txt

@@ -91,7 +91,7 @@ STATUS
     study the XOSC32K problem.
 
     With that workaround (and a bunch of other fixes), the basic NSH
-    configuration appears fully function, indicating the the board bring-
+    configuration appears fully function, indicating the board bring-
     up is complete.
 
     There are additional drivers ported from SAML21 which has, in most cases,

Documentation/platforms/arm/stm32f4/boards/clicker2-stm32/index.rst

@@ -527,7 +527,7 @@ NOTES:
          nsh> telnetd
 
    Note the 'ifconfig' is executed to get the IP address of the node.
-   This is necessary because the IP address is assigned by the the
+   This is necessary because the IP address is assigned by the
    Coordinator and may not be known a priori.
 
 10. This configuration also includes the Telnet client program.  This

Documentation/platforms/arm/stm32f4/boards/olimex-stm32-p407/index.rst

@@ -290,7 +290,7 @@ must be is one of the following.
 dhtxx
 -----
 
-Configuration added by Abdelatif Guettouche for testing the the DHTxx
+Configuration added by Abdelatif Guettouche for testing the DHTxx
 sensor.  This configuration expects this setup::
 
       DHTXX_PIN_OUTPUT   PG9

Documentation/platforms/arm/stm32l4/boards/b-l475e-iot01a/index.rst

@@ -282,7 +282,7 @@ NOTES:
             nsh> ifconfig wpan0 hw 37
 
       Where 37 the address is an example.  It should be different for
-      each radio, but in the the range 1..ed and ef..fe (ee and ff are
+      each radio, but in the range 1..ed and ef..fe (ee and ff are
       the reserved for multicast and broadcast addresses, respectively.
       Zero is a valid address but not recommended).
 

Documentation/platforms/arm/tiva/index.rst

@@ -174,7 +174,7 @@ currently code complete (minus some ROM *DriverLib* hooks) but untested.
 
 **TI LaunchXL-CC1312R1**. Basic board support for the TI
 LaunchXL-CC1312R1 board is in place. Board bring-up, however, cannot be
-done until the the basic CC13x2 architecture support is complete,
+done until the basic CC13x2 architecture support is complete,
 hopefully in NuttX-7.29.
 
 TI/Stellaris LM4F120x

Documentation/platforms/arm64/qemu/boards/qemu-armv8a/index.rst

@@ -639,7 +639,7 @@ Status
  Ubuntu PC rather than an Ubuntu at VMWare. For Physical Ubuntu PC, the ostest
  was run for 10 times at least but the crash was never seen again, but it's
  almost crashed every time running the ostest at Virtual Ubuntu in VMWare
- Checking for the the fail point. It's seem at signal routine to access another
+ Checking for the fail point. It's seem at signal routine to access another
  CPU's task context reg will get a NULL pointer, but watch the task context with
  GDB, shows everything as OK. So maybe this is a SMP cache synchronize issue?
  But synchronize operations have been done at thread switch. It is hard to

Documentation/platforms/xtensa/esp32/boards/esp32-lyrat/index.rst

@@ -490,7 +490,7 @@ USB connection by means of the CP2102N bridge, at 115200 bps).
 nxrecorder
 ----------
 
-This configuration is used to record raw audio from the the ES8388 audio codec
+This configuration is used to record raw audio from the ES8388 audio codec
 through the I2S0 peripheral to a FAT32 SD Card. By default the audio is recorded from
 the on-board microphones.
 For the ESP32-LyraT, make sure the DIP switches 1 and 2 are turned to the ON position.

Documentation/platforms/z80/ez80/boards/makerlisp/README.txt

@@ -300,7 +300,7 @@ Configuration Subdirectories
        performance because of the zero wait state SRAM implementation.
 
     2. A serial console is provided on UART0.  This configuration should work
-       with or without the the VGA and Keyboard adapter boards.  Normal
+       with or without the VGA and Keyboard adapter boards.  Normal
        connectivity is via host serial console connected through the USB
        serial console.
 

arch/arm/src/am335x/am335x_lcdc.c

@@ -496,7 +496,7 @@ static int am335x_get_refclk(uint32_t *frequency)
  *
  * Returned value:
  *   Zero (OK) is returned on success; a negated errno value is returned in
- *   the the case of a failure.
+ *   the case of a failure.
  *
  ****************************************************************************/
 

arch/arm/src/am335x/am335x_lcdc.h

@@ -211,7 +211,7 @@ struct am335x_panel_info_s
  *
  * Returned value:
  *   Zero (OK) is returned on success; a negated errno value is returned in
- *   the the case of a failure.
+ *   the case of a failure.
  *
  ****************************************************************************/
 

arch/arm/src/am335x/am335x_lowputc.c

@@ -191,7 +191,7 @@ void am335x_lowsetup(void)
 #warning Missing logic
 
   /* Configure UART pins for the selected CONSOLE.  If there are multiple
-   * pin options for a given UART, the the applicable option must be
+   * pin options for a given UART, the applicable option must be
    * disambiguated in the board.h header file.
    */
 

arch/arm/src/at32/at32_gpio.c

@@ -277,7 +277,7 @@ int at32_configgpio(uint32_t cfgset)
   putreg32(regval, base + AT32_GPIO_PULL_OFFSET);
 
   /* Set the alternate function (Only alternate function pins)
-   * This is done after configuring the the pin's connection
+   * This is done after configuring the pin's connection
    * on a change away from an Alternate function.
    */
 

arch/arm/src/at32/at32_pwr.c

@@ -232,7 +232,7 @@ int at32_pwr_enablewkup(enum at32_pwr_wupin_e wupin, bool wupon)
         return -EINVAL;
     }
 
-  /* Set/clear the the wakeup pin enable bit in the CSR.  This must be done
+  /* Set/clear the wakeup pin enable bit in the CSR.  This must be done
    * within a critical section because the CSR is shared with other functions
    * that may be running concurrently on another thread.
    */

arch/arm/src/cxd32xx/cxd32_serial.c

@@ -428,7 +428,7 @@ static void up_shutdown(struct uart_dev_s *dev)
  * Description:
  *   Configure the UART to operation in interrupt driven mode.
  *   This method is called when the serial port is opened.
- *   Normally, this is just after the the setup() method is called,
+ *   Normally, this is just after the setup() method is called,
  *   however, the serial console may operate in  a non-interrupt driven mode
  *   during the boot phase.
  *

arch/arm/src/cxd56xx/cxd56_serial.c

@@ -563,7 +563,7 @@ static void up_shutdown(struct uart_dev_s *dev)
  * Description:
  *   Configure the UART to operation in interrupt driven mode.
  *   This method is called when the serial port is opened.
- *   Normally, this is just after the the setup() method is called,
+ *   Normally, this is just after the setup() method is called,
  *   however, the serial console may operate in  a non-interrupt driven mode
  *   during the boot phase.
  *

arch/arm/src/imx9/imx9_allocateheap.c

@@ -56,7 +56,7 @@
  * .bss in some RAM.  We refer to that RAM as the primary RAM.  It also
  * holds the IDLE threads stack and any remaining portion of the primary
  * OCRAM is automatically added to the heap.  The linker provided address,
- * ... .sbss, .ebss, .sdat, etc. ...  are expected to lie in the the region
+ * ... .sbss, .ebss, .sdat, etc. ...  are expected to lie in the region
  * defined by the OCRAM configuration settings.
  *
  * Other RAM regions must be selected use configuration options and the

arch/arm/src/imx9/imx9_edma.c

@@ -192,7 +192,7 @@ static struct imx9_edmatcd_s *imx9_tcd_alloc(void)
   struct imx9_edmatcd_s *tcd;
   irqstate_t flags;
 
-  /* Take the 'dsem'.  When we hold the the 'dsem', then we know that one
+  /* Take the 'dsem'.  When we hold the 'dsem', then we know that one
    * TCD is reserved for us in the free list.
    *
    * NOTE: We use a critical section here because we may block waiting for
@@ -224,7 +224,7 @@ static struct imx9_edmatcd_s *imx9_tcd_alloc(void)
 #if CONFIG_IMX9_EDMA_NTCD > 0
 static void imx9_tcd_free_nolock(struct imx9_edmatcd_s *tcd)
 {
-  /* Add the the TCD to the end of the free list and post the 'dsem',
+  /* Add the TCD to the end of the free list and post the 'dsem',
    * possibly waking up another thread that might be waiting for
    * a TCD.
    */
@@ -237,7 +237,7 @@ static void imx9_tcd_free(struct imx9_edmatcd_s *tcd)
 {
   irqstate_t flags;
 
-  /* Add the the TCD to the end of the free list and post the 'dsem',
+  /* Add the TCD to the end of the free list and post the 'dsem',
    * possibly waking up another thread that might be waiting for
    * a TCD.
    */
@@ -1328,7 +1328,7 @@ int imx9_dmach_xfrsetup(DMACH_HANDLE handle,
  *   this will be generated with the final TCD.
  *
  *   At the conclusion of the DMA, the DMA channel is reset, all TCDs are
- *   freed, and the callback function is called with the the success/fail
+ *   freed, and the callback function is called with the success/fail
  *   result of the DMA.
  *
  *   NOTE: On Rx DMAs (peripheral-to-memory or memory-to-memory), it is
@@ -1417,7 +1417,7 @@ void imx9_dmach_stop(DMACH_HANDLE handle)
  *
  * Description:
  *   This function checks the TCD (Task Control Descriptor) status for a
- *   specified eDMA channel and returns the the number of major loop counts
+ *   specified eDMA channel and returns the number of major loop counts
  *   that have not finished.
  *
  *   NOTES:

arch/arm/src/imx9/imx9_edma.h

@@ -350,7 +350,7 @@ int imx9_dmach_xfrsetup(DMACH_HANDLE handle,
  *   interrupts will be generated with the final being the DONE interrupt.
  *
  *   At the conclusion of the DMA, the DMA channel is reset, all TCDs are
- *   freed, and the callback function is called with the the success/fail
+ *   freed, and the callback function is called with the success/fail
  *   result of the DMA.
  *
  *   NOTE:
@@ -397,7 +397,7 @@ void imx9_dmach_stop(DMACH_HANDLE handle);
  *
  * Description:
  *   This function checks the TCD (Task Control Descriptor) status for a
- *   specified eDMA channel and returns the the number of major loop counts
+ *   specified eDMA channel and returns the number of major loop counts
  *   that have not finished.
  *
  *   NOTES:

arch/arm/src/imxrt/imxrt_allocateheap.c

@@ -70,7 +70,7 @@
  * .bss in some RAM.  We refer to that RAM as the primary RAM.  It also
  * holds the IDLE threads stack and any remaining portion of the primary
  * OCRAM is automatically added to the heap.  The linker provided address,
- * ... .sbss, .ebss, .sdat, etc. ...  are expected to lie in the the region
+ * ... .sbss, .ebss, .sdat, etc. ...  are expected to lie in the region
  * defined by the OCRAM configuration settings.
  *
  * Other RAM regions must be selected use configuration options and the

arch/arm/src/imxrt/imxrt_edma.c

@@ -191,7 +191,7 @@ static struct imxrt_edmatcd_s *imxrt_tcd_alloc(void)
   struct imxrt_edmatcd_s *tcd;
   irqstate_t flags;
 
-  /* Take the 'dsem'.  When we hold the the 'dsem', then we know that one
+  /* Take the 'dsem'.  When we hold the 'dsem', then we know that one
    * TCD is reserved for us in the free list.
    *
    * NOTE: We use a critical section here because we may block waiting for
@@ -223,7 +223,7 @@ static struct imxrt_edmatcd_s *imxrt_tcd_alloc(void)
 #if CONFIG_IMXRT_EDMA_NTCD > 0
 static void imxrt_tcd_free_nolock(struct imxrt_edmatcd_s *tcd)
 {
-  /* Add the the TCD to the end of the free list and post the 'dsem',
+  /* Add the TCD to the end of the free list and post the 'dsem',
    * possibly waking up another thread that might be waiting for
    * a TCD.
    */
@@ -236,7 +236,7 @@ static void imxrt_tcd_free(struct imxrt_edmatcd_s *tcd)
 {
   irqstate_t flags;
 
-  /* Add the the TCD to the end of the free list and post the 'dsem',
+  /* Add the TCD to the end of the free list and post the 'dsem',
    * possibly waking up another thread that might be waiting for
    * a TCD.
    */
@@ -1126,7 +1126,7 @@ int imxrt_dmach_xfrsetup(DMACH_HANDLE handle,
  *   this will be generated with the final TCD.
  *
  *   At the conclusion of the DMA, the DMA channel is reset, all TCDs are
- *   freed, and the callback function is called with the the success/fail
+ *   freed, and the callback function is called with the success/fail
  *   result of the DMA.
  *
  *   NOTE: On Rx DMAs (peripheral-to-memory or memory-to-memory), it is
@@ -1220,7 +1220,7 @@ void imxrt_dmach_stop(DMACH_HANDLE handle)
  *
  * Description:
  *   This function checks the TCD (Task Control Descriptor) status for a
- *   specified eDMA channel and returns the the number of major loop counts
+ *   specified eDMA channel and returns the number of major loop counts
  *   that have not finished.
  *
  *   NOTES:

arch/arm/src/imxrt/imxrt_edma.h

@@ -331,7 +331,7 @@ int imxrt_dmach_xfrsetup(DMACH_HANDLE handle,
  *   interrupts will be generated with the final being the DONE interrupt.
  *
  *   At the conclusion of the DMA, the DMA channel is reset, all TCDs are
- *   freed, and the callback function is called with the the success/fail
+ *   freed, and the callback function is called with the success/fail
  *   result of the DMA.
  *
  *   NOTE: On Rx DMAs (peripheral-to-memory or memory-to-memory), it is
@@ -377,7 +377,7 @@ void imxrt_dmach_stop(DMACH_HANDLE handle);
  *
  * Description:
  *   This function checks the TCD (Task Control Descriptor) status for a
- *   specified eDMA channel and returns the the number of major loop counts
+ *   specified eDMA channel and returns the number of major loop counts
  *   that have not finished.
  *
  *   NOTES:

arch/arm/src/imxrt/imxrt_ehci.c

@@ -4770,7 +4770,7 @@ static int imxrt_cancel(struct usbhost_driver_s *drvr, usbhost_ep_t ep)
 
   /* We must have exclusive access to the EHCI hardware and data structures.
    * This will prevent servicing any transfer completion events while we
-   * perform the the cancellation, but will not prevent DMA-related race
+   * perform the cancellation, but will not prevent DMA-related race
    * conditions.
    *
    * REVISIT: This won't work.  This function must be callable from the

arch/arm/src/imxrt/imxrt_hprtc.c

@@ -356,7 +356,7 @@ int imxrt_hprtc_initialize(void)
 {
   uint32_t regval;
 
-  /* Enable clocking to the the SNVS HP module.
+  /* Enable clocking to the SNVS HP module.
    * Clock is on in run mode, but off in WAIT and STOP modes.
    */
 

arch/arm/src/imxrt/imxrt_lpsrtc.c

@@ -114,7 +114,7 @@ int imxrt_lpsrtc_initialize(void)
 
   imxrt_hprtc_initialize();
 
-  /* Enable clocking to the the SNVS LP module.
+  /* Enable clocking to the SNVS LP module.
    * Clock is on during all modes, except STOP mode.
    */
 

arch/arm/src/kinetis/kinetis_edma.c

@@ -191,7 +191,7 @@ static struct kinetis_edmatcd_s *kinetis_tcd_alloc(void)
   struct kinetis_edmatcd_s *tcd;
   irqstate_t flags;
 
-  /* Take the 'dsem'.  When we hold the the 'dsem', then we know that one
+  /* Take the 'dsem'.  When we hold the 'dsem', then we know that one
    * TCD is reserved for us in the free list.
    *
    * NOTE: We use a critical section here because we may block waiting for
@@ -224,7 +224,7 @@ static struct kinetis_edmatcd_s *kinetis_tcd_alloc(void)
 #if CONFIG_KINETIS_EDMA_NTCD > 0
 static void kinetis_tcd_free_nolock(struct kinetis_edmatcd_s *tcd)
 {
-  /* Add the the TCD to the end of the free list and post the 'dsem',
+  /* Add the TCD to the end of the free list and post the 'dsem',
    * possibly waking up another thread that might be waiting for
    * a TCD.
    */
@@ -237,7 +237,7 @@ static void kinetis_tcd_free(struct kinetis_edmatcd_s *tcd)
 {
   irqstate_t flags;
 
-  /* Add the the TCD to the end of the free list and post the 'dsem',
+  /* Add the TCD to the end of the free list and post the 'dsem',
    * possibly waking up another thread that might be waiting for
    * a TCD.
    */
@@ -1098,7 +1098,7 @@ int kinetis_dmach_xfrsetup(DMACH_HANDLE *handle,
  *   this will be generated with the final TCD.
  *
  *   At the conclusion of the DMA, the DMA channel is reset, all TCDs are
- *   freed, and the callback function is called with the the success/fail
+ *   freed, and the callback function is called with the success/fail
  *   result of the DMA.
  *
  *   NOTE: On Rx DMAs (peripheral-to-memory or memory-to-memory), it is
@@ -1192,7 +1192,7 @@ void kinetis_dmach_stop(DMACH_HANDLE handle)
  *
  * Description:
  *   This function checks the TCD (Task Control Descriptor) status for a
- *   specified eDMA channel and returns the the number of major loop counts
+ *   specified eDMA channel and returns the number of major loop counts
  *   that have not finished.
  *
  *   NOTES:

arch/arm/src/kinetis/kinetis_edma.h

@@ -331,7 +331,7 @@ int kinetis_dmach_xfrsetup(DMACH_HANDLE *handle,
  *   interrupts will be generated with the final being the DONE interrupt.
  *
  *   At the conclusion of the DMA, the DMA channel is reset, all TCDs are
- *   freed, and the callback function is called with the the success/fail
+ *   freed, and the callback function is called with the success/fail
  *   result of the DMA.
  *
  *   NOTE:
@@ -378,7 +378,7 @@ void kinetis_dmach_stop(DMACH_HANDLE handle);
  *
  * Description:
  *   This function checks the TCD (Task Control Descriptor) status for a
- *   specified eDMA channel and returns the the number of major loop counts
+ *   specified eDMA channel and returns the number of major loop counts
  *   that have not finished.
  *
  *   NOTES: