michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: use :kconfig:option: domain role

Browse source 
Kconfig options now belong to the Kconfig domain, therefore, the
:kconfig:option: role needs to be used.

Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This commit is contained in:
Gerard Marull-Paretas 2022-02-07 17:27:43 +01:00 • committed by Carles Cufí
commit 260deccb6e
162 changed files with 696 additions and 696 deletions
Download patch file Download diff file Expand all files Collapse all files

12
boards/arc/em_starterkit/doc/index.rst
View file

@ -68,16 +68,16 @@ In Zephyr, only firmware versions 2.2 and 2.3 are supported.
* For EM Starter Kit 2.2, EM7D, EM9D and EM11D core configurations are supported.
* Use :kconfig:`CONFIG_BOARD_EM_STARTERKIT_R22` to select 2.2 version.
* Use :kconfig:`CONFIG_SOC_EMSK_EM7D`, :kconfig:`CONFIG_SOC_EMSK_EM9D` or
:kconfig:`CONFIG_SOC_EMSK_EM11D` to select EM7D or EM9D or EM11D.
* Use :kconfig:option:`CONFIG_BOARD_EM_STARTERKIT_R22` to select 2.2 version.
* Use :kconfig:option:`CONFIG_SOC_EMSK_EM7D`, :kconfig:option:`CONFIG_SOC_EMSK_EM9D` or
:kconfig:option:`CONFIG_SOC_EMSK_EM11D` to select EM7D or EM9D or EM11D.
* For EM Starter Kit 2.3, EM7D, EM9D and EM11D core configurations are
supported.
* Use :kconfig:`CONFIG_BOARD_EM_STARTERKIT_R23` to select 2.3 version.
* Use :kconfig:`CONFIG_SOC_EMSK_EM7D`, :kconfig:`CONFIG_SOC_EMSK_EM9D` or
:kconfig:`CONFIG_SOC_EMSK_EM11D` to select EM7D or EM9D or EM11D.
* Use :kconfig:option:`CONFIG_BOARD_EM_STARTERKIT_R23` to select 2.3 version.
* Use :kconfig:option:`CONFIG_SOC_EMSK_EM7D`, :kconfig:option:`CONFIG_SOC_EMSK_EM9D` or
:kconfig:option:`CONFIG_SOC_EMSK_EM11D` to select EM7D or EM9D or EM11D.
Supported Features
==================

8
boards/arc/emsdp/doc/index.rst
View file

@ -26,10 +26,10 @@ Hardware
The EM Software Development Platform supports different core configurations, such as EM4,
EM5D, EM6, EM7D, EM9D, EM9D+ESP, EM11D, the default core configuration is EM11D. Use
:kconfig:`CONFIG_SOC_EMSDP_EM4`, :kconfig:`CONFIG_SOC_EMSDP_EM5D`,
:kconfig:`CONFIG_SOC_EMSDP_EM6`, :kconfig:`CONFIG_SOC_EMSDP_EM7D`,
:kconfig:`CONFIG_SOC_EMSDP_EM7D_ESP`, :kconfig:`CONFIG_SOC_EMSDP_EM9D` or
:kconfig:`CONFIG_SOC_EMSDP_EM11D` to select different core configuration.
:kconfig:option:`CONFIG_SOC_EMSDP_EM4`, :kconfig:option:`CONFIG_SOC_EMSDP_EM5D`,
:kconfig:option:`CONFIG_SOC_EMSDP_EM6`, :kconfig:option:`CONFIG_SOC_EMSDP_EM7D`,
:kconfig:option:`CONFIG_SOC_EMSDP_EM7D_ESP`, :kconfig:option:`CONFIG_SOC_EMSDP_EM9D` or
:kconfig:option:`CONFIG_SOC_EMSDP_EM11D` to select different core configuration.
The following table shows the hardware features supported for different core configuration:

2
boards/arm/arty/doc/index.rst
View file

@ -184,7 +184,7 @@ the next time the FPGA is configured.
The steps to persist the application within the FPGA bitstream are covered by
the ARM Cortex-M1/M3 DesignStart FPGA Xilinx edition user guide. If the
:kconfig:`CONFIG_BUILD_OUTPUT_BIN` is enabled and the `SiFive elf2hex`_ package
:kconfig:option:`CONFIG_BUILD_OUTPUT_BIN` is enabled and the `SiFive elf2hex`_ package
is available, the build system will automatically generate a Verilog memory hex
dump :file:`zephyr.mem` file suitable for initialising the block RAM using
`Xilinx Vivado`_.

4
boards/arm/cc1352r1_launchxl/doc/index.rst
View file

@ -196,7 +196,7 @@ Bootloader
The ROM bootloader on CC13x2 and CC26x2 devices is enabled by default. The
bootloader will start if there is no valid application image in flash or the
so-called backdoor is enabled (via option
:kconfig:`CONFIG_CC13X2_CC26X2_BOOTLOADER_BACKDOOR_ENABLE`) and BTN-1 is held
:kconfig:option:`CONFIG_CC13X2_CC26X2_BOOTLOADER_BACKDOOR_ENABLE`) and BTN-1 is held
down during reset. See the bootloader documentation in chapter 10 of the `TI
CC13x2 / CC26x2 Technical Reference Manual`_ for additional information.
@ -205,7 +205,7 @@ Power Management and UART
System and device power management are supported on this platform, and
can be enabled via the standard Kconfig options in Zephyr, such as
:kconfig:`CONFIG_PM`, :kconfig:`CONFIG_PM_DEVICE`.
:kconfig:option:`CONFIG_PM`, :kconfig:option:`CONFIG_PM_DEVICE`.
When system power management is turned on (CONFIG_PM=y),
sleep state 2 (standby mode) is allowed, and polling is used to retrieve input

4
boards/arm/cc1352r_sensortag/doc/index.rst
View file

@ -222,7 +222,7 @@ Bootloader
The ROM bootloader on CC13x2 and CC26x2 devices is enabled by default. The
bootloader will start if there is no valid application image in flash or the
so-called backdoor is enabled (via option
:kconfig:`CONFIG_CC13X2_CC26X2_BOOTLOADER_BACKDOOR_ENABLE`) and BTN-1 is held
:kconfig:option:`CONFIG_CC13X2_CC26X2_BOOTLOADER_BACKDOOR_ENABLE`) and BTN-1 is held
down during reset. See the bootloader documentation in chapter 10 of the `TI
CC13x2 / CC26x2 Technical Reference Manual`_ for additional information.
@ -231,7 +231,7 @@ Power Management and UART
System and device power management are supported on this platform, and
can be enabled via the standard Kconfig options in Zephyr, such as
:kconfig:`CONFIG_PM`, :kconfig:`CONFIG_PM_DEVICE`.
:kconfig:option:`CONFIG_PM`, :kconfig:option:`CONFIG_PM_DEVICE`.
When system power management is turned on (CONFIG_PM=y),
sleep state 2 (standby mode) is allowed, and polling is used to retrieve input

4
boards/arm/cc26x2r1_launchxl/doc/index.rst
View file

@ -202,7 +202,7 @@ Bootloader
The ROM bootloader on CC13x2 and CC26x2 devices is enabled by default. The
bootloader will start if there is no valid application image in flash or the
so-called backdoor is enabled (via option
:kconfig:`CONFIG_CC13X2_CC26X2_BOOTLOADER_BACKDOOR_ENABLE`) and BTN-1 is held
:kconfig:option:`CONFIG_CC13X2_CC26X2_BOOTLOADER_BACKDOOR_ENABLE`) and BTN-1 is held
down during reset. See the bootloader documentation in chapter 10 of the `TI
CC13x2 / CC26x2 Technical Reference Manual`_ for additional information.
@ -211,7 +211,7 @@ Power Management and UART
System and device power management are supported on this platform, and
can be enabled via the standard Kconfig options in Zephyr, such as
:kconfig:`CONFIG_PM`, :kconfig:`CONFIG_PM_DEVICE`.
:kconfig:option:`CONFIG_PM`, :kconfig:option:`CONFIG_PM_DEVICE`.
When system power management is turned on (CONFIG_PM=y),
sleep state 2 (standby mode) is allowed, and polling is used to retrieve input

8
boards/arm/cc3220sf_launchxl/doc/index.rst
View file

@ -244,7 +244,7 @@ It is available as a Zephyr Wi-Fi device driver in
Usage:
======
Set :kconfig:`CONFIG_WIFI_SIMPLELINK` and :kconfig:`CONFIG_WIFI` to ``y``
Set :kconfig:option:`CONFIG_WIFI_SIMPLELINK` and :kconfig:option:`CONFIG_WIFI` to ``y``
to enable Wi-Fi.
See :zephyr_file:`samples/net/wifi/boards/cc3220sf_launchxl.conf`.
@ -272,14 +272,14 @@ Secure Socket Offload
The SimpleLink Wi-Fi driver provides socket operations to the Zephyr socket
offload point, enabling Zephyr BSD socket API calls to be directed to the
SimpleLink Wi-Fi driver, by setting :kconfig:`CONFIG_NET_SOCKETS_OFFLOAD`
SimpleLink Wi-Fi driver, by setting :kconfig:option:`CONFIG_NET_SOCKETS_OFFLOAD`
to ``y``.
Secure socket (TLS) communication is handled as part of the socket APIs,
and enabled by:
- setting both :kconfig:`CONFIG_NET_SOCKETS_SOCKOPT_TLS`
and :kconfig:`CONFIG_TLS_CREDENTIAL_FILENAMES` to ``y``,
- setting both :kconfig:option:`CONFIG_NET_SOCKETS_SOCKOPT_TLS`
and :kconfig:option:`CONFIG_TLS_CREDENTIAL_FILENAMES` to ``y``,
- using the TI Uniflash tool to program the required certificates and
keys to the secure flash filesystem, and enabling the TI Trusted
Root-Certificate Catalog.

8
boards/arm/cc3235sf_launchxl/doc/index.rst
View file

@ -244,7 +244,7 @@ It is available as a Zephyr Wi-Fi device driver in
Usage:
======
Set :kconfig:`CONFIG_WIFI_SIMPLELINK` and :kconfig:`CONFIG_WIFI` to ``y``
Set :kconfig:option:`CONFIG_WIFI_SIMPLELINK` and :kconfig:option:`CONFIG_WIFI` to ``y``
to enable Wi-Fi.
See :zephyr_file:`samples/net/wifi/boards/cc3235sf_launchxl.conf`.
@ -272,14 +272,14 @@ Secure Socket Offload
The SimpleLink Wi-Fi driver provides socket operations to the Zephyr socket
offload point, enabling Zephyr BSD socket API calls to be directed to the
SimpleLink Wi-Fi driver, by setting :kconfig:`CONFIG_NET_SOCKETS_OFFLOAD`
SimpleLink Wi-Fi driver, by setting :kconfig:option:`CONFIG_NET_SOCKETS_OFFLOAD`
to ``y``.
Secure socket (TLS) communication is handled as part of the socket APIs,
and enabled by:
- setting both :kconfig:`CONFIG_NET_SOCKETS_SOCKOPT_TLS`
and :kconfig:`CONFIG_TLS_CREDENTIAL_FILENAMES` to ``y``,
- setting both :kconfig:option:`CONFIG_NET_SOCKETS_SOCKOPT_TLS`
and :kconfig:option:`CONFIG_TLS_CREDENTIAL_FILENAMES` to ``y``,
- using the TI Uniflash tool to program the required certificates and
keys to the secure flash filesystem, and enabling the TI Trusted
Root-Certificate Catalog.

4
boards/arm/gd32f350r_eval/doc/index.rst
View file

@ -57,10 +57,10 @@ The board configuration supports the following hardware features:
- N/A
- N/A
* - USART
- :kconfig:`CONFIG_SERIAL`
- :kconfig:option:`CONFIG_SERIAL`
- :dtcompatible:`gd,gd32-usart`
* - PINMUX
- :kconfig:`CONFIG_PINCTRL`
- :kconfig:option:`CONFIG_PINCTRL`
- :dtcompatible:`gd,gd32-pinctrl-af`
Serial Port

14
boards/arm/gd32f450i_eval/doc/index.rst
View file

@ -60,31 +60,31 @@ The board configuration supports the following hardware features:
- Kconfig option
- Devicetree compatible
* - EXTI
- :kconfig:`CONFIG_GD32_EXTI`
- :kconfig:option:`CONFIG_GD32_EXTI`
- :dtcompatible:`gd,gd32-exti`
* - GPIO
- :kconfig:`CONFIG_GPIO`
- :kconfig:option:`CONFIG_GPIO`
- :dtcompatible:`gd,gd32-gpio`
* - NVIC
- N/A
- :dtcompatible:`arm,v7m-nvic`
* - PWM
- :kconfig:`CONFIG_PWM`
- :kconfig:option:`CONFIG_PWM`
- :dtcompatible:`gd,gd32-pwm`
* - SYSTICK
- N/A
- N/A
* - USART
- :kconfig:`CONFIG_SERIAL`
- :kconfig:option:`CONFIG_SERIAL`
- :dtcompatible:`gd,gd32-usart`
* - DAC
- :kconfig:`CONFIG_DAC`
- :kconfig:option:`CONFIG_DAC`
- :dtcompatible:`gd,gd32-dac`
* - I2C
- :kconfig:`CONFIG_I2C`
- :kconfig:option:`CONFIG_I2C`
- :dtcompatible:`gd,gd32-i2c`
* - EEPROM
- :kconfig:`CONFIG_EEPROM`
- :kconfig:option:`CONFIG_EEPROM`
- :dtcompatible:`atmel,at24`
Serial Port

2
boards/arm/mimxrt1050_evk/doc/index.rst
View file

@ -377,7 +377,7 @@ Troubleshooting
If the debug probe fails to connect with the following error, it's possible
that the boot header in HyperFlash is invalid or corrupted. The boot header is
configured by :kconfig:`CONFIG_NXP_IMX_RT_BOOT_HEADER`.
configured by :kconfig:option:`CONFIG_NXP_IMX_RT_BOOT_HEADER`.
.. code-block:: console

2
boards/arm/mimxrt1060_evk/doc/index.rst
View file

@ -374,7 +374,7 @@ Troubleshooting
If the debug probe fails to connect with the following error, it's possible
that the boot header in QSPI flash is invalid or corrupted. The boot header is
configured by :kconfig:`CONFIG_NXP_IMX_RT_BOOT_HEADER`.
configured by :kconfig:option:`CONFIG_NXP_IMX_RT_BOOT_HEADER`.
.. code-block:: console

2
boards/arm/mimxrt1064_evk/doc/index.rst
View file

@ -375,7 +375,7 @@ Troubleshooting
If the debug probe fails to connect with the following error, it's possible
that the boot header in QSPI flash is invalid or corrupted. The boot header is
configured by :kconfig:`CONFIG_NXP_IMX_RT_BOOT_HEADER`.
configured by :kconfig:option:`CONFIG_NXP_IMX_RT_BOOT_HEADER`.
.. code-block:: console

2
boards/arm/nrf52840dongle_nrf52840/doc/index.rst
View file

