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>
