The `bluetooth/common/log.h` and `bluetooth/common/log.c` files have been
removed. Files that were using them have been updated to use
`zephyr/logging/log.h` instead.
Those replacement have been done consequently:
- `/BT_DBG/LOG_DBG/`
- `/BT_ERR/LOG_ERR/`
- `/BT_WARN/LOG_WRN/`
- `/BT_INFO/LOG_INF/`
- `/BT_HEXDUMP_DBG/LOG_HEXDUMP_DBG/`
- `/BT_DBG_OBJ_ID/LOG_DBG_OBJ_ID/`
Also, some files were relying on the `common/log.h` include to include
`zephyr/bluetooth/hci.h`, in those cases the include of `hci.h` has
been added.
For files that were including `common/log.h` but not using any logs,
the include has been removed and not replaced.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
After merging #51809, a few things were spotted that needed tweaking.
Among them:
- Rename the folder from bt_crypto to crypto, since the prefix is
unnecesary
- Remove the include folder
- Remove the path from the global include paths
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Functions related to string manipulation that were defined in
`common/log.h` has been moved to the `common/bt_str.h` file and their
implementation in `common/bt_str.c`.
Files that were using those functions has been updated consequently.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
In order to get rid of the duplication of the code that we had until now
in the tree, consolidate the handling of multiple calls to
bt_hci_cmd_send_sync(BT_HCI_OP_LE_RAND, ...) in a single location,
namely in hci_core.
This allows all of the users of this HCI command to use a single
implementation of the iterated sending of the HCI command to fill a
buffer with random bytes.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Considering that in most scenarios, bt_rand will not be called
frequently, but the current implementation of tinycrypt will
occupy more than 300 bytes of RAM space. Its existence is to
optimize the frequent call of bt_rand.
Therefore, it is considered to put it into a config
(`BT_HOST_CRYPTO_RANDOM`), when this config has been selected,
will use tinycrypt library for random. Otherwise will call bt random
hci command.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Fix infinite recursion in host-based bt_rand function. This would call
HCI LE Random Number command, which would in turn call bt_rand, causing
an infinite recursion.
bt_rand -> prng_reseed -> BT_HCI_OP_LE_RAND -> le_rand -> bt_rand
To solve this issue the controller should avoid doing calls into the
host, so all calls to bt_rand in the controller should be replaced with
a call to a controller function.
Fixes#22202
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Fix calling bt_hex and bt_addr_le_str multiple times in the same logging
call could result in string overwritten since log_strdup is not
guaranteed to duplicate the string buffer in all logging configurations.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
move misc/byteorder.h to sys/byteorder.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The API name space for Bluetooth is bt_* and BT_* so it makes sense to
align the Kconfig name space with this. The additional benefit is that
this also makes the names shorter. It is also in line with what Linux
uses for Bluetooth Kconfig entries.
Some Bluetooth-related Networking Kconfig defines are renamed as well
in order to be consistent, such as NET_L2_BLUETOOTH.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Move the PRNG initialization after reading local supported commands,
so that we don't send HCI_LE_Rand if the controller doesn't support it
(we still need to fail the init however). The patch also removes a few
unnecessary #ifdefs related to crypto.h.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Since more and more code is going to be reused by both the Host and the
Controller, this commit introduces a common/ folder that will contain
everything that is not tied to one of the two components but shared by
them.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Convert code to use u{8,16,32,64}_t and s{8,16,32,64}_t instead of C99
integer types.
Jira: ZEP-2051
Change-Id: I8f57a17f78e674aca5400f005db8975c9f9e150e
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
There may be use cases where input and output is in big-endian rather
than little-endian. Introduce a native big-endian API to avoid
excessive byte order reversals in these cases.
Change-Id: Ia7b3e01bb0a07c4560b23f60c2f615ec614eb431
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Expose LE Encrypt helpers to applications. If software-
based controller is compiled-in, then controller's AES
hardware will be used by the exposed helper interface.
Change-id: I2bac9dfa5ccb3dd50447079affb52d920ae5bd81
Signed-off-by: Vinayak Chettimada <vinayak.kariappa.chettimada@nordicsemi.no>.
