docs: Align with add-on

Signed-off-by: Arkadiusz Balys <arkadiusz.balys@nordicsemi.no>

Author: ArekBalysNordic

docs/include/requirements/thread.txt

@@ -1,4 +1,4 @@
-If you want to commission the |matter_name| device and control it remotely through a Thread network, you need to set-up the `Thread Border Router <Thread Border Router>`_ and control it with the `chip-tool`_, or use a commercial ecosystem controller.
+If you want to commission the |matter_name| device and control it remotely through a Thread network, you need to set-up the `Thread Border Router <Thread Border Router>`_ and control it with the :ref:`CHIP Tool <ug_matter_gs_tools_chip>`, or use a commercial ecosystem controller.
 When this happens, you will also be able to control it through a Matter controller device :ref:`configured on PC or smartphone <ug_matter_configuring>`.
 This requires additional hardware depending on the setup you choose.
 

docs/include/requirements/thread_wifi.txt

@@ -1,4 +1,4 @@
-If you want to commission the |matter_name| device and control it remotely through a Thread or Wi-Fi network, you need to set-up the `Thread Border Router <Thread Border Router>`_ (Matter over Thread only) and control it with the `chip-tool`_, or use a commercial ecosystem controller.
+If you want to commission the |matter_name| device and control it remotely through a Thread or Wi-Fi network, you need to set-up the `Thread Border Router <Thread Border Router>`_ (Matter over Thread only) and control it with the :ref:`CHIP Tool <ug_matter_gs_tools_chip>`, or use a commercial ecosystem controller.
 When this happens, you will also be able to control it through a Matter controller device :ref:`configured on PC or smartphone <ug_matter_configuring>`.
 This requires additional hardware depending on the setup you choose.
 

docs/includes/sample_board_rows.txt

@@ -2,14 +2,40 @@
 
 | Hardware platforms | PCA | Board name | Board target |
 
+.. nrf52840dk_nrf52840
+
+| `Developing with nRF52 Series`_ | PCA10056 | `nrf52840dk`_ | ``nrf52840dk/nrf52840`` |
+
+.. nrf5340dk_nrf5340_cpuapp
+
+| `Developing with nRF53 Series`_ | PCA10095 | `nrf5340dk`_ | ``nrf5340dk/nrf5340/cpuapp`` |
+
 .. nrf54l15dk_nrf54l15_cpuapp
 
 | `Developing with nRF54L Series`_ | PCA10156 | `nrf54l15dk`_ | ``nrf54l15dk/nrf54l15/cpuapp`` |
 
+.. nrf54l15dk_nrf54l15_cpuapp_ns
+
+| `Developing with nRF54L Series`_ | PCA10156 | `nrf54l15dk`_ | ``nrf54l15dk/nrf54l15/cpuapp/ns`` |
+
+.. nrf54l15dk_nrf54l10_cpuapp
+
+| `Developing with nRF54L Series`_ | PCA10156 | `nrf54l15dk`_ | ``nrf54l15dk/nrf54l10/cpuapp`` |
+
 .. nrf54lm20dk_nrf54lm20a_cpuapp
 
 | `Developing with nRF54L Series`_ | PCA10184 | `nrf54lm20dk`_ | ``nrf54lm20dk/nrf54lm20a/cpuapp`` |
 
 .. nrf54lm20dk_nrf54lm20b_cpuapp
 
 | `Developing with nRF54L Series`_ | PCA10184 | `nrf54lm20dk`_ | ``nrf54lm20dk/nrf54lm20b/cpuapp`` |
+
+.. nrf54l15tag_nrf54l15_cpuapp
+
+| `Developing with nRF54L Series`_ | PCA10156 | `nrf54l15dk`_ | ``nrf54l15tag/nrf54l15/cpuapp`` |
+
+.. nrf54l15dk_nrf54l15_cpuapp_and_cpuapp_ns
+
+| `Developing with nRF54L Series`_ | PCA10156 | `nrf54l15dk`_ | ``nrf54l15dk/nrf54l15/cpuapp``    |
+|                                |          |                                         |                                   |
+|                                |          |                                         | ``nrf54l15dk/nrf54l15/cpuapp/ns`` |

