doc: matter: fix Kconfig references

ArekBalysNordic · ArekBalysNordic · commit 620f81cf2088 · 2025-09-17T14:17:02.000+02:00
Fixed Kconfig references in multiple places.

Signed-off-by: Arkadiusz Balys &lt;arkadiusz.balys@nordicsemi.no&gt;
diff --git a/applications/matter_bridge/doc/matter_bridge_description.rst b/applications/matter_bridge/doc/matter_bridge_description.rst
@@ -382,23 +382,15 @@ Configuration options
 
 Check and configure the following configuration options:
 
-.. _CONFIG_BRIDGED_DEVICE_IMPLEMENTATION:
+.. _CONFIG_BRIDGED_DEVICE_SIMULATED:
 
-CONFIG_BRIDGED_DEVICE_IMPLEMENTATION
-   ``bool`` - Select bridged device implementation.
-   See the :ref:`matter_bridge_app_bridged_support_configs` section for more information.
-   Accepts the following values:
+CONFIG_BRIDGED_DEVICE_SIMULATED
+   ``bool`` - Implement a simulated bridged device.
 
-   .. _CONFIG_BRIDGED_DEVICE_SIMULATED:
+.. _CONFIG_BRIDGED_DEVICE_BT:
 
-   CONFIG_BRIDGED_DEVICE_SIMULATED
-      ``bool`` - Implement a simulated bridged device.
-      You must also configure :ref:`CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_IMPLEMENTATION <CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_IMPLEMENTATION>`
-
-   .. _CONFIG_BRIDGED_DEVICE_BT:
-
-   CONFIG_BRIDGED_DEVICE_BT
-      ``bool`` - Implement a Bluetooth LE bridged device.
+CONFIG_BRIDGED_DEVICE_BT
+   ``bool`` - Implement a Bluetooth LE bridged device.
 
 .. _CONFIG_BRIDGE_HUMIDITY_SENSOR_BRIDGED_DEVICE:
 
@@ -410,21 +402,15 @@ CONFIG_BRIDGE_HUMIDITY_SENSOR_BRIDGED_DEVICE
 CONFIG_BRIDGE_ONOFF_LIGHT_BRIDGED_DEVICE
    ``bool`` - Enable support for OnOff Light bridged device.
 
-.. _CONFIG_BRIDGE_SWITCH_BRIDGED_DEVICE:
-
-CONFIG_BRIDGE_SWITCH_BRIDGED_DEVICE
-   ``bool`` - Enable support for a switch bridged device.
-   Accepts the following values:
+.. _CONFIG_BRIDGE_GENERIC_SWITCH_BRIDGED_DEVICE:
 
-   .. _CONFIG_BRIDGE_GENERIC_SWITCH_BRIDGED_DEVICE:
+CONFIG_BRIDGE_GENERIC_SWITCH_BRIDGED_DEVICE
+   ``bool`` - Enable support for Generic Switch bridged device.
 
-   CONFIG_BRIDGE_GENERIC_SWITCH_BRIDGED_DEVICE
-      ``bool`` - Enable support for Generic Switch bridged device.
+.. _CONFIG_BRIDGE_ONOFF_LIGHT_SWITCH_BRIDGED_DEVICE:
 
-   .. _CONFIG_BRIDGE_ONOFF_LIGHT_SWITCH_BRIDGED_DEVICE:
-
-   CONFIG_BRIDGE_ONOFF_LIGHT_SWITCH_BRIDGED_DEVICE
-      ``bool`` - Enable support for OnOff Light Switch bridged device.
+CONFIG_BRIDGE_ONOFF_LIGHT_SWITCH_BRIDGED_DEVICE
+   ``bool`` - Enable support for OnOff Light Switch bridged device.
 
 .. _CONFIG_BRIDGE_TEMPERATURE_SENSOR_BRIDGED_DEVICE:
 
@@ -443,23 +429,17 @@ CONFIG_BRIDGE_MIGRATE_VERSION_1
 
    If you selected the simulated device implementation using the :ref:`CONFIG_BRIDGED_DEVICE_SIMULATED <CONFIG_BRIDGED_DEVICE_SIMULATED>` Kconfig option, also check and configure the following option:
 
-.. _CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_IMPLEMENTATION:
-
-CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_IMPLEMENTATION
-   ``bool`` - Select the simulated OnOff device implementation.
-   Accepts the following values:
-
-   .. _CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_AUTOMATIC:
+.. _CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_AUTOMATIC:
 
-   CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_AUTOMATIC
-      ``bool`` - Automatically simulated OnOff device.
-      The simulated device automatically changes its state periodically.
+CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_AUTOMATIC
+   ``bool`` - Automatically simulated OnOff device.
+   The simulated device automatically changes its state periodically.
 
