This commit adds CONFIG_BT_USE_PSA_API to allow the end
user to prefer PSA APIs over TinyCrypt for crypto operations
in bluetooth. Of course, this is possible only if
a PSA provider is available on the system, i.e.
CONFIG_PSA_CRYPTO_CLIENT is set.
This commit also extends
tests/bluetooth/mesh/basic/bluetooth.mesh.gatt adding a specific
case using PSA.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
By enabling CONFIG_BT_USE_PSA_API the user can specify to use
PSA APIs instead of TinyCrypt for crypto operations in bluetooth
host module.
This commit also extends tests/bluetooth/gatt in order to
add a PSA test.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
The HCI command LE Read Supported States command returns
if the controller supports running the scanner and initiator
roles in parallel.
This commit utilizes this information in the host:
- It does not prevent initiating a connection when the scanner is
running
- It does not prevent the host from restarting the background
scanner when there the host wants to auto-initiate a connection.
- It does not stop the scanner when the host wants to auto-initiate
a connection.
To support this feature, the scanner and initiator
always have to use the same address.
This because the HCI command LE Set Random Address
cannot be issued after the initiator or scanner has started.
1. When privacy is disabled, the scanner has to use its identity
address to ensure it uses the same address as the initiator.
2. Only one identity is supported.
To simplify the implementation, it is a requirement to use
extended advertising commands to avoid interfering with
the random address used by the advertiser(s).
Also, it is a requirement to never use time-limited scanning,
as RPA this feature does not work when privacy is being used.
See https://github.com/zephyrproject-rtos/zephyr/issues/73634.
The changes in this commit will be tested out of tree as the
Zephyr Bluetooth Controller does not support this functionality.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Returning a status code will allow the application developer
to detect logic issues.
We consider this as not breaking the API.
If `-Werror -Wunused-result` is enabled, the application developer needs
to validate the return code.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Callbacks can only be registered once. Otherwise the slist
will become circular.
In this commit we have choosen to ignore the second registration
call if the callback has already been registed. The alternative
is to trigger an assertion. That doesn't work if the assertions
are turned off.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
This allows us to use functionality provided by slist.
First use case: Avoid adding an element twice.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
The same way as `bt_hci_get_adv_handle` and `bt_hci_get_conn_handle` add
a function to get the handle of a periodic advertising sync.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
When testing https://github.com/zephyrproject-rtos/zephyr/pull/72090/,
there is an issue found.
The change in the previous commit is to put all data sending
operations into the work queue context, and lock the current
AG before sending data.
And in change of #72090, the HCI TX thread is removed. All
sending sequence are happened in work queue context.
There is a possible problem when AG creates a SCO connection
by calling the function bt_conn_create_sco. Before the
function bt_conn_create_sco is called, AG will be locked to
avoid creating repeated SCO connection.
And the execution of the function bt_conn_create_sco
depends on the work queue. Because the HCI command of
function bt_conn_create_sco is sent in work queue context.
In the normal case, there is not any issue.
But there is a case that when the function
bt_conn_create_sco is being executed, there is a pending AG
TX waiting to be executed.
Once the work queue starts executing the handler, the AG TX
handler is executed first. Since the lock has been acquired
by other threads, the AG TX handler cannot acquire the lock.
As a result, the SCO connection creation fails.
Remove the AG lock from SCO creating. Instead, use a flag
to mark whether a SCO connection is be created.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
Due to the sent callback of RFCOMM is changed, the
sending buf need to be primed waiting for the
previous one to be completed. Add a worker for
this purpose.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
Due to the parameter `buf` has been removed by rfcomm,
update the prototype of channel sent callback hfp_hf_sent.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
Due to the sending buf cannot be referred
by sending layer.
It is unsafe to use `buf` identification
for a transmission, because the buf may
have been newly transmitted when the
sent callback is triggered.
Now instead, when the send completion
callback is received, the upper layer
is notified that a transfer is completed.
If multiple bufs are sent at the same
time, there is no guarantee which buf
is completed when the sent callback
triggered. Therefore, it is recommended
that the caller transfers the next data
block after the previous transfer is
completed.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
There is a change (commit no.: 93d0eac834) that if
the `ref` of sending buf is not 1, the error code
`-EINVAL` will be returned from bt_conn_send_cb.
It causes the RFCOMM functionality cannot work
properly.
Remove the ref operation from the buf to be sent
to fix the issue.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
View buffers are now also a limited resource. Acquire them before
attempting to pull data. `CONFIG_BT_CONN_FRAG_COUNT` should be tuned on
a per-application basis to avoid this.
A possible optimization, that was present before, is to not create a
frag when the original buffer fits the controller's HCI size.
I prefer deferring this optimization to a future patchset.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
We can get rid of the view pool for SDU segments :)
We have to make the code slightly more complex :'(
The basic idea is always giving the original SDU buffer to `conn.c` for it
to pull ACL fragments from.
In order to do this, we need to add the PDU headers just-in-time.
`bt_l2cap_send_pdu()` does not add them before putting the PDU on the queue
anymore. They are added by `l2cap_data_pull()` right before the data leaves
`l2cap.c` for `conn.c`.
We also have to inform `conn.c` "out of band" of the real L2CAP PDU size so
it doesn't fragment across segment boundaries. This oob is the new `length`
parameter to the `.pull()` method.
This is the added complexity mentioned above.
Since SDU segmentation concerns only LE-L2CAP, ISO and Classic L2CAP don't
need this extra logic.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
We don't need the TX thread anymore.
Generalizing the pull-based architecture (ie. `tx_processor`) to HCI
commands makes it possible to run the whole TX path from the the system
workqueue, or any workqueue really.
There is an edge-case, where we call `bt_hci_cmd_send_sync()` from the
syswq, stalling the system. The proposed mitigation is to attempt to drain
the command queue from within `bt_hci_cmd_send_sync()`.
My spidey sense tingles however, and it would be better to just remove the
capability of calling this fn from the syswq. But doing this requires
refactoring a bunch of synchronous procedures in the stack (e.g. stack
init, connection establishment, address setting etc), dragging in more
work. I will do it, but in a later patch.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This API replaces `bt_l2cap_send()` and `bt_l2cap_send_cb()`.
The difference is that it takes the `struct bt_l2cap_le_chan` object
directly instead of a connection + CID.
We need the channel object in order to put the PDU on the TX queue. It
is inefficient to do a search for every PDU when the caller knows the
channel object's address and can just pass it down.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
The current TX pattern in the host is to try to push a buffer through all
the layers up until it is ingested by the controller.
Since sending can fail at any layer, we need error-handling and separate
retry logic on pretty much all layers. That logic obscures the "happy path"
for people trying ot understand the code.
This commit inverts the control, in a way that doesn't require changing the
host or HCI driver API (yet):
Layers don't send buffers synchronously, they instead put their buffer in a
private queue of their own and raise a TX flag on the lower layer. Think of
it as a `READY` interrupt line that has to be serviced by the lower layer.
Sending is now non-blocking, rate depends on the size of buffer pools.
There is a single TX processing function. This can be thought as the
Interrupt Service Routine that will handle the `READY` interrupt from the
layers above.
That `tx_processor()` will then attempt to allocate enough resources in
order to send the buffer through to the controller. This allocation logic
does not block.
After acquiring all the resources, the TX processor will attempt to pull
data from the upper layer. The upper layer has to figure out which buffer
to pass to the controller. This is a good spot to put scheduling or QoS
logic in the upper layer.
Notes:
- user-facing API for tuning QoS will be implemented in a future patch
- this scheme could (and probably will) be extended to upper layers (e.g.
ATT, L2CAP CoC segmentation).
- this patch removes the `pending_no_cb()` memory optimization for
clarity/correctness. It might get re-implemented after a stabilization
period. Hopefully with more documentation.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Instead of allocating segments/fragments and copying data into them, we
allocate segments as "views" (or slices) into the original buffer.
The view also gives access to the headroom of the original buffer, allowing
lower layers to push their headers.
We choose not to allow multiple views into the same buffer as the headroom
of a view would overlap with the data of the previous view.
We mark a buffer as locked (or "in-view") by temporarily setting its
headroom to zero. This effectively stops create_view because the requested
headroom is not available.
Each layer that does some kind of fragmentation and wants to use views for
that needs to maintain a buffer pool (bufsize 0, count = max views) and a
metadata array (size = max views) for the view mechanism to work.
Maximum number of views: number of parallel buffers from the upper layer,
e.g. number of L2CAP channels for L2CAP segmentation or number of ACL
connections for HCI fragmentation.
Reason for the change:
1. prevent deadlocks or (ATT/SMP) requests timing out
2. save time (zero-copy)
3. save memory (gets rid of frag pools)
L2CAP CoC: would either allocate from the `alloc_seg` application callback,
or worse _steal_ from the same pool, or allocate from the global ACL pool.
Conn/HCI: would either allocate from `frag_pool` or the global ACL pool.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
`bt_conn_send_cb` used to allocate a TX context (K_FOREVER).
Instead, we now put the context in the userdata of the buffer.
This means that now this fn will never block and always succeed since the
tx_queue is a FIFO (infinite size). It just puts the buf on the queue.
The metadata is stored safely in there until we have acquired all the
necessary resources to send it to the controller without failing: TX
context and controller buffer.
I.e. when `bt_conn_process_tx` is called, that's when a TX context is
try-allocated and the contents of `buf->userdata` is moved into it.
The buffer is now ready to be sent to the lower layer.
`bt_conn_process_tx` will return -EWOULDBLOCK if it's not able to acquire a
TX context, this PR modifies `bt_conn_prepare_events` to respond to this by
also waiting on the TX context pool.
Unfortunately, this increases the required userdata size for any buffers
handed to `bt_conn_send_cb`. This will be fixed in a later commit.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
If the new encryption state is the same as the old one, there's no point in
doing additional processing or callbacks. Simply log a warning and ignore
the HCI event in such a case.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
Add support for HCI drivers which use the newly defined HCI driver API.
Since Zephyr (currently) only supports a single HCI driver instance,
boards are expected to indicate the instance using a new devicetree
chosen property `zephyr,bt_hci`.
In order to maintain compatibility with not-yet-converted drivers the
code has been placed behind `#if DT_HAS_CHOSEN(zephyr_bt_hci)`
conditionals.
Signed-off-by: Johan Hedberg <johan.hedberg@gmail.com>
https://github.com/zephyrproject-rtos/zephyr/pull/72674 fixed
a bug where this configuration did not work.
Now that this configuration is tested, we should mark it
as supported.
The timeout check that was present in the code before
was useless and was not working because the check was
run before a default timeout of 0 was converted to a timeout.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
This commit adds host support for the Path Loss Monitoring
feature see Bluetooth Core specification, Version 5.4,
Vol 6, Part B, Section 4.6.32.
Limited logic is required, just adding a wrapper around the
HCI command and callback for HCI event.
Add new zone - BT_CONN_LE_PATH_LOSS_ZONE_UNAVAILABLE, to
convert 0xFF path loss to a useful zone.
Add new Kconfigs and functionality to the bt shell.
Signed-off-by: Sean Madigan <sean.madigan@nordicsemi.no>
When reading the error message:
"ASSERTION_FAIL: command opcode 0x0c03 timeout with err -11" it may not be
obvious what is wrong with their setup unless you are very familiar
with HCI.
This commit adds some more documentation to make this more obvious.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Currently calls to these two functions fail unnecessarily when
CONFIG_BT_SMP is disabled. This fix allows identity resets
without having the BT_SMP stack enabled. The primary use case
is enabling random mac address rotation for privacy in memory
constrained SOCs. Fixes#73313
Signed-off-by: Patrick Patel <ppatel@micro-design.com>
The driver isn't currently buildable due to "west blobs" support never
having been added for hal_telink. Furthermore, even if the blob
dependency is manually made available it turns out the code has
bitrotten to the point where it doesn't build anymore. This situation
has continued for several years without anyone taking action, so I think
it's safe to assume this is unmaintained and should be removed.
Signed-off-by: Johan Hedberg <johan.hedberg@gmail.com>
Before this commit, the following bugs were present:
- When `CONFIG_BT_FILTER_ACCEPT_LIST` was set, connection establishment
was cancelled upon RPA timeout. This required the application
to restart the initiator every RPA timeout.
- When `CONFIG_BT_FILTER_ACCEPT_LIST` was not set, the RPA was not updated
while the initiator was running.
This commit unifies the RPA timeout handling for both these cases.
Upon RPA timeout the initiator is cancelled and restarted when
the controller raises the LE Connection Complete event.
The workqueue state is checked when restarting the initiator to prevent
it being restarted when the timeout is hit.
Corresponding test cases have been added to ensure that this
feature works.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Expectation: After calling `bt_disable()` it is possible to
use the Bluetooth APIs as if `bt_enable()` was never called.
This was not the case for `bt_id_create()`, it was not possible
to set the default identity. This prevented an application
developer to restart the stack as a different identity.
Keys also need to be cleared to avoid the following pattern:
1. Pair two devices
2. Central calls `bt_disable()` and `bt_enable()`.
The central will now generate a new identity address.
3. Connect the two devices.
4. Re-establish encryption. Now the central will try to use
the previously used keys. The procedure will fail
because the peripheral does not have any keys associated
with the new central address.
The API documentation is updated accordingly.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
implement a2dp.c and avdtp.c
add a2dp related Kconfig:
BT_AVDTP_RTP_VERSION, BT_A2DP_SOURCE and BT_A2DP_SINK
a2dp_codec_sbc.c/h are used to provide some APIs to get
A2DP SBC codec information. (like: channel num).
Signed-off-by: Mark Wang <yichang.wang@nxp.com>
The BR Keys cannot be scanned by function
bt_foreach_bond.
Add function bt_foreach_bond_br for br.
The function bt_foreach_bond_br will be
called by bt_foreach_bond if the BR is
enabled.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
These are safety checks to guard against silent data corruption. The
implementation currently does not clobber bufs, but soon it will. The
bufs will be zero-copy segmented and fragmented, which involves
overwriting already-sent contents with headers for the next fragment.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
If bt_conn_set_state(conn, BT_CONN_DISCONNECTED) is called
while the connection is already disconnected, this triggers
a warning. This is likely to happen when bt_conn_cleanup_all
is called as part of bt_disable.
Added the state check to avoid unnecessary warnings in the log.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Add support for bt_disable in the ISO implementation.
This involves clearing all information related to states
in the controller, such as the BIGs and CIGs.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The default stack size of RFCOMM DLC is 256.
The default value is sufficient for basic operation.
If more stack space is used (such as call function printk)
in context of callback disconnected of RFCOMM DLC, the
default stack size is not sufficient.
Add a configuration BT_RFCOMM_DLC_STACK_SIZE to configure
the RFCOMM DLC stack size.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
To avoid the case that CONN_TX is available but RFCOMM_TX is
unavailable, set the default value of BT_RFCOMM_TX_MAX to
BT_CONN_TX_MAX.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
This function was used to shortcut HCI for combined host + controller
builds. It doesn't provide much value and adds complexity to the HCI
driver interface, so just remove it. This means vendor-specific HCI
commands is now the only way for the host to access the same
information.
Signed-off-by: Johan Hedberg <johan.hedberg@gmail.com>
Enabling vendor-specific extensions also implies support for vendor
events, so a separate Kconfig option for that is unnecessary.
One small additional thing this requires is the use of the
__maybe_unused annotation, since there's no-longer a single Kconfig
option that the controller hci.c can use to know that the vendor event
helper symbols are needed.
Signed-off-by: Johan Hedberg <johan.hedberg@gmail.com>
The naming of these two options was problematic, since it's both of them
are about vendor extensions, even though one has _EXT in the name and
the other doesn't. Just merge one option into the other. This has a
slight overhead on the controller side of enabling some more vendor
features if BT_HCI_VS is enabled, but that should hopefully be
acceptable.
Signed-off-by: Johan Hedberg <johan.hedberg@gmail.com>
Calling bt_disable in system workqueue context while BLE connected may
lead to calling wait_for_tx_work in this context. Fix check in code to
avoid assertion failure.
Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
Make `bt_hci_cmd_send_sync` return `-EACCES` when receiving
`BT_HCI_ERR_CMD_DISALLOWED`.
Update some tests that were expecting `-EIO` when
getting `BT_HCI_ERR_CMD_DISALLOWED`.
Add a warning in `set_random_address` when getting that new error. This
is done in case someone try to set a new random address while legacy
advertising, scanning or initiating is enabled. This is illegal behavior
according to the Core Spec (see Vol 4, Part E 7.8.4).
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
Rename struct bt_hci_iso_data_hdr to bt_hci_iso_sdu_hdr, and
struct bt_hci_iso_ts_data_hdr to bt_hci_iso_sdu_ts_hdr.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
