doc: sphinx-lint: fix bad usage of "default role" (single backticks)

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,15 +172,15 @@ 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!
 
 #. Plug in ``ctcc/nrf52840`` card to mPCIe/M.2 slot or use mPCIe/M.2 adapter to USB
    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,27 +135,27 @@ 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
   selecting the HW models which are built in the native simulator runner context, IRQ handling,
   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