bluetooth: fix Kconfig combination compilation issues by huangyulong3 · Pull Request #585 · open-vela/frameworks_bluetooth

huangyulong3 · 2026-05-06T09:20:26Z

Summary

Fix CS RAP module missing macro/type definitions (v/90625)
Add CONFIG_BT_SIGNING and CONFIG_BT_SMP guards in SAL LE adapter (v/90629)
Add fallback defaults for GATT client config macros (v/90631)
Add BT_RFCOMM dependency to BLUETOOTH_SPP Kconfig (v/90632)
Fix const qualifier mismatch in bt_cs_start_distance_measurement (v/90633)
Implement L2CAP dynamic channel SAL interface (v/90634)
Implement PAN profile SAL interface stub (v/90635)
Fix FRAMEWORK_LOCAL mode compilation failures (v/90636)

Test plan

Base config (goldfish-armeabi-v7a-ap) builds successfully
CONFIG_BLUETOOTH_L2CAP=y builds successfully
CONFIG_BLUETOOTH_PAN=y builds successfully
CONFIG_BLUETOOTH_FRAMEWORK_LOCAL=y builds successfully
HFP AG only / HFP HF only / GATT Client only / GATT Server only variants pass
Debug all on / AVRCP full variants pass

Related JIRAs

v/90625, v/90629, v/90631, v/90632, v/90633, v/90634, v/90635, v/90636

Signed-off-by: huangyulong3 huangyulong3@xiaomi.com

chengkai15 · 2026-05-06T09:35:48Z

 	bool "Serial Port Profile (SPP)"
 	default n
+	select BT_RFCOMM
+	select BT_RFCOMM


Done. Removed the duplicate select BT_RFCOMM line.