-   .. _CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_SHELL:
+.. _CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_SHELL:
 
-   CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_SHELL
-      ``bool`` - Shell-controlled simulated OnOff device.
-      The state of the simulated device is changed using shell commands.
+CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_SHELL
+   ``bool`` - Shell-controlled simulated OnOff device.
+   The state of the simulated device is changed using shell commands.
 
 If you selected the Bluetooth LE device implementation using the :ref:`CONFIG_BRIDGED_DEVICE_BT <CONFIG_BRIDGED_DEVICE_BT>` Kconfig option, also check and configure the following options:
 
diff --git a/doc/nrf/protocols/matter/end_product/factory_provisioning.rst b/doc/nrf/protocols/matter/end_product/factory_provisioning.rst
@@ -140,7 +140,7 @@ The following table lists the parameters of a factory data set:
 | ``rd_uid``             | rotating device ID unique ID         | <16, 32> B           | byte string  | optional    | The unique ID for rotating device ID, which consists of a randomly-generated 128-bit (or longer) octet string.                                                                                                              |
 |                        |                                      |                      |              |             | The rotating device ID is an optional identifier that is used for the :ref:`ug_matter_configuring_ffs` purposes.                                                                                                            |
 |                        |                                      |                      |              |             | This parameter should be protected against reading or writing over-the-air after initial introduction into the device, and stay fixed during the lifetime of the device.                                                    |
-|                        |                                      |                      |              |             | When building an application with the Factory Data support, the `CONFIG_CHIP_FACTORY_DATA_ROTATING_DEVICE_UID_MAX_LEN` must be set with the length of the actual ``rd_uid`` stored in the Factory Data partition.           |
+|                        |                                      |                      |              |             | When building an application with the Factory Data support, the :ref:`CONFIG_CHIP_FACTORY_DATA_ROTATING_DEVICE_UID_MAX_LEN` must be set with the length of the actual ``rd_uid`` stored in the Factory Data partition.           |
 +------------------------+--------------------------------------+----------------------+--------------+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 | ``user``               | User data                            | variable, max 1024 B | CBOR map     | optional    | The user data is provided in the JSON format.                                                                                                                                                                               |
 |                        |                                      |                      |              |             | This parameter is optional and depends on the device manufacturer's purpose.                                                                                                                                                |
@@ -968,7 +968,7 @@ To override the inherited classes, complete the following steps:
 #. Disable building both the default and the nRF Connect implementations of factory data providers to start using your own implementation of factory data parser and provider.
    This can be done in one of the following ways:
 
-   * Set the :kconfig:option:`CONFIG_FACTORY_DATA_CUSTOM_BACKEND` Kconfig option to ``y`` in the :file:`prj.conf` file.
+   * Set the :ref:`CONFIG_FACTORY_DATA_CUSTOM_BACKEND` Kconfig option to ``y`` in the :file:`prj.conf` file.
    * Build an example with the following option (replace ``<build_target>`` with your board name, for example ``nrf52840dk_nrf52840``):
 
      .. parsed-literal::
diff --git a/doc/nrf/protocols/matter/end_product/security.rst b/doc/nrf/protocols/matter/end_product/security.rst
@@ -352,7 +352,7 @@ If the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_DAC_PRIV_KEY_KMU_ENCRYPTED` Kconf
 
 By default, the DAC private key occupies the last slots dedicated for application purposes.
 For the non-encrypted version, it occupies the last two slots (178 and 179), and for the encrypted version, it occupies the last four slots (176-179).
-You can change the default slots by setting the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_DAC_PRIV_KEY_KMU_SLOT` Kconfig option to the first slot number of the desired slots, making sure that all slots fit within the possible range.
+You can change the default slots by setting the :kconfig:option:`CONFIG_CHIP_CRYPTO_PSA_DAC_PRIV_KEY_KMU_SLOT_ID` Kconfig option to the first slot number of the desired slots, making sure that all slots fit within the possible range.
 This means you can set it to slot numbers 0-176 for encrypted, or 0-178 for non-encrypted.
 To read more about KMU slots, see the :ref:`ug_nrf54l_crypto_kmu_slots` section of the :ref:`ug_nrf54l_cryptography` page, which details the KMU peripheral.
 
diff --git a/doc/nrf/protocols/matter/getting_started/advanced_kconfigs.rst b/doc/nrf/protocols/matter/getting_started/advanced_kconfigs.rst
@@ -222,25 +222,25 @@ When the device leaves the last fabric, one of several reactions can be set to h
 
 To enable one of the reactions to the last fabric removal, set the corresponding Kconfig option to ``y``:
 
