doc: Doc check and fixes for 2.7

Doc check and fixes for 2.7

Signed-off-by: Uma Praseeda <[email protected]>

Author: umapraseeda

nrf_modem/include/nrf_modem_dect_phy.h

@@ -1131,7 +1131,7 @@ int nrf_modem_dect_phy_deinit(void);
  * Incoming data received on the physical layer control and data channels is sent to the
  * @ref nrf_modem_dect_phy_callbacks.pcc and @ref nrf_modem_dect_phy_callbacks.pdc callbacks.
  *
- * When the operation has completed, either successfully or unsuccesfully, the result is sent
+ * When the operation has completed, either successfully or unsuccessfully, the result is sent
  * to the @ref nrf_modem_dect_phy_callbacks.op_complete callback, with a `handle`
  * parameter equal to the `handle` specified in @p params.
  *
@@ -1149,7 +1149,7 @@ int nrf_modem_dect_phy_rx(const struct nrf_modem_dect_phy_rx_params *params);
  *
  * Schedule a data transmission with given parameters.
  *
- * When the operation has completed, either successfully or unsuccesfully, the result is sent
+ * When the operation has completed, either successfully or unsuccessfully, the result is sent
  * to the @ref nrf_modem_dect_phy_callbacks.op_complete callback, with a `handle`
  * parameter equal to the `handle` specified in @p params.
  *
@@ -1177,7 +1177,7 @@ int nrf_modem_dect_phy_tx(const struct nrf_modem_dect_phy_tx_params *params);
  * received. In that case modem will inject ACK or NACK feedback into the Transmission feedback
  * field based on the PDC reception result once the reception is complete.
  *
- * When the operation has completed, either successfully or unsuccesfully, the result is sent
+ * When the operation has completed, either successfully or unsuccessfully, the result is sent
  * to the @ref nrf_modem_dect_phy_callbacks.op_complete callback, with a `handle`
  * parameter equal to the `handle` specified in @p params.
  *