chengkai15 · 2026-05-06T09:55:07Z

        g_a2dp_sink.offloading = msg->data.valuebool;
        break;
    case PROFILE_EVT_REMOTE_DETACH: {
+#ifdef CONFIG_BLUETOOTH_FRAMEWORK_SOCKET_IPC


suggest do not add CONFIG_BLUETOOTH_FRAMEWORK_SOCKET_IPC within *c

Done. Moved cookie fields out of #ifdef CONFIG_BLUETOOTH_FRAMEWORK_SOCKET_IPC in bluetooth.h so they are unconditionally available in bt_instance_t. Removed all ifdefs from .c files.

chengkai15 · 2026-05-06T09:55:17Z

        g_a2dp_source.offloading = msg->data.valuebool;
        break;
    case PROFILE_EVT_REMOTE_DETACH: {
+#ifdef CONFIG_BLUETOOTH_FRAMEWORK_SOCKET_IPC


Done. Same fix — cookie fields are now unconditional in bt_instance_t.

chengkai15 · 2026-05-06T09:56:11Z

@@ -0,0 +1,34 @@
+/****************************************************************************
+ *  Copyright (C) 2024 Xiaomi Corporation


Done. Fixed copyright year to 2026.

chengkai15 · 2026-05-06T13:04:08Z

    scanner_device_t* device;
    uint32_t timestamp_ms;

+#ifdef CONFIG_BLUETOOTH_FRAMEWORK_SOCKET_IPC


suggest do not add CONFIG_BLUETOOTH_FRAMEWORK_SOCKET_IPC in service cods, maybe it coudl be add in ipc code

gzh-terry

Additional note: l2cap_service.h declares l2cap_on_cid_allocated(bt_address_t* addr, uint16_t cid, uint16_t psm) but the implementation in l2cap_service.c has signature (addr, psm, cid) — parameter names are swapped between declaration and definition. This is a pre-existing bug but since this PR adds a new caller, it would be good to fix the header to match the implementation.

gzh-terry · 2026-05-07T04:18:33Z

+    sal_l2cap_channel_t* ch = find_channel_by_le_chan(BT_L2CAP_LE_CHAN(chan));
+    if (!ch) {
+        return;
+    }


bt_sal_l2cap_init() and bt_sal_l2cap_cleanup() are declared in the header and implemented here, but never called from anywhere (e.g., l2cap_service_init() does not call bt_sal_l2cap_init()). This is dead code. Either wire them into the service lifecycle or remove them.

This is to prepare for implementing L2CAP socket communication later.

gzh-terry · 2026-05-07T04:18:33Z

+
+    *chan = &ch->le_chan.chan;
+
+    l2cap_on_cid_allocated(&ch->addr, ch->psm, 0);


bt_sal_l2cap_stop_listen_channel only marks in_use = false but the server remains registered in zblue (no bt_l2cap_server_unregister API exists). If the same PSM is listened again, bt_l2cap_server_register will fail because zblue still has it registered.

Suggestion: on re-listen, check if a server with the same PSM is already registered in zblue and reuse it instead of trying to register again.

gzh-terry · 2026-05-07T04:18:33Z

+
+    l2cap_on_channel_connected(&ch->addr, &param);
+}
+


l2cap_on_cid_allocated is documented as "for client only" in handle_cid_allocated(). Calling it from l2cap_accept_cb (server-side accept) with cid=0 will:

Fail to find any channel (searches L2CAP_CHANNEL_ROLE_CLIENT only)

Print a misleading error log: "record allocated CID: 0x0 failed!"

This call should be removed. For server-side channels, the CID is properly assigned later in l2cap_connected_cb → handle_channel_connected via param->local_cid.

gzh-terry · 2026-05-07T04:21:11Z

+bt_status_t bt_sal_pan_disconnect(bt_address_t* addr);
+bt_status_t bt_sal_pan_write(bt_address_t* addr, uint16_t protocol,
+    uint8_t* dst_addr, uint8_t* src_addr,
+    uint8_t* data, uint16_t length);


nit: dst_addr, src_addr, and data should all be const qualified. These are input-only parameters for a write/send operation — the callee should not modify them.

Same applies to bt_sal_l2cap_send_packet in sal_l2cap_interface.h — data should be const uint8_t*.

General principle: cross-layer payload pointers (app → framework → stack) that are informational/read-only should be const to express intent and catch accidental mutation at compile time.

gzh-terry · 2026-05-07T04:22:09Z

+static sal_l2cap_channel_t g_channels[L2CAP_MAX_CHANNELS];
+static sal_l2cap_server_t g_servers[L2CAP_MAX_SERVERS];


Are these arrays too large?
Can we allocate them when actually connected?

huangyulong3 · 2026-05-11T15:51:56Z

All review comments have been addressed in the latest push (commits b9363e9 and a21f41a):

@chengkai15 — re: CONFIG_BLUETOOTH_FRAMEWORK_SOCKET_IPC in scan_manager.c:
The bt_socket_server_is_busy() call and #include "bt_socket.h" are pre-existing in dev branch (not introduced by this PR). The #ifdef guard is the minimal fix to unblock compilation when SOCKET_IPC is disabled. A cleaner approach (e.g., providing a no-op stub in the IPC header or moving the busy-check into the IPC layer) can be done as a follow-up.

@gzh-terry — re: l2cap_on_cid_allocated called from l2cap_accept_cb:
Done. Removed the call — it only searches CLIENT role channels and would always fail on server-side accept with a misleading error log.

@gzh-terry — re: bt_sal_l2cap_stop_listen_channel re-listen issue:
Done. bt_sal_l2cap_listen_channel() now detects an already-registered PSM and reuses the existing server entry instead of trying to re-register (which would fail since zblue has no unregister API).

@gzh-terry — re: const qualifiers:
Done. Added const to:

bt_sal_l2cap_send_packet(data) → const uint8_t* data
bt_sal_pan_write(dst_addr, src_addr, data) → all const uint8_t*

@gzh-terry — re: g_channels[]/g_servers[] static arrays too large:
Done. Changed to pointer arrays with per-element calloc()/free(). Memory is only consumed when channels/servers are actually in use. BSS now only holds 20+8 pointers instead of full structs.

@gzh-terry — re: bt_sal_l2cap_init()/bt_sal_l2cap_cleanup() dead code:
These are intended to be called from the service manager during BT enable/disable lifecycle. Wiring them in requires changes to the adapter state machine beyond this PR's scope (Kconfig compilation fixes). Will track as a follow-up.

@gzh-terry — re: l2cap_service.h parameter order mismatch:
This is a pre-existing issue — l2cap_on_cid_allocated() has no header declaration (defined directly in l2cap_service.c). The problematic call from this PR has been removed per your other comment, so no longer relevant here. Can fix the missing declaration separately.

…dapter bug: v/90629 sal_adapter_le_interface.c unconditionally accesses struct bt_keys members remote_csrk/local_csrk (only exist when CONFIG_BT_SIGNING is enabled) and references zblue_on_pairing_complete_ctkd (only declared under CONFIG_BT_SMP). This causes compilation failure in BLE-only configurations where SMP/SIGNING may not be enabled. Add appropriate ifdef guards. Signed-off-by: huangyulong3 <huangyulong3@xiaomi.com>

bug: v/90631 sal_gatt_client_interface.c uses CONFIG_GATT_CLIENT_SERVICE_MAX, CONFIG_GATT_CLIENT_ELEMENT_MAX, and CONFIG_GATT_CLIENT_CHAR_PER_SERVICE_MAX as array sizes, but these Kconfig options depend on multiple configs being enabled simultaneously. In some config combinations they are undefined, causing compilation failure. Add #ifndef fallback defaults (20, 200, 100). Signed-off-by: huangyulong3 <huangyulong3@xiaomi.com>

bug: v/90632 BLUETOOTH_SPP does not select BT_RFCOMM. When HFP (which normally brings in RFCOMM via its own select) is disabled but SPP remains enabled, RFCOMM is not compiled into the zblue library, causing undefined reference errors for bt_rfcomm_dlc_connect, bt_rfcomm_server_register, etc. Add explicit select BT_RFCOMM to the BLUETOOTH_SPP menuconfig. Signed-off-by: huangyulong3 <huangyulong3@xiaomi.com>

…rement bug: v/90633 bt_cs.h declares bt_cs_start_distance_measurement with const parameter but the implementation in bt_cs.c and the interface typedef in cs_service.h omit const, causing -Wdiscarded-qualifiers warnings and potential build failure with -Werror. Align implementation and interface with the header declaration. Signed-off-by: huangyulong3 <huangyulong3@xiaomi.com>

bug: v/90634 When CONFIG_BLUETOOTH_L2CAP is enabled, l2cap_service.c references sal_l2cap_interface.h and bt_sal_l2cap_* functions which were never implemented, causing fatal compilation error. Implement the SAL L2CAP interface header and zblue-based implementation supporting channel listen, connect, disconnect, and data send operations. Add build rules to Makefile. Channels and servers are dynamically allocated via calloc/free to minimize BSS footprint when L2CAP connections are idle. Server entries are kept allocated after stop_listen since zblue has no unregister API, and reused on re-listen for the same PSM. Signed-off-by: huangyulong3 <huangyulong3@xiaomi.com>

bug: v/90635 When CONFIG_BLUETOOTH_PAN is enabled, pan_service.c references sal_pan_interface.h and bt_sal_pan_* functions which were never implemented, causing fatal compilation error. Add SAL PAN interface header and zblue-based stub implementation that returns BT_STATUS_NOT_SUPPORTED (BNEP not yet available in zblue). Add build rules to Makefile. Input-only pointer parameters (dst_addr, src_addr, data) are const qualified to express intent and prevent accidental mutation. Signed-off-by: huangyulong3 <huangyulong3@xiaomi.com>

bug: v/90636 When CONFIG_BLUETOOTH_FRAMEWORK_LOCAL is enabled (no socket IPC), several compilation errors occur: - bt_instance_t cookie fields are guarded by SOCKET_IPC ifdef but referenced unconditionally in service code. Move cookie fields out of the ifdef so they are always available. - scan_manager.c calls bt_socket_server_is_busy() which only exists when SOCKET_IPC is enabled. Add ifdef guard around the call. Signed-off-by: huangyulong3 <huangyulong3@xiaomi.com>

huangyulong3 requested review from chengkai15, gzh-terry, hyson710, zhangyuan376 and zhongzhijie1 as code owners May 6, 2026 09:20

huangyulong3 force-pushed the feature/fix_bluetooth_kconfig_combination_issues branch from f630c8c to 3337ab9 Compare May 6, 2026 09:21

chengkai15 reviewed May 6, 2026

View reviewed changes

huangyulong3 force-pushed the feature/fix_bluetooth_kconfig_combination_issues branch 4 times, most recently from 561f9fe to 9576771 Compare May 6, 2026 11:03

chengkai15 reviewed May 6, 2026

View reviewed changes

gzh-terry reviewed May 7, 2026

View reviewed changes

liujinye-sys force-pushed the dev branch from d6b8e00 to 0cf1898 Compare May 9, 2026 06:44

huangyulong3 force-pushed the feature/fix_bluetooth_kconfig_combination_issues branch from 9576771 to 4d949d8 Compare May 11, 2026 14:22

huangyulong3 added 7 commits May 11, 2026 23:55

huangyulong3 force-pushed the feature/fix_bluetooth_kconfig_combination_issues branch from a21f41a to fb31f0d Compare May 11, 2026 15:59

		@@ -0,0 +1,34 @@
		/****************************************************************************
		* Copyright (C) 2024 Xiaomi Corporation


		*chan = &ch->le_chan.chan;

		l2cap_on_cid_allocated(&ch->addr, ch->psm, 0);

		static sal_l2cap_channel_t g_channels[L2CAP_MAX_CHANNELS];
		static sal_l2cap_server_t g_servers[L2CAP_MAX_SERVERS];

Conversation

huangyulong3 commented May 6, 2026

Summary

Test plan

Related JIRAs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gzh-terry left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

huangyulong3 commented May 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants