doc: sphinx-lint: fix bad usage of "default role"

Fixes bad usage of single backticks in lieu of double backticks for
rendering inline literals, or simple '*' for italics.

When appropriate, a better construct than double backticks has been
selected (ex. :file:, :kconfig:option:, :c:func:, ...), or proper :ref:
have been used if the original intention was to have a link.

Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>

boards/adafruit/feather_nrf52840/doc/index.rst

@@ -181,8 +181,8 @@ but does not support debugging the device.
 #. If using UF2, connect the board to your host computer using USB.
 
 #. Tap the reset button twice quickly to enter bootloader mode.
-   A mass storage device named `FTHR840BOOT` for (Express) or
-   `FTHRSNSBOOT` (Sense) should appear on the host. Ensure this is
+   A mass storage device named ``FTHR840BOOT`` for (Express) or
+   ``FTHRSNSBOOT`` (Sense) should appear on the host. Ensure this is
    mounted.
 
 #. Flash the image.

boards/adafruit/kb2040/doc/index.rst

@@ -117,7 +117,7 @@ Using UF2
 
 Since it doesn't expose the SWD pins, you must flash the Adafruit KB2040 with
 a UF2 file. By default, building an app for this board will generate a
-`build/zephyr/zephyr.uf2` file. If the KB2040 is powered on with the `BOOTSEL`
+:file:`build/zephyr/zephyr.uf2` file. If the KB2040 is powered on with the ``BOOTSEL``
 button pressed, it will appear on the host as a mass storage device. The
 UF2 file should be drag-and-dropped to the device, which will flash the KB2040.
 

boards/adafruit/qt_py_rp2040/doc/index.rst

@@ -116,7 +116,7 @@ Using UF2
 
 Since it doesn't expose the SWD pins, you must flash the Adafruit QT Py RP2040 with
 a UF2 file. By default, building an app for this board will generate a
-`build/zephyr/zephyr.uf2` file. If the QT Py RP2040 is powered on with the `BOOTSEL`
+:file:`build/zephyr/zephyr.uf2` file. If the QT Py RP2040 is powered on with the ``BOOTSEL``
 button pressed, it will appear on the host as a mass storage device. The
 UF2 file should be drag-and-dropped to the device, which will flash the QT Py RP2040.
 

boards/ambiq/apollo3_evb/doc/index.rst

@@ -69,7 +69,7 @@ Build the Zephyr kernel and application, then flash it to the device:
    :goals: flash
 
 .. note::
-   `west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module
+   ``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module
    to be installed on you host computer.
 
 Open a serial terminal (minicom, putty, etc.) with the following settings:

boards/ambiq/apollo3p_evb/doc/index.rst

@@ -69,7 +69,7 @@ Build the Zephyr kernel and application, then flash it to the device:
    :goals: flash
 
 .. note::
-   `west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module
+   ``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module
    to be installed on you host computer.
 
 Open a serial terminal (minicom, putty, etc.) with the following settings:

boards/ambiq/apollo4p_blue_kxr_evb/doc/index.rst

@@ -77,7 +77,7 @@ Build the Zephyr kernel and application, then flash it to the device:
    :goals: flash
 
 .. note::
-   `west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module
+   ``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module
    to be installed on you host computer.
 
 Open a serial terminal (minicom, putty, etc.) with the following settings:

boards/ambiq/apollo4p_evb/doc/index.rst

@@ -72,7 +72,7 @@ Build the Zephyr kernel and application, then flash it to the device:
    :goals: flash
 
 .. note::
-   `west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module
+   ``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module
    to be installed on you host computer.
 
 Open a serial terminal (minicom, putty, etc.) with the following settings:

boards/arduino/nano_33_ble/doc/index.rst

@@ -160,7 +160,7 @@ That license ties to Arduino Nano 33 BLE hardware serial number,
 it also works with the ZephyrRTOS.
 
 Follow the instruction of the tutorial for Arduino
-`Lauterbach TRACE32 GDB Front-End Debugger for Nano 33 BLE`
+`Lauterbach TRACE32 GDB Front-End Debugger for Nano 33 BLE`_
 to install the TRACE32.
 
 After installing the TRACE32, You should set the environmental variable ``T32_DIR``.

boards/arm/fvp_base_revc_2xaemv8a/doc/index.rst

@@ -99,7 +99,7 @@ Checkout and Build the TF-A:
    cd trusted-firmware-a/
    make PLAT=fvp PRELOADED_BL33_BASE="0x88000000" all fip
 
-then export the ``ARMFVP_BL1_FILE` and ``ARMFVP_FIP_FILE`` environment variables:
+then export the :envvar:`ARMFVP_BL1_FILE` and :envvar:`ARMFVP_FIP_FILE` environment variables:
 
 .. code-block:: console
 

boards/circuitdojo/feather/doc/index.rst

@@ -100,7 +100,7 @@ or Nordic based examples.
    Trusted Firmware-M (TF-M) and building the ``ns`` target is not supported for this board.
 
 Some of the examples do not use secure mode, so they do not require the
-``ns`` suffix. A great example of this is the `hello_world` below.
+``ns`` suffix. A great example of this is the ``hello_world`` below.
 
 Flashing
 ========

boards/ct/ctcc/doc/index.rst

@@ -172,7 +172,7 @@ As an example we'll use the :zephyr:code-sample:`usb-cdc-acm-console` sample.
 
 .. note::
 
-   In all examples it is assumed to use default `root-rsa-2048.pem` file from ``mcuboot/boot``
+   In all examples it is assumed to use default :file:`root-rsa-2048.pem` file from ``mcuboot/boot``
    directory. Providing certificate in build args produces signed binary automatically.
    Do not use this certificate in your production firmware!
 
@@ -180,7 +180,7 @@ As an example we'll use the :zephyr:code-sample:`usb-cdc-acm-console` sample.
    and plug such adapter to USB port.
 
    You should see ``NordicSemiconductor MCUBOOT`` or ``NordicSemiconductor Zephyr DFU sample``
-   (if you flashed `dfu` sample to slot0) device once plugging it into host
+   (if you flashed ``dfu`` sample to slot0) device once plugging it into host
    USB port. You can check that on Linux system by entering ``lsusb`` command.
 
    To check if DFU device is visible you can enter ``sudo dfu-util -l`` command. Once the

boards/enjoydigital/litex_vexriscv/doc/index.rst

@@ -184,7 +184,7 @@ Use `ecpprog <https://github.com/gregdavill/ecpprog>`_ to upload the bitstream t
 
    ecpprog -S antmicro_sdi_mipi_video_converter.bit
 
-You can boot from a serial port using litex_term (replace `ttyUSBX` with your device) , e.g.:
+You can boot from a serial port using litex_term (replace ``ttyUSBX`` with your device) , e.g.:
 
 .. code-block:: bash
 

boards/intel/rpl/doc/index.rst

@@ -23,7 +23,7 @@ please refer to `RPL`_.
 
 Raptor Lake Customer Reference Board (RPL CRB) is an example implementation of a
 compact single board computer with high performance for IoT edge devices. The
-supported boards are `intel_rpl_s_crb` and `intel_rpl_p_crb`.
+supported boards are ``intel_rpl_s_crb`` and ``intel_rpl_p_crb``.
 
 These board configurations enable kernel support for the supported Raptor Lake
 boards.

boards/intel/socfpga/agilex5_socdk/doc/index.rst

@@ -45,7 +45,7 @@ hardware features:
 NOTE: TODO, more details on dev kit will be updated as and when available.
 
 The default configuration can be found in the defconfig file:
-        `boards/intel/socfpga/agilex5_socdk/intel_socfpga_agilex5_socdk_defconfig`
+:zephyr_file:`boards/intel/socfpga/agilex5_socdk/intel_socfpga_agilex5_socdk_defconfig`.
 
 Programming and Debugging
 *************************

boards/m5stack/m5stack_core2/doc/index.rst

@@ -79,7 +79,7 @@ of the M5Stack Core2 board.
 | MPU6886          | combines a 3-axis gyroscope and a 3-axis accelerometer.                  |           |
 |                  | For details please refer to :ref:`m5stack_core2_ext`                     |           |
 +------------------+--------------------------------------------------------------------------+-----------+
-| Grove port       | Note: Grove port requires 5V to be enabled via `bus_5v` regulator        | supported |
+| Grove port       | Note: Grove port requires 5V to be enabled via ``bus_5v`` regulator      | supported |
 +------------------+--------------------------------------------------------------------------+-----------+
 | Built-in         | The `SPM-1423`_ I2S driven microphone.                                   | todo      |
 | microphone       |                                                                          |           |

boards/native/doc/arch_soc.rst

@@ -183,7 +183,7 @@ Currently, these are the most significant features which are not supported in th
 * Stack checks: :kconfig:option:`CONFIG_HW_STACK_PROTECTION`,
   :kconfig:option:`CONFIG_STACK_CANARIES`, and
   :kconfig:option:`CONFIG_THREAD_ANALYZER`.
-  This is due to how Zephyr allocated threads' stacks are not `actually` being used like they are
+  This is due to how Zephyr allocated threads' stacks are not *actually* being used like they are
   in other architectures. Check
   :ref:`the architecture section's architecture layer paragraph <posix_arch_design_archl>`
   for more information.
@@ -355,7 +355,7 @@ while this newly created thread will be the first "SW" thread and start
 executing the boot of the embedded code (including the POSIX arch code).
 
 During this MCU boot process, the Zephyr kernel will be initialized and
-eventually this will call into the embedded application `main()`,
+eventually this will call into the embedded application ``main()``,
 just like in the embedded target.
 As the embedded SW execution progresses, more Zephyr threads may be spawned,
 and for each the POSIX architecture will create a dedicated pthread.
@@ -413,7 +413,7 @@ Busy waits
 Busy waits work thanks to provided board functionality.
 This does not need to be the same for all boards, but both native_sim and the
 nrf52_bsim board work similarly thru the combination of a board specific
-`arch_busy_wait()` and a special fake HW timer (provided by the board).
+:c:func:`arch_busy_wait()` and a special fake HW timer (provided by the board).
 
 When a SW thread wants to busy wait, this fake timer will be programmed in
 the future time corresponding to the end of the busy wait and the CPU will
@@ -422,7 +422,7 @@ When this fake HW timer expires the CPU will be waken with a special
 non-maskable phony interrupt which does not have a corresponding interrupt
 handler but will resume the busy_wait SW execution.
 Note that other interrupts may arrive while the busy wait is in progress,
-which may delay the `k_busy_wait()` return just like in real life.
+which may delay the :c:func:`k_busy_wait()` return just like in real life.
 
 Interrupts may be locked out or masked during this time, but the special
 fake-timer non-maskable interrupt will wake the CPU nonetheless.

boards/native/doc/bsim_boards_design.rst

@@ -16,7 +16,7 @@ Bsim boards
 
 This page covers the design, architecture and rationale, of the
 nrf5x_bsim boards and other similar bsim boards.
-These boards are postfixed with `_bsim` as they use BabbleSim_
+These boards are postfixed with ``_bsim`` as they use BabbleSim_
 (shortened bsim), to simulate the radio environment.
 These boards use the `native simulator`_ and the :ref:`POSIX architecture<Posix arch>` to build
 and execute the embedded code natively on Linux.
@@ -135,13 +135,13 @@ The basic architecture layering of these boards is as follows:
   simulation specific ones.
 - The architecture (arch) is the Zephyr :ref:`POSIX architecture<Posix arch>`
   layer.
-  The SOC layer is `inf_clock`. And the board layer is dependent on
+  The SOC layer is ``inf_clock``. And the board layer is dependent on
   the specific device we are simulating.
 - The POSIX architecture provides an adaptation from the Zephyr arch API
   (which handles mostly the thread context switching) to the native simulator
   CPU thread emulation.
   See :ref:`POSIX arch architecture<posix_arch_architecture>`
-- The SOC `inf_clock` layer provides an adaptation to the native simulator CPU "simulation"
+- The SOC ``inf_clock`` layer provides an adaptation to the native simulator CPU "simulation"
   and the handling of control between the "CPU simulation" (Zephyr threads) and the
   HW models thread ( See `Threading`_ ).
 - The board layer provides all SOC/ IC specific content, including
@@ -149,13 +149,13 @@ The basic architecture layering of these boards is as follows:
   busy wait API (see :ref:`posix_busy_wait<posix_busy_wait>`), and Zephyr's printk backend.
   Note that in a normal Zephyr target interrupt handling and a custom busy wait
   would be provided by the SOC layer, but abusing Zephyr's layering, and for the
-  `inf_clock` layer to be generic, these were delegated to the board.
+  ``inf_clock`` layer to be generic, these were delegated to the board.
   The board layer provides other test specific
   functionality like bs_tests hooks, trace control, etc, and
   by means of the native simulator, provides the :c:func:`main` entry point for the Linux
   program, command line argument handling, and the overall time scheduling of
   the simulated device.
-  Note that the POSIX arch and `inf_clock` soc expect a set of APIs being provided by
+  Note that the POSIX arch and ``inf_clock`` soc expect a set of APIs being provided by
   the board. This includes the busy wait API, a basic tracing API, the interrupt
   controller and interrupt handling APIs, :c:func:`posix_exit`,
   and :c:func:`posix_get_hw_cycle` (see :file:`posix_board_if.h` and :file:`posix_soc_if.h`).
@@ -173,7 +173,7 @@ Important limitations and unsupported features
 
 All native and bsim boards share the same set of
 :ref:`important limitations which<posix_arch_limitations>`
-are inherited from the POSIX arch and `inf_clock` design.
+are inherited from the POSIX arch and ``inf_clock`` design.
 
 Similarly, they inherit the POSIX architecture
 :ref:`unsupported features set <posix_arch_unsupported>`.
@@ -261,7 +261,7 @@ posix_print and nsi_print backends
 ==================================
 
 The bsim board provides a backend for the ``posix_print`` API which is expected by the posix
-ARCH and `inf_clock` code, and for the ``nsi_print`` API expected by the native simulator.
+ARCH and ``inf_clock`` code, and for the ``nsi_print`` API expected by the native simulator.
 
 These simply route this API calls into the ``bs_trace`` bsim API.
 Any message printed to these APIs, and by extension by default to Zephyr's ``printk``,
@@ -287,12 +287,12 @@ callbacks are assigned to the respective hooks.
 There is a set of one time hooks at different levels of initialization of the HW
 and Zephyr OS, a hook to process possible command line arguments, and, a hook
 that can be used to sniff or capture interrupts.
-`bs_tests` also provides a hook which will be called from the embedded application
+``bs_tests`` also provides a hook which will be called from the embedded application
 :c:func:`main`, but this will only work if the main application supports it,
 that is, if the main app is a version for simulation which calls
 :c:func:`bst_main` when running in the bsim board.
 
-Apart from these hooks, the `bs_tests` system provides facilities to build a
+Apart from these hooks, the ``bs_tests`` system provides facilities to build a
 dedicated test "task". This will be executed in the HW models thread context,
 but will have access to all SW variables. This task will be driven with a
 special timer which can be configured to produce either periodic or one time
@@ -302,15 +302,15 @@ at specific points in time. This can be combined with Babblesim's tb_defs macros
 to build quite complex test tasks which can wait for a given amount of time,
 for conditions to be fulfilled, etc.
 
-Note when writing the tests with `bs_tests` one needs to be aware that other
+Note when writing the tests with ``bs_tests`` one needs to be aware that other
 bs tests will probably be built with the same application, and that therefore
 the tests should not be registering initialization or callback functions using
 NATIVE_TASKS or Zephyr's PRE/POST kernel driver initialization APIs as this
 will execute even if the test is not selected.
-Instead the equivalent `bs_tests` provided hooks should be used.
+Instead the equivalent ``bs_tests`` provided hooks should be used.
 
 Note also that, for AMP targets like the :ref:`nrf5340bsim <nrf5340bsim>`, each embedded MCU has
-its own separate `bs_tests` built with that MCU. You can select if and what test is used
+its own separate ``bs_tests`` built with that MCU. You can select if and what test is used
 for each MCU separatedly with the command line options.
 
 Command line argument parsing

boards/nxp/lpcxpresso54114/doc/index.rst

@@ -74,8 +74,8 @@ features:
 
 The default configuration for each core can be found in the defconfig files:
 
-	`boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m4_defconfig`
-	`boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m0_defconfig`
+- :zephyr_file:`boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m4_defconfig`
+- :zephyr_file:`boards/nxp/lpcxpresso54114/lpcxpresso54114_lpc54114_m0_defconfig`
 
 Other hardware features are not currently supported by the port.
 

boards/nxp/lpcxpresso55s69/doc/index.rst

@@ -299,7 +299,7 @@ board.
 -----------------------------------------
 
         1. Install the :ref:`linkserver-debug-host-tools` and make sure they are in your search path.
-        2. To update the debug firmware, please follow the instructions on `LPCXPRESSO55S69 Debug Firmware`
+        2. To update the debug firmware, please follow the instructions on `LPCXPRESSO55S69 Debug Firmware`_
 
 :ref:`opensda-daplink-onboard-debug-probe`
 ------------------------------------------

boards/nxp/mimxrt1040_evk/doc/index.rst

@@ -335,7 +335,7 @@ Remove resistors from R497, R498, R456 and R457.
 
 And due to pin conflict issue, the PCM interface of Bluetooth module cannot be supported.
 
-For the debugger fails to connect with the following error, please refer to section `WiFi Module`.
+For the debugger fails to connect with the following error, please refer to the next section.
 
 WiFi Module
 -----------

boards/nxp/mimxrt1170_evk/doc/index.rst

@@ -111,8 +111,8 @@ NXP considers the MIMXRT1170-EVK as the superset board for the i.MX RT11xx
 family of MCUs.  This board is a focus for NXP's Full Platform Support for
 Zephyr, to better enable the entire RT11xx family.  NXP prioritizes enabling
 this board with new support for Zephyr features. Note that this table