@ -264,7 +264,7 @@ name.
.. note::
This board supports building other Zephyr applications for flashing with
MCUboot in this way also. Just make sure :kconfig:`CONFIG_BOOTLOADER_MCUBOOT`
MCUboot in this way also. Just make sure :kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT`
is set when building your application. For example, to compile blinky for
loading by MCUboot, use this:

6
boards/arm/rpi_pico/doc/index.rst
View file

@ -52,13 +52,13 @@ hardware features:
- N/A
- :dtcompatible:`arm,v6m-nvic`
* - UART
- :kconfig:`CONFIG_SERIAL`
- :kconfig:option:`CONFIG_SERIAL`
- :dtcompatible:`rpi,pico-uart`
* - GPIO
- :kconfig:`CONFIG_GPIO`
- :kconfig:option:`CONFIG_GPIO`
- :dtcompatible:`rpi,pico-gpio`
* - I2C
- :kconfig:`CONFIG_I2C`
- :kconfig:option:`CONFIG_I2C`
- :dtcompatible:`rpi,pico-i2c`
Programming and Debugging

40
boards/posix/native_posix/doc/index.rst
View file

@ -182,7 +182,7 @@ Application tests using the ``ztest`` framework will exit after all
tests have completed.
If you want your application to gracefully finish when it reaches some point,
you may add a conditionally compiled (:kconfig:`CONFIG_ARCH_POSIX`) call to
you may add a conditionally compiled (:kconfig:option:`CONFIG_ARCH_POSIX`) call to
``posix_exit(int status)`` at that point.
Debugging
@ -199,13 +199,13 @@ code multiple times and get the exact same result. Instrumenting the
code does not affect its execution.
To ease debugging you may want to compile your code without optimizations
(e.g., -O0) by setting :kconfig:`CONFIG_NO_OPTIMIZATIONS`.
(e.g., -O0) by setting :kconfig:option:`CONFIG_NO_OPTIMIZATIONS`.
Address Sanitizer (ASan)
========================
You can also build Zephyr with `Address Sanitizer`_. To do this, set
:kconfig:`CONFIG_ASAN`, for example, in the application project file, or in the
:kconfig:option:`CONFIG_ASAN`, for example, in the application project file, or in the
``west build`` or ``cmake`` command line invocation.
Note that you will need the ASan library installed in your system.
@ -239,7 +239,7 @@ LP64 ABI (x86-64 in x86 systems), where pointers and longs are 64 bits.
You can use this target if you cannot compile or run 32 bit binaries.
If you are using another 32 bit POSIX arch target you may also override its ABI
target and pointer bit width by setting :kconfig:`CONFIG_64BIT`.
target and pointer bit width by setting :kconfig:option:`CONFIG_64BIT`.
Rationale for this port
@ -414,7 +414,7 @@ This model can be configured to slow down the execution of native_posix to
real time.
You can do this with the ``--rt`` and ``--no-rt`` options from the command line.
The default behavior is set with
:kconfig:`CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME`.
:kconfig:option:`CONFIG_NATIVE_POSIX_SLOWDOWN_TO_REAL_TIME`.
Note that all this model does is wait before raising the
next system tick interrupt until the corresponding real/host time.
If, for some reason, native_posix runs slower than real time, all this
@ -469,7 +469,7 @@ The following peripherals are currently provided with this board:
**Clock, timer and system tick model**
This model provides the system tick timer. By default
:kconfig:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` configures it to tick every 10ms.
:kconfig:option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` configures it to tick every 10ms.
This peripheral driver also provides the needed functionality for this
architecture-specific :c:func:`k_busy_wait`.
@ -526,7 +526,7 @@ The following peripherals are currently provided with this board:
Zephyr via this network interface. Multiple TAP based network interfaces can
be created if needed. The IP address configuration can be specified for each
network interface instance.
See :kconfig:`CONFIG_ETH_NATIVE_POSIX_SETUP_SCRIPT` option for more details.
See :kconfig:option:`CONFIG_ETH_NATIVE_POSIX_SETUP_SCRIPT` option for more details.
The :ref:`eth-native-posix-sample` sample app provides
some use examples and more information about this driver configuration.
@ -570,7 +570,7 @@ The following peripherals are currently provided with this board:
A flash driver is provided that accesses all flash data through a binary file
on the host file system. The behavior of the flash device can be configured
through the native POSIX board devicetree or Kconfig settings under
:kconfig:`CONFIG_FLASH_SIMULATOR`.
:kconfig:option:`CONFIG_FLASH_SIMULATOR`.
By default the binary data is located in the file *flash.bin* in the current
working directory. The location of this file can be changed through the
@ -585,24 +585,24 @@ The following peripherals are currently provided with this board:
UART
****
This driver can be configured with :kconfig:`CONFIG_UART_NATIVE_POSIX`
This driver can be configured with :kconfig:option:`CONFIG_UART_NATIVE_POSIX`
to instantiate up to two UARTs. By default only one UART is enabled.
With :kconfig:`CONFIG_UART_NATIVE_POSIX_PORT_1_ENABLE`
With :kconfig:option:`CONFIG_UART_NATIVE_POSIX_PORT_1_ENABLE`
you can enable the second one.
For the first UART, it can link it to a new
pseudoterminal (i.e. ``/dev/pts<nbr>``), or map the UART input and
output to the executable's ``stdin`` and ``stdout``.
This is chosen by selecting either
:kconfig:`CONFIG_NATIVE_UART_0_ON_OWN_PTY` or
:kconfig:`CONFIG_NATIVE_UART_0_ON_STDINOUT`
:kconfig:option:`CONFIG_NATIVE_UART_0_ON_OWN_PTY` or
:kconfig:option:`CONFIG_NATIVE_UART_0_ON_STDINOUT`
For interactive use with the :ref:`shell_api`, choose the first (OWN_PTY) option.
The second (STDINOUT) option can be used with the shell for automated
testing, such as when piping other processes' output to control it.
This is because the shell subsystem expects access to a raw terminal,
which (by default) a normal Linux terminal is not.
When :kconfig:`CONFIG_NATIVE_UART_0_ON_OWN_PTY` is chosen, the name of the
When :kconfig:option:`CONFIG_NATIVE_UART_0_ON_OWN_PTY` is chosen, the name of the
newly created UART pseudo-terminal will be displayed in the console.
If you want to interact with it manually, you should attach a terminal emulator
to it. This can be done, for example with the command::
@ -615,7 +615,7 @@ You may also chose to automatically attach a terminal emulator to the first UART
by passing the command line option ``-attach_uart`` to the executable.
The command used for attaching to the new shell can be set with the command line
option ``-attach_uart_cmd=<"cmd">``. Where the default command is given by
:kconfig:`CONFIG_NATIVE_UART_AUTOATTACH_DEFAULT_CMD`.
:kconfig:option:`CONFIG_NATIVE_UART_AUTOATTACH_DEFAULT_CMD`.
Note that the default command assumes both ``xterm`` and ``screen`` are
installed in the system.
@ -632,21 +632,21 @@ development by integrating more seamlessly with the host operating system:
``stdout``.
This driver is selected by default if the `UART`_ is not compiled in.
Otherwise :kconfig:`CONFIG_UART_CONSOLE` will be set to select the UART as
Otherwise :kconfig:option:`CONFIG_UART_CONSOLE` will be set to select the UART as
console backend.
**Logger backend**:
A backend which prints all logger output to the process ``stdout``.
It supports timestamping, which can be enabled with
:kconfig:`CONFIG_LOG_BACKEND_FORMAT_TIMESTAMP`; and colored output which can
be enabled with :kconfig:`CONFIG_LOG_BACKEND_SHOW_COLOR` and controlled
:kconfig:option:`CONFIG_LOG_BACKEND_FORMAT_TIMESTAMP`; and colored output which can
be enabled with :kconfig:option:`CONFIG_LOG_BACKEND_SHOW_COLOR` and controlled
with the command line options ``--color``, ``--no-color`` and
``--force-color``.
In native_posix, by default, the logger is configured with
:kconfig:`CONFIG_LOG_MODE_IMMEDIATE`.
:kconfig:option:`CONFIG_LOG_MODE_IMMEDIATE`.
This backend can be selected with :kconfig:`CONFIG_LOG_BACKEND_NATIVE_POSIX`
This backend can be selected with :kconfig:option:`CONFIG_LOG_BACKEND_NATIVE_POSIX`
and is enabled by default unless the native_posix UART is compiled in.
In this later case, by default, the logger is set to output to the `UART`_.
@ -660,7 +660,7 @@ Host based flash access
If a flash device is present, the file system partitions on the flash
device can be exposed through the host file system by enabling
:kconfig:`CONFIG_FUSE_FS_ACCESS`. This option enables a FUSE
:kconfig:option:`CONFIG_FUSE_FS_ACCESS`. This option enables a FUSE
(File system in User space) layer that maps the Zephyr file system calls to
the required UNIX file system calls, and provides access to the flash file
system partitions with normal operating system commands such as ``cd``,

10
boards/riscv/gd32vf103v_eval/doc/index.rst
View file

@ -53,19 +53,19 @@ The board configuration supports the following hardware features:
- Kconfig option
- Devicetree compatible
* - GPIO
- :kconfig:`CONFIG_GPIO`
- :kconfig:option:`CONFIG_GPIO`
- :dtcompatible:`gd,gd32-gpio`
* - Machine timer
- :kconfig:`CONFIG_RISCV_MACHINE_TIMER`
- :kconfig:option:`CONFIG_RISCV_MACHINE_TIMER`
- :dtcompatible:`riscv,machine-timer`
* - Nuclei ECLIC Interrupt Controller
- :kconfig:`CONFIG_NUCLEI_ECLIC`
- :kconfig:option:`CONFIG_NUCLEI_ECLIC`
- :dtcompatible:`nuclei,eclic`
* - PWM
- :kconfig:`CONFIG_PWM`
- :kconfig:option:`CONFIG_PWM`
- :dtcompatible:`gd,gd32-pwm`
* - USART
- :kconfig:`CONFIG_SERIAL`
- :kconfig:option:`CONFIG_SERIAL`
- :dtcompatible:`gd,gd32-usart`
Serial Port

4
boards/riscv/neorv32/doc/index.rst
View file

@ -164,7 +164,7 @@ revert to the application stored in the block RAM within the FPGA bitstream
the next time the FPGA is configured.
The steps to persist the application within the FPGA bitstream are covered by
the NEORV32 user guide. If the :kconfig:`CONFIG_BUILD_OUTPUT_BIN` is enabled and
the NEORV32 user guide. If the :kconfig:option:`CONFIG_BUILD_OUTPUT_BIN` is enabled and
the NEORV32 ``image_gen`` binary is available, the build system will
automatically generate a :file:`zephyr.vhd` file suitable for initialising the
internal instruction memory of the NEORV32.
@ -182,7 +182,7 @@ can be passed at build time:
Uploading via UART
==================
If the :kconfig:`CONFIG_BUILD_OUTPUT_BIN` is enabled and the NEORV32
If the :kconfig:option:`CONFIG_BUILD_OUTPUT_BIN` is enabled and the NEORV32
``image_gen`` binary is available, the build system will automatically generate
a :file:`zephyr_exe.bin` file suitable for uploading to the NEORV32 via the
built-in bootloader as described in the NEORV32 user guide.

6
doc/application/index.rst
View file

@ -526,7 +526,7 @@ Zephyr is a project under constant development and thus there are features that
are still in early stages of their development cycle. Such features will be
marked ``[EXPERIMENTAL]`` in their Kconfig title.
The :kconfig:`CONFIG_WARN_EXPERIMENTAL` setting can be used to enable warnings
The :kconfig:option:`CONFIG_WARN_EXPERIMENTAL` setting can be used to enable warnings
at CMake configure time if any experimental feature is enabled.
.. code-block:: none
@ -534,8 +534,8 @@ at CMake configure time if any experimental feature is enabled.
CONFIG_WARN_EXPERIMENTAL=y
For example, if option ``CONFIG_FOO`` is experimental, then enabling it and
:kconfig:`CONIG_WARN_EXPERIMENTAL` will print the following warning at CMake
configure time when you build an application:
:kconfig:option:`CONIG_WARN_EXPERIMENTAL` will print the following warning at
CMake configure time when you build an application:
.. code-block:: none

2
doc/glossary.rst
View file

@ -53,7 +53,7 @@ Glossary of Terms
Device Runtime Power Management (PM) refers the capability of devices to
save energy independently of the the system power state. Devices will keep
reference of their usage and will automatically be suspended or resumed.
This feature is enabled via the :kconfig:`CONFIG_PM_DEVICE_RUNTIME`
This feature is enabled via the :kconfig:option:`CONFIG_PM_DEVICE_RUNTIME`
Kconfig option.
idle thread

88
doc/guides/arch/arm_cortex_m.rst
View file

@ -97,11 +97,11 @@ Thread stack alignment
----------------------
Each Zephyr thread is defined with its own stack memory. By default, Cortex-M enforces a double word thread stack alignment, see
:kconfig:`CONFIG_STACK_ALIGN_DOUBLE_WORD`. If MPU-based HW-assisted stack overflow detection (:kconfig:`CONFIG_MPU_STACK_GUARD`)
is enabled, thread stacks need to be aligned with a larger value, reflected by :kconfig:`CONFIG_ARM_MPU_REGION_MIN_ALIGN_AND_SIZE`.
:kconfig:option:`CONFIG_STACK_ALIGN_DOUBLE_WORD`. If MPU-based HW-assisted stack overflow detection (:kconfig:option:`CONFIG_MPU_STACK_GUARD`)
is enabled, thread stacks need to be aligned with a larger value, reflected by :kconfig:option:`CONFIG_ARM_MPU_REGION_MIN_ALIGN_AND_SIZE`.
In Arm v6-M and Arm v7-M architecture variants, thread stacks are additionally required to be align with a value equal to their size,
in applications that need to support user mode (:kconfig:`CONFIG_USERSPACE`). The thread stack sizes in that case need to be a power
of two. This is all reflected by :kconfig:`CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT`, that is enforced in Arm v6-M and Arm v7-M
in applications that need to support user mode (:kconfig:option:`CONFIG_USERSPACE`). The thread stack sizes in that case need to be a power
of two. This is all reflected by :kconfig:option:`CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT`, that is enforced in Arm v6-M and Arm v7-M
builds with user mode support.
Stack pointers
@ -114,7 +114,7 @@ handler mode.
In Arm Cortex-M builds a single interrupt stack memory is shared among exceptions and interrupts. The size of the interrupt stack needs
to be selected taking into consideration nested interrupts, each pushing an additional stack frame. Deverlopers can modify the interrupt
stack size using :kconfig:`CONFIG_ISR_STACK_SIZE`.
stack size using :kconfig:option:`CONFIG_ISR_STACK_SIZE`.
The interrupt stack is also used during early boot so the kernel can initialize the main thread's stack before switching to the main thread.
@ -161,9 +161,9 @@ Typically a thread context-switch will perform the following operations
memories, and/or programs a stack-overflow MPU guard at the bottom of the thread's
privileged stack
* restores the PSP for the incoming thread and re-programs the stack pointer limit
register (if applicable, see :kconfig:`CONFIG_BUILTIN_STACK_GUARD`)
register (if applicable, see :kconfig:option:`CONFIG_BUILTIN_STACK_GUARD`)
* optionally does a stack limit checking for the switched-in thread, if
sentinel-based stack limit checking is enabled (see :kconfig:`CONFIG_STACK_SENTINEL`).
sentinel-based stack limit checking is enabled (see :kconfig:option:`CONFIG_STACK_SENTINEL`).
PendSV exception return sequence restores the new thread's caller-saved registers and the
return address, as part of unstacking the exception stack frame.
@ -175,7 +175,7 @@ Stack limit checking (Arm v8-M)
-------------------------------
Armv8-M and Armv8.1-M variants support stack limit checking using the MSPLIM and PSPLIM
core registers. The feature is enabled when :kconfig:`CONFIG_BUILTIN_STACK_GUARD` is set.
core registers. The feature is enabled when :kconfig:option:`CONFIG_BUILTIN_STACK_GUARD` is set.
When stack limit checking is enabled, both the thread's privileged or user stack, as well
as the interrupt stack are guarded by PSPLIM and MSPLIM registers, respectively. MSPLIM is
configured *once* during kernel boot, while PSLIM is re-programmed during every thread
@ -225,7 +225,7 @@ higher than any configurable exception priority.
In *Mainline* Cortex-M, the available fault exceptions (e.g. MemManageFault,
UsageFault, etc.) are assigned the highest *configurable* priority level.
(:kconfig:`CONFIG_CPU_CORTEX_M_HAS_PROGRAMMABLE_FAULT_PRIOS` signifies explicitly
(:kconfig:option:`CONFIG_CPU_CORTEX_M_HAS_PROGRAMMABLE_FAULT_PRIOS` signifies explicitly
that the Cortex-M implementation supports configurable fault priorities.)
This priority level is never shared with HW interrupts (an exception to
@ -255,7 +255,7 @@ HW interrupts in Mainline Cortex-M builds are allocated a priority level lower t
One exception to the above rules is when Zephyr applications support Zero Latency Interrupts
(ZLIs). Such interrupts are designed to have a priority level higher than any HW or system
interrupt. If the ZLI feature is enabled in Mainline Cortex-M builds (see
:kconfig:`CONFIG_ZERO_LATENCY_IRQS`), then
:kconfig:option:`CONFIG_ZERO_LATENCY_IRQS`), then
* ZLIs are assigned the highest configurable priority level
* SVCs are assigned the second highest configurable priority level
@ -278,7 +278,7 @@ priority. While this fulfils the OS requirement of locking interrupts, the conse
is that kernel runtime errors (triggering SVCs) will escalate to HardFault.
In Mainline Cortex-M locking interrupts is implemented using the BASEPRI register (Mainline
Cortex-M builds select :kconfig:`CONFIG_CPU_CORTEX_M_HAS_BASEPRI` to signify that BASEPRI register is
Cortex-M builds select :kconfig:option:`CONFIG_CPU_CORTEX_M_HAS_BASEPRI` to signify that BASEPRI register is
implemented.). By modifying BASEPRI (or BASEPRI_MAX) arch_irq_lock() masks all system and HW
interrupts with the exception of
@ -309,10 +309,10 @@ handling and do not go through all of the common Zephyr interrupt handling
code.
Direct dynamic interrupts are enabled via switching on
:kconfig:`CONFIG_DYNAMIC_DIRECT_INTERRUPTS`.
:kconfig:option:`CONFIG_DYNAMIC_DIRECT_INTERRUPTS`.
Note that enabling direct dynamic interrupts requires enabling support for
dynamic interrupts in the kernel, as well (see :kconfig:`CONFIG_DYNAMIC_INTERRUPTS`).
dynamic interrupts in the kernel, as well (see :kconfig:option:`CONFIG_DYNAMIC_INTERRUPTS`).
Zero Latency interrupts
-----------------------
@ -321,7 +321,7 @@ As described above, in Mainline Cortex-M applications, the Zephyr kernel reserve
the highest configurable interrupt priority level for its own use (SVC). SVCs will
not be masked by interrupt locking. Zero-latency interrupt can be used to set up
an interrupt at the highest interrupt priority which will not be blocked by interrupt
locking. To use the ZLI feature :kconfig:`CONFIG_ZERO_LATENCY_IRQS` needs to be enabled.
locking. To use the ZLI feature :kconfig:option:`CONFIG_ZERO_LATENCY_IRQS` needs to be enabled.
Zero latency IRQs have minimal interrupt latency, as they will always preempt regular HW
or system interrupts.
@ -369,7 +369,7 @@ User mode system calls
User mode is supported in Cortex-M platforms that implement the standard (Arm) MPU
or a similar core peripheral logic for memory access policy configuration and
control, such as the NXP MPU for Kinetis platforms. (Currently,
:kconfig:`CONFIG_ARCH_HAS_USERSPACE` is selected if :kconfig:`CONFIG_ARM_MPU` is enabled
:kconfig:option:`CONFIG_ARCH_HAS_USERSPACE` is selected if :kconfig:option:`CONFIG_ARM_MPU` is enabled
by the user in the board default Kconfig settings).
A thread performs a system call by triggering a (synchronous) SVC exception, where
@ -401,25 +401,25 @@ latency if they occur during a system call preparation.
MPU-assisted stack overflow detection
-------------------------------------
Cortex-M platforms with MPU may enable :kconfig:`CONFIG_MPU_STACK_GUARD` to enable the MPU-based
Cortex-M platforms with MPU may enable :kconfig:option:`CONFIG_MPU_STACK_GUARD` to enable the MPU-based
stack overflow detection mechanism. The following points need to be considered when enabling the
MPU stack guards
* stack overflows are triggering processor faults as soon as they occur
* the mechanism is essential for detecting stack overflows in supervisor threads, or
user threads in privileged mode; stack overflows in threads in user mode will always be
detected regardless of :kconfig:`CONFIG_MPU_STACK_GUARD` being set.
detected regardless of :kconfig:option:`CONFIG_MPU_STACK_GUARD` being set.
* stack overflows are always detected, however, the mechanism does not guarantee that
no memory corruption occurs when supervisor threads overflow their stack memory
* :kconfig:`CONFIG_MPU_STACK_GUARD` will normally reserve one MPU region for programming
the stack guard (in certain Arm v8-M configurations with :kconfig:`CONFIG_MPU_GAP_FILLING`
* :kconfig:option:`CONFIG_MPU_STACK_GUARD` will normally reserve one MPU region for programming
the stack guard (in certain Arm v8-M configurations with :kconfig:option:`CONFIG_MPU_GAP_FILLING`
enabled 2 MPU regions are required to implement the guard feature)
* MPU guards are re-programmed at every context-switch, adding a small overhead to the
thread swap routine. Compared, however, to the :kconfig:`CONFIG_BUILTIN_STACK_GUARD` feature,
thread swap routine. Compared, however, to the :kconfig:option:`CONFIG_BUILTIN_STACK_GUARD` feature,
no re-programming occurs during system calls.
* When :kconfig:`CONFIG_HW_STACK_PROTECTION` is enabled on Arm v8-M platforms the native
* When :kconfig:option:`CONFIG_HW_STACK_PROTECTION` is enabled on Arm v8-M platforms the native
stack limit checking mechanism is used by default instead of the MPU-based stack overflow
detection mechanism; users may override this setting by manually enabling :kconfig:`CONFIG_MPU_STACK_GUARD`
detection mechanism; users may override this setting by manually enabling :kconfig:option:`CONFIG_MPU_STACK_GUARD`
in these scenarios.
Memory map and MPU considerations
@ -428,21 +428,21 @@ Memory map and MPU considerations
Fixed MPU regions
-----------------
By default, when :kconfig:`CONFIG_ARM_MPU` is enabled a set of *fixed* MPU regions
By default, when :kconfig:option:`CONFIG_ARM_MPU` is enabled a set of *fixed* MPU regions
are programmed during system boot.
* One MPU region programs the entire flash area as read-execute.
User can override this setting by enabling :kconfig:`CONFIG_MPU_ALLOW_FLASH_WRITE`,
which programs the flash with RWX permissions. If :kconfig:`CONFIG_USERSPACE` is
User can override this setting by enabling :kconfig:option:`CONFIG_MPU_ALLOW_FLASH_WRITE`,
which programs the flash with RWX permissions. If :kconfig:option:`CONFIG_USERSPACE` is
enabled unprivileged access on the entire flash area is allowed.
* One MPU region programs the entire SRAM area with privileged-only
RW permissions. That is, an MPU region is utilized to disallow execute permissions on
SRAM. (An exception to this setting is when :kconfig:`CONFIG_MPU_GAP_FILLING` is disabled (Arm v8-M only);
SRAM. (An exception to this setting is when :kconfig:option:`CONFIG_MPU_GAP_FILLING` is disabled (Arm v8-M only);
in that case no SRAM MPU programming is done so the access is determined by the default
Arm memory map policies, allowing for privileged-only RWX permissions on SRAM).
The above MPU regions are defined in :file:`soc/arm/common/arm_mpu_regions.c`.
Alternative MPU configurations are allowed by enabling :kconfig:`CONFIG_CPU_HAS_CUSTOM_FIXED_SOC_MPU_REGIONS`.
Alternative MPU configurations are allowed by enabling :kconfig:option:`CONFIG_CPU_HAS_CUSTOM_FIXED_SOC_MPU_REGIONS`.
When enabled, this option signifies that the Cortex-M SoC will define and
configure its own fixed MPU regions in the SoC definition.
@ -452,12 +452,12 @@ Static MPU regions
Additional *static* MPU regions may be programmed once during system boot. These regions
are required to enable certain features
* a RX region to allow execution from SRAM, when :kconfig:`CONFIG_ARCH_HAS_RAMFUNC_SUPPORT` is
* a RX region to allow execution from SRAM, when :kconfig:option:`CONFIG_ARCH_HAS_RAMFUNC_SUPPORT` is
enabled and users have defined functions to execute from SRAM.
* a RX region for relocating text sections to SRAM, when :kconfig:`CONFIG_CODE_DATA_RELOCATION_SRAM` is enabled
* a no-cache region to allow for a none-cacheable SRAM area, when :kconfig:`CONFIG_NOCACHE_MEMORY` is enabled
* a possibly unprivileged RW region for GCOV code coverage accounting area, when :kconfig:`CONFIG_COVERAGE_GCOV` is enabled
* a no-access region to implement null pointer dereference detection, when :kconfig:`CONFIG_NULL_POINTER_EXCEPTION_DETECTION_MPU` is enabled
* a RX region for relocating text sections to SRAM, when :kconfig:option:`CONFIG_CODE_DATA_RELOCATION_SRAM` is enabled
* a no-cache region to allow for a none-cacheable SRAM area, when :kconfig:option:`CONFIG_NOCACHE_MEMORY` is enabled
* a possibly unprivileged RW region for GCOV code coverage accounting area, when :kconfig:option:`CONFIG_COVERAGE_GCOV` is enabled
* a no-access region to implement null pointer dereference detection, when :kconfig:option:`CONFIG_NULL_POINTER_EXCEPTION_DETECTION_MPU` is enabled
The boundaries of these static MPU regions are derived from symbols exposed by the linker, in
:file:`include/linker/linker-defs.h`.
@ -485,15 +485,15 @@ features that require MPU region programming. In most practical applications, ho
only a certain set of features is required and 8 MPU regions are, in many cases, sufficient.
In Arm v8-M processors the MPU architecture does not allow programmed MPU regions to
overlap. :kconfig:`CONFIG_MPU_GAP_FILLING` controls whether the fixed MPU region
overlap. :kconfig:option:`CONFIG_MPU_GAP_FILLING` controls whether the fixed MPU region
covering the entire SRAM is programmed. When it does, a full SRAM area partitioning
is required, in order to program the static and the dynamic MPU regions. This increases
the total number of required MPU regions. When :kconfig:`CONFIG_MPU_GAP_FILLING` is not
the total number of required MPU regions. When :kconfig:option:`CONFIG_MPU_GAP_FILLING` is not
enabled the fixed MPU region convering the entire SRAM is not programmed, thus, the static
and dynamic regions are simply programmed on top of the always-existing background region
(full-SRAM partitioning is not required).
Note, however, that the background SRAM region allows execution from SRAM, so when
:kconfig:`CONFIG_MPU_GAP_FILLING` is not set Zephyr is not protected against attacks
:kconfig:option:`CONFIG_MPU_GAP_FILLING` is not set Zephyr is not protected against attacks
that attempt to execute malicious code from SRAM.
@ -504,8 +504,8 @@ Both unshared and shared FP registers mode are supported in Cortex-M (see
:ref:`float_v2` for more details).
When FPU support is enabled in the build
(:kconfig:`CONFIG_FPU` is enabled), the
sharing FP registers mode (:kconfig:`CONFIG_FPU_SHARING`)
(:kconfig:option:`CONFIG_FPU` is enabled), the
sharing FP registers mode (:kconfig:option:`CONFIG_FPU_SHARING`)
is enabled by default. This is done as some compiler configurations
may activate a floating point context by generating FP instructions
for any thread, regardless of whether floating point calculations are
@ -541,7 +541,7 @@ Chain-loadable images
Cortex-M applications may either be standalone images or chain-loadable, for instance,
by a bootloader. Application images chain-loadable by bootloaders (or other applications)
normally occupy a specific area in the flash denoted as their *code partition*.
:kconfig:`CONFIG_USE_DT_CODE_PARTITION` will ensure that a Zephyr chain-loadable image
:kconfig:option:`CONFIG_USE_DT_CODE_PARTITION` will ensure that a Zephyr chain-loadable image
will be linked into its code partition, specified in DeviceTree.
HW initialization at boot
@ -549,14 +549,14 @@ HW initialization at boot
In order to boot properly, chain-loaded applications may require that the core Arm
hardware registers and peripherals are initialized in their reset values. Enabling
:kconfig:`CONFIG_INIT_ARCH_HW_AT_BOOT` Zephyr to force the initialization of the
:kconfig:option:`CONFIG_INIT_ARCH_HW_AT_BOOT` Zephyr to force the initialization of the
internal Cortex-M architectural state during boot to the reset values as specified
by the corresponding Arm architecture manual.
Software vector relaying
------------------------
In Cortex-M platforms that implement the VTOR register (see :kconfig:`CONFIG_CPU_CORTEX_M_HAS_VTOR`),
In Cortex-M platforms that implement the VTOR register (see :kconfig:option:`CONFIG_CPU_CORTEX_M_HAS_VTOR`),
chain-loadable images relocate the Cortex-M vector table by updating the VTOR register with the offset
of the image vector table.
@ -565,10 +565,10 @@ vector table which remains at a fixed location. Therefore, a chain-loadable imag
require an alternative way to route HW interrupts and system exeptions to its own vector
table; this is achieved with software vector relaying.
When a bootloader image enables :kconfig:`CONFIG_SW_VECTOR_RELAY`
When a bootloader image enables :kconfig:option:`CONFIG_SW_VECTOR_RELAY`
it is able to relay exceptions and interrupts based on a vector table
pointer that is set by the chain-loadable application. The latter sets
the :kconfig:`CONFIG_SW_VECTOR_RELAY_CLIENT` option to instruct the boot
the :kconfig:option:`CONFIG_SW_VECTOR_RELAY_CLIENT` option to instruct the boot
sequence to set the vector table pointer in SRAM so that the bootloader can
forward the exceptions and interrupts to the chain-loadable image's software
vector table.
@ -580,7 +580,7 @@ Code relocation
===============
Cortex-M support the code relocation feature. When
:kconfig:`CONFIG_CODE_DATA_RELOCATION_SRAM` is selected,
:kconfig:option:`CONFIG_CODE_DATA_RELOCATION_SRAM` is selected,
Zephyr will relocate .text, data and .bss sections
from the specified files and place it in SRAM. It is
possible to relocate only parts of the code sections
@ -604,7 +604,7 @@ CMSIS
Cortex-M CMSIS headers are hosted in a standalone module repository:
`zephyrproject-rtos/cmsis <https://github.com/zephyrproject-rtos/cmsis>`_.
:kconfig:`CONFIG_CPU_CORTEX_M` selects :kconfig:`CONFIG_HAS_CMSIS_CORE` to signify that
:kconfig:option:`CONFIG_CPU_CORTEX_M` selects :kconfig:option:`CONFIG_HAS_CMSIS_CORE` to signify that
CMSIS headers are available for all supported Cortex-M variants.
Testing

