* [PATCH BlueZ] advertising: add property with advertisement ID
From: Michal Dzik @ 2026-05-25 4:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Michal Dzik
Identifier is an internal value, but it must be exposed to client app
if client app wants to use a advertisement in BAP broadcast
---
doc/org.bluez.LEAdvertisement.rst | 6 ++++++
src/advertising.c | 13 ++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/org.bluez.LEAdvertisement.rst b/doc/org.bluez.LEAdvertisement.rst
index aae80f08f..4dd36a0cc 100644
--- a/doc/org.bluez.LEAdvertisement.rst
+++ b/doc/org.bluez.LEAdvertisement.rst
@@ -235,3 +235,9 @@ The provided value is used only if the "CanSetTxPower" feature is enabled on the
**org.bluez.LEAdvertisingManager(5)**.
Values must be in range [-127 to +20], where units are in dBm.
+
+byte Identifier [read-write, optional]
+``````````````````````````````````````
+
+Identifier of the advertisement. Set by bluetoothd after advertisement is registered with
+**org.bluez.LEAdvertisingManager(5)**.
diff --git a/src/advertising.c b/src/advertising.c
index f529ecd14..3b758f51e 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -1511,8 +1511,19 @@ static void add_client_complete(struct btd_adv_client *client, uint8_t status)
queue_remove(client->manager->clients, client);
g_idle_add(client_free_idle_cb, client);
- } else
+ } else {
+ DBusMessageIter iter;
+
+ /* Check if the attribute has the Identifier property */
+ if (g_dbus_proxy_get_property(client->proxy, "Identifier",
+ &iter)) {
+ g_dbus_proxy_set_property_basic(client->proxy,
+ "Identifier", DBUS_TYPE_BYTE, &client->instance,
+ NULL, NULL, NULL);
+ }
+
reply = dbus_message_new_method_return(client->reg);
+ }
g_dbus_send_message(btd_get_dbus_connection(), reply);
dbus_message_unref(client->reg);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading
From: Shuai Zhang @ 2026-05-25 4:54 UTC (permalink / raw)
To: Paul Menzel
Cc: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
linux-arm-msm, linux-bluetooth, linux-kernel, cheng.jiang,
quic_chezhou, wei.deng, jinwang.li, mengshi.wu, stable
In-Reply-To: <1b8e8129-4f42-429e-bd70-5e368551739c@molgen.mpg.de>
Hi Paul
Thanks for your review and suggestions.
On 5/22/2026 10:50 PM, Paul Menzel wrote:
> Dear Shuai,
>
>
> Thank you for your patch. Please mention the delay in the
> summary/title. Maybe:
>
> Use 100 ms SSR delay for rampatch and NVM loading
>
> Am 22.05.26 um 13:08 schrieb Shuai Zhang:
>> When bt_en is pulled high by hardware, the host does not re-download
>> the firmware after SSR. The controller loads the rampatch and NVM
>> internally.
>>
>> On HMT chip, due to the large firmware file size, the
>
> Please document the size (> X MB)
On HMT chip, the rampatch size is ~264 KB and the NVM is ~9.4 KB.
I will update this information in the next version of the patch.
>
>> loading process takes approximately 70ms. The previous 50ms delay is
>> too short, causing the controller to not respond to the reset command
>> sent by the host, which leads to BT initialization failure.
>
> Maybe paste the log?
Bluetooth: hci0: QCA memdump Done, received 458752, total 458752
Bluetooth: hci0: mem_dump_status: 2
Bluetooth: hci0: Opcode 0x0c03 failed: -110
I will update this information in the next version of the patch.
>
>> Increase the delay to 100ms to ensure the controller has finished
>> loading the firmware before the host sends commands.
>
> Why can’t it be increased to 1 s?
>
>> Steps to reproduce:
>> 1. Trigger SSR and wait for SSR to complete:
>> hcitool cmd 0x3f 0c 26
>> 2. Run "bluetoothctl power on" and observe that BT fails to start.
>>
>> Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart)
>> fail when BT_EN is pulled up by hw")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
>> ---
>> drivers/bluetooth/hci_qca.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>> index ed280399b..184f52f9c 100644
>> --- a/drivers/bluetooth/hci_qca.c
>> +++ b/drivers/bluetooth/hci_qca.c
>> @@ -1680,8 +1680,8 @@ static void qca_hw_error(struct hci_dev *hdev,
>> u8 code)
>> mod_timer(&qca->tx_idle_timer, jiffies +
>> msecs_to_jiffies(qca->tx_idle_delay));
>> - /* Controller reset completion time is 50ms */
>> - msleep(50);
>> + /* Wait for the controller to load the rampatch and NVM.*/
>
> Missing space at the end.
>
>> + msleep(100);
>> clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
>> clear_bit(QCA_IBS_DISABLED, &qca->flags);
>
> Is the time it took to load the rampatch and NVM visible in the logs?
No, the loading time of the rampatch and NVM is not visible in the host
logs,
as the firmware is loaded internally by the controller.
>
>
> Kind regards,
>
> Paul
Thanks,
Shuai
^ permalink raw reply
* [bluez/bluez] c2977f: advertising: add property with advertisement ID
From: mdzik-sue @ 2026-05-25 6:03 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1100171
Home: https://github.com/bluez/bluez
Commit: c2977f7afda39ee27e97f62132352f73b9ad6a4d
https://github.com/bluez/bluez/commit/c2977f7afda39ee27e97f62132352f73b9ad6a4d
Author: Michal Dzik <michal.dzik@streamunlimited.com>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
M doc/org.bluez.LEAdvertisement.rst
M src/advertising.c
Log Message:
-----------
advertising: add property with advertisement ID
Identifier is an internal value, but it must be exposed to client app
if client app wants to use a advertisement in BAP broadcast
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading
From: Shuai Zhang @ 2026-05-25 6:49 UTC (permalink / raw)
To: Paul Menzel, Luiz Augusto von Dentz
Cc: Bartosz Golaszewski, Marcel Holtmann, linux-arm-msm,
linux-bluetooth, linux-kernel, cheng.jiang, quic_chezhou,
wei.deng, jinwang.li, mengshi.wu, stable
In-Reply-To: <55439fa7-2057-4dd7-9651-db15bd27de3a@molgen.mpg.de>
Hi Paul, Luiz
On 5/23/2026 4:42 AM, Paul Menzel wrote:
> Dear Luiz,
>
>
> Thank you for your reply.
>
> Am 22.05.26 um 18:22 schrieb Luiz Augusto von Dentz:
>
>> On Fri, May 22, 2026 at 10:50 AM Paul Menzel <pmenzel@molgen.mpg.de>
>> wrote:
>
>>> Thank you for your patch. Please mention the delay in the
>>> summary/title.
>>> Maybe:
>>>
>>> Use 100 ms SSR delay for rampatch and NVM loading
>>>
>>> Am 22.05.26 um 13:08 schrieb Shuai Zhang:
>>>> When bt_en is pulled high by hardware, the host does not re-download
>>>> the firmware after SSR. The controller loads the rampatch and NVM
>>>> internally.
>>>>
>>>> On HMT chip, due to the large firmware file size, the
>>>
>>> Please document the size (> X MB)
>>>
>>>> loading process takes approximately 70ms. The previous 50ms delay is
>>>> too short, causing the controller to not respond to the reset command
>>>> sent by the host, which leads to BT initialization failure.
>>>
>>> Maybe paste the log?
>>>
>>>> Increase the delay to 100ms to ensure the controller has finished
>>>> loading the firmware before the host sends commands.
>>>
>>> Why can’t it be increased to 1 s?
>>
>> Why would increasing it to 1s be a good idea? Actually a _proper_
>> driver should be able to detect when loading has finished, not just
>> use an arbitrary timer and hope that works and the controller is
>> responsive afterward.
>
> Indeed it’s not a fail safe in this case, and that’s what my comment
> was about, that it should be explained why 100 ms is chosen, and not a
> flexible way implemented. Sorry for not being clear.
The 100 ms value is based on actual measurement data from the controller
team. In HMT2.1 ROM,
the BT boot time (warm reset, which is the SSR recovery path) was
observed to approach 50+ ms.
The previous 50 ms delay therefore provides no margin, causing
intermittent initialization failures.
100 ms was chosen as it gives approximately 2x margin over the observed
worst-case boot time,
while keeping the SSR recovery latency reasonable for userspace.
Regarding a more flexible approach: in the current configuration where
bt_en is pulled high
and the controller self-loads the rampatch/NVM, no HCI event is
generated by the controller
to indicate firmware load completion.
Without such a notification mechanism, a fixed delay is the only viable
option at this level.
>
>>>> Steps to reproduce:
>>>> 1. Trigger SSR and wait for SSR to complete:
>>>> hcitool cmd 0x3f 0c 26
>>>> 2. Run "bluetoothctl power on" and observe that BT fails to start.
>>>>
>>>> Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem
>>>> Restart) fail when BT_EN is pulled up by hw")
>>>> Cc: stable@vger.kernel.org
>>>> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
>>>> ---
>>>> drivers/bluetooth/hci_qca.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
>>>> index ed280399b..184f52f9c 100644
>>>> --- a/drivers/bluetooth/hci_qca.c
>>>> +++ b/drivers/bluetooth/hci_qca.c
>>>> @@ -1680,8 +1680,8 @@ static void qca_hw_error(struct hci_dev
>>>> *hdev, u8 code)
>>>> mod_timer(&qca->tx_idle_timer, jiffies +
>>>> msecs_to_jiffies(qca->tx_idle_delay));
>>>>
>>>> - /* Controller reset completion time is 50ms */
>>>> - msleep(50);
>>>> + /* Wait for the controller to load the rampatch and
>>>> NVM.*/
>>>
>>> Missing space at the end.
>>>
>>>> + msleep(100);
>>>>
>>>> clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
>>>> clear_bit(QCA_IBS_DISABLED, &qca->flags);
>>>
>>> Is the time it took to load the rampatch and NVM visible in the logs?
>
>
> Kind regards,
>
> Paul
Thanks,
Shuai
^ permalink raw reply
* [PATCH BlueZ v2 0/1] Add configurable default LE PHY policy
From: Tarjei Bitustøyl @ 2026-05-25 6:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Tarjei Bitustøyl
In-Reply-To: <20260524221421.258593-1-tarjeib@gmail.com>
This adds an opt-in bluetoothd setting for the adapter's default LE PHY
policy.
v2:
- Check MGMT_SETTING_PHY_CONFIGURATION before sending PHY
configuration commands.
Tarjei Bitustøyl (1):
adapter: Add configurable default LE PHYs
src/adapter.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++++++
src/btd.h | 2 ++
src/main.c | 61 +++++++++++++++++++++++++++++++++++++++
src/main.conf | 8 ++++++
4 files changed, 150 insertions(+)
--
2.43.0
^ permalink raw reply
* [PATCH BlueZ v2 1/1] adapter: Add configurable default LE PHYs
From: Tarjei Bitustøyl @ 2026-05-25 6:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Tarjei Bitustøyl
In-Reply-To: <20260525065045.27375-1-tarjeib@gmail.com>
Some controllers mis-handle LE procedures on specific PHYs with
certain peers. On an Intel AX210-class controller, connecting to a
Frostbay BLE device can fail during early ATT/GATT setup unless the
adapter is limited to LE 1M TX/RX.
Add an opt-in [LE] DefaultPHYs setting to bluetoothd and apply it at
adapter startup using MGMT_OP_GET/SET_PHY_CONFIGURATION while
preserving non-configurable PHY bits.
This provides a generic, adapter-wide workaround for controller-
specific LE PHY interoperability problems affecting scanning and
connection establishment, without adding device-specific quirks.
v2:
- Check MGMT_SETTING_PHY_CONFIGURATION before sending PHY
configuration commands.
---
src/adapter.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++++++
src/btd.h | 2 ++
src/main.c | 61 +++++++++++++++++++++++++++++++++++++++
src/main.conf | 8 ++++++
4 files changed, 150 insertions(+)
diff --git a/src/adapter.c b/src/adapter.c
index 20f7c3e03..46df362c5 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -4972,6 +4972,84 @@ done:
mgmt_tlv_list_free(list);
}
+static void set_default_le_phys_complete(uint8_t status, uint16_t length,
+ const void *param, void *user_data)
+{
+ struct btd_adapter *adapter = user_data;
+
+ if (status != MGMT_STATUS_SUCCESS)
+ btd_error(adapter->dev_id,
+ "Failed to set default LE PHYs for hci%u: %s (0x%02x)",
+ adapter->dev_id, mgmt_errstr(status), status);
+}
+
+static void get_default_le_phys_complete(uint8_t status, uint16_t length,
+ const void *param, void *user_data)
+{
+ struct btd_adapter *adapter = user_data;
+ const struct mgmt_rp_get_phy_confguration *rp = param;
+ struct mgmt_cp_set_phy_confguration cp;
+ uint32_t configurable_phys;
+ uint32_t selected_phys;
+ uint32_t next_phys;
+
+ if (status != MGMT_STATUS_SUCCESS) {
+ btd_error(adapter->dev_id,
+ "Failed to read PHY configuration for hci%u: %s (0x%02x)",
+ adapter->dev_id, mgmt_errstr(status), status);
+ return;
+ }
+
+ if (length < sizeof(*rp)) {
+ btd_error(adapter->dev_id,
+ "Too small get PHY configuration response for hci%u",
+ adapter->dev_id);
+ return;
+ }
+
+ configurable_phys = btohl(rp->configurable_phys);
+ selected_phys = btohl(rp->selected_phys);
+
+ configurable_phys &= MGMT_PHY_LE_TX_MASK | MGMT_PHY_LE_RX_MASK;
+ next_phys = selected_phys & ~configurable_phys;
+ next_phys |= btd_opts.default_le_phys & configurable_phys;
+
+ if (next_phys == selected_phys)
+ return;
+
+ cp.selected_phys = cpu_to_le32(next_phys);
+
+ if (mgmt_send(adapter->mgmt, MGMT_OP_SET_PHY_CONFIGURATION,
+ adapter->dev_id, sizeof(cp), &cp,
+ set_default_le_phys_complete, adapter, NULL) > 0)
+ return;
+
+ btd_error(adapter->dev_id,
+ "Failed to set default LE PHYs for hci%u",
+ adapter->dev_id);
+}
+
+static void load_default_le_phys(struct btd_adapter *adapter)
+{
+ if (!btd_opts.default_le_phys_configured)
+ return;
+
+ if (!(adapter->supported_settings & MGMT_SETTING_LE))
+ return;
+
+ if (!(adapter->supported_settings & MGMT_SETTING_PHY_CONFIGURATION))
+ return;
+
+ if (mgmt_send(adapter->mgmt, MGMT_OP_GET_PHY_CONFIGURATION,
+ adapter->dev_id, 0, NULL,
+ get_default_le_phys_complete, adapter, NULL) > 0)
+ return;
+
+ btd_error(adapter->dev_id,
+ "Failed to read PHY configuration for hci%u",
+ adapter->dev_id);
+}
+
static void load_devices(struct btd_adapter *adapter)
{
char dirname[PATH_MAX];
@@ -9455,6 +9533,7 @@ load:
btd_profile_foreach(probe_profile, adapter);
clear_blocked(adapter);
load_defaults(adapter);
+ load_default_le_phys(adapter);
load_devices(adapter);
/* restore Service Changed CCC value for bonded devices */
diff --git a/src/btd.h b/src/btd.h
index db2e81239..59f44dc8c 100644
--- a/src/btd.h
+++ b/src/btd.h
@@ -140,6 +140,8 @@ struct btd_opts {
bool device_privacy;
uint32_t name_request_retry_delay;
uint8_t secure_conn;
+ uint32_t default_le_phys;
+ bool default_le_phys_configured;
struct btd_defaults defaults;
diff --git a/src/main.c b/src/main.c
index 8aa19a3e3..97c64845b 100644
--- a/src/main.c
+++ b/src/main.c
@@ -32,6 +32,7 @@
#include <dbus/dbus.h>
#include "bluetooth/bluetooth.h"
+#include "bluetooth/mgmt.h"
#include "bluetooth/sdp.h"
#include "gdbus/gdbus.h"
@@ -132,6 +133,7 @@ static const char *le_options[] = {
"Autoconnecttimeout",
"AdvMonAllowlistScanDuration",
"AdvMonNoFilterScanDuration",
+ "DefaultPHYs",
"EnableAdvMonInterleaveScan",
NULL
};
@@ -145,6 +147,8 @@ static const char *policy_options[] = {
NULL
};
+static void parse_default_le_phys(GKeyFile *config);
+
static const char *gatt_options[] = {
"Cache",
"KeySize",
@@ -751,6 +755,7 @@ static void parse_le_config(GKeyFile *config)
return;
parse_mode_config(config, "LE", params, ARRAY_SIZE(params));
+ parse_default_le_phys(config);
}
static bool match_experimental(const void *data, const void *match_data)
@@ -966,6 +971,62 @@ static void parse_repairing(GKeyFile *config)
g_free(str);
}
+struct phy_config_entry {
+ const char *name;
+ uint32_t bit;
+};
+
+static const struct phy_config_entry le_phy_configs[] = {
+ { "LE1MTX", MGMT_PHY_LE_1M_TX },
+ { "LE1MRX", MGMT_PHY_LE_1M_RX },
+ { "LE2MTX", MGMT_PHY_LE_2M_TX },
+ { "LE2MRX", MGMT_PHY_LE_2M_RX },
+ { "LECODEDTX", MGMT_PHY_LE_CODED_TX },
+ { "LECODEDRX", MGMT_PHY_LE_CODED_RX },
+};
+
+static void parse_default_le_phys(GKeyFile *config)
+{
+ char *str = NULL;
+ char **tokens;
+ uint32_t phys = 0;
+ bool valid = false;
+ int i;
+
+ if (!parse_config_string(config, "LE", "DefaultPHYs", &str))
+ return;
+
+ tokens = g_strsplit_set(str, ", \t", -1);
+
+ for (i = 0; tokens[i]; i++) {
+ const char *token = tokens[i];
+ size_t j;
+
+ if (!token[0])
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(le_phy_configs); j++) {
+ if (strcasecmp(le_phy_configs[j].name, token) != 0)
+ continue;
+
+ phys |= le_phy_configs[j].bit;
+ valid = true;
+ break;
+ }
+
+ if (j == ARRAY_SIZE(le_phy_configs))
+ warn("Invalid DefaultPHYs token: %s", token);
+ }
+
+ if (valid) {
+ btd_opts.default_le_phys = phys;
+ btd_opts.default_le_phys_configured = true;
+ }
+
+ g_strfreev(tokens);
+ g_free(str);
+}
+
static bool parse_config_hex(GKeyFile *config, char *group,
const char *key, uint32_t *val)
{
diff --git a/src/main.conf b/src/main.conf
index 5846ef92d..ed955897e 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -247,6 +247,14 @@
# Default: 500
#AdvMonNoFilterScanDuration=
+# Configure the controller's default LE PHY policy used for scanning and
+# connection establishment. Only configurable LE PHYs are changed; mandatory
+# PHYs remain selected automatically.
+# Possible values: comma or space separated list of LE1MTX, LE1MRX, LE2MTX,
+# LE2MRX, LECODEDTX, LECODEDRX.
+# Example: keep LE on 1M only.
+#DefaultPHYs = LE1MTX LE1MRX
+
# Enable/Disable Advertisement Monitor interleave scan for power saving.
# 0: disable
# 1: enable
--
2.43.0
^ permalink raw reply related
* [PATCH v2] Bluetooth: hci_qca: Use 100 ms SSR delay for rampatch and NVM loading
From: Shuai Zhang @ 2026-05-25 6:51 UTC (permalink / raw)
To: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-arm-msm, linux-bluetooth, linux-kernel, cheng.jiang,
quic_chezhou, wei.deng, jinwang.li, mengshi.wu, shuai.zhang,
stable, Dmitry Baryshkov
When bt_en is pulled high by hardware, the host does not re-download
the firmware after SSR. The controller loads the rampatch and NVM
internally.
On HMT chip, the rampatch is ~264 KB and the NVM is ~9.4 KB. The
loading process takes approximately 70 ms. The previous 50 ms delay is
too short, causing the controller to not respond to the reset command
sent by the host, which leads to BT initialization failure:
Bluetooth: hci0: QCA memdump Done, received 458752, total 458752
Bluetooth: hci0: mem_dump_status: 2
Bluetooth: hci0: Opcode 0x0c03 failed: -110
Increase the delay to 100 ms, which was confirmed as a safe value by
the controller, to ensure the controller has finished loading the
firmware before the host sends commands.
Steps to reproduce:
1. Trigger SSR and wait for SSR to complete:
hcitool cmd 0x3f 0c 26
2. Run "bluetoothctl power on" and observe that BT fails to start.
Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw")
Cc: stable@vger.kernel.org
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
---
Changes in v2:
- Updated subject to mention 100 ms delay value
- Added firmware sizes (~264 KB rampatch, ~9.4 KB NVM)
- Added failure log excerpt
- Explained why 100 ms: confirmed as a safe value by the controller team
- Fixed missing space in comment ('NVM. */')
- Link v1
https://lore.kernel.org/linux-bluetooth/20260522110838.1158643-1-shuai.zhang@oss.qualcomm.com/
drivers/bluetooth/hci_qca.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index ed280399b..34500137d 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1680,8 +1680,8 @@ static void qca_hw_error(struct hci_dev *hdev, u8 code)
mod_timer(&qca->tx_idle_timer, jiffies +
msecs_to_jiffies(qca->tx_idle_delay));
- /* Controller reset completion time is 50ms */
- msleep(50);
+ /* Wait for the controller to load the rampatch and NVM. */
+ msleep(100);
clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
clear_bit(QCA_IBS_DISABLED, &qca->flags);
--
2.34.1
^ permalink raw reply related
* RE: [BlueZ] advertising: add property with advertisement ID
From: bluez.test.bot @ 2026-05-25 7:01 UTC (permalink / raw)
To: linux-bluetooth, michal.dzik
In-Reply-To: <20260525041151.3893522-1-michal.dzik@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 2518 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=1100171
---Test result---
Test Summary:
CheckPatch PASS 0.34 seconds
GitLint PASS 0.23 seconds
BuildEll PASS 19.89 seconds
BluezMake PASS 638.08 seconds
MakeCheck FAIL 19.19 seconds
MakeDistcheck FAIL 227.16 seconds
CheckValgrind FAIL 290.16 seconds
CheckSmatch WARNING 347.82 seconds
bluezmakeextell PASS 187.84 seconds
IncrementalBuild PASS 658.32 seconds
ScanBuild PASS 1026.14 seconds
Details
##############################
Test: MakeCheck - FAIL
Desc: Run Bluez Make Check
Output:
make[3]: *** [Makefile:10239: test-suite.log] Error 1
make[2]: *** [Makefile:10347: check-TESTS] Error 2
make[1]: *** [Makefile:10818: check-am] Error 2
make: *** [Makefile:10820: check] Error 2
##############################
Test: MakeDistcheck - FAIL
Desc: Run Bluez Make Distcheck
Output:
make[4]: *** [Makefile:10239: test-suite.log] Error 1
make[3]: *** [Makefile:10347: check-TESTS] Error 2
make[2]: *** [Makefile:10818: check-am] Error 2
make[1]: *** [Makefile:10820: check] Error 2
make: *** [Makefile:10741: distcheck] Error 1
##############################
Test: CheckValgrind - FAIL
Desc: Run Bluez Make Check with Valgrind
Output:
tools/mgmt-tester.c: In function ‘main’:
tools/mgmt-tester.c:12990:5: note: variable tracking size limit exceeded with ‘-fvar-tracking-assignments’, retrying without
12990 | int main(int argc, char *argv[])
| ^~~~
make[3]: *** [Makefile:10239: test-suite.log] Error 1
make[2]: *** [Makefile:10347: check-TESTS] Error 2
make[1]: *** [Makefile:10818: check-am] Error 2
make: *** [Makefile:10820: check] Error 2
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/advertising.c: note: in included file:./src/shared/mgmt.h:95:25: error: redefinition of unsigned int enum mgmt_io_capabilitysrc/advertising.c: note: in included file:./src/shared/mgmt.h:95:25: error: redefinition of unsigned int enum mgmt_io_capability
https://github.com/bluez/bluez/pull/2149
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: hci_qca: Use 100 ms SSR delay for rampatch and NVM loading
From: Dmitry Baryshkov @ 2026-05-25 8:35 UTC (permalink / raw)
To: Shuai Zhang
Cc: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
linux-arm-msm, linux-bluetooth, linux-kernel, cheng.jiang,
quic_chezhou, wei.deng, jinwang.li, mengshi.wu, stable
In-Reply-To: <20260525065156.2213123-1-shuai.zhang@oss.qualcomm.com>
On Mon, May 25, 2026 at 02:51:56PM +0800, Shuai Zhang wrote:
> When bt_en is pulled high by hardware, the host does not re-download
> the firmware after SSR. The controller loads the rampatch and NVM
> internally.
>
> On HMT chip, the rampatch is ~264 KB and the NVM is ~9.4 KB. The
What is HMT? Don't use abbreviations which are not known outside of your
company.
> loading process takes approximately 70 ms. The previous 50 ms delay is
> too short, causing the controller to not respond to the reset command
> sent by the host, which leads to BT initialization failure:
>
> Bluetooth: hci0: QCA memdump Done, received 458752, total 458752
> Bluetooth: hci0: mem_dump_status: 2
> Bluetooth: hci0: Opcode 0x0c03 failed: -110
>
> Increase the delay to 100 ms, which was confirmed as a safe value by
> the controller, to ensure the controller has finished loading the
> firmware before the host sends commands.
>
> Steps to reproduce:
> 1. Trigger SSR and wait for SSR to complete:
> hcitool cmd 0x3f 0c 26
> 2. Run "bluetoothctl power on" and observe that BT fails to start.
>
> Fixes: fce1a9244a0f ("Bluetooth: hci_qca: Fix SSR (SubSystem Restart) fail when BT_EN is pulled up by hw")
> Cc: stable@vger.kernel.org
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* [bluez/bluez] dc3162: adapter: Add configurable default LE PHYs
From: Tarjei @ 2026-05-25 10:18 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1100262
Home: https://github.com/bluez/bluez
Commit: dc316288b2356b3b2285ef20851b4aa4a112764f
https://github.com/bluez/bluez/commit/dc316288b2356b3b2285ef20851b4aa4a112764f
Author: Tarjei Bitustøyl <tarjeib@gmail.com>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
M src/adapter.c
M src/btd.h
M src/main.c
M src/main.conf
Log Message:
-----------
adapter: Add configurable default LE PHYs
Some controllers mis-handle LE procedures on specific PHYs with
certain peers. On an Intel AX210-class controller, connecting to a
Frostbay BLE device can fail during early ATT/GATT setup unless the
adapter is limited to LE 1M TX/RX.
Add an opt-in [LE] DefaultPHYs setting to bluetoothd and apply it at
adapter startup using MGMT_OP_GET/SET_PHY_CONFIGURATION while
preserving non-configurable PHY bits.
This provides a generic, adapter-wide workaround for controller-
specific LE PHY interoperability problems affecting scanning and
connection establishment, without adding device-specific quirks.
v2:
- Check MGMT_SETTING_PHY_CONFIGURATION before sending PHY
configuration commands.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-25 10:18 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1100107
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
* RE: Add configurable default LE PHY policy
From: bluez.test.bot @ 2026-05-25 11:04 UTC (permalink / raw)
To: linux-bluetooth, tarjeib
In-Reply-To: <20260525065045.27375-2-tarjeib@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 993 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=1100262
---Test result---
Test Summary:
CheckPatch PASS 0.58 seconds
GitLint PASS 0.33 seconds
BuildEll PASS 20.00 seconds
BluezMake PASS 621.23 seconds
CheckSmatch WARNING 323.73 seconds
bluezmakeextell PASS 164.72 seconds
IncrementalBuild PASS 622.45 seconds
ScanBuild PASS 920.21 seconds
Details
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/main.c: note: in included file (through src/device.h):
https://github.com/bluez/bluez/pull/2150
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v3] Bluetooth: RFCOMM: validate skb length in MCC handlers
From: SeungJu Cheon @ 2026-05-25 11:04 UTC (permalink / raw)
To: linux-bluetooth
Cc: marcel, luiz.dentz, pmenzel, me, linux-kernel,
linux-kernel-mentees, skhan, SeungJu Cheon, Muhammad Bilal
The RFCOMM MCC handlers cast skb->data to protocol-specific structs
without validating skb->len first. A malicious remote device can send
truncated MCC frames and trigger out-of-bounds reads in these handlers.
Fix this by using skb_pull_data() to validate and access the required
data before dereferencing it.
rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows
1-byte RPN requests. Handle this by validating only the DLCI byte first,
and validating the full struct only when len > 1.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Suggested-by: Muhammad Bilal <meatuni001@gmail.com>
Signed-off-by: SeungJu Cheon <suunj1331@gmail.com>
---
v3:
- Apply skb_pull_data() in rfcomm_recv_mcc() before accessing the
MCC header
- Return -EILSEQ instead of -EINVAL for malformed frames
v2:
- Use skb_pull_data() instead of manual length checks (Luiz)
- Add MCC header length validation in rfcomm_recv_mcc() (Paul)
- Allow 1-byte RPN requests per ETSI TS 07.10 (Paul)
Testing:
Tested under QEMU with VHCI and KASAN enabled by injecting both
well-formed and malformed RFCOMM MCC frames.
Well-formed PN/MSC/RLS frames and both valid RPN variants (full
8-byte form and 1-byte query form) are parsed identically to the
pre-patch behavior.
The following malformed frames are rejected before reaching the
MCC sub-handlers:
- truncated MCC headers
- PN/MSC/RLS/RPN payloads shorter than the fixed struct size
- invalid intermediate RPN lengths (len != 1 && len < 8)
- MCC payload lengths larger than the actual skb data
Frames with cr=0 are still silently dropped, and oversized frames
continue to ignore trailing bytes as before.
net/bluetooth/rfcomm/core.c | 67 +++++++++++++++++++++++++++----------
1 file changed, 49 insertions(+), 18 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index d11bd5337d57..364b9381c2dc 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1431,10 +1431,15 @@ static int rfcomm_apply_pn(struct rfcomm_dlc *d, int cr, struct rfcomm_pn *pn)
static int rfcomm_recv_pn(struct rfcomm_session *s, int cr, struct sk_buff *skb)
{
- struct rfcomm_pn *pn = (void *) skb->data;
+ struct rfcomm_pn *pn;
struct rfcomm_dlc *d;
- u8 dlci = pn->dlci;
+ u8 dlci;
+
+ pn = skb_pull_data(skb, sizeof(*pn));
+ if (!pn)
+ return -EILSEQ;
+ dlci = pn->dlci;
BT_DBG("session %p state %ld dlci %d", s, s->state, dlci);
if (!dlci)
@@ -1483,8 +1488,8 @@ static int rfcomm_recv_pn(struct rfcomm_session *s, int cr, struct sk_buff *skb)
static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_buff *skb)
{
- struct rfcomm_rpn *rpn = (void *) skb->data;
- u8 dlci = __get_dlci(rpn->dlci);
+ struct rfcomm_rpn *rpn;
+ u8 dlci;
u8 bit_rate = 0;
u8 data_bits = 0;
@@ -1495,15 +1500,16 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_
u8 xoff_char = 0;
u16 rpn_mask = RFCOMM_RPN_PM_ALL;
- BT_DBG("dlci %d cr %d len 0x%x bitr 0x%x line 0x%x flow 0x%x xonc 0x%x xoffc 0x%x pm 0x%x",
- dlci, cr, len, rpn->bit_rate, rpn->line_settings, rpn->flow_ctrl,
- rpn->xon_char, rpn->xoff_char, rpn->param_mask);
+ if (len == 1) {
+ rpn = skb_pull_data(skb, 1);
+ if (!rpn)
+ return -EILSEQ;
- if (!cr)
- return 0;
+ dlci = __get_dlci(rpn->dlci);
+
+ if (!cr)
+ return 0;
- if (len == 1) {
- /* This is a request, return default (according to ETSI TS 07.10) settings */
bit_rate = RFCOMM_RPN_BR_9600;
data_bits = RFCOMM_RPN_DATA_8;
stop_bits = RFCOMM_RPN_STOP_1;
@@ -1514,6 +1520,19 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_
goto rpn_out;
}
+ rpn = skb_pull_data(skb, sizeof(*rpn));
+ if (!rpn)
+ return -EILSEQ;
+
+ dlci = __get_dlci(rpn->dlci);
+
+ BT_DBG("dlci %d cr %d len 0x%x bitr 0x%x line 0x%x flow 0x%x xonc 0x%x xoffc 0x%x pm 0x%x",
+ dlci, cr, len, rpn->bit_rate, rpn->line_settings, rpn->flow_ctrl,
+ rpn->xon_char, rpn->xoff_char, rpn->param_mask);
+
+ if (!cr)
+ return 0;
+
/* Check for sane values, ignore/accept bit_rate, 8 bits, 1 stop bit,
* no parity, no flow control lines, normal XON/XOFF chars */
@@ -1589,9 +1608,14 @@ static int rfcomm_recv_rpn(struct rfcomm_session *s, int cr, int len, struct sk_
static int rfcomm_recv_rls(struct rfcomm_session *s, int cr, struct sk_buff *skb)
{
- struct rfcomm_rls *rls = (void *) skb->data;
- u8 dlci = __get_dlci(rls->dlci);
+ struct rfcomm_rls *rls;
+ u8 dlci;
+ rls = skb_pull_data(skb, sizeof(*rls));
+ if (!rls)
+ return -EILSEQ;
+
+ dlci = __get_dlci(rls->dlci);
BT_DBG("dlci %d cr %d status 0x%x", dlci, cr, rls->status);
if (!cr)
@@ -1608,10 +1632,15 @@ static int rfcomm_recv_rls(struct rfcomm_session *s, int cr, struct sk_buff *skb
static int rfcomm_recv_msc(struct rfcomm_session *s, int cr, struct sk_buff *skb)
{
- struct rfcomm_msc *msc = (void *) skb->data;
+ struct rfcomm_msc *msc;
struct rfcomm_dlc *d;
- u8 dlci = __get_dlci(msc->dlci);
+ u8 dlci;
+
+ msc = skb_pull_data(skb, sizeof(*msc));
+ if (!msc)
+ return -EILSEQ;
+ dlci = __get_dlci(msc->dlci);
BT_DBG("dlci %d cr %d v24 0x%x", dlci, cr, msc->v24_sig);
d = rfcomm_dlc_get(s, dlci);
@@ -1644,17 +1673,19 @@ static int rfcomm_recv_msc(struct rfcomm_session *s, int cr, struct sk_buff *skb
static int rfcomm_recv_mcc(struct rfcomm_session *s, struct sk_buff *skb)
{
- struct rfcomm_mcc *mcc = (void *) skb->data;
+ struct rfcomm_mcc *mcc;
u8 type, cr, len;
+ mcc = skb_pull_data(skb, sizeof(*mcc));
+ if (!mcc)
+ return -EILSEQ;
+
cr = __test_cr(mcc->type);
type = __get_mcc_type(mcc->type);
len = __get_mcc_len(mcc->len);
BT_DBG("%p type 0x%x cr %d", s, type, cr);
- skb_pull(skb, 2);
-
switch (type) {
case RFCOMM_PN:
rfcomm_recv_pn(s, cr, skb);
--
2.52.0
^ permalink raw reply related
* RE: [v2] Bluetooth: hci_qca: Use 100 ms SSR delay for rampatch and NVM loading
From: bluez.test.bot @ 2026-05-25 11:18 UTC (permalink / raw)
To: linux-bluetooth, shuai.zhang
In-Reply-To: <20260525065156.2213123-1-shuai.zhang@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 988 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=1100263
---Test result---
Test Summary:
CheckPatch PASS 0.53 seconds
VerifyFixes PASS 0.07 seconds
VerifySignedoff PASS 0.07 seconds
GitLint PASS 0.19 seconds
SubjectPrefix PASS 0.06 seconds
BuildKernel PASS 26.29 seconds
CheckAllWarning PASS 29.22 seconds
CheckSparse PASS 27.37 seconds
BuildKernel32 PASS 25.45 seconds
TestRunnerSetup PASS 574.26 seconds
IncrementalBuild PASS 25.16 seconds
https://github.com/bluez/bluetooth-next/pull/235
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH BlueZ v3 0/1] Add configurable default LE PHY policy
From: Tarjei Bitustøyl @ 2026-05-25 11:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Tarjei Bitustøyl
In-Reply-To: <20260524221421.258593-1-tarjeib@gmail.com>
This adds an opt-in bluetoothd setting for the adapter's default LE PHY
policy.
v3:
- Match the queue header include spelling in main.c with device.h to
avoid the Sparse redefinition warning seen in CI.
v2:
- Check MGMT_SETTING_PHY_CONFIGURATION before sending PHY
configuration commands.
Tarjei Bitustøyl (1):
adapter: Add configurable default LE PHYs
src/adapter.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++++++
src/btd.h | 2 ++
src/main.c | 63 +++++++++++++++++++++++++++++++++++++++-
src/main.conf | 8 ++++++
4 files changed, 151 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* [PATCH BlueZ v3 1/1] adapter: Add configurable default LE PHYs
From: Tarjei Bitustøyl @ 2026-05-25 11:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Tarjei Bitustøyl
In-Reply-To: <20260525113709.115020-1-tarjeib@gmail.com>
Some controllers mis-handle LE procedures on specific PHYs with
certain peers. On an Intel AX210-class controller, connecting to a
Frostbay BLE device can fail during early ATT/GATT setup unless the
adapter is limited to LE 1M TX/RX.
Add an opt-in [LE] DefaultPHYs setting to bluetoothd and apply it at
adapter startup using MGMT_OP_GET/SET_PHY_CONFIGURATION while
preserving non-configurable PHY bits.
This provides a generic, adapter-wide workaround for controller-
specific LE PHY interoperability problems affecting scanning and
connection establishment, without adding device-specific quirks.
v3:
- Match the queue header include spelling in main.c with device.h to
avoid the Sparse redefinition warning seen in CI.
v2:
- Check MGMT_SETTING_PHY_CONFIGURATION before sending PHY
configuration commands.
---
src/adapter.c | 79 +++++++++++++++++++++++++++++++++++++++++++++++++++
src/btd.h | 2 ++
src/main.c | 63 +++++++++++++++++++++++++++++++++++++++-
src/main.conf | 8 ++++++
4 files changed, 151 insertions(+), 1 deletion(-)
diff --git a/src/adapter.c b/src/adapter.c
index 20f7c3e03..46df362c5 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -4972,6 +4972,84 @@ done:
mgmt_tlv_list_free(list);
}
+static void set_default_le_phys_complete(uint8_t status, uint16_t length,
+ const void *param, void *user_data)
+{
+ struct btd_adapter *adapter = user_data;
+
+ if (status != MGMT_STATUS_SUCCESS)
+ btd_error(adapter->dev_id,
+ "Failed to set default LE PHYs for hci%u: %s (0x%02x)",
+ adapter->dev_id, mgmt_errstr(status), status);
+}
+
+static void get_default_le_phys_complete(uint8_t status, uint16_t length,
+ const void *param, void *user_data)
+{
+ struct btd_adapter *adapter = user_data;
+ const struct mgmt_rp_get_phy_confguration *rp = param;
+ struct mgmt_cp_set_phy_confguration cp;
+ uint32_t configurable_phys;
+ uint32_t selected_phys;
+ uint32_t next_phys;
+
+ if (status != MGMT_STATUS_SUCCESS) {
+ btd_error(adapter->dev_id,
+ "Failed to read PHY configuration for hci%u: %s (0x%02x)",
+ adapter->dev_id, mgmt_errstr(status), status);
+ return;
+ }
+
+ if (length < sizeof(*rp)) {
+ btd_error(adapter->dev_id,
+ "Too small get PHY configuration response for hci%u",
+ adapter->dev_id);
+ return;
+ }
+
+ configurable_phys = btohl(rp->configurable_phys);
+ selected_phys = btohl(rp->selected_phys);
+
+ configurable_phys &= MGMT_PHY_LE_TX_MASK | MGMT_PHY_LE_RX_MASK;
+ next_phys = selected_phys & ~configurable_phys;
+ next_phys |= btd_opts.default_le_phys & configurable_phys;
+
+ if (next_phys == selected_phys)
+ return;
+
+ cp.selected_phys = cpu_to_le32(next_phys);
+
+ if (mgmt_send(adapter->mgmt, MGMT_OP_SET_PHY_CONFIGURATION,
+ adapter->dev_id, sizeof(cp), &cp,
+ set_default_le_phys_complete, adapter, NULL) > 0)
+ return;
+
+ btd_error(adapter->dev_id,
+ "Failed to set default LE PHYs for hci%u",
+ adapter->dev_id);
+}
+
+static void load_default_le_phys(struct btd_adapter *adapter)
+{
+ if (!btd_opts.default_le_phys_configured)
+ return;
+
+ if (!(adapter->supported_settings & MGMT_SETTING_LE))
+ return;
+
+ if (!(adapter->supported_settings & MGMT_SETTING_PHY_CONFIGURATION))
+ return;
+
+ if (mgmt_send(adapter->mgmt, MGMT_OP_GET_PHY_CONFIGURATION,
+ adapter->dev_id, 0, NULL,
+ get_default_le_phys_complete, adapter, NULL) > 0)
+ return;
+
+ btd_error(adapter->dev_id,
+ "Failed to read PHY configuration for hci%u",
+ adapter->dev_id);
+}
+
static void load_devices(struct btd_adapter *adapter)
{
char dirname[PATH_MAX];
@@ -9455,6 +9533,7 @@ load:
btd_profile_foreach(probe_profile, adapter);
clear_blocked(adapter);
load_defaults(adapter);
+ load_default_le_phys(adapter);
load_devices(adapter);
/* restore Service Changed CCC value for bonded devices */
diff --git a/src/btd.h b/src/btd.h
index db2e81239..59f44dc8c 100644
--- a/src/btd.h
+++ b/src/btd.h
@@ -140,6 +140,8 @@ struct btd_opts {
bool device_privacy;
uint32_t name_request_retry_delay;
uint8_t secure_conn;
+ uint32_t default_le_phys;
+ bool default_le_phys_configured;
struct btd_defaults defaults;
diff --git a/src/main.c b/src/main.c
index 8aa19a3e3..83be19be3 100644
--- a/src/main.c
+++ b/src/main.c
@@ -32,6 +32,7 @@
#include <dbus/dbus.h>
#include "bluetooth/bluetooth.h"
+#include "bluetooth/mgmt.h"
#include "bluetooth/sdp.h"
#include "gdbus/gdbus.h"
@@ -43,7 +44,7 @@
#include "shared/att-types.h"
#include "shared/mainloop.h"
#include "shared/timeout.h"
-#include "shared/queue.h"
+#include "src/shared/queue.h"
#include "shared/crypto.h"
#include "bluetooth/uuid.h"
#include "shared/util.h"
@@ -132,6 +133,7 @@ static const char *le_options[] = {
"Autoconnecttimeout",
"AdvMonAllowlistScanDuration",
"AdvMonNoFilterScanDuration",
+ "DefaultPHYs",
"EnableAdvMonInterleaveScan",
NULL
};
@@ -145,6 +147,8 @@ static const char *policy_options[] = {
NULL
};
+static void parse_default_le_phys(GKeyFile *config);
+
static const char *gatt_options[] = {
"Cache",
"KeySize",
@@ -751,6 +755,7 @@ static void parse_le_config(GKeyFile *config)
return;
parse_mode_config(config, "LE", params, ARRAY_SIZE(params));
+ parse_default_le_phys(config);
}
static bool match_experimental(const void *data, const void *match_data)
@@ -966,6 +971,62 @@ static void parse_repairing(GKeyFile *config)
g_free(str);
}
+struct phy_config_entry {
+ const char *name;
+ uint32_t bit;
+};
+
+static const struct phy_config_entry le_phy_configs[] = {
+ { "LE1MTX", MGMT_PHY_LE_1M_TX },
+ { "LE1MRX", MGMT_PHY_LE_1M_RX },
+ { "LE2MTX", MGMT_PHY_LE_2M_TX },
+ { "LE2MRX", MGMT_PHY_LE_2M_RX },
+ { "LECODEDTX", MGMT_PHY_LE_CODED_TX },
+ { "LECODEDRX", MGMT_PHY_LE_CODED_RX },
+};
+
+static void parse_default_le_phys(GKeyFile *config)
+{
+ char *str = NULL;
+ char **tokens;
+ uint32_t phys = 0;
+ bool valid = false;
+ int i;
+
+ if (!parse_config_string(config, "LE", "DefaultPHYs", &str))
+ return;
+
+ tokens = g_strsplit_set(str, ", \t", -1);
+
+ for (i = 0; tokens[i]; i++) {
+ const char *token = tokens[i];
+ size_t j;
+
+ if (!token[0])
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(le_phy_configs); j++) {
+ if (strcasecmp(le_phy_configs[j].name, token) != 0)
+ continue;
+
+ phys |= le_phy_configs[j].bit;
+ valid = true;
+ break;
+ }
+
+ if (j == ARRAY_SIZE(le_phy_configs))
+ warn("Invalid DefaultPHYs token: %s", token);
+ }
+
+ if (valid) {
+ btd_opts.default_le_phys = phys;
+ btd_opts.default_le_phys_configured = true;
+ }
+
+ g_strfreev(tokens);
+ g_free(str);
+}
+
static bool parse_config_hex(GKeyFile *config, char *group,
const char *key, uint32_t *val)
{
diff --git a/src/main.conf b/src/main.conf
index 5846ef92d..ed955897e 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -247,6 +247,14 @@
# Default: 500
#AdvMonNoFilterScanDuration=
+# Configure the controller's default LE PHY policy used for scanning and
+# connection establishment. Only configurable LE PHYs are changed; mandatory
+# PHYs remain selected automatically.
+# Possible values: comma or space separated list of LE1MTX, LE1MRX, LE2MTX,
+# LE2MRX, LECODEDTX, LECODEDRX.
+# Example: keep LE on 1M only.
+#DefaultPHYs = LE1MTX LE1MRX
+
# Enable/Disable Advertisement Monitor interleave scan for power saving.
# 0: disable
# 1: enable
--
2.43.0
^ permalink raw reply related
* [PATCH v3] Bluetooth: Add Broadcom channel priority commands
From: Sasha Finkelstein @ 2026-05-25 12:11 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Marcel Holtmann,
Luiz Augusto von Dentz, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-kernel, asahi, linux-arm-kernel, linux-bluetooth, netdev,
Sasha Finkelstein
Certain Broadcom bluetooth chips (bcm4377/bcm4378/bcm438) need ACL
streams carrying audio to be set as "high priority" using a vendor
specific command to prevent 10-ish second-long dropouts whenever
something does a device scan. This patch sends the command when the
socket priority is set to TC_PRIO_INTERACTIVE, as BlueZ does for audio.
From experimenting with the hardware - this command is not suitable for
per-skb priority switching, as prioritization is done on the handle
level, with this command reconfiguring certain radio timings, and
dropping to low priority in order to send a low packet on the same
handle as an audio stream is being played on causes the same kind of
dropout it is supposed to avoid. In addition, the hardware is rather
picky about when this command can be sent, as sending it during
connection open results in a timeout. The vendor stacks solve it by
having high-level visibility into what a connection is used for and
sending it from userspace when it is known that an audio stream is
about to start. As we can't have that visibility without introducing a
new ioctl, the socket priority is used as proxy.
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
---
Changes in v3:
- use a struct for command data
- Link to v2: https://lore.kernel.org/r/20260407-brcm-prio-v2-1-3f745edf49af@gmail.com
Changes in v2:
- new ioctl got nack-ed, so let's use sk_priority as the trigger
- Link to v1: https://lore.kernel.org/r/20260407-brcm-prio-v1-1-f38b17376640@gmail.com
---
MAINTAINERS | 2 ++
drivers/bluetooth/hci_bcm4377.c | 2 ++
include/net/bluetooth/hci_core.h | 15 +++++++++++++++
net/bluetooth/Kconfig | 7 +++++++
net/bluetooth/Makefile | 1 +
net/bluetooth/brcm.c | 38 ++++++++++++++++++++++++++++++++++++++
net/bluetooth/brcm.h | 19 +++++++++++++++++++
net/bluetooth/hci_core.c | 4 ++++
8 files changed, 88 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 10e8253181d3..da4d12ec70d6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2581,6 +2581,8 @@ F: include/dt-bindings/pinctrl/apple.h
F: include/linux/mfd/macsmc.h
F: include/linux/soc/apple/*
F: include/uapi/drm/asahi_drm.h
+F: net/bluetooth/brcm.c
+F: net/bluetooth/brcm.h
ARM/ARTPEC MACHINE SUPPORT
M: Jesper Nilsson <jesper.nilsson@axis.com>
diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
index 925d0a635945..5f79920c0306 100644
--- a/drivers/bluetooth/hci_bcm4377.c
+++ b/drivers/bluetooth/hci_bcm4377.c
@@ -2397,6 +2397,8 @@ static int bcm4377_probe(struct pci_dev *pdev, const struct pci_device_id *id)
if (bcm4377->hw->broken_le_ext_adv_report_phy)
hci_set_quirk(hdev, HCI_QUIRK_FIXUP_LE_EXT_ADV_REPORT_PHY);
+ hci_set_brcm_capable(hdev);
+
pci_set_drvdata(pdev, bcm4377);
hci_set_drvdata(hdev, bcm4377);
SET_HCIDEV_DEV(hdev, &pdev->dev);
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index aa600fbf9a53..53ebb2ae898f 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -642,6 +642,10 @@ struct hci_dev {
bool aosp_quality_report;
#endif
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+ bool brcm_capable;
+#endif
+
int (*open)(struct hci_dev *hdev);
int (*close)(struct hci_dev *hdev);
int (*flush)(struct hci_dev *hdev);
@@ -756,6 +760,10 @@ struct hci_conn {
unsigned int sent;
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+ bool brcm_high_prio;
+#endif
+
struct sk_buff_head data_q;
struct list_head chan_list;
@@ -1791,6 +1799,13 @@ static inline void hci_set_aosp_capable(struct hci_dev *hdev)
#endif
}
+static inline void hci_set_brcm_capable(struct hci_dev *hdev)
+{
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+ hdev->brcm_capable = true;
+#endif
+}
+
static inline void hci_devcd_setup(struct hci_dev *hdev)
{
#ifdef CONFIG_DEV_COREDUMP
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index ee6457d1a5ee..b611942c7b8f 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -107,6 +107,13 @@ config BT_AOSPEXT
This options enables support for the Android Open Source
Project defined HCI vendor extensions.
+config BT_BRCMEXT
+ bool "Enable Broadcom extensions"
+ depends on BT
+ help
+ This option enables support for the Broadcom defined HCI
+ vendor extensions.
+
config BT_DEBUGFS
bool "Export Bluetooth internals in debugfs"
depends on BT && DEBUG_FS
diff --git a/net/bluetooth/Makefile b/net/bluetooth/Makefile
index 41049b280887..d402645dfb7d 100644
--- a/net/bluetooth/Makefile
+++ b/net/bluetooth/Makefile
@@ -23,5 +23,6 @@ bluetooth-$(CONFIG_BT_LE) += iso.o
bluetooth-$(CONFIG_BT_LEDS) += leds.o
bluetooth-$(CONFIG_BT_MSFTEXT) += msft.o
bluetooth-$(CONFIG_BT_AOSPEXT) += aosp.o
+bluetooth-$(CONFIG_BT_BRCMEXT) += brcm.o
bluetooth-$(CONFIG_BT_DEBUGFS) += hci_debugfs.o
bluetooth-$(CONFIG_BT_SELFTEST) += selftest.o
diff --git a/net/bluetooth/brcm.c b/net/bluetooth/brcm.c
new file mode 100644
index 000000000000..299d83d465c3
--- /dev/null
+++ b/net/bluetooth/brcm.c
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2026 The Asahi Linux Contributors
+ */
+
+#include <net/bluetooth/bluetooth.h>
+#include <net/bluetooth/hci_core.h>
+
+#include "brcm.h"
+
+struct brcm_prio_cmd {
+ __le16 handle;
+ u8 enable;
+} __packed;
+
+int brcm_set_high_priority(struct hci_dev *hdev, struct hci_conn *conn,
+ bool enable)
+{
+ struct sk_buff *skb;
+ struct brcm_prio_cmd cmd;
+
+ if (!hdev->brcm_capable)
+ return 0;
+
+ if (conn->brcm_high_prio == enable)
+ return 0;
+
+ cmd.handle = cpu_to_le16(conn->handle);
+ cmd.enable = !!enable;
+
+ skb = hci_cmd_sync(hdev, 0xfc57, sizeof(cmd), &cmd, HCI_CMD_TIMEOUT);
+ if (IS_ERR(skb))
+ return PTR_ERR(skb);
+
+ conn->brcm_high_prio = enable;
+ kfree_skb(skb);
+ return 0;
+}
diff --git a/net/bluetooth/brcm.h b/net/bluetooth/brcm.h
new file mode 100644
index 000000000000..2290fc6cf798
--- /dev/null
+++ b/net/bluetooth/brcm.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2026 The Asahi Linux Contributors
+ */
+
+#if IS_ENABLED(CONFIG_BT_BRCMEXT)
+
+int brcm_set_high_priority(struct hci_dev *hdev, struct hci_conn *conn,
+ bool enable);
+
+#else
+
+static inline int brcm_set_high_priority(struct hci_dev *hdev,
+ struct hci_conn *conn, bool enable)
+{
+ return 0;
+}
+
+#endif
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index c46c1236ebfa..0e74bad496a2 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -46,6 +46,7 @@
#include "msft.h"
#include "aosp.h"
#include "hci_codec.h"
+#include "brcm.h"
static void hci_rx_work(struct work_struct *work);
static void hci_cmd_work(struct work_struct *work);
@@ -3696,6 +3697,9 @@ static void hci_sched_acl_pkt(struct hci_dev *hdev)
skb = skb_dequeue(&chan->data_q);
+ if (skb->priority == TC_PRIO_INTERACTIVE)
+ brcm_set_high_priority(hdev, chan->conn, true);
+
hci_conn_enter_active_mode(chan->conn,
bt_cb(skb)->force_active);
---
base-commit: 8bc67e4db64aa72732c474b44ea8622062c903f0
change-id: 20260407-brcm-prio-b630e6cc3834
Best regards,
--
Sasha Finkelstein <k@chaosmail.tech>
^ permalink raw reply related
* [bluez/bluez] 360693: adapter: Add configurable default LE PHYs
From: Tarjei @ 2026-05-25 13:44 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1100433
Home: https://github.com/bluez/bluez
Commit: 360693d705ade0b49c1b21b4ad9b93dc3624d01a
https://github.com/bluez/bluez/commit/360693d705ade0b49c1b21b4ad9b93dc3624d01a
Author: Tarjei Bitustøyl <tarjeib@gmail.com>
Date: 2026-05-25 (Mon, 25 May 2026)
Changed paths:
M src/adapter.c
M src/btd.h
M src/main.c
M src/main.conf
Log Message:
-----------
adapter: Add configurable default LE PHYs
Some controllers mis-handle LE procedures on specific PHYs with
certain peers. On an Intel AX210-class controller, connecting to a
Frostbay BLE device can fail during early ATT/GATT setup unless the
adapter is limited to LE 1M TX/RX.
Add an opt-in [LE] DefaultPHYs setting to bluetoothd and apply it at
adapter startup using MGMT_OP_GET/SET_PHY_CONFIGURATION while
preserving non-configurable PHY bits.
This provides a generic, adapter-wide workaround for controller-
specific LE PHY interoperability problems affecting scanning and
connection establishment, without adding device-specific quirks.
v3:
- Match the queue header include spelling in main.c with device.h to
avoid the Sparse redefinition warning seen in CI.
v2:
- Check MGMT_SETTING_PHY_CONFIGURATION before sending PHY
configuration commands.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-25 13:44 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1100262
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
* Re: [PATCH v3] Bluetooth: Add Broadcom channel priority commands
From: Joshua Peisach @ 2026-05-25 13:58 UTC (permalink / raw)
To: Sasha Finkelstein, Sven Peter, Janne Grunau, Neal Gompa,
Marcel Holtmann, Luiz Augusto von Dentz, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: linux-kernel, asahi, linux-arm-kernel, linux-bluetooth, netdev
In-Reply-To: <20260525-brcm-prio-v3-1-6259e10233f8@chaosmail.tech>
On Mon May 25, 2026 at 8:11 AM EDT, Sasha Finkelstein wrote:
> --- /dev/null
> +++ b/net/bluetooth/brcm.c
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 The Asahi Linux Contributors
> + */
> +
> +#include <net/bluetooth/bluetooth.h>
> +#include <net/bluetooth/hci_core.h>
> +
> +#include "brcm.h"
> +
> +struct brcm_prio_cmd {
> + __le16 handle;
> + u8 enable;
> +} __packed;
> +
> +int brcm_set_high_priority(struct hci_dev *hdev, struct hci_conn *conn,
> + bool enable)
> +{
> + struct sk_buff *skb;
> + struct brcm_prio_cmd cmd;
> +
> + if (!hdev->brcm_capable)
> + return 0;
> +
> + if (conn->brcm_high_prio == enable)
> + return 0;
> +
> + cmd.handle = cpu_to_le16(conn->handle);
> + cmd.enable = !!enable;
> +
Probably a dumb question, but worth asking - what is the purpose of the
"!!"? Wouldn't just passing "enable" be sufficient?
Also, currently, cmd.enable seems to just be set and used in the case
of boolean conditions. Would it make sense for the enable field in
brcm_prio_cmd to be a bool or does it not really matter?
> + skb = hci_cmd_sync(hdev, 0xfc57, sizeof(cmd), &cmd, HCI_CMD_TIMEOUT);
> + if (IS_ERR(skb))
> + return PTR_ERR(skb);
> +
> + conn->brcm_high_prio = enable;
> + kfree_skb(skb);
> + return 0;
> +}
> diff --git a/net/bluetooth/brcm.h b/net/bluetooth/brcm.h
> new file mode 100644
> index 000000000000..2290fc6cf798
> --- /dev/null
> +++ b/net/bluetooth/brcm.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2026 The Asahi Linux Contributors
> + */
> +
> +#if IS_ENABLED(CONFIG_BT_BRCMEXT)
> +
> +int brcm_set_high_priority(struct hci_dev *hdev, struct hci_conn *conn,
> + bool enable);
> +
> +#else
> +
> +static inline int brcm_set_high_priority(struct hci_dev *hdev,
> + struct hci_conn *conn, bool enable)
> +{
> + return 0;
> +}
> +
> +#endif
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index c46c1236ebfa..0e74bad496a2 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -46,6 +46,7 @@
> #include "msft.h"
> #include "aosp.h"
> #include "hci_codec.h"
> +#include "brcm.h"
>
> static void hci_rx_work(struct work_struct *work);
> static void hci_cmd_work(struct work_struct *work);
> @@ -3696,6 +3697,9 @@ static void hci_sched_acl_pkt(struct hci_dev *hdev)
>
> skb = skb_dequeue(&chan->data_q);
>
> + if (skb->priority == TC_PRIO_INTERACTIVE)
> + brcm_set_high_priority(hdev, chan->conn, true);
> +
> hci_conn_enter_active_mode(chan->conn,
> bt_cb(skb)->force_active);
>
>
> ---
> base-commit: 8bc67e4db64aa72732c474b44ea8622062c903f0
> change-id: 20260407-brcm-prio-b630e6cc3834
>
> Best regards,
> --
> Sasha Finkelstein <k@chaosmail.tech>
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: Add Broadcom channel priority commands
From: Sasha Finkelstein @ 2026-05-25 14:05 UTC (permalink / raw)
To: Joshua Peisach
Cc: Sven Peter, Janne Grunau, Neal Gompa, Marcel Holtmann,
Luiz Augusto von Dentz, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-kernel, asahi,
linux-arm-kernel, linux-bluetooth, netdev
In-Reply-To: <DIRT7260SRQZ.1BFF8CX3FJ57G@ubuntu.com>
> On May 25, 2026, at 15:58, Joshua Peisach <jpeisach@ubuntu.com> wrote:
>
> On Mon May 25, 2026 at 8:11 AM EDT, Sasha Finkelstein wrote:
>>
>> + cmd.enable = !!enable;
>> +
>
> Probably a dumb question, but worth asking - what is the purpose of the
> "!!"? Wouldn't just passing "enable" be sufficient?
This is a way to enforce that the value is exactly 0 or 1, not 0 or non-zero.
>
> Also, currently, cmd.enable seems to just be set and used in the case
> of boolean conditions. Would it make sense for the enable field in
> brcm_prio_cmd to be a bool or does it not really matter?
>
Opposite, actually, this struct is fed to firmware, and it needs to be
specifically a u8.
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: Add Broadcom channel priority commands
From: Joshua Peisach @ 2026-05-25 14:07 UTC (permalink / raw)
To: Sasha Finkelstein, Joshua Peisach
Cc: Sven Peter, Janne Grunau, Neal Gompa, Marcel Holtmann,
Luiz Augusto von Dentz, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, linux-kernel, asahi,
linux-arm-kernel, linux-bluetooth, netdev
In-Reply-To: <172D11E7-AF98-43F8-B41B-907738749EA5@chaosmail.tech>
On Mon May 25, 2026 at 10:05 AM EDT, Sasha Finkelstein wrote:
>
>> On May 25, 2026, at 15:58, Joshua Peisach <jpeisach@ubuntu.com> wrote:
>>
>> On Mon May 25, 2026 at 8:11 AM EDT, Sasha Finkelstein wrote:
>>>
>>> + cmd.enable = !!enable;
>>> +
>>
>> Probably a dumb question, but worth asking - what is the purpose of the
>> "!!"? Wouldn't just passing "enable" be sufficient?
>
> This is a way to enforce that the value is exactly 0 or 1, not 0 or non-zero.
>
>>
>> Also, currently, cmd.enable seems to just be set and used in the case
>> of boolean conditions. Would it make sense for the enable field in
>> brcm_prio_cmd to be a bool or does it not really matter?
>>
> Opposite, actually, this struct is fed to firmware, and it needs to be
> specifically a u8.
Got it, thanks!
Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
^ permalink raw reply
* RE: [v3] Bluetooth: RFCOMM: validate skb length in MCC handlers
From: bluez.test.bot @ 2026-05-25 14:21 UTC (permalink / raw)
To: linux-bluetooth, suunj1331
In-Reply-To: <20260525110443.139485-1-suunj1331@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1042 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=1100421
---Test result---
Test Summary:
CheckPatch PASS 0.59 seconds
VerifyFixes PASS 0.07 seconds
VerifySignedoff PASS 0.07 seconds
GitLint PASS 1.31 seconds
SubjectPrefix PASS 0.09 seconds
BuildKernel PASS 26.59 seconds
CheckAllWarning PASS 29.34 seconds
CheckSparse PASS 28.00 seconds
BuildKernel32 PASS 25.80 seconds
TestRunnerSetup PASS 573.06 seconds
TestRunner_rfcomm-tester PASS 25.38 seconds
IncrementalBuild PASS 25.10 seconds
https://github.com/bluez/bluetooth-next/pull/236
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v3] Bluetooth: Add Broadcom channel priority commands
From: bluez.test.bot @ 2026-05-25 14:29 UTC (permalink / raw)
To: linux-bluetooth, k
In-Reply-To: <20260525-brcm-prio-v3-1-6259e10233f8@chaosmail.tech>
[-- Attachment #1: Type: text/plain, Size: 3290 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=1100446
---Test result---
Test Summary:
CheckPatch FAIL 2.47 seconds
VerifyFixes PASS 0.58 seconds
VerifySignedoff PASS 0.74 seconds
GitLint FAIL 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.04 seconds
CheckAllWarning PASS 28.05 seconds
CheckSparse PASS 26.50 seconds
BuildKernel32 PASS 24.72 seconds
TestRunnerSetup PASS 527.44 seconds
TestRunner_l2cap-tester PASS 58.70 seconds
TestRunner_iso-tester PASS 77.29 seconds
TestRunner_bnep-tester PASS 19.22 seconds
TestRunner_mgmt-tester FAIL 211.10 seconds
TestRunner_rfcomm-tester PASS 25.41 seconds
TestRunner_sco-tester PASS 32.43 seconds
TestRunner_ioctl-tester PASS 25.88 seconds
TestRunner_mesh-tester FAIL 26.00 seconds
TestRunner_smp-tester PASS 23.37 seconds
TestRunner_userchan-tester PASS 20.14 seconds
TestRunner_6lowpan-tester PASS 22.74 seconds
IncrementalBuild PASS 24.00 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v3] Bluetooth: Add Broadcom channel priority commands
WARNING: please write a help paragraph that fully describes the config symbol with at least 4 lines
#200: FILE: net/bluetooth/Kconfig:110:
+config BT_BRCMEXT
+ bool "Enable Broadcom extensions"
+ depends on BT
+ help
+ This option enables support for the Broadcom defined HCI
+ vendor extensions.
+
total: 0 errors, 1 warnings, 0 checks, 141 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/14593220.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:
[v3] Bluetooth: Add Broadcom channel priority commands
47: B2 Line has trailing whitespace: "-- "
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.241 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.378 seconds
Mesh - Send cancel - 2 Timed out 1.987 seconds
https://github.com/bluez/bluetooth-next/pull/237
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: Add configurable default LE PHY policy
From: bluez.test.bot @ 2026-05-25 14:33 UTC (permalink / raw)
To: linux-bluetooth, tarjeib
In-Reply-To: <20260525113709.115020-2-tarjeib@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1144 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=1100433
---Test result---
Test Summary:
CheckPatch PASS 0.39 seconds
GitLint FAIL 0.21 seconds
BuildEll PASS 19.92 seconds
BluezMake PASS 646.41 seconds
CheckSmatch PASS 354.93 seconds
bluezmakeextell PASS 182.02 seconds
IncrementalBuild PASS 665.89 seconds
ScanBuild PASS 1045.30 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ,v3,1/1] adapter: Add configurable default LE PHYs
18: B3 Line contains hard tab characters (\t): " avoid the Sparse redefinition warning seen in CI."
22: B3 Line contains hard tab characters (\t): " configuration commands."
https://github.com/bluez/bluez/pull/2152
---
Regards,
Linux Bluetooth
^ 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