Commit 32918ddd authored by Benjamin Cabé's avatar Benjamin Cabé Committed by Fabio Baltieri
Browse files

doc: Fix broken references to Kconfig options 



Fixed a few occurrences of incorrect references to Kconfig options
(missing the CONFIG_ prefix)

Signed-off-by: default avatarBenjamin Cabé <benjamin@zephyrproject.org>
parent 36defb42

doc/connectivity/bluetooth/api/mesh/shell.rst

+9 −9
Original line number Diff line number Diff line
@@ -344,7 +344,7 @@ and :kconfig:option:`CONFIG_BT_MESH_PB_GATT_CLIENT` configuration options must b 


	Get or set the mesh node's UUID, used in the unprovisioned beacons.



	* ``UUID``: If present, new 128-bit UUID value. Providing a hex-string shorter than 16 bytes will populate the N most significant bytes of the array and zero-pad the rest. If omitted, the current UUID will be printed. To enable this command, the :kconfig:option:`BT_MESH_SHELL_PROV_CTX_INSTANCE` option must be enabled.

	* ``UUID``: If present, new 128-bit UUID value. Providing a hex-string shorter than 16 bytes will populate the N most significant bytes of the array and zero-pad the rest. If omitted, the current UUID will be printed. To enable this command, the :kconfig:option:`CONFIG_BT_MESH_SHELL_PROV_CTX_INSTANCE` option must be enabled.





``mesh prov input-num <Number>``
@@ -373,7 +373,7 @@ and :kconfig:option:`CONFIG_BT_MESH_PB_GATT_CLIENT` configuration options must b 
	Set or clear the static OOB authentication value. The static OOB authentication value must

	be set before provisioning starts to have any effect. The static OOB value must be same on

	both participants in the provisioning. To enable this command, the

	:kconfig:option:`BT_MESH_SHELL_PROV_CTX_INSTANCE` option must be enabled.

	:kconfig:option:`CONFIG_BT_MESH_SHELL_PROV_CTX_INSTANCE` option must be enabled.



	* ``Val``: If present, indicates the new hexadecimal value of the static OOB. Providing a hex-string shorter than 16 bytes will populate the N most significant bytes of the array and zero-pad the rest. If omitted, the static OOB value is cleared.
@@ -394,7 +394,7 @@ and :kconfig:option:`CONFIG_BT_MESH_PB_GATT_CLIENT` configuration options must b 


	Enable or disable printing of incoming unprovisioned beacons. Allows a provisioner device to

	detect nearby unprovisioned devices and provision them. To enable this command, the

	:kconfig:option:`BT_MESH_SHELL_PROV_CTX_INSTANCE` option must be enabled.

	:kconfig:option:`CONFIG_BT_MESH_SHELL_PROV_CTX_INSTANCE` option must be enabled.



	* ``Val``: Whether to enable the unprovisioned beacon printing.
@@ -499,16 +499,16 @@ enabled, and as long as the Configuration Client model is present in the model c 
application. This shell module can be used for configuring itself and other nodes in the mesh

network.



The Configuration Client uses general message parameters set by ``mesh target dst`` and

``mesh target net`` to target specific nodes. When the Bluetooth mesh shell node is provisioned,

given that the :kconfig:option:`BT_MESH_SHELL_PROV_CTX_INSTANCE` option is enabled with the shell

The Configuration Client uses general message parameters set by ``mesh target dst`` and ``mesh

target net`` to target specific nodes. When the Bluetooth mesh shell node is provisioned, given that

the :kconfig:option:`CONFIG_BT_MESH_SHELL_PROV_CTX_INSTANCE` option is enabled with the shell

provisioning context initialized, the Configuration Client model targets itself by default.

Similarly, when another node has been provisioned by the Bluetooth mesh shell, the Configuration

Client model targets the new node. In most common use-cases, the Configuration Client is depending

on the provisioning features and the Configuration database to be fully functional. 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 the mesh nodes it provisioned. The following steps

are an example of how you can set up a device to start using the Configuration Client commands:

Configuration Client always sends messages using the Device key bound to the destination address, so

it will only be able to configure itself and the mesh nodes it provisioned. The following steps are

an example of how you can set up a device to start using the Configuration Client commands:



* Initialize the client node (``mesh init``).

* Create the CDB (``mesh cdb create``).

doc/kernel/services/interrupts.rst

+1 −1
Original line number Diff line number Diff line
@@ -233,7 +233,7 @@ become shared, meaning the two ISR/argument pairs (previous one and the one that 
has just been registered) will be invoked each time the interrupt is triggered.

The entities that make use of an interrupt line in the shared interrupt context

are known as clients. The maximum number of allowed clients for an interrupt is

controlled by :kconfig:option:`SHARED_IRQ_MAX_NUM_CLIENTS`.

controlled by :kconfig:option:`CONFIG_SHARED_IRQ_MAX_NUM_CLIENTS`.



Interrupt sharing is transparent to the user. As such, the user may register

interrupts using :c:macro:`IRQ_CONNECT` and :c:func:`irq_connect_dynamic` as

doc/services/shell/index.rst

+4 −4
Original line number Diff line number Diff line
@@ -634,21 +634,21 @@ backend and the Log RTT backend does not work by default, because both default 
to channel ``0``. There are two options:



1. The Shell buffer can use an alternate channel, for example using

:kconfig:option:`SHELL_BACKEND_RTT_BUFFER` set to ``1``.

:kconfig:option:`CONFIG_SHELL_BACKEND_RTT_BUFFER` set to ``1``.

This allows monitoring the log using `JLinkRTTViewer

<https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/#j-link-rtt-viewer>`_

while a script interfaces over channel 1.



2. The Log buffer can use an alternate channel, for example using

:kconfig:option:`LOG_BACKEND_RTT_BUFFER` set to ``1``.

:kconfig:option:`CONFIG_LOG_BACKEND_RTT_BUFFER` set to ``1``.

This allows interactive use of the shell through JLinkRTTViewer, while the log

is written to file.



.. warning::

	Regardless of the channel selection, the RTT log backend must be explicitly

	enabled using :kconfig:option:`LOG_BACKEND_RTT` set to ``y``, because it

	enabled using :kconfig:option:`CONFIG_LOG_BACKEND_RTT` set to ``y``, because it

	defaults to ``n`` when the Shell RTT backend is also enabled using

	:kconfig:option:`SHELL_BACKEND_RTT` being set to ``y``.

	:kconfig:option:`CONFIG_SHELL_BACKEND_RTT` being set to ``y``.



Usage

*****

CRA Git | Maintained and supported by SUSTech CRA and CCSE