16
doc/guides/arch/x86.rst
View file

@ -16,12 +16,12 @@ During very early boot, page tables are loaded so technically the kernel
is executing in virtual address space. By default, physical and virtual
memory are identity mapped and thus giving the appearance of execution
taking place in physical address space. The physical address space is
marked by kconfig :kconfig:`CONFIG_SRAM_BASE_ADDRESS` and
:kconfig:`CONFIG_SRAM_SIZE` while the virtual address space is marked by
:kconfig:`CONFIG_KERNEL_VM_BASE` and :kconfig:`CONFIG_KERNEL_VM_SIZE`.
Note that :kconfig:`CONFIG_SRAM_OFFSET` controls where the Zephyr kernel
marked by kconfig :kconfig:option:`CONFIG_SRAM_BASE_ADDRESS` and
:kconfig:option:`CONFIG_SRAM_SIZE` while the virtual address space is marked by
:kconfig:option:`CONFIG_KERNEL_VM_BASE` and :kconfig:option:`CONFIG_KERNEL_VM_SIZE`.
Note that :kconfig:option:`CONFIG_SRAM_OFFSET` controls where the Zephyr kernel
is being placed in the memory, and its counterpart
:kconfig:`CONFIG_KERNEL_VM_OFFSET`.
:kconfig:option:`CONFIG_KERNEL_VM_OFFSET`.
Separate Virtual Address Space from Physical Address Space
==========================================================
@ -53,7 +53,7 @@ There are restrictions on where virtual address space can be:
If they are not disjoint, it would clear the entries needed for
virtual addresses.
- If :kconfig:`CONFIG_X86_PAE` is enabled (``=y``), each address space
- If :kconfig:option:`CONFIG_X86_PAE` is enabled (``=y``), each address space
must reside in their own 1GB region, due to each entry of PDP
(Page Directory Pointer) covers 1GB of memory. For example:
@ -66,7 +66,7 @@ There are restrictions on where virtual address space can be:
- ``CONFIG_SRAM_BASE_ADDRESS == 0x00000000`` and
``CONFIG_KERNEL_VM_BASE = 0x20000000`` is not.
- If :kconfig:`CONFIG_X86_PAE` is disabled (``=n``), each address space
- If :kconfig:option:`CONFIG_X86_PAE` is disabled (``=n``), each address space
must reside in their own 4MB region, due to each entry of PD
(Page Directory) covers 4MB of memory.
@ -117,7 +117,7 @@ The argument ``--map`` takes the following value:
Note that specifying additional memory mappings requires larger storage
space for the pre-allocated page tables (both kernel and per-domain
tables). :kconfig:`CONFIG_X86_EXTRA_PAGE_TABLE_PAGES` is needed to
tables). :kconfig:option:`CONFIG_X86_EXTRA_PAGE_TABLE_PAGES` is needed to
specify how many more memory pages to be reserved for the page tables.
If the needed space is not exactly the same as required space,
the ``gen_mmu.py`` script will print out a message indicating what

28
doc/guides/bluetooth/bluetooth-arch.rst
View file

@ -106,20 +106,20 @@ BLE-enabled builds that can be produced from the Zephyr project codebase:
and responding with events and received data. A build of this type sets the
following Kconfig option values:
* :kconfig:`CONFIG_BT` ``=y``
* :kconfig:`CONFIG_BT_HCI` ``=y``
* :kconfig:`CONFIG_BT_HCI_RAW` ``=y``
* :kconfig:`CONFIG_BT_CTLR` ``=y``
* :kconfig:`CONFIG_BT_LL_SW_SPLIT` ``=y`` (if using the open source Link Layer)
* :kconfig:option:`CONFIG_BT` ``=y``
* :kconfig:option:`CONFIG_BT_HCI` ``=y``
* :kconfig:option:`CONFIG_BT_HCI_RAW` ``=y``
* :kconfig:option:`CONFIG_BT_CTLR` ``=y``
* :kconfig:option:`CONFIG_BT_LL_SW_SPLIT` ``=y`` (if using the open source Link Layer)
* **Host-only build**: A Zephyr OS Host build will contain the Application and
the BLE Host, along with an HCI driver (UART or SPI) to interface with an
external Controller chip.
A build of this type sets the following Kconfig option values:
* :kconfig:`CONFIG_BT` ``=y``
* :kconfig:`CONFIG_BT_HCI` ``=y``
* :kconfig:`CONFIG_BT_CTLR` ``=n``
* :kconfig:option:`CONFIG_BT` ``=y``
* :kconfig:option:`CONFIG_BT_HCI` ``=y``
* :kconfig:option:`CONFIG_BT_CTLR` ``=n``
All of the samples located in ``samples/bluetooth`` except for the ones
used for Controller-only builds can be built as Host-only
@ -128,10 +128,10 @@ BLE-enabled builds that can be produced from the Zephyr project codebase:
Controller, and it is used exclusively for single-chip (SoC) configurations.
A build of this type sets the following Kconfig option values:
* :kconfig:`CONFIG_BT` ``=y``
* :kconfig:`CONFIG_BT_HCI` ``=y``
* :kconfig:`CONFIG_BT_CTLR` ``=y``
* :kconfig:`CONFIG_BT_LL_SW_SPLIT` ``=y`` (if using the open source Link Layer)
* :kconfig:option:`CONFIG_BT` ``=y``
* :kconfig:option:`CONFIG_BT_HCI` ``=y``
* :kconfig:option:`CONFIG_BT_CTLR` ``=y``
* :kconfig:option:`CONFIG_BT_LL_SW_SPLIT` ``=y`` (if using the open source Link Layer)
All of the samples located in ``samples/bluetooth`` except for the ones
used for Controller-only builds can be built as Combined
@ -243,8 +243,8 @@ four distinct roles of BLE usage:
* Observer (scanning for BLE advertisements)
Each role comes with its own build-time configuration option:
:kconfig:`CONFIG_BT_PERIPHERAL`, :kconfig:`CONFIG_BT_CENTRAL`,
:kconfig:`CONFIG_BT_BROADCASTER` & :kconfig:`CONFIG_BT_OBSERVER`. Of the
:kconfig:option:`CONFIG_BT_PERIPHERAL`, :kconfig:option:`CONFIG_BT_CENTRAL`,
:kconfig:option:`CONFIG_BT_BROADCASTER` & :kconfig:option:`CONFIG_BT_OBSERVER`. Of the
connection-oriented roles central implicitly enables observer role, and
peripheral implicitly enables broadcaster role. Usually the first step
when creating an application is to decide which roles are needed and go

6
doc/guides/bluetooth/bluetooth-dev.rst
View file

@ -60,8 +60,8 @@ application:
CONFIG_BT_DEBUG_MONITOR_UART=y
CONFIG_UART_CONSOLE=n
Setting :kconfig:`CONFIG_BT_DEBUG_MONITOR_UART` to ``y`` replaces the
:kconfig:`CONFIG_BT_DEBUG_LOG` option, and setting :kconfig:`CONFIG_UART_CONSOLE`
Setting :kconfig:option:`CONFIG_BT_DEBUG_MONITOR_UART` to ``y`` replaces the
:kconfig:option:`CONFIG_BT_DEBUG_LOG` option, and setting :kconfig:option:`CONFIG_UART_CONSOLE`
to ``n`` disables the default ``printk``/``printf`` hooks.
To decode the binary protocol that will now be sent to the console UART you need
@ -97,7 +97,7 @@ which is comprised of the following devices:
<wrn> bt_hci_core: opcode 0x0c33 status 0x12
when booting your sample of choice (make sure you have enabled
:kconfig:`CONFIG_BT_DEBUG_LOG` in your :file:`prj.conf` before running the
:kconfig:option:`CONFIG_BT_DEBUG_LOG` in your :file:`prj.conf` before running the
sample), or if there is no data flowing from the Controller to the Host, then
you need to disable Host to Controller flow control. To do so, set
``CONFIG_BT_HCI_ACL_FLOW_CONTROL=n`` in your :file:`prj.conf`.

4
doc/guides/build/index.rst
View file

@ -219,7 +219,7 @@ Unfixed size binary
Fixed size binary
The fixed size intermediate binary is produced when :ref:`usermode_api`
is enabled or when generated IRQ tables are used,
:kconfig:`CONFIG_GEN_ISR_TABLES`
:kconfig:option:`CONFIG_GEN_ISR_TABLES`
It produces a binary where sizes are fixed and thus the size must not change
between the intermediate binary and the final binary.
@ -266,7 +266,7 @@ Device dependencies
:figclass: align-center
:width: 80%
When :kconfig:`CONFIG_GEN_ISR_TABLES` is enabled:
When :kconfig:option:`CONFIG_GEN_ISR_TABLES` is enabled:
The *gen_isr_tables.py* script scant the fixed size binary and creates
an isr_tables.c source file with a hardware vector table and/or software
IRQ table.

4
doc/guides/code-relocation.rst
View file

@ -24,7 +24,7 @@ An example of such a string is:
This script is invoked with the following parameters:
``python3 gen_relocate_app.py -i input_string -o generated_linker -c generated_code``
Kconfig :kconfig:`CONFIG_CODE_DATA_RELOCATION` option, when enabled in
Kconfig :kconfig:option:`CONFIG_CODE_DATA_RELOCATION` option, when enabled in
``prj.conf``, will invoke the script and do the required relocation.
This script also trigger the generation of ``linker_relocate.ld`` and
@ -49,7 +49,7 @@ for data copy operations from ROM to required memory type.
**The procedure to invoke this feature is:**
* Enable :kconfig:`CONFIG_CODE_DATA_RELOCATION` in the ``prj.conf`` file
* Enable :kconfig:option:`CONFIG_CODE_DATA_RELOCATION` in the ``prj.conf`` file
* Inside the ``CMakeLists.txt`` file in the project, mention
all the files that need relocation.

8
doc/guides/debug_tools/gdbstub.rst
View file

@ -38,18 +38,18 @@ The following features are supported:
Enabling GDB Stub
*****************
GDB stub can be enabled with the :kconfig:`CONFIG_GDBSTUB` option.
GDB stub can be enabled with the :kconfig:option:`CONFIG_GDBSTUB` option.
Using Serial Backend
====================
The serial backend for GDB stub can be enabled with
the :kconfig:`CONFIG_GDBSTUB_SERIAL_BACKEND` option.
the :kconfig:option:`CONFIG_GDBSTUB_SERIAL_BACKEND` option.
Since serial backend utilizes UART devices to send and receive GDB commands,
* If there are spare UART devices on the board, set
:kconfig:`CONFIG_GDBSTUB_SERIAL_BACKEND_NAME` to the spare UART device
:kconfig:option:`CONFIG_GDBSTUB_SERIAL_BACKEND_NAME` to the spare UART device
so that :c:func:`printk` and log messages are not being printed to
the same UART device used for GDB.
@ -57,7 +57,7 @@ Since serial backend utilizes UART devices to send and receive GDB commands,
must be disabled if they are also using the same UART device for output.
GDB related messages may interleave with log messages which may have
unintended consequences. Usually this can be done by disabling
:kconfig:`CONFIG_PRINTK` and :kconfig:`CONFIG_LOG`.
:kconfig:option:`CONFIG_PRINTK` and :kconfig:option:`CONFIG_LOG`.
Debugging
*********

14
doc/guides/debug_tools/tracing/index.rst
View file

@ -89,7 +89,7 @@ internally and statically at compile-time in the bottom-layer.
The CTF top layer is enabled using the configuration option
:kconfig:`CONFIG_TRACING_CTF` and can be used with the different transport
:kconfig:option:`CONFIG_TRACING_CTF` and can be used with the different transport
backends both in synchronous and asynchronous modes.
@ -105,7 +105,7 @@ transports, for example UART or using snapshot mode (both still not
supported in Zephyr).
To enable tracing support with `SEGGER SystemView`_ add the configuration option
:kconfig:`CONFIG_SEGGER_SYSTEMVIEW` to your project configuration file and set
:kconfig:option:`CONFIG_SEGGER_SYSTEMVIEW` to your project configuration file and set
it to *y*. For example, this can be added to the
:ref:`synchronization_sample` to visualize fast switching between threads.
SystemView can also be used for post-mortem tracing, which can be enabled with
@ -160,7 +160,7 @@ The following functions can be defined by the user:
- ``void sys_trace_isr_exit_user(int nested_interrupts)``
- ``void sys_trace_idle_user()``
Enable this format with the :kconfig:`CONFIG_TRACING_USER` option.
Enable this format with the :kconfig:option:`CONFIG_TRACING_USER` option.
Transport Backends
@ -205,8 +205,8 @@ Using RAM backend
For devices that do not have available I/O for tracing such as USB or UART but have
enough RAM to collect trace datas, the ram backend can be enabled with configuration
:kconfig:`CONFIG_TRACING_BACKEND_RAM`.
Adjust :kconfig:`CONFIG_RAM_TRACING_BUFFER_SIZE` to be able to record enough traces for your needs.
:kconfig:option:`CONFIG_TRACING_BACKEND_RAM`.
Adjust :kconfig:option:`CONFIG_RAM_TRACING_BUFFER_SIZE` to be able to record enough traces for your needs.
Then thanks to a runtime debugger such as gdb this buffer can be fetched from the target
to an host computer::
@ -371,10 +371,10 @@ all initialized mutexes, one can write::
cur = SYS_PORT_TRACK_NEXT(cur);
}
To enable object tracking, enable :kconfig:`CONFIG_TRACING_OBJECT_TRACKING`.
To enable object tracking, enable :kconfig:option:`CONFIG_TRACING_OBJECT_TRACKING`.
Note that each list can be enabled or disabled via their tracing
configuration. For example, to disable tracking of semaphores, one can
disable :kconfig:`CONFIG_TRACING_SEMAPHORE`.
disable :kconfig:option:`CONFIG_TRACING_SEMAPHORE`.
Object tracking is behind tracing configuration as it currently leverages
tracing infrastructure to perform the tracking.

2
doc/guides/device_mgmt/dfu.rst
View file

