From 30926ec0d360e8964172fffbf09bf57751a4afff Mon Sep 17 00:00:00 2001 From: Aleksander Wasaznik Date: Mon, 27 Feb 2023 15:42:15 +0100 Subject: [PATCH] Bluetooth: Host: Fix doc; bt_id_create does not accept pub addr `bt_id_create` does not accept public addresses, but the phrasing that is removed in this change can be interpreted as "replace the public address with a different public address". This was confusing users, so it will be removed. The intended meaning of the original sentence may have been "use the provided address for BT_ID_DEFAULT, instead of using the public address". Amending the sentence to something like that was considered. But, there was no consensus on the usefulness of this addition, so it was left out for brevity. Signed-off-by: Aleksander Wasaznik --- include/zephyr/bluetooth/bluetooth.h | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/include/zephyr/bluetooth/bluetooth.h b/include/zephyr/bluetooth/bluetooth.h index c8382c12d2d0e8..e8dbaa42497b1d 100644 --- a/include/zephyr/bluetooth/bluetooth.h +++ b/include/zephyr/bluetooth/bluetooth.h @@ -254,17 +254,16 @@ void bt_id_get(bt_addr_le_t *addrs, size_t *count); /** * @brief Create a new identity. * - * Create a new identity using the given address and IRK. This function - * can be called before calling bt_enable(), in which case it can be used - * to override the controller's public address (in case it has one). However, - * the new identity will only be stored persistently in flash when this API - * is used after bt_enable(). The reason is that the persistent settings - * are loaded after bt_enable() and would therefore cause potential conflicts - * with the stack blindly overwriting what's stored in flash. The identity - * will also not be written to flash in case a pre-defined address is - * provided, since in such a situation the app clearly has some place it got - * the address from and will be able to repeat the procedure on every power - * cycle, i.e. it would be redundant to also store the information in flash. + * Create a new identity using the given address and IRK. This function can be + * called before calling bt_enable(). However, the new identity will only be + * stored persistently in flash when this API is used after bt_enable(). The + * reason is that the persistent settings are loaded after bt_enable() and would + * therefore cause potential conflicts with the stack blindly overwriting what's + * stored in flash. The identity will also not be written to flash in case a + * pre-defined address is provided, since in such a situation the app clearly + * has some place it got the address from and will be able to repeat the + * procedure on every power cycle, i.e. it would be redundant to also store the + * information in flash. * * Generating random static address or random IRK is not supported when calling * this function before bt_enable().