-* :kconfig:option:`CONFIG_CHIP_LAST_FABRIC_REMOVED_NONE` - Do not react to the last fabric removal.
+* :ref:`CONFIG_CHIP_LAST_FABRIC_REMOVED_NONE` - Do not react to the last fabric removal.
   The device will keep all saved data and network credentials, and will not reboot.
-* :kconfig:option:`CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_ONLY` - Remove all saved network credentials.
+* :ref:`CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_ONLY` - Remove all saved network credentials.
   The device will remove all saved network credentials, keep application-specific non-volatile data, and will not reboot.
-* :kconfig:option:`CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_PAIRING_START` - Remove all saved network credentials and start Bluetooth LE advertising.
+* :ref:`CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_PAIRING_START` - Remove all saved network credentials and start Bluetooth LE advertising.
   The device will remove all saved network credentials, keep application-specific non-volatile data, and start advertising Bluetooth LE Matter service.
   After that, it will be ready for commissioning to Matter over Bluetooth LE.
-* :kconfig:option:`CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_REBOOT` - Remove all saved network credentials and reboot the device.
+* :ref:`CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_REBOOT` - Remove all saved network credentials and reboot the device.
   This option is selected by default.
 
   When the :kconfig:option:`CONFIG_CHIP_FACTORY_RESET_ERASE_SETTINGS` Kconfig option is also set to ``y``, the device will also remove all non-volatile data stored on the device, including application-specific entries.
   This means the device is restored to the factory settings.
 
-To create a delay between  the chosen reaction and the last fabric being removed, set the :kconfig:option:`CONFIG_CHIP_LAST_FABRIC_REMOVED_ACTION_DELAY` Kconfig option to a specific time in milliseconds.
+To create a delay between  the chosen reaction and the last fabric being removed, set the :ref:`CONFIG_CHIP_LAST_FABRIC_REMOVED_ACTION_DELAY` Kconfig option to a specific time in milliseconds.
 By default this Kconfig option is set to 1 second.
 
 .. note::
   The :kconfig:option:`CONFIG_CHIP_FACTORY_RESET_ERASE_SETTINGS` Kconfig option is set to ``y`` by default.
-  To disable removing application-specific non-volatile data when the :kconfig:option:`CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_REBOOT` Kconfig option is selected, set the :kconfig:option:`CONFIG_CHIP_FACTORY_RESET_ERASE_SETTINGS` Kconfig option to ``n``.
+  To disable removing application-specific non-volatile data when the :ref:`CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_REBOOT` Kconfig option is selected, set the :kconfig:option:`CONFIG_CHIP_FACTORY_RESET_ERASE_SETTINGS` Kconfig option to ``n``.
 
 .. _ug_matter_configuring_read_client:
 
diff --git a/doc/nrf/protocols/matter/getting_started/memory_optimization.rst b/doc/nrf/protocols/matter/getting_started/memory_optimization.rst
@@ -67,7 +67,7 @@ Measuring memory usage
 ======================
 
 You can obtain the current memory statistics from the device using Kconfig options and UART shell commands.
-To do this, set the :kconfig:option:`CONFIG_CHIP_MEMORY_PROFILING` global Matter memory profiling Kconfig to ``y``.
+Set the :ref:`CONFIG_CHIP_MEMORY_PROFILING` Kconfig option to ``y``.
 This activates all the other necessary Kconfig options and enables all UART shell commands for measuring memory usage.
 Alternatively, you can enable each option separately.
 
diff --git a/samples/matter/common/config.rst b/samples/matter/common/config.rst
@@ -248,3 +248,78 @@ The following snippets are available:
 
 * ``diagnostic-logs`` - Enables the set of configurations needed for full Matter diagnostic logs support.
   See :ref:`ug_matter_diagnostic_logs_snippet` in the Matter protocol section for more information.