-covers two boards: the RT1170 EVK (`mimxrt1170_evk//cm7/cm4`), and
-RT1170 EVKB (`mimxrt1170_evk@B//cm7/cm4`)
+covers two boards: the RT1170 EVK (``mimxrt1170_evk//cm7/cm4``), and
+RT1170 EVKB (``mimxrt1170_evk@B//cm7/cm4``)
 
 +-----------+------------+-------------------------------------+-----------------+-----------------+
 | Interface | Controller | Driver/Component                    | RT1170 EVK      | RT1170 EVKB     |
@@ -478,4 +478,4 @@ ENET1G Driver
 
 Current default of ethernet driver is to use 100M Ethernet instance ENET.
 To use the 1G Ethernet instance ENET1G, include the overlay to west build with
-the option `-DEXTRA_DTC_OVERLAY_FILE=nxp,enet1g.overlay` instead.
+the option ``-DEXTRA_DTC_OVERLAY_FILE=nxp,enet1g.overlay`` instead.

boards/nxp/rd_rw612_bga/doc/index.rst

@@ -196,7 +196,7 @@ Remove resistors:
 - R508
 - R505
 
-Then, build for the board target `rd_rw612_bga//ethernet`.
+Then, build for the board target ``rd_rw612_bga//ethernet``.
 
 Resources
 *********

boards/nxp/s32z2xxdc2/doc/index.rst

@@ -118,7 +118,7 @@ Serial Port
 ===========
 
 The SoC has 12 LINFlexD instances that can be used in UART mode. The console can
-be accessed by default on the USB micro-B connector `J119`.
+be accessed by default on the USB micro-B connector J119.
 
 Watchdog
 ========

boards/phytec/phyboard_electra/doc/index.rst

@@ -84,7 +84,7 @@ GPIO
 ----
 
 The phyCORE-AM64x has a heartbeat LED connected to gpio6. It's configured
-to build and run the `basic/blinky` sample.
+to build and run the :zephyr:code-sample:`blinky` sample.
 
 SD Card
 *******
@@ -111,9 +111,11 @@ To test the M4F core, we build the :ref:`hello_world` sample with the following
    :zephyr-app: samples/hello_world
    :goals: build
 
-This builds the program and the binary is present in the `build/zephyr` directory as `zephyr.elf`.
+This builds the program and the binary is present in the :file:`build/zephyr` directory as
+:file:`zephyr.elf`.
 
-We now copy this binary onto the SD card in the `/lib/firmware` directory and name it as `am64-mcu-m4f0_0-fw`.
+We now copy this binary onto the SD card in the :file:`/lib/firmware` directory and name it as
+:file:`am64-mcu-m4f0_0-fw`.
 
 .. code-block:: console
 

boards/phytec/phyboard_lyra/doc/phyboard_lyra_am62xx_m4.rst

@@ -96,16 +96,18 @@ The Linux running on the A53 uses the remoteproc framework to manage the M4F co-
 Therefore, the testing requires the binary to be copied to the SD card to allow the A53 cores to
 load it while booting using remoteproc.
 
-To test the M4F core, we build the `hello_world` sample with the following command.
+To test the M4F core, we build the :ref:`hello_world` sample with the following command.
 
 .. code-block:: console
 
    # From the root of the Zephyr repository
    west build -p -b phyboard_lyra/am6234/m4 samples/hello_world
 
-This builds the program and the binary is present in the `build/zephyr` directory as `zephyr.elf`.
+This builds the program and the binary is present in the :file:`build/zephyr` directory as
+:file:`zephyr.elf`.
 
-We now copy this binary onto the SD card in the `/lib/firmware` directory and name it as `am62-mcu-m4f0_0-fw`.
+We now copy this binary onto the SD card in the :file:`/lib/firmware` directory and name it as
+:file:`am62-mcu-m4f0_0-fw`.
 
 .. code-block:: console
 
@@ -134,7 +136,8 @@ port.
 Debugging
 *********
 
-The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the `debug` build target:
+The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the ``debug`` build
+target:
 
 .. zephyr-app-commands::
    :app: <my_app>

boards/rak/rak11720/doc/index.rst

@@ -92,7 +92,7 @@ Build the Zephyr kernel and application, then flash it to the device:
    :goals: flash
 
 .. note::
-   `west flash` requires `SEGGER J-Link software`_ and `pylink`_ Python module
+   ``west flash`` requires `SEGGER J-Link software`_ and `pylink`_ Python module
    to be installed on you host computer.
 
 Open a serial terminal (minicom, putty, etc.) with the following settings:

boards/raspberrypi/rpi_5/doc/index.rst

@@ -69,7 +69,7 @@ In brief,
         * `bcm2712-rpi-5.dtb`_
     3. Insert the Micro SD card and power on the Raspberry Pi 5.
 
-then, You will see the Raspberry Pi 5 running the `zephyr.bin`.
+then, You will see the Raspberry Pi 5 running the :file:`zephyr.bin`.
 
 config.txt
 ----------
@@ -83,14 +83,15 @@ config.txt
 zephyr.bin
 ----------
 
-Build an app `samples/basic/blinky`
+Build an app, for example :zephyr:code-sample:`blinky`
 
 .. zephyr-app-commands::
    :zephyr-app: samples/basic/blinky
    :board: rpi_5
    :goals: build
 
-Copy `zephyr.bin` from `build/zephyr` directory to the root directory of the Micro SD card.
+Copy :file:`zephyr.bin` from :file:`build/zephyr` directory to the root directory of the Micro SD
+card.
 
 Insert the Micro SD card and power on the Raspberry Pi 5. And then, the STAT LED will start to blink.
 
@@ -125,14 +126,14 @@ config.txt
 zephyr.bin
 ----------
 
-Build an app `samples/hello_world`
+Build an app, for example :ref:`hello_world`:
 
 .. zephyr-app-commands::
    :zephyr-app: samples/hello_world
    :board: rpi_5
    :goals: build
 
-Copy `zephyr.bin` from `build/zephyr` directory to the root directory of the Micro SD card.
+Copy :file:`zephyr.bin` from :file:`build/zephyr` directory to the root directory of the Micro SD card.
 
 Insert the Micro SD card into your Raspberry Pi 5.
 

boards/raspberrypi/rpi_pico/doc/index.rst

@@ -137,11 +137,11 @@ Programmable I/O (PIO)
 The RP2040 SoC comes with two PIO periherals. These are two simple
 co-processors that are designed for I/O operations. The PIOs run
 a custom instruction set, generated from a custom assembly language.
-PIO programs are assembled using `pioasm`, a tool provided by Raspberry Pi.
+PIO programs are assembled using :command:`pioasm`, a tool provided by Raspberry Pi.
 
 Zephyr does not (currently) assemble PIO programs. Rather, they should be
 manually assembled and embedded in source code. An example of how this is done
-can be found at `drivers/serial/uart_rpi_pico_pio.c`.
+can be found at :zephyr_file:`drivers/serial/uart_rpi_pico_pio.c`.
 
 Sample:  SPI via PIO
 ====================
@@ -187,7 +187,7 @@ Create a file in /etc/udev.rules.d with any name, and write the line below.
 
    ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="660", GROUP="plugdev", TAG+="uaccess"
 
-This example is valid for the case that the user joins to `plugdev` groups.
+This example is valid for the case that the user joins to ``plugdev`` groups.
 
 The Raspberry Pi Pico has an SWD interface that can be used to program
 and debug the on board RP2040. This interface can be utilized by OpenOCD.
@@ -208,22 +208,23 @@ Here is an example of building and flashing the :zephyr:code-sample:`blinky` app
    :goals: build flash
    :gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=cmsis-dap
 
-Set the environment variables **OPENOCD** to `/usr/local/bin/openocd`
-and **OPENOCD_DEFAULT_PATH** to `/usr/local/share/openocd/scripts`. This should work
+Set the environment variables **OPENOCD** to :file:`/usr/local/bin/openocd`
+and **OPENOCD_DEFAULT_PATH** to :file:`/usr/local/share/openocd/scripts`. This should work
 with the OpenOCD that was installed with the default configuration.
 This configuration also works with an environment that is set up by the `pico_setup.sh`_ script.
 
 **RPI_PICO_DEBUG_ADAPTER** specifies what debug adapter is used for debugging.
 
-If **RPI_PICO_DEBUG_ADAPTER** was not assigned, `cmsis-dap` is used by default.
-The other supported adapters are `raspberrypi-swd`, `jlink` and `blackmagicprobe`.
-How to connect `cmsis-dap` and `raspberrypi-swd` is described in `Getting Started with Raspberry Pi Pico`_.
+If **RPI_PICO_DEBUG_ADAPTER** was not assigned, ``cmsis-dap`` is used by default.
+The other supported adapters are ``raspberrypi-swd``, ``jlink`` and ``blackmagicprobe``.
+How to connect ``cmsis-dap`` and ``raspberrypi-swd`` is described in `Getting Started with Raspberry Pi Pico`_.
 Any other SWD debug adapter maybe also work with this configuration.
 
 The value of **RPI_PICO_DEBUG_ADAPTER** is cached, so it can be omitted from
-`west flash` and `west debug` if it was previously set while running `west build`.
+``west flash`` and ``west debug`` if it was previously set while running
+``west build``.
 
-**RPI_PICO_DEBUG_ADAPTER** is used in an argument to OpenOCD as `"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"`.
+**RPI_PICO_DEBUG_ADAPTER** is used in an argument to OpenOCD as ``"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"``.
 Thus, **RPI_PICO_DEBUG_ADAPTER** needs to be assigned the file name of the debug adapter.
 
 You can also flash the board with the following
@@ -238,7 +239,7 @@ Using UF2
 
 If you don't have an SWD adapter, you can flash the Raspberry Pi Pico with
 a UF2 file. By default, building an app for this board will generate a
-`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the `BOOTSEL`
+:file:`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the ``BOOTSEL``
 button pressed, it will appear on the host as a mass storage device. The
 UF2 file should be drag-and-dropped to the device, which will flash the Pico.
 
@@ -270,7 +271,7 @@ Here is an example for debugging the :zephyr:code-sample:`blinky` application.
    :gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=raspberrypi-swd
 
 As with flashing, you can specify the debug adapter by specifying **RPI_PICO_DEBUG_ADAPTER**
-at `west build` time. No needs to specify it at `west debug` time.
+at ``west build`` time. No needs to specify it at ``west debug`` time.
 
 You can also debug with OpenOCD and gdb launching from command-line.
 Run the following command:

boards/renesas/rzt2m_starterkit/doc/index.rst

@@ -67,7 +67,7 @@ By default, the board is configured for use with:
 
 * UART0 connected to the USB serial port (pins K18, K19),
 * UART3 connected to the PMOD Header (J25, pins H16, G20),
-* LEDs defined as `led0`, `led1`, `led2` and `led3`,
+* LEDs defined as ``led0``, ``led1``, ``led2`` and ``led3``,
 
 The Zephyr console uses UART0.
 
@@ -78,7 +78,7 @@ Debugging
 =========
 
 Connect to the board using the J-Link On-board USB connector.
-Use `west` to start the debug server:
+Use ``west`` to start the debug server:
 
 .. code-block:: console
 

boards/seeed/xiao_ble/doc/index.rst

@@ -92,9 +92,9 @@ UF2 Flashing
 
 To enter the bootloader, connect the USB port of the XIAO BLE to your host, and
 double tap the reset botton to the left of the USB connector. A mass storage
-device named `XIAO BLE` should appear on the host. Using the command line, or
-your file manager copy the `zephyr/zephyr.uf2` file from your build to the base
-of the `XIAO BLE` mass storage device. The XIAO BLE will automatically reset
+device named ``XIAO BLE`` should appear on the host. Using the command line, or
+your file manager copy the :file:`zephyr/zephyr.uf2` file from your build to the base
+of the ``XIAO BLE`` mass storage device. The XIAO BLE will automatically reset
 and launch the newly flashed application.
 
 External Debugger

boards/seeed/xiao_esp32c3/doc/index.rst

@@ -172,7 +172,7 @@ For the :code:`Hello, world!` application, follow the instructions below.
    :board: xiao_esp32c3
    :goals: build flash
 
-Since the Zephyr console is by default on the `usb_serial` device, we use
+Since the Zephyr console is by default on the ``usb_serial`` device, we use
 the espressif monitor to view.
 
 .. code-block:: console

boards/shields/mikroe_mcp2518fd_click/doc/index.rst

@@ -16,7 +16,7 @@ Requirements
 ************
 
 The shield uses a mikroBUS interface. The target board must define
-a `mikrobus_spi` and `mikrobus_header`  node labels
+a ``mikrobus_spi`` and ``mikrobus_header``  node labels
 (see :ref:`shields` for more details). The target board must also
 support level triggered interrupts.
 

boards/shields/rpi_pico_uno_flexypin/doc/index.rst

@@ -6,12 +6,13 @@ RaspberryPi Pico to UNO FlexyPin Adapter
 Overview
 ********
 
-Raspberry Pi Pico to Uno `FlexyPin Adapter` is a converter-PCB to Arduino UNO form-factor
-from Raspberry Pi Pico that is released in Open Source Hardware.
-This board design to use with `FlexyPin`.
+The Raspberry Pi Pico to Uno FlexyPin Adapter is an open-source hardware converter PCB that adapts
+the Raspberry Pi Pico to the Arduino UNO form factor
+This board is designed to be use with FlexyPin connector pins.
 The FlexyPin holds Pico and contacts to castellated through-hole.
-With simple soldering, it can also be used as a board to convert the RapsberryPi Pico
-o the Arduino UNO form factor.
+
+With simple soldering, it can also be used as a board to convert the Rapsberry Pi Pico
+to the Arduino UNO form factor.
 
 .. image:: img/rpi_pico_uno_flexypin.png
      :align: center

boards/silabs/dev_kits/sltb010a/doc/index.rst

@@ -149,7 +149,7 @@ BRD4184B:
    :goals: flash
 
 .. note::
-   `west flash` requires `SEGGER J-Link software`_ to be installed on you host
+   ``west flash`` requires `SEGGER J-Link software`_ to be installed on you host
    computer.
 
 Open a serial terminal (minicom, putty, etc.) with the following settings:

boards/silabs/dev_kits/xg27_dk2602a/doc/index.rst

@@ -82,14 +82,14 @@ The simplest way to flash the board is by using West, which runs Simplicity
 Commander in unattended mode and passes all the necessary arguments to it.
 
 - If Simplicity Commander is installed in the system and the directory in
-  which `commander` executable is located is present in the `PATH` environment
+  which ``commander`` executable is located is present in the :envvar:`PATH` environment
   variable:
 
   .. code-block:: console
 
    west flash
 
-- Otherwise, one should specify full path to the `commander` executable:
+- Otherwise, one should specify full path to the ``commander`` executable:
 
   .. code-block:: console
 
@@ -114,7 +114,7 @@ Build the Zephyr kernel and application:
    :goals: build
 
 Connect your device to your host computer using the USB port and you
-should see a USB connection. Use `west`'s flash command
+should see a USB connection. Use ``west``'s flash command
 
 Open a serial terminal (minicom, putty, etc.) with the following settings:
 

boards/sparkfun/micromod/doc/index.rst

@@ -139,7 +139,7 @@ applications as usual (see :ref:`build_an_application` and
 :ref:`application_run` for more details).
 
 The flashing tool will depend on the carrier used along with the board.
-In the case of `Sparkfun asset tracking carrier`, it is possible to use
+In the case of `Sparkfun asset tracking carrier`_, it is possible to use
 the SWD interface along with a J-Link.
 
 Here is an example for the :ref:`hello_world` application.
@@ -199,6 +199,7 @@ References
 .. target-notes::
 
 .. _Micromod specification website: https://www.sparkfun.com/micromod
+.. _Sparkfun asset tracking carrier: https://www.sparkfun.com/products/17272
 .. _Micromod nRF52840 guide: https://learn.sparkfun.com/tutorials/micromod-nrf52840-processor-hookup-guide
 .. _J-Link Software and documentation pack: https://www.segger.com/jlink-software.html
 .. _nRF52840 Product Specification: http://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.0.pdf

boards/sparkfun/pro_micro_rp2040/doc/index.rst

@@ -119,8 +119,8 @@ The Pro Micro board does make the SWD pins available on pads on the
 underside of the board. You can solder to these pins, and use a JTag
 debugger. You can also flash the SparkFun ProMicro RP2040 with a UF2 file.
 By default, building an app for this board will generate a
-`build/zephyr/zephyr.uf2` file. If the Pro Micro RP2040 is powered on with
-the `BOOTSEL` button pressed, it will appear on the host as a mass storage
+:file:`build/zephyr/zephyr.uf2` file. If the Pro Micro RP2040 is powered on with
+the ``BOOTSEL`` button pressed, it will appear on the host as a mass storage
 device. The UF2 file should be copied to the device, which will
 flash the Pro Micro RP2040.
 

boards/sparkfun/thing_plus/doc/index.rst

@@ -92,7 +92,7 @@ In most cases you'll want to use the ``ns`` target with any of the Zephyr
 or Nordic based examples.
 
 Some of the examples do not use secure mode, so they do not required the ``ns`` suffix.
-A great example of this is the `hello_world` below.
+A great example of this is the :ref:`hello_world` below.
 
 Flashing
 ========

boards/st/b_u585i_iot02a/doc/index.rst

@@ -220,7 +220,7 @@ The BOARD options are summarized below:
 +-------------------------------+-------------------------------------------+
 
 Here are the instructions to build Zephyr with a non-secure configuration,
-using `tfm_ipc_` sample:
+using :ref:`tfm_ipc` sample:
 
    .. code-block:: bash
 
@@ -236,7 +236,7 @@ option bit TZEN will be set).
       $ west flash
 
 Please note that, after having run a TFM sample on the board, you will need to
-run `./build/tfm/api_ns/regression.sh` once more to clean up the board from secure
+run ``./build/tfm/api_ns/regression.sh`` once more to clean up the board from secure
 options and get back the platform back to a "normal" state and be able to run
 usual, non-TFM, binaries.
 Also note that, even then, TZEN will remain set, and you will need to use

boards/st/nucleo_l552ze_q/doc/nucleol552ze_q.rst

@@ -197,9 +197,9 @@ The BOARD options are summarized below:
 +--------------------------------+-------------------------------------------+
 
 Here are the instructions to build Zephyr with a non-secure configuration,
-using `tfm_ipc_` sample:
+using :ref:`tfm_ipc` sample:
 
-   .. code-block:: bash
+   .. code-block:: console
 
       $ west build -b nucleo_l552ze_q/stm32l552xx/ns samples/tfm_integration/tfm_ipc/
 
@@ -213,7 +213,7 @@ option bit TZEN will be set).
       $ west flash
 
 Please note that, after having run a TFM sample on the board, you will need to