docs/index.rst

@@ -11,8 +11,8 @@ In combination with the |NCS|, the |addon| allows for development of Matter acce
 
 For additional context on other solutions, refer to the following resources:
 
-* `Matter overview`_ — Introduction to the Matter protocol and its use in the |NCS|.
-* `Matter architecture`_ — How Matter accessories, controllers, and networks fit together.
+* :ref:`Matter overview <ug_matter_intro_overview>` — Introduction to the Matter protocol and its use in the |NCS|.
+* :ref:`ug_matter_overview_architecture` — How Matter accessories, controllers, and networks fit together.
 * `Matter add-on repository`_ — Source code for the Matter add-on.
 
 .. toctree::
@@ -21,6 +21,8 @@ For additional context on other solutions, refer to the following resources:
    :glob:
 
    setup
+   samples/index
+   snippets/index
    matter/index
    config
    release_notes

docs/links.txt

@@ -17,6 +17,8 @@
 .. _`Matter nRF Connect releases`: https://github.com/nrfconnect/sdk-connectedhomeip/releases
 .. _`Thread tools`: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/protocols/thread/tools.html
 .. _`Running OTBR using Docker`: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/protocols/thread/tools.html#ug-thread-tools-tbr-docker
+.. _`nRF Sniffer for 802.15.4`: https://docs.nordicsemi.com/bundle/ug_sniffer_802154/page/UG/sniffer_802154/intro_802154.html
+.. _`nRF Thread Topology Monitor`: https://docs.nordicsemi.com/bundle/ug_nrf_ttm/page/UG/nrf_ttm/ttm_introduction.html
 .. _`Testing Matter in the NCS`: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/protocols/matter/getting_started/testing/index.html
 .. _`Matter controller`: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/protocols/matter/overview/network_topologies.html#ug-matter-configuring-controller
 .. _`Onboarding information formats`: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/protocols/matter/overview/commissioning.html#ug-matter-network-topologies-commissioning-onboarding-formats
@@ -34,6 +36,16 @@
 
 .. ### Matter add-on external :ref: targets
 
+.. _app_approtect: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/security/ap_protect.html
+.. _ug_thread_tools: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/protocols/thread/tools.html
+.. _ug_thread_tools_tbr: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/protocols/thread/tools.html#ug-thread-tools-tbr
+.. _partition_manager: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/scripts/partition_manager/partition_manager.html
+.. _migration_partitions: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/releases_and_maturity/migration/migration_partitions.html
+.. _ncs_release_notes_340: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/releases_and_maturity/releases/release-notes-3.4.0.html
+.. _`Power optimization recommendations`: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/test_and_optimize/optimizing/power_general.html
+.. _`Disable unused pins and peripherals`: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/test_and_optimize/optimizing/power_general.html#disable-unused-pins-and-peripherals
+.. _`Enable Device Power Management module`: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/test_and_optimize/optimizing/power_general.html#enable-device-power-management-module
+.. _`Configure radio transmitter power`: https://docs.nordicsemi.com/bundle/ncs-|ncs_version|/page/nrf/test_and_optimize/optimizing/power_general.html#configure-radio-transmitter-power
 
 .. ### Matter documentation backtick links (from sdk-nrf links.txt)
 

docs/matter/end_product/attestation.rst

@@ -153,10 +153,12 @@ Dedicating a separate partition for this purpose lets avoid recertification when
 
 For information about how to generate the factory data, read the detailed :ref:`ug_matter_device_factory_provisioning` guide in the Matter documentation.
 
+.. _ug_matter_device_attestation_secured_communication:
+
 Requirements for secured communication
 ======================================
 