@ -47,7 +47,7 @@ In order to use MCUboot with Zephyr you need to take the following into account:
};
3. Your application's :file:`.conf` file needs to enable the
:kconfig:`CONFIG_BOOTLOADER_MCUBOOT` Kconfig option in order for Zephyr to
:kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT` Kconfig option in order for Zephyr to
be built in an MCUboot-compatible manner
4. You need to build and flash MCUboot itself on your device
5. You might need to take precautions to avoid mass erasing the flash and also

54
doc/guides/device_mgmt/mcumgr.rst
View file

@ -91,7 +91,7 @@ transport expects a different set of key/value options:
* - ``own_addr_type``
- can be one of ``public``, ``random``, ``rpa_pub``, ``rpa_rnd``, where ``random`` is the default.
* - ``peer_name``
- the name the peer BLE device advertises, this should match the configuration specified with :kconfig:`CONFIG_BT_DEVICE_NAME`.
- the name the peer BLE device advertises, this should match the configuration specified with :kconfig:option:`CONFIG_BT_DEVICE_NAME`.
* - ``peer_id``
- the peer BLE device address or UUID. Only required when ``peer_name`` was not given. The format depends on the OS where ``mcumgr`` is run, it is a 6 bytes hexadecimal string separated by colons on Linux, or a 128-bit UUID on macOS.
* - ``conn_timeout``
@ -106,7 +106,7 @@ transport expects a different set of key/value options:
:widths: 10 60
* - ``addr``
- can be a DNS name (if it can be resolved to the device IP), IPv4 addr (app must be built with :kconfig:`CONFIG_MCUMGR_SMP_UDP_IPV4`), or IPv6 addr (app must be built with :kconfig:`CONFIG_MCUMGR_SMP_UDP_IPV6`)
- can be a DNS name (if it can be resolved to the device IP), IPv4 addr (app must be built with :kconfig:option:`CONFIG_MCUMGR_SMP_UDP_IPV4`), or IPv6 addr (app must be built with :kconfig:option:`CONFIG_MCUMGR_SMP_UDP_IPV6`)
* - ``port``
- any valid UDP port.
@ -169,44 +169,44 @@ on Zephyr. The ones that are supported are described in the following table:
* - ``echo``
- Send data to a device and display the echoed back data. This command is
part of the ``OS`` group, which must be enabled by setting
:kconfig:`CONFIG_MCUMGR_CMD_OS_MGMT`. The ``echo`` command itself can be
enabled by setting :kconfig:`CONFIG_OS_MGMT_ECHO`.
:kconfig:option:`CONFIG_MCUMGR_CMD_OS_MGMT`. The ``echo`` command itself can be
enabled by setting :kconfig:option:`CONFIG_OS_MGMT_ECHO`.
* - ``fs``
- Access files on a device. More info in :ref:`fs_mgmt`.
* - ``image``
- Manage images on a device. More info in :ref:`image_mgmt`.
* - ``reset``
- Perform a soft reset of a device. This command is part of the ``OS``
group, which must be enabled by setting :kconfig:`CONFIG_MCUMGR_CMD_OS_MGMT`.
group, which must be enabled by setting :kconfig:option:`CONFIG_MCUMGR_CMD_OS_MGMT`.
The ``reset`` command itself is always enabled and the time taken for a
reset to happen can be set with :kconfig:`CONFIG_OS_MGMT_RESET_MS` (in ms).
reset to happen can be set with :kconfig:option:`CONFIG_OS_MGMT_RESET_MS` (in ms).
* - ``shell``
- Execute a command in the remote shell. This option is disabled by default
and can be enabled with :kconfig:`CONFIG_MCUMGR_CMD_SHELL_MGMT` = ``y``.
and can be enabled with :kconfig:option:`CONFIG_MCUMGR_CMD_SHELL_MGMT` = ``y``.
To know more about the shell in Zephyr check :ref:`shell_api`.
* - ``stat``
- Read statistics from a device. More info in :ref:`stats_mgmt`.
* - ``taskstat``
- Read task statistics from a device. This command is part of the ``OS``
group, which must be enabled by setting :kconfig:`CONFIG_MCUMGR_CMD_OS_MGMT`.
group, which must be enabled by setting :kconfig:option:`CONFIG_MCUMGR_CMD_OS_MGMT`.
The ``taskstat`` command itself can be enabled by setting
:kconfig:`CONFIG_OS_MGMT_TASKSTAT`. :kconfig:`CONFIG_THREAD_MONITOR` also
:kconfig:option:`CONFIG_OS_MGMT_TASKSTAT`. :kconfig:option:`CONFIG_THREAD_MONITOR` also
needs to be enabled otherwise a ``-8`` (``MGMT_ERR_ENOTSUP``) will be
returned.
.. tip::
``taskstat`` has a few options that might require tweaking. The
:kconfig:`CONFIG_THREAD_NAME` must be set to display the task names, otherwise
:kconfig:option:`CONFIG_THREAD_NAME` must be set to display the task names, otherwise
the priority is displayed. Since the ``taskstat`` packets are large, they
might need increasing the :kconfig:`CONFIG_MCUMGR_BUF_SIZE` option.
might need increasing the :kconfig:option:`CONFIG_MCUMGR_BUF_SIZE` option.
.. warning::
To display the correct stack size in the ``taskstat`` command, the
:kconfig:`CONFIG_THREAD_STACK_INFO` option must be set.
:kconfig:option:`CONFIG_THREAD_STACK_INFO` option must be set.
To display the correct stack usage in the ``taskstat`` command, both
:kconfig:`CONFIG_THREAD_STACK_INFO` and :kconfig:`CONFIG_INIT_STACKS` options
:kconfig:option:`CONFIG_THREAD_STACK_INFO` and :kconfig:option:`CONFIG_INIT_STACKS` options
must be set.
.. _image_mgmt:
@ -261,7 +261,7 @@ To upload a new image::
The ``-e`` option should always be passed in because the ``upload`` command
already checks if an erase is required, respecting the
:kconfig:`CONFIG_IMG_ERASE_PROGRESSIVELY` setting.
:kconfig:option:`CONFIG_IMG_ERASE_PROGRESSIVELY` setting.
.. tip::
@ -379,13 +379,13 @@ directly upgraded to.
.. tip::
The maximum size of a chunk communicated between the client and server is set
with :kconfig:`CONFIG_IMG_MGMT_UL_CHUNK_SIZE`. The default is 512 but can be
with :kconfig:option:`CONFIG_IMG_MGMT_UL_CHUNK_SIZE`. The default is 512 but can be
decreased for systems with low amount of RAM downto 128. When this value is
changed, the ``mtu`` of the port must be smaller than or equal to this value.
.. tip::
Building with :kconfig:`CONFIG_IMG_MGMT_VERBOSE_ERR` enables better error
Building with :kconfig:option:`CONFIG_IMG_MGMT_VERBOSE_ERR` enables better error
messages when failures happen (but increases the application size).
.. _stats_mgmt:
@ -421,7 +421,7 @@ Each entry can be declared with ``STATS_SECT_ENTRY`` (or the equivalent
All statistics in a section must be declared with the same size.
The statistics counters can either have names or not, depending on the setting
of the :kconfig:`CONFIG_STATS_NAMES` option. Using names requires an extra
of the :kconfig:option:`CONFIG_STATS_NAMES` option. Using names requires an extra
declaration step::
STATS_NAME_START(my_stats)
@ -432,13 +432,13 @@ declaration step::
.. tip::
Disabling :kconfig:`CONFIG_STATS_NAMES` will free resources. When this option
Disabling :kconfig:option:`CONFIG_STATS_NAMES` will free resources. When this option
is disabled the ``STATS_NAME*`` macros output nothing, so adding them in the
code does not increase the binary size.
.. tip::
:kconfig:`CONFIG_STAT_MGMT_MAX_NAME_LEN` sets the maximum length of a section
:kconfig:option:`CONFIG_STAT_MGMT_MAX_NAME_LEN` sets the maximum length of a section
name that can can be accepted as parameter for showing the section data, and
might require tweaking for long section names.
@ -471,7 +471,7 @@ To get the current value of the counters in ``my_stats``::
32 my_stat_counter2
48 my_stat_counter3
When :kconfig:`CONFIG_STATS_NAMES` is disabled the output will look like this::
When :kconfig:option:`CONFIG_STATS_NAMES` is disabled the output will look like this::
$ mcumgr --conn acm0 stat my_stats
stat group: my_stats
@ -486,16 +486,16 @@ Filesystem Management
The filesystem module is disabled by default due to security concerns:
because of a lack of access control every file in the FS will be accessible,
including secrets, etc. To enable it :kconfig:`CONFIG_MCUMGR_CMD_FS_MGMT` must
including secrets, etc. To enable it :kconfig:option:`CONFIG_MCUMGR_CMD_FS_MGMT` must
be set (``y``). Once enabled the following sub-commands can be used::
mcumgr <connection-options> fs download <remote-file> <local-file>
mcumgr <connection-options> fs upload <local-file> <remote-file>
Using the ``fs`` command, requires :kconfig:`CONFIG_FILE_SYSTEM` to be enabled,
Using the ``fs`` command, requires :kconfig:option:`CONFIG_FILE_SYSTEM` to be enabled,
and that some particular filesystem is enabled and properly mounted by the running
application, eg for littefs this would mean enabling
:kconfig:`CONFIG_FILE_SYSTEM_LITTLEFS`, defining a storage partition :ref:`flash_map_api`
:kconfig:option:`CONFIG_FILE_SYSTEM_LITTLEFS`, defining a storage partition :ref:`flash_map_api`
and mounting the filesystem in the startup (:c:func:`fs_mount`).
Uploading a new file to a littlefs storage, mounted under ``/lfs``, can be done with::
@ -507,7 +507,7 @@ Uploading a new file to a littlefs storage, mounted under ``/lfs``, can be done
Where ``25`` is the size of the file.
For downloading a file, let's first use the ``fs`` command
(:kconfig:`CONFIG_FILE_SYSTEM_SHELL` must be enabled) in a remote shell to create
(:kconfig:option:`CONFIG_FILE_SYSTEM_SHELL` must be enabled) in a remote shell to create
a new file::
uart:~$ fs write /lfs/bar.txt 41 42 43 44 31 32 33 34 0a
@ -529,16 +529,16 @@ Where ``0`` is the return code, and ``9`` is the size of the file.
.. warning::
The commands might exhaust the system workqueue, if its size is not large
enough, so increasing :kconfig:`CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE` might be
enough, so increasing :kconfig:option:`CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE` might be
required for correct behavior.
The size of the stack allocated buffer used to store the blocks, while transffering
a file can be adjusted with :kconfig:`CONFIG_FS_MGMT_DL_CHUNK_SIZE`; this allows
a file can be adjusted with :kconfig:option:`CONFIG_FS_MGMT_DL_CHUNK_SIZE`; this allows
saving RAM resources.
.. tip::
:kconfig:`CONFIG_FS_MGMT_PATH_SIZE` sets the maximum PATH accepted for a file
:kconfig:option:`CONFIG_FS_MGMT_PATH_SIZE` sets the maximum PATH accepted for a file
name. It might require tweaking for longer file names.
Bootloader integration

6
doc/guides/device_mgmt/ota.rst
View file

@ -73,9 +73,9 @@ Lightweight M2M (LWM2M)
=======================
The :ref:`lwm2m_interface` protocol includes support for firmware update via
:kconfig:`CONFIG_LWM2M_FIRMWARE_UPDATE_OBJ_SUPPORT`. Devices securely connect to
an LwM2M server using DTLS. An :ref:`lwm2m-client-sample` sample is available
but it does not demonstrate the firmware update feature.
:kconfig:option:`CONFIG_LWM2M_FIRMWARE_UPDATE_OBJ_SUPPORT`. Devices securely
connect to an LwM2M server using DTLS. An :ref:`lwm2m-client-sample` sample is
available but it does not demonstrate the firmware update feature.
.. _MCUboot bootloader: https://mcuboot.com/
.. _Golioth: https://golioth.io/

14
doc/guides/flash_debug/host-tools.rst
View file

@ -47,7 +47,7 @@ Flash configuration for devices:
1. Define flash partitions required to accommodate the bootloader and
application image; see :ref:`flash_map_api` for details.
2. Have board :file:`.defconfig` file with the
:kconfig:`CONFIG_USE_DT_CODE_PARTITION` Kconfig option set to ``y`` to
:kconfig:option:`CONFIG_USE_DT_CODE_PARTITION` Kconfig option set to ``y`` to
instruct the build system to use these partitions for code relocation.
This option can also be set in ``prj.conf`` or any other Kconfig fragment.
3. Build and flash the SAM-BA bootloader on the device.
@ -59,20 +59,20 @@ Flash configuration for devices:
1. Define flash partitions required to accommodate the bootloader and
application image; see :ref:`flash_map_api` for details.
2. Have board :file:`.defconfig` file with the
:kconfig:`CONFIG_BOOTLOADER_BOSSA` Kconfig option set to ``y``. This will
automatically select the :kconfig:`CONFIG_USE_DT_CODE_PARTITION` Kconfig
:kconfig:option:`CONFIG_BOOTLOADER_BOSSA` Kconfig option set to ``y``. This will
automatically select the :kconfig:option:`CONFIG_USE_DT_CODE_PARTITION` Kconfig
option which instruct the build system to use these partitions for code
relocation. The board :file:`.defconfig` file should have
:kconfig:`CONFIG_BOOTLOADER_BOSSA_ARDUINO` ,
:kconfig:`CONFIG_BOOTLOADER_BOSSA_ADAFRUIT_UF2` or the
:kconfig:`CONFIG_BOOTLOADER_BOSSA_LEGACY` Kconfig option set to ``y``
:kconfig:option:`CONFIG_BOOTLOADER_BOSSA_ARDUINO` ,
:kconfig:option:`CONFIG_BOOTLOADER_BOSSA_ADAFRUIT_UF2` or the
:kconfig:option:`CONFIG_BOOTLOADER_BOSSA_LEGACY` Kconfig option set to ``y``
to select the right compatible SAM-BA bootloader mode.
These options can also be set in ``prj.conf`` or any other Kconfig fragment.
3. Build and flash the SAM-BA bootloader on the device.
.. note::
The :kconfig:`CONFIG_BOOTLOADER_BOSSA_LEGACY` Kconfig option should be used
The :kconfig:option:`CONFIG_BOOTLOADER_BOSSA_LEGACY` Kconfig option should be used
as last resource. Try configure first with Devices without ROM bootloader.

2
doc/guides/networking/net-stack-architecture.rst
View file

@ -102,7 +102,7 @@ Data receiving (RX)
header and frame check sequence, etc.
4. The packet is processed by a network interface. The network statistics are
collected if enabled by :kconfig:`CONFIG_NET_STATISTICS`.
collected if enabled by :kconfig:option:`CONFIG_NET_STATISTICS`.
5. The packet is then passed to L3 processing. If the packet is IP based,
then the L3 layer checks if the packet is a proper IPv6 or IPv4 packet.

10
doc/guides/networking/net_pkt_processing_stats.rst
View file

@ -13,8 +13,8 @@ statistics inside network stack.
Network stack contains infrastructure to figure out how long the network packet
processing takes either in sending or receiving path. There are two Kconfig
options that control this. For transmit (TX) path the option is called
:kconfig:`CONFIG_NET_PKT_TXTIME_STATS` and for receive (RX) path the options is
called :kconfig:`CONFIG_NET_PKT_RXTIME_STATS`. Note that for TX, all kind of
:kconfig:option:`CONFIG_NET_PKT_TXTIME_STATS` and for receive (RX) path the options is
called :kconfig:option:`CONFIG_NET_PKT_RXTIME_STATS`. Note that for TX, all kind of
network packet statistics is collected. For RX, only UDP, TCP or raw packet
type network packet statistics is collected.
@ -35,10 +35,10 @@ when it was sent to the network. The RX time tells the time from its creation
to when it was passed to the application. The values are in microseconds. The
statistics will be collected per traffic class if there are more than one
transmit or receive queues defined in the system. These are controlled by
:kconfig:`CONFIG_NET_TC_TX_COUNT` and :kconfig:`CONFIG_NET_TC_RX_COUNT` options.
:kconfig:option:`CONFIG_NET_TC_TX_COUNT` and :kconfig:option:`CONFIG_NET_TC_RX_COUNT` options.
If you enable :kconfig:`CONFIG_NET_PKT_TXTIME_STATS_DETAIL` or
:kconfig:`CONFIG_NET_PKT_RXTIME_STATS_DETAIL` options, then additional
If you enable :kconfig:option:`CONFIG_NET_PKT_TXTIME_STATS_DETAIL` or
:kconfig:option:`CONFIG_NET_PKT_RXTIME_STATS_DETAIL` options, then additional
information for TX or RX network packets are collected when the network packet
traverses the IP stack.

6
doc/guides/networking/qemu_setup.rst
View file

@ -154,8 +154,8 @@ board is connected to a dedicated router, it should not be needed.
To access the internet from a Zephyr application using IPv4,
a gateway should be set via DHCP or configured manually.
For applications using the "Settings" facility (with the config option
:kconfig:`CONFIG_NET_CONFIG_SETTINGS` enabled),
set the :kconfig:`CONFIG_NET_CONFIG_MY_IPV4_GW` option to the IP address
:kconfig:option:`CONFIG_NET_CONFIG_SETTINGS` enabled),
set the :kconfig:option:`CONFIG_NET_CONFIG_MY_IPV4_GW` option to the IP address
of the gateway. For apps not using the "Settings" facility, set up the
gateway by calling the :c:func:`net_if_ipv4_set_gw` at runtime.
@ -188,7 +188,7 @@ on Debian-based systems:
An alternative to relying on the host's DNS server is to use one in the
network. For example, 8.8.8.8 is a publicly available DNS server. You can
configure it using :kconfig:`CONFIG_DNS_SERVER1` option.
configure it using :kconfig:option:`CONFIG_DNS_SERVER1` option.
Network connection between two QEMU VMs

14
doc/guides/optimizations/footprint.rst
View file

@ -11,19 +11,19 @@ usage in different scenarios on as many supported platforms as possible. You
should start the optimization process by reviewing all stack sizes and adjusting
them for your application:
:kconfig:`CONFIG_ISR_STACK_SIZE`
:kconfig:option:`CONFIG_ISR_STACK_SIZE`
Set to 2048 by default
:kconfig:`CONFIG_MAIN_STACK_SIZE`
:kconfig:option:`CONFIG_MAIN_STACK_SIZE`
Set to 1024 by default
:kconfig:`CONFIG_IDLE_STACK_SIZE`
:kconfig:option:`CONFIG_IDLE_STACK_SIZE`
Set to 320 by default
:kconfig:`CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE`
:kconfig:option:`CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE`
Set to 1024 by default
:kconfig:`CONFIG_PRIVILEGED_STACK_SIZE`
:kconfig:option:`CONFIG_PRIVILEGED_STACK_SIZE`
Set to 1024 by default, depends on userspace feature.
@ -43,10 +43,10 @@ Various Debug/Informational Options
The following options are enabled by default to provide more information about
the running application and to provide means for debugging and error handling:
:kconfig:`CONFIG_BOOT_BANNER`
:kconfig:option:`CONFIG_BOOT_BANNER`
This option can be disabled to save a few bytes.
:kconfig:`CONFIG_DEBUG`
:kconfig:option:`CONFIG_DEBUG`
This option can be disabled for production builds

2
doc/guides/optimizations/tools.rst
View file

@ -38,7 +38,7 @@ Then:
To view worst-case stack usage analysis, build this with the
:kconfig:`CONFIG_STACK_USAGE` enabled.
:kconfig:option:`CONFIG_STACK_USAGE` enabled.
.. zephyr-app-commands::
:tool: all

6
doc/guides/pinctrl/index.rst
View file

@ -153,7 +153,7 @@ In most situations, the states defined in Devicetree will be the ones used in
the compiled firmware. However, there are some cases where certain states will
be conditionally used depending on a compilation flag. A typical case is the
``sleep`` state. This state is only used in practice if
:kconfig:`CONFIG_PM_DEVICE` is enabled. If a firmware variant without device
:kconfig:option:`CONFIG_PM_DEVICE` is enabled. If a firmware variant without device
power management is needed, one should in theory remove the ``sleep`` state from
Devicetree to not waste ROM space storing such unused state.
@ -177,7 +177,7 @@ Dynamic pin control refers to the capability of changing pin configuration
at runtime. This feature can be useful in situations where the same firmware
needs to run onto slightly different boards, each having a peripheral routed at
a different set of pins. This feature can be enabled by setting
:kconfig:`CONFIG_PINCTRL_DYNAMIC`.
:kconfig:option:`CONFIG_PINCTRL_DYNAMIC`.
.. note::
@ -369,7 +369,7 @@ Pin control drivers
Pin control drivers need to implement a single function:
:c:func:`pinctrl_configure_pins`. This function receives an array of pin
configurations that need to be applied. Furthermore, if
:kconfig:`CONFIG_PINCTRL_STORE_REG` is set, it also receives the associated
:kconfig:option:`CONFIG_PINCTRL_STORE_REG` is set, it also receives the associated
device register address for the given pins. This information may be required by
some drivers to perform device specific actions.

2
doc/guides/pm/device.rst
View file

@ -140,6 +140,6 @@ Power Domain
Power domain on Zephyr is represented as a regular device. The power management
subsystem ensures that a domain is resumed before and suspended after devices
using it. When :kconfig:`CONFIG_PM_DEVICE_RUNTIME` is enabled, every time a
using it. When :kconfig:option:`CONFIG_PM_DEVICE_RUNTIME` is enabled, every time a
device is suspended or resumed the same action is done in the domain the
device belongs.

2
doc/guides/pm/device_runtime.rst
View file

@ -7,7 +7,7 @@ Introduction
The device runtime power management (PM) framework is an active power management
mechanism which reduces the overall system power consumtion by suspending the
devices which are idle or not used independently of the system state. It can be
enabled by setting :kconfig:`CONFIG_PM_DEVICE_RUNTIME`. In this model the device
enabled by setting :kconfig:option:`CONFIG_PM_DEVICE_RUNTIME`. In this model the device
driver is responsible to indicate when it needs the device and when it does not.
This information is used to determine when to suspend or resume a device based
on usage count.

2
doc/guides/pm/power_domain.rst
View file

@ -11,7 +11,7 @@ that device B is on the same power domain and should also be configured into a
low power state.
Power domains are optional on Zephyr, to enable this feature the
option :kconfig:`CONFIG_PM_DEVICE_POWER_DOMAIN` has to be set.
option :kconfig:option:`CONFIG_PM_DEVICE_POWER_DOMAIN` has to be set.
When a power domain turns itself on or off, it is the responsibilty of the
power domain to notify all devices using it through their power management

2
doc/guides/pm/system.rst
View file

@ -2,7 +2,7 @@ System Power Management
#######################
The kernel enters the idle state when it has nothing to schedule. If enabled via
the :kconfig:`CONFIG_PM` Kconfig option, the Power Management
the :kconfig:option:`CONFIG_PM` Kconfig option, the Power Management
Subsystem can put an idle system in one of the supported power states, based
on the selected power management policy and the duration of the idle time
allotted by the kernel.

36
doc/guides/porting/arch.rst
View file

@ -137,7 +137,7 @@ parameter.
executing. A common interrupt handler demuxer is installed for all entries of
the real interrupt vector table, which then fetches the device's ISR and
parameter from the separate table. This approach is commonly used in the ARC
and ARM architectures via the :kconfig:`CONFIG_GEN_ISR_TABLES` implementation.
and ARM architectures via the :kconfig:option:`CONFIG_GEN_ISR_TABLES` implementation.
You can find examples of the stubs by looking at :code:`_interrupt_enter()` in
x86, :code:`_IntExit()` in ARM, :code:`_isr_wrapper()` in ARM, or the full
implementation description for ARC in :zephyr_file:`arch/arc/core/isr_wrapper.S`.
@ -266,7 +266,7 @@ to stack corruption.
.. note::
If running a coop-only system, i.e. if :kconfig:`CONFIG_NUM_PREEMPT_PRIORITIES`
If running a coop-only system, i.e. if :kconfig:option:`CONFIG_NUM_PREEMPT_PRIORITIES`
is 0, no preemptive context switch ever happens. The interrupt code can be
optimized to not take any scheduling decision when this is the case.
@ -298,7 +298,7 @@ gracefully exits its entry point function.
This means implementing an architecture-specific version of
:c:func:`k_thread_abort`, and setting the Kconfig option
:kconfig:`CONFIG_ARCH_HAS_THREAD_ABORT` as needed for the architecture (e.g. see
:kconfig:option:`CONFIG_ARCH_HAS_THREAD_ABORT` as needed for the architecture (e.g. see
:zephyr_file:`arch/arm/core/aarch32/cortex_m/Kconfig`).
Thread Local Storage
@ -378,7 +378,7 @@ port, since it is so useful for debugging. It is a simple polling, output-only,
serial port driver on which to send the console (:code:`printk`,
:code:`printf`) output.
It is not required, and a RAM console (:kconfig:`CONFIG_RAM_CONSOLE`)
It is not required, and a RAM console (:kconfig:option:`CONFIG_RAM_CONSOLE`)
can be used to send all output to a circular buffer that can be read
by a debugger instead.
@ -392,13 +392,13 @@ expected to be implemented as part of an architecture port.
* Atomic operators.
* If instructions do exist for a given architecture, the implementation is
configured using the :kconfig:`CONFIG_ATOMIC_OPERATIONS_ARCH` Kconfig
configured using the :kconfig:option:`CONFIG_ATOMIC_OPERATIONS_ARCH` Kconfig
option.
* If instructions do not exist for a given architecture,
a generic version that wraps :c:func:`irq_lock` or :c:func:`irq_unlock`
around non-atomic operations exists. It is configured using the
:kconfig:`CONFIG_ATOMIC_OPERATIONS_C` Kconfig option.
:kconfig:option:`CONFIG_ATOMIC_OPERATIONS_C` Kconfig option.
* Find-least-significant-bit-set and find-most-significant-bit-set.
@ -471,7 +471,7 @@ Memory Management
*****************
If the target platform enables paging and requires drivers to memory-map
their I/O regions, :kconfig:`CONFIG_MMU` needs to be enabled and the
their I/O regions, :kconfig:option:`CONFIG_MMU` needs to be enabled and the
:c:func:`arch_mem_map` API implemented.
Stack Objects
@ -494,7 +494,7 @@ Two types of thread stacks exist:
- "thread" stacks which typically use more memory, but are capable of hosting
thread running in user mode, as well as any use-cases for kernel stacks.
If :kconfig:`CONFIG_USERSPACE` is not enabled, "thread" and "kernel" stacks are
If :kconfig:option:`CONFIG_USERSPACE` is not enabled, "thread" and "kernel" stacks are
equivalent.
Additional macros may be defined in the architecture layer to specify
@ -573,17 +573,17 @@ of the system after this happens:
it's possible to overshoot the guard and corrupt adjacent data structures
before the hardware detects this situation.
To enable the :kconfig:`CONFIG_HW_STACK_PROTECTION` feature, the system must
To enable the :kconfig:option:`CONFIG_HW_STACK_PROTECTION` feature, the system must
provide some kind of hardware-based stack overflow protection, and enable the
:kconfig:`CONFIG_ARCH_HAS_STACK_PROTECTION` option.
:kconfig:option:`CONFIG_ARCH_HAS_STACK_PROTECTION` option.
Two forms of HW-based stack overflow detection are supported: dedicated
CPU features for this purpose, or special read-only guard regions immediately
preceding stack buffers.
:kconfig:`CONFIG_HW_STACK_PROTECTION` only catches stack overflows for
:kconfig:option:`CONFIG_HW_STACK_PROTECTION` only catches stack overflows for
supervisor threads. This is not required to catch stack overflow from user
threads; :kconfig:`CONFIG_USERSPACE` is orthogonal.
threads; :kconfig:option:`CONFIG_USERSPACE` is orthogonal.
This feature only detects supervisor mode stack overflows, including stack
overflows when handling system calls. It doesn't guarantee that the kernel has
@ -592,7 +592,7 @@ a fatal error, with no assertions about the integrity of the overall system
possible.
Stack overflows in user mode are recoverable (from the kernel's perspective)
and require no special configuration; :kconfig:`CONFIG_HW_STACK_PROTECTION`
and require no special configuration; :kconfig:option:`CONFIG_HW_STACK_PROTECTION`
only applies to catching overflows when the CPU is in sueprvisor mode.
CPU-based stack overflow detection
@ -651,7 +651,7 @@ User mode enabled
Enabling user mode activates two new requirements:
* A separate fixed-sized privilege mode stack, specified by
:kconfig:`CONFIG_PRIVILEGED_STACK_SIZE`, must be allocated that the user
:kconfig:option:`CONFIG_PRIVILEGED_STACK_SIZE`, must be allocated that the user
thread cannot access. It is used as the stack by the kernel when handling
system calls. If stack guards are implemented, a stack guard region must
be able to be placed before it, with support for carve-outs if necessary.
@ -666,7 +666,7 @@ Enabling user mode activates two new requirements:
This becomes more complicated if the memory protection hardware requires that
all memory regions be sized to a power of two, and aligned to their own size.
This is common on older MPUs and is known with
:kconfig:`CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT`.
:kconfig:option:`CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT`.
``thread.stack_info`` always tracks the user-accessible part of the stack
object, it must always be correct to program a memory protection region with
@ -731,7 +731,7 @@ privilege elevation stack must be allocated elsewhere.
:c:macro:`ARCH_THREAD_STACK_OBJ_ALIGN()` should both be defined to
:c:macro:`Z_POW2_CEIL()`. :c:macro:`K_THREAD_STACK_RESERVED` must be 0.
For the privilege stacks, the :kconfig:`CONFIG_GEN_PRIV_STACKS` must be,
For the privilege stacks, the :kconfig:option:`CONFIG_GEN_PRIV_STACKS` must be,
enabled. For every thread stack found in the system, a corresponding fixed-
size kernel stack used for handling system calls is generated. The address
of the privilege stacks can be looked up quickly at runtime based on the
@ -767,7 +767,7 @@ User Mode Threads
*****************
To support user mode threads, several kernel-to-arch APIs need to be
implemented, and the system must enable the :kconfig:`CONFIG_ARCH_HAS_USERSPACE`
implemented, and the system must enable the :kconfig:option:`CONFIG_ARCH_HAS_USERSPACE`
option. Please see the documentation for each of these functions for more
details:
@ -795,7 +795,7 @@ details:
Some architectures may need to update software memory management structures
or modify hardware registers on another CPU when memory domain APIs are invoked.
If so, :kconfig:`CONFIG_ARCH_MEM_DOMAIN_SYNCHRONOUS_API` must be selected by the
If so, :kconfig:option:`CONFIG_ARCH_MEM_DOMAIN_SYNCHRONOUS_API` must be selected by the
architecture and some additional APIs must be implemented. This is common
on MMU systems and uncommon on MPU systems:

6
doc/guides/smf/index.rst
View file

@ -9,7 +9,7 @@ Overview
The State Machine Framework (SMF) is an application agnostic framework that
provides an easy way for developers to integrate state machines into their
application. The framework can be added to any project by enabling the
:kconfig:`CONFIG_SMF` option.
:kconfig:option:`CONFIG_SMF` option.
State Creation
==============
@ -35,14 +35,14 @@ use ``SMF_CTX(&user_obj)``.
By default, a state can have no anscestor states, resulting in a flat state
machine. But to enable the creation of a hierarchical state machine, the
:kconfig:`CONFIG_SMF_ANCESTOR_SUPPORT` option must be enabled.
:kconfig:option:`CONFIG_SMF_ANCESTOR_SUPPORT` option must be enabled.
The following macro can be used for easy state creation:
* :c:macro:`SMF_CREATE_STATE` Create a state
**NOTE:** The :c:macro:`SMF_CREATE_STATE` macro takes an additional parameter
when :kconfig:`CONFIG_SMF_ANCESTOR_SUPPORT` is enabled.
when :kconfig:option:`CONFIG_SMF_ANCESTOR_SUPPORT` is enabled.
State Machine Creation
======================

6
doc/guides/test/coverage.rst
View file

@ -36,10 +36,10 @@ device has enough RAM when enabling the coverage for it. For example a small dev
like frdm_k64f can run a simple test application but the more complex test
cases which consume more RAM will crash when coverage is enabled.
To enable the device for coverage, select :kconfig:`CONFIG_HAS_COVERAGE_SUPPORT`
To enable the device for coverage, select :kconfig:option:`CONFIG_HAS_COVERAGE_SUPPORT`
in the Kconfig.board file.
To report the coverage for the particular test application set :kconfig:`CONFIG_COVERAGE`.
To report the coverage for the particular test application set :kconfig:option:`CONFIG_COVERAGE`.
Steps to generate code coverage reports
=======================================
@ -100,7 +100,7 @@ That means you can use the same tools you would while developing any
other desktop application.
To build your application with ``gcc``'s `gcov`_, simply set
:kconfig:`CONFIG_COVERAGE` before compiling it.
:kconfig:option:`CONFIG_COVERAGE` before compiling it.
When you run your application, ``gcov`` coverage data will be dumped into the
respective ``gcda`` and ``gcno`` files.
You may postprocess these with your preferred tools. For example:

6
doc/guides/test/ztest.rst
View file

@ -464,9 +464,9 @@ Mocking
These functions allow abstracting callbacks and related functions and
controlling them from specific tests. You can enable the mocking framework by
setting :kconfig:`CONFIG_ZTEST_MOCKING` to "y" in the configuration file of the
setting :kconfig:option:`CONFIG_ZTEST_MOCKING` to "y" in the configuration file of the
test. The amount of concurrent return values and expected parameters is
limited by :kconfig:`CONFIG_ZTEST_PARAMETER_COUNT`.
limited by :kconfig:option:`CONFIG_ZTEST_PARAMETER_COUNT`.
Here is an example for configuring the function ``expect_two_parameters`` to
expect the values ``a=2`` and ``b=3``, and telling ``returns_int`` to return
@ -483,7 +483,7 @@ Customizing Test Output
The way output is presented when running tests can be customized.
An example can be found in :zephyr_file:`tests/ztest/custom_output`.
Customization is enabled by setting :kconfig:`CONFIG_ZTEST_TC_UTIL_USER_OVERRIDE` to "y"
Customization is enabled by setting :kconfig:option:`CONFIG_ZTEST_TC_UTIL_USER_OVERRIDE` to "y"
and adding a file :file:`tc_util_user_override.h` with your overrides.
Add the line ``zephyr_include_directories(my_folder)`` to

8
doc/guides/tfm/build.rst
View file

@ -53,7 +53,7 @@ the properties.
Signing Images
**************
When :kconfig:`CONFIG_TFM_BL2` is set to ``y``, TF-M uses a secure bootloader
When :kconfig:option:`CONFIG_TFM_BL2` is set to ``y``, TF-M uses a secure bootloader
(BL2) and firmware images must be signed with a private key. The firmware image
is validated by the bootloader during updates using the corresponding public
key, which is stored inside the secure bootloader firmware image.
@ -61,8 +61,8 @@ key, which is stored inside the secure bootloader firmware image.
By default, ``<tfm-dir>/bl2/ext/mcuboot/root-rsa-3072.pem`` is used to sign secure
images, and ``<tfm-dir>/bl2/ext/mcuboot/root-rsa-3072_1.pem`` is used to sign
non-secure images. Theses default .pem keys can (and **should**) be overridden
using the :kconfig:`CONFIG_TFM_KEY_FILE_S` and
:kconfig:`CONFIG_TFM_KEY_FILE_NS` config flags.
using the :kconfig:option:`CONFIG_TFM_KEY_FILE_S` and
:kconfig:option:`CONFIG_TFM_KEY_FILE_NS` config flags.
To satisfy `PSA Certified Level 1`_ requirements, **You MUST replace
the default .pem file with a new key pair!**
@ -76,7 +76,7 @@ To generate a new public/private key pair, run the following commands:
You can then place the new .pem files in an alternate location, such as your
Zephyr application folder, and reference them in the ``prj.conf`` file via the
:kconfig:`CONFIG_TFM_KEY_FILE_S` and :kconfig:`CONFIG_TFM_KEY_FILE_NS` config
:kconfig:option:`CONFIG_TFM_KEY_FILE_S` and :kconfig:option:`CONFIG_TFM_KEY_FILE_NS` config
flags.
.. warning::

10
doc/guides/tfm/integration.rst
View file

@ -10,7 +10,7 @@ Board Definitions
*****************
TF-M will be built for the secure processing environment along with Zephyr if
the :kconfig:`CONFIG_BUILD_WITH_TFM` flag is set to ``y``.
the :kconfig:option:`CONFIG_BUILD_WITH_TFM` flag is set to ``y``.
Generally, this value should never be set at the application level, however,
and all config flags required for TF-M should be set in a board variant with
@ -18,7 +18,7 @@ the ``_ns`` suffix.
This board variant must define an appropriate flash, SRAM and peripheral
configuration that takes into account the initialisation process in the secure
processing environment. :kconfig:`CONFIG_TFM_BOARD` must also be set via
processing environment. :kconfig:option:`CONFIG_TFM_BOARD` must also be set via
`modules/trusted-firmware-m/Kconfig.tfm <https://github.com/zephyrproject-rtos/zephyr/blob/main/modules/trusted-firmware-m/Kconfig.tfm>`__
to the board name that TF-M expects for this target, so that it knows which
target to build for the secure processing environment.
@ -34,8 +34,8 @@ kconfig flags that indicate that Zephyr should be built as a
non-secure image, linked with TF-M as an external project, and optionally the
secure bootloader:
* :kconfig:`CONFIG_TRUSTED_EXECUTION_NONSECURE` ``y``
* :kconfig:`CONFIG_ARM_TRUSTZONE_M` ``y``
* :kconfig:option:`CONFIG_TRUSTED_EXECUTION_NONSECURE` ``y``
* :kconfig:option:`CONFIG_ARM_TRUSTZONE_M` ``y``
Comparing the ``mps2_an521.dts`` and ``mps2_an521_ns.dts`` files, we can see
that the ``_ns`` version defines offsets in flash and SRAM memory, which leave
@ -84,4 +84,4 @@ This matches the flash memory layout we see in ``flash_layout.h`` in TF-M:
* 0x0030_A000 Unused (984 KB)
``mps2/an521`` will be passed in to Tf-M as the board target, specified via
:kconfig:`CONFIG_TFM_BOARD`.
:kconfig:option:`CONFIG_TFM_BOARD`.