-run `./build/tfm/api_ns/regression.sh` once more to clean up the board from secure
+run ``./build/tfm/api_ns/regression.sh`` once more to clean up the board from secure
 options and get back the platform back to a "normal" state and be able to run
 usual, non-TFM, binaries.
 Also note that, even then, TZEN will remain set, and you will need to use

boards/st/stm32l562e_dk/doc/index.rst

@@ -223,7 +223,7 @@ The BOARD options are summarized below:
 +------------------------------+-------------------------------------------+
 
 Here are the instructions to build Zephyr with a non-secure configuration,
-using `tfm_ipc_` sample:
+using :ref:`tfm_ipc` sample:
 
    .. code-block:: bash
 
@@ -239,7 +239,7 @@ option bit TZEN will be set).
       $ west flash
 
 Please note that, after having run a TFM sample on the board, you will need to
-run `./build/tfm/api_ns/regression.sh` once more to clean up the board from secure
+run ``./build/tfm/api_ns/regression.sh`` once more to clean up the board from secure
 options and get back the platform back to a "normal" state and be able to run
 usual, non-TFM, binaries.
 Also note that, even then, TZEN will remain set, and you will need to use

boards/st/stm32wb5mm_dk/doc/stm32wb5mm_dk.rst

@@ -142,8 +142,8 @@ For compatibility information with the various versions of these binaries,
 please check `modules/hal/stm32/lib/stm32wb/hci/README`_
 in the ``hal_stm32`` repo.
 
-Note that since STM32WB Cube package V1.13.2, `"full stack"` binaries are not
-compatible anymore for a use in Zephyr and only `"HCI Only"` versions should be
+Note that since STM32WB Cube package V1.13.2, "full stack" binaries are not
+compatible anymore for a use in Zephyr and only "HCI Only" versions should be
 used on the M0 side.
 
 Connections and IOs

boards/st/stm32wb5mmg/doc/stm32wb5mmg.rst

@@ -248,8 +248,8 @@ the ``--runner`` (or ``-r``) option:
 
    $ west flash --runner openocd
 
-Flashing `hci_uart` application to STM32WB5MMG
-----------------------------------------------
+Flashing ``hci_uart`` application to STM32WB5MMG
+------------------------------------------------
 
 Connect the B-U585I-IOT02A to your host computer using the USB port. Put
 the SW4 (MCU SWD) in OFF mode and SW5 (SWD BLE) in ON mode. Then build

boards/telink/tlsr9518adk80d/doc/index.rst

@@ -235,7 +235,7 @@ It is also possible to use the west flash command, but additional steps are requ
 Debugging
 =========
 
-This port supports UART debug and OpenOCD+GDB. The `west debug` command also supported. You may run
+This port supports UART debug and OpenOCD+GDB. The ``west debug`` command also supported. You may run
 it in a simple way, like:
 
 .. code-block:: console

boards/ti/sk_am62/doc/index.rst

@@ -94,16 +94,18 @@ The board can using remoteproc, and uses the OpenAMP resource table to accomplis
 
 The testing requires the binary to be copied to the SD card to allow the A53 cores to load it while booting using remoteproc.
 
-To test the M4F core, we build the `hello_world` sample with the following command.
+To test the M4F core, we build the :ref:`hello_world` sample with the following command.
 
 .. code-block:: console
 
    # From the root of the Zephyr repository
    west build -p -b sk_am62/am6234/m4 samples/hello_world
 
-This builds the program and the binary is present in the `build/zephyr` directory as `zephyr.elf`.
+This builds the program and the binary is present in the :file:`build/zephyr` directory as
+:file:`zephyr.elf`.
 
-We now copy this binary onto the SD card in the `/lib/firmware` directory and name it as `am62-mcu-m4f0_0-fw`.
+We now copy this binary onto the SD card in the :file:`/lib/firmware` directory and name it as
+:file:`am62-mcu-m4f0_0-fw`.
 
 .. code-block:: console
 
@@ -122,7 +124,7 @@ The binary will run and print Hello world to the MCU_UART0 port.
 Debugging
 *********
 
-The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the `debug` build target:
+The board is equipped with an XDS110 JTAG debugger. To debug a binary, utilize the ``debug`` build target:
 
 .. zephyr-app-commands::
    :app: <my_app>

boards/wiznet/w5500_evb_pico/doc/index.rst

@@ -165,7 +165,7 @@ Create a file in /etc/udev.rules.d with any name, and write the line below.
 
    ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="660", GROUP="plugdev", TAG+="uaccess"
 
-This example is valid for the case that the user joins to `plugdev` groups.
+This example is valid for the case that the user joins to ``plugdev`` groups.
 
 The Raspberry Pi Pico, and thus the W55500 Evaluation Board, has an SWD
 interface that can be used to program and debug the on board RP2040. This
@@ -189,26 +189,26 @@ application.
    :goals: build flash
    :gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=picoprobe
 
-Set the environment variables **OPENOCD** to `/usr/local/bin/openocd` and
-**OPENOCD_DEFAULT_PATH** to `/usr/local/share/openocd/scripts`. This should
+Set the environment variables **OPENOCD** to :file:`/usr/local/bin/openocd` and
+**OPENOCD_DEFAULT_PATH** to :file:`/usr/local/share/openocd/scripts`. This should
 work with the OpenOCD that was installed with the default configuration. This
 configuration also works with an environment that is set up by the
 `pico_setup.sh`_ script.
 
 **RPI_PICO_DEBUG_ADAPTER** specifies what debug adapter is used for debugging.
 
-If **RPI_PICO_DEBUG_ADAPTER** was not assigned, `picoprobe` is used by default.
-The other supported adapters are `raspberrypi-swd`, `jlink` and
-`blackmagicprobe`. How to connect `picoprobe` and `raspberrypi-swd` is
+If **RPI_PICO_DEBUG_ADAPTER** was not assigned, ``picoprobe`` is used by default.
+The other supported adapters are ``raspberrypi-swd``, ``jlink`` and
+``blackmagicprobe``. How to connect ``picoprobe`` and ``raspberrypi-swd`` is
 described in `Getting Started with Raspberry Pi Pico`_. Any other SWD debug
 adapter maybe also work with this configuration.
 
 The value of **RPI_PICO_DEBUG_ADAPTER** is cached, so it can be omitted from
-`west flash` and `west debug` if it was previously set while running
-`west build`.
+``west flash`` and ``west debug`` if it was previously set while running
+``west build``.
 
 **RPI_PICO_DEBUG_ADAPTER** is used in an argument to OpenOCD as
-`"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"`. Thus,
+``"source [find interface/${RPI_PICO_DEBUG_ADAPTER}.cfg]"``. Thus,
 **RPI_PICO_DEBUG_ADAPTER** needs to be assigned the file name of the debug
 adapter.
 
@@ -224,7 +224,7 @@ Using UF2
 
 If you don't have an SWD adapter, you can flash the Raspberry Pi Pico with
 a UF2 file. By default, building an app for this board will generate a