-Before the commissioner can verify the DAC information, it must establish a secure PASE session, which is required for sending commissioning messages, including the `Device Attestation procedure`_.
+Before the commissioner can verify the DAC information, it must establish a secure PASE session, which is required for sending commissioning messages, including the :ref:`Device Attestation procedure <ug_matter_device_attestation_procedure>`.
 
 The Verifier is used for this purpose.
 This is one of the input values of the underlying SPAKE2+ protocol.
@@ -183,12 +185,12 @@ Product Attestation Intermediate certificate
 
 Verifier
   The Verifier itself is not a part of the DAC, although it is included in the factory data.
-  See `Requirements for secured communication`_.
+  See :ref:`Requirements for secured communication <ug_matter_device_attestation_secured_communication>`.
 
 Certification Declaration
   This is |matter_cd_definition|.
   It contains a series of information required for Device Attestation, including Vendor ID, Certificate ID, certification type, optional information related to DAC, and other.
-  CD is included in the attestation information packet send by the commissionee during the `Device Attestation procedure`_.
+  CD is included in the attestation information packet send by the commissionee during the :ref:`Device Attestation procedure <ug_matter_device_attestation_procedure>`.
 
   .. note::
       The CD information is not located in the factory data, but in the application itself.
@@ -198,6 +200,8 @@ Certification Declaration
 
 These are the elements that are checked and validated by the commissioner at the start of the commissioning procedure.
 
+.. _ug_matter_device_attestation_procedure:
+
 Device Attestation procedure
 ****************************
 

docs/matter/end_product/bootloader.rst

@@ -16,15 +16,15 @@ Adding MCUboot to application
 *****************************
 
 Read :ref:`ug_bootloader_adding_sysbuild_immutable_mcuboot` to learn how to add MCUboot to an |NCS| application.
-Some Matter samples include :term:`Device Firmware Update (DFU)` support out of the box, as listed in the :ref:`sample feature matrix table <matter_samples>`.
+Some Matter samples include Device Firmware Update (DFU) support out of the box, as listed in the :ref:`sample feature matrix table <matter_samples>`.
 
 MCUboot minimal configuration
 *****************************
 
 MCUboot is by default configured to enable debug features, such as logs.
 You can reduce the size of the bootloader image by disabling unnecessary features.
 
-See the following files for the MCUboot minimal configuration used by :ref:`Matter samples <matter_samples>` in the |NCS|:
+See the following files for the MCUboot minimal configuration used by :ref:`matter_samples` in the |NCS|:
 
 * :file:`prj.conf` file located in each sample's :file:`sysbuild/mcuboot` directory
 * Board files located in each sample's :file:`sysbuild/mcuboot/boards` directory
@@ -37,7 +37,17 @@ This configuration allows to reduce the flash partition occupied by MCUboot to 2
 Partition layout
 ****************
 
-.. include:: ../../../includes/pm_deprecation.txt
+.. note::
+   The :ref:`partition_manager` is a component in the |NCS| and is responsible for handling the memory partitioning at build time.
+
+   This functionality is in the process of being deprecated and replaced by Zephyr's default devicetree-based memory partitioning.
+   It is recommended that all new designs using Nordic devices are to be built with DTS instead of Partition Manager.
+   Partition Manager will be removed from the |NCS| by the end of 2026 from the main branch.
+
+   For more information on how to configure partitions using DTS and how to migrate your existing configuration to DTS, see the following pages:
+
+   * :ref:`migration_partitions`
+   * :ref:`ncs_release_notes_340`
 
 A bootloader is a critical component in a Matter device, ensuring secure firmware updates and authenticating new application images.
 All Nordic Matter samples in the |NCS| use MCUboot as the primary bootloader, with configuration and partitioning adapted to application and device needs.
@@ -174,11 +184,11 @@ The following tables summarize the partitions by target.
 Settings partition
 ==================
 
