|  | # 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_GATT | 
|  | 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)) || BT_PER_ADV | 
|  | # 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 Set Connection CTE Receive Parameters. Value required to store max allowed number | 
|  | # of antenna ids for platforms other than Nordic. | 
|  | default 83 if (!BT_EXT_ADV && !BT_BREDR && BT_CTLR_DF && BT_CTLR_DF_CONN_CTE_REQ && !SOC_COMPATIBLE_NRF) | 
|  | # 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 BT_DEBUG_TYPE | 
|  | 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 | 
|  |  | 
|  | 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 |