-`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the `BOOTSEL`
+:file:`build/zephyr/zephyr.uf2` file. If the Pico is powered on with the ``BOOTSEL``
 button pressed, it will appear on the host as a mass storage device. The
 UF2 file should be drag-and-dropped to the device, which will flash the Pico.
 
@@ -256,8 +256,8 @@ Here is an example for debugging the :zephyr:code-sample:`blinky` application.
    :gen-args: -DOPENOCD=/usr/local/bin/openocd -DOPENOCD_DEFAULT_PATH=/usr/local/share/openocd/scripts -DRPI_PICO_DEBUG_ADAPTER=raspberrypi-swd
 
 As with flashing, you can specify the debug adapter by specifying
-**RPI_PICO_DEBUG_ADAPTER** at `west build` time. No needs to specify it at
-`west debug` time.
+**RPI_PICO_DEBUG_ADAPTER** at ``west build`` time. No needs to specify it at
+``west debug`` time.
 
 You can also debug with OpenOCD and gdb launching from command-line.
 Run the following command:

doc/connectivity/bluetooth/api/audio/bluetooth-le-audio-arch.rst

@@ -22,14 +22,14 @@ The overall design of the LE Audio stack is that the implementation follows the
 as closely as possible,
 both in terms of structure but also naming.
 Most API functions are prefixed by the specification acronym
-(e.g. `bt_bap` for the Basic Audio Profile (BAP) and `bt_vcp` for the Volume Control Profile (VCP)).
-The functions are then further prefixed with the specific role from each profile where applicable
-(e.g. :c:func:`bt_bap_unicast_client_discover` and :c:func:`bt_vcp_vol_rend_set_vol`).
+(e.g. ``bt_bap`` for the Basic Audio Profile (BAP) and ``bt_vcp`` for the Volume Control Profile
+(VCP)). The functions are then further prefixed with the specific role from each profile where
+applicable (e.g. :c:func:`bt_bap_unicast_client_discover` and :c:func:`bt_vcp_vol_rend_set_vol`).
 There are usually a function per procedure defined by the profile or service specifications,
 and additional helper or meta functions that do not correspond to procedures.
 
 The structure of the files generally also follow this,
-where BAP related files are prefixed with `bap` and VCP related files are prefixed with `vcp`.
+where BAP related files are prefixed with ``bap`` and VCP related files are prefixed with ``vcp``.
 If the file is specific for a profile role, the role is also embedded in the file name.
 
 Generic Audio Framework (GAF)
@@ -1065,8 +1065,8 @@ but the GTBS instance will report 2 calls,
 making it possible for a simple Call Control Client to control all calls from a single bearer.
 Similarly the supported URIs for each bearer are also made into a union in GTBS, and when placing
 a call using the GTBS the server will pick the most suited bearer depending on the URI.
-For example calls with URI `tel` would go to the regular phone application,
-and calls with the URI `skype` would go to the Teams application.
+For example calls with URI ``tel`` would go to the regular phone application,
+and calls with the URI ``skype`` would go to the Teams application.
 
 In conclusion the GTBS implementation in Zephyr is a union of the non-generic telephone bearers.
 
@@ -1175,8 +1175,8 @@ the data is kept in and controlled by the application.
 
 As a rule of thumb, the return types of the callbacks for each profile implementation indicate
 whether the data is controlled by the stack or the application.
-For example all the callbacks for the VCP Volume Renderer have the return type of `void`,
-but the return type of the BAP Unicast Server callbacks are `int`,
+For example all the callbacks for the VCP Volume Renderer have the return type of ``void``,
+but the return type of the BAP Unicast Server callbacks are ``int``,
 indicating that the application not only controls a lot of the Unicast Server data,
 but can also reject the requests.
 The choice of what the return type of the callbacks often depend on the specifications,
@@ -1202,7 +1202,7 @@ In Zephyr we do not force the device to always use these, as a device that uses
 use other profiles and services that do not require such security.
 We guard all access to services using a custom security check implemented in
 :zephyr_file:`subsys/bluetooth/audio/audio.c`, where all LE Audio services must use the
-internal `BT_AUDIO_CHRC` macro for proper security verification.
+internal :c:macro:`BT_AUDIO_CHRC` macro for proper security verification.
 
 Access to the LTK for encrypted SIRKs in CSIS
 ---------------------------------------------
@@ -1235,10 +1235,10 @@ The LE audio channel on Discord
 
 Zephyr has a specific Discord channel for LE Audio development, which is open to all.
 Find it here at https://discordapp.com/channels/720317445772017664/1207326649591271434 or simply
-search for `ble-audio` from within Discord.
-Since the `ble-audio` channel is open for all,
+search for "ble-audio" from within Discord.
+Since the ``#ble-audio`` channel is open for all,
 we cannot discuss any specifications that are in development in that channel.
-For discussions that require a Bluetooth SIG membership we refer to the `bluetooth-sig`
+For discussions that require a Bluetooth SIG membership we refer to the ``#bluetooth-sig``
 Discord channel found at https://discordapp.com/channels/720317445772017664/869172014018097162.
 
 Zephyr weekly meetings

doc/connectivity/bluetooth/bluetooth-shell.rst

@@ -218,7 +218,7 @@ Extended Advertising
 ====================
 
 Let's now have a look at some extended advertising features. To enable extended advertising, use the
-`ext-adv` parameter.
+``ext-adv`` parameter.
 
 .. code-block:: console
 

doc/connectivity/networking/api/coap_client.rst

@@ -52,10 +52,10 @@ The callback provided in the callback will be called in following cases:
 - There is a response for the request
 - The request failed for some reason
 
-The callback contains a flag `last_block`, which indicates if there is more data to come in the
-response and means that the current response is part of a blockwise transfer. When the `last_block`
-is set to true, the response is finished and the client is ready for the next request after
-returning from the callback.
+The callback contains a flag ``last_block``, which indicates if there is more data to come in the
+response and means that the current response is part of a blockwise transfer. When the
+``last_block`` is set to true, the response is finished and the client is ready for the next request
+after returning from the callback.
 
 If the server responds to the request, the library provides the response to the
 application through the response callback registered in the request structure.

doc/connectivity/networking/api/tls_credentials_shell.rst

@@ -206,7 +206,7 @@ After the list is printed, a final summary of the found credentials will be prin
 
    <N> credentials found.
 
-Where `<N>` is the number of credentials found, and is zero if none are found.
+Where ``<N>`` is the number of credentials found, and is zero if none are found.
 
 .. _tls_credentials_shell_cred_types:
 

doc/connectivity/networking/api/wifi.rst

@@ -18,7 +18,8 @@ Only personal mode security is supported with below types:
 * WPA3-PSK-256
 * WPA3-SAE
 
-The Wi-Fi management API is implemented in the `wifi_mgmt` module as a part of the networking L2 stack.
+The Wi-Fi management API is implemented in the ``wifi_mgmt`` module as a part of the networking L2
+stack.
 Currently, two types of Wi-Fi drivers are supported:
 
 * Networking or socket offloaded drivers
@@ -29,7 +30,7 @@ Wi-Fi Enterprise test: X.509 Certificate header generation
 
 Wi-Fi enterprise security requires use of X.509 certificates, test certificates
 in PEM format are committed to the repo at :zephyr_file:`samples/net/wifi/test_certs` and the during the
-build process the certificates are converted to a `C` header file that is included by the Wi-Fi shell
+build process the certificates are converted to a C header file that is included by the Wi-Fi shell
 module.
 
 .. code-block:: bash
@@ -46,16 +47,16 @@ To initiate Wi-Fi connection, the following command can be used:
     uart:~$ wifi connect -s <SSID> -k 5 -a anon -K whatever
 
 Server certificate is also provided in the same directory for testing purposes.
-Any `AAA` server can be used for testing purposes, for example, `FreeRADIUS` or `hostapd`.
+Any AAA server can be used for testing purposes, for example, ``FreeRADIUS`` or ``hostapd``.
 
 .. important::
 
-    The passphrase for the client-key.pem and the server-key.pem is `whatever`.
+    The passphrase for the :file:`client-key.pem`` and the :file:`server-key.pem` is ``whatever``.
 
 .. note::
 
     The certificates are for testing purposes only and should not be used in production.
-    The certificates are generated using `FreeRADIUS raddb <https://github.com/FreeRADIUS/freeradius-server/tree/master/raddb/certs> _` scripts.
+    They are generated using `FreeRADIUS raddb <https://github.com/FreeRADIUS/freeradius-server/tree/master/raddb/certs>`_ scripts.
 
 API Reference
 *************

doc/connectivity/usb/device_next/usb_device.rst

@@ -30,7 +30,7 @@ The USB device stack has built-in USB functions. Some can be used directly in
 the user application through a special API, such as HID or Audio class devices,
 while others use a general Zephyr RTOS driver API, such as MSC and CDC class
 implementations. The *Identification string* identifies a class or function
-instance (`n`) and is used as an argument to the :c:func:`usbd_register_class`.
+instance (``n``) and is used as an argument to the :c:func:`usbd_register_class`.
 
 +-----------------------------------+-------------------------+-------------------------+
 | Class or function                 | User API (if any)       | Identification string   |

doc/contribute/index.rst

@@ -27,7 +27,7 @@ General Guidelines
    merged.
 
 :ref:`contributor-expectations`
-   This document is another mandatory read that describes the expected behavior of `all`
+   This document is another mandatory read that describes the expected behavior of *all*
    contributors to the project.
 
 :ref:`coding_guidelines`

doc/develop/debug/index.rst

@@ -291,7 +291,7 @@ Debugging I2C communication
 
 There is a possibility to log all or some of the I2C transactions done by the application.
 This feature is enabled by the Kconfig option :kconfig:option:`CONFIG_I2C_DUMP_MESSAGES`, but it
-uses the ``LOG_DBG`` function to print the contents so the
+uses the :c:macro:`LOG_DBG` function to print the contents so the
 :kconfig:option:`CONFIG_I2C_LOG_LEVEL_DBG` option must also be enabled.
 
 The sample output of the dump looks like this::

doc/develop/manifest/index.rst

@@ -12,7 +12,7 @@ Active Projects/Modules
 +++++++++++++++++++++++
 
 The projects below are enabled by default and will be downloaded when you
-call `west update`. Many of the projects or modules listed below are
+call :command:`west update`. Many of the projects or modules listed below are
 essential for building generic Zephyr application and include among others
 hardware support for many of the platforms available in Zephyr.
 
@@ -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 projects or modules listed below
+call :command:`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.
 

doc/develop/modules.rst

@@ -52,7 +52,7 @@ In summary:
 
 Modules are repositories that contain a :file:`zephyr/module.yml` file, so that
 the Zephyr build system can pull in the source code from the repository.
-:ref:`West projects <west-manifests-projects>` are entries in the `projects:`
+:ref:`West projects <west-manifests-projects>` are entries in the ``projects:``
 section in the :file:`west.yml` manifest file.
 West projects are often also modules, but not always. There are west projects
 that are not included in the final firmware image (eg. tools) and thus do not
@@ -545,7 +545,7 @@ The ``sysbuild-cmake: <cmake-directory>`` part specifies that
 use.
 
 Here is an example :file:`module.yml` file referring to
-:file:`CMakeLists.txt` and :file:`Kconfig` files in the `sysbuild` directory of
+:file:`CMakeLists.txt` and :file:`Kconfig` files in the ``sysbuild`` directory of
 the module:
 
 .. code-block:: yaml
@@ -592,7 +592,7 @@ be monitored for your module. The supported formats are:
        - <an-other-module-related-cpe>
        - <module-related-purl>
 
-A real life example for `mbedTLS` module could look like this:
+A real life example for ``mbedTLS`` module could look like this:
 
 .. code-block:: yaml
 

doc/develop/test/pytest.rst

@@ -14,7 +14,7 @@ Pytest is a python framework that *“makes it easy to write small, readable tes
 support complex functional testing for applications and libraries”* (`<https://docs.pytest.org/en/7.3.x/>`_).
 Python is known for its free libraries and ease of using it for scripting. In addition, pytest
 utilizes the concept of plugins and fixtures, increasing its expendability and reusability.