@@ -1200,11 +1200,11 @@ int nrf_modem_dect_phy_tx_harq(const struct nrf_modem_dect_phy_tx_params *params
  * The RX operation scheduling is relative to the end of the TX operation and must include
  * the guard time.
  *
- * When the TX operation has completed, either successfully or unsuccesfully, the result is sent
+ * When the TX operation has completed, either successfully or unsuccessfully, the result is sent
  * to the @ref nrf_modem_dect_phy_callbacks.op_complete callback, with a `handle`
  * parameter equal to the `handle` specified in @p params.tx.
  *
- * When the RX operation has completed, either successfully or unsuccesfully, the result is sent
+ * When the RX operation has completed, either successfully or unsuccessfully, the result is sent
  * to the @ref nrf_modem_dect_phy_callbacks.op_complete callback, with a `handle`
  * parameter equal to the `handle` specified in @p params.rx.
  *
@@ -1223,7 +1223,7 @@ int nrf_modem_dect_phy_tx_rx(const struct nrf_modem_dect_phy_tx_rx_params *param
  * Schedule an RSSI measurement operation with given parameters.
  * The measurements are sent to the @ref nrf_modem_dect_phy_callbacks.rssi callback.
  *
- * When the operation has completed, either successfully or unsuccesfully, the result is sent
+ * When the operation has completed, either successfully or unsuccessfully, the result is sent
  * to the @ref nrf_modem_dect_phy_callbacks.op_complete callback, with a `handle`
  * parameter equal to the `handle` specified in @p params.
  *

nrf_rpc/doc/protocol_specification.rst

@@ -58,7 +58,7 @@ A description of the various fields and their meaning:
   The remote processor is then obliged to use the source context ID as the destination context ID in the response packet.
   This ensures that responses and any packets that follow within each conversation are correctly routed to the initiating thread.
 
-  The exact source context ID allocation pattern is implementation-defined, meaning that when the packet sender intiates a new conversation or responds to the initiating packet, it is free to allocate any unused source context ID for the new conversation.
+  The exact source context ID allocation pattern is implementation-defined, meaning that when the packet sender initiates a new conversation or responds to the initiating packet, it is free to allocate any unused source context ID for the new conversation.
 
 ``Command ID``: 8 bits
   Identifies an individual command or event within an nRF RPC group.

softdevice_controller/CHANGELOG.rst

@@ -35,7 +35,7 @@ Changes
   Generally, this change will result in either increased scanning time, or similar scanning time to before.
   In cases where there are many conflicting activities within the scan window, this change may result in reduced scanning time. (DRGN-19050)
 * Scan windows are no longer limited to 16 seconds. (DRGN-19050)
-* The deprecated functions :c:func:`rand_prio_low_get` and :c:func:`rand_prio_high_get` have been removed.
+* The deprecated structure members ``sdc_rand_source_t.rand_prio_low_get`` and ``sdc_rand_source_t.rand_prio_high_get`` have been removed.
   This change does not affect applications developed in the |NCS| context. (DRGN-20473)
 * The HCI commands used to configure a scanner or initiator no longer return ``BT_HCI_ERR_INVALID_PARAM`` when the sum of scan windows is greater than the scan interval.
   Now the controller will truncate the scan windows so that the sum of the windows fit within the scan interval. (DRGN-21710)
@@ -57,13 +57,13 @@ Changes
 Bug fixes
 =========
 
-* Fixed an issue where an assert could happen if a initiator ran for more than 2147 seconds before connecting (DRGN-22163).
+* Fixed an issue where an assert could happen if an initiator ran for more than 2147 seconds before connecting (DRGN-22163).
 * Fixed an extremely rare race condition where using :c:func:`sdc_soc_ecb_block_encrypt` from an ISR could lead to encryption failures. (DRGN-21603)
 * Fixed an issue where the vendor-specific ISO Read TX Timestamp command returned a timestamp that was 41 µs too small (DRGN-21605).
 * Fixed an issue where an assert could happen if a CIS peripheral stopped receiving packets from the CIS central.
   This would only occur after the window widening reached at least half of the ISO interval in magnitude.
   Assuming worst case clock accuracies on both central and peripheral, this would correspond to 2.4, 3.7, and 4.9 seconds for ISO intervals of 5 ms, 7.5 ms, and 10 ms.
-  This issue would not occur if the supervision timeout was set to a value smaller than the onces mentioned above (DRGN-21619).
+  This issue would not occur if the supervision timeout was set to a value smaller than the ones mentioned above (DRGN-21619).
 * Fixed an issue where the peripheral waited for a link to time out when tearing down the connection.
   This happened when the central would acknowledge ``TERMINATE_IND`` in the same event as it was being sent (DRGN-21637).
 * Fixed an issue where the |controller| would accept the HCI LE Set Random Address command while passive scanning had been enabled.

softdevice_controller/doc/isochronous_channels.rst

@@ -61,7 +61,7 @@ Configurations for parallel use of CIS and BIS
 
 Parallel use of one CIS and one BIS is tested.
 However, there is no absolute maximum of BISes, CISes and ACLs that can be used concurrently.
-Instead, the amount of roles that can be used at the same time is limited by available memory and the on-air timings.
+Instead, the number of roles that can be used at the same time is limited by available memory and the on-air timings.
 
 Tested topologies
 *****************
@@ -194,7 +194,7 @@ Time of arrival
    Expect a larger latency if data is not provided every SDU interval and the stream is configured with retransmissions.
    This is due to the fact that the controller first needs to send empty data packets for the data that was not provided.
    In case data is missing, the controller sends NULL data every ISO event.
-   This also ensures that the data provided with the time of arrival mode is retransmitted the configured amount of times.
+   This also ensures that the data provided with the time of arrival mode is retransmitted the configured number of times.
 
    Use this mode if the exact time when an SDU is sent does not matter or if SDUs are only produced at a rate much smaller than the SDU interval.
    To use this mode, set the sequence number to 0 and do not add a timestamp to the HCI ISO data.
@@ -208,7 +208,7 @@ Sequence numbers
    The controller learns the initial sequence number, so there is no need to align the sequence number each time with the one that is returned when calling the HCI VS ISO Read TX Timestamp command.
 
    Pay special attention on the CIS peripheral side, because the timings of ISO are based on the central's clock.
-   This means that you need to account for drift between the central's and the peripheral's clocks for the the generation of SDUs.
+   This means that you need to account for drift between the central's and the peripheral's clocks for the generation of SDUs.
    To do this, use the HCI VS ISO Read TX Timestamp command.
    The command provides a timestamp corresponding to the last possible point in time that the previous SDU could have been provided.
    When combined with the SDU interval, this gives an indication of the last possible time when an SDU can be provided.
@@ -230,7 +230,7 @@ The application needs to inform the |controller| which SDUs should be time-synch
 
 The recommended way to provide this information is using the timestamps mode.
 Using the same timestamp for multiple SDUs guarantees that the SDUs are time-synchronized.
-Synchronization can not be reliably achieved using the time of arrival method.
+Synchronization cannot be reliably achieved using the time of arrival method.
 See the :ref:`iso_providing_data` section for more information.
 
 The following logical flow demonstrates how to send time-synchronized SDUs on multiple CISes or BISes:

softdevice_controller/include/sdc_hci_vs.h

@@ -1677,8 +1677,8 @@ uint8_t sdc_hci_cmd_vs_scan_accept_ext_adv_packets_set(const sdc_hci_cmd_vs_scan
  * This means that there is no guarantee that the controller works as intended when non-tested
  * priorities are used.
  * The default values for the priorities of the different roles are listed in
- * https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/doc/sch
- * eduling.html
+ * https://docs.nordicsemi.com/bundle/ncs-latest/page/nrfxlib/softdevice_controller/doc/scheduling.html
+ *
  *
  * Priority changes configured using this API are not persisted on resets.
  *