bartoszek/zephyr
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
b9253b5c19
zephyr/subsys/bluetooth/common/Kconfig
Joakim Andersson 6483e12a8a Bluetooth: Refactor bluetooth buffer configuration for simplification 
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>
2021-05-06 14:56:18 +02:00

375 lines
13 KiB
Plaintext
Raw Blame History

# Bluetooth common configuration options
# Copyright (c) 2017 Nordic Semiconductor ASA
# Copyright (c) 2016 Intel Corporation
# SPDX-License-Identifier: Apache-2.0
config BT_BUF_ACL_TX_SIZE
int "Maximum supported ACL size for outgoing data"
range 27 251
default 27
help
Maximum supported ACL size of data packets sent from the Host to the
Controller. This value does not include the HCI ACL header.
The Host will segment the data transmitted to the Controller so that
packets sent to the Controller will contain data up to this size.
In a combined build this value will be set in both the Host and the
Controller.
In a Host-only build the Host will read the maximum ACL size supported
by the Controller and use the smallest value supported by both the
Bost and the Controller.
The Host supports sending of larger L2CAP PDUs than the ACL size and
will fragment L2CAP PDUs into ACL data packets.
The Controller will return this value in the HCI LE Read Buffer
Size command response. If this size if greater than effective Link
Layer transmission size then the Controller will perform
fragmentation before transmitting the packet(s) on air.
If this value is less than the effective Link Layer transmission size
then this will restrict the maximum Link Layer transmission size.
Maximum is set to 251 due to implementation limitations (use of
uint8_t for length field in PDU buffer structure).
config BT_BUF_ACL_TX_COUNT
int "Number of outgoing ACL data buffers"
default 7 if BT_HCI_RAW
default 3
range 1 255
help
Number of outgoing ACL data buffers sent from the Host to the
Controller. This determines the maximum amount of data packets the
Host can have queued in the Controller before waiting for the
to notify the Host that more packets can be queued with the Number of
Completed Packets event.
The buffers are shared between all of the connections and the Host
determines how to divide the buffers between the connections.
The Controller will return this value in the HCI LE Read Buffer Size
command response.
config BT_BUF_ACL_RX_SIZE
int "Maximum supported ACL size for incoming data"
default 200 if BT_BREDR
# Mesh Proxy Recommended: 64 Pkey + 2 Bytes Mesh header.
# Overhead: ATT Write command Header (3) in an L2CAP PDU (4).
default 73 if BT_MESH_PROXY
default 70 if BT_EATT
default 69 if BT_SMP
default 27
range 70 1300 if BT_EATT
range 69 1300 if BT_SMP
range 27 1300
help
Maximum support ACL size of data packets sent from the Controller to
the Host. This value does not include the HCI ACL header.
In a combined Host and Controller build the buffer sizes in both the
Host and the Controller will use this value for buffer sizes, and
therefore Controller to Host flow Controller is not needed.
In a Host only build with Controller to Host flow control enabled
the Host will inform the Controller about the maximum ACL data size it
can send by setting this value in the Host Buffer Size command.
If Controller to Host flow control is not enabled then the Controller
can assume the Host has infinite buffer size so this value should then
be set to something that is guaranteed the Controller will not exceed
or the data packets will be dropped.
In a Controller only build this will determine the maximum ACL size
that the Controller will send to the Host.
The Host supports reassembling of L2CAP PDUs from ACL data packets,
but the maximum supported L2CAP PDU size is limited by the maximum
supported ACL size.
This means the maximum L2CAP PDU MTU is restricted by the maximum ACL
size subtracting the 4 byte header of an L2CAP PDU.
When using L2CAP Connection oriented Channels without segmentation
then the L2CAP SDU MTU is also restricetd by the maximum ACL size
subtracting the 4 Byte header of an L2CAP PDU plus the 2 byte header
of an L2CAP SDU.
With Enhanced ATT enabled the minimum of 70 is needed to support the
minimum ATT_MTU of 64 octets in an L2CAP SDU without segmentation.
With SMP LE Secure Connections enabled the minimum of 69 is needed to
support the minimum SMP MTU of 65 octets (public key + opcode) in an
L2CAP PDU.
An L2CAP PDU is also referred to as an L2CAP basic frame or B-frame.
An L2CAP SDU is also referred to as an L2CAP Credit-based frame or
K-frame.
config BT_BUF_ACL_RX_COUNT
int "Number of incoming ACL data buffers"
default NET_BUF_RX_COUNT if NET_L2_BT
default 3 if BT_RECV_IS_RX_THREAD
default 6
range 1 64
help
Number or incoming ACL data buffers sent from the Controller to the
Host.
In a combined Host and Controller build the buffers are shared and
therefore Controller to Host flow control is not needed.
In a Host only build with Controller to Host flow control enabled
the Host will inform the Controller about the maximum number of
buffers by setting this value in the Host Buffer Size command.
When Controller to Host flow control is not enabled the Controller
can assume that the Host has infinite amount of buffers.
config BT_BUF_EVT_RX_SIZE
int "Maximum supported HCI Event buffer length"
default 255 if (BT_EXT_ADV && !(BT_BUF_EVT_DISCARDABLE_COUNT > 0))
# LE Read Supported Commands command complete event.
default 68
range 68 255
help
Maximum supported HCI event buffer size. This value does not include
the HCI Event header.
This value is used by both the Host and the Controller for buffer
sizes that include HCI events. It should be set according to the
expected HCI events that can be generated from the configuration.
If the subset of possible HCI events is unknown, this should be set to
the maximum of 255.
config BT_BUF_EVT_RX_COUNT
int "Number of HCI Event buffers"
default 3 if BT_RECV_IS_RX_THREAD
default 20 if (BT_MESH && !(BT_BUF_EVT_DISCARDABLE_COUNT > 0))
default 10
range 2 255
help
Number of buffers available for incoming HCI events from the
Controller.
config BT_BUF_EVT_DISCARDABLE_SIZE
int "Maximum supported discardable HCI Event buffer length"
range 43 255
# LE Extended Advertising Report event
default 255 if BT_BREDR || BT_EXT_ADV
# Le Advertising Report event
default 43
help
Maximum support discardable HCI event size of buffers in the separate
discardable event buffer pool. This value does not include the
HCI Event header.
The minimum size is set based on the Advertising Report. Setting
the buffer size different than BT_BUF_EVT_RX_SIZE can save memory.
config BT_BUF_EVT_DISCARDABLE_COUNT
int "Number of discardable HCI Event buffers"
range 1 255
default 20 if BT_MESH
default 3
depends on !BT_HCI_RAW
help
Number of buffers in a separate buffer pool for events which
the HCI driver considers discardable. Examples of such events
could be e.g. Advertising Reports. The benefit of having such
a pool is that the if there is a heavy inflow of such events
it will not cause the allocation for other critical events to
block and may even eliminate deadlocks in some cases.
config BT_BUF_CMD_TX_SIZE
int "Maximum support HCI Command buffer length"
# LE Set Extended Advertising Data command
default 255 if (BT_EXT_ADV || BT_BREDR)
# LE Generate DHKey v2 command
default 65
range 65 255
help
Maximum data size for each HCI Command buffer. This value does not
include the HCI Command header.
This value is used by both the Host and the Controller for buffer
sizes that include HCI commands. It should be set according to the
expected HCI commands that can be sent from the configuration.
If the subset of possible HCI commands is unknown, this should be set
to the maximum of 255.
config BT_BUF_CMD_TX_COUNT
int "Number of HCI command buffers"
default 2
range 2 64
help
Number of buffers available for outgoing HCI commands from the Host.
config BT_HAS_HCI_VS
bool
help
This option is set by the Bluetooth controller to indicate support
for the Zephyr HCI Vendor-Specific Commands and Event.
config BT_HCI_VS
bool "Zephyr HCI Vendor-Specific Commands"
depends on BT_HAS_HCI_VS || !BT_CTLR
default y if BT_HAS_HCI_VS
help
Enable support for the Zephyr HCI Vendor-Specific Commands in the
Host and/or Controller. This enables Set Version Information,
Supported Commands, Supported Features vendor commands.
config BT_HCI_VS_EXT
bool "Zephyr HCI Vendor-Specific Extensions"
depends on BT_HCI_VS
default y
help
Enable support for the Zephyr HCI Vendor-Specific Extensions in the
Host and/or Controller. This enables Write BD_ADDR, Read Build Info,
Read Static Addresses and Read Key Hierarchy Roots vendor commands.
config BT_HCI_VS_EXT_DETECT
bool "Use heuristics to guess HCI vendor extensions support in advance"
depends on BT_HCI_VS_EXT && !BT_CTLR
default y if BOARD_QEMU_X86 || BOARD_QEMU_CORTEX_M3 || BOARD_NATIVE_POSIX
help
Use some heuristics to try to guess in advance whether the controller
supports the HCI vendor extensions in advance, in order to prevent
sending vendor commands to controller which may interpret them in
completely different ways.
config BT_HCI_MESH_EXT
bool "Mesh HCI Command support"
depends on BT_BROADCASTER && BT_OBSERVER && !BT_LL_SW_SPLIT
help
Enable support for the Bluetooth Mesh HCI Commands.
config BT_WAIT_NOP
bool "Wait for \"NOP\" Command Complete event during init"
help
Emit a Command Complete event from the Controller (and wait for it
from the Host) for the NOP opcode to indicate that the Controller is
ready to receive commands.
config BT_RPA
bool
select TINYCRYPT
select TINYCRYPT_AES
config BT_ASSERT
bool "Custom Bluetooth assert implementation"
default y
help
Use a custom Bluetooth assert implementation instead of the
kernel-wide __ASSERT() when CONFIG_ASSERT is disabled.
if BT_ASSERT
config BT_ASSERT_VERBOSE
bool "Print out an assert string when using BT_ASSERT"
default y
help
When CONFIG_BT_ASSERT is enabled, this option turns on printing the
cause of the assert to the console using printk().
config BT_ASSERT_PANIC
bool "Use k_panic() instead of k_oops()"
help
When CONFIG_BT_ASSERT is enabled, this option makes the code call
k_panic() instead of k_oops() when an assertion is triggered.
endif # BT_ASSERT
config BT_DEBUG
# Hidden option to make the conditions more intuitive
bool
config BT_MONITOR
bool
choice
prompt "Bluetooth debug type"
default BT_DEBUG_NONE
config BT_DEBUG_NONE
bool "No debug log"
help
Select this to disable all Bluetooth debug logs.
config BT_DEBUG_LOG
bool "Normal printf-style to console"
select BT_DEBUG
select LOG
help
This option enables Bluetooth debug going to standard
serial console.
config BT_DEBUG_MONITOR_UART
bool "Monitor protocol over UART"
select BT_DEBUG
select LOG
select CONSOLE_HAS_DRIVER
select BT_MONITOR
help
Use a custom logging protocol over the console UART
instead of plain-text output. Requires a special application
on the host side that can decode this protocol. Currently
the 'btmon' tool from BlueZ is capable of doing this.
If the target board has two or more external UARTs it is
possible to keep using UART_CONSOLE together with this option,
however if there is only a single external UART then
UART_CONSOLE needs to be disabled (in which case printk/printf
will get encoded into the monitor protocol).
config BT_DEBUG_MONITOR_RTT
bool "Monitor protocol over RTT"
depends on USE_SEGGER_RTT
depends on SEGGER_RTT_MAX_NUM_UP_BUFFERS >= 2
select BT_DEBUG
select BT_MONITOR
help
Use a custom logging protocol over the RTT buffer instead of
plain-text output. Requires a special application
on the host side that can decode this protocol. Currently
the 'btmon' tool from BlueZ is capable of doing this.
if BT_DEBUG_MONITOR_RTT
config BT_DEBUG_MONITOR_RTT_BUFFER
int "Buffer number used for custom logger output."
range 1 SEGGER_RTT_MAX_NUM_UP_BUFFERS
default 1
help
Select index of up-buffer used for logger output.
Make sure the buffer number is not used by other logger,
e.g. in LOG_BACKEND_RTT_BUFFER, otherwise the buffer will be
overwritten.
config BT_DEBUG_MONITOR_RTT_BUFFER_NAME
string "Buffer name used for custom logger output."
default "btmonitor"
help
Select index of up-buffer used for logger output.
config BT_DEBUG_MONITOR_RTT_BUFFER_SIZE
int "Size of reserved up-buffer for custom logger output."
default 1024
help
Specify reserved size of up-buffer used for custom logger output.
endif # BT_DEBUG_MONITOR_RTT
endchoice # Bluetooth debug type
if BT_DEBUG
# Workaround for not being able to have commas in macro arguments
DT_CHOSEN_Z_BT_MON_UART := zephyr,bt-mon-uart
config BT_MONITOR_ON_DEV_NAME
string "Device Name of Bluetooth monitor logging UART"
depends on BT_DEBUG_MONITOR_UART
default "$(dt_chosen_label,$(DT_CHOSEN_Z_BT_MON_UART))" if HAS_DTS
default "UART_0"
help
This option specifies the name of UART device to be used
for the Bluetooth monitor logging.
config BT_DEBUG_HCI_DRIVER
bool "Bluetooth HCI driver debug"
help
This option enables debug support for the active
Bluetooth HCI driver, including the Controller-side HCI layer
when included in the build.
config BT_DEBUG_RPA
bool "Bluetooth Resolvable Private Address (RPA) debug"
depends on BT_RPA
help
This option enables debug support for the Bluetooth
Resolvable Private Address (RPA) generation and resolution.
endif # BT_DEBUG
Reference in New Issue View Git Blame Copy Permalink