10
doc/guides/tfm/overview.rst
View file

@ -137,7 +137,7 @@ to you.
duplication between services.
The current isolation level can be checked via
:kconfig:`CONFIG_TFM_ISOLATION_LEVEL`.
:kconfig:option:`CONFIG_TFM_ISOLATION_LEVEL`.
Secure Boot
===========
@ -174,9 +174,9 @@ When dealing with (optionally) encrypted images:
Key config properties to control secure boot in Zephyr are:
* :kconfig:`CONFIG_TFM_BL2` toggles the bootloader (default = ``y``).
* :kconfig:`CONFIG_TFM_KEY_FILE_S` overrides the secure signing key.
* :kconfig:`CONFIG_TFM_KEY_FILE_NS` overrides the non-secure signing key.
* :kconfig:option:`CONFIG_TFM_BL2` toggles the bootloader (default = ``y``).
* :kconfig:option:`CONFIG_TFM_KEY_FILE_S` overrides the secure signing key.
* :kconfig:option:`CONFIG_TFM_KEY_FILE_NS` overrides the non-secure signing key.
Secure Processing Environment
=============================
@ -260,7 +260,7 @@ Non-Secure Processing Environment
=================================
Zephyr is used for the NSPE, using a board that is supported by TF-M where the
:kconfig:`CONFIG_BUILD_WITH_TFM` flag has been enabled.
:kconfig:option:`CONFIG_BUILD_WITH_TFM` flag has been enabled.
Generally, you simply need to select the ``*_ns`` variant of a valid target
(for example ``mps2_an521_ns``), which will configure your Zephyr application

2
doc/guides/tfm/requirements.rst
View file

@ -33,7 +33,7 @@ The following are some of the boards that can be used with TF-M:
You can run ``west boards -n _ns$`` to search for non-secure variants
of different board targets. To make sure TF-M is supported for a board
in its output, check that :kconfig:`CONFIG_TRUSTED_EXECUTION_NONSECURE`
in its output, check that :kconfig:option:`CONFIG_TRUSTED_EXECUTION_NONSECURE`
is set to ``y`` in that board's default configuration.
Software Requirements

8
doc/guides/west/sign.rst
View file

@ -44,13 +44,13 @@ Notes on the above commands:
For more information on these and other related configuration options, see:
- :kconfig:`CONFIG_BOOTLOADER_MCUBOOT`: build the application for loading by
- :kconfig:option:`CONFIG_BOOTLOADER_MCUBOOT`: build the application for loading by
MCUboot
- :kconfig:`CONFIG_MCUBOOT_SIGNATURE_KEY_FILE`: the key file to use with ``west
- :kconfig:option:`CONFIG_MCUBOOT_SIGNATURE_KEY_FILE`: the key file to use with ``west
sign``. If you have your own key, change this appropriately
- :kconfig:`CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS`: optional additional command line
- :kconfig:option:`CONFIG_MCUBOOT_EXTRA_IMGTOOL_ARGS`: optional additional command line
arguments for ``imgtool``
- :kconfig:`CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE`: also generate a confirmed
- :kconfig:option:`CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE`: also generate a confirmed
image, which may be more useful for flashing in production environments than
the OTA-able default image
- On Windows, if you get "Access denied" issues, the recommended fix is

4
doc/reference/api/design_guidelines.rst
View file

@ -71,8 +71,8 @@ Conditional Data and APIs
APIs and libraries may provide features that are expensive in RAM or
code size but are optional in the sense that some applications can be
implemented without them. Examples of such feature include
:kconfig:`capturing a timestamp <CONFIG_CAN_RX_TIMESTAMP>` or
:kconfig:`providing an alternative interface <CONFIG_SPI_ASYNC>`. The
:kconfig:option:`capturing a timestamp <CONFIG_CAN_RX_TIMESTAMP>` or
:kconfig:option:`providing an alternative interface <CONFIG_SPI_ASYNC>`. The
developer in coordination with the community must determine whether
enabling the features is to be controllable through a Kconfig option.

2
doc/reference/audio/codec.rst
View file

@ -13,7 +13,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_AUDIO_CODEC`
* :kconfig:option:`CONFIG_AUDIO_CODEC`
API Reference
*************

2
doc/reference/audio/dmic.rst
View file

@ -13,7 +13,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_AUDIO_DMIC`
* :kconfig:option:`CONFIG_AUDIO_DMIC`
API Reference
*************

2
doc/reference/audio/i2s.rst
View file

@ -16,7 +16,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_I2S`
* :kconfig:option:`CONFIG_I2S`
API Reference
*************

4
doc/reference/bluetooth/gatt.rst
View file

@ -58,7 +58,7 @@ the data has been transmitted over the air. Indications are supported by
:c:func:`bt_gatt_indicate` API.
Client procedures can be enabled with the configuration option:
:kconfig:`CONFIG_BT_GATT_CLIENT`
:kconfig:option:`CONFIG_BT_GATT_CLIENT`
Discover procedures can be initiated with the use of
:c:func:`bt_gatt_discover` API which takes the
@ -73,7 +73,7 @@ to NULL allows all attributes to be discovered.
Read procedures are supported by :c:func:`bt_gatt_read` API which takes the
:c:struct:`bt_gatt_read_params` struct as parameters. In the parameters one or
more attributes can be set, though setting multiple handles requires the option:
:kconfig:`CONFIG_BT_GATT_READ_MULTIPLE`
:kconfig:option:`CONFIG_BT_GATT_READ_MULTIPLE`
Write procedures are supported by :c:func:`bt_gatt_write` API and takes
:c:struct:`bt_gatt_write_params` struct as parameters. In case the write

2
doc/reference/bluetooth/l2cap.rst
View file

@ -4,7 +4,7 @@ Logical Link Control and Adaptation Protocol (L2CAP)
####################################################
L2CAP layer enables connection-oriented channels which can be enable with the
configuration option: :kconfig:`CONFIG_BT_L2CAP_DYNAMIC_CHANNEL`. This channels
configuration option: :kconfig:option:`CONFIG_BT_L2CAP_DYNAMIC_CHANNEL`. This channels
support segmentation and reassembly transparently, they also support credit
based flow control making it suitable for data streams.

6
doc/reference/bluetooth/mesh/access.rst
View file

@ -56,7 +56,7 @@ messages on. Only messages encrypted with application keys in the AppKey list
will be passed to the model.
The maximum number of supported application keys each model can hold is
configured with the :kconfig:`CONFIG_BT_MESH_MODEL_KEY_COUNT` configuration
configured with the :kconfig:option:`CONFIG_BT_MESH_MODEL_KEY_COUNT` configuration
option. The contents of the AppKey list is managed by the
:ref:`bluetooth_mesh_models_cfg_srv`.
@ -70,7 +70,7 @@ virtual address in its subscription list. This allows nodes to address
multiple nodes throughout the mesh network with a single message.
The maximum number of supported addresses in the Subscription list each model
can hold is configured with the :kconfig:`CONFIG_BT_MESH_MODEL_GROUP_COUNT`
can hold is configured with the :kconfig:option:`CONFIG_BT_MESH_MODEL_GROUP_COUNT`
configuration option. The contents of the subscription list is managed by the
:ref:`bluetooth_mesh_models_cfg_srv`.
@ -132,7 +132,7 @@ relationships between the models must be defined by the model implementations.
The model extension concept adds some overhead in the access layer packet
processing, and must be explicitly enabled with
:kconfig:`CONFIG_BT_MESH_MODEL_EXTENSIONS` to have any effect.
:kconfig:option:`CONFIG_BT_MESH_MODEL_EXTENSIONS` to have any effect.
Model data storage
==================

2
doc/reference/bluetooth/mesh/core.rst
View file

@ -19,7 +19,7 @@ The radio control and polling is managed automatically by the mesh stack, but
the LPN API allows the application to trigger the polling at any time through
:c:func:`bt_mesh_lpn_poll`. The LPN operation parameters, including poll
interval, poll event timing and Friend requirements is controlled through the
:kconfig:`CONFIG_BT_MESH_LOW_POWER` option and related configuration options.
:kconfig:option:`CONFIG_BT_MESH_LOW_POWER` option and related configuration options.
Replay Protection List
**********************

2
doc/reference/bluetooth/mesh/provisioning.rst
View file

@ -101,7 +101,7 @@ mechanism. In this case, a new key pair will be generated by the mesh stack
for each Provisioning process.
To enable support of OOB public key on the unprovisioned device side,
:kconfig:`CONFIG_BT_MESH_PROV_OOB_PUBLIC_KEY` needs to be enabled. The
:kconfig:option:`CONFIG_BT_MESH_PROV_OOB_PUBLIC_KEY` needs to be enabled. The
application must provide public and private keys before the Provisioning
process is started by initializing pointers to
:c:member:`bt_mesh_prov.public_key_be`

2
doc/reference/bluetooth/mesh/proxy.rst
View file

@ -5,7 +5,7 @@ Proxy
The Proxy feature allows legacy devices like phones to access the Bluetooth
mesh network through GATT. The Proxy feature is only compiled in if the
:kconfig:`CONFIG_BT_MESH_GATT_PROXY` option is set. The Proxy feature state is
:kconfig:option:`CONFIG_BT_MESH_GATT_PROXY` option is set. The Proxy feature state is
controlled by the :ref:`bluetooth_mesh_models_cfg_srv`, and the initial value
can be set with :c:member:`bt_mesh_cfg_srv.gatt_proxy`.

8
doc/reference/bluetooth/mesh/shell.rst
View file

@ -305,7 +305,7 @@ Provisioning
Proxy Client
============
The Proxy Client model is an optional mesh subsystem that can be enabled through the :kconfig:`CONFIG_BT_MESH_PROXY_CLIENT` configuration option.
The Proxy Client model is an optional mesh subsystem that can be enabled through the :kconfig:option:`CONFIG_BT_MESH_PROXY_CLIENT` configuration option.
``mesh proxy-connect <NetKeyIndex>``
------------------------------------
@ -327,7 +327,7 @@ The Proxy Client model is an optional mesh subsystem that can be enabled through
Configuration Client model
==========================
The Configuration Client model is an optional mesh subsystem that can be enabled through the :kconfig:`CONFIG_BT_MESH_CFG_CLI` configuration option. If included, the Bluetooth mesh shell module instantiates a Configuration Client model for configuring itself and other nodes in the mesh network.
The Configuration Client model is an optional mesh subsystem that can be enabled through the :kconfig:option:`CONFIG_BT_MESH_CFG_CLI` configuration option. If included, the Bluetooth mesh shell module instantiates a Configuration Client model for configuring itself and other nodes in the mesh network.
The Configuration Client uses the general messages parameters set by ``mesh dst`` and ``mesh netidx`` to target specific nodes. When the Bluetooth mesh shell node is provisioned, the Configuration Client model targets itself by default. When another node has been provisioned by the Bluetooth mesh shell, the Configuration Client model targets the new node. The Configuration Client always sends messages using the Device key bound to the destination address, so it will only be able to configure itself and mesh nodes it provisioned.
@ -697,7 +697,7 @@ The Configuration Client uses the general messages parameters set by ``mesh dst`
Health Client model
===================
The Health Client model is an optional mesh subsystem that can be enabled through the :kconfig:`CONFIG_BT_MESH_HEALTH_CLI` configuration option. If included, the Bluetooth mesh shell module instantiates a Health Client model for configuring itself and other nodes in the mesh network.
The Health Client model is an optional mesh subsystem that can be enabled through the :kconfig:option:`CONFIG_BT_MESH_HEALTH_CLI` configuration option. If included, the Bluetooth mesh shell module instantiates a Health Client model for configuring itself and other nodes in the mesh network.
The Health Client uses the general messages parameters set by ``mesh dst`` and ``mesh netidx`` to target specific nodes. When the Bluetooth mesh shell node is provisioned, the Health Client model targets itself by default. When another node has been provisioned by the Bluetooth mesh shell, the Health Client model targets the new node. The Health Client always sends messages using the Device key bound to the destination address, so it will only be able to configure itself and mesh nodes it provisioned.
@ -809,7 +809,7 @@ Health Server model
Configuration database
======================
The Configuration database is an optional mesh subsystem that can be enabled through the :kconfig:`CONFIG_BT_MESH_CDB` configuration option. The Configuration database is only available on provisioner devices, and allows them to store all information about the mesh network. To avoid conflicts, there should only be one mesh node in the network with the Configuration database enabled. This node is the Configurator, and is responsible for adding new nodes to the network and configuring them.
The Configuration database is an optional mesh subsystem that can be enabled through the :kconfig:option:`CONFIG_BT_MESH_CDB` configuration option. The Configuration database is only available on provisioner devices, and allows them to store all information about the mesh network. To avoid conflicts, there should only be one mesh node in the network with the Configuration database enabled. This node is the Configurator, and is responsible for adding new nodes to the network and configuring them.
``mesh cdb-create [NetKey]``
----------------------------

2
doc/reference/data_structures/ring_buffers.rst
View file

@ -377,7 +377,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_RING_BUFFER`: Enable ring buffer.
* :kconfig:option:`CONFIG_RING_BUFFER`: Enable ring buffer.
API Reference
*************

4
doc/reference/devicetree/api.rst
View file

@ -374,7 +374,7 @@ device.
- A device which can be used as a system-wide entropy source
* - zephyr,flash
- A node whose ``reg`` is sometimes used to set the defaults for
:kconfig:`CONFIG_FLASH_BASE_ADDRESS` and :kconfig:`CONFIG_FLASH_SIZE`
:kconfig:option:`CONFIG_FLASH_BASE_ADDRESS` and :kconfig:option:`CONFIG_FLASH_SIZE`
* - zephyr,flash-controller
- The node corresponding to the flash controller device for
the ``zephyr,flash`` node
@ -401,7 +401,7 @@ device.
* - zephyr,uart-mcumgr
- UART used for :ref:`device_mgmt`
* - zephyr,uart-pipe
- Sets default :kconfig:`CONFIG_UART_PIPE_ON_DEV_NAME`
- Sets default :kconfig:option:`CONFIG_UART_PIPE_ON_DEV_NAME`
* - zephyr,usb-device
- USB device node. If defined and has a ``vbus-gpios`` property, these
will be used by the USB subsystem to enable/disable VBUS

2
doc/reference/kernel/data_passing/mailboxes.rst
View file

@ -629,7 +629,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_NUM_MBOX_ASYNC_MSGS`
* :kconfig:option:`CONFIG_NUM_MBOX_ASYNC_MSGS`
API Reference
*************

2
doc/reference/kernel/data_passing/stacks.rst
View file

@ -34,7 +34,7 @@ The value is given directly to a waiting thread, if one exists;
otherwise the value is added to the LIFO's queue.
.. note::
If :kconfig:`CONFIG_NO_RUNTIME_CHECKS` is enabled, the kernel will *not* detect
If :kconfig:option:`CONFIG_NO_RUNTIME_CHECKS` is enabled, the kernel will *not* detect
and prevent attempts to add a data value to a stack that has already reached
its maximum quantity of queued values. Adding a data value to a stack that is
already full will result in array overflow, and lead to unpredictable behavior.

6
doc/reference/kernel/memory/heap.rst
View file

@ -92,7 +92,7 @@ complete within 1-200 cycles. One complexity is that the search of
the minimum bucket size for an allocation (the set of free blocks that
"might fit") has a compile-time upper bound of iterations to prevent
unbounded list searches, at the expense of some fragmentation
resistance. This :kconfig:`CONFIG_SYS_HEAP_ALLOC_LOOPS` value may be
resistance. This :kconfig:option:`CONFIG_SYS_HEAP_ALLOC_LOOPS` value may be
chosen by the user at build time, and defaults to a value of 3.
Multi-Heap Wrapper Utility
@ -158,7 +158,7 @@ Defining the Heap Memory Pool
=============================
The size of the heap memory pool is specified using the
:kconfig:`CONFIG_HEAP_MEM_POOL_SIZE` configuration option.
:kconfig:option:`CONFIG_HEAP_MEM_POOL_SIZE` configuration option.
By default, the heap memory pool size is zero bytes. This value instructs
the kernel not to define the heap memory pool object. The maximum size is limited
@ -212,7 +212,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_HEAP_MEM_POOL_SIZE`
* :kconfig:option:`CONFIG_HEAP_MEM_POOL_SIZE`
API Reference
=============

2
doc/reference/kernel/memory/slabs.rst
View file

@ -145,7 +145,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_MEM_SLAB_TRACE_MAX_UTILIZATION`
* :kconfig:option:`CONFIG_MEM_SLAB_TRACE_MAX_UTILIZATION`
API Reference
*************

6
doc/reference/kernel/other/atomic.rst
View file

