michaelh/zephyr
1
0
Fork 0
Code Releases Activity
zephyr/subsys/bluetooth/common/dummy.c

63 lines
2.3 KiB
C
Raw Normal View History

Bluetooth: Enforce cooperative priorities in Bluetooth threads The Bluetooth subsystem assumes execution of its system threads in cooperative priority, including the system workqueue and the thread that interact with the controller (i.e. calling bt_send). This commit adds a compile-time check for the system workqueue priority and documentation for the bt_send API call. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2017-06-15 10:31:06 +02:00
/**
* @file dummy.c
* Static compilation checks.
*/
/*
* Copyright (c) 2017 Nordic Semiconductor ASA
*
* SPDX-License-Identifier: Apache-2.0
*/
Bluetooth: Assert alignof bt_addr types I got some feedback about confusion as to why the bt_addr types are not packed. This commit adds a note about it. This commit also adds a check for the alignof of the structs to verify the statement 'their members are bytes or byte arrays' to thoroughly prove that the struct is effectively as-if packed. Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
2024-04-10 21:37:51 +02:00
#include <stdalign.h>
includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> 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>
2022-08-25 09:58:46 +02:00
#include <zephyr/kernel.h>
subsystems: migrate includes to <zephyr/...> 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>
2022-05-06 11:12:04 +02:00
#include <zephyr/bluetooth/bluetooth.h>
Bluetooth: host: Add lower bound for `CONFIG_BT_BUF_ACL_RX_COUNT` See comment above assert for more. Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
2024-07-08 14:52:07 +02:00
#include <zephyr/bluetooth/buf.h>
Bluetooth: common: Add build asserts for address struct sizes In some HCI packed structures we place non-packed structs inside (in particular the address structs). Alignment is not an issue for those because all their members are just byte-aligned, but size is. If the compiler ever packs those it would become a real problem, and so detect this at build time. See the link below for more info: https://stackoverflow.com/a/66389167 Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2021-09-29 14:54:51 +02:00
/*
* The unpacked structs below are used inside __packed structures that reflect
* what goes on the wire. While alignment is not a problem for those, since all
* their members are bytes or byte arrays, the size is. They must not be padded
* by the compiler, otherwise the on-wire packet will not map the packed
* structure correctly.
Bluetooth: Assert alignof bt_addr types I got some feedback about confusion as to why the bt_addr types are not packed. This commit adds a note about it. This commit also adds a check for the alignof of the structs to verify the statement 'their members are bytes or byte arrays' to thoroughly prove that the struct is effectively as-if packed. Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
2024-04-10 21:37:51 +02:00
*
* The bt_addr structs are not marked __packed because it's considered ugly by
* some. But here is a proof that the structs have all the properties of, and
* can be safely used as packed structs.
Bluetooth: common: Add build asserts for address struct sizes In some HCI packed structures we place non-packed structs inside (in particular the address structs). Alignment is not an issue for those because all their members are just byte-aligned, but size is. If the compiler ever packs those it would become a real problem, and so detect this at build time. See the link below for more info: https://stackoverflow.com/a/66389167 Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2021-09-29 14:54:51 +02:00
*/
BUILD_ASSERT(sizeof(bt_addr_t) == BT_ADDR_SIZE);
Bluetooth: Assert alignof bt_addr types I got some feedback about confusion as to why the bt_addr types are not packed. This commit adds a note about it. This commit also adds a check for the alignof of the structs to verify the statement 'their members are bytes or byte arrays' to thoroughly prove that the struct is effectively as-if packed. Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
2024-04-10 21:37:51 +02:00
BUILD_ASSERT(alignof(bt_addr_t) == 1);
Bluetooth: common: Add build asserts for address struct sizes In some HCI packed structures we place non-packed structs inside (in particular the address structs). Alignment is not an issue for those because all their members are just byte-aligned, but size is. If the compiler ever packs those it would become a real problem, and so detect this at build time. See the link below for more info: https://stackoverflow.com/a/66389167 Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2021-09-29 14:54:51 +02:00
BUILD_ASSERT(sizeof(bt_addr_le_t) == BT_ADDR_LE_SIZE);
Bluetooth: Assert alignof bt_addr types I got some feedback about confusion as to why the bt_addr types are not packed. This commit adds a note about it. This commit also adds a check for the alignof of the structs to verify the statement 'their members are bytes or byte arrays' to thoroughly prove that the struct is effectively as-if packed. Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
2024-04-10 21:37:51 +02:00
BUILD_ASSERT(alignof(bt_addr_le_t) == 1);
Bluetooth: Enforce cooperative priorities in Bluetooth threads The Bluetooth subsystem assumes execution of its system threads in cooperative priority, including the system workqueue and the thread that interact with the controller (i.e. calling bt_send). This commit adds a compile-time check for the system workqueue priority and documentation for the bt_send API call. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2017-06-15 10:31:06 +02:00
bluetooth: config: Fix bluetooth config dependencies Fix bluetooth config dependencies where the definitions depend on other definitions. BT_RX_PRIO is not always defined in a controller only build. BT_CTLR_TX_BUFFER_SIZE does not depend on BT_CTLR, but BT_LL_SW. Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
2018-10-04 13:44:33 +02:00
#if defined(CONFIG_BT_HCI_HOST)
Bluetooth: Call bt_recv from priority higher that TX thread. A build assert in dummy.c lists the following requirement: [...] receive thread priority shall be higher than the Bluetooth Host's Tx and the Controller's receive thread priority. This is required in order to dispatch Number of Completed Packets event before any new data arrives on a connection to the Host threads. The drivers uses a priority that is equal to the Host TX thread, and since they don't use the CONFIG define that is only available to the controller then this BUILD_ASSERT will not catch the requirement. Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
2020-08-19 17:16:01 +02:00
/* The Bluetooth subsystem requires that higher priority events shall be given
* in a priority higher than the Bluetooth Host's Tx and the Controller's
* receive thread priority.
Bluetooth: Add BUILD_ASSERT to check Tx and Rx thread priorities Added BUILD_ASSERT check for Tx and Rx thread priorities. The Tx thread priority shall be higher than Rx thread priority in order to correctly detect transaction violations in ATT and SMP protocols. The Number of Completed Packets for a connection shall be processed before any new data is received and processed for that connection. The Controller's priority receive thread priority shall be higher than the Host's Tx and the Controller's Rx thread priority. Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
2017-07-11 09:47:08 +02:00
* This is required in order to dispatch Number of Completed Packets event
* before any new data arrives on a connection to the Host threads.
*/
Bluetooth: Call bt_recv from priority higher that TX thread. A build assert in dummy.c lists the following requirement: [...] receive thread priority shall be higher than the Bluetooth Host's Tx and the Controller's receive thread priority. This is required in order to dispatch Number of Completed Packets event before any new data arrives on a connection to the Host threads. The drivers uses a priority that is equal to the Host TX thread, and since they don't use the CONFIG define that is only available to the controller then this BUILD_ASSERT will not catch the requirement. Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
2020-08-19 17:16:01 +02:00
BUILD_ASSERT(CONFIG_BT_DRIVER_RX_HIGH_PRIO < CONFIG_BT_HCI_TX_PRIO);
#endif /* defined(CONFIG_BT_HCI_HOST) */
Bluetooth: common: Statically check for immediate logging Immediate logging is not compatible with the software-based controller due to the additional ISR latency that it introduces. Ensure that deferred logging is in use whenever using the software-based LL. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2019-10-01 14:21:27 +02:00
bluetooth: Allow immediate logging with software-based LL Some logging configuration are compatible with software-base Link Layer. Currently only one configuration is supported: RTT back-end in drop mode and no clean output Signed-off-by: Guillaume Lager <guillaume.lager@gmail.com>
2020-08-31 15:33:36 +02:00
#if (defined(CONFIG_LOG_BACKEND_RTT) && \
(defined(CONFIG_SEGGER_RTT_MODE_BLOCK_IF_FIFO_FULL) || \
defined(CONFIG_LOG_BACKEND_RTT_MODE_BLOCK))) || \
defined(CONFIG_LOG_BACKEND_NET) || \
defined(CONFIG_LOG_IMMEDIATE_CLEAN_OUTPUT)
#define INCOMPATIBLE_IMMEDIATE_LOG_BACKEND 1
#endif
/* Immediate logging on most backend is not supported
* with the software-based Link Layer since it introduces ISR latency
* due to outputting log messages with interrupts disabled.
Bluetooth: common: Statically check for immediate logging Immediate logging is not compatible with the software-based controller due to the additional ISR latency that it introduces. Ensure that deferred logging is in use whenever using the software-based LL. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2019-10-01 14:21:27 +02:00
*/
#if !defined(CONFIG_TEST) && !defined(CONFIG_ARCH_POSIX) && \
bluetooth: Allow immediate logging with software-based LL Some logging configuration are compatible with software-base Link Layer. Currently only one configuration is supported: RTT back-end in drop mode and no clean output Signed-off-by: Guillaume Lager <guillaume.lager@gmail.com>
2020-08-31 15:33:36 +02:00
defined(CONFIG_BT_LL_SW_SPLIT) && \
defined(INCOMPATIBLE_IMMEDIATE_LOG_BACKEND)
logging: Deprecate v1, default to v2 Reduced logging mode selection to deferred, immediate, minimal and frontend. Decoupled logging version from mode and created CONFIG_LOG1 which can be used to explicitly select deprecated version. From now on, chosing CONFIG_LOG_MODE_{IMMEDIATE,DEFERRED} will result in version2. Deprecated CONFIG_LOG2_MODE_{IMMEDIATE,DEFERRED} with cmake warning. Codebase adapted to those changes. Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
2022-01-12 15:52:48 +01:00
BUILD_ASSERT(!IS_ENABLED(CONFIG_LOG_MODE_IMMEDIATE), "Immediate logging "
bluetooth: Allow immediate logging with software-based LL Some logging configuration are compatible with software-base Link Layer. Currently only one configuration is supported: RTT back-end in drop mode and no clean output Signed-off-by: Guillaume Lager <guillaume.lager@gmail.com>
2020-08-31 15:33:36 +02:00
"on selected backend(s) not "
global: Replace BUILD_ASSERT_MSG() with BUILD_ASSERT() Replace all occurences of BUILD_ASSERT_MSG() with BUILD_ASSERT() as a result of merging BUILD_ASSERT() and BUILD_ASSERT_MSG(). Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
2020-03-12 17:16:00 +02:00
"supported with the software Link Layer");
Bluetooth: common: Statically check for immediate logging Immediate logging is not compatible with the software-based controller due to the additional ISR latency that it introduces. Ensure that deferred logging is in use whenever using the software-based LL. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2019-10-01 14:21:27 +02:00
#endif
Copy permalink