Remove IPSP support from the tree.
It has no maintainers, and is regularly broken. The fact that it's
nontrivial to set-up in linux makes it hard to fix reported issues.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Since the acl mtu for mesh is reduced to 37 in PR #59004, there is no
need in BT_L2CAP_TX_MTU to be longer than 33 bytes for mesh.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
A recent change in MCS significantly reduced the requirement
of L2CAP_TX_BUF_COUNT and should now work with any value.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
This is an alternative API for the L2CAP receive functionality. It
allows an application the receive L2CAP segments directly and manage
credits explictly. The API is guarded by an experimental kconfig option.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/57485
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Turns out the [first bugfix] was too naive: there is a case where resuming
all channels will not work on all queued SDUs, and the work handler will
give up and wait for the next sent SDU instead of trying to resume again.
This happens when the number of credits and conn contexts is very low for
the amount of data to send.
Always reschedule with a delay to avoid that situation.
[first bugfix]: https://github.com/zephyrproject-rtos/zephyr/pull/50476
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
The EATT MTU in Zephyr is static. We know it at channel creation time,
so we should communicate the MTU as part of channel creation.
Side note: With this approach, it should no longer be neccessary or
useful to do a channel reconfigure.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Move all Kconfig symbols related to Bluetooth logging into the newly
created `Kconfig.logging`. The logging symbols are now grouped by into a
menu "Bluetooth logging". Closely related symbols are grouped with each
others. For example, audio related logging symbol are found behind a
submenu "Audio" inside the "Bluetooth logging".
The deprecated logging symbols have also been moved in a submenu of
"Bluetooth logging", it's easier to avoid them so.
Behavior of the Bluetooth logging system:
When `LOG` symbol is selected, if Bluetooth is enabled (`BT` symbol
selected), the Bluetooth logging is enabled.
If the user does not set any log level, the Bluetooth logging symbols
will inherit the log level of `BT_LOG_LEVEL`. If the user does not set
the level of `BT_LOG_LEVEL`, the default log level will be the one
defined by the logging subsystem. Which currently is `LOG_LEVEL_INF`.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
Rename the bt_audio_unicast_client API to bt_bap_unicast_client
and move the API to bap.h
Also adds the _bap_ infix to the bt_unicast_client functions.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Rename the bt_audio_audio_server API to bt_bap_unicast_server
and move API to bap.h.
This also adds the _bap_ infix for bt_unicast_server.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
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>
Rename BASS to BAP Scan Delegator and BASS Client
to BAP Broadcast Assistant. This is the first step towards
integrating the BASS with the rest of BAP.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
This adds initial support for Hearing Access Service client. The client
performs GATT discovery to find and read HAS related characteristics and
subscribe for characteristic value notifications/indications.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
The EATT support is optional for BAP. The specification mandates the
minimum MTU supported to be 64 bytes.
As per BAP_v1.0
"The Unicast Server shall support a minimum ATT_MTU of 64 octets for
one Unenhanced ATT bearer, or for at least one Enhanced ATT bearer
if the Unicast Server supports Enhanced ATT bearers."
The same applies for other BAP roles.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Set the number of L2CAP TX buffers suffiently high if MCS (media
control) is enabled.
Add BUILD_ASSERT if number is too low.
Signed-off-by: Asbjørn Sæbø <asbjorn.sabo@nordicsemi.no>
The Bluetooth proxy feature includes proxy client
and proxy server. In addition to the proxy pdu
message used above, pb-gatt also uses the same
proxy pdu message.
Currently zephyr bluetooth mesh couples them in one file.
A file at the separation is called gatt_services.c,
which is used to contain Mesh Provisioning Service
and Mesh Proxy Service.
Another file in the separation is called proxy_msg.c,
which is used to process Proxy pdu messages.
Also according to Trond's suggestion:
Rename `CONFIG_BT_MESH_PROXY` to `CONFIG_BT_MESH_GATT`.
Create an additional promptless entry
`CONFIG_BT_MESH_GATT_SERVER` that selects
`CONFIG_BT_MESH_GATT` and is selected by
`CONFIG_BT_MESH_GATT_PROXY` or `CONFIG_BT_MESH_PB_GATT`.
Create additional `CONFIG_BT_MESH_PROXY` used to represent
proxy feature (also include proxy client).
see #36343
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Refactor and simplify the bluetooth buffer configurations to improve the
easy of configurations and eliminate invalid ones.
By moving configurations out of host and controller specific
configurations and into a common one it becomes easier to configure
the host and controller separately as the same configurations can be
used as would be for a combined build.
All HCI configurations are now given exluding the matching HCI header,
which eases the configuration as the application don't have to know the
different header sizes.
The BT_RX_BUF_LEN is split into ACL and Event, as well as the suprising
use of Command size.
BT_L2CAP_RX_MTU is removed as the stack does not support reassembling of
HCI ACL data to larger L2CAP PDUs. The application will have to set
ACL RX size and account for the L2CAP PDU header itself.
BT_EATT_RX_MTU was removed as it is only used for setting a different
default value for another option which leads to the stuck kconfig symbol
problem.
The configurations can be updated according to the table below:
** New configuration | ** Old configuration
All configurations
BT_BUF_ACL_RX_SIZE | BT_L2CAP_RX_MTU + 4
BT_BUF_ACL_RX_SIZE | BT_RX_BUF_LEN - 4
BT_BUF_EVT_RX_SIZE | BT_RX_BUF_LEN - 2
BT_BUF_CMD_TX_SIZE | BT_RX_BUF_LEN - 3
BT_BUF_CMD_TX_COUNT | BT_HCI_CMD_COUNT
BT_BUF_EVT_RX_COUNT | BT_RX_BUF_COUNT
BT_BUF_ACL_RX_COUNT | BT_RX_BUF_COUNT
BT_BUF_ACL_RX_COUNT | BT_ACL_RX_COUNT
BT_BUF_EVT_DISCARDABLE_SIZE | BT_DISCARDABLE_BUF_SIZE - 2
BT_BUF_EVT_DISCARDABLE_COUNT | BT_DISCARDABLE_BUF_COUNT
Controller-build
BT_BUF_ACL_TX_SIZE | BT_CTLR_TX_BUFFERS_SIZE
BT_BUF_ACL_TX_COUNT | BT_CTLR_TX_BUFFER
HCI-bridge
BT_BUF_ACL_TX_SIZE | BT_HCI_ACL_DATA_SIZE
BT_BUF_ACL_TX_COUNT | 6
Fixed invalid configurations setting either BT_L2CAP_RX_MTU or
BT_CTLR_DATA_LENGTH_MAX larger than BT_RX_BUF_LEN could lead to buffer
overruns.
Fix advertising report max data length calculation.
This always used the BT_DISCARDABLE_BUF_SIZE macro but this feature
can be turned off and advertising reports will be allocated from the RX
buffer in that case. Also controller-build does not have this buffer
(in hci_raw.c). Also the wrong HCI header was used in the calculation,
HCI event header should have been used instead of HCI ACL header.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Set the L2CAP TX MTU default to fit the public key packet in a single
L2CAP fragment. This matches the configuration for RX buffer lengths
being set with this configuration.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Allow application to enable L2CAP dynamic channels without support
for Enhanced Credit Based Flow Control (CBFC).
Since these are separate features in the qualification it should
be possible to qualify L2CAP connection oriented channels without
also having to qualify L2CAP enhanced credit based flow control.
The L2CAP/LE/REJ/BI-02-C conformance test will fail when enhanced CBFC
has not been selected in the ICS.
The lower tester expects that since the Enhanced CBFC is not supported,
the command L2CAP_CREDIT_BASED_CONNECTION_REQ should be met with an
L2CAP_COMMAND_REJECT_RSP and not an L2CAP_CREDIT_BASED_CONNECTION_RSP.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Remove dependency on CONFIG_BT_ACL_FLOW_CONTROL and use
CONFIG_BT_L2CAP_RX_MTU always to set L2CAP RX MTU.
The ATT MTU is set from two different KConfig options depending
on if CONFIG_BT_ACL_FLOW_CONTROL is enabled, which makes it
a confusing option and hard to provide a conf file that
supports multiple board configurations.
This changes the behavior when CONFIG_BT_ACL_FLOW_CONTROL and
CONFIG_BT_BUF_RX_LEN was used to set the L2CAP RX MTU, and by
extension the ATT MTU.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
This adds support for EATT bearer which was introduced in 5.2, they work
as extra channels to have GATT traffic, at the moment it is completely
transparent to application when they are in use since the allocation
happens automatically.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
I think people might be reading differences into 'if' and 'depends on'
that aren't there, like maybe 'if' being needed to "hide" a symbol,
while 'depends on' just adds a dependency.
There are no differences between 'if' and 'depends on'. 'if' is just a
shorthand for 'depends on'. They work the same when it comes to creating
implicit menus too.
The way symbols get "hidden" is through their dependencies not being
satisfied ('if'/'depends on' get copied up as a dependency on the
prompt).
Since 'if' and 'depends on' are the same, an 'if' with just a single
symbol in it can be replaced with a 'depends on'. IMO, it's best to
avoid 'if' there as a style choice too, because it confuses people into
thinking there's deep Kconfig magic going on that requires 'if'.
Going for 'depends on' can also remove some nested 'if's, which
generates nicer symbol information and docs, because nested 'if's really
are so simple/dumb that they just add the dependencies from both 'if's
to all symbols within.
Replace a bunch of single-symbol 'if's with 'depends on' to despam the
Kconfig files a bit and make it clearer how things work. Also do some
other minor related dependency refactoring.
The replacement isn't complete. Will fix up the rest later. Splitting it
a bit to make it more manageable.
(Everything above is true for choices, menus, and comments as well.)
Detected by tweaking the Kconfiglib parsing code. It's impossible to
detect after parsing, because 'if' turns into 'depends on'.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
When NET_L2_BT the memory pressure for fragments can be quite high
since that would be transfering IP packets which are considerable big
so this makes our frag_pool to be of the same size as NET_BUF_TX_COUNT.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This is a moderate redesign of the pending TX packet handling that
aims to eliminate potential deadlocks between the TX thread and the
system workqueue thread. The main changes are:
- TX context (bt_conn_tx) is allocated during buffer allocation, i.e.
not in the TX thread.
- We don't allocate a TX context unless there's an associated
callback. When there's no callback simple integer counters are used
for tracking.
- The TX thread is no longer responsible for TX callbacks or
scheduling of TX callbacks. Instead, the callbacks get directly
scheduled (k_work_submit) from the RX priority thread.
- CONFIG_BT_CONN_TX_MAX defaults to CONFIG_BT_L2CAP_TX_BUF_COUNT,
and in most cases wont need changing. The value now only indicates
how many pending packets with a callback are possible.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Use this short header style in all Kconfig files:
# <description>
# <copyright>
# <license>
...
Also change all <description>s from
# Kconfig[.extension] - Foo-related options
to just
# Foo-related options
It's clear enough that it's about Kconfig.
The <description> cleanup was done with this command, along with some
manual cleanup (big letter at the start, etc.)
git ls-files '*Kconfig*' | \
xargs sed -i -E '1 s/#\s*Kconfig[\w.-]*\s*-\s*/# /'
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
subsys/bluetooth/host/Kconfig.l2cap is already sourced within an
'if BT_CONN' in subsys/bluetooth/host/Kconfig, so BT_DEBUG_L2CAP does
not need a 'depends on BT_CONN'.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
The Bluetooth menu has way too many option so this move the L2CAP
specific option to its own menu.
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