-A pytest plugin `pytest-twister-harness` was introduced to provide an integration between pytest
+A pytest plugin ``pytest-twister-harness`` was introduced to provide an integration between pytest
 and twister, allowing Zephyr’s community to utilize pytest functionality with keeping twister as
 the main framework.
 

doc/develop/test/twister.rst

@@ -261,11 +261,11 @@ test application and has to follow basic rules:
    two sections:
 
    * Ztest tests: The individual test cases in the ztest testsuite will be
-     concatenated by dot (`.`) to the identifier in the ``testcase.yaml`` file
+     concatenated by dot (``.``) to the identifier in the ``testcase.yaml`` file
      generating unique identifiers for every test case in the suite.
 
    * Standalone tests and samples: This type of test should at least have 3
-     sections concatnated by dot (`.`) in the test scenario identifier in the
+     sections concatnated by dot (``.``) in the test scenario identifier in the
      ``testcase.yaml`` (or ``sample.yaml``) file.
      The last section of the name shall signify the test case itself.
 
@@ -851,10 +851,10 @@ Command line arguments define the initial scope in the following way:
 * ``-l/--all``: all available platforms;
 * ``-G/--integration``: all platforms from an ``integration_platforms`` list in
   a given test configuration file. If a test has no ``integration_platforms``
-  `"scope presumption"` will happen;
-* No scope argument: `"scope presumption"` will happen.
+  *"scope presumption"* will happen;
+* No scope argument: *"scope presumption"* will happen.
 
-`"Scope presumption"`: A list of Twister's :ref:`default platforms <twister_default_testing_board>`
+*"Scope presumption"*: A list of Twister's :ref:`default platforms <twister_default_testing_board>`
 is used as the initial list. If nothing is left after the filtration, the ``platform_allow`` list
 is used as the initial scope.
 
@@ -1338,7 +1338,7 @@ 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_on_all` options used in some test scenarios.
+- Ability to override ``build_on_all`` options used in some test scenarios.
   This will treat tests or sample as any other just build for default
   platforms you specify in the configuration file or on the command line.
 - Ignore some logic in twister to expand platform coverage in cases where
@@ -1350,16 +1350,16 @@ Platform Configuration
 
 The following options control platform filtering in twister:
 
-- `override_default_platforms`: override default key a platform sets in board
+- ``override_default_platforms``: override default key a platform sets in board
   configuration and instead use the list of platforms provided in the
   configuration file as the list of default platforms. This option is set to
   False by default.
-- `increased_platform_scope`: This option is set to True by default, when
+- ``increased_platform_scope``: This option is set to True by default, when
   disabled, twister will not increase platform coverage automatically and will
   only build and run tests on the specified platforms.
-- `default_platforms`: A list of additional default platforms to add. This list
+- ``default_platforms``: A list of additional default platforms to add. This list
   can either be used to replace the existing default platforms or can extend it
-  depending on the value of `override_default_platforms`.
+  depending on the value of ``override_default_platforms``.
 
 And example platforms configuration:
 

doc/develop/test/ztest.rst

@@ -600,7 +600,7 @@ By default the tests are sorted and ran in alphanumerical order.  Test cases may
 be dependent on this sequence. Enable :kconfig:option:`CONFIG_ZTEST_SHUFFLE` to
 randomize the order. The output from the test will display the seed for failed
 tests.  For native simulator builds you can provide the seed as an argument to
-twister with `--seed`
+twister with ``--seed``.
 
 Static configuration of ZTEST_SHUFFLE contains:
 

doc/develop/tools/vscode.rst

@@ -17,7 +17,7 @@ Get VS Code
 
 `Download VS Code`_ and install it.
 
-Install the required extensions through the `Extensions` marketplace in the left panel.
+Install the required extensions through the :guilabel:`Extensions` marketplace in the left panel.
 Search for the `C/C++ Extension Pack`_ and install it.
 
 Initialize a new workspace

doc/develop/west/sign.rst

@@ -116,7 +116,7 @@ for all images, for example:
    west build -b <board> <application> -DSIGNING_SCRIPT=<file>
 
 The zephyr property method is achieved by adjusting the ``SIGNING_SCRIPT`` property
-on the `zephyr_property_target`, ideally from by a module by using:
+on the ``zephyr_property_target``, ideally from by a module by using:
 
 .. code-block:: cmake
 

doc/glossary.rst

@@ -60,7 +60,7 @@ Glossary of Terms
       See :ref:`board_terminology` for additional details.
 
    board qualifiers
-      The set of additional tokens, separated by a forward slash (`/`) that
+      The set of additional tokens, separated by a forward slash (``/``) that
       follow the :term:`board name` (and optionally :term:`board revision`) to
       form the :term:`board target`. The currently accepted qualifiers are
       :term:`SoC`, :term:`CPU cluster` and :term:`variant`.

doc/hardware/arch/risc-v.rst

@@ -23,7 +23,7 @@ ISA extensions
 **************
 
 It's possible to set in Zephyr which ISA extensions (RV32/64I(E)MAFD(G)QC)
-are available on a given platform, by setting the appropriate `RISCV_ISA_*`
+are available on a given platform, by setting the appropriate ``CONFIG_RISCV_ISA_*``
 kconfig. Look at :file:`arch/riscv/Kconfig.isa` for more information.
 
 Note that Zephyr SDK toolchain support may not be defined for all
@@ -33,5 +33,5 @@ SMP support
 ***********
 
 SMP is supported on RISC-V, but currently only on Qemu platforms. In
-order to test the SMP support, one can use `qemu_riscv32_smp` or
-`qemu_riscv64_smp` boards.
+order to test the SMP support, one can use ``qemu_riscv32_smp`` or
+``qemu_riscv64_smp`` boards.

doc/hardware/emulator/bus_emulators.rst

@@ -73,7 +73,7 @@ an emulator instance using one of the :c:func:`EMUL_DT_DEFINE()` or
 :c:func:`EMUL_DT_INST_DEFINE()` APIs.
 
 Emulators for peripheral devices reuse the same devicetree node as the real
-device driver. This means that your emulator defines `DT_DRV_COMPAT` using the
+device driver. This means that your emulator defines ``DT_DRV_COMPAT`` using the
 same ``compat`` value from the real driver.
 
 .. code-block:: C

doc/hardware/peripherals/uart.rst

@@ -14,9 +14,9 @@ on the method, different API functions are used according to below sections:
 3. :ref:`uart_async_api` using :ref:`dma_api`
 
 Polling is the most basic method to access the UART peripheral. The reading
-function, `uart_poll_in`, is a non-blocking function and returns a character
-or `-1` when no valid data is available. The writing function,
-`uart_poll_out`, is a blocking function and the thread waits until the given
+function, :c:func:`uart_poll_in`, is a non-blocking function and returns a character
+or ``-1`` when no valid data is available. The writing function,
+:c:func:`uart_poll_out`, is a blocking function and the thread waits until the given
 character is sent.
 
 With the Interrupt-driven API, possibly slow communication can happen in the

doc/kernel/object_cores/index.rst

@@ -13,7 +13,7 @@ perform operations on registered objects.
 Object Core Concepts
 ********************
 
-Each instance of an object embeds an object core field named `obj_core`.
+Each instance of an object embeds an object core field named ``obj_core``.
 Objects of the same type are linked together via their respective object
 cores to form a singly linked list. Each object core also links to the their
 respective object type. Each object type contains a singly linked list

doc/kernel/services/interrupts.rst

@@ -604,8 +604,8 @@ If this configuration is supported by the used architecture and toolchaing the
 :kconfig:option:`ISR_TABLES_LOCAL_DECLARATION_SUPPORTED` is set.
 See details of this option for the information about currently supported configurations.
 
-Any invocation of :c:macro:`IRQ_CONNECT` or `IRQ_DIRECT_CONNECT` will declare an instance of struct
-_isr_list_sname which is placde in a special .intList section:
+Any invocation of :c:macro:`IRQ_CONNECT` or :c:macro:`IRQ_DIRECT_CONNECT` will declare an instance
+of ``struct _isr_list_sname`` which is placed in a special .intList section:
 
 .. code-block:: c
 
@@ -619,7 +619,7 @@ _isr_list_sname which is placde in a special .intList section:
     };
 
 Note that the section name is placed in flexible array member.
-It means that the size of the initialized structure will warry depending on the
+It means that the size of the initialized structure will vary depending on the
 structure name length.
 The whole entry is used by the script during the build of the application
 and has all the information needed for proper interrupt placement.
@@ -720,7 +720,7 @@ aggregator. In this case it may be desirable to override these defaults and use
 number of bits per level. Regardless of how many bits used for each level, the sum of
 the total bits used between all levels must sum to be less than or equal to 32-bits,
 fitting into a single 32-bit integer. To modify the bit total per level, override the
-default 8 in `Kconfig.multilevel` by setting :kconfig:option:`CONFIG_1ST_LEVEL_INTERRUPT_BITS`
+default 8 in :file:`Kconfig.multilevel` by setting :kconfig:option:`CONFIG_1ST_LEVEL_INTERRUPT_BITS`
 for the  first level, :kconfig:option:`CONFIG_2ND_LEVEL_INTERRUPT_BITS` for the second level and
 :kconfig:option:`CONFIG_3RD_LEVEL_INTERRUPT_BITS` for the third level. These masks control the
 length of the bit masks and shift to apply when generating interrupt values, when checking the

doc/project/release_process.rst

@@ -127,7 +127,7 @@ feature freeze milestone. An issue labeled as a blocker practically blocks a
 release from happening. All blocker bugs shall be resolved before a release is
 created.
 
-A fix for a bug that is granted `blocker` status can be merged to 'main' and included in
+A fix for a bug that is granted ``blocker`` status can be merged to 'main' and included in
 the release all the way until the final release date.
 
 Bugs of moderate severity and higher that have impact on all users are typically

doc/releases/index.rst

@@ -73,7 +73,7 @@ Release Notes
 Release notes contain a list of changes that have been made to the different
 areas of the project during the development cycle of the release.
 Changes that require the user to modify their own application to support the new
-release may be mentioned in the release notes, but the details regarding `what`
+release may be mentioned in the release notes, but the details regarding *what*
 needs to be changed are to be detailed in the release's migration guide.
 
 .. toctree::

doc/releases/migration-guide-4.0.rst

@@ -30,14 +30,14 @@ Boards
   to define default flash and ram partitioning based on TF-M.
 
 * STM32WBA: The command used for fetching blobs required to build ble applications is now
-  `west blobs fetch hal_stm32` instead of `west blobs fetch stm32`.
+  ``west blobs fetch hal_stm32`` instead of ``west blobs fetch stm32``.
 
 STM32
 =====
 
-* On all official STM32 boards, `west flash` selects STM32CubeProgrammer as the default west runner.
+* On all official STM32 boards, ``west flash`` selects STM32CubeProgrammer as the default west runner.
   If you want to enforce the selection of another runner like OpenOCD or pyOCD for flashing, you should
-  specify it using the west `--runner` or `-r` option. (:github:`75284`)
+  specify it using the west ``--runner`` or ``-r`` option. (:github:`75284`)
 
 Modules
 *******
@@ -69,10 +69,10 @@ zcbor
   Migration guide at https://github.com/NordicSemiconductor/zcbor/blob/0.9.0/MIGRATION_GUIDE.md
   Migration guide copied here:
 
-  * `zcbor_simple_*()` functions have been removed to avoid confusion about their use.
+  * ``zcbor_simple_*()`` functions have been removed to avoid confusion about their use.
     They are still in the C file because they are used by other functions.
     Instead, use the specific functions for the currently supported simple values, i.e.
-    `zcbor_bool_*()`, `zcbor_nil_*()`, and `zcbor_undefined_*()`.
+    ``zcbor_bool_*()``, ``zcbor_nil_*()``, and ``zcbor_undefined_*()``.
     If a removed variant is strictly needed, add your own forward declaration in your code.
 
   * Code generation naming:

doc/releases/release-notes-4.0.rst

@@ -68,8 +68,8 @@ Architectures
     has an additional field ``csf`` that points to the callee-saved-registers upon an fatal error,
     which can be accessed in :c:func:`k_sys_fatal_error_handler` by ``esf->csf``.
 
-    * For SoCs that select `RISCV_SOC_HAS_ISR_STACKING`, the `SOC_ISR_STACKING_ESF_DECLARE` has to
-      include the `csf` member, otherwise the build would fail.
+    * For SoCs that select ``RISCV_SOC_HAS_ISR_STACKING``, the ``SOC_ISR_STACKING_ESF_DECLARE`` has to
+      include the ``csf`` member, otherwise the build would fail.
 
 * Xtensa
 

doc/security/standards/etsi-303645.rst

@@ -4,7 +4,7 @@ ETSI 303-645
 ############
 
 
-`ETSI EN 303 645`, also known as "Cyber Security for Consumer Internet
+**ETSI EN 303 645**, also known as "Cyber Security for Consumer Internet
 of Things: Baseline Requirements," is a standard developed by the
 European Telecommunications Standards Institute (ETSI).
 

doc/services/device_mgmt/ec_host_cmd.rst

@@ -76,7 +76,7 @@ SoCs, modify the compatible string as shown.
        ...
    };
 
-The chip that runs Zephyr is a SPI slave and the `cs-gpios` property is used to point our CS pin.
+The chip that runs Zephyr is a SPI slave and the ``cs-gpios`` property is used to point our CS pin.
 For the SPI, it is required to set the backend chosen node ``zephyr,host-cmd-spi-backend``.
 
 The supported backend and peripheral drivers:
@@ -120,10 +120,10 @@ Logging
 The host command has an embedded logging system of the ongoing communication. The are a few logging
 levels:
 
-* `LOG_INF` is used to log a command id of a new command and not success responses. Repeats of the
+* :c:macro:`LOG_INF` is used to log a command id of a new command and not success responses. Repeats of the
   same command are not logged
-* `LOG_DBG` logs every command, even repeats
-* `LOG_DBG` + :kconfig:option:`CONFIG_EC_HOST_CMD_LOG_DBG_BUFFERS` logs every command and responses
+* :c:macro:`LOG_DBG` logs every command, even repeats
+* :c:macro:`LOG_DBG` + :kconfig:option:`CONFIG_EC_HOST_CMD_LOG_DBG_BUFFERS` logs every command and responses
   with the data buffers
 
 API Reference

doc/services/device_mgmt/smp_groups/smp_group_0.rst

@@ -546,7 +546,7 @@ the :kconfig:option:`CONFIG_MCUMGR_GRP_OS_RESET_HOOK` is enabled and an
 application registers a callback, the callback will be called when this command
 is issued and can be used to perform any necessary tidy operations prior to the
 module rebooting, or to reject the reset request outright altogether with an
-error response. For details on this functionality, see `ref:`mcumgr_callbacks`.
+error response. For details on this functionality, see :ref:`mcumgr_callbacks`.
 
 System reset request
 ====================

