* Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading
From: Luiz Augusto von Dentz @ 2026-05-22 16:22 UTC (permalink / raw)
To: Paul Menzel
Cc: Shuai Zhang, 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: <1b8e8129-4f42-429e-bd70-5e368551739c@molgen.mpg.de>
Hi Paul,
On Fri, May 22, 2026 at 10:50 AM Paul Menzel <pmenzel@molgen.mpg.de> 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)
>
> > 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.
> > 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
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 2/3] Bluetooth: hci_qca: Support QCA2066 on M.2 connector via pwrseq
From: Loic Poulain @ 2026-05-22 16:11 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <cx3pbr47tsy5mnag73oopkodnx4jgoiipz5pzrp4uze7mk4fgg@zogzww23ueni>
On Wed, May 20, 2026 at 2:33 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Wed, May 20, 2026 at 01:01:43PM +0200, Loic Poulain wrote:
> > 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.
> >
> > Also allocate bt_power unconditionally for all SOC types since the
> > pwrseq path is independent of the SOC type switch.
> >
> > Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> > ---
> > drivers/bluetooth/hci_qca.c | 33 +++++++++++++--------------------
> > 1 file changed, 13 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index b5439b9956cfb0497e6ba6ccd9ed61224d23a9dd..de5cba7b7f44e280a48dad5d670fa2758d3268d0 100644
> > --- a/drivers/bluetooth/hci_qca.c
> > +++ b/drivers/bluetooth/hci_qca.c
> > @@ -1873,6 +1873,9 @@ static int qca_power_on(struct hci_dev *hdev)
> > /* Controller needs time to bootup. */
> > msleep(150);
> > }
> > +
> > + if (qcadev->bt_power && qcadev->bt_power->pwrseq)
> > + pwrseq_power_on(qcadev->bt_power->pwrseq);
> > }
> >
> > clear_bit(QCA_BT_OFF, &qca->flags);
> > @@ -2415,25 +2418,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> > else
> > qcadev->btsoc_type = QCA_ROME;
> >
> > - switch (qcadev->btsoc_type) {
> > - case QCA_QCA6390:
> > - case QCA_WCN3950:
> > - case QCA_WCN3988:
> > - case QCA_WCN3990:
> > - case QCA_WCN3991:
> > - case QCA_WCN3998:
> > - case QCA_WCN6750:
> > - case QCA_WCN6855:
> > - case QCA_WCN7850:
> > - qcadev->bt_power = devm_kzalloc(&serdev->dev,
> > - sizeof(struct qca_power),
> > - GFP_KERNEL);
> > - if (!qcadev->bt_power)
> > - return -ENOMEM;
> > - break;
> > - default:
> > - break;
> > - }
> > + qcadev->bt_power = devm_kzalloc(&serdev->dev, sizeof(struct qca_power), GFP_KERNEL);
> > + if (!qcadev->bt_power)
> > + return -ENOMEM;
>
> This builds bt_power for all devices even though it wasn't the case
> beforehand. As such, you can drop all further `if (qcadev->bt_power)`
> checks in the driver. But, you also need to check that this won't break
> support for other (older) chips.
Ok, I will do, and double check.
>
> >
> > switch (qcadev->btsoc_type) {
> > case QCA_WCN3950:
> > @@ -2543,7 +2530,13 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> > return PTR_ERR(qcadev->bt_en);
> > }
> >
> > - if (!qcadev->bt_en)
> > + if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
>
> And this breaks support for pwrseq for non-M.2 BT devices. There is no
> OF graph in such a case.
Not sure why, here we handle OF graph as an optional pwrseq provider,
but still support legacy enablement.
>
> > + 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);
> > + }
> > +
> > + if (!qcadev->bt_en && !qcadev->bt_power->pwrseq)
> > bt_en_available = false;
> >
> > qcadev->susclk = devm_clk_get_optional_enabled_with_rate(
> >
> > --
> > 2.34.1
> >
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading
From: Paul Menzel @ 2026-05-22 14:50 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: <20260522110838.1158643-1-shuai.zhang@oss.qualcomm.com>
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)
> 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?
> 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
^ permalink raw reply
* Re: [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading
From: Dmitry Baryshkov @ 2026-05-22 14:19 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: <20260522110838.1158643-1-shuai.zhang@oss.qualcomm.com>
On Fri, May 22, 2026 at 07:08:38PM +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, due to the large firmware file size, the
> 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.
>
> Increase the delay to 100ms 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
> Signed-off-by: Shuai Zhang <shuai.zhang@oss.qualcomm.com>
> ---
> drivers/bluetooth/hci_qca.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* RE: [BlueZ] monitor: Add support for HCI Event Encryption Change v2
From: bluez.test.bot @ 2026-05-22 14:15 UTC (permalink / raw)
To: linux-bluetooth, apusaka
In-Reply-To: <20260522111540.581113-1-apusaka@google.com>
[-- Attachment #1: Type: text/plain, Size: 2576 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=1099306
---Test result---
Test Summary:
CheckPatch FAIL 0.50 seconds
GitLint PASS 0.41 seconds
BuildEll PASS 20.30 seconds
BluezMake PASS 661.62 seconds
MakeCheck PASS 0.95 seconds
MakeDistcheck FAIL 235.11 seconds
CheckValgrind PASS 228.16 seconds
CheckSmatch WARNING 359.26 seconds
bluezmakeextell PASS 182.87 seconds
IncrementalBuild PASS 688.00 seconds
ScanBuild PASS 1069.98 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[BlueZ] monitor: Add support for HCI Event Encryption Change v2
WARNING:PREFER_DEFINED_ATTRIBUTE_MACRO: Prefer __packed over __attribute__((packed))
#114: FILE: monitor/bt.h:3705:
+} __attribute__ ((packed));
/github/workspace/src/patch/14589097.patch total: 0 errors, 1 warnings, 39 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/14589097.patch has style problems, please review.
NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
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: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
monitor/packet.c:2002:26: warning: Variable length array is used.monitor/packet.c: note: in included file:monitor/bt.h:3917:52: warning: array of flexible structuresmonitor/bt.h:3905:40: warning: array of flexible structures
https://github.com/bluez/bluez/pull/2146
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading
From: bluez.test.bot @ 2026-05-22 13:44 UTC (permalink / raw)
To: linux-bluetooth, shuai.zhang
In-Reply-To: <20260522110838.1158643-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=1099303
---Test result---
Test Summary:
CheckPatch PASS 0.72 seconds
VerifyFixes PASS 0.13 seconds
VerifySignedoff PASS 0.13 seconds
GitLint PASS 0.32 seconds
SubjectPrefix PASS 0.12 seconds
BuildKernel PASS 26.24 seconds
CheckAllWarning PASS 31.73 seconds
CheckSparse PASS 28.54 seconds
BuildKernel32 PASS 26.68 seconds
TestRunnerSetup PASS 535.95 seconds
IncrementalBuild PASS 24.16 seconds
https://github.com/bluez/bluetooth-next/pull/233
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez] 6e45cd: monitor: Add support for HCI Event Encryption Chan...
From: apusaka @ 2026-05-22 13:17 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1099306
Home: https://github.com/bluez/bluez
Commit: 6e45cdbb18850e9043d2bf73c5735849a0e217cc
https://github.com/bluez/bluez/commit/6e45cdbb18850e9043d2bf73c5735849a0e217cc
Author: Archie Pusaka <apusaka@chromium.org>
Date: 2026-05-22 (Fri, 22 May 2026)
Changed paths:
M monitor/bt.h
M monitor/packet.c
Log Message:
-----------
monitor: Add support for HCI Event Encryption Change v2
> HCI Event: Encryption Change v2 (0x59) plen 5
Status: Success (0x00)
Handle: 256 (BR-ACL) Address: 00:11:22:34:56:78
Encryption: Enabled with E0 (0x01)
Key size: 16
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH BlueZ] monitor: Add support for HCI Event Encryption Change v2
From: Archie Pusaka @ 2026-05-22 11:15 UTC (permalink / raw)
To: linux-bluetooth, Luiz Augusto von Dentz; +Cc: CrosBT Upstreaming, Archie Pusaka
From: Archie Pusaka <apusaka@chromium.org>
> HCI Event: Encryption Change v2 (0x59) plen 5
Status: Success (0x00)
Handle: 256 (BR-ACL) Address: 00:11:22:34:56:78
Encryption: Enabled with E0 (0x01)
Key size: 16
---
monitor/bt.h | 8 ++++++++
monitor/packet.c | 13 +++++++++++++
2 files changed, 21 insertions(+)
diff --git a/monitor/bt.h b/monitor/bt.h
index 147b76537..eac6b5ed7 100644
--- a/monitor/bt.h
+++ b/monitor/bt.h
@@ -3696,6 +3696,14 @@ struct bt_hci_evt_auth_payload_timeout_expired {
uint16_t handle;
} __attribute__ ((packed));
+#define BT_HCI_EVT_ENCRYPT_CHANGE_V2 0x59
+struct bt_hci_evt_encrypt_change_v2 {
+ uint8_t status;
+ uint16_t handle;
+ uint8_t encr_mode;
+ uint8_t encr_key_size;
+} __attribute__ ((packed));
+
#define BT_HCI_EVT_LE_CONN_COMPLETE 0x01
struct bt_hci_evt_le_conn_complete {
uint8_t status;
diff --git a/monitor/packet.c b/monitor/packet.c
index ff0b1cac2..0de7e6f57 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -12008,6 +12008,17 @@ static void auth_payload_timeout_expired_evt(struct timeval *tv, uint16_t index,
print_handle(evt->handle);
}
+static void encrypt_change_evt_v2(struct timeval *tv, uint16_t index,
+ const void *data, uint8_t size)
+{
+ const struct bt_hci_evt_encrypt_change_v2 *evt = data;
+
+ print_status(evt->status);
+ print_handle(evt->handle);
+ print_encr_mode_change(evt->encr_mode, evt->handle);
+ print_key_size(evt->encr_key_size);
+}
+
static void le_conn_complete_evt(struct timeval *tv, uint16_t index,
const void *data, uint8_t size)
{
@@ -13737,6 +13748,8 @@ static const struct event_data event_table[] = {
{ 0x57, "Authenticated Payload Timeout Expired",
auth_payload_timeout_expired_evt, 2, true },
{ 0x58, "SAM Status Change" },
+ { 0x59, "Encryption Change v2",
+ encrypt_change_evt_v2, 5, true },
{ 0xfe, "Testing" },
{ 0xff, "Vendor", vendor_evt, 0, false },
{ }
--
2.54.0.746.g67dd491aae-goog
^ permalink raw reply related
* [PATCH v1] Bluetooth: hci_qca: Increase SSR delay for rampatch and NVM loading
From: Shuai Zhang @ 2026-05-22 11:08 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
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
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.
Increase the delay to 100ms 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
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.*/
+ msleep(100);
clear_bit(QCA_SSR_TRIGGERED, &qca->flags);
clear_bit(QCA_IBS_DISABLED, &qca->flags);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Konrad Dybcio @ 2026-05-22 9:48 UTC (permalink / raw)
To: Loic Poulain, Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <CAFEp6-3Gbd1gzfeu5xdfBJixL6JXaoSFkRUsBjOji0ZEOHHyvw@mail.gmail.com>
On 5/20/26 4:41 PM, Loic Poulain wrote:
> On Wed, May 20, 2026 at 4:36 PM Dmitry Baryshkov
> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>
>> On Wed, May 20, 2026 at 04:29:40PM +0200, Loic Poulain wrote:
>>> On Wed, May 20, 2026 at 2:34 PM Dmitry Baryshkov
>>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>>>
>>>> On Wed, May 20, 2026 at 01:01:44PM +0200, Loic Poulain wrote:
>>>>> 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.
>>>>>
>>>>> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts | 65 +++++++++++++++++++++++
>>>>> 1 file changed, 65 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
>>>>> index 93ed575817af1c5e903662c209ead629fe202ee2..6fcad77f320cb82eccb6f07244d185abfb1976d9 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
>>>>> +++ b/arch/arm64/boot/dts/qcom/monaco-arduino-monza.dts
>>>>> @@ -154,6 +154,39 @@ vreg_nvme: regulator-3p3-m2 {
>>>>> enable-active-high;
>>>>> startup-delay-us = <20000>;
>>>>> };
>>>>> +
>>>>> + wireless-lga-connector {
>>>>> + compatible = "pcie-m2-e-connector";
>>>>
>>>> I think it was discussed that LGA can't be an actual M.2 E-key
>>>> connector.
>>>
>>> I am not sure I followed this discussion. Do you mean that I should
>>> introduce a dedicated LGA/vendor-compatible string in the compatible
>>> list of the pcie-m2-e-connector binding, or that LGA-based designs
>>> should not be described using the pcie-m2-e-connector binding (graph
>>> representation)?
>>
>> I think, it should be a separate, vendor-specific compat (maybe using
>> m2-e as a fallback).
>
> ok, understood.
Oh, I reviewed this before looking at this discussion.. yeah Dmitry's
suggestion is good
Konrad
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: monaco-arduino-monza: Add QCA2066 M.2 WiFi/BT support
From: Konrad Dybcio @ 2026-05-22 9:47 UTC (permalink / raw)
To: Loic Poulain, Manivannan Sadhasivam, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-pci, linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <20260520-monza-wireless-v1-3-9f6942310653@oss.qualcomm.com>
On 5/20/26 1:01 PM, Loic Poulain wrote:
> 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.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [Bug 221524] Intel 8265 Bluetooth regression (BLE hearing aid unusable) in kernel 6.12 vs 6.1
From: bugzilla-daemon @ 2026-05-22 9:06 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221524-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221524
Artem S. Tashkinov (aros@gmx.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |REJECTED
Resolution|--- |INSUFFICIENT_DATA
--
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
* [Bug 221481] btintel_pcie: suspend fails with -EBUSY on Intel Lunar Lake (s2idle)
From: bugzilla-daemon @ 2026-05-22 9:04 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221481-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221481
--- Comment #1 from Artem S. Tashkinov (aros@gmx.com) ---
Is this a regression? If it is, could you bisect?
https://docs.kernel.org/admin-guide/bug-bisect.html
--
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: [v1] obexd: fix PBAP PullPhoneBook failure with ebook backend
From: bluez.test.bot @ 2026-05-22 8:51 UTC (permalink / raw)
To: linux-bluetooth, zhiyuan.sheng
In-Reply-To: <20260522060312.1503481-1-zhiyuan.sheng@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 826 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=1099150
---Test result---
Test Summary:
CheckPatch PASS 0.49 seconds
GitLint PASS 0.34 seconds
BuildEll PASS 20.38 seconds
BluezMake PASS 679.47 seconds
CheckSmatch PASS 362.36 seconds
bluezmakeextell PASS 187.61 seconds
IncrementalBuild PASS 668.91 seconds
ScanBuild PASS 1076.15 seconds
https://github.com/bluez/bluez/pull/2145
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v1] profile: Set L2CAP IMTU for external profile listeners
From: bluez.test.bot @ 2026-05-22 8:37 UTC (permalink / raw)
To: linux-bluetooth, wei.deng
In-Reply-To: <20260522054015.431152-1-wei.deng@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 825 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=1099144
---Test result---
Test Summary:
CheckPatch PASS 0.39 seconds
GitLint PASS 0.28 seconds
BuildEll PASS 15.97 seconds
BluezMake PASS 489.53 seconds
CheckSmatch PASS 252.95 seconds
bluezmakeextell PASS 129.96 seconds
IncrementalBuild PASS 493.87 seconds
ScanBuild PASS 719.71 seconds
https://github.com/bluez/bluez/pull/2144
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [Bug 221552] btmtk: MT7921 (USB 0e8d:e020 / PCI 14c3:7920) Bluetooth broken since 7.0.7 - fix for 0489:e0e2 does not cover this PID
From: bugzilla-daemon @ 2026-05-22 8:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221552-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221552
Artem S. Tashkinov (aros@gmx.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution|--- |INSUFFICIENT_DATA
--
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
* [bluez/bluez] f00fac: obexd: fix PBAP PullPhoneBook failure with ebook b...
From: github-actions[bot] @ 2026-05-22 8:01 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1099150
Home: https://github.com/bluez/bluez
Commit: f00faca1eda199fb974b5c58a0011f9e86318954
https://github.com/bluez/bluez/commit/f00faca1eda199fb974b5c58a0011f9e86318954
Author: Zhiyuan Sheng <zhiyuan.sheng@oss.qualcomm.com>
Date: 2026-05-22 (Fri, 22 May 2026)
Changed paths:
M obexd/plugins/pbap.c
M obexd/plugins/phonebook-ebook.c
Log Message:
-----------
obexd: fix PBAP PullPhoneBook failure with ebook backend
phonebook_pull() in phonebook-ebook.c does not set *err = 0 on the
success path, unlike phonebook-tracker.c and phonebook-dummy.c. The
caller vobject_pull_open() in pbap.c declares 'ret' without
initialization and passes &ret to phonebook_pull(), so 'ret' retains
an indeterminate stack value when the ebook backend is in use. The
subsequent 'if (ret < 0)' check then incorrectly triggers and rejects
the request with Internal Server Error.
Fix this by setting *err = 0 on success in phonebook-ebook.c, and
initialize 'ret' to 0 in vobject_pull_open() as a defensive measure
to guard against any backend that omits this assignment.
Signed-off-by: Zhiyuan Sheng <zhiyuan.sheng@oss.qualcomm.com>
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 4756b9: profile: Set L2CAP IMTU for external profile liste...
From: github-actions[bot] @ 2026-05-22 8:01 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1099144
Home: https://github.com/bluez/bluez
Commit: 4756b963976b8c9c4406e0ee2e6a44c4f754a2cd
https://github.com/bluez/bluez/commit/4756b963976b8c9c4406e0ee2e6a44c4f754a2cd
Author: Wei Deng <wei.deng@oss.qualcomm.com>
Date: 2026-05-22 (Fri, 22 May 2026)
Changed paths:
M src/profile.c
Log Message:
-----------
profile: Set L2CAP IMTU for external profile listeners
bt_io_listen() in ext_start_servers() creates the L2CAP listening
socket for external profiles without an explicit IMTU, causing the
socket to default to the L2CAP minimum of 672 bytes. This is advertised
to the peer in L2CAP_CONFIGURATION_RSP and limits PDU size, degrading
Rx throughput.
The obexd client side (obexd/client/bluetooth.c) already sets IMTU to
BT_RX_MTU (32767) when connecting. Mirror that on the server side by
setting BT_IO_OPT_IMTU to 32767 in ext_start_servers().
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluetooth-next:master] BUILD SUCCESS 3c2c428f25e25d18a496d7b04926451cb03652aa
From: kernel test robot @ 2026-05-22 6:14 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git master
branch HEAD: 3c2c428f25e25d18a496d7b04926451cb03652aa Bluetooth: btusb: Allow firmware re-download when version matches
elapsed time: 866m
configs tested: 161
configs skipped: 12
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001 gcc-8.5.0
arc randconfig-001-20260522 gcc-9.5.0
arc randconfig-002 gcc-8.5.0
arc randconfig-002-20260522 gcc-8.5.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm defconfig clang-23
arm randconfig-001 gcc-8.5.0
arm randconfig-001-20260522 gcc-8.5.0
arm randconfig-002 gcc-11.5.0
arm randconfig-002-20260522 gcc-10.5.0
arm randconfig-003 clang-20
arm randconfig-003-20260522 gcc-11.5.0
arm randconfig-004 gcc-14.3.0
arm randconfig-004-20260522 clang-23
arm64 allmodconfig clang-19
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260522 clang-20
arm64 randconfig-002-20260522 gcc-14.3.0
arm64 randconfig-003-20260522 clang-23
arm64 randconfig-004-20260522 gcc-10.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260522 gcc-15.2.0
csky randconfig-002-20260522 gcc-15.2.0
hexagon allnoconfig clang-23
hexagon defconfig clang-23
hexagon randconfig-001-20260522 clang-23
hexagon randconfig-002-20260522 clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260522 clang-20
i386 buildonly-randconfig-002-20260522 gcc-14
i386 buildonly-randconfig-003-20260522 clang-20
i386 buildonly-randconfig-004-20260522 gcc-14
i386 buildonly-randconfig-005-20260522 clang-20
i386 buildonly-randconfig-006-20260522 gcc-13
i386 defconfig clang-20
i386 randconfig-001-20260522 gcc-14
i386 randconfig-002-20260522 clang-20
i386 randconfig-003-20260522 gcc-13
i386 randconfig-004-20260522 gcc-14
i386 randconfig-005-20260522 gcc-14
i386 randconfig-006-20260522 clang-20
i386 randconfig-007-20260522 gcc-13
i386 randconfig-011-20260522 gcc-14
i386 randconfig-012-20260522 clang-20
i386 randconfig-013-20260522 clang-20
i386 randconfig-014-20260522 gcc-14
i386 randconfig-015-20260522 clang-20
i386 randconfig-016-20260522 clang-20
i386 randconfig-017-20260522 gcc-14
loongarch allmodconfig clang-19
loongarch allnoconfig clang-23
loongarch defconfig clang-19
loongarch randconfig-001-20260522 clang-23
loongarch randconfig-002-20260522 gcc-15.2.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
m68k defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260522 gcc-8.5.0
nios2 randconfig-002-20260522 gcc-8.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260522 gcc-14.3.0
parisc randconfig-002-20260522 gcc-8.5.0
parisc64 defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260522 clang-20
powerpc randconfig-002-20260522 clang-18
powerpc warp_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260522 gcc-10.5.0
powerpc64 randconfig-002-20260522 gcc-12.5.0
riscv allmodconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig clang-23
riscv randconfig-001-20260522 clang-17
riscv randconfig-002-20260522 clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig clang-23
s390 randconfig-001-20260522 clang-23
s390 randconfig-002-20260522 clang-23
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-15.2.0
sh randconfig-001-20260522 gcc-10.5.0
sh randconfig-002-20260522 gcc-14.3.0
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260522 gcc-15.2.0
sparc randconfig-002-20260522 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 randconfig-001-20260522 gcc-14.3.0
sparc64 randconfig-002-20260522 gcc-12.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260522 clang-23
um randconfig-002-20260522 gcc-14
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260522 clang-20
x86_64 buildonly-randconfig-002-20260522 gcc-13
x86_64 buildonly-randconfig-003-20260522 gcc-14
x86_64 buildonly-randconfig-004-20260522 clang-20
x86_64 buildonly-randconfig-005-20260522 clang-20
x86_64 buildonly-randconfig-006-20260522 gcc-14
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260522 clang-20
x86_64 randconfig-002-20260522 clang-20
x86_64 randconfig-003-20260522 gcc-14
x86_64 randconfig-004-20260522 gcc-14
x86_64 randconfig-005-20260522 gcc-14
x86_64 randconfig-006-20260522 gcc-14
x86_64 randconfig-011-20260522 gcc-14
x86_64 randconfig-013-20260522 gcc-13
x86_64 randconfig-071-20260522 gcc-14
x86_64 randconfig-072-20260522 gcc-14
x86_64 randconfig-073-20260522 clang-20
x86_64 randconfig-074-20260522 gcc-14
x86_64 randconfig-075-20260522 clang-20
x86_64 randconfig-076-20260522 gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig gcc-15.2.0
xtensa randconfig-001-20260522 gcc-9.5.0
xtensa randconfig-002-20260522 gcc-11.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v1] obexd: fix PBAP PullPhoneBook failure with ebook backend
From: Zhiyuan Sheng @ 2026-05-22 6:03 UTC (permalink / raw)
To: linux-bluetooth; +Cc: cheng.jiang, shuai.zhang
phonebook_pull() in phonebook-ebook.c does not set *err = 0 on the
success path, unlike phonebook-tracker.c and phonebook-dummy.c. The
caller vobject_pull_open() in pbap.c declares 'ret' without
initialization and passes &ret to phonebook_pull(), so 'ret' retains
an indeterminate stack value when the ebook backend is in use. The
subsequent 'if (ret < 0)' check then incorrectly triggers and rejects
the request with Internal Server Error.
Fix this by setting *err = 0 on success in phonebook-ebook.c, and
initialize 'ret' to 0 in vobject_pull_open() as a defensive measure
to guard against any backend that omits this assignment.
Signed-off-by: Zhiyuan Sheng <zhiyuan.sheng@oss.qualcomm.com>
---
obexd/plugins/pbap.c | 2 +-
obexd/plugins/phonebook-ebook.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/obexd/plugins/pbap.c b/obexd/plugins/pbap.c
index 74976890d..9f8684863 100644
--- a/obexd/plugins/pbap.c
+++ b/obexd/plugins/pbap.c
@@ -661,7 +661,7 @@ static void *vobject_pull_open(const char *name, int oflag, mode_t mode,
{
struct pbap_session *pbap = context;
phonebook_cb cb;
- int ret;
+ int ret = 0;
void *request;
DBG("name %s context %p maxlistcount %d", name, context,
diff --git a/obexd/plugins/phonebook-ebook.c b/obexd/plugins/phonebook-ebook.c
index d772edca0..5fc0498c1 100644
--- a/obexd/plugins/phonebook-ebook.c
+++ b/obexd/plugins/phonebook-ebook.c
@@ -262,6 +262,9 @@ void *phonebook_pull(const char *name, const struct apparam_field *params,
data->query = e_book_query_to_string(query);
e_book_query_unref(query);
+ if (err)
+ *err = 0;
+
return data;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v1] profile: Set L2CAP IMTU for external profile listeners
From: Wei Deng @ 2026-05-22 5:40 UTC (permalink / raw)
To: linux-bluetooth
Cc: luiz.von.dentz, cheng.jiang, jinwang.li, shuai.zhang, wei.deng
bt_io_listen() in ext_start_servers() creates the L2CAP listening
socket for external profiles without an explicit IMTU, causing the
socket to default to the L2CAP minimum of 672 bytes. This is advertised
to the peer in L2CAP_CONFIGURATION_RSP and limits PDU size, degrading
Rx throughput.
The obexd client side (obexd/client/bluetooth.c) already sets IMTU to
BT_RX_MTU (32767) when connecting. Mirror that on the server side by
setting BT_IO_OPT_IMTU to 32767 in ext_start_servers().
Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
---
src/profile.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/profile.c b/src/profile.c
index dfc5f7161..297959f3c 100644
--- a/src/profile.c
+++ b/src/profile.c
@@ -55,6 +55,8 @@
#define MAS_DEFAULT_CHANNEL 16
#define MNS_DEFAULT_CHANNEL 17
+#define BT_RX_MTU 32767
+
#define BTD_PROFILE_PSM_AUTO -1
#define BTD_PROFILE_CHAN_AUTO -1
@@ -1411,6 +1413,7 @@ static uint32_t ext_start_servers(struct ext_profile *ext,
BT_IO_OPT_MODE, ext->mode,
BT_IO_OPT_PSM, psm,
BT_IO_OPT_SEC_LEVEL, ext->sec_level,
+ BT_IO_OPT_IMTU, BT_RX_MTU,
BT_IO_OPT_INVALID);
if (err != NULL) {
error("L2CAP server failed for %s: %s",
--
2.34.1
^ permalink raw reply related
* RE: [v3] Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp
From: bluez.test.bot @ 2026-05-21 20:48 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260521190332.3171234-1-luiz.dentz@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=1098993
---Test result---
Test Summary:
CheckPatch PASS 0.76 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint PASS 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 24.91 seconds
CheckAllWarning PASS 27.98 seconds
CheckSparse PASS 26.40 seconds
BuildKernel32 PASS 24.55 seconds
TestRunnerSetup PASS 529.10 seconds
TestRunner_l2cap-tester PASS 59.90 seconds
IncrementalBuild PASS 23.97 seconds
https://github.com/bluez/bluetooth-next/pull/232
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v4] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
From: bluez.test.bot @ 2026-05-21 19:08 UTC (permalink / raw)
To: linux-bluetooth, michael.bommarito
In-Reply-To: <20260521144518.1361335-1-michael.bommarito@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1747 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=1098859
---Test result---
Test Summary:
CheckPatch FAIL 1.00 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint PASS 0.35 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 27.44 seconds
CheckAllWarning PASS 29.96 seconds
CheckSparse PASS 28.91 seconds
BuildKernel32 PASS 28.26 seconds
TestRunnerSetup PASS 587.14 seconds
TestRunner_l2cap-tester PASS 59.17 seconds
IncrementalBuild PASS 25.06 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v4] Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig
WARNING: The commit message has 'stable@', perhaps it also needs a 'Fixes:' tag?
total: 0 errors, 1 warnings, 0 checks, 65 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/14587556.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.
https://github.com/bluez/bluetooth-next/pull/231
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH v3] Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp
From: Luiz Augusto von Dentz @ 2026-05-21 19:03 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
If dcid is received for an already-assigned destination CID the spec
requires that both channels to be discarded, but calling l2cap_chan_del
may invalidate the tmp cursor created by list_for_each_entry_safe and
in fact it is the wrong procedure as the chan->dcid may be assigned
previously it really needs to be disconnected.
Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so
instead schedule l2cap_chan_timeout with delay 0 to close the channel
asynchronously.
Fixes: 15f02b910562 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode")
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
net/bluetooth/l2cap_core.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 5668c92b3f58..5ae34bbcc5b2 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -5244,7 +5244,7 @@ static inline int l2cap_ecred_conn_rsp(struct l2cap_conn *conn,
struct l2cap_ecred_conn_rsp *rsp = (void *) data;
struct hci_conn *hcon = conn->hcon;
u16 mtu, mps, credits, result;
- struct l2cap_chan *chan, *tmp;
+ struct l2cap_chan *chan, *tmp, *orig = NULL;
int err = 0, sec_level;
int i = 0;
@@ -5264,7 +5264,7 @@ static inline int l2cap_ecred_conn_rsp(struct l2cap_conn *conn,
list_for_each_entry_safe(chan, tmp, &conn->chan_l, list) {
u16 dcid;
- if (chan->ident != cmd->ident ||
+ if (orig == chan || chan->ident != cmd->ident ||
chan->mode != L2CAP_MODE_EXT_FLOWCTL ||
chan->state == BT_CONNECTED)
continue;
@@ -5283,8 +5283,10 @@ static inline int l2cap_ecred_conn_rsp(struct l2cap_conn *conn,
BT_DBG("dcid[%d] 0x%4.4x", i, dcid);
+ orig = __l2cap_get_chan_by_dcid(conn, dcid);
+
/* Check if dcid is already in use */
- if (dcid && __l2cap_get_chan_by_dcid(conn, dcid)) {
+ if (dcid && orig) {
/* If a device receives a
* L2CAP_CREDIT_BASED_CONNECTION_RSP packet with an
* already-assigned Destination CID, then both the
@@ -5293,10 +5295,16 @@ static inline int l2cap_ecred_conn_rsp(struct l2cap_conn *conn,
*/
l2cap_chan_del(chan, ECONNREFUSED);
l2cap_chan_unlock(chan);
- chan = __l2cap_get_chan_by_dcid(conn, dcid);
- l2cap_chan_lock(chan);
- l2cap_chan_del(chan, ECONNRESET);
- l2cap_chan_unlock(chan);
+ l2cap_chan_lock(orig);
+ /* Disconnect the original channel as it may be
+ * considered connected since dcid has already been
+ * assigned; don't call l2cap_chan_close directly
+ * since that could lead to l2cap_chan_del and then
+ * removing the channel from the list while we're
+ * iterating over it.
+ */
+ __set_chan_timer(orig, 0);
+ l2cap_chan_unlock(orig);
continue;
}
--
2.53.0
^ permalink raw reply related
* [bluez/action-ci] 0be099: all: Fix "exit" typos
From: hadess @ 2026-05-21 18:47 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/main
Home: https://github.com/bluez/action-ci
Commit: 0be0998f89cd216d1b4d3461e583db3840832774
https://github.com/bluez/action-ci/commit/0be0998f89cd216d1b4d3461e583db3840832774
Author: Bastien Nocera <hadess@hadess.net>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M entrypoint.sh
M sync_repo.sh
Log Message:
-----------
all: Fix "exit" typos
Commit: 3dfee91519ae21d4828ed91b26a91f951cbef3f0
https://github.com/bluez/action-ci/commit/3dfee91519ae21d4828ed91b26a91f951cbef3f0
Author: Bastien Nocera <hadess@hadess.net>
Date: 2026-05-21 (Thu, 21 May 2026)
Changed paths:
M entrypoint.sh
M sync_repo.sh
Log Message:
-----------
*.sh: Fix double quote errors from shellcheck
Fix all double-quote warnings from shellcheck:
Double quote to prevent globbing and word splitting.
And add quotes in the "echo" calls that show how those commands are run.
Compare: https://github.com/bluez/action-ci/compare/9b6d3efc8435...3dfee91519ae
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/action-ci/settings/notifications
^ 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