-The nRF Connect platform in Matter uses Zephyr's :ref:`zephyr:settings_api` API to provide the storage capabilities to the Matter stack.
+The nRF Connect platform in Matter uses Zephyr's `Settings <Settings>`_ API to provide the storage capabilities to the Matter stack.
 This requires that you define the ``settings_storage`` partition in the flash.
 The recommended minimum size of the partition is 32 kB, but you can reserve even more space if your application uses the storage extensively.
 
-The Zephyr settings storage is implemented by the :ref:`Zephyr NVS (Non-Volatile Storage) <zephyr:nvs_api>` or :ref:`ZMS (Zephyr Memory Storage) <zephyr:zms_api>` backends.
+The Zephyr settings storage is implemented by the `Zephyr NVS (Non-Volatile Storage) <Non-Volatile Storage (NVS)>`_ or `ZMS (Zephyr Memory Storage) <ZMS (Zephyr Memory Storage)>`_ backends.
 You can select either backend, and the selection affects several factors, such as the operational performance or memory lifetime.
 To achieve the optimal experience, it is recommended to use:
 

docs/matter/end_product/certification.rst

@@ -100,7 +100,7 @@ Reporting
 =========
 
 After the Matter component successfully passes all required test cases, the ATL sends a test report to both you and CSA.
-The test report summarizes the testing process and includes a variety of information, including details about the device, `Certification types`_, test plans, and Test Harness.
+The test report summarizes the testing process and includes a variety of information, including details about the device, :ref:`Certification types <ug_matter_device_certification_types>`, test plans, and Test Harness.
 
 Application
 ===========
@@ -401,6 +401,8 @@ In contrast, portfolio certification accommodates devices that may differ at the
 
 For more details, read a dedicated document in the `Matter Resource Kit`_.
 
+.. _ug_matter_device_product_family_certification:
+
 Product Family Certification
 ----------------------------
 
@@ -423,7 +425,7 @@ Certification by Similarity
 ---------------------------
 
 Certification by Similarity lets you certify products that derive from a previously certified product.
-This variant is meant for Matter components that use Matter software that was already certified as part of either the standard procedure or the `Product Family certification`_.
+This variant is meant for Matter components that use Matter software that was already certified as part of either the standard procedure or the :ref:`Product Family certification <ug_matter_device_product_family_certification>`.
 
 .. figure:: images/matter_device_certification_process_cbs.svg
    :alt: Matter certification by similarity overview

docs/matter/end_product/ecosystems_certification.rst

@@ -25,11 +25,11 @@ The Matter samples delivered in the |NCS| have not received official certificate
 However, they have been tested against the Works with Google Home certification test cases and have successfully passed all of them.
 The following is a full list of Matter samples that were verified to pass the Works with Google certification test cases:
 
-* :ref:`matter_lock_sample`
-* :ref:`matter_light_bulb_sample`
-* :ref:`matter_thermostat_sample`
-* :ref:`matter_window_covering_sample`
-* :ref:`matter_weather_station_app`
+* `Matter lock sample <Matter lock sample>`_
+* `Matter light bulb sample <Matter light bulb sample>`_
+* `Matter thermostat sample <Matter thermostat sample>`_
+* `Matter window covering sample <Matter window covering sample>`_
+* `Matter Weather Station sample <Matter Weather Station sample>`_
 
 .. _ug_matter_amazon_certification:
 
@@ -53,12 +53,12 @@ This means that if you create a Matter product based on the |NCS|, you can appro
 You can do this by filling the Reference APID field when you register your product on Amazon's developer page.
 Use one of the following values:
 