doc/services/device_mgmt/smp_transport.rst

@@ -14,8 +14,8 @@ BLE (Bluetooth Low Energy)
 MCUmgr Clients need to use following BLE Characteristics, when implementing
 SMP client:
 
-- **Service UUID**: `8D53DC1D-1DB7-4CD3-868B-8A527460AA84`
-- **Characteristic UUID**: `DA2E7828-FBCE-4E01-AE9E-261174997C48`
+- **Service UUID**: ``8D53DC1D-1DB7-4CD3-868B-8A527460AA84``
+- **Characteristic UUID**: ``DA2E7828-FBCE-4E01-AE9E-261174997C48``
 
 All SMP communication utilizes a single GATT characteristic.  An SMP request is
 sent via a GATT Write Without Response command. An SMP response is sent in the form

doc/services/input/gpio-kbd.rst

@@ -171,7 +171,7 @@ Actual key mask configuration
 *****************************
 
 If the key matrix is not complete, a map of the keys that are actually
-populated can be specified using the `actual-key-mask` property. This allows
+populated can be specified using the ``actual-key-mask`` property. This allows
 the matrix state to be filtered to remove keys that are not present before
 ghosting detection, potentially allowing key combinations that would otherwise
 be blocked by it.

doc/services/llext/build.rst

@@ -112,18 +112,18 @@ The different build steps are:
 ``PRE_BUILD``
 
     Before the extension code is linked, if the architecture uses dynamic
-    libraries. This step can access `lib_target` and its own properties.
+    libraries. This step can access ``lib_target`` and its own properties.
 
 ``POST_BUILD``
 
     After the extension code is built, but before packaging it in an ``.llext``
-    file. This step is expected to create a `pkg_input` file by reading the
-    contents of `lib_output`.
+    file. This step is expected to create a :file:`pkg_input` file by reading the
+    contents of :file:`lib_output`.
 
 ``POST_PKG``
 
     After the extension output file has been created. The command can operate
-    on the final llext file `pkg_output`.
+    on the final llext file :file:`pkg_output`.
 
 Anything else after ``COMMAND`` will be passed to ``add_custom_command()`` as-is
 (including multiple commands and other options).

doc/services/llext/config.rst

@@ -104,7 +104,7 @@ significant as the number of exported symbols increases.
 
         Perform an extra processing step on the Zephyr binary and on all
         extensions being built, converting every string in the symbol tables to
-        a pointer-sized hash called `Symbol Link Identifier` (SLID), which is
+        a pointer-sized hash called Symbol Link Identifier (SLID), which is
         stored in the binary.
 
         This speeds up the symbol lookup process by allowing usage of

doc/services/logging/index.rst

@@ -500,7 +500,7 @@ backends.
 
 In some cases, logs need to be redirected at the macro level. For these cases,
 :kconfig:option:`CONFIG_LOG_CUSTOM_HEADER` can be used to inject an application provided
-header named `zephyr_custom_log.h` at the end of :zephyr_file:`include/zephyr/logging/log.h`.
+header named :file:`zephyr_custom_log.h` at the end of :zephyr_file:`include/zephyr/logging/log.h`.
 
 Frontend using ARM Coresight STM (System Trace Macrocell)
 ---------------------------------------------------------

doc/services/mem_mgmt/index.rst

@@ -66,8 +66,8 @@ and act on regions and attributes (see next section for more details).
 A test for the ``mem-attr`` library and its usage is provided in
 ``tests/subsys/mem_mgmt/mem_attr/``.
 
-Migration guide from `zephyr,memory-region-mpu`
-***********************************************
+Migration guide from ``zephyr,memory-region-mpu``
+*************************************************
 
 When the ``zephyr,memory-attr`` property was introduced, the
 ``zephyr,memory-region-mpu`` property was removed and deprecated.

doc/services/pm/device_runtime.rst

@@ -32,7 +32,7 @@ in response to :c:func:`pm_device_runtime_get` and :c:func:`pm_device_runtime_pu
 calls on the child device.
 
 For the previous to automatically control the power domain state, device runtime PM must be enabled
-on the power domain device (either through the `zephyr,pm-device-runtime-auto` devicetree property
+on the power domain device (either through the ``zephyr,pm-device-runtime-auto`` devicetree property
 or :c:func:`pm_device_runtime_enable`).
 
 .. graphviz::

doc/services/portability/posix/conformance/index.rst

@@ -3,7 +3,9 @@
 POSIX Conformance
 #################
 
-As per `IEEE 1003.1-2017`, this section details Zephyr's POSIX conformance.
+As per `IEEE 1003.1-2017`_, this section details Zephyr's POSIX conformance.
+
+.. _IEEE 1003.1-2017: https://standards.ieee.org/ieee/1003.1/7101/
 
 .. _posix_system_interfaces:
 

doc/services/storage/flash_map/flash_map.rst

@@ -32,7 +32,7 @@ Most ``<zephyr/storage/flash_map.h>`` API functions require a :c:struct:`flash_a
 characterizing the flash area they will be working on. There are two possible
 methods to obtain such a pointer:
 
- * obtain it using `flash_area_open`;
+ * obtain it using :c:func:`flash_area_open`;
 
  * defining a :c:struct:`flash_area` type object, which requires providing
    a valid :c:struct:`device` object pointer with offset and size of the area

doc/services/tracing/index.rst

@@ -365,7 +365,7 @@ To enable tracing support with `SEGGER SystemView`_ add the configuration option
 it to *y*. For example, this can be added to the
 :zephyr:code-sample:`synchronization` sample to visualize fast switching between threads.
 SystemView can also be used for post-mortem tracing, which can be enabled with
-`CONFIG_SEGGER_SYSVIEW_POST_MORTEM_MODE`. In this mode, a debugger can
+:kconfig:option:`CONFIG_SEGGER_SYSVIEW_POST_MORTEM_MODE`. In this mode, a debugger can
 be attached after the system has crashed using ``west attach`` after which the
 latest data from the internal RAM buffer can be loaded into SystemView::
 

doc/services/zbus/index.rst

@@ -380,7 +380,8 @@ Limitations
 Based on the fact that developers can use zbus to solve many different problems, some challenges
 arise. ZBus will not solve every problem, so it is necessary to analyze the situation to be sure
 zbus is applicable. For instance, based on the zbus benchmark, it would not be well suited to a
-high-speed stream of bytes between threads. The `Pipe` kernel object solves this kind of need.
+high-speed stream of bytes between threads. The :ref:`Pipe <pipes_v2>` kernel object solves this
+kind of need.
 
 Delivery guarantees
 -------------------
