eddd98f811
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>
66 lines
1.7 KiB
Plaintext
66 lines
1.7 KiB
Plaintext
# Bluetooth ATT/GATT configuration options
|
|
|
|
# Copyright (c) 2019 Intel Corporation
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
menu "L2CAP Options"
|
|
|
|
config BT_L2CAP_RX_MTU
|
|
int "Maximum supported L2CAP MTU for incoming data"
|
|
default 200 if BT_BREDR
|
|
default 65 if BT_SMP
|
|
default 23
|
|
range 65 1300 if BT_SMP
|
|
range 23 1300
|
|
depends on BT_HCI_ACL_FLOW_CONTROL
|
|
help
|
|
Maximum size of each incoming L2CAP PDU.
|
|
|
|
config BT_L2CAP_TX_BUF_COUNT
|
|
int "Number of L2CAP TX buffers"
|
|
default NET_BUF_TX_COUNT if NET_L2_BT
|
|
default BT_CTLR_TX_BUFFERS if BT_CTLR
|
|
default 3
|
|
range 2 255
|
|
help
|
|
Number of buffers available for outgoing L2CAP packets.
|
|
|
|
config BT_L2CAP_TX_FRAG_COUNT
|
|
int "Number of L2CAP TX fragment buffers"
|
|
default NET_BUF_TX_COUNT if NET_L2_BT
|
|
default 2
|
|
range 0 255
|
|
help
|
|
Number of buffers available for fragments of TX buffers. Warning:
|
|
setting this to 0 means that the application must ensure that
|
|
queued TX buffers never need to be fragmented, i.e. that the
|
|
controller's buffer size is large enough. If this is not ensured,
|
|
and there are no dedicated fragment buffers, a deadlock may occur.
|
|
In most cases the default value of 2 is a safe bet.
|
|
|
|
config BT_L2CAP_TX_MTU
|
|
int "Maximum supported L2CAP MTU for L2CAP TX buffers"
|
|
default 253 if BT_BREDR
|
|
default 65 if BT_SMP
|
|
default 23
|
|
range 65 2000 if BT_SMP
|
|
range 23 2000
|
|
help
|
|
Maximum L2CAP MTU for L2CAP TX buffers.
|
|
|
|
config BT_L2CAP_DYNAMIC_CHANNEL
|
|
bool "L2CAP Dynamic Channel support"
|
|
depends on BT_SMP
|
|
help
|
|
This option enables support for LE Connection oriented Channels,
|
|
allowing the creation of dynamic L2CAP Channels.
|
|
|
|
config BT_DEBUG_L2CAP
|
|
bool "Bluetooth L2CAP debug"
|
|
depends on BT_DEBUG
|
|
help
|
|
This option enables debug support for the Bluetooth
|
|
L2ACP layer.
|
|
|
|
endmenu
|