-+-----------------------------------------------------------+-----------------------+
-| Matter platform variant                                   | Reference Design APID |
-+===========================================================+=======================+
-| :ref:`nRF52840 DK <ug_nrf52>` (Matter over Thread)        | ZNwt                  |
-+-----------------------------------------------------------+-----------------------+
-| :ref:`nRF5340 DK <ug_nrf5340>` (Matter over Thread)       | xzNd                  |
-+-----------------------------------------------------------+-----------------------+
-| :ref:`nRF7002 DK <ug_nrf70>` (Matter over Wi-Fi®)         | jyjh                  |
-+-----------------------------------------------------------+-----------------------+
++-----------------------------------------------------------------------------+-----------------------+
+| Matter platform variant                                                     | Reference Design APID |
++=============================================================================+=======================+
+| `nRF52 Series <Developing with nRF52 Series>`_ (Matter over Thread)         | ZNwt                  |
++-----------------------------------------------------------------------------+-----------------------+
+| `nRF53 Series <Developing with nRF53 Series>`_ (Matter over Thread)         | xzNd                  |
++-----------------------------------------------------------------------------+-----------------------+
+| `nRF70 Series <Developing with nRF70 Series>`_ (Matter over Wi-Fi®)         | jyjh                  |
++-----------------------------------------------------------------------------+-----------------------+

docs/matter/end_product/factory_provisioning.rst

@@ -663,13 +663,13 @@ Preparing factory data partition on a device
 ============================================
 
 The factory data partition is an area in the device's persistent storage, where the factory data set is stored.
-This area is configured using the :ref:`partition_manager`, within which all partitions are declared in the :file:`pm_static.yml` file.
+This area is configured using the `Partition Manager <Partition Manager>`_, within which all partitions are declared in the :file:`pm_static.yml` file.
 
 To prepare an example that supports factory data, add a partition called ``factory_data`` to the :file:`pm_static.yml` file.
 The partition size should be a multiple of one flash page (for nRF52 and nRF53 SoCs, a single page size equals 4 kB).
 
 See the following code snippet for an example of a factory data partition in the :file:`pm_static.yml` file.
-The snippet is based on the :file:`pm_static.yml` file from the :ref:`matter_lock_sample` and uses the nRF52840 DK:
+The snippet is based on the :file:`pm_static.yml` file from the `Matter lock sample <Matter lock sample>`_ and uses the nRF52840 DK:
 
 .. parsed-literal::
    :class: highlight
@@ -694,7 +694,17 @@ The snippet is based on the :file:`pm_static.yml` file from the :ref:`matter_loc
 In this example, a ``factory_data`` partition has been placed between the application partition (``mcuboot_primary_app``) and the settings storage.
 Its size has been set to one flash page (4 kB).
 
-.. include:: ../../../includes/pm_deprecation.txt
+.. note::
+   The :ref:`partition_manager` is a component in the |NCS| and is responsible for handling the memory partitioning at build time.
+
+   This functionality is in the process of being deprecated and replaced by Zephyr's default devicetree-based memory partitioning.
+   It is recommended that all new designs using Nordic devices are to be built with DTS instead of Partition Manager.
+   Partition Manager will be removed from the |NCS| by the end of 2026 from the main branch.
+
+   For more information on how to configure partitions using DTS and how to migrate your existing configuration to DTS, see the following pages:
+
+   * :ref:`migration_partitions`
+   * :ref:`ncs_release_notes_340`
 
 Use Partition Manager's report tool to ensure you created the factory data partition correctly.
 Navigate to the example directory and run the following command:
@@ -895,8 +905,8 @@ Another way to program the factory data to a device is to use the nRF Connect pl
 
    $ west build -b nrf52840dk_nrf52840 -- \
    -DCONFIG_CHIP_FACTORY_DATA=y \
-   -DSB_CONFIG_MATTER_FACTORY_DATA_GENERATE=y \
-   -DSB_CONFIG_MATTER_FACTORY_DATA_MERGE_WITH_FIRMWARE=y
+   -DSB_CONFIG_MATTER_ADD_ON_FACTORY_DATA_GENERATE=y \
+   -DSB_CONFIG_MATTER_ADD_ON_FACTORY_DATA_MERGE_WITH_FIRMWARE=y
 
 You can also build an example with auto-generation of new CD, DAC and PAI certificates.
 The newly generated certificates will be added to factory data set automatically.