@@ -524,12 +525,12 @@ sequence of the static observers.
    notified.
 
 
-Channels can have a `validator function` that enables a channel to accept only valid messages.
+Channels can have a *validator function* that enables a channel to accept only valid messages.
 Publish attempts invalidated by hard channels will return immediately with an error code. This
 allows original creators of a channel to exert some authority over other developers/publishers who
 may want to piggy-back on their channels. The following code defines and initializes a :dfn:`hard
 channel` and its dependencies. Only valid messages can be published to a :dfn:`hard channel`. It is
-possible because a `validator function` was passed to the channel's definition. In this example,
+possible because a *validator function* was passed to the channel's definition. In this example,
 only messages with ``move`` equal to 0, -1, and 1 are valid. Publish function will discard all other
 values to ``move``.
 

samples/bluetooth/bap_broadcast_sink/README.rst

@@ -16,9 +16,9 @@ This sample can be found under
 
 Check the :ref:`bluetooth samples section <bluetooth-samples>` for general information.
 
-Use `CONFIG_TARGET_BROADCAST_NAME` Kconfig to specify the name (CONFIG_BT_DEVICE_NAME)
-of a broadcast source to listen to. With default value (empty string), sink
-device will listen to all available broadcast sources.
+Use :kconfig:option:`CONFIG_TARGET_BROADCAST_NAME` Kconfig to specify the name
+(:kconfig:option:`CONFIG_BT_DEVICE_NAME`) of a broadcast source to listen to. With default value
+(empty string), sink device will listen to all available broadcast sources.
 
 Requirements
 ************
@@ -30,7 +30,7 @@ Building and Running
 ********************
 
 When building targeting an nrf52 series board with the Zephyr Bluetooth Controller,
-use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO
+use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO
 feature support.
 
 Building for an nrf5340dk
@@ -67,7 +67,7 @@ Similarly to how you would for real HW, you can do:
    :goals: build
    :west-args: --sysbuild
 
-Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
+Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
 For more information, check :ref:`this board documentation <nrf5340bsim>`.
 
 Building for a simulated nrf52_bsim

samples/bluetooth/bap_broadcast_source/README.rst

@@ -29,7 +29,7 @@ Building and Running
 ********************
 
 When building targeting an nrf52 series board with the Zephyr Bluetooth Controller,
-use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO
+use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO
 feature support.
 
 Building for an nrf5340dk
@@ -66,7 +66,7 @@ Similarly to how you would for real HW, you can do:
    :goals: build
    :west-args: --sysbuild
 
-Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
+Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
 For more information, check :ref:`this board documentation <nrf5340bsim>`.
 
 Building for a simulated nrf52_bsim

samples/bluetooth/bap_unicast_client/README.rst

@@ -25,7 +25,7 @@ Building and Running
 ********************
 
 When building targeting an nrf52 series board with the Zephyr Bluetooth Controller,
-use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO
+use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO
 feature support.
 
 Building for an nrf52840dk
@@ -71,7 +71,7 @@ Similarly to how you would for real HW, you can do:
    :goals: build
    :gen-args: -DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf
 
-Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
+Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
 For more information, check :ref:`this board documentation <nrf52_bsim>`.
 
 Building for a simulated nrf5340bsim

samples/bluetooth/bap_unicast_server/README.rst

@@ -25,7 +25,7 @@ Building and Running
 ********************
 
 When building targeting an nrf52 series board with the Zephyr Bluetooth Controller,
-use `-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf` to enable the required ISO
+use ``-DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf`` to enable the required ISO
 feature support.
 
 Building for an nrf52840dk
@@ -71,7 +71,7 @@ Similarly to how you would for real HW, you can do:
    :goals: build
    :gen-args: -DOVERLAY_CONFIG=overlay-bt_ll_sw_split.conf
 
-Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
+Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
 For more information, check :ref:`this board documentation <nrf52_bsim>`.
 
 Building for a simulated nrf5340bsim

samples/bluetooth/broadcaster_multiple/README.rst

@@ -12,11 +12,11 @@ uses multiple advertising sets functionality.
 
 This sample advertises two non-connectable non-scannable advertising sets with
 two different SID. Number of advertising sets can be increased by updating the
-`CONFIG_BT_EXT_ADV_MAX_ADV_SET` value in the project configuration file.
+:kconfig:option:`CONFIG_BT_EXT_ADV_MAX_ADV_SET` value in the project configuration file.
 
 When building this sample combined with a Bluetooth LE Controller, the
 advertising data length can be increased from the default 31 bytes by updating
-the Controller's `CONFIG_BT_CTLR_ADV_DATA_LEN_MAX` value. The size of the
+the Controller's :kconfig:option:`CONFIG_BT_CTLR_ADV_DATA_LEN_MAX` value. The size of the
 manufacturer data is calculated to maximize the use of supported AD data length.
 
 Requirements

samples/bluetooth/cap_acceptor/README.rst

@@ -61,7 +61,7 @@ Similarly to how you would for real HW, you can do:
    :goals: build
    :west-args: --sysbuild
 
-Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
+Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
 For more information, check :ref:`this board documentation <nrf5340bsim>`.
 
 Building for a simulated nrf52_bsim

samples/bluetooth/cap_initiator/README.rst

@@ -62,7 +62,7 @@ Similarly to how you would for real HW, you can do:
    :goals: build
    :west-args: --sysbuild
 
-Note this will produce a Linux executable in `./build/zephyr/zephyr.exe`.
+Note this will produce a Linux executable in :file:`./build/zephyr/zephyr.exe`.
 For more information, check :ref:`this board documentation <nrf5340bsim>`.
 
 Building for a simulated nrf52_bsim

samples/bluetooth/encrypted_advertising/README.rst

@@ -15,7 +15,7 @@ This sample demonstrates the use of the encrypted advertising feature, such as:
  - the decryption of those advertising payloads,
  - and the update of the Randomizer field whenever the RPA is changed.
 
-To use the `bt_ead_encrypt` and `bt_ead_decrypt` functions, you must enable
+To use the :c:func:`bt_ead_encrypt` and :c:func:`bt_ead_decrypt` functions, you must enable
 the Kconfig symbol :kconfig:option:`CONFIG_BT_EAD`.
 
 While this sample uses extended advertising, it is **not** mandatory when using

samples/bluetooth/extended_adv/README.rst

@@ -21,7 +21,7 @@ while the scanner cools-down for 5 seconds to restart its process.
 This sample handles all actions in a separate thread, to promote good design
 practices. Even though it is not strictly required, scheduling from another context is
 strongly recommended (e.g. using a work item), as re-starting an advertiser or
-scanner from within the `recycled` callback exposes the application to deadlocking.
+scanner from within the ``recycled`` callback exposes the application to deadlocking.
 
 Requirements
 ************

samples/bluetooth/hci_uart/README.rst

@@ -157,7 +157,7 @@ Using the controller with the Zephyr host
 This describes how to hook up a board running this sample to a board running
 an application that uses the Zephyr host.
 
-On the controller side, the `zephyr,bt-c2h-uart` DTS property (in the `chosen`
+On the controller side, the ``zephyr,bt-c2h-uart`` DTS property (in the ``chosen``
 block) is used to select which uart device to use. For example if we want to
 keep the console logs, we can keep console on uart0 and the HCI on uart1 like
 so:
@@ -180,7 +180,7 @@ driver instead of the built-in controller:
    CONFIG_BT_HCI=y
    CONFIG_BT_CTLR=n
 
-Similarly, the `zephyr,bt-hci` DTS property selects which HCI instance to use.
+Similarly, the ``zephyr,bt-hci`` DTS property selects which HCI instance to use.
 The UART needs to have as its child node a HCI UART node:
 
 .. code-block:: dts

samples/bluetooth/hci_uart_3wire/README.rst

@@ -157,7 +157,7 @@ Using the controller with the Zephyr host
 This describes how to hook up a board running this sample to a board running
 an application that uses the Zephyr host.
 
-On the controller side, the `zephyr,bt-c2h-uart` DTS property (in the `chosen`
+On the controller side, the ``zephyr,bt-c2h-uart`` DTS property (in the ``chosen``
 block) is used to select which uart device to use. For example if we want to
 keep the console logs, we can keep console on uart0 and the HCI on uart1 like
 so:
@@ -180,7 +180,7 @@ driver instead of the built-in controller:
    CONFIG_BT_HCI=y
    CONFIG_BT_CTLR=n
 
-Similarly, the `zephyr,bt-hci` DTS property selects which HCI instance to use.
+Similarly, the ``zephyr,bt-hci`` DTS property selects which HCI instance to use.
 The UART needs to have as its child node a HCI UART node:
 
 .. code-block:: dts

samples/bluetooth/hci_uart_async/README.rst

@@ -125,7 +125,7 @@ Using the controller with the Zephyr host
 This describes how to hook up a board running this sample to a board running
 an application that uses the Zephyr host.
 
-On the controller side, the `zephyr,bt-c2h-uart` DTS property (in the `chosen`
+On the controller side, the ``zephyr,bt-c2h-uart`` DTS property (in the ``chosen``
 block) is used to select which uart device to use. For example if we want to
 keep the console logs, we can keep console on uart0 and the HCI on uart1 like
 so:
@@ -148,7 +148,7 @@ driver instead of the built-in controller:
    CONFIG_BT_HCI=y
    CONFIG_BT_CTLR=n
 
-Similarly, the `zephyr,bt-hci` DTS property selects which HCI instance to use.
+Similarly, the ``zephyr,bt-hci`` DTS property selects which HCI instance to use.
 The UART needs to have as its child node a HCI UART node:
 
 .. code-block:: dts

samples/bluetooth/iso_broadcast/README.rst

@@ -22,7 +22,7 @@ Building and Running
 ********************
 
 This sample can be found under :zephyr_file:`samples/bluetooth/iso_broadcast` in
-the Zephyr tree. Use `-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf` to enable
+the Zephyr tree. Use ``-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf`` to enable
 required ISO feature support in Zephyr Bluetooth Controller on supported boards.
 
 Use the sample found under :zephyr_file:`samples/bluetooth/iso_receive` in the

samples/bluetooth/iso_receive/README.rst

@@ -22,7 +22,7 @@ Building and Running
 ********************
 
 This sample can be found under :zephyr_file:`samples/bluetooth/iso_receive` in
-the Zephyr tree. Use `-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf` to enable
+the Zephyr tree. Use ``-DEXTRA_CONF_FILE=overlay-bt_ll_sw_split.conf`` to enable
 required ISO feature support in Zephyr Bluetooth Controller on supported boards.
 
 Use the sample found under :zephyr_file:`samples/bluetooth/iso_broadcast` on

samples/bluetooth/observer/README.rst

@@ -13,7 +13,7 @@ If any found, prints the address of the device, the RSSI value, the Advertising
 type, and the Advertising data length to the console.
 
 If the used Bluetooth Low Energy Controller supports Extended Scanning, you may
-enable `CONFIG_BT_EXT_ADV` in the project configuration file. Refer to the
+enable :kconfig:option:`CONFIG_BT_EXT_ADV` in the project configuration file. Refer to the
 project configuration file for further details.
 
 Requirements