* [bluez/bluez] 7059a2: shared: Add create_context CS config parameter
From: Bhavani @ 2026-07-17 14:17 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1129618
Home: https://github.com/bluez/bluez
Commit: 7059a2547f09eb71e3fe0faf597918d9e658ed73
https://github.com/bluez/bluez/commit/7059a2547f09eb71e3fe0faf597918d9e658ed73
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-07-17 (Fri, 17 Jul 2026)
Changed paths:
M src/shared/cs-types.h
Log Message:
-----------
shared: Add create_context CS config parameter
Add create_context in bt_rap_le_cs_config structure
Commit: ee37dfde9ccfd98fd8ac9d19065d10b654c6db0b
https://github.com/bluez/bluez/commit/ee37dfde9ccfd98fd8ac9d19065d10b654c6db0b
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-07-17 (Fri, 17 Jul 2026)
Changed paths:
M profiles/ranging/rap.c
M profiles/ranging/rap_hci.c
Log Message:
-----------
profiles: Add create_context param as part of CS Create Config cmd
- Add the create_context field to the CS Create Config command.
- Route HCI command-send failures and non-zero-status completion
events to CS_STATE_HOLD instead of CS_STATE_STOPPED.
reserving CS_STATE_STOPPED for the clean/expected
stop (Procedure Enable Complete with state == 0x00)
Commit: 54de92d0bf259b924f89566ab777043fa467d900
https://github.com/bluez/bluez/commit/54de92d0bf259b924f89566ab777043fa467d900
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-07-17 (Fri, 17 Jul 2026)
Changed paths:
M client/cs.c
M client/cs.h
Log Message:
-----------
client: Add create_context CS config parameter
- Add the create_context field to the CS config parameter table so
bluetoothctl can control whether cs.start writes the CS configuration
to the local Controller only (0x00) or to both local and remote
Controllers via the CS Configuration procedure (0x01), matching the
Create_Context field of the LE CS Create Config HCI command
- Change the license in cs.c and cs.h.
- Drop RangingInterface support for now,
as it is still under discussion.
Commit: 9efbc3b2c56a230045209606316e6bcb3dee6f5e
https://github.com/bluez/bluez/commit/9efbc3b2c56a230045209606316e6bcb3dee6f5e
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-07-17 (Fri, 17 Jul 2026)
Changed paths:
M doc/bluetoothctl-cs.rst
Log Message:
-----------
doc: Document create_context in bluetoothctl-cs.rst
Document the new create_context parameter introduced in client/cs.c.
Compare: https://github.com/bluez/bluez/compare/7059a2547f09%5E...9efbc3b2c56a
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH BlueZ v2] adapter: Infer BR/EDR only at public LE addresses
From: Luiz Augusto von Dentz @ 2026-07-17 14:14 UTC (permalink / raw)
To: Philipp Dunkel; +Cc: linux-bluetooth
In-Reply-To: <20260717082347.8429-1-pip@pipobscure.com>
Hi Philipp,
On Fri, Jul 17, 2026 at 4:27 AM Philipp Dunkel <pip@pipobscure.com> wrote:
>
> btd_adapter_device_found() records BR/EDR support for any LE device
> whose advertising Flags lack "BR/EDR Not Supported" (EIR_BREDR_UNSUP).
> The address type is not considered:
>
> if (bdaddr_type != BDADDR_BREDR && eir_data.flags &&
> !(eir_data.flags & EIR_BREDR_UNSUP)) {
> device_set_bredr_support(dev);
>
> When the advertisement uses a random address the device gets a BR/EDR
> bearer whose address is that random address, and start_discovery_cb()
> then prefers SDP over GATT:
>
> if (device->bredr)
> device_browse_sdp(device, NULL);
> else
> device_browse_gatt(device, NULL);
>
> SDP requires a BR/EDR ACL, so bluetoothd pages the random address. A
> random address is not a BD_ADDR and cannot be paged, so the attempt
> always ends in Page Timeout, and the failure tears down the working LE
> link:
>
> connect_failed_callback() hci0 5A:B4:98:1F:CC:04 status 4
> bonding_attempt_complete() hci0 bdaddr 5A:B4:98:1F:CC:04
> type 0 status 0x4
> device_bonding_complete() bonding (nil) status 0x04
> browse_request_cancel()
> btd_gatt_database_att_disconnected()
>
> Nothing requested the connection ("bonding (nil)") and the LE link was
> healthy. Any LE association that outlives the page timeout is killed by
> it; measured on one host, applications get about 4.7 s from connect
> before the link disappears, of which GATT discovery already takes 2.3 s.
>
> Current phones advertise Flags 0x1a (LE General Discoverable plus
> Simultaneous LE and BR/EDR, with BR/EDR Not Supported clear) from
> resolvable private addresses, so this triggers routinely rather than in
> some corner case.
>
> The Flags bits describe what the device supports. They do not promise
> that the address it is advertising from is a BD_ADDR. A dual-mode device
> uses the same Public Device Address for BR/EDR and LE, so the inference
> is sound only for BDADDR_LE_PUBLIC. Restrict it to that.
>
> The other two device_set_bredr_support() callers already require the
> device to have been seen over BR/EDR (bdaddr_type == BDADDR_BREDR), so
> they are unaffected. A device later seen over BR/EDR, or whose RPA is
> resolved to a public identity, still gets BR/EDR support recorded there.
> ---
> Changes in v2:
> - Commit message only; the code change is byte-for-byte identical to v1.
> - Dropped the "Assisted-by:" trailer, which checkpatch rejected as a
> non-standard signature with an unrecognized email address. The
> disclosure is kept below the --- instead, see the note at the end.
This is a false positive, in fact we do want to know if this was
created by an AI Model.
> - Quoted the two code excerpts with spaces rather than hard tabs
> (gitlint B3).
> - Wrapped the bonding_attempt_complete() log line, which was 76 chars,
> onto a continuation line to fit 75. The text is unchanged.
>
> This patch was developed with assistance from Claude Code
> (claude-opus-4-8). It was reviewed line by line and the results below
> reproduced on real hardware by me before submitting; nothing here is
> inferred.
>
> Verified on a dual-mode controller with ControllerMode=dual, against iOS and
> Android peers advertising Flags 0x1a from resolvable private addresses. A GATT
> association that includes a ~7 s user prompt, which previously failed every
> time at ~4.7 s with the Page Timeout above, now completes:
>
> before: connect +0.0s, GATT resolved +2.3s, first exchange +2.7s,
> Page Timeout +4.7s -> LE link destroyed, transfer never completed
> after: same host, same peers, classic still enabled, transfer completes
> with the user prompt taking 7.0s of it
>
> Setting ControllerMode=le instead of applying the patch also makes the failure
> go away, which independently confirms the mechanism: with no classic radio
> there is no page to time out. The patch achieves the same without giving up
> BR/EDR, and A2DP/HFP continue to work on the host afterwards.
>
> make is clean with no new warnings in src/adapter.c, and make check passes
> 39/39.
>
> No unit test is included: src/adapter.c is linked only into bluetoothd and not
> into any unit test target, so btd_adapter_device_found() cannot be exercised by
> the existing harness. Extracting the check into a unit-testable helper looked
> like scope creep for a bug fix, but I am happy to add that if preferred.
>
> src/adapter.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/src/adapter.c b/src/adapter.c
> index 4ffa32a..30e7679 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -7415,8 +7415,17 @@ void btd_adapter_device_found(struct btd_adapter *adapter,
> * older kernels send separate adv_ind and scan_rsp. Newer
> * kernels send them merged, so once we know which mgmt version
> * supports this we can make the non-zero check conditional.
> + *
> + * Only infer BR/EDR support when the LE address is a Public Device
> + * Address. A dual-mode device uses the same Public Device Address for
> + * BR/EDR and LE, so in that case the advertised address is also a valid
> + * BD_ADDR to page. A random address (static, resolvable or
> + * non-resolvable) has no defined relationship to the device's BD_ADDR,
> + * so recording BR/EDR support against it makes the device look pageable
> + * at an address that can never be paged: SDP discovery then fails with
> + * Page Timeout and takes the working LE link down with it.
> */
> - if (bdaddr_type != BDADDR_BREDR && eir_data.flags &&
> + if (bdaddr_type == BDADDR_LE_PUBLIC && eir_data.flags &&
> !(eir_data.flags & EIR_BREDR_UNSUP)) {
> device_set_bredr_support(dev);
> /* Update last seen for BR/EDR in case its flag is set */
> --
> 2.55.0
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ v4 2/2] profiles: Register RAS UUID reactively instead of probing
From: Luiz Augusto von Dentz @ 2026-07-17 14:06 UTC (permalink / raw)
To: Naga Bhavani Akella
Cc: linux-bluetooth, quic_mohamull, quic_hbandi, quic_anubhavg
In-Reply-To: <CABBYNZJuitiNCz_COYYvUEY6_TbB=d6dZet=XEmHUkh=ENrzSg@mail.gmail.com>
Hi Naga,
On Fri, Jul 17, 2026 at 10:02 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Naga,
>
> On Fri, Jul 17, 2026 at 8:41 AM Naga Bhavani Akella
> <naga.akella@oss.qualcomm.com> wrote:
> >
> > Replace the unconditional reflector-role GATT_UUID probe in
> > gatt_client_init() with a reactive registration driven by actual
> > remote RAS access, using the notification API added in shared/rap.
>
> It seems you already have something like that in bt_rap_register
> attached callback, it is just never used, which explains why
> rap_attached is never called and you need the likes of probe in order
> to create rap_data_new.
In case I wasn't clear, I meant shared/bap.c needs to call
rap->attached callback whenever a session is connected, just follow
what was done in the likes of shared/bap.c which does bt_bap_attach ->
bap->attached, so bt_rap_attach shall probably call rap->attached.
>
> > ---
> > profiles/ranging/rap.c | 25 +++++++++++++++++++++++++
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/profiles/ranging/rap.c b/profiles/ranging/rap.c
> > index 3ffc0da76..4f6d7f2db 100644
> > --- a/profiles/ranging/rap.c
> > +++ b/profiles/ranging/rap.c
> > @@ -308,6 +308,27 @@ static void rap_attached(struct bt_rap *rap, void *user_data)
> > rap_data_add(data);
> > }
> >
> > +static void rap_ras_accessed(struct bt_att *att, void *user_data)
> > +{
> > + struct btd_device *device;
> > + struct btd_service *service;
> > +
> > + device = btd_adapter_find_device_by_fd(bt_att_get_fd(att));
> > + if (!device) {
> > + error("unable to find device for RAS access");
> > + return;
> > + }
> > +
> > + service = btd_device_get_service(device, GATT_UUID);
> > + if (!service) {
> > + btd_device_add_uuid(device, GATT_UUID);
> > + service = btd_device_get_service(device, GATT_UUID);
> > + }
> > +
> > + if (service)
> > + service_accept(service, btd_device_is_initiator(device));
> > +}
> > +
> > enum cs_dict_target {
> > CS_TARGET_SETTINGS,
> > CS_TARGET_CFG,
> > @@ -830,6 +851,7 @@ static struct btd_profile rap_profile = {
> > };
> >
> > static unsigned int rap_id;
> > +static unsigned int rap_ras_accessed_id;
> >
> > static int rap_init(void)
> > {
> > @@ -840,6 +862,8 @@ static int rap_init(void)
> > return err;
> >
> > rap_id = bt_rap_register(rap_attached, rap_detached, NULL);
> > + rap_ras_accessed_id = bt_rap_ras_accessed_register(rap_ras_accessed,
> > + NULL);
> >
> > return 0;
> > }
> > @@ -848,6 +872,7 @@ static void rap_exit(void)
> > {
> > btd_profile_unregister(&rap_profile);
> > bt_rap_unregister(rap_id);
> > + bt_rap_ras_accessed_unregister(rap_ras_accessed_id);
> > }
> >
> > BLUETOOTH_PLUGIN_DEFINE(rap, VERSION, BLUETOOTH_PLUGIN_PRIORITY_DEFAULT,
> > --
> >
>
>
> --
> Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ v4 2/2] profiles: Register RAS UUID reactively instead of probing
From: Luiz Augusto von Dentz @ 2026-07-17 14:02 UTC (permalink / raw)
To: Naga Bhavani Akella
Cc: linux-bluetooth, quic_mohamull, quic_hbandi, quic_anubhavg
In-Reply-To: <20260717124111.3296537-3-naga.akella@oss.qualcomm.com>
Hi Naga,
On Fri, Jul 17, 2026 at 8:41 AM Naga Bhavani Akella
<naga.akella@oss.qualcomm.com> wrote:
>
> Replace the unconditional reflector-role GATT_UUID probe in
> gatt_client_init() with a reactive registration driven by actual
> remote RAS access, using the notification API added in shared/rap.
It seems you already have something like that in bt_rap_register
attached callback, it is just never used, which explains why
rap_attached is never called and you need the likes of probe in order
to create rap_data_new.
> ---
> profiles/ranging/rap.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/profiles/ranging/rap.c b/profiles/ranging/rap.c
> index 3ffc0da76..4f6d7f2db 100644
> --- a/profiles/ranging/rap.c
> +++ b/profiles/ranging/rap.c
> @@ -308,6 +308,27 @@ static void rap_attached(struct bt_rap *rap, void *user_data)
> rap_data_add(data);
> }
>
> +static void rap_ras_accessed(struct bt_att *att, void *user_data)
> +{
> + struct btd_device *device;
> + struct btd_service *service;
> +
> + device = btd_adapter_find_device_by_fd(bt_att_get_fd(att));
> + if (!device) {
> + error("unable to find device for RAS access");
> + return;
> + }
> +
> + service = btd_device_get_service(device, GATT_UUID);
> + if (!service) {
> + btd_device_add_uuid(device, GATT_UUID);
> + service = btd_device_get_service(device, GATT_UUID);
> + }
> +
> + if (service)
> + service_accept(service, btd_device_is_initiator(device));
> +}
> +
> enum cs_dict_target {
> CS_TARGET_SETTINGS,
> CS_TARGET_CFG,
> @@ -830,6 +851,7 @@ static struct btd_profile rap_profile = {
> };
>
> static unsigned int rap_id;
> +static unsigned int rap_ras_accessed_id;
>
> static int rap_init(void)
> {
> @@ -840,6 +862,8 @@ static int rap_init(void)
> return err;
>
> rap_id = bt_rap_register(rap_attached, rap_detached, NULL);
> + rap_ras_accessed_id = bt_rap_ras_accessed_register(rap_ras_accessed,
> + NULL);
>
> return 0;
> }
> @@ -848,6 +872,7 @@ static void rap_exit(void)
> {
> btd_profile_unregister(&rap_profile);
> bt_rap_unregister(rap_id);
> + bt_rap_ras_accessed_unregister(rap_ras_accessed_id);
> }
>
> BLUETOOTH_PLUGIN_DEFINE(rap, VERSION, BLUETOOTH_PLUGIN_PRIORITY_DEFAULT,
> --
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH BlueZ v1 4/4] doc: Document create_context in bluetoothctl-cs.rst
From: Naga Bhavani Akella @ 2026-07-17 13:35 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
In-Reply-To: <20260717133503.3711396-1-naga.akella@oss.qualcomm.com>
Document the new create_context parameter introduced in client/cs.c.
---
doc/bluetoothctl-cs.rst | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/doc/bluetoothctl-cs.rst b/doc/bluetoothctl-cs.rst
index bbc1d8565..e49b4ea08 100644
--- a/doc/bluetoothctl-cs.rst
+++ b/doc/bluetoothctl-cs.rst
@@ -191,6 +191,24 @@ Get/set the CS configuration identifier.
:Example Set config id to 1:
| **> config_id 1**
+create_context
+--------------
+
+Get/set where the CS configuration is written when **cs.start** sends
+it to the Controller.
+
+:Usage: **> create_context [0|1]**
+:[0|1]: ``0x00`` write the configuration to the local Controller only;
+ ``0x01`` also write it to the remote Controller using the CS
+ Configuration procedure (optional, shows current if omitted;
+ default ``1``)
+:Example Show current value:
+ | **> create_context**
+:Example Write the configuration to the local Controller only:
+ | **> create_context 0**
+:Example Write the configuration to both local and remote Controllers:
+ | **> create_context 1**
+
main_mode_type
--------------
--
^ permalink raw reply related
* [PATCH BlueZ v1 3/4] client: Add create_context CS config parameter
From: Naga Bhavani Akella @ 2026-07-17 13:35 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
In-Reply-To: <20260717133503.3711396-1-naga.akella@oss.qualcomm.com>
- Add the create_context field to the CS config parameter table so
bluetoothctl can control whether cs.start writes the CS configuration
to the local Controller only (0x00) or to both local and remote
Controllers via the CS Configuration procedure (0x01), matching the
Create_Context field of the LE CS Create Config HCI command
- Change the license in cs.c and cs.h.
- Drop RangingInterface support for now,
as it is still under discussion.
---
client/cs.c | 109 +++++++++-------------------------------------------
client/cs.h | 2 +-
2 files changed, 19 insertions(+), 92 deletions(-)
diff --git a/client/cs.c b/client/cs.c
index 89251b502..9f069589d 100644
--- a/client/cs.c
+++ b/client/cs.c
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: LGPL-2.1-or-later
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
* BlueZ - Bluetooth protocol stack for Linux
*
@@ -25,21 +25,6 @@
static GList * cs_proxies;
static GList **cs_device_list;
-static DBusConnection *dbus_conn;
-
-#define RANGING_INTERFACE "org.bluez.ChannelSoundingRanging1"
-#define RANGE_ESTIMATE "RangeEstimate"
-
-/* One signal watch per device proxy, so each device's RangeEstimate
- * watch can be independently added/removed instead of clobbering a
- * single shared handle.
- */
-struct cs_watch {
- GDBusProxy *proxy;
- guint watch_id;
-};
-
-static GList *cs_watches;
/* ---- Per-device active session ---- */
@@ -58,6 +43,7 @@ static uint8_t cs_sync_ant = 0xFF;
static int8_t cs_max_tx_power = 0x14;
static struct {
+ uint8_t create_context;
uint8_t config_id;
uint8_t main_mode_type;
uint8_t sub_mode_type;
@@ -75,6 +61,7 @@ static struct {
uint8_t channel_jump;
uint8_t companion_signal_enable;
} cs_cfg = {
+ .create_context = 0x01,
.config_id = 0x00,
.main_mode_type = 0x01,
.sub_mode_type = 0xFF,
@@ -138,6 +125,10 @@ struct cs_param_desc {
};
static const struct cs_param_desc cs_param_table[] = {
+ { .name = "create_context", .type = CS_PARAM_U8_RANGE,
+ .field = &cs_cfg.create_context, .min = 0, .max = 1,
+ .range_error = "create_context: 0x00=local only"
+ " 0x01=local and remote\n" },
{ .name = "sync_ant_sel", .type = CS_PARAM_U8, .field = &cs_sync_ant },
{ .name = "config_id", .type = CS_PARAM_U8,
.field = &cs_cfg.config_id },
@@ -195,74 +186,14 @@ static const struct cs_param_desc cs_param_table[] = {
.field = &cs_freq.snr_control_reflector },
};
-static gboolean range_estimate_cb(DBusConnection *connection,
- DBusMessage *msg, void *user_data)
-{
- GDBusProxy *proxy = user_data;
- DBusMessageIter iter;
- double distance;
- uint8_t confidence;
-
- if (!dbus_message_iter_init(msg, &iter))
- return TRUE;
-
- if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_DOUBLE)
- return TRUE;
-
- dbus_message_iter_get_basic(&iter, &distance);
- dbus_message_iter_next(&iter);
-
- if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_BYTE)
- return TRUE;
-
- dbus_message_iter_get_basic(&iter, &confidence);
-
- bt_shell_printf("[CS] %s Distance: %.3f m Confidence: %u%%\n",
- g_dbus_proxy_get_path(proxy), distance, confidence);
-
- return TRUE;
-}
-
-static struct cs_watch *cs_find_watch(GDBusProxy *proxy)
-{
- struct cs_watch *w;
- GList *list;
-
- for (list = g_list_first(cs_watches); list; list = g_list_next(list)) {
- w = list->data;
-
- if (w->proxy == proxy)
- return w;
- }
-
- return NULL;
-}
-
void cs_proxy_added(GDBusProxy *proxy)
{
- struct cs_watch *w;
-
cs_proxies = g_list_append(cs_proxies, proxy);
-
- if (!dbus_conn)
- dbus_conn = bt_shell_get_env("DBUS_CONNECTION");
-
- if (!dbus_conn)
- return;
-
- w = g_new0(struct cs_watch, 1);
- w->proxy = proxy;
- w->watch_id = g_dbus_add_signal_watch(dbus_conn, NULL,
- g_dbus_proxy_get_path(proxy),
- RANGING_INTERFACE, RANGE_ESTIMATE,
- range_estimate_cb, proxy, NULL);
- cs_watches = g_list_append(cs_watches, w);
}
void cs_proxy_removed(GDBusProxy *proxy)
{
struct cs_session *s;
- struct cs_watch *w;
GList *list;
cs_proxies = g_list_remove(cs_proxies, proxy);
@@ -277,13 +208,6 @@ void cs_proxy_removed(GDBusProxy *proxy)
break;
}
}
-
- w = cs_find_watch(proxy);
- if (w) {
- g_dbus_remove_watch(dbus_conn, w->watch_id);
- cs_watches = g_list_remove(cs_watches, w);
- g_free(w);
- }
}
/* Drop any active CS session for a device proxy path on disconnect. */
@@ -506,6 +430,8 @@ static void start_measurement_setup(DBusMessageIter *iter, void *user_data)
dict_append_byte(&dict, "max_tx_power", tx);
/* CS config */
+ dict_append_byte(&dict, "create_context",
+ cs_cfg.create_context);
dict_append_byte(&dict, "config_id",
cs_cfg.config_id);
dict_append_byte(&dict, "main_mode_type",
@@ -951,6 +877,9 @@ static void cmd_cs_show(int argc, char *argv[])
bt_shell_printf(" max_tx_power : %d dBm\n", cs_max_tx_power);
bt_shell_printf("\n=== CS Config Params ===\n");
+ bt_shell_printf(" create_context : %u"
+ " (0=local only 1=local+remote)\n",
+ cs_cfg.create_context);
bt_shell_printf(" config_id : %u\n",
cs_cfg.config_id);
bt_shell_printf(" main_mode_type : 0x%02x\n",
@@ -1051,6 +980,12 @@ static const struct bt_shell_menu cs_menu = {
"Max TX power in dBm, signed (default 20)" },
{ "config_id", "<value>", cmd_cs_set,
"CS configuration identifier (default 0)" },
+ { "create_context", "<0|1>", cmd_cs_set,
+ "0x00 writes the CS config to the local"
+ " Controller only; 0x01 also writes it to"
+ " the remote Controller via the CS"
+ " Configuration procedure (default 1)",
+ cs_bool_generator },
{ "main_mode_type", "<1|2|3>", cmd_cs_set,
"1 Mode 1 (RTT), 2 Mode 2 (PBR), 3 Both"
" (default 1)",
@@ -1144,14 +1079,6 @@ void cs_remove_submenu(void)
g_list_free_full(cs_sessions, g_free);
cs_sessions = NULL;
- while (cs_watches) {
- struct cs_watch *w = cs_watches->data;
-
- g_dbus_remove_watch(dbus_conn, w->watch_id);
- cs_watches = g_list_remove(cs_watches, w);
- g_free(w);
- }
-
g_list_free(cs_proxies);
cs_proxies = NULL;
}
diff --git a/client/cs.h b/client/cs.h
index 8902c8143..243d2a72b 100644
--- a/client/cs.h
+++ b/client/cs.h
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: LGPL-2.1-or-later
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
* BlueZ - Bluetooth protocol stack for Linux
*
--
^ permalink raw reply related
* [PATCH BlueZ v1 2/4] profiles: Add create_context param as part of CS Create Config cmd
From: Naga Bhavani Akella @ 2026-07-17 13:35 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
In-Reply-To: <20260717133503.3711396-1-naga.akella@oss.qualcomm.com>
- Add the create_context field to the CS Create Config command.
- Route HCI command-send failures and non-zero-status completion
events to CS_STATE_HOLD instead of CS_STATE_STOPPED.
reserving CS_STATE_STOPPED for the clean/expected
stop (Procedure Enable Complete with state == 0x00)
---
profiles/ranging/rap.c | 1 +
profiles/ranging/rap_hci.c | 42 +++++++++++++++++++++++---------------
2 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/profiles/ranging/rap.c b/profiles/ranging/rap.c
index 3ffc0da76..082c35558 100644
--- a/profiles/ranging/rap.c
+++ b/profiles/ranging/rap.c
@@ -337,6 +337,7 @@ struct cs_dict_param_desc {
static const struct cs_dict_param_desc cs_dict_param_table[] = {
CS_SETTINGS_FIELD("role", role),
CS_SETTINGS_FIELD("sync_ant_sel", cs_sync_ant_sel),
+ CS_CFG_FIELD("create_context", create_context),
CS_CFG_FIELD("config_id", config_id),
CS_CFG_FIELD("main_mode_type", main_mode_type),
CS_CFG_FIELD("sub_mode_type", sub_mode_type),
diff --git a/profiles/ranging/rap_hci.c b/profiles/ranging/rap_hci.c
index e57f967a2..58ccf87bf 100644
--- a/profiles/ranging/rap_hci.c
+++ b/profiles/ranging/rap_hci.c
@@ -282,6 +282,7 @@ static void cs_state_machine_init(struct cs_state_machine *sm,
sm->cs_opt.max_tx_power = max_tx_power;
sm->cs_opt.rtt_type = 0;
+ sm->cs_config.create_context = 0x01;
sm->cs_config.config_id = 0;
sm->cs_config.main_mode_type = 0x01;
sm->cs_config.sub_mode_type = 0xFF;
@@ -459,7 +460,12 @@ static void rap_send_hci_cs_create_config_command(struct cs_state_machine *sm,
memset(&cmd, 0, sizeof(cmd));
cmd.handle = cpu_to_le16(handle);
- cmd.create_context = 0x01; /* Initiates cs config procedure */
+
+ /* 0x00: write config to the local Controller only.
+ * 0x01: write config to both local and remote Controllers using
+ * the CS Configuration procedure.
+ */
+ cmd.create_context = sm->cs_config.create_context;
cmd.config_id = sm->cs_config.config_id;
cmd.main_mode_type = sm->cs_config.main_mode_type;
@@ -483,7 +489,7 @@ static void rap_send_hci_cs_create_config_command(struct cs_state_machine *sm,
if (!status) {
error("Failed to send CS Create Config command");
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
return;
}
@@ -530,10 +536,10 @@ static void rap_def_settings_done_cb(const void *data, uint8_t size,
DBG("Reflector role: Waiting for CS Config Completed");
}
} else {
- /* Error - transition to stopped */
+ /* Error - transition to hold */
error("CS Set default setting failed with status 0x%02X",
rp->status);
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
}
}
@@ -559,7 +565,7 @@ static void rap_send_hci_cs_remove_config_command(struct cs_state_machine *sm,
if (!status) {
error("Failed to send CS Remove Config command");
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
return;
}
@@ -587,7 +593,7 @@ static void rap_send_hci_cs_security_enable_command(
if (!status) {
error("Failed to send CS Security Enable command");
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
return;
}
@@ -751,7 +757,7 @@ static void rap_rd_rem_fae_cmplt_evt(const void *data, uint8_t size,
}
error("Remote FAE Table read failed with status 0x%02X",
evt->status);
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
return;
}
@@ -838,7 +844,7 @@ static void rap_rd_rmt_supp_cap_cmplt_evt(const void *data, uint8_t size,
if (evt->status != 0) {
error("Remote capabilities failed with status 0x%02X",
evt->status);
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
return;
}
@@ -920,7 +926,7 @@ static void rap_cs_config_cmplt_evt(const void *data, uint8_t size,
error("CS Config Remove failed with status 0x%02X",
evt->status);
}
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
return;
}
@@ -977,14 +983,14 @@ static void rap_cs_config_cmplt_evt(const void *data, uint8_t size,
mapping = find_mapping_by_handle(sm, evt->handle);
if (!mapping || !mapping->is_central) {
error("CS Security Enable skipped: not BLE Central");
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
return;
}
if (bt_att_get_security(mapping->att, NULL) <
BT_ATT_SECURITY_MEDIUM) {
error("CS Security Enable skipped: not encrypted");
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
return;
}
@@ -1052,7 +1058,7 @@ static void rap_cs_sec_enable_cmplt_evt(const void *data, uint8_t size,
if (!rap_send_hci_cs_set_procedure_parameters(
sm, handle)) {
error("Failed to send CS Set Procedure Params");
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
return;
}
@@ -1060,7 +1066,7 @@ static void rap_cs_sec_enable_cmplt_evt(const void *data, uint8_t size,
if (!rap_send_hci_cs_procedure_enable(sm, handle,
true)) {
error("Failed to send CS Procedure Enable");
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
return;
}
} else {
@@ -1068,10 +1074,10 @@ static void rap_cs_sec_enable_cmplt_evt(const void *data, uint8_t size,
DBG("Reflector role: Waiting for CS Proc compl event");
}
} else {
- /* Error - transition to stopped */
+ /* Error - transition to hold */
error("Security enable failed with status 0x%02X",
rap_ev.status);
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
}
/* Send callback to RAP Profile */
@@ -1097,7 +1103,8 @@ static void rap_cs_proc_enable_cmplt_evt(const void *data, uint8_t size,
DBG("size=0x%02X", size);
if ((cs_get_current_state(sm) != CS_STATE_WAIT_PROC_CMPLT) &&
- (cs_get_current_state(sm) != CS_STATE_STARTED)) {
+ (cs_get_current_state(sm) != CS_STATE_STARTED) &&
+ (cs_get_current_state(sm) != CS_STATE_STOPPED)) {
DBG("Event received in Wrong State!! ");
DBG("Expected : CS_STATE_WAIT_PROC_CMPLT");
return;
@@ -1116,7 +1123,7 @@ static void rap_cs_proc_enable_cmplt_evt(const void *data, uint8_t size,
if (evt->status != 0) {
error("Procedure enable failed with status 0x%02X",
evt->status);
- cs_set_state(sm, CS_STATE_STOPPED);
+ cs_set_state(sm, CS_STATE_HOLD);
sm->procedure_active = false;
if (sm->proc_active_func)
sm->proc_active_func(false, sm->proc_active_data);
@@ -1816,6 +1823,7 @@ void bt_rap_clear_conn_handle(void *hci_sm, uint16_t handle)
DBG("Clearing connection mapping: handle=0x%04X", handle);
remove_conn_mapping(sm, handle);
sm->procedure_active = false;
+ sm->current_state = CS_STATE_UNSPECIFIED;
}
bool bt_rap_is_procedure_active(void *hci_sm)
--
^ permalink raw reply related
* [PATCH BlueZ v1 1/4] shared: Add create_context CS config parameter
From: Naga Bhavani Akella @ 2026-07-17 13:35 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
In-Reply-To: <20260717133503.3711396-1-naga.akella@oss.qualcomm.com>
Add create_context in bt_rap_le_cs_config structure
---
src/shared/cs-types.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/shared/cs-types.h b/src/shared/cs-types.h
index 0d53d4ab8..f894f8796 100644
--- a/src/shared/cs-types.h
+++ b/src/shared/cs-types.h
@@ -10,6 +10,7 @@
#include <stdint.h>
struct bt_rap_le_cs_config {
+ uint8_t create_context;
uint8_t config_id;
uint8_t main_mode_type;
uint8_t sub_mode_type;
--
^ permalink raw reply related
* [PATCH BlueZ v1 0/4] CS: Add create_context support
From: Naga Bhavani Akella @ 2026-07-17 13:34 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
This series adds end-to-end support for the create_context parameter
across the shared, profile, and bluetoothctl layers, allowing users to
control the Create_Context behavior from bluetoothctl and propagating
the setting down to the HCI command.
In addition, the series improves CS state handling by transitioning to
CS_STATE_HOLD on HCI command transmission failures and non-zero command
completion statuses, reserving CS_STATE_STOPPED for the expected
procedure termination indicated by a Procedure Enable Complete event
with state == 0x00.
Finally, the series updates the license headers in cs.c and cs.h and
removes the RangingInterface-related code for now, as the interface is
still under discussion.
Naga Bhavani Akella (4):
shared: Add create_context CS config parameter
profiles: Add create_context param as part of CS Create Config cmd
client: Add create_context CS config parameter
doc: Document create_context in bluetoothctl-cs.rst
client/cs.c | 109 ++++++-------------------------------
client/cs.h | 2 +-
doc/bluetoothctl-cs.rst | 18 ++++++
profiles/ranging/rap.c | 1 +
profiles/ranging/rap_hci.c | 42 ++++++++------
src/shared/cs-types.h | 1 +
6 files changed, 64 insertions(+), 109 deletions(-)
--
^ permalink raw reply
* RE: ranging: Reactive RAS UUID
From: bluez.test.bot @ 2026-07-17 13:33 UTC (permalink / raw)
To: linux-bluetooth, naga.akella
In-Reply-To: <20260717124111.3296537-2-naga.akella@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 987 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1129585
---Test result---
Test Summary:
CheckPatch PASS 0.75 seconds
GitLint PASS 0.48 seconds
BuildEll PASS 18.79 seconds
BluezMake PASS 586.07 seconds
MakeCheck PASS 0.92 seconds
MakeDistcheck PASS 145.94 seconds
CheckValgrind PASS 138.86 seconds
CheckSmatch PASS 249.89 seconds
bluezmakeextell PASS 90.15 seconds
IncrementalBuild PASS 675.63 seconds
ScanBuild PASS 812.25 seconds
https://github.com/bluez/bluez/pull/2328
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez] 05f685: rap: Add RAS attribute access notification API
From: Bhavani @ 2026-07-17 12:47 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1129585
Home: https://github.com/bluez/bluez
Commit: 05f6854f1088379cad49e051c9f085dbec18d0a4
https://github.com/bluez/bluez/commit/05f6854f1088379cad49e051c9f085dbec18d0a4
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-07-17 (Fri, 17 Jul 2026)
Changed paths:
M src/shared/rap.c
M src/shared/rap.h
Log Message:
-----------
rap: Add RAS attribute access notification API
Add a callback registration mechanism to notify bt_rap consumers
when a remote peer accesses or discovers a RAS GATT attribute.
Introduce register/unregister APIs and invoke callbacks asynchronously
from all relevant RAS characteristic read/write handlers,
following the existing bt_rap_register() pattern to avoid
reentrancy into device/profile/D-Bus logic.
Commit: b519f6ee42bb1bea70662d091c20c44c186318aa
https://github.com/bluez/bluez/commit/b519f6ee42bb1bea70662d091c20c44c186318aa
Author: Naga Bhavani Akella <naga.akella@oss.qualcomm.com>
Date: 2026-07-17 (Fri, 17 Jul 2026)
Changed paths:
M profiles/ranging/rap.c
Log Message:
-----------
profiles: Register RAS UUID reactively instead of probing
Replace the unconditional reflector-role GATT_UUID probe in
gatt_client_init() with a reactive registration driven by actual
remote RAS access, using the notification API added in shared/rap.
Compare: https://github.com/bluez/bluez/compare/05f6854f1088%5E...b519f6ee42bb
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH BlueZ v3 2/4] src: Register GATT profiles for Channel Sounding reflector
From: Naga Bhavani Akella @ 2026-07-17 12:42 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: linux-bluetooth, quic_mohamull, quic_hbandi, quic_anubhavg
In-Reply-To: <CABBYNZJF7ucGh-CLT0YVkgZkU-bVzY_t2-D9Luvodx4dpzDEug@mail.gmail.com>
Hi Luiz,
Thanks for the comment
On 7/16/2026 9:45 PM, Luiz Augusto von Dentz wrote:
> Hi Naga,
>
> On Sun, Jul 12, 2026 at 8:18 AM Naga Bhavani Akella
> <naga.akella@oss.qualcomm.com> wrote:
>>
>> Probe and accept GATT_UUID profiles on non-initiator (reflector)
>> devices before gatt_client discovery checks,
>> ensuring RAP's org.bluez.ChannelSounding1 DBus interface is registered
>> even when GATT client discovery is skipped.
>
> This is not how it should be done, what you do is to detect that if
> the remote side discover/read any of RAS attributes then you add its
> UUID via btd_device_add_uuid.
Addressed the comment in patch set v4>
>> ---
>> src/device.c | 28 +++++++++++++++++++++-------
>> 1 file changed, 21 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/device.c b/src/device.c
>> index 65d84be56..cedfe3a20 100644
>> --- a/src/device.c
>> +++ b/src/device.c
>> @@ -6301,17 +6301,31 @@ static void gatt_debug(const char *str, void *user_data)
>> static void gatt_client_init(struct btd_device *device)
>> {
>> uint8_t features;
>> + GSList *uuid_list;
>>
>> gatt_client_cleanup(device);
>>
>> - if (!btd_device_is_initiator(device) && !btd_opts.reverse_discovery) {
>> - DBG("Reverse service discovery disabled: skipping GATT client");
>> - return;
>> - }
>> + if (!btd_device_is_initiator(device)) {
>> + /*
>> + * For the reflector role GATT client discovery is skipped, but
>> + * profiles that match GATT_UUID still need to be probed and
>> + * accepted so they can register their D-Bus interfaces (e.g.
>> + * org.bluez.ChannelSounding1).
>> + */
>> + uuid_list = g_slist_append(NULL, (char *)GATT_UUID);
>> + device_probe_profiles(device, uuid_list);
>> + g_slist_free(uuid_list);
>> + device_accept_gatt_profiles(device);
>>
>> - if (!btd_device_is_initiator(device) && !btd_opts.gatt_client) {
>> - DBG("GATT client disabled: skipping GATT client");
>> - return;
>> + if (!btd_opts.reverse_discovery) {
>> + DBG("Reverse srvc disc disabled: skip GATT client");
>> + return;
>> + }
>> +
>> + if (!btd_opts.gatt_client) {
>> + DBG("GATT client disabled: skipping GATT client");
>> + return;
>> + }
>> }
>>
>> features = BT_GATT_CHRC_CLI_FEAT_ROBUST_CACHING
>> --
>>
>
>
^ permalink raw reply
* Re: [PATCH v4 08/11] Bluetooth: hci_qca: Support QCA2066 on M.2 connector via pwrseq
From: Bartosz Golaszewski @ 2026-07-17 12:41 UTC (permalink / raw)
To: Loic Poulain
Cc: Bartosz Golaszewski, linux-pci, linux-pm, linux-kernel,
linux-arm-msm, linux-bluetooth, devicetree, Manivannan Sadhasivam,
Manivannan Sadhasivam, Marcel Holtmann, Luiz Augusto von Dentz,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <CAFEp6-0HnYOboVWc3GUG5qMN_phP4ryJp=T=LgZs2ujyX1isMg@mail.gmail.com>
On Fri, 17 Jul 2026 14:32:27 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> Hi Bartosz,
>
> On Fri, Jul 17, 2026 at 11:35 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>>
>> On Thu, 16 Jul 2026 18:18:25 +0200, Loic Poulain
>> <loic.poulain@oss.qualcomm.com> said:
>> > For QCA2066 (and other QCA chips) on M.2 connectors, the UART enable is
>> > controlled by the W_DISABLE2# signal managed by the pcie-m2 power sequencer
>> > rather than a dedicated BT enable GPIO.
>> >
>> > When the serdev controller has an OF graph (indicating it is connected to
>> > an M.2 connector), acquire the 'uart' pwrseq target from the connector's
>> > power sequencer and use it to control BT power instead of the bt-enable
>> > GPIO. This is factored out into qca_serdev_get_m2_pwrseq().
>> >
>> > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
>> > Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
>> > ---
>> > drivers/bluetooth/hci_qca.c | 41 +++++++++++++++++++++++++++++++----------
>> > 1 file changed, 31 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> > index 25c4387136245fca25e375951f960d7240116781..22f6185a946ef04c45e41b2b34126e3f58d603ca 100644
>> > --- a/drivers/bluetooth/hci_qca.c
>> > +++ b/drivers/bluetooth/hci_qca.c
>> > @@ -1872,6 +1872,9 @@ static int qca_power_on(struct hci_dev *hdev)
>> > /* Controller needs time to bootup. */
>> > msleep(150);
>> > }
>> > +
>> > + if (qcadev->bt_power.pwrseq)
>> > + pwrseq_power_on(qcadev->bt_power.pwrseq);
>> > }
>> >
>> > clear_bit(QCA_BT_OFF, &qca->flags);
>> > @@ -2387,6 +2390,28 @@ static int qca_init_regulators(struct qca_power *qca,
>> > return 0;
>> > }
>> >
>> > +static void qca_serdev_put_pwrseq(void *data)
>> > +{
>> > + pwrseq_put(data);
>> > +}
>> > +
>> > +static int qca_serdev_get_m2_pwrseq(struct qca_serdev *qcadev)
>> > +{
>> > + struct serdev_device *serdev = qcadev->serdev_hu.serdev;
>> > + struct pwrseq_desc *pwrseq;
>> > +
>> > + if (!of_graph_is_present(dev_of_node(&serdev->ctrl->dev)))
>> > + return 0;
>> > +
>> > + pwrseq = pwrseq_get(&serdev->ctrl->dev, "uart");
>>
>> There's devm_pwrseq_get() you can use instead of scheduling your own action.
>
> The reason is discussed here:
> https://lore.kernel.org/all/20260716083141.GA4101439@google.com/
>
> We want the lifetime of the pwrseq descriptor to be tied to the serdev
> consumer device rather than the underlying serdev controller.
> Maybe a short comment explaining this relationship would be helpful.
>
Ah, subtle. Yeah a comment would be helpful.
Bart
^ permalink raw reply
* [PATCH BlueZ v4 2/2] profiles: Register RAS UUID reactively instead of probing
From: Naga Bhavani Akella @ 2026-07-17 12:41 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
In-Reply-To: <20260717124111.3296537-1-naga.akella@oss.qualcomm.com>
Replace the unconditional reflector-role GATT_UUID probe in
gatt_client_init() with a reactive registration driven by actual
remote RAS access, using the notification API added in shared/rap.
---
profiles/ranging/rap.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/profiles/ranging/rap.c b/profiles/ranging/rap.c
index 3ffc0da76..4f6d7f2db 100644
--- a/profiles/ranging/rap.c
+++ b/profiles/ranging/rap.c
@@ -308,6 +308,27 @@ static void rap_attached(struct bt_rap *rap, void *user_data)
rap_data_add(data);
}
+static void rap_ras_accessed(struct bt_att *att, void *user_data)
+{
+ struct btd_device *device;
+ struct btd_service *service;
+
+ device = btd_adapter_find_device_by_fd(bt_att_get_fd(att));
+ if (!device) {
+ error("unable to find device for RAS access");
+ return;
+ }
+
+ service = btd_device_get_service(device, GATT_UUID);
+ if (!service) {
+ btd_device_add_uuid(device, GATT_UUID);
+ service = btd_device_get_service(device, GATT_UUID);
+ }
+
+ if (service)
+ service_accept(service, btd_device_is_initiator(device));
+}
+
enum cs_dict_target {
CS_TARGET_SETTINGS,
CS_TARGET_CFG,
@@ -830,6 +851,7 @@ static struct btd_profile rap_profile = {
};
static unsigned int rap_id;
+static unsigned int rap_ras_accessed_id;
static int rap_init(void)
{
@@ -840,6 +862,8 @@ static int rap_init(void)
return err;
rap_id = bt_rap_register(rap_attached, rap_detached, NULL);
+ rap_ras_accessed_id = bt_rap_ras_accessed_register(rap_ras_accessed,
+ NULL);
return 0;
}
@@ -848,6 +872,7 @@ static void rap_exit(void)
{
btd_profile_unregister(&rap_profile);
bt_rap_unregister(rap_id);
+ bt_rap_ras_accessed_unregister(rap_ras_accessed_id);
}
BLUETOOTH_PLUGIN_DEFINE(rap, VERSION, BLUETOOTH_PLUGIN_PRIORITY_DEFAULT,
--
^ permalink raw reply related
* [PATCH BlueZ v4 1/2] rap: Add RAS attribute access notification API
From: Naga Bhavani Akella @ 2026-07-17 12:41 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
In-Reply-To: <20260717124111.3296537-1-naga.akella@oss.qualcomm.com>
Add a callback registration mechanism to notify bt_rap consumers
when a remote peer accesses or discovers a RAS GATT attribute.
Introduce register/unregister APIs and invoke callbacks asynchronously
from all relevant RAS characteristic read/write handlers,
following the existing bt_rap_register() pattern to avoid
reentrancy into device/profile/D-Bus logic.
---
src/shared/rap.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++
src/shared/rap.h | 6 +++
2 files changed, 104 insertions(+)
diff --git a/src/shared/rap.c b/src/shared/rap.c
index dfb272d3a..567abdb75 100644
--- a/src/shared/rap.c
+++ b/src/shared/rap.c
@@ -306,6 +306,7 @@ struct bt_rap {
static struct queue *rap_db;
static struct queue *bt_rap_cbs;
+static struct queue *bt_rap_accessed_cbs;
static struct queue *sessions;
struct bt_rap_cb {
@@ -315,6 +316,12 @@ struct bt_rap_cb {
void *user_data;
};
+struct bt_rap_accessed_cb {
+ unsigned int id;
+ bt_rap_accessed_func_t func;
+ void *user_data;
+};
+
struct bt_rap_ready {
unsigned int id;
bt_rap_ready_func_t func;
@@ -724,6 +731,42 @@ static void cs_tracker_init(struct cstracker *t)
t->segment_data.iov_len = 0;
}
+static bool notify_ras_accessed_idle(void *user_data)
+{
+ struct bt_att *att = user_data;
+ const struct queue_entry *entry;
+
+ for (entry = queue_get_entries(bt_rap_accessed_cbs); entry;
+ entry = entry->next) {
+ struct bt_rap_accessed_cb *cb = entry->data;
+
+ cb->func(att, cb->user_data);
+ }
+
+ return false;
+}
+
+static void notify_ras_accessed_destroy(void *user_data)
+{
+ struct bt_att *att = user_data;
+
+ bt_att_unref(att);
+}
+
+/*
+ * Notify that the remote side has discovered/accessed a RAS attribute.
+ * Deferred to idle so it does not reenter device/profile logic from within
+ * the gatt-server's request-dispatch stack.
+ */
+static void notify_ras_accessed(struct bt_att *att)
+{
+ if (!att || !bt_rap_accessed_cbs || queue_isempty(bt_rap_accessed_cbs))
+ return;
+
+ timeout_add(0, notify_ras_accessed_idle, bt_att_ref(att),
+ notify_ras_accessed_destroy);
+}
+
static void ras_features_read_cb(struct gatt_db_attribute *attrib,
unsigned int id, uint16_t offset,
uint8_t opcode, struct bt_att *att,
@@ -737,6 +780,8 @@ static void ras_features_read_cb(struct gatt_db_attribute *attrib,
*/
uint8_t value[4] = { 0x01, 0x00, 0x00, 0x00 };
+ notify_ras_accessed(att);
+
gatt_db_attribute_read_result(attrib, id, 0, value, sizeof(value));
}
@@ -745,6 +790,8 @@ static void ras_ondemand_read_cb(struct gatt_db_attribute *attrib,
uint8_t opcode, struct bt_att *att,
void *user_data)
{
+ notify_ras_accessed(att);
+
/* No static read data – on‑demand data is pushed via
* notifications
*/
@@ -761,6 +808,8 @@ static void ras_control_point_write_cb(struct gatt_db_attribute *attrib,
uint8_t opcode, struct bt_att *att,
void *user_data)
{
+ notify_ras_accessed(att);
+
/* Control point handler - implementation TBD */
}
@@ -773,6 +822,8 @@ static void ras_data_ready_read_cb(struct gatt_db_attribute *attrib,
uint16_t counter = 0;
uint8_t value[2];
+ notify_ras_accessed(att);
+
put_le16(counter, value);
gatt_db_attribute_read_result(attrib, id, 0, value, sizeof(value));
}
@@ -785,6 +836,8 @@ static void ras_data_overwritten_read_cb(struct gatt_db_attribute *attrib,
{
uint8_t value[2] = { 0x00, 0x00 };
+ notify_ras_accessed(att);
+
gatt_db_attribute_read_result(attrib, id, 0, value, sizeof(value));
}
@@ -800,6 +853,7 @@ static void ras_ranging_data_ccc_write_cb(struct gatt_db_attribute *attrib,
uint16_t *this_ccc;
uint16_t *other_ccc;
+ notify_ras_accessed(att);
if (!ras) {
gatt_db_attribute_write_result(attrib, id,
BT_ATT_ERROR_UNLIKELY);
@@ -1052,6 +1106,50 @@ bool bt_rap_unregister(unsigned int id)
return true;
}
+unsigned int bt_rap_ras_accessed_register(bt_rap_accessed_func_t func,
+ void *user_data)
+{
+ struct bt_rap_accessed_cb *cb;
+ static unsigned int id;
+
+ if (!func)
+ return 0;
+
+ if (!bt_rap_accessed_cbs)
+ bt_rap_accessed_cbs = queue_new();
+
+ cb = new0(struct bt_rap_accessed_cb, 1);
+ cb->id = ++id ? id : ++id;
+ cb->func = func;
+ cb->user_data = user_data;
+
+ queue_push_tail(bt_rap_accessed_cbs, cb);
+
+ return cb->id;
+}
+
+static bool match_accessed_id(const void *data, const void *match_data)
+{
+ const struct bt_rap_accessed_cb *cb = data;
+ unsigned int id = PTR_TO_UINT(match_data);
+
+ return cb->id == id;
+}
+
+bool bt_rap_ras_accessed_unregister(unsigned int id)
+{
+ struct bt_rap_accessed_cb *cb;
+
+ cb = queue_remove_if(bt_rap_accessed_cbs, match_accessed_id,
+ UINT_TO_PTR(id));
+ if (!cb)
+ return false;
+
+ free(cb);
+
+ return true;
+}
+
static inline size_t serialize_segmentation_header(
const struct segmentation_header *s,
uint8_t *out, size_t out_len)
diff --git a/src/shared/rap.h b/src/shared/rap.h
index 5582635e6..a78e9a5c6 100644
--- a/src/shared/rap.h
+++ b/src/shared/rap.h
@@ -15,6 +15,7 @@
struct bt_rap;
struct gatt_db;
struct bt_gatt_client;
+struct bt_att;
/* Channel Sounding Events */
struct bt_rap_hci_cs_options {
@@ -161,6 +162,7 @@ typedef void (*bt_rap_debug_func_t)(const char *str, void *user_data);
typedef void (*bt_rap_ready_func_t)(struct bt_rap *rap, void *user_data);
typedef void (*bt_rap_destroy_func_t)(void *user_data);
typedef void (*bt_rap_func_t)(struct bt_rap *rap, void *user_data);
+typedef void (*bt_rap_accessed_func_t)(struct bt_att *att, void *user_data);
struct bt_rap *bt_rap_ref(struct bt_rap *rap);
void bt_rap_unref(struct bt_rap *rap);
@@ -187,6 +189,10 @@ bool bt_rap_ready_unregister(struct bt_rap *rap, unsigned int id);
bool bt_rap_unregister(unsigned int id);
+unsigned int bt_rap_ras_accessed_register(bt_rap_accessed_func_t func,
+ void *user_data);
+bool bt_rap_ras_accessed_unregister(unsigned int id);
+
struct bt_rap *bt_rap_new(struct gatt_db *ldb, struct gatt_db *rdb);
bool bt_rap_set_cs_config_params(void *hci_sm,
--
^ permalink raw reply related
* [PATCH BlueZ v4 0/2] ranging: Reactive RAS UUID
From: Naga Bhavani Akella @ 2026-07-17 12:41 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg,
Naga Bhavani Akella
This series replaces the probe with a reactive mechanism.
GATT_UUID is only added and the RAP profile only probed
/accepted once the remote peer actually discovers or accesses
a RAS GATT attribute (Features, Ondemand Data,
Control Point, Data Ready, Data Overwritten, or subscribes via the
Ranging Data CCC).
Patch 1 adds a generic RAS-access notification callback API to
shared/rap.
Patch 2 consumes that API in profiles/ranging/rap.c to bridge the
notification to btd_device_add_uuid()/service_accept(), and reverts
the probe in gatt_client_init()
Naga Bhavani Akella (2):
rap: Add RAS attribute access notification API
profiles: Register RAS UUID reactively instead of probing
profiles/ranging/rap.c | 25 +++++++++++
src/shared/rap.c | 98 ++++++++++++++++++++++++++++++++++++++++++
src/shared/rap.h | 6 +++
3 files changed, 129 insertions(+)
--
^ permalink raw reply
* Re: [PATCH v4 08/11] Bluetooth: hci_qca: Support QCA2066 on M.2 connector via pwrseq
From: Loic Poulain @ 2026-07-17 12:32 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Manivannan Sadhasivam, Manivannan Sadhasivam,
Marcel Holtmann, Luiz Augusto von Dentz, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <CAMRc=Mc3gt_uruVmUmqsOsvKX=52V4TBVC0hbo69KgjEGhch3A@mail.gmail.com>
Hi Bartosz,
On Fri, Jul 17, 2026 at 11:35 AM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Thu, 16 Jul 2026 18:18:25 +0200, Loic Poulain
> <loic.poulain@oss.qualcomm.com> said:
> > For QCA2066 (and other QCA chips) on M.2 connectors, the UART enable is
> > controlled by the W_DISABLE2# signal managed by the pcie-m2 power sequencer
> > rather than a dedicated BT enable GPIO.
> >
> > When the serdev controller has an OF graph (indicating it is connected to
> > an M.2 connector), acquire the 'uart' pwrseq target from the connector's
> > power sequencer and use it to control BT power instead of the bt-enable
> > GPIO. This is factored out into qca_serdev_get_m2_pwrseq().
> >
> > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> > Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> > ---
> > drivers/bluetooth/hci_qca.c | 41 +++++++++++++++++++++++++++++++----------
> > 1 file changed, 31 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index 25c4387136245fca25e375951f960d7240116781..22f6185a946ef04c45e41b2b34126e3f58d603ca 100644
> > --- a/drivers/bluetooth/hci_qca.c
> > +++ b/drivers/bluetooth/hci_qca.c
> > @@ -1872,6 +1872,9 @@ static int qca_power_on(struct hci_dev *hdev)
> > /* Controller needs time to bootup. */
> > msleep(150);
> > }
> > +
> > + if (qcadev->bt_power.pwrseq)
> > + pwrseq_power_on(qcadev->bt_power.pwrseq);
> > }
> >
> > clear_bit(QCA_BT_OFF, &qca->flags);
> > @@ -2387,6 +2390,28 @@ static int qca_init_regulators(struct qca_power *qca,
> > return 0;
> > }
> >
> > +static void qca_serdev_put_pwrseq(void *data)
> > +{
> > + pwrseq_put(data);
> > +}
> > +
> > +static int qca_serdev_get_m2_pwrseq(struct qca_serdev *qcadev)
> > +{
> > + struct serdev_device *serdev = qcadev->serdev_hu.serdev;
> > + struct pwrseq_desc *pwrseq;
> > +
> > + if (!of_graph_is_present(dev_of_node(&serdev->ctrl->dev)))
> > + return 0;
> > +
> > + pwrseq = pwrseq_get(&serdev->ctrl->dev, "uart");
>
> There's devm_pwrseq_get() you can use instead of scheduling your own action.
The reason is discussed here:
https://lore.kernel.org/all/20260716083141.GA4101439@google.com/
We want the lifetime of the pwrseq descriptor to be tied to the serdev
consumer device rather than the underlying serdev controller.
Maybe a short comment explaining this relationship would be helpful.
Regards,
Loic
>
> > + if (IS_ERR(pwrseq))
> > + return PTR_ERR(pwrseq);
> > +
> > + qcadev->bt_power.pwrseq = pwrseq;
> > +
> > + return devm_add_action_or_reset(&serdev->dev, qca_serdev_put_pwrseq, pwrseq);
> > +}
> > +
> > static int qca_serdev_probe(struct serdev_device *serdev)
> > {
> > struct qca_serdev *qcadev;
> > @@ -2417,6 +2442,10 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> > else
> > qcadev->btsoc_type = QCA_ROME;
> >
> > + err = qca_serdev_get_m2_pwrseq(qcadev);
> > + if (err)
> > + return err;
> > +
> > switch (qcadev->btsoc_type) {
> > case QCA_WCN3950:
> > case QCA_WCN3988:
> > @@ -2426,17 +2455,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> > case QCA_WCN6750:
> > case QCA_WCN6855:
> > case QCA_WCN7850:
> > - /*
> > - * OF graph link is only present for BT devices attached through
> > - * the M.2 Key E connector.
> > - */
> > - if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
> > - qcadev->bt_power.pwrseq = devm_pwrseq_get(&serdev->ctrl->dev,
> > - "uart");
> > - if (IS_ERR(qcadev->bt_power.pwrseq))
> > - return PTR_ERR(qcadev->bt_power.pwrseq);
> > + /* M.2 connector modules are powered by the pwrseq acquired above. */
> > + if (qcadev->bt_power.pwrseq)
> > break;
> > - }
> >
> > if (!device_property_present(&serdev->dev, "enable-gpios")) {
> > /*
> >
> > --
> > 2.34.1
> >
> >
>
> Bart
^ permalink raw reply
* [Bug 221754] RTL8852BE Bluetooth (0bda:b853) fails to init: Opcode 0xfcf0 failed: -16, hci0 never registers with mgmt (BD Address 00:00:00:00:00:00)
From: bugzilla-daemon @ 2026-07-17 11:07 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221754-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221754
Adam (dohojda.adam@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dohojda.adam@gmail.com
--- Comment #2 from Adam (dohojda.adam@gmail.com) ---
I have very same problem on Lenovo IdeaPad Slim 5 14AHP11
Disribution & kernel: Ubuntu 26.04 LTS, kernel 7.0.0-27-generic
lsusb: 0bda:b853 Realtek Semiconductor Corp. Bluetooth Radio
My filtered dmseg trace:
```
[ 3.426562] systemd[1]: systemd-hibernate-clear.service - Clear Stale
Hibernate Storage Info skipped, unmet condition check
ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67
[ 4.034621] amdxdna 0000:05:00.1: [drm] Load firmware
amdnpu/1502_00/npu_7.sbin
[ 4.058678] kvm_amd: [Firmware Bug]: Cannot enable x2AVIC, AVIC is
unsupported
[ 4.081452] rtw89_8852be 0000:02:00.0: loaded firmware
rtw89/rtw8852b_fw-1.bin
[ 4.089206] rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.15
(6fb3ec41), cmd version 0, type 5
[ 4.089213] rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.15
(6fb3ec41), cmd version 0, type 3
[ 5.716983] amdgpu 0000:04:00.0: [drm] Loading DMUB firmware via PSP:
version=0x08005700
[ 5.717220] amdgpu 0000:04:00.0: [VCN instance 0] Found VCN firmware Version
ENC: 1.24 DEC: 9 VEP: 0 Revision: 16
[ 5.750181] Bluetooth: hci0: RTL: examining hci_ver=0b hci_rev=000b
lmp_ver=0b lmp_subver=8852
[ 5.753172] Bluetooth: hci0: RTL: rom_version status=0 version=3
[ 5.756172] Bluetooth: hci0: RTL: btrtl_initialize: key id 0
[ 5.756176] Bluetooth: hci0: RTL: loading rtl_bt/rtl8852bu_fw.bin
[ 5.757225] Bluetooth: hci0: RTL: loading rtl_bt/rtl8852bu_config.bin
[ 5.766164] Bluetooth: hci0: AOSP extensions version v0.96
[ 5.766168] Bluetooth: hci0: AOSP quality report is not supported
[ 131.458300] Bluetooth: hci0: RTL: examining hci_ver=0b hci_rev=000b
lmp_ver=0b lmp_subver=8852
[ 131.461055] Bluetooth: hci0: RTL: rom_version status=0 version=3
[ 131.464314] Bluetooth: hci0: RTL: btrtl_initialize: key id 0
[ 131.464331] Bluetooth: hci0: RTL: loading rtl_bt/rtl8852bu_fw.bin
[ 131.465152] Bluetooth: hci0: RTL: loading rtl_bt/rtl8852bu_config.bin
[ 131.470914] Bluetooth: hci0: Opcode 0xfcf0 failed: -16
[ 131.475291] Bluetooth: hci0: AOSP extensions version v0.96
[ 131.475307] Bluetooth: hci0: AOSP quality report is not supported
```
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* RE: [BlueZ,v2] adapter: Infer BR/EDR only at public LE addresses
From: bluez.test.bot @ 2026-07-17 10:53 UTC (permalink / raw)
To: linux-bluetooth, pip
In-Reply-To: <20260717082347.8429-1-pip@pipobscure.com>
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1129413
---Test result---
Test Summary:
CheckPatch PASS 0.39 seconds
GitLint PASS 0.28 seconds
BuildEll PASS 20.18 seconds
BluezMake PASS 517.38 seconds
CheckSmatch PASS 295.30 seconds
bluezmakeextell PASS 95.13 seconds
IncrementalBuild PASS 484.94 seconds
ScanBuild PASS 870.81 seconds
https://github.com/bluez/bluez/pull/2326
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: Bluetooth: btmtk: Add MT7928 support
From: bluez.test.bot @ 2026-07-17 10:44 UTC (permalink / raw)
To: linux-bluetooth, chris.lu
In-Reply-To: <20260717083936.2923891-2-chris.lu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 3666 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1129429
---Test result---
Test Summary:
CheckPatch FAIL 4.29 seconds
VerifyFixes PASS 0.07 seconds
VerifySignedoff PASS 0.07 seconds
GitLint FAIL 1.45 seconds
SubjectPrefix PASS 0.44 seconds
BuildKernel PASS 27.05 seconds
CheckAllWarning PASS 30.15 seconds
CheckSparse PASS 28.77 seconds
BuildKernel32 PASS 26.82 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 502.67 seconds
IncrementalBuild PASS 38.23 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v16,1/7] Bluetooth: btmtksdio: Fix SKB handling issues in TX path
WARNING: Reported-by: should be immediately followed by Closes: with a URL to the report
#111:
Reported-by: Sashiko <sashiko-review@kernel.org>
Signed-off-by: Chris Lu <chris.lu@mediatek.com>
total: 0 errors, 1 warnings, 103 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14693204.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[v16,2/7] Bluetooth: btmtk: Add firmware size validation in btmtk_setup_firmware_79xx()
1: T1 Title exceeds max length (87>80): "[v16,2/7] Bluetooth: btmtk: Add firmware size validation in btmtk_setup_firmware_79xx()"
[v16,5/7] Bluetooth: btmtk: Improve BT firmware logging
14: B1 Line exceeds max length (92>80): "[ 212.878783] Bluetooth: hci1: Loading BT firmware: mediatek/BT_RAM_CODE_MT7922_1_1_hdr.bin"
15: B1 Line exceeds max length (93>80): "[ 212.889614] Bluetooth: hci1: BT HW ver: 0x7922, SW ver: 0x008a, Build Time: 20260224103448"
17: B1 Line exceeds max length (115>80): "[ 216.048890] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported."
[v16,7/7] Bluetooth: btmtk: Add MT7928 support
28: B1 Line exceeds max length (92>80): "[ 6931.197167] usb 1-3: New USB device found, idVendor=0e8d, idProduct=7935, bcdDevice= 1.00"
33: B1 Line exceeds max length (97>80): "[ 6931.213478] Bluetooth: hci1: Loading CBMCU firmware: mediatek/mt7928/CBMCU_CODE_MT7935_1_1.bin"
34: B1 Line exceeds max length (98>80): "[ 6931.215214] Bluetooth: hci1: CBMCU HW ver: 0x7935, SW ver: 0x0000, Build Time: 20260601T161751+"
36: B1 Line exceeds max length (99>80): "[ 6931.643916] Bluetooth: hci1: Loading BT firmware: mediatek/mt7928/BT_RAM_CODE_MT7935_1_1_hdr.bin"
37: B1 Line exceeds max length (93>80): "[ 6931.650467] Bluetooth: hci1: BT HW ver: 0x7935, SW ver: 0x0000, Build Time: 20260527000816"
39: B1 Line exceeds max length (115>80): "[ 6935.039833] Bluetooth: hci1: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported."
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/449
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-07-17 10:14 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1129094
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 0e25b2: adapter: Infer BR/EDR only at public LE addresses
From: Philipp Dunkel @ 2026-07-17 10:14 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1129413
Home: https://github.com/bluez/bluez
Commit: 0e25b2b3c57c5d086e3f08aae50444c9621361d2
https://github.com/bluez/bluez/commit/0e25b2b3c57c5d086e3f08aae50444c9621361d2
Author: Philipp Dunkel <pip@pipobscure.com>
Date: 2026-07-17 (Fri, 17 Jul 2026)
Changed paths:
M src/adapter.c
Log Message:
-----------
adapter: Infer BR/EDR only at public LE addresses
btd_adapter_device_found() records BR/EDR support for any LE device
whose advertising Flags lack "BR/EDR Not Supported" (EIR_BREDR_UNSUP).
The address type is not considered:
if (bdaddr_type != BDADDR_BREDR && eir_data.flags &&
!(eir_data.flags & EIR_BREDR_UNSUP)) {
device_set_bredr_support(dev);
When the advertisement uses a random address the device gets a BR/EDR
bearer whose address is that random address, and start_discovery_cb()
then prefers SDP over GATT:
if (device->bredr)
device_browse_sdp(device, NULL);
else
device_browse_gatt(device, NULL);
SDP requires a BR/EDR ACL, so bluetoothd pages the random address. A
random address is not a BD_ADDR and cannot be paged, so the attempt
always ends in Page Timeout, and the failure tears down the working LE
link:
connect_failed_callback() hci0 5A:B4:98:1F:CC:04 status 4
bonding_attempt_complete() hci0 bdaddr 5A:B4:98:1F:CC:04
type 0 status 0x4
device_bonding_complete() bonding (nil) status 0x04
browse_request_cancel()
btd_gatt_database_att_disconnected()
Nothing requested the connection ("bonding (nil)") and the LE link was
healthy. Any LE association that outlives the page timeout is killed by
it; measured on one host, applications get about 4.7 s from connect
before the link disappears, of which GATT discovery already takes 2.3 s.
Current phones advertise Flags 0x1a (LE General Discoverable plus
Simultaneous LE and BR/EDR, with BR/EDR Not Supported clear) from
resolvable private addresses, so this triggers routinely rather than in
some corner case.
The Flags bits describe what the device supports. They do not promise
that the address it is advertising from is a BD_ADDR. A dual-mode device
uses the same Public Device Address for BR/EDR and LE, so the inference
is sound only for BDADDR_LE_PUBLIC. Restrict it to that.
The other two device_set_bredr_support() callers already require the
device to have been seen over BR/EDR (bdaddr_type == BDADDR_BREDR), so
they are unaffected. A device later seen over BR/EDR, or whose RPA is
resolved to a public identity, still gets BR/EDR support recorded there.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-07-13
From: patchwork-bot+netdevbpf @ 2026-07-17 9:40 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: davem, kuba, linux-bluetooth, netdev
In-Reply-To: <20260713141940.954317-1-luiz.dentz@gmail.com>
Hello:
This pull request was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 13 Jul 2026 10:19:40 -0400 you wrote:
> The following changes since commit 3f1f755366687d051174739fb99f7d560202f60b:
>
> net: openvswitch: reject oversized nested action attrs (2026-07-11 13:09:11 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git tags/for-net-2026-07-13
>
> [...]
Here is the summary with links:
- [GIT,PULL] bluetooth 2026-07-13
https://git.kernel.org/netdev/net/c/78d24e77ffd3
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v4 11/11] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Bartosz Golaszewski @ 2026-07-17 9:35 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Manivannan Sadhasivam, Konrad Dybcio,
Dmitry Baryshkov, Manivannan Sadhasivam, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260716-monza-wireless-v4-11-9b02e6f549d7@oss.qualcomm.com>
On Thu, 16 Jul 2026 18:18:28 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> Add support for the QCA2066 (QCNFA765) WiFi/Bluetooth module on the
> Arduino VENTUNO Q board. The module is interfaced via LGA and is
> compatible with the M.2 Key E.
>
> Add wireless-lga-connector node using pcie-m2-e-connector binding,
> connecting PCIe port 0 to the WiFi interface and UART10 port 3 to
> the Bluetooth interface.
>
> Add pcie@1,0 downstream port node with pciclass,0604 compatible so
> the pci-pwrctrl driver can acquire the power sequencer and enable
> the M.2 slot before PCIe enumeration.
>
> Add nfa725b_default_state pinctrl for the W_DISABLE1/2 GPIOs
> (gpio56/gpio55) used by the power sequencer.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v4 08/11] Bluetooth: hci_qca: Support QCA2066 on M.2 connector via pwrseq
From: Bartosz Golaszewski @ 2026-07-17 9:35 UTC (permalink / raw)
To: Loic Poulain
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree, Manivannan Sadhasivam, Manivannan Sadhasivam,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260716-monza-wireless-v4-8-9b02e6f549d7@oss.qualcomm.com>
On Thu, 16 Jul 2026 18:18:25 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> For QCA2066 (and other QCA chips) on M.2 connectors, the UART enable is
> controlled by the W_DISABLE2# signal managed by the pcie-m2 power sequencer
> rather than a dedicated BT enable GPIO.
>
> When the serdev controller has an OF graph (indicating it is connected to
> an M.2 connector), acquire the 'uart' pwrseq target from the connector's
> power sequencer and use it to control BT power instead of the bt-enable
> GPIO. This is factored out into qca_serdev_get_m2_pwrseq().
>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> drivers/bluetooth/hci_qca.c | 41 +++++++++++++++++++++++++++++++----------
> 1 file changed, 31 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> index 25c4387136245fca25e375951f960d7240116781..22f6185a946ef04c45e41b2b34126e3f58d603ca 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -1872,6 +1872,9 @@ static int qca_power_on(struct hci_dev *hdev)
> /* Controller needs time to bootup. */
> msleep(150);
> }
> +
> + if (qcadev->bt_power.pwrseq)
> + pwrseq_power_on(qcadev->bt_power.pwrseq);
> }
>
> clear_bit(QCA_BT_OFF, &qca->flags);
> @@ -2387,6 +2390,28 @@ static int qca_init_regulators(struct qca_power *qca,
> return 0;
> }
>
> +static void qca_serdev_put_pwrseq(void *data)
> +{
> + pwrseq_put(data);
> +}
> +
> +static int qca_serdev_get_m2_pwrseq(struct qca_serdev *qcadev)
> +{
> + struct serdev_device *serdev = qcadev->serdev_hu.serdev;
> + struct pwrseq_desc *pwrseq;
> +
> + if (!of_graph_is_present(dev_of_node(&serdev->ctrl->dev)))
> + return 0;
> +
> + pwrseq = pwrseq_get(&serdev->ctrl->dev, "uart");
There's devm_pwrseq_get() you can use instead of scheduling your own action.
> + if (IS_ERR(pwrseq))
> + return PTR_ERR(pwrseq);
> +
> + qcadev->bt_power.pwrseq = pwrseq;
> +
> + return devm_add_action_or_reset(&serdev->dev, qca_serdev_put_pwrseq, pwrseq);
> +}
> +
> static int qca_serdev_probe(struct serdev_device *serdev)
> {
> struct qca_serdev *qcadev;
> @@ -2417,6 +2442,10 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> else
> qcadev->btsoc_type = QCA_ROME;
>
> + err = qca_serdev_get_m2_pwrseq(qcadev);
> + if (err)
> + return err;
> +
> switch (qcadev->btsoc_type) {
> case QCA_WCN3950:
> case QCA_WCN3988:
> @@ -2426,17 +2455,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> case QCA_WCN6750:
> case QCA_WCN6855:
> case QCA_WCN7850:
> - /*
> - * OF graph link is only present for BT devices attached through
> - * the M.2 Key E connector.
> - */
> - if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
> - qcadev->bt_power.pwrseq = devm_pwrseq_get(&serdev->ctrl->dev,
> - "uart");
> - if (IS_ERR(qcadev->bt_power.pwrseq))
> - return PTR_ERR(qcadev->bt_power.pwrseq);
> + /* M.2 connector modules are powered by the pwrseq acquired above. */
> + if (qcadev->bt_power.pwrseq)
> break;
> - }
>
> if (!device_property_present(&serdev->dev, "enable-gpios")) {
> /*
>
> --
> 2.34.1
>
>
Bart
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox