doc: Bluetooth: Mesh: Align wording for models instantiation req

According to https://github.com/zephyrproject-rtos/zephyr/pull/61886#issuecomment-1713302331
we need to use "must only" for models that spec states:
`If supported, ... shall be supported by the primary element and shall
not be supported by any secondary element`.

Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This commit is contained in:
Pavel Vasilyev 2023-09-12 10:22:59 +02:00 committed by Carles Cufí
commit 422cfeeb1a
13 changed files with 24 additions and 23 deletions

View file

@ -17,8 +17,8 @@ All configuration functions in the Configuration Client API have ``net_idx``
and ``addr`` as their first parameters. These should be set to the network
index and primary unicast address that the target node was provisioned with.
The Configuration Client model is optional, but should be instantiated on the
first element if it is present in the composition data.
The Configuration Client model is optional, and it must only be instantiated on the
primary element if present in the Composition Data.
API reference
*************

View file

@ -15,7 +15,7 @@ mesh node. It does not have an API of its own, but relies on a
controlled through the :ref:`bluetooth_mesh_heartbeat` API.
The Configuration Server model is mandatory on all Bluetooth mesh nodes, and
should be instantiated in the first element.
must only be instantiated on the primary element.
API reference
*************

View file

@ -12,9 +12,9 @@ used in this function call. The second parameter is the ``ctx`` or message
context. Message context contains netkey index, appkey index and unicast
address that the target node uses.
The Health Client model is optional, and may be instantiated in any element.
However, if a Health Client model is instantiated in an element other than the
first, an instance must also be present in the first element.
The Health Client model is optional, and may be instantiated on any element.
However, if a Health Client model is instantiated on an element other than the
primary, an instance must also be present on the primary element.
See :ref:`bluetooth_mesh_health_faults` for a list of specification defined
fault values.

View file

@ -7,6 +7,8 @@ The Health Server model provides attention callbacks and node diagnostics for
:ref:`bluetooth_mesh_models_health_cli` models. It is primarily used to report
faults in the mesh node and map the mesh nodes to their physical location.
If present, the Health Server model must be instantiated on the primary element.
Faults
******

View file

@ -13,6 +13,9 @@ how long a node will advertise Mesh Proxy Service with Private Network Identity
The On-Demand Private Proxy Client model communicates with an On-Demand Private Proxy Server model
using the device key of the node containing the target On-Demand Private Proxy Server model instance.
If present, the On-Demand Private Proxy Client model must only be instantiated on the primary
element.
Configurations
**************

View file

@ -17,7 +17,7 @@ The On-Demand Private Proxy Server does not have an API of its own, and relies o
:ref:`bluetooth_mesh_od_cli` to control it. The On-Demand Private Proxy Server
model only accepts messages encrypted with the node's device key.
If present, the On-Demand Private Proxy Server model must be instantiated on the primary
If present, the On-Demand Private Proxy Server model must only be instantiated on the primary
element.
API reference

View file

@ -13,11 +13,11 @@ a sequence of access layer messages to nodes supporting the :ref:`bluetooth_mesh
The Opcodes Aggregator Client model communicates with an Opcodes Aggregator Server model
using the device key of the target node or the application keys configured by the Configuration Client.
The Opcodes Aggregator Client model must only be instantiated on the primary
element, and it is implicitly bound to the device key on initialization.
If present, the Opcodes Aggregator Client model must only be instantiated on the primary element.
The Opcodes Aggregator Client model should be bound to the same application keys that the client models,
used to produce the sequence of messages, are bound to.
The Opcodes Aggregator Client model is implicitly bound to the device key on initialization. It
should be bound to the same application keys as the client models that are used to produce the sequence of
messages.
To be able to aggregate a message from a client model, it should support an asynchronous
API, for example through callbacks.

View file

@ -13,8 +13,7 @@ a sequence of access layer messages.
The Opcodes Aggregator Server model accepts messages encrypted with the node's device key
or the application keys.
The Opcodes Aggregator Server model can only be instantiated on the
node's primary element.
If present, the Opcodes Aggregator Server model must only be instantiated on the primary element.
The targeted server models should be bound to the same application key that is used
to encrypt the sequence of access layer messages sent to the Opcodes Aggregator Server.

View file

@ -25,8 +25,7 @@ All configuration functions in the Private Beacon Client API have ``net_idx``
and ``addr`` as their first parameters. These should be set to the network
index and the primary unicast address the target node was provisioned with.
The Private Beacon Client model is optional, and can be instantiated on any
element.
If present, the Private Beacon Client model must only be instantiated on the primary element.
API reference
*************

View file

@ -28,8 +28,7 @@ Server model through the :c:struct:`bt_mesh_priv_beacon_srv` instance passed to
changes to this configuration in the settings subsystem, the initial values may
be overwritten upon loading.
The Private Beacon Server model is optional, and can only be instantiated in the
node's primary element.
If present, the Private Beacon Server model must only be instantiated on the primary element.
API reference
*************

View file

@ -15,8 +15,7 @@ The Remote Provisioning Server does not have an API of its own, but relies on a
:ref:`bluetooth_mesh_models_rpr_cli` to control it. The Remote Provisioning Server
model only accepts messages encrypted with the node's device key.
If present, the Remote Provisioning Server model must be instantiated on the primary
element.
If present, the Remote Provisioning Server model must be instantiated on the primary element.
Note that after refreshing the device key, node address or Composition Data through a Node Provisioning Protocol
Interface (NPPI) procedure, the :c:member:`bt_mesh_prov.reprovisioned` callback is triggered. See section

View file

@ -13,8 +13,8 @@ replay protection list (SRPL) of a node that supports the :ref:`bluetooth_mesh_s
The Solicitation PDU RPL Configuration Client model communicates with a Solicitation PDU RPL Configuration Server model
using the application keys configured by the Configuration Client.
If present, the Solicitation PDU RPL Configuration Client model must be instantiated on the primary
element.
If present, the Solicitation PDU RPL Configuration Client model must only be instantiated on the
primary element.
Configurations
**************

View file

@ -14,8 +14,8 @@ successfully processed by a node, the SSRC field and SSEQ field of the message a
The Solicitation PDU RPL Configuration Server does not have an API of its own, and relies on a :ref:`bluetooth_mesh_srpl_cli` to control it.
The model only accepts messages encrypted with an application key as configured by the Configuration Client.
If present, the Solicitation PDU RPL Configuration Server model must be instantiated on the primary
element.
If present, the Solicitation PDU RPL Configuration Server model must only be instantiated on the
primary element.
Configurations
**************