@ -107,9 +107,9 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_ATOMIC_OPERATIONS_BUILTIN`
* :kconfig:`CONFIG_ATOMIC_OPERATIONS_ARCH`
* :kconfig:`CONFIG_ATOMIC_OPERATIONS_C`
* :kconfig:option:`CONFIG_ATOMIC_OPERATIONS_BUILTIN`
* :kconfig:option:`CONFIG_ATOMIC_OPERATIONS_ARCH`
* :kconfig:option:`CONFIG_ATOMIC_OPERATIONS_C`
API Reference
*************

12
doc/reference/kernel/other/fatal.rst
View file

@ -20,7 +20,7 @@ conditionally compiled. Their definitions may be found in
Assertions are enabled by setting the ``__ASSERT_ON`` preprocessor symbol to a
non-zero value. There are two ways to do this:
- Use the :kconfig:`CONFIG_ASSERT` and :kconfig:`CONFIG_ASSERT_LEVEL` kconfig
- Use the :kconfig:option:`CONFIG_ASSERT` and :kconfig:option:`CONFIG_ASSERT_LEVEL` kconfig
options.
- Add ``-D__ASSERT_ON=<level>`` to the project's CFLAGS, either on the
build command line or in a CMakeLists.txt.
@ -34,7 +34,7 @@ issued since assertion code is not normally present in a final product.
Specifying assertion level 2 suppresses these warnings.
Assertions are enabled by default when running Zephyr test cases, as
configured by the :kconfig:`CONFIG_TEST` option.
configured by the :kconfig:option:`CONFIG_TEST` option.
The policy for what to do when encountering a failed assertion is controlled
by the implementation of :c:func:`assert_post_action`. Zephyr provides
@ -198,9 +198,9 @@ addresses outside of the stack buffer. Because this is enforced by the
memory protection hardware, there is no risk of data corruption to memory
that the thread would not otherwise be able to write to.
If a thread is running in supervisor mode, or if :kconfig:`CONFIG_USERSPACE` is
If a thread is running in supervisor mode, or if :kconfig:option:`CONFIG_USERSPACE` is
not enabled, depending on configuration stack overflows may or may not be
caught. :kconfig:`CONFIG_HW_STACK_PROTECTION` is supported on some
caught. :kconfig:option:`CONFIG_HW_STACK_PROTECTION` is supported on some
architectures and will catch stack overflows in supervisor mode, including
when handling a system call on behalf of a user thread. Typically this is
implemented via dedicated CPU features, or read-only MMU/MPU guard regions
@ -210,7 +210,7 @@ should be treated as a very serious condition impacting the health of the
entire system.
If a platform lacks memory management hardware support,
:kconfig:`CONFIG_STACK_SENTINEL` is a software-only stack overflow detection
:kconfig:option:`CONFIG_STACK_SENTINEL` is a software-only stack overflow detection
feature which periodically checks if a sentinel value at the end of the stack
buffer has been corrupted. It does not require hardware support, but provides
no protection against data corruption. Since the checks are typically done at
@ -218,7 +218,7 @@ interrupt exit, the overflow may be detected a nontrivial amount of time after
the stack actually overflowed.
Finally, Zephyr supports GCC compiler stack canaries via
:kconfig:`CONFIG_STACK_CANARIES`. If enabled, the compiler will insert a canary
:kconfig:option:`CONFIG_STACK_CANARIES`. If enabled, the compiler will insert a canary
value randomly generated at boot into function stack frames, checking that the
canary has not been overwritten at function exit. If the check fails, the
compiler invokes :c:func:`__stack_chk_fail()`, whose Zephyr implementation

16
doc/reference/kernel/other/float.rst
View file

@ -238,13 +238,13 @@ the switched-out thread. Floating point registers are saved on the thread's
stack. Floating point registers are restored when a thread context is restored
iff they were saved at the context save. Saving and restoring of the floating
point registers is synchronous and thus not lazy. The FPU is always disabled
when an ISR is called (independent of :kconfig:`CONFIG_FPU_SHARING`).
when an ISR is called (independent of :kconfig:option:`CONFIG_FPU_SHARING`).
Floating point disabling with :c:func:`k_float_disable` is not implemented.
When :kconfig:`CONFIG_FPU_SHARING` is used, then 136 bytes of stack space
When :kconfig:option:`CONFIG_FPU_SHARING` is used, then 136 bytes of stack space
is required for each FPU user thread to load and store floating point
registers. No extra stack is required if :kconfig:`CONFIG_FPU_SHARING` is
registers. No extra stack is required if :kconfig:option:`CONFIG_FPU_SHARING` is
not used.
x86 architecture
@ -335,17 +335,17 @@ perform floating point operations.
Configuration Options
*********************
To configure unshared FP registers mode, enable the :kconfig:`CONFIG_FPU`
configuration option and leave the :kconfig:`CONFIG_FPU_SHARING` configuration
To configure unshared FP registers mode, enable the :kconfig:option:`CONFIG_FPU`
configuration option and leave the :kconfig:option:`CONFIG_FPU_SHARING` configuration
option disabled.
To configure shared FP registers mode, enable both the :kconfig:`CONFIG_FPU`
configuration option and the :kconfig:`CONFIG_FPU_SHARING` configuration option.
To configure shared FP registers mode, enable both the :kconfig:option:`CONFIG_FPU`
configuration option and the :kconfig:option:`CONFIG_FPU_SHARING` configuration option.
Also, ensure that any thread that uses the floating point registers has
sufficient added stack space for saving floating point register values
during context switches, as described above.
For x86, use the :kconfig:`CONFIG_X86_SSE` configuration option to enable
For x86, use the :kconfig:option:`CONFIG_X86_SSE` configuration option to enable
support for SSEx instructions.
API Reference

18
doc/reference/kernel/other/interrupts.rst
View file

@ -67,9 +67,9 @@ through the use of one or more nested interrupt controllers. Sources of
hardware interrupts are combined into one line that is then routed to
the parent controller.
If nested interrupt controllers are supported, :kconfig:`CONFIG_MULTI_LEVEL_INTERRUPTS`
should be set to 1, and :kconfig:`CONFIG_2ND_LEVEL_INTERRUPTS` and
:kconfig:`CONFIG_3RD_LEVEL_INTERRUPTS` configured as well, based on the
If nested interrupt controllers are supported, :kconfig:option:`CONFIG_MULTI_LEVEL_INTERRUPTS`
should be set to 1, and :kconfig:option:`CONFIG_2ND_LEVEL_INTERRUPTS` and
:kconfig:option:`CONFIG_3RD_LEVEL_INTERRUPTS` configured as well, based on the
hardware architecture.
A unique 32-bit interrupt number is assigned with information
@ -173,7 +173,7 @@ The kernel addresses such use-cases by allowing interrupts with critical
latency constraints to execute at a priority level that cannot be blocked
by interrupt locking. These interrupts are defined as
*zero-latency interrupts*. The support for zero-latency interrupts requires
:kconfig:`CONFIG_ZERO_LATENCY_IRQS` to be enabled. In addition to that, the
:kconfig:option:`CONFIG_ZERO_LATENCY_IRQS` to be enabled. In addition to that, the
flag :c:macro:`IRQ_ZERO_LATENCY` must be passed to :c:macro:`IRQ_CONNECT` or
:c:macro:`IRQ_DIRECT_CONNECT` macros to configure the particular interrupt
with zero latency.
@ -270,7 +270,7 @@ possible to install interrupts at runtime with
...
}
Dynamic interrupts require the :kconfig:`CONFIG_DYNAMIC_INTERRUPTS` option to
Dynamic interrupts require the :kconfig:option:`CONFIG_DYNAMIC_INTERRUPTS` option to
be enabled. Removing or re-configuring a dynamic interrupt is currently
unsupported.
@ -377,7 +377,7 @@ argument is ignored.
Vector Table
------------
A vector table is generated when :kconfig:`CONFIG_GEN_IRQ_VECTOR_TABLE` is
A vector table is generated when :kconfig:option:`CONFIG_GEN_IRQ_VECTOR_TABLE` is
enabled. This data structure is used natively by the CPU and is simply an
array of function pointers, where each element n corresponds to the IRQ handler
for IRQ line n, and the function pointers are:
@ -394,7 +394,7 @@ for IRQ line n, and the function pointers are:
Some architectures (such as the Nios II internal interrupt controller) have a
common entry point for all interrupts and do not support a vector table, in
which case the :kconfig:`CONFIG_GEN_IRQ_VECTOR_TABLE` option should be
which case the :kconfig:option:`CONFIG_GEN_IRQ_VECTOR_TABLE` option should be
disabled.
Some architectures may reserve some initial vectors for system exceptions
@ -450,7 +450,7 @@ to program the IRQ-to-vector association in the interrupt controller.
For dynamic interrupts, the build must generate some 4-byte dynamic interrupt
stubs, one stub per dynamic interrupt in use. The number of stubs is controlled
by the :kconfig:`CONFIG_X86_DYNAMIC_IRQ_STUBS` option. Each stub pushes an
by the :kconfig:option:`CONFIG_X86_DYNAMIC_IRQ_STUBS` option. Each stub pushes an
unique identifier which is then used to fetch the appropriate handler function
and parameter out of a table populated when the dynamic interrupt was
connected.
@ -471,7 +471,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_ISR_STACK_SIZE`
* :kconfig:option:`CONFIG_ISR_STACK_SIZE`
Additional architecture-specific and device-specific configuration options
also exist.

2
doc/reference/kernel/other/polling.rst
View file

@ -289,7 +289,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_POLL`
* :kconfig:option:`CONFIG_POLL`
API Reference
*************

8
doc/reference/kernel/other/thread_local_storage.rst
View file

@ -13,15 +13,15 @@ Zephyr currently requires toolchain support for TLS.
Configuration
*************
To enable thread local storage in Zephyr, :kconfig:`CONFIG_THREAD_LOCAL_STORAGE`
To enable thread local storage in Zephyr, :kconfig:option:`CONFIG_THREAD_LOCAL_STORAGE`
needs to be enabled. Note that this option may not be available if
the architecture or the SoC does not have the hidden option
:kconfig:`CONFIG_ARCH_HAS_THREAD_LOCAL_STORAGE` enabled, which means
:kconfig:option:`CONFIG_ARCH_HAS_THREAD_LOCAL_STORAGE` enabled, which means
the architecture or the SoC does not have the necessary code to support
thread local storage and/or the toolchain does not support TLS.
:kconfig:`CONFIG_ERRNO_IN_TLS` can be enabled together with
:kconfig:`CONFIG_ERRNO` to let the variable ``errno`` be a thread local
:kconfig:option:`CONFIG_ERRNO_IN_TLS` can be enabled together with
:kconfig:option:`CONFIG_ERRNO` to let the variable ``errno`` be a thread local
variable. This allows user threads to access the value of ``errno`` without
making a system call.

16
doc/reference/kernel/scheduling/index.rst
View file

@ -41,7 +41,7 @@ exist, the scheduler chooses the one that has been waiting longest.
A thread's relative priority is primarily determined by its static priority.
However, when both earliest-deadline-first scheduling is enabled
(:kconfig:`CONFIG_SCHED_DEADLINE`) and a choice of threads have equal
(:kconfig:option:`CONFIG_SCHED_DEADLINE`) and a choice of threads have equal
static priority, then the thread with the earlier deadline is considered
to have the higher priority. Thus, when earliest-deadline-first scheduling is
enabled, two threads are only considered to have the same priority when both
@ -59,7 +59,7 @@ The kernel can be built with one of several choices for the ready queue
implementation, offering different choices between code size, constant factor
runtime overhead and performance scaling when many threads are added.
* Simple linked-list ready queue (:kconfig:`CONFIG_SCHED_DUMB`)
* Simple linked-list ready queue (:kconfig:option:`CONFIG_SCHED_DUMB`)
The scheduler ready queue will be implemented as a simple unordered list, with
very fast constant time performance for single threads and very low code size.
@ -68,7 +68,7 @@ runtime overhead and performance scaling when many threads are added.
the queue at any given time. On most platforms (that are not otherwise using
the red/black tree) this results in a savings of ~2k of code size.
* Red/black tree ready queue (:kconfig:`CONFIG_SCHED_SCALABLE`)
* Red/black tree ready queue (:kconfig:option:`CONFIG_SCHED_SCALABLE`)
The scheduler ready queue will be implemented as a red/black tree. This has
rather slower constant-time insertion and removal overhead, and on most
@ -79,7 +79,7 @@ runtime overhead and performance scaling when many threads are added.
Use this for applications needing many concurrent runnable threads (> 20 or
so). Most applications won't need this ready queue implementation.
* Traditional multi-queue ready queue (:kconfig:`CONFIG_SCHED_MULTIQ`)
* Traditional multi-queue ready queue (:kconfig:option:`CONFIG_SCHED_MULTIQ`)
When selected, the scheduler ready queue will be implemented as the
classic/textbook array of lists, one per priority (max 32 priorities).
@ -102,17 +102,17 @@ The wait_q abstraction used in IPC primitives to pend threads for later wakeup
shares the same backend data structure choices as the scheduler, and can use
the same options.
* Scalable wait_q implementation (:kconfig:`CONFIG_WAITQ_SCALABLE`)
* Scalable wait_q implementation (:kconfig:option:`CONFIG_WAITQ_SCALABLE`)
When selected, the wait_q will be implemented with a balanced tree. Choose
this if you expect to have many threads waiting on individual primitives.
There is a ~2kb code size increase over :kconfig:`CONFIG_WAITQ_DUMB` (which may
be shared with :kconfig:`CONFIG_SCHED_SCALABLE`) if the red/black tree is not
There is a ~2kb code size increase over :kconfig:option:`CONFIG_WAITQ_DUMB` (which may
be shared with :kconfig:option:`CONFIG_SCHED_SCALABLE`) if the red/black tree is not
used elsewhere in the application, and pend/unpend operations on "small"
queues will be somewhat slower (though this is not generally a performance
path).
* Simple linked-list wait_q (:kconfig:`CONFIG_WAITQ_DUMB`)
* Simple linked-list wait_q (:kconfig:option:`CONFIG_WAITQ_DUMB`)
When selected, the wait_q will be implemented with a doubly-linked list.
Choose this if you expect to have only a few threads blocked on any single

14
doc/reference/kernel/smp/smp.rst
View file

@ -13,12 +13,12 @@ No special application code needs to be written to take advantage of
this feature. If there are two Zephyr application threads runnable on
a supported dual processor device, they will both run simultaneously.
SMP configuration is controlled under the :kconfig:`CONFIG_SMP` kconfig
SMP configuration is controlled under the :kconfig:option:`CONFIG_SMP` kconfig
variable. This must be set to "y" to enable SMP features, otherwise
a uniprocessor kernel will be built. In general the platform default
will have enabled this anywhere it's supported. When enabled, the
number of physical CPUs available is visible at build time as
:kconfig:`CONFIG_MP_NUM_CPUS`. Likewise, the default for this will be the
:kconfig:option:`CONFIG_MP_NUM_CPUS`. Likewise, the default for this will be the
number of available CPUs on the platform and it is not expected that
typical apps will change it. But it is legal and supported to set
this to a smaller (but obviously not larger) number for special
@ -99,7 +99,7 @@ CPU Mask
It is often desirable for real time applications to deliberately
partition work across physical CPUs instead of relying solely on the
kernel scheduler to decide on which threads to execute. Zephyr
provides an API, controlled by the :kconfig:`CONFIG_SCHED_CPU_MASK`
provides an API, controlled by the :kconfig:option:`CONFIG_SCHED_CPU_MASK`
kconfig variable, which can associate a specific set of CPUs with each
thread, indicating on which CPUs it can run.
@ -116,9 +116,9 @@ Note that when this feature is enabled, the scheduler algorithm
involved in doing the per-CPU mask test requires that the list be
traversed in full. The kernel does not keep a per-CPU run queue.
That means that the performance benefits from the
:kconfig:`CONFIG_SCHED_SCALABLE` and :kconfig:`CONFIG_SCHED_MULTIQ`
:kconfig:option:`CONFIG_SCHED_SCALABLE` and :kconfig:option:`CONFIG_SCHED_MULTIQ`
scheduler backends cannot be realized. CPU mask processing is
available only when :kconfig:`CONFIG_SCHED_DUMB` is the selected
available only when :kconfig:option:`CONFIG_SCHED_DUMB` is the selected
backend. This requirement is enforced in the configuration layer.
SMP Boot Process
@ -293,8 +293,8 @@ run from the scheduler, passing in an "interrupted" handle reflecting
the same opaque type used by switch, which the kernel will then save
in the interrupted thread struct.
Note that while SMP requires :kconfig:`CONFIG_USE_SWITCH`, the reverse is not
true. A uniprocessor architecture built with :kconfig:`CONFIG_SMP` set to No might
Note that while SMP requires :kconfig:option:`CONFIG_USE_SWITCH`, the reverse is not
true. A uniprocessor architecture built with :kconfig:option:`CONFIG_SMP` set to No might
still decide to implement its context switching using
:c:func:`arch_switch`.

2
doc/reference/kernel/synchronization/events.rst
View file

@ -164,7 +164,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_EVENTS`
* :kconfig:option:`CONFIG_EVENTS`
API Reference
**************

4
doc/reference/kernel/synchronization/mutexes.rst
View file

@ -71,7 +71,7 @@ the unlocking thread resets its priority to the level it had before locking
that mutex.
.. note::
The :kconfig:`CONFIG_PRIORITY_CEILING` configuration option limits
The :kconfig:option:`CONFIG_PRIORITY_CEILING` configuration option limits
how high the kernel can raise a thread's priority due to priority
inheritance. The default value of 0 permits unlimited elevation.
@ -159,7 +159,7 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_PRIORITY_CEILING`
* :kconfig:option:`CONFIG_PRIORITY_CEILING`
API Reference
*************

48
doc/reference/kernel/threads/index.rst
View file

@ -47,7 +47,7 @@ A thread has the following key properties:
By default, threads run in supervisor mode and allow access to
privileged CPU instructions, the entire memory address space, and
peripherals. User mode threads have a reduced set of privileges.
This depends on the :kconfig:`CONFIG_USERSPACE` option. See :ref:`usermode_api`.
This depends on the :kconfig:option:`CONFIG_USERSPACE` option. See :ref:`usermode_api`.
.. _lifecycle_v2:
@ -250,13 +250,13 @@ a cooperative thread, and vice versa, by changing its priority.
Thread priorities are set and changed only at the application's request.
The kernel supports a virtually unlimited number of thread priority levels.
The configuration options :kconfig:`CONFIG_NUM_COOP_PRIORITIES` and
:kconfig:`CONFIG_NUM_PREEMPT_PRIORITIES` specify the number of priority
The configuration options :kconfig:option:`CONFIG_NUM_COOP_PRIORITIES` and
:kconfig:option:`CONFIG_NUM_PREEMPT_PRIORITIES` specify the number of priority
levels for each class of thread, resulting in the following usable priority
ranges:
* cooperative threads: (-:kconfig:`CONFIG_NUM_COOP_PRIORITIES`) to -1
* preemptive threads: 0 to (:kconfig:`CONFIG_NUM_PREEMPT_PRIORITIES` - 1)
* cooperative threads: (-:kconfig:option:`CONFIG_NUM_COOP_PRIORITIES`) to -1
* preemptive threads: 0 to (:kconfig:option:`CONFIG_NUM_PREEMPT_PRIORITIES` - 1)
.. image:: priorities.svg
:align: center
@ -269,7 +269,7 @@ results in the ranges -5 to -1 and 0 to 9, respectively.
Meta-IRQ Priorities
===================
When enabled (see :kconfig:`CONFIG_NUM_METAIRQ_PRIORITIES`), there is a special
When enabled (see :kconfig:option:`CONFIG_NUM_METAIRQ_PRIORITIES`), there is a special
subclass of cooperative priorities at the highest (numerically lowest)
end of the priority space: meta-IRQ threads. These are scheduled
according to their normal priority, but also have the special ability
@ -338,12 +338,12 @@ The following thread options are supported.
of this register when scheduling the thread.
:c:macro:`K_USER`
If :kconfig:`CONFIG_USERSPACE` is enabled, this thread will be created in
If :kconfig:option:`CONFIG_USERSPACE` is enabled, this thread will be created in
user mode and will have reduced privileges. See :ref:`usermode_api`. Otherwise
this flag does nothing.
:c:macro:`K_INHERIT_PERMS`
If :kconfig:`CONFIG_USERSPACE` is enabled, this thread will inherit all
If :kconfig:option:`CONFIG_USERSPACE` is enabled, this thread will inherit all
kernel object permissions that the parent thread had, except the parent
thread object. See :ref:`usermode_api`.
@ -362,7 +362,7 @@ it chooses. The default custom data value for a thread is zero.
within a single shared kernel interrupt handling context.
By default, thread custom data support is disabled. The configuration option
:kconfig:`CONFIG_THREAD_CUSTOM_DATA` can be used to enable support.
:kconfig:option:`CONFIG_THREAD_CUSTOM_DATA` can be used to enable support.
The :c:func:`k_thread_custom_data_set` and
:c:func:`k_thread_custom_data_get` functions are used to write and read
@ -468,7 +468,7 @@ The following code has the same effect as the code segment above.
User Mode Constraints
---------------------
This section only applies if :kconfig:`CONFIG_USERSPACE` is enabled, and a user
This section only applies if :kconfig:option:`CONFIG_USERSPACE` is enabled, and a user
thread tries to create a new thread. The :c:func:`k_thread_create` API is
still used, but there are additional constraints which must be met or the
calling thread will be terminated:
@ -494,7 +494,7 @@ calling thread will be terminated:
Dropping Permissions
====================
If :kconfig:`CONFIG_USERSPACE` is enabled, a thread running in supervisor mode
If :kconfig:option:`CONFIG_USERSPACE` is enabled, a thread running in supervisor mode
may perform a one-way transition to user mode using the
:c:func:`k_thread_user_mode_enter` API. This is a one-way operation which
will reset and zero the thread's stack memory. The thread will be marked
@ -522,20 +522,20 @@ The following code illustrates the ways a thread can terminate.
/* thread terminates at end of entry point function */
}
If :kconfig:`CONFIG_USERSPACE` is enabled, aborting a thread will additionally
If :kconfig:option:`CONFIG_USERSPACE` is enabled, aborting a thread will additionally
mark the thread and stack objects as uninitialized so that they may be re-used.
Runtime Statistics
******************
Thread runtime statistics can be gathered and retrieved if
:kconfig:`CONFIG_THREAD_RUNTIME_STATS` is enabled, for example, total number of
:kconfig:option:`CONFIG_THREAD_RUNTIME_STATS` is enabled, for example, total number of
execution cycles of a thread.
By default, the runtime statistics are gathered using the default kernel
timer. For some architectures, SoCs or boards, there are timers with higher
resolution available via timing functions. Using of these timers can be
enabled via :kconfig:`CONFIG_THREAD_RUNTIME_STATS_USE_TIMING_FUNCTIONS`.
enabled via :kconfig:option:`CONFIG_THREAD_RUNTIME_STATS_USE_TIMING_FUNCTIONS`.
Here is an example:
@ -561,16 +561,16 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_MAIN_THREAD_PRIORITY`
* :kconfig:`CONFIG_MAIN_STACK_SIZE`
* :kconfig:`CONFIG_IDLE_STACK_SIZE`
* :kconfig:`CONFIG_THREAD_CUSTOM_DATA`
* :kconfig:`CONFIG_NUM_COOP_PRIORITIES`
* :kconfig:`CONFIG_NUM_PREEMPT_PRIORITIES`
* :kconfig:`CONFIG_TIMESLICING`
* :kconfig:`CONFIG_TIMESLICE_SIZE`
* :kconfig:`CONFIG_TIMESLICE_PRIORITY`
* :kconfig:`CONFIG_USERSPACE`
* :kconfig:option:`CONFIG_MAIN_THREAD_PRIORITY`
* :kconfig:option:`CONFIG_MAIN_STACK_SIZE`
* :kconfig:option:`CONFIG_IDLE_STACK_SIZE`
* :kconfig:option:`CONFIG_THREAD_CUSTOM_DATA`
* :kconfig:option:`CONFIG_NUM_COOP_PRIORITIES`
* :kconfig:option:`CONFIG_NUM_PREEMPT_PRIORITIES`
* :kconfig:option:`CONFIG_TIMESLICING`
* :kconfig:option:`CONFIG_TIMESLICE_SIZE`
* :kconfig:option:`CONFIG_TIMESLICE_PRIORITY`
* :kconfig:option:`CONFIG_USERSPACE`

18
doc/reference/kernel/threads/nothread.rst
View file

@ -10,7 +10,7 @@ Thread support is not necessary in some applications:
* Examples intended to demonstrate core functionality
Thread support can be disabled in Zephyr by setting
:kconfig:`CONFIG_MULTITHREADING` to ``n``. Since this configuration has
:kconfig:option:`CONFIG_MULTITHREADING` to ``n``. Since this configuration has
a significant impact on Zephyr's functionality and testing of it has
been limited, there are conditions on what can be expected to work in
this configuration.
@ -19,7 +19,7 @@ What Can be Expected to Work
****************************
These core capabilities shall function correctly when
:kconfig:`CONFIG_MULTITHREADING` is disabled:
:kconfig:option:`CONFIG_MULTITHREADING` is disabled:
* The :ref:`build system <application>`
@ -42,12 +42,12 @@ These core capabilities shall function correctly when
* Specifically identified drivers in certain subsystems, listed below.
The expectations above affect selection of other features; for example
:kconfig:`CONFIG_SYS_CLOCK_EXISTS` cannot be set to ``n``.
:kconfig:option:`CONFIG_SYS_CLOCK_EXISTS` cannot be set to ``n``.
What Cannot be Expected to Work
*******************************
Functionality that will not work with :kconfig:`CONFIG_MULTITHREADING`
Functionality that will not work with :kconfig:option:`CONFIG_MULTITHREADING`
includes majority of the kernel API:
* :ref:`threads_v2`
@ -74,7 +74,7 @@ Subsystem Behavior Without Thread Support
*****************************************
The sections below list driver and functional subsystems that are
expected to work to some degree when :kconfig:`CONFIG_MULTITHREADING` is
expected to work to some degree when :kconfig:option:`CONFIG_MULTITHREADING` is
disabled. Subsystems that are not listed here should not be expected to
work.
@ -108,14 +108,14 @@ UART
A subset of the :ref:`uart_api` is expected to work for all SoC UART
peripheral drivers.
* Applications that select :kconfig:`CONFIG_UART_INTERRUPT_DRIVEN` may
* Applications that select :kconfig:option:`CONFIG_UART_INTERRUPT_DRIVEN` may
work, depending on driver implementation.
* Applications that select :kconfig:`CONFIG_UART_ASYNC_API` may
* Applications that select :kconfig:option:`CONFIG_UART_ASYNC_API` may
work, depending on driver implementation.
* Applications that do not select either :kconfig:`CONFIG_UART_ASYNC_API`
or :kconfig:`CONFIG_UART_INTERRUPT_DRIVEN` are expected to work.
* Applications that do not select either :kconfig:option:`CONFIG_UART_ASYNC_API`
or :kconfig:option:`CONFIG_UART_INTERRUPT_DRIVEN` are expected to work.
*List/table of supported drivers to go here, including which API options
are supported*

8
doc/reference/kernel/threads/workqueue.rst
View file

@ -399,7 +399,7 @@ These APIs must be provided with a :c:struct:`k_work_sync` object that has no
application-inspectable components but is needed to provide the
synchronization objects. These objects should not be allocated on a stack if
the code is expected to work on architectures with
:kconfig:`CONFIG_KERNEL_COHERENCE`.
:kconfig:option:`CONFIG_KERNEL_COHERENCE`.
Workqueue Best Practices
************************
@ -542,9 +542,9 @@ Configuration Options
Related configuration options:
* :kconfig:`CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE`
* :kconfig:`CONFIG_SYSTEM_WORKQUEUE_PRIORITY`
* :kconfig:`CONFIG_SYSTEM_WORKQUEUE_NO_YIELD`
* :kconfig:option:`CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE`
* :kconfig:option:`CONFIG_SYSTEM_WORKQUEUE_PRIORITY`
* :kconfig:option:`CONFIG_SYSTEM_WORKQUEUE_NO_YIELD`
API Reference
**************

2
doc/reference/kernel/timing/clocks.rst
View file

@ -36,7 +36,7 @@ For asynchronous timekeeping, the kernel defines a "ticks" concept. A
uptime and timeout bookkeeping. Interrupts are expected to be
delivered on tick boundaries to the extent practical, and no
fractional ticks are tracked. The choice of tick rate is configurable
via :kconfig:`CONFIG_SYS_CLOCK_TICKS_PER_SEC`. Defaults on most
via :kconfig:option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC`. Defaults on most
hardware platforms (ones that support setting arbitrary interrupt
timeouts) are expected to be in the range of 10 kHz, with software
emulation platforms and legacy drivers using a more traditional 100 Hz

2
doc/reference/libc/index.rst
View file

@ -24,7 +24,7 @@ source code form with Zephyr. Instead, the :ref:`zephyr_sdk` comes with a
precompiled library for each supported architecture (:file:`libc.a` and
:file:`libm.a`). Other 3rd-party toolchains, such as :ref:`toolchain_gnuarmemb`,
also bundle newlib as a precompiled library.
Newlib can be enabled by selecting the :kconfig:`CONFIG_NEWLIB_LIBC` in the
Newlib can be enabled by selecting the :kconfig:option:`CONFIG_NEWLIB_LIBC` in the
application configuration file. Part of the support for ``newlib`` is a set of
hooks available under :file:`lib/libc/newlib/libc-hooks.c` which integrates
the C standard library with basic kernel services.

100
doc/reference/logging/index.rst
View file

@ -111,101 +111,101 @@ Global Kconfig Options
These options can be found in the following path :zephyr_file:`subsys/logging/Kconfig`.
:kconfig:`CONFIG_LOG`: Global switch, turns on/off the logging.
:kconfig:option:`CONFIG_LOG`: Global switch, turns on/off the logging.
Mode of operations:
:kconfig:`CONFIG_LOG_MODE_DEFERRED`: Deferred mode.
:kconfig:option:`CONFIG_LOG_MODE_DEFERRED`: Deferred mode.
:kconfig:`CONFIG_LOG_MODE_IMMEDIATE`: Immediate (synchronous) mode.
:kconfig:option:`CONFIG_LOG_MODE_IMMEDIATE`: Immediate (synchronous) mode.
:kconfig:`CONFIG_LOG_MODE_MINIMAL`: Minimal footprint mode.
:kconfig:option:`CONFIG_LOG_MODE_MINIMAL`: Minimal footprint mode.
:kconfig:`CONFIG_LOG1`: Use deprecated version of logging.
:kconfig:option:`CONFIG_LOG1`: Use deprecated version of logging.
Filtering options:
:kconfig:`CONFIG_LOG_RUNTIME_FILTERING`: Enables runtime reconfiguration of the
:kconfig:option:`CONFIG_LOG_RUNTIME_FILTERING`: Enables runtime reconfiguration of the
filtering.
:kconfig:`CONFIG_LOG_DEFAULT_LEVEL`: Default level, sets the logging level
:kconfig:option:`CONFIG_LOG_DEFAULT_LEVEL`: Default level, sets the logging level
used by modules that are not setting their own logging level.
:kconfig:`CONFIG_LOG_OVERRIDE_LEVEL`: It overrides module logging level when
:kconfig:option:`CONFIG_LOG_OVERRIDE_LEVEL`: It overrides module logging level when
it is not set or set lower than the override value.
:kconfig:`CONFIG_LOG_MAX_LEVEL`: Maximal (lowest severity) level which is
:kconfig:option:`CONFIG_LOG_MAX_LEVEL`: Maximal (lowest severity) level which is
compiled in.
Processing options:
:kconfig:`CONFIG_LOG_MODE_OVERFLOW`: When new message cannot be allocated,
:kconfig:option:`CONFIG_LOG_MODE_OVERFLOW`: When new message cannot be allocated,
oldest one are discarded.
:kconfig:`CONFIG_LOG_BLOCK_IN_THREAD`: If enabled and new log message cannot
:kconfig:option:`CONFIG_LOG_BLOCK_IN_THREAD`: If enabled and new log message cannot
be allocated thread context will block for up to
:kconfig:`CONFIG_LOG_BLOCK_IN_THREAD_TIMEOUT_MS` or until log message is
:kconfig:option:`CONFIG_LOG_BLOCK_IN_THREAD_TIMEOUT_MS` or until log message is
allocated.
:kconfig:`CONFIG_LOG_PRINTK`: Redirect printk calls to the logging.
:kconfig:option:`CONFIG_LOG_PRINTK`: Redirect printk calls to the logging.
:kconfig:`CONFIG_LOG_PRINTK_MAX_STRING_LENGTH`: Maximal string length that can
:kconfig:option:`CONFIG_LOG_PRINTK_MAX_STRING_LENGTH`: Maximal string length that can
be processed by printk. Longer strings are trimmed.
:kconfig:`CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD`: When number of buffered log
:kconfig:option:`CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD`: When number of buffered log
messages reaches the threshold dedicated thread (see :c:func:`log_thread_set`)
is waken up. If :kconfig:`CONFIG_LOG_PROCESS_THREAD` is enabled then this
is waken up. If :kconfig:option:`CONFIG_LOG_PROCESS_THREAD` is enabled then this
threshold is used by the internal thread.
:kconfig:`CONFIG_LOG_PROCESS_THREAD`: When enabled, logging thread is created
:kconfig:option:`CONFIG_LOG_PROCESS_THREAD`: When enabled, logging thread is created
which handles log processing.
:kconfig:`CONFIG_LOG_PROCESS_THREAD_STARTUP_DELAY_MS`: Delay in milliseconds
:kconfig:option:`CONFIG_LOG_PROCESS_THREAD_STARTUP_DELAY_MS`: Delay in milliseconds
after which logging thread is started.
:kconfig:`CONFIG_LOG_BUFFER_SIZE`: Number of bytes dedicated for the message pool.
:kconfig:option:`CONFIG_LOG_BUFFER_SIZE`: Number of bytes dedicated for the message pool.
Single message capable of storing standard log with up to 3 arguments or hexdump
message with 12 bytes of data take 32 bytes. In v2 it indicates buffer size
dedicated for circular packet buffer.
:kconfig:`CONFIG_LOG_DETECT_MISSED_STRDUP`: Enable detection of missed transient
:kconfig:option:`CONFIG_LOG_DETECT_MISSED_STRDUP`: Enable detection of missed transient
strings handling.
:kconfig:`CONFIG_LOG_STRDUP_MAX_STRING`: Longest string that can be duplicated
:kconfig:option:`CONFIG_LOG_STRDUP_MAX_STRING`: Longest string that can be duplicated
using log_strdup().
:kconfig:`CONFIG_LOG_STRDUP_BUF_COUNT`: Number of buffers in the pool used by
:kconfig:option:`CONFIG_LOG_STRDUP_BUF_COUNT`: Number of buffers in the pool used by
log_strdup().
:kconfig:`CONFIG_LOG_DOMAIN_ID`: Domain ID. Valid in multi-domain systems.
:kconfig:option:`CONFIG_LOG_DOMAIN_ID`: Domain ID. Valid in multi-domain systems.
:kconfig:`CONFIG_LOG_FRONTEND`: Redirect logs to a custom frontend.
:kconfig:option:`CONFIG_LOG_FRONTEND`: Redirect logs to a custom frontend.
:kconfig:`CONFIG_LOG_TIMESTAMP_64BIT`: 64 bit timestamp.
:kconfig:option:`CONFIG_LOG_TIMESTAMP_64BIT`: 64 bit timestamp.
Formatting options:
:kconfig:`CONFIG_LOG_FUNC_NAME_PREFIX_ERR`: Prepend standard ERROR log messages
:kconfig:option:`CONFIG_LOG_FUNC_NAME_PREFIX_ERR`: Prepend standard ERROR log messages
with function name. Hexdump messages are not prepended.
:kconfig:`CONFIG_LOG_FUNC_NAME_PREFIX_WRN`: Prepend standard WARNING log messages
:kconfig:option:`CONFIG_LOG_FUNC_NAME_PREFIX_WRN`: Prepend standard WARNING log messages
with function name. Hexdump messages are not prepended.
:kconfig:`CONFIG_LOG_FUNC_NAME_PREFIX_INF`: Prepend standard INFO log messages
:kconfig:option:`CONFIG_LOG_FUNC_NAME_PREFIX_INF`: Prepend standard INFO log messages
with function name. Hexdump messages are not prepended.
:kconfig:`CONFIG_LOG_FUNC_NAME_PREFIX_DBG`: Prepend standard DEBUG log messages
:kconfig:option:`CONFIG_LOG_FUNC_NAME_PREFIX_DBG`: Prepend standard DEBUG log messages
with function name. Hexdump messages are not prepended.
:kconfig:`CONFIG_LOG_BACKEND_SHOW_COLOR`: Enables coloring of errors (red)
:kconfig:option:`CONFIG_LOG_BACKEND_SHOW_COLOR`: Enables coloring of errors (red)
and warnings (yellow).
:kconfig:`CONFIG_LOG_BACKEND_FORMAT_TIMESTAMP`: If enabled timestamp is
:kconfig:option:`CONFIG_LOG_BACKEND_FORMAT_TIMESTAMP`: If enabled timestamp is
formatted to *hh:mm:ss:mmm,uuu*. Otherwise is printed in raw format.
Backend options:
:kconfig:`CONFIG_LOG_BACKEND_UART`: Enabled build-in UART backend.
:kconfig:option:`CONFIG_LOG_BACKEND_UART`: Enabled build-in UART backend.
.. _log_usage:
@ -218,7 +218,7 @@ Logging in a module
In order to use logging in the module, a unique name of a module must be
specified and module must be registered using :c:macro:`LOG_MODULE_REGISTER`.
Optionally, a compile time log level for the module can be specified as the
second parameter. Default log level (:kconfig:`CONFIG_LOG_DEFAULT_LEVEL`) is used
second parameter. Default log level (:kconfig:option:`CONFIG_LOG_DEFAULT_LEVEL`) is used
if custom log level is not provided.
.. code-block:: c
@ -230,7 +230,7 @@ If the module consists of multiple files, then ``LOG_MODULE_REGISTER()`` should
appear in exactly one of them. Each other file should use
:c:macro:`LOG_MODULE_DECLARE` to declare its membership in the module.
Optionally, a compile time log level for the module can be specified as
the second parameter. Default log level (:kconfig:`CONFIG_LOG_DEFAULT_LEVEL`)
the second parameter. Default log level (:kconfig:option:`CONFIG_LOG_DEFAULT_LEVEL`)
is used if custom log level is not provided.
.. code-block:: c
@ -243,7 +243,7 @@ In order to use logging API in a function implemented in a header file
:c:macro:`LOG_MODULE_DECLARE` macro must be used in the function body
before logging API is called. Optionally, a compile time log level for the module
can be specified as the second parameter. Default log level
(:kconfig:`CONFIG_LOG_DEFAULT_LEVEL`) is used if custom log level is not
(:kconfig:option:`CONFIG_LOG_DEFAULT_LEVEL`) is used if custom log level is not
provided.
.. code-block:: c
@ -358,8 +358,8 @@ Following snippet shows how logging can be processed in simple forever loop.
If logs are processed from a thread then it is possible to enable a feature
which will wake up processing thread when certain amount of log messages are
buffered (see :kconfig:`CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD`). It is also
possible to enable internal logging thread (see :kconfig:`CONFIG_LOG_PROCESS_THREAD`).
buffered (see :kconfig:option:`CONFIG_LOG_PROCESS_TRIGGER_THRESHOLD`). It is also
possible to enable internal logging thread (see :kconfig:option:`CONFIG_LOG_PROCESS_THREAD`).
In that case, logging thread is initialized and log messages are processed implicitly.
.. _logging_panic:
@ -485,7 +485,7 @@ are two strategies to handle that case:
- No overflow - new log is dropped if space for a message cannot be allocated.
- Overflow - oldest pending messages are freed, until new message can be
allocated. Enabled by :kconfig:`CONFIG_LOG_MODE_OVERFLOW`. Note that it degrades
allocated. Enabled by :kconfig:option:`CONFIG_LOG_MODE_OVERFLOW`. Note that it degrades
performance thus it is recommended to adjust buffer size and amount of enabled
logs to limit dropping.
@ -518,7 +518,7 @@ particular source will be buffered.
Custom Frontend
===============
Custom frontend is enabled using :kconfig:`CONFIG_LOG_FRONTEND`. Logs are redirected
Custom frontend is enabled using :kconfig:option:`CONFIG_LOG_FRONTEND`. Logs are redirected
to functions declared in :zephyr_file:`include/logging/log_frontend.h`.
This may be required in very time-sensitive cases, but most of the logging
features cannot be used then, which includes default frontend, core and all
@ -536,13 +536,13 @@ Since log message contains only the value of the argument, when ``%s`` is used
only the address of a string is stored. Because a string variable argument could
be transient, allocated on the stack, or modifiable, logger provides a mechanism
and a dedicated buffer pool to hold copies of strings. The buffer size and count
is configurable (see :kconfig:`CONFIG_LOG_STRDUP_MAX_STRING` and
:kconfig:`CONFIG_LOG_STRDUP_BUF_COUNT`).
is configurable (see :kconfig:option:`CONFIG_LOG_STRDUP_MAX_STRING` and
:kconfig:option:`CONFIG_LOG_STRDUP_BUF_COUNT`).
If a string argument is transient, the user must call :c:func:`log_strdup` to
duplicate the passed string into a buffer from the pool. See the examples below.
If a strdup buffer cannot be allocated, a warning message is logged and an error
code returned indicating :kconfig:`CONFIG_LOG_STRDUP_BUF_COUNT` should be
code returned indicating :kconfig:option:`CONFIG_LOG_STRDUP_BUF_COUNT` should be
increased. Buffers are freed together with the log message.
.. code-block:: c
@ -552,7 +552,7 @@ increased. Buffers are freed together with the log message.
LOG_INF("logging transient string: %s", log_strdup(local_str));
local_str[0] = '\0'; /* String can be modified, logger will use duplicate."
When :kconfig:`CONFIG_LOG_DETECT_MISSED_STRDUP` is enabled logger will scan
When :kconfig:option:`CONFIG_LOG_DETECT_MISSED_STRDUP` is enabled logger will scan
each log message and report if string format specifier is found and string
address is not in read only memory section or does not belong to memory pool
dedicated to string duplicates. It indictes that :c:func:`log_strdup` is
@ -671,18 +671,18 @@ Configuration
Here are kconfig options related to dictionary-based logging:
- :kconfig:`CONFIG_LOG_DICTIONARY_SUPPORT` enables dictionary-based logging
- :kconfig:option:`CONFIG_LOG_DICTIONARY_SUPPORT` enables dictionary-based logging
support. This should be selected by the backends which require it.
- The UART backend can be used for dictionary-based logging. These are
additional config for the UART backend:
- :kconfig:`CONFIG_LOG_BACKEND_UART_OUTPUT_DICTIONARY_HEX` tells
- :kconfig:option:`CONFIG_LOG_BACKEND_UART_OUTPUT_DICTIONARY_HEX` tells
the UART backend to output hexadecimal characters for dictionary based
logging. This is useful when the log data needs to be captured manually
via terminals and consoles.
- :kconfig:`CONFIG_LOG_BACKEND_UART_OUTPUT_DICTIONARY_BIN` tells
- :kconfig:option:`CONFIG_LOG_BACKEND_UART_OUTPUT_DICTIONARY_BIN` tells
the UART backend to output binary data.
@ -733,7 +733,7 @@ Logging v2
Solves major limitations of v1. However, in order to get most of the logging
capabilities following recommendations shall be followed:
* Enable :kconfig:`CONFIG_LOG_SPEED` to slightly speed up deferred logging at the
* Enable :kconfig:option:`CONFIG_LOG_SPEED` to slightly speed up deferred logging at the
cost of slight increase in memory footprint.
* Compiler with C11 ``_Generic`` keyword support is recommended. Logging
performance is significantly degraded without it. See :ref:`cbprintf_packaging`.
@ -784,7 +784,7 @@ from userspace. It is at the cost of larger memory footprint for a log message.
.. rubric:: Benchmark details
.. [#f0] :kconfig:`CONFIG_LOG_SPEED` enabled.
.. [#f0] :kconfig:option:`CONFIG_LOG_SPEED` enabled.
.. [#f1] Number of log messages with various number of arguments that fits in 2048
bytes dedicated for logging.
@ -801,9 +801,9 @@ Stack usage
When logging is enabled it impacts stack usage of the context that uses logging API. If stack
is optimized it may lead to stack overflow. Stack usage depends on mode and optimization. It
also significantly varies between platforms. In general, when :kconfig:`CONFIG_LOG_MODE_DEFERRED`
also significantly varies between platforms. In general, when :kconfig:option:`CONFIG_LOG_MODE_DEFERRED`
is used stack usage is smaller since logging is limited to creating and storing log message.
When :kconfig:`CONFIG_LOG_MODE_IMMEDIATE` is used then log message is processed by the backend
When :kconfig:option:`CONFIG_LOG_MODE_IMMEDIATE` is used then log message is processed by the backend
which includes string formatting. In case of that mode, stack usage will depend on which backends
are used.

8
doc/reference/memory_management/demand_paging.rst
View file

@ -84,16 +84,16 @@ Paging Statistics
*****************
Paging statistics can be obtained via various function calls when
:kconfig:`CONFIG_DEMAND_PAGING_TIMING_HISTOGRAM_NUM_BINS` is enabled:
:kconfig:option:`CONFIG_DEMAND_PAGING_TIMING_HISTOGRAM_NUM_BINS` is enabled:
* Overall statistics via :c:func:`k_mem_paging_stats_get()`
* Per-thread statistics via :c:func:`k_mem_paging_thread_stats_get()`
if :kconfig:`CONFIG_DEMAND_PAGING_THREAD_STATS` is enabled
if :kconfig:option:`CONFIG_DEMAND_PAGING_THREAD_STATS` is enabled
* Execution time histogram can be obtained when
:kconfig:`CONFIG_DEMAND_PAGING_TIMING_HISTOGRAM` is enabled, and
:kconfig:`CONFIG_DEMAND_PAGING_TIMING_HISTOGRAM_NUM_BINS` is defined.
:kconfig:option:`CONFIG_DEMAND_PAGING_TIMING_HISTOGRAM` is enabled, and
:kconfig:option:`CONFIG_DEMAND_PAGING_TIMING_HISTOGRAM_NUM_BINS` is defined.
Note that the timing is highly dependent on the architecture,
SoC or board. It is highly recommended that
``k_mem_paging_eviction_histogram_bounds[]`` and

24
doc/reference/misc/formatted_output.rst
View file

@ -25,18 +25,18 @@ use of ``s*printf()`` C libraries in Zephyr can be converted to
Several Kconfig options control the set of features that are enabled,
allowing some control over features and memory usage:
* :kconfig:`CONFIG_CBPRINTF_FULL_INTEGRAL`
or :kconfig:`CONFIG_CBPRINTF_REDUCED_INTEGRAL`
* :kconfig:`CONFIG_CBPRINTF_FP_SUPPORT`
* :kconfig:`CONFIG_CBPRINTF_FP_A_SUPPORT`
* :kconfig:`CONFIG_CBPRINTF_FP_ALWAYS_A`
* :kconfig:`CONFIG_CBPRINTF_N_SPECIFIER`
* :kconfig:option:`CONFIG_CBPRINTF_FULL_INTEGRAL`
or :kconfig:option:`CONFIG_CBPRINTF_REDUCED_INTEGRAL`
* :kconfig:option:`CONFIG_CBPRINTF_FP_SUPPORT`
* :kconfig:option:`CONFIG_CBPRINTF_FP_A_SUPPORT`
* :kconfig:option:`CONFIG_CBPRINTF_FP_ALWAYS_A`
* :kconfig:option:`CONFIG_CBPRINTF_N_SPECIFIER`
:kconfig:`CONFIG_CBPRINTF_LIBC_SUBSTS` can be used to provide functions
:kconfig:option:`CONFIG_CBPRINTF_LIBC_SUBSTS` can be used to provide functions
that behave like standard libc functions but use the selected cbprintf
formatter rather than pulling in another formatter from libc.
In addition :kconfig:`CONFIG_CBPRINTF_NANO` can be used to revert back to
In addition :kconfig:option:`CONFIG_CBPRINTF_NANO` can be used to revert back to
the very space-optimized but limited formatter used for :c:func:`printk`
before this capability was added.
@ -76,8 +76,8 @@ Package can be created using two methods:
Several Kconfig options control behavior of the packaging:
* :kconfig:`CONFIG_CBPRINTF_PACKAGE_LONGDOUBLE`
* :kconfig:`CONFIG_CBPRINTF_STATIC_PACKAGE_CHECK_ALIGNMENT`
* :kconfig:option:`CONFIG_CBPRINTF_PACKAGE_LONGDOUBLE`
* :kconfig:option:`CONFIG_CBPRINTF_STATIC_PACKAGE_CHECK_ALIGNMENT`
Cbprintf package format
=======================
@ -122,8 +122,8 @@ formatting since address changes whenever package is copied.
.. warning::
If :kconfig:`CONFIG_MINIMAL_LIBC` is selected in combination with
:kconfig:`CONFIG_CBPRINTF_NANO` formatting with C standard library
If :kconfig:option:`CONFIG_MINIMAL_LIBC` is selected in combination with
:kconfig:option:`CONFIG_CBPRINTF_NANO` formatting with C standard library
functions like ``printf`` or ``snprintf`` is limited. Among other
things the ``%n`` specifier, most format flags, precision control, and
floating point are not supported.

4
doc/reference/misc/timeutil.rst
View file

@ -7,7 +7,7 @@ Overview
********
:ref:`kernel_timing_uptime` in Zephyr is based on the a tick counter. With
the default :kconfig:`CONFIG_TICKLESS_KERNEL` this counter advances at a
the default :kconfig:option:`CONFIG_TICKLESS_KERNEL` this counter advances at a
nominally constant rate from zero at the instant the system started. The POSIX
equivalent to this counter is something like ``CLOCK_MONOTONIC`` or, in Linux,
``CLOCK_MONOTONIC_RAW``. :c:func:`k_uptime_get()` provides a millisecond
@ -76,7 +76,7 @@ There are several factors that affect synchronizing time scales:
* The rate of discrete instant representation change. For example Zephyr
uptime is tracked in ticks which advance at events that nominally occur at
:kconfig:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` Hertz, while an external time
:kconfig:option:`CONFIG_SYS_CLOCK_TICKS_PER_SEC` Hertz, while an external time
source may provide data in whole or fractional seconds (e.g. microseconds).
* The absolute offset required to align the two scales at a single instant.
* The relative error between observable instants in each scale, required to

