* [PATCH BlueZ v2] adapter: Fix failed bonding attempt after LE link disconnection
From: Simon Mikuda @ 2026-06-10 8:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Simon Mikuda
In-Reply-To: <20260608111034.3684632-1-simon.mikuda@streamunlimited.com>
What happens when issue occurs:
- device is connected to both bearers BR/EDR and LE
- bonding is requested
- LE link disconnects
- pairing keys arrive
BlueZ would finish bonding request with error and mark device as
temporary. Then it would be disconnected+removed after default
temporary timeout (30 seconds).
---
src/adapter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/adapter.c b/src/adapter.c
index cc753fbd6..538f63e0a 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -8622,7 +8622,9 @@ static void dev_disconnected(struct btd_adapter *adapter,
disconnect_notify(device, reason);
}
- bonding_attempt_complete(adapter, &addr->bdaddr, addr->type,
+ /* device could be still connected to different bearer */
+ if (!device || !btd_device_is_connected(device))
+ bonding_attempt_complete(adapter, &addr->bdaddr, addr->type,
MGMT_STATUS_DISCONNECTED);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] Bluetooth: qca: Add BT FW build version to kernel log
From: Bartosz Golaszewski @ 2026-06-10 8:17 UTC (permalink / raw)
To: Xiuzhuo Shang
Cc: linux-arm-msm, linux-bluetooth, linux-kernel, cheng.jiang,
quic_chezhou, wei.deng, shuai.zhang, mengshi.wu, jinwang.li,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz
In-Reply-To: <c0eee7b4-50ee-4635-b8d6-fe9cb4ea05a8@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 9:36 AM Xiuzhuo Shang
<xiuzhuo.shang@oss.qualcomm.com> wrote:
>
> Hi Bart,
>
> The main change in v2 was the commit message — I added the motivation and an example log line as
>
> Paul requested on v1. Carrying your Acked-by (given on v1) forward was just to avoid losing it. So
>
> v2 wasn't sent solely to collect a tag.
>
Well, I don't know it because you didn't add a changelog to v2. Please
add something like "Changes in v2:" in the future.
Bartosz
^ permalink raw reply
* Re: [PATCH BlueZ] shared/bap: Transition ASE to QoS Configured on CIS loss
From: Simon Mikuda @ 2026-06-10 7:57 UTC (permalink / raw)
To: Pauli Virtanen, linux-bluetooth
In-Reply-To: <e89af328197d3fb429c08b7a3107d7fd8e05ac00.camel@iki.fi>
this check is for ep (struct bt_bap_endpoint) that is used only for
unicast. broadcasts use different state in struct bt_bap_stream, so it
should be OK
On 6/10/26 00:15, Pauli Virtanen wrote:
> ti, 2026-06-09 kello 23:11 +0200, Simon Mikuda kirjoitti:
>> stream_io_disconnected() only handled the Releasing state, leaving
>> Enabling, Streaming and Disabling ASEs stuck when the CIS was lost
>> unexpectedly. The ASE shall autonomously move to QoS Configured on loss
>> of the CIS and notify the peer; add that transition.
>>
>> Fixes PTS test BAP/USR/SCC/BV-167-C
>> ---
>> src/shared/bap.c | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/src/shared/bap.c b/src/shared/bap.c
>> index deb85b264..350ed53d9 100644
>> --- a/src/shared/bap.c
>> +++ b/src/shared/bap.c
>> @@ -6779,6 +6779,14 @@ static bool stream_io_disconnected(struct io *io, void *user_data)
>> if (stream->ep->state == BT_ASCS_ASE_STATE_RELEASING)
>> stream_set_state(stream, BT_BAP_STREAM_STATE_CONFIG);
>>
>> + /* On loss of the CIS the ASE shall autonomously transition to QoS
>> + * Configured and notify the peer.
>> + */
>> + if (stream->ep->state == BT_ASCS_ASE_STATE_STREAMING ||
>> + stream->ep->state == BT_ASCS_ASE_STATE_ENABLING ||
>> + stream->ep->state == BT_ASCS_ASE_STATE_DISABLING)
>> + stream_set_state(stream, BT_BAP_STREAM_STATE_QOS);
>> +
>> bt_bap_stream_set_io(stream, -1);
>> return false;
>> }
> iirc it may be also broadcast source here, does it do the right thing?
>
^ permalink raw reply
* Re: [PATCH BlueZ] shared/bap: Don't link ucast streams before CIS IDs are assigned
From: Simon Mikuda @ 2026-06-10 7:46 UTC (permalink / raw)
To: Pauli Virtanen, linux-bluetooth
In-Reply-To: <0744a915b7ea628647a17fa9aad0aa4365f83989.camel@iki.fi>
I looked into it and 0 is valid ID (probably not used, but still valid).
There is a ugly part in bluez though, when stream is allocated cig and
cis in qos struct are 0 not 0xff:
stream = new0(struct bt_bap_stream, 1); /* qos all-zero: cig/cis = 0 */
and also in tests there are some struct comparisons that also use
cig/cis == 0. Some parts check for 0xff (BT_ISO_QOS_CIG_UNSET,
BT_ISO_QOS_CIS_UNSET)
Maybe more clean fix would be to hook this up to state, so that when
CIG/CIS is not at least configured it is rejected e.g.:
if (stream->ep->state < BT_ASCS_ASE_STATE_QOS || link->ep->state <
BT_ASCS_ASE_STATE_QOS)
return -EINVAL;
Also probably i should cleanup all structs (code and tests), so that cig
and cis are initialized properly with 0xff. And then provide the fix?
On 6/10/26 00:03, Pauli Virtanen wrote:
> ti, 2026-06-09 kello 23:11 +0200, Simon Mikuda kirjoitti:
>> bap_ucast_io_link pairs streams whose CIG/CIS IDs match, but the IDs
>> are unset in Codec Configured state, so a Sink and Source bound for
>> different CISes get linked. The stray link later propagates a
>> disconnect to the wrong ASE and breaks Receiver Start Ready.
>>
>> Skip linking until QoS Configured assigns the IDs.
>>
>> Fixes PTS test BAP/USR/STR/BV-362-C
>> ---
>> src/shared/bap.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/src/shared/bap.c b/src/shared/bap.c
>> index deb85b264..98537de60 100644
>> --- a/src/shared/bap.c
>> +++ b/src/shared/bap.c
>> @@ -2679,6 +2679,12 @@ static int bap_ucast_io_link(struct bt_bap_stream *stream,
>> stream->ep->dir == link->ep->dir)
>> return -EINVAL;
>>
>> + /* Don't link until QoS Configured assigns the CIS IDs; while unset
>> + * the check above would pair unrelated streams.
>> + */
>> + if (!stream->qos.ucast.cis_id || !link->qos.ucast.cis_id)
>> + return -EINVAL;
> Zero is valid CIS ID?
>
>> +
>> if (stream->client && !(stream->locked && link->locked))
>> return -EINVAL;
>>
^ permalink raw reply
* Re: [PATCH v2 4/7] dt-bindings: bluetooth: qcom,wcn6855-bt: document WCN6851
From: Krzysztof Kozlowski @ 2026-06-10 7:41 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
Konrad Dybcio, Qiang Yu, Jeff Johnson, Liam Girdwood, Mark Brown,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pci, linux-kernel, linux-wireless, ath11k, devicetree,
Bartosz Golaszewski, linux-bluetooth, Bartosz Golaszewski
In-Reply-To: <20260608-sm8350-wifi-v2-4-efb68f1ff04c@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 09:59:22AM +0300, Dmitry Baryshkov wrote:
> WCN6851 is an earlier version of WCN6855 WiFi/BT chip, compatible with
> it. Add a device-specific compat string with the fallback to WCN6855
> one.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> .../devicetree/bindings/net/bluetooth/qcom,wcn6855-bt.yaml | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: qca: Add BT FW build version to kernel log
From: Xiuzhuo Shang @ 2026-06-10 7:36 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-arm-msm, linux-bluetooth, linux-kernel, cheng.jiang,
quic_chezhou, wei.deng, shuai.zhang, mengshi.wu, jinwang.li,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz
In-Reply-To: <CAMRc=MdojC6T1RuqRNE-ssoRw1pKyUHyOS9AD0ROfCpPPOqw1A@mail.gmail.com>
Hi Bart,
The main change in v2 was the commit message — I added the motivation and an example log line as
Paul requested on v1. Carrying your Acked-by (given on v1) forward was just to avoid losing it. So
v2 wasn't sent solely to collect a tag.
Thanks,
Xiuzhuo
On 6/10/2026 3:07 PM, Bartosz Golaszewski wrote:
> On Wed, 10 Jun 2026 08:42:32 +0200, Xiuzhuo Shang
> <xiuzhuo.shang@oss.qualcomm.com> said:
>> Firmware version is critical for bug triage. Users reporting issues
>> typically share dmesg output rather than debugfs contents, requiring
>> extra communication rounds to collect this information. Log the FW
>> build version directly to the kernel log so it is immediately
>> available in bug reports.
>>
>> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
>> ---
>
> Please don't send a new version if all you did is collected a single tag.
>
> Bart
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: net: wireless: qcom,ath10k: Document NVMEM cells
From: Krzysztof Kozlowski @ 2026-06-10 7:16 UTC (permalink / raw)
To: Loic Poulain
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Jens Axboe, Johannes Berg,
Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan, linux-mmc, devicetree,
linux-kernel, linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, Bartosz Golaszewski
In-Reply-To: <20260609-block-as-nvmem-v4-2-45712e6b22c6@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 09:52:27AM +0200, Loic Poulain wrote:
> Document the NVMEM cells supported by the ath10k driver, the
> mac-address, pre-calibration data, and calibration data.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> .../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index c21d66c7cd558ab792524be9afec8b79272d1c87..7391df5e7071e626af4c64b9919d48c41ac09f1e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -92,6 +92,22 @@ properties:
>
> ieee80211-freq-limit: true
>
> + nvmem-cells:
> + minItems: 1
> + maxItems: 3
> + description: |
If there is going to be resend:
Do not need '|' unless you need to preserve formatting.
> + References to nvmem cells for MAC address and/or calibration data.
> + Supported cell names are mac-address, calibration, and pre-calibration.
> +
> + nvmem-cell-names:
> + minItems: 1
> + maxItems: 3
> + items:
> + enum:
> + - mac-address
> + - calibration
> + - pre-calibration
This means you expect random order with variable number of items. Is
that intentional? If yes, please provide short explanation in the commit
msg.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: qca: Add BT FW build version to kernel log
From: Bartosz Golaszewski @ 2026-06-10 7:07 UTC (permalink / raw)
To: Xiuzhuo Shang
Cc: linux-arm-msm, linux-bluetooth, linux-kernel, cheng.jiang,
quic_chezhou, wei.deng, shuai.zhang, mengshi.wu, jinwang.li,
Bartosz Golaszewski, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz
In-Reply-To: <20260610064232.2385866-1-xiuzhuo.shang@oss.qualcomm.com>
On Wed, 10 Jun 2026 08:42:32 +0200, Xiuzhuo Shang
<xiuzhuo.shang@oss.qualcomm.com> said:
> Firmware version is critical for bug triage. Users reporting issues
> typically share dmesg output rather than debugfs contents, requiring
> extra communication rounds to collect this information. Log the FW
> build version directly to the kernel log so it is immediately
> available in bug reports.
>
> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
> ---
Please don't send a new version if all you did is collected a single tag.
Bart
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()
From: Sean Wang @ 2026-06-10 6:52 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Mark-yw Chen, Sean Wang,
Tomasz Figa, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek, stable
In-Reply-To: <20260609121329.1262170-1-senozhatsky@chromium.org>
Hi,
On Tue, Jun 9, 2026 at 7:19 AM Sergey Senozhatsky
<senozhatsky@chromium.org> wrote:
>
> Every once in a while we see a hung btmtksdio_flush() task:
>
> INFO: task kworker/u17:0:189 blocked for more than 122 seconds.
> __cancel_work_timer+0x3f4/0x460
> cancel_work_sync+0x1c/0x2c
> btmtksdio_flush+0x2c/0x40
> hci_dev_open_sync+0x10c4/0x2190
> [..]
>
> It all boils down to incorrect time_is_before_jiffies() usage in
> btmtksdio_txrx_work(). The btmtksdio_txrx_work() loop is expected
> to be terminated if running for longer than 5*HZ. However the
> timeout check is twisted: time_is_before_jiffies(old_jiffies + 5*HZ)
> evaluates to true when old_jiffies + 5*HZ is in the past i.e. when a
> timeout has occurred. Using OR with time_is_before_jiffies(txrx_timeout)
> means that:
> - before the 5-second timeout: the condition is `int_status || false`,
> so it loops as long as there are pending interrupts.
> - after the 5-second timeout: the condition becomes `int_status || true`,
> which is always true.
>
> When the loop becomes infinite btmtksdio_txrx_work() loop never
> terminates and never releases the SDIO host.
>
> Fix loop termination condition to actually enforce a 5*HZ timeout.
>
> Fixes: 26270bc189ea4 ("Bluetooth: btmtksdio: move interrupt service to work")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> ---
> drivers/bluetooth/btmtksdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btmtksdio.c b/drivers/bluetooth/btmtksdio.c
> index 5b0fab7b89b5..c6f80c419e90 100644
> --- a/drivers/bluetooth/btmtksdio.c
> +++ b/drivers/bluetooth/btmtksdio.c
> @@ -620,7 +620,7 @@ static void btmtksdio_txrx_work(struct work_struct *work)
> if (btmtksdio_rx_packet(bdev, rx_size) < 0)
> bdev->hdev->stat.err_rx++;
> }
> - } while (int_status || time_is_before_jiffies(txrx_timeout));
> + } while (int_status && time_is_after_jiffies(txrx_timeout));
yes, loop continues only while there is interrupt work and the timeout
deadline is still in the future
Reviewed-by: Sean Wang <sean.wang@mediatek.com>
Thanks for fixing this long-standing issue.
>
> /* Enable interrupt */
> if (bdev->func->irq_handler)
> --
> 2.54.0.1064.gd145956f57-goog
>
>
^ permalink raw reply
* [PATCH] Bluetooth: SCO: Fix use-after-free in sco_conn_ready() connect path
From: Sanghyun Park @ 2026-06-10 6:43 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, Luiz Augusto von Dentz
Cc: Sanghyun Park, linux-bluetooth, linux-kernel
sco_conn_ready() reads conn->sk without holding the connection lock or
taking a socket reference. A concurrent close() can detach and free that
socket before sco_conn_ready() calls lock_sock(sk), resulting in a
use-after-free.
Fix this by taking the connection lock and using sco_sock_hold() to read
conn->sk with a reference held before calling lock_sock(). Drop the
reference with sock_put() after releasing the socket lock.
Race:
CPU0 (hci_rx_work) CPU1 (userspace close)
============================ ==========================
sco_conn_ready(conn):
sk = conn->sk
close(sco_fd)
sco_sock_release()
sco_sock_close()
__sco_sock_close()
sco_chan_del()
conn->sk = NULL
sock_orphan()
sco_sock_kill()
sock_put(sk) -> frees sk
lock_sock(sk)
// UAF: sk may already be freed
Signed-off-by: Sanghyun Park <sanghyun.park.cnu@gmail.com>
---
net/bluetooth/sco.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 6383db54657..c2c4b5a5b82 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -1306,16 +1306,21 @@ static int sco_sock_release(struct socket *sock)
static void sco_conn_ready(struct sco_conn *conn)
{
struct sock *parent;
- struct sock *sk = conn->sk;
+ struct sock *sk;
BT_DBG("conn %p", conn);
+ sco_conn_lock(conn);
+ sk = sco_sock_hold(conn);
+ sco_conn_unlock(conn);
+
if (sk) {
lock_sock(sk);
sco_sock_clear_timer(sk);
sk->sk_state = BT_CONNECTED;
sk->sk_state_change(sk);
release_sock(sk);
+ sock_put(sk);
} else {
sco_conn_lock(conn);
--
2.48.1
^ permalink raw reply related
* [PATCH v2] Bluetooth: qca: Add BT FW build version to kernel log
From: Xiuzhuo Shang @ 2026-06-10 6:42 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, shuai.zhang, mengshi.wu, jinwang.li,
xiuzhuo.shang, Bartosz Golaszewski
In-Reply-To: <20260609075417.1160702-1-xiuzhuo.shang@oss.qualcomm.com>
Firmware version is critical for bug triage. Users reporting issues
typically share dmesg output rather than debugfs contents, requiring
extra communication rounds to collect this information. Log the FW
build version directly to the kernel log so it is immediately
available in bug reports.
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
---
Example output:
Bluetooth: hci0: QCA FW build version: BTFW.MOSELLE.1.1.3-00106-MSL_PATCHZ-1
drivers/bluetooth/btqca.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index dda76365726f..04ebe290bc78 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -143,6 +143,8 @@ static int qca_read_fw_build_info(struct hci_dev *hdev)
hci_set_fw_info(hdev, "%s", build_label);
+ bt_dev_info(hdev, "QCA FW build version: %s", build_label);
+
kfree(build_label);
out:
kfree_skb(skb);
--
2.43.0
^ permalink raw reply related
* [bluetooth-next:master] BUILD SUCCESS e5ea095d9bd1f3cf78d56f780d0f278f77663373
From: kernel test robot @ 2026-06-10 6:12 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: e5ea095d9bd1f3cf78d56f780d0f278f77663373 Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant
elapsed time: 766m
configs tested: 174
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-16.1.0
alpha allyesconfig gcc-16.1.0
alpha defconfig gcc-16.1.0
arc allmodconfig clang-23
arc allnoconfig gcc-16.1.0
arc allyesconfig clang-23
arc defconfig gcc-16.1.0
arc randconfig-001-20260610 gcc-8.5.0
arc randconfig-002-20260610 gcc-8.5.0
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260610 gcc-8.5.0
arm randconfig-002-20260610 gcc-8.5.0
arm randconfig-003-20260610 gcc-8.5.0
arm randconfig-004-20260610 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260610 gcc-11.5.0
arm64 randconfig-002-20260610 gcc-11.5.0
arm64 randconfig-003-20260610 gcc-11.5.0
arm64 randconfig-004-20260610 gcc-11.5.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260610 gcc-11.5.0
csky randconfig-002-20260610 gcc-11.5.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001-20260610 clang-22
hexagon randconfig-002-20260610 clang-22
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260610 gcc-14
i386 buildonly-randconfig-002-20260610 gcc-14
i386 buildonly-randconfig-003-20260610 gcc-14
i386 buildonly-randconfig-004-20260610 gcc-14
i386 buildonly-randconfig-005-20260610 gcc-14
i386 buildonly-randconfig-006-20260610 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260610 gcc-14
i386 randconfig-002-20260610 gcc-14
i386 randconfig-003-20260610 gcc-14
i386 randconfig-004-20260610 gcc-14
i386 randconfig-005-20260610 gcc-14
i386 randconfig-006-20260610 gcc-14
i386 randconfig-007-20260610 gcc-14
i386 randconfig-011-20260610 gcc-14
i386 randconfig-012-20260610 gcc-14
i386 randconfig-013-20260610 gcc-14
i386 randconfig-014-20260610 gcc-14
i386 randconfig-015-20260610 gcc-14
i386 randconfig-016-20260610 gcc-14
i386 randconfig-017-20260610 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001-20260610 clang-22
loongarch randconfig-002-20260610 clang-22
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
microblaze allnoconfig gcc-16.1.0
microblaze allyesconfig gcc-16.1.0
microblaze defconfig clang-23
mips allmodconfig gcc-16.1.0
mips allnoconfig gcc-16.1.0
mips allyesconfig gcc-16.1.0
nios2 allmodconfig clang-20
nios2 allnoconfig clang-23
nios2 defconfig clang-23
nios2 randconfig-001-20260610 clang-22
nios2 randconfig-002-20260610 clang-22
openrisc allmodconfig clang-20
openrisc allnoconfig clang-23
openrisc defconfig gcc-16.1.0
parisc allmodconfig gcc-16.1.0
parisc allnoconfig clang-23
parisc allyesconfig clang-17
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260610 gcc-8.5.0
parisc randconfig-002-20260610 gcc-8.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc microwatt_defconfig gcc-16.1.0
powerpc randconfig-001-20260610 gcc-8.5.0
powerpc randconfig-002-20260610 gcc-8.5.0
powerpc64 randconfig-001-20260610 gcc-8.5.0
powerpc64 randconfig-002-20260610 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001 gcc-16.1.0
riscv randconfig-001-20260610 gcc-16.1.0
riscv randconfig-002 gcc-16.1.0
riscv randconfig-002-20260610 gcc-16.1.0
s390 allmodconfig clang-17
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001 gcc-16.1.0
s390 randconfig-001-20260610 gcc-16.1.0
s390 randconfig-002 gcc-16.1.0
s390 randconfig-002-20260610 gcc-16.1.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh defconfig gcc-14
sh randconfig-001 gcc-16.1.0
sh randconfig-001-20260610 gcc-16.1.0
sh randconfig-002 gcc-16.1.0
sh randconfig-002-20260610 gcc-16.1.0
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260610 gcc-14.3.0
sparc randconfig-002-20260610 gcc-14.3.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260610 gcc-14.3.0
sparc64 randconfig-002-20260610 gcc-14.3.0
um allmodconfig clang-17
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260610 gcc-14.3.0
um randconfig-002-20260610 gcc-14.3.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-22
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-22
x86_64 buildonly-randconfig-001-20260610 gcc-14
x86_64 buildonly-randconfig-002-20260610 gcc-14
x86_64 buildonly-randconfig-003-20260610 gcc-14
x86_64 buildonly-randconfig-004-20260610 gcc-14
x86_64 buildonly-randconfig-005-20260610 gcc-14
x86_64 buildonly-randconfig-006-20260610 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001-20260610 gcc-13
x86_64 randconfig-002-20260610 gcc-13
x86_64 randconfig-003-20260610 gcc-13
x86_64 randconfig-004-20260610 gcc-13
x86_64 randconfig-005-20260610 gcc-13
x86_64 randconfig-006-20260610 gcc-13
x86_64 randconfig-011-20260610 gcc-14
x86_64 randconfig-012-20260610 gcc-14
x86_64 randconfig-013-20260610 gcc-14
x86_64 randconfig-014-20260610 gcc-14
x86_64 randconfig-015-20260610 gcc-14
x86_64 randconfig-016-20260610 gcc-14
x86_64 randconfig-071-20260610 gcc-14
x86_64 randconfig-072-20260610 gcc-14
x86_64 randconfig-073-20260610 gcc-14
x86_64 randconfig-074-20260610 gcc-14
x86_64 randconfig-075-20260610 gcc-14
x86_64 randconfig-076-20260610 gcc-14
x86_64 rhel-9.4 clang-22
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-22
x86_64 rhel-9.4-kselftests clang-22
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-22
xtensa allnoconfig clang-23
xtensa allyesconfig clang-20
xtensa randconfig-001-20260610 gcc-14.3.0
xtensa randconfig-002-20260610 gcc-14.3.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2] Bluetooth: SCO: Fix use-after-free on listening socket in sco_conn_ready()
From: Sanghyun Park @ 2026-06-10 6:08 UTC (permalink / raw)
To: marcel, johan.hedberg, luiz.dentz
Cc: Sanghyun Park, linux-bluetooth, linux-kernel
sco_conn_ready() calls sco_get_sock_listen() which returns a raw
pointer to a listening socket without taking a reference. After
releasing sco_sk_list.lock, a concurrent close() of the listening socket
can free it between the list lookup return and lock_sock(parent),
resulting in a use-after-free.
Fix by taking a reference with sock_hold() inside sco_get_sock_listen()
while the list lock is still held, and dropping it with sock_put() in
sco_conn_ready() after release_sock().
Race:
CPU0 (HCI event workqueue) CPU1 (userspace)
============================ ==========================
sco_conn_ready():
parent = sco_get_sock_listen()
// returns parent without a reference
close(listen_fd):
sco_sock_release()
sco_sock_kill()
sock_put(parent) -> frees parent
lock_sock(parent)
// UAF: parent may already be freed
Signed-off-by: Sanghyun Park <sanghyun.park.cnu@gmail.com>
---
Changes in v2:
- Move sock_hold() from sco_conn_ready() into sco_get_sock_listen() so
the reference is taken while sco_sk_list.lock is still held.
- Drop the verbose reproduction/KASAN text, personal note, and unverified
Fixes tag from the commit message.
- Fix whitespace damage.
net/bluetooth/sco.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 6383db54657..20518bbc93a 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -410,6 +410,11 @@ static struct sock *sco_get_sock_listen(bdaddr_t *src)
sk1 = sk;
}
+ if (sk)
+ sock_hold(sk);
+ else if (sk1)
+ sock_hold(sk1);
+
read_unlock(&sco_sk_list.lock);
return sk ? sk : sk1;
@@ -1336,6 +1341,7 @@ static void sco_conn_ready(struct sco_conn *conn)
BTPROTO_SCO, GFP_ATOMIC, 0);
if (!sk) {
release_sock(parent);
+ sock_put(parent);
sco_conn_unlock(conn);
return;
}
@@ -1357,6 +1363,7 @@ static void sco_conn_ready(struct sco_conn *conn)
parent->sk_data_ready(parent);
release_sock(parent);
+ sock_put(parent);
sco_conn_unlock(conn);
}
^ permalink raw reply related
* Re: [PATCH v1] Bluetooth: qca: Add BT FW build version log
From: Xiuzhuo Shang @ 2026-06-10 5:49 UTC (permalink / raw)
To: Paul Menzel, Bartosz Golaszewski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, linux-arm-msm,
linux-bluetooth, linux-kernel, cheng.jiang, quic_chezhou,
wei.deng, shuai.zhang, mengshi.wu, jinwang.li
In-Reply-To: <8697f148-5e21-44b4-a949-9d348e39c2ea@molgen.mpg.de>
Hi，Paul，
On 6/9/2026 6:29 PM, Paul Menzel wrote:
> Dear Xiuzhuo, dear Bartosz
>
>
> Am 09.06.26 um 11:39 schrieb Bartosz Golaszewski:
>> On Tue, 9 Jun 2026 09:54:17 +0200, Xiuzhuo Shang said:
>>> Printf BT FW build version log after BT FW downloaded.
>
> Please paste the new lines, so reviewers see how it is going to look like. Please also document a motivation (answering Why?).
Thanks for your suggestion, I will send PATCH v2.
>
>>> Signed-off-by: Xiuzhuo Shang <xiuzhuo.shang@oss.qualcomm.com>
>>> ---
>>> drivers/bluetooth/btqca.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
>>> index dda76365726f..04ebe290bc78 100644
>>> --- a/drivers/bluetooth/btqca.c
>>> +++ b/drivers/bluetooth/btqca.c
>>> @@ -143,6 +143,8 @@ static int qca_read_fw_build_info(struct hci_dev *hdev)
>>>
>>> hci_set_fw_info(hdev, "%s", build_label);
>>>
>>> + bt_dev_info(hdev, "QCA FW build version: %s", build_label);
>>> +
>>> kfree(build_label);
>>> out:
>>> kfree_skb(skb);
>>
>> This string can be read from debugfs, do we need an additional message in the
>> kernel log?
>
> In my opinion the firmware version should be part of the Linux logs, as that is what users share with bug reports, and you do not want to have several cycles collecting information. For example, currently for QCA6174 it’s currently:
>
> Bluetooth: hci0: QCA: patch rome 0x302 build 0x3e8, firmware rome 0x302 build 0x111
>
>
> Kind regards,
>
> Paul
>
>
> PS:
>
> ```
> $ sudo dmesg | grep -e ath10k -e Bluetooth
> [ 17.880668] ath10k_pci 0000:3a:00.0: enabling device (0000 -> 0002)
> [ 17.883428] ath10k_pci 0000:3a:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
> [ 18.138972] ath10k_pci 0000:3a:00.0: qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:1535
> [ 18.138977] ath10k_pci 0000:3a:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 0
> [ 18.139068] ath10k_pci 0000:3a:00.0: firmware ver WLAN.RM.4.4.1-00309- api 6 features wowlan,ignore-otp,mfp crc32 0793bcf2
> [ 18.206593] ath10k_pci 0000:3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
> [ 18.221145] Bluetooth: Core ver 2.22
> [ 18.221802] Bluetooth: HCI device and connection manager initialized
> [ 18.221807] Bluetooth: HCI socket layer initialized
> [ 18.221808] Bluetooth: L2CAP socket layer initialized
> [ 18.221813] Bluetooth: SCO socket layer initialized
> [ 18.258187] Bluetooth: hci0: using rampatch file: qca/rampatch_usb_00000302.bin
> [ 18.258192] Bluetooth: hci0: QCA: patch rome 0x302 build 0x3e8, firmware rome 0x302 build 0x111
> [ 18.301557] ath10k_pci 0000:3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
> [ 18.381567] ath10k_pci 0000:3a:00.0 wlp58s0: renamed from wlan0
> [ 18.619003] Bluetooth: hci0: using NVM file: qca/nvm_usb_00000302.bin
> [ 18.643646] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.
> ```
^ permalink raw reply
* RE: [BlueZ] avrcp: Abort continuing response on fragmented CT replies
From: bluez.test.bot @ 2026-06-09 23:06 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260609212656.3900190-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 989 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=1108830
---Test result---
Test Summary:
CheckPatch PASS 0.47 seconds
GitLint PASS 0.32 seconds
BuildEll PASS 20.54 seconds
BluezMake PASS 650.26 seconds
MakeCheck PASS 3.37 seconds
MakeDistcheck PASS 248.95 seconds
CheckValgrind PASS 225.60 seconds
CheckSmatch PASS 353.04 seconds
bluezmakeextell PASS 182.32 seconds
IncrementalBuild PASS 659.64 seconds
ScanBuild PASS 1039.95 seconds
https://github.com/bluez/bluez/pull/2211
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ] avdtp: Return correct error when SEP is inuse
From: bluez.test.bot @ 2026-06-09 23:06 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260609213013.3900808-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 989 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=1108834
---Test result---
Test Summary:
CheckPatch PASS 0.28 seconds
GitLint PASS 0.20 seconds
BuildEll PASS 20.53 seconds
BluezMake PASS 669.66 seconds
MakeCheck PASS 2.95 seconds
MakeDistcheck PASS 247.75 seconds
CheckValgrind PASS 228.75 seconds
CheckSmatch PASS 352.15 seconds
bluezmakeextell PASS 184.12 seconds
IncrementalBuild PASS 662.09 seconds
ScanBuild PASS 1053.81 seconds
https://github.com/bluez/bluez/pull/2212
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ] transport: Complete Acquire for Sink ASE entering Enabling
From: bluez.test.bot @ 2026-06-09 23:04 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260609211130.3887817-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 1600 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=1108826
---Test result---
Test Summary:
CheckPatch PASS 0.38 seconds
GitLint PASS 0.25 seconds
BuildEll PASS 18.46 seconds
BluezMake PASS 675.35 seconds
MakeCheck PASS 15.28 seconds
MakeDistcheck PASS 227.96 seconds
CheckValgrind PASS 260.62 seconds
CheckSmatch WARNING 315.70 seconds
bluezmakeextell PASS 170.28 seconds
IncrementalBuild PASS 665.24 seconds
ScanBuild PASS 938.94 seconds
Details
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structures
https://github.com/bluez/bluez/pull/2210
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ] shared/bap: Report invalid-length ASE CP write via notification
From: bluez.test.bot @ 2026-06-09 23:02 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260609211104.3887577-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 1600 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=1108823
---Test result---
Test Summary:
CheckPatch PASS 0.34 seconds
GitLint PASS 0.23 seconds
BuildEll PASS 18.69 seconds
BluezMake PASS 685.55 seconds
MakeCheck PASS 12.43 seconds
MakeDistcheck PASS 225.68 seconds
CheckValgrind PASS 256.41 seconds
CheckSmatch WARNING 313.77 seconds
bluezmakeextell PASS 167.62 seconds
IncrementalBuild PASS 619.95 seconds
ScanBuild PASS 919.45 seconds
Details
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structures
https://github.com/bluez/bluez/pull/2207
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ] shared/bap: Transition ASE to QoS Configured on CIS loss
From: bluez.test.bot @ 2026-06-09 23:02 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260609211120.3887737-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 1600 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=1108825
---Test result---
Test Summary:
CheckPatch PASS 0.45 seconds
GitLint PASS 0.48 seconds
BuildEll PASS 20.19 seconds
BluezMake PASS 625.65 seconds
MakeCheck PASS 12.74 seconds
MakeDistcheck PASS 236.69 seconds
CheckValgrind PASS 257.53 seconds
CheckSmatch WARNING 326.14 seconds
bluezmakeextell PASS 165.85 seconds
IncrementalBuild PASS 622.35 seconds
ScanBuild PASS 935.06 seconds
Details
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structures
https://github.com/bluez/bluez/pull/2209
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ] shared/bap: Don't link ucast streams before CIS IDs are assigned
From: bluez.test.bot @ 2026-06-09 23:00 UTC (permalink / raw)
To: linux-bluetooth, simon.mikuda
In-Reply-To: <20260609211111.3887657-1-simon.mikuda@streamunlimited.com>
[-- Attachment #1: Type: text/plain, Size: 1600 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=1108824
---Test result---
Test Summary:
CheckPatch PASS 0.46 seconds
GitLint PASS 0.33 seconds
BuildEll PASS 20.37 seconds
BluezMake PASS 601.20 seconds
MakeCheck PASS 12.72 seconds
MakeDistcheck PASS 233.39 seconds
CheckValgrind PASS 253.37 seconds
CheckSmatch WARNING 322.84 seconds
bluezmakeextell PASS 165.30 seconds
IncrementalBuild PASS 608.51 seconds
ScanBuild PASS 916.87 seconds
Details
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structuressrc/shared/bap.c:317:25: warning: array of flexible structuressrc/shared/bap.c: note: in included file:./src/shared/ascs.h:88:25: warning: array of flexible structures
https://github.com/bluez/bluez/pull/2208
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH BlueZ] shared/bap: Transition ASE to QoS Configured on CIS loss
From: Pauli Virtanen @ 2026-06-09 22:15 UTC (permalink / raw)
To: Simon Mikuda, linux-bluetooth
In-Reply-To: <20260609211120.3887737-1-simon.mikuda@streamunlimited.com>
ti, 2026-06-09 kello 23:11 +0200, Simon Mikuda kirjoitti:
> stream_io_disconnected() only handled the Releasing state, leaving
> Enabling, Streaming and Disabling ASEs stuck when the CIS was lost
> unexpectedly. The ASE shall autonomously move to QoS Configured on loss
> of the CIS and notify the peer; add that transition.
>
> Fixes PTS test BAP/USR/SCC/BV-167-C
> ---
> src/shared/bap.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/shared/bap.c b/src/shared/bap.c
> index deb85b264..350ed53d9 100644
> --- a/src/shared/bap.c
> +++ b/src/shared/bap.c
> @@ -6779,6 +6779,14 @@ static bool stream_io_disconnected(struct io *io, void *user_data)
> if (stream->ep->state == BT_ASCS_ASE_STATE_RELEASING)
> stream_set_state(stream, BT_BAP_STREAM_STATE_CONFIG);
>
> + /* On loss of the CIS the ASE shall autonomously transition to QoS
> + * Configured and notify the peer.
> + */
> + if (stream->ep->state == BT_ASCS_ASE_STATE_STREAMING ||
> + stream->ep->state == BT_ASCS_ASE_STATE_ENABLING ||
> + stream->ep->state == BT_ASCS_ASE_STATE_DISABLING)
> + stream_set_state(stream, BT_BAP_STREAM_STATE_QOS);
> +
> bt_bap_stream_set_io(stream, -1);
> return false;
> }
iirc it may be also broadcast source here, does it do the right thing?
--
Pauli Virtanen
^ permalink raw reply
* [bluez/bluez] da2011: avdtp: Return correct error when SEP is inuse
From: Šimon Mikuda @ 2026-06-09 22:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1108834
Home: https://github.com/bluez/bluez
Commit: da201148e7a288e2568a1822d55c69d932b77672
https://github.com/bluez/bluez/commit/da201148e7a288e2568a1822d55c69d932b77672
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-09 (Tue, 09 Jun 2026)
Changed paths:
M profiles/audio/avdtp.c
Log Message:
-----------
avdtp: Return correct error when SEP is inuse
This fixes AVDTP/SNK/ACP/SIG/SMG/BI-08-C
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 029590: avrcp: Abort continuing response on fragmented CT ...
From: Šimon Mikuda @ 2026-06-09 22:08 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1108830
Home: https://github.com/bluez/bluez
Commit: 029590df103af1e37e72c3936604e23829155036
https://github.com/bluez/bluez/commit/029590df103af1e37e72c3936604e23829155036
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-09 (Tue, 09 Jun 2026)
Changed paths:
M profiles/audio/avrcp.c
Log Message:
-----------
avrcp: Abort continuing response on fragmented CT replies
Send AbortContinuingResponse when a Get Element Attributes reply
arrives fragmented, as the CT side does not reassemble fragments.
Fixes PTS test AVRCP/CT/RCR/BV-03-C
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 95d160: transport: Complete Acquire for Sink ASE entering ...
From: Šimon Mikuda @ 2026-06-09 22:07 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1108826
Home: https://github.com/bluez/bluez
Commit: 95d16025c92d0a67f5b3886ad18bb80a6efeee31
https://github.com/bluez/bluez/commit/95d16025c92d0a67f5b3886ad18bb80a6efeee31
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-09 (Tue, 09 Jun 2026)
Changed paths:
M profiles/audio/transport.c
M src/shared/bap.c
Log Message:
-----------
transport: Complete Acquire for Sink ASE entering Enabling
On the QoS to Enabling transition the IO is not yet available because
the CIS is not established, so the handler returns early and a pending
Acquire is left unanswered once the IO later arrives.
Notify the connecting callbacks once the fd is attached so the
transport can re-run the Enabling handling and complete the Acquire.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 0aee36: shared/bap: Transition ASE to QoS Configured on CI...
From: Šimon Mikuda @ 2026-06-09 22:07 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1108825
Home: https://github.com/bluez/bluez
Commit: 0aee365bc6f29c2b2625b8ec057de32f1bbe2420
https://github.com/bluez/bluez/commit/0aee365bc6f29c2b2625b8ec057de32f1bbe2420
Author: Simon Mikuda <simon.mikuda@streamunlimited.com>
Date: 2026-06-09 (Tue, 09 Jun 2026)
Changed paths:
M src/shared/bap.c
Log Message:
-----------
shared/bap: Transition ASE to QoS Configured on CIS loss
stream_io_disconnected() only handled the Releasing state, leaving
Enabling, Streaming and Disabling ASEs stuck when the CIS was lost
unexpectedly. The ASE shall autonomously move to QoS Configured on loss
of the CIS and notify the peer; add that transition.
Fixes PTS test BAP/USR/SCC/BV-167-C
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/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