+
+.. _matter_stack_config:
+
+Shared configurations in Matter stack
+#####################################
+
+.. contents::
+   :local:
+   :depth: 2
+
+This page lists Kconfig options and snippets shared by ``sdk-connectedhomeip``.
+See the :ref:`ug_matter_device_advanced_kconfigs` page for more detailed information.
+
+Configuration options
+*********************
+
+Check and configure the following configuration options:
+
+.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ACTION_DELAY:
+
+CONFIG_CHIP_LAST_FABRIC_REMOVED_ACTION_DELAY
+  ``int`` - After removing the last fabric wait defined time [in milliseconds] to perform an action.
+  After removing the last fabric the device will wait for the defined time and then perform an action chosen by the CHIP_LAST_FABRIC_REMOVED_ACTION option.
+  This schedule will allow for avoiding race conditions before the device removes non-volatile data.
+
+.. _CONFIG_FACTORY_DATA_CUSTOM_BACKEND:
+
+CONFIG_FACTORY_DATA_CUSTOM_BACKEND
+  ``bool`` - Enable a custom backend for factory data.
+  This option is used to enable a custom backend for factory data.
+  The custom backend is used to store the factory data in a custom location.
+
+.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_PAIRING_START:
+
+CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_PAIRING_START
+  ``bool`` - After removing the last fabric erase NVS and start Bluetooth LE advertising.
+  After removing the last fabric the device will perform the factory reset without rebooting and start the Bluetooth LE advertisement automatically.
+  The current RAM state will be saved and the new commissioning to the next fabric will use the next possible fabric index.
+  This option should not be used for devices that normally do not advertise Bluetooth LE on boot to keep their original behavior.
+
+.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_REBOOT:
+
+CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_AND_REBOOT
+  ``bool`` - After removing the last fabric erase NVS and reboot.
+  After removing the last fabric the device will perform the factory reset and then reboot.
+  The current RAM state will be removed and the new commissioning to the new fabric will use the initial fabric index.
+  This option is the most safe.
+
+.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_ONLY:
+
+CONFIG_CHIP_LAST_FABRIC_REMOVED_ERASE_ONLY
+  ``bool`` - After removing the last fabric erase NVS only.
+  After removing the last fabric the device will perform the factory reset only without rebooting.
+  The current RAM state will be saved and the new commissioning to the next fabric will use the next possible fabric index.
+
+.. _CONFIG_CHIP_LAST_FABRIC_REMOVED_NONE:
+
+CONFIG_CHIP_LAST_FABRIC_REMOVED_NONE
+  ``bool`` - After removing the last fabric do not perform any action.
+  After removing the last fabric the device will not perform factory reset or reboot.
+  The current state will be left as it is and the BLE advertising will not start automatically.
+
+.. _CONFIG_CHIP_MEMORY_PROFILING:
+
+CONFIG_CHIP_MEMORY_PROFILING
+  ``bool`` - Enable features for tracking memory usage.
+  Enables features for tracking memory usage in Matter.
+
+.. _CONFIG_CHIP_NUS:
+
+CONFIG_CHIP_NUS
+  ``bool`` - Enable Nordic UART service for Matter purposes.
+  Enables Nordic UART service (NUS) for Matter samples.
+  Using NUS service you can control a Matter sample using pre-defined BLE commands and do defined operations.
+  The CHIP NUS service can be useful to keep communication with a smart home device when a connection within Matter network is lost.
diff --git a/samples/matter/light_bulb/README.rst b/samples/matter/light_bulb/README.rst
@@ -187,10 +187,6 @@ To set up an AWS IoT instance and configure the sample, complete the following s
 #. Observe that the light bulb changes state.
    The local changes to the attributes always take precedence over what is set in the shadow's desired state.
 
-.. note::
-   The integration layer has built-in reconnection logic and tries to maintain the connection as long as the device is connected to the internet.
-   The reconnection interval can be configured using the :kconfig:option:`CONFIG_AWS_IOT_RECONNECTION_INTERVAL_SECONDS` option.
-
 User interface
 **************
 
diff --git a/samples/matter/lock/README.rst b/samples/matter/lock/README.rst
@@ -340,7 +340,7 @@ Factory data support
 Enabling Matter Bluetooth LE with Nordic UART Service
 =====================================================
 
-You can enable the :ref:`matter_lock_sample_ble_nus` feature by setting the :kconfig:option:`CONFIG_CHIP_NUS` Kconfig option to ``y``.
+You can enable the :ref:`matter_lock_sample_ble_nus` feature by setting the :ref:`CONFIG_CHIP_NUS` Kconfig option to ``y``.
 
 .. note::
    This sample supports one Bluetooth LE connection at a time.
@@ -809,7 +809,7 @@ To test the :ref:`matter_lock_sample_ble_nus` feature, complete the following st
    Some of the steps depend on which :ref:`configuration <matter_lock_sample_custom_configs>` the sample was built with.
 
 #. Install `nRF Toolbox`_ on your Android (Android 11 or newer) or iOS (iOS 16.1 or newer) smartphone.
-#. Build the door lock application for Matter over Thread with the :kconfig:option:`CONFIG_CHIP_NUS` set to ``y``.
+#. Build the door lock application for Matter over Thread with the :ref:`CONFIG_CHIP_NUS` set to ``y``.
    For example, if you build from command line for the ``nrf52840dk/nrf52840``, use the following command:
 
    .. code-block:: console