2
doc/reference/networking/coap.rst
View file

@ -76,7 +76,7 @@ responsibility to either reply or act according to CoAP request.
coap_handle_request(&request, resources, options, opt_num,
client_addr, client_addr_len);
If :kconfig:`CONFIG_COAP_URI_WILDCARD` enabled, server may accept multiple resources
If :kconfig:option:`CONFIG_COAP_URI_WILDCARD` enabled, server may accept multiple resources
using MQTT-like wildcard style:
- the plus symbol represents a single-level wild card in the path;

6
doc/reference/networking/dns_resolve.rst
View file

@ -16,15 +16,15 @@ Supported DNS answers are IPv4/IPv6 addresses and CNAME.
If a CNAME is received, the DNS resolver will create another DNS query.
The number of additional queries is controlled by the
:kconfig:`CONFIG_DNS_RESOLVER_ADDITIONAL_QUERIES` Kconfig variable.
:kconfig:option:`CONFIG_DNS_RESOLVER_ADDITIONAL_QUERIES` Kconfig variable.
The multicast DNS (mDNS) client resolver support can be enabled by setting
:kconfig:`CONFIG_MDNS_RESOLVER` Kconfig option.
:kconfig:option:`CONFIG_MDNS_RESOLVER` Kconfig option.
See `IETF RFC6762 <https://tools.ietf.org/html/rfc6762>`_ for more details
about mDNS.
The link-local multicast name resolution (LLMNR) client resolver support can be
enabled by setting the :kconfig:`CONFIG_LLMNR_RESOLVER` Kconfig variable.
enabled by setting the :kconfig:option:`CONFIG_LLMNR_RESOLVER` Kconfig variable.
See `IETF RFC4795 <https://tools.ietf.org/html/rfc4795>`_ for more details
about LLMNR.

2
doc/reference/networking/gptp.rst
View file

@ -49,7 +49,7 @@ Enabling the stack
The following configuration option must me enabled in :file:`prj.conf` file.
- :kconfig:`CONFIG_NET_GPTP`
- :kconfig:option:`CONFIG_NET_GPTP`
Application interfaces
**********************

4
doc/reference/networking/gsm_modem.rst
View file

@ -18,5 +18,5 @@ to use the GSM modem.
The GSM muxing, that is defined in
`GSM 07.10 <https://www.etsi.org/deliver/etsi_ts/127000_127099/127010/15.00.00_60/ts_127010v150000p.pdf>`__,
and which allows mixing of AT commands and PPP traffic, is also supported in
this version of Zephyr. One needs to enable :kconfig:`CONFIG_GSM_MUX` and
:kconfig:`CONFIG_UART_MUX` configuration options to enable muxing.
this version of Zephyr. One needs to enable :kconfig:option:`CONFIG_GSM_MUX` and
:kconfig:option:`CONFIG_UART_MUX` configuration options to enable muxing.

2
doc/reference/networking/lwm2m.rst
View file

@ -367,7 +367,7 @@ Using LwM2M library with DTLS
*****************************
The Zephyr LwM2M library can be used with DTLS transport for secure
communication by selecting :kconfig:`CONFIG_LWM2M_DTLS_SUPPORT`. In the client
communication by selecting :kconfig:option:`CONFIG_LWM2M_DTLS_SUPPORT`. In the client
initialization we need to create a PSK and identity. These need to match
the security information loaded onto the LwM2M server. Normally, the
endpoint name is used to lookup the related security information:

20
doc/reference/networking/net_config.rst
View file

@ -21,7 +21,7 @@ setup the system:
:header: "Option name", "Description"
:widths: auto
":kconfig:`CONFIG_NET_CONFIG_SETTINGS`", "This option controls whether the
":kconfig:option:`CONFIG_NET_CONFIG_SETTINGS`", "This option controls whether the
network system is configured or initialized at all. If not set, then the
config library is not used for initialization and the application needs to
do all the network related configuration itself. If this option is set,
@ -30,34 +30,34 @@ setup the system:
is only usable in testing and should not be used in production code. See
the config library Kconfig file :zephyr_file:`subsys/net/lib/config/Kconfig`
for specific options to set the static IP addresses."
":kconfig:`CONFIG_NET_CONFIG_AUTO_INIT`", "The networking system is
":kconfig:option:`CONFIG_NET_CONFIG_AUTO_INIT`", "The networking system is
automatically configured when the device is started."
":kconfig:`CONFIG_NET_CONFIG_INIT_TIMEOUT`", "This tells how long to wait for
":kconfig:option:`CONFIG_NET_CONFIG_INIT_TIMEOUT`", "This tells how long to wait for
the networking to be ready and available. If for example IPv4 address from
DHCPv4 is not received within this limit, then a call to
``net_config_init()`` will return error during the device startup."
":kconfig:`CONFIG_NET_CONFIG_NEED_IPV4`", "The network application needs IPv4
":kconfig:option:`CONFIG_NET_CONFIG_NEED_IPV4`", "The network application needs IPv4
support to function properly. This option makes sure the network application
is initialized properly in order to use IPv4.
If :kconfig:`CONFIG_NET_IPV4` is not enabled, then setting this option will
If :kconfig:option:`CONFIG_NET_IPV4` is not enabled, then setting this option will
automatically enable IPv4."
":kconfig:`CONFIG_NET_CONFIG_NEED_IPV6`", "The network application needs IPv6
":kconfig:option:`CONFIG_NET_CONFIG_NEED_IPV6`", "The network application needs IPv6
support to function properly. This option makes sure the network application
is initialized properly in order to use IPv6.
If :kconfig:`CONFIG_NET_IPV6` is not enabled, then setting this option will
If :kconfig:option:`CONFIG_NET_IPV6` is not enabled, then setting this option will
automatically enable IPv6."
":kconfig:`CONFIG_NET_CONFIG_NEED_IPV6_ROUTER`", "If IPv6 is enabled, then
":kconfig:option:`CONFIG_NET_CONFIG_NEED_IPV6_ROUTER`", "If IPv6 is enabled, then
this option tells that the network application needs IPv6 router to exists
before continuing. This means in practice that the application wants to wait
until it receives IPv6 router advertisement message before continuing."
":kconfig:`CONFIG_NET_CONFIG_BT_NODE`", "Enables application to operate in
":kconfig:option:`CONFIG_NET_CONFIG_BT_NODE`", "Enables application to operate in
Bluetooth node mode which requires GATT service to be registered and start
advertising as peripheral."
Sample usage
************
If :kconfig:`CONFIG_NET_CONFIG_AUTO_INIT` is set, then the configuration library
If :kconfig:option:`CONFIG_NET_CONFIG_AUTO_INIT` is set, then the configuration library
is automatically enabled and run during the device boot. In this case,
the library will call ``net_config_init()`` automatically and the application
does not need to do any network configuration.

8
doc/reference/networking/net_hostname.rst
View file

@ -14,14 +14,14 @@ A networked device might need a hostname, for example, if the device
is configured to be a mDNS responder (see :ref:`dns_resolve_interface` for
details) and needs to respond to ``<hostname>.local`` DNS queries.
The :kconfig:`CONFIG_NET_HOSTNAME_ENABLE` must be set in order
The :kconfig:option:`CONFIG_NET_HOSTNAME_ENABLE` must be set in order
to store the hostname and enable the relevant APIs. If the option is enabled,
then the default hostname is set to be ``zephyr`` by
:kconfig:`CONFIG_NET_HOSTNAME` option.
:kconfig:option:`CONFIG_NET_HOSTNAME` option.
If the same firmware image is used to flash multiple boards, then it is not
practical to use the same hostname in all of the boards. In that case, one
can enable :kconfig:`CONFIG_NET_HOSTNAME_UNIQUE` which will add a unique
can enable :kconfig:option:`CONFIG_NET_HOSTNAME_UNIQUE` which will add a unique
postfix to the hostname. By default the link local address of the first network
interface is used as a postfix. In Ethernet networks, the link local address
refers to MAC address. For example, if the link local address is
@ -29,7 +29,7 @@ refers to MAC address. For example, if the link local address is
``zephyr010203040506``. If you want to set the prefix yourself, then call
``net_hostname_set_postfix()`` before the network interfaces are created.
For example for the Ethernet networks, the initialization priority is set by
:kconfig:`CONFIG_ETH_INIT_PRIORITY` so you would need to set the postfix before
:kconfig:option:`CONFIG_ETH_INIT_PRIORITY` so you would need to set the postfix before
that. The postfix can be set only once.
API Reference

10
doc/reference/networking/net_if.rst
View file

@ -19,7 +19,7 @@ and that section is populated at linking time.
Network interfaces are created by ``NET_DEVICE_INIT()`` macro.
For Ethernet network, a macro called ``ETH_NET_DEVICE_INIT()`` should be used
instead as it will create VLAN interfaces automatically if
:kconfig:`CONFIG_NET_VLAN` is enabled. These macros are typically used in
:kconfig:option:`CONFIG_NET_VLAN` is enabled. These macros are typically used in
network device driver source code.
The network interface can be turned ON by calling ``net_if_up()`` and OFF
@ -39,8 +39,8 @@ IP address manually. See the API documentation below for functions such as
The ``net_if_get_default()`` returns a *default* network interface. What
this default interface means can be configured via options like
:kconfig:`CONFIG_NET_DEFAULT_IF_FIRST` and
:kconfig:`CONFIG_NET_DEFAULT_IF_ETHERNET`.
:kconfig:option:`CONFIG_NET_DEFAULT_IF_FIRST` and
:kconfig:option:`CONFIG_NET_DEFAULT_IF_ETHERNET`.
See Kconfig file :zephyr_file:`subsys/net/ip/Kconfig` what options are available for
selecting the default network interface.
@ -48,9 +48,9 @@ The transmitted and received network packets can be classified via a network
packet priority. This is typically done in Ethernet networks when virtual LANs
(VLANs) are used. Higher priority packets can be sent or received earlier than
lower priority packets. The traffic class setup can be configured by
:kconfig:`CONFIG_NET_TC_TX_COUNT` and :kconfig:`CONFIG_NET_TC_RX_COUNT` options.
:kconfig:option:`CONFIG_NET_TC_TX_COUNT` and :kconfig:option:`CONFIG_NET_TC_RX_COUNT` options.
If the :kconfig:`CONFIG_NET_PROMISCUOUS_MODE` is enabled and if the underlaying
If the :kconfig:option:`CONFIG_NET_PROMISCUOUS_MODE` is enabled and if the underlaying
network technology supports promiscuous mode, then it is possible to receive
all the network packets that the network device driver is able to receive.
See :ref:`promiscuous_interface` API for more details.

2
doc/reference/networking/net_pkt_filter.rst
View file

@ -15,7 +15,7 @@ construct custom rules for accepting and/or denying packet transmission
and reception. This can be used to create a basic firewall, control
network traffic, etc.
The :kconfig:`CONFIG_NET_PKT_FILTER` must be set in order to enable the
The :kconfig:option:`CONFIG_NET_PKT_FILTER` must be set in order to enable the
relevant APIs.
Both the transmission and reception paths may have a list of filter rules.

22
doc/reference/networking/net_shell.rst
View file

@ -16,30 +16,30 @@ The following net-shell commands are implemented:
:widths: auto
"net allocs", "Print network memory allocations. Only available if
:kconfig:`CONFIG_NET_DEBUG_NET_PKT_ALLOC` is set."
:kconfig:option:`CONFIG_NET_DEBUG_NET_PKT_ALLOC` is set."
"net arp", "Print information about IPv4 ARP cache. Only available if
:kconfig:`CONFIG_NET_ARP` is set in IPv4 enabled networks."
:kconfig:option:`CONFIG_NET_ARP` is set in IPv4 enabled networks."
"net capture", "Monitor network traffic See :ref:`network_monitoring`
for details."
"net conn", "Print information about network connections."
"net dns", "Show how DNS is configured. The command can also be used to
resolve a DNS name. Only available if :kconfig:`CONFIG_DNS_RESOLVER` is set."
resolve a DNS name. Only available if :kconfig:option:`CONFIG_DNS_RESOLVER` is set."
"net events", "Enable network event monitoring. Only available if
:kconfig:`CONFIG_NET_MGMT_EVENT_MONITOR` is set."
:kconfig:option:`CONFIG_NET_MGMT_EVENT_MONITOR` is set."
"net gptp", "Print information about gPTP support. Only available if
:kconfig:`CONFIG_NET_GPTP` is set."
:kconfig:option:`CONFIG_NET_GPTP` is set."
"net iface", "Print information about network interfaces."
"net ipv6", "Print IPv6 specific information and configuration.
Only available if :kconfig:`CONFIG_NET_IPV6` is set."
Only available if :kconfig:option:`CONFIG_NET_IPV6` is set."
"net mem", "Print information about network memory usage. The command will
print more information if :kconfig:`CONFIG_NET_BUF_POOL_USAGE` is set."
print more information if :kconfig:option:`CONFIG_NET_BUF_POOL_USAGE` is set."
"net nbr", "Print neighbor information. Only available if
:kconfig:`CONFIG_NET_IPV6` is set."
:kconfig:option:`CONFIG_NET_IPV6` is set."
"net ping", "Ping a network host."
"net route", "Show IPv6 network routes. Only available if
:kconfig:`CONFIG_NET_ROUTE` is set."
:kconfig:option:`CONFIG_NET_ROUTE` is set."
"net stats", "Show network statistics."
"net tcp", "Connect/send data/close TCP connection. Only available if
:kconfig:`CONFIG_NET_TCP` is set."
:kconfig:option:`CONFIG_NET_TCP` is set."
"net vlan", "Show Ethernet virtual LAN information. Only available if
:kconfig:`CONFIG_NET_VLAN` is set."
:kconfig:option:`CONFIG_NET_VLAN` is set."

12
doc/reference/networking/net_stats.rst
View file

@ -10,26 +10,26 @@ Network Statistics
Overview
********
Network statistics are collected if :kconfig:`CONFIG_NET_STATISTICS` is set.
Network statistics are collected if :kconfig:option:`CONFIG_NET_STATISTICS` is set.
Individual component statistics for IPv4 or IPv6 can be turned off
if those statistics are not needed. See various options in
:zephyr_file:`subsys/net/ip/Kconfig.stats` file for details.
By default, the system collects network statistics per network interface. This
can be controlled by :kconfig:`CONFIG_NET_STATISTICS_PER_INTERFACE` option.
can be controlled by :kconfig:option:`CONFIG_NET_STATISTICS_PER_INTERFACE` option.
The :kconfig:`CONFIG_NET_STATISTICS_USER_API` option can be set if the
The :kconfig:option:`CONFIG_NET_STATISTICS_USER_API` option can be set if the
application wants to collect statistics for further processing. The network
management interface API is used for that. See :ref:`net_mgmt_interface` for
details.
The :kconfig:`CONFIG_NET_STATISTICS_ETHERNET` option can be set to collect
The :kconfig:option:`CONFIG_NET_STATISTICS_ETHERNET` option can be set to collect
generic Ethernet statistics. If the
:kconfig:`CONFIG_NET_STATISTICS_ETHERNET_VENDOR` option is set, then
:kconfig:option:`CONFIG_NET_STATISTICS_ETHERNET_VENDOR` option is set, then
Ethernet device driver can collect Ethernet device specific statistics.
These statistics can then be transferred to application for processing.
If the :kconfig:`CONFIG_NET_SHELL` option is set, then network shell can
If the :kconfig:option:`CONFIG_NET_SHELL` option is set, then network shell can
show statistics information with ``net stats`` command.
API Reference

2
doc/reference/networking/ppp.rst
View file

@ -21,7 +21,7 @@ In Zephyr, each individual PPP link is modelled as a network interface. This
is similar to how Linux implements PPP.
PPP support must be enabled at compile time by setting option
:kconfig:`CONFIG_NET_PPP` and :kconfig:`CONFIG_NET_L2_PPP`.
:kconfig:option:`CONFIG_NET_PPP` and :kconfig:option:`CONFIG_NET_L2_PPP`.
The PPP support in Zephyr 2.0 is still experimental and the implementation
supports only these protocols:

10
doc/reference/networking/sockets.rst
View file

@ -22,10 +22,10 @@ compatible API implementation for Zephyr:
* Is namespaced by default, to avoid name conflicts with well-known
names like ``close()``, which may be part of libc or other POSIX
compatibility libraries.
If enabled by :kconfig:`CONFIG_NET_SOCKETS_POSIX_NAMES`, it will also
If enabled by :kconfig:option:`CONFIG_NET_SOCKETS_POSIX_NAMES`, it will also
expose native POSIX names.
BSD Sockets compatible API is enabled using :kconfig:`CONFIG_NET_SOCKETS`
BSD Sockets compatible API is enabled using :kconfig:option:`CONFIG_NET_SOCKETS`
config option and implements the following operations: ``socket()``, ``close()``,
``recv()``, ``recvfrom()``, ``send()``, ``sendto()``, ``connect()``, ``bind()``,
``listen()``, ``accept()``, ``fcntl()`` (to set non-blocking mode),
@ -35,7 +35,7 @@ config option and implements the following operations: ``socket()``, ``close()``
Based on the namespacing requirements above, these operations are by
default exposed as functions with ``zsock_`` prefix, e.g.
:c:func:`zsock_socket` and :c:func:`zsock_close`. If the config option
:kconfig:`CONFIG_NET_SOCKETS_POSIX_NAMES` is defined, all the functions
:kconfig:option:`CONFIG_NET_SOCKETS_POSIX_NAMES` is defined, all the functions
will be also exposed as aliases without the prefix. This includes the
functions like ``close()`` and ``fcntl()`` (which may conflict with
functions in libc or other libraries, for example, with the filesystem
@ -69,8 +69,8 @@ mbedTLS library. Secure sockets implementation allows use of both TLS and DTLS
protocols with standard socket calls. See :c:enum:`net_ip_protocol_secure` type
for supported secure protocol versions.
To enable secure sockets, set the :kconfig:`CONFIG_NET_SOCKETS_SOCKOPT_TLS`
option. To enable DTLS support, use :kconfig:`CONFIG_NET_SOCKETS_ENABLE_DTLS`
To enable secure sockets, set the :kconfig:option:`CONFIG_NET_SOCKETS_SOCKOPT_TLS`
option. To enable DTLS support, use :kconfig:option:`CONFIG_NET_SOCKETS_ENABLE_DTLS`
option.
TLS credentials subsystem

Some files were not shown because too many files have changed in this diff Show more