* RE: Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()
From: bluez.test.bot @ 2026-05-29 18:21 UTC (permalink / raw)
To: linux-bluetooth, oss
In-Reply-To: <20260529165449.3553936-2-oss@fourdim.xyz>
[-- Attachment #1: Type: text/plain, Size: 11948 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=1103029
---Test result---
Test Summary:
CheckPatch PASS 1.68 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint PASS 0.35 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.47 seconds
CheckAllWarning PASS 27.77 seconds
CheckSparse PASS 26.54 seconds
BuildKernel32 PASS 24.52 seconds
TestRunnerSetup PASS 530.14 seconds
TestRunner_l2cap-tester FAIL 55.83 seconds
TestRunner_smp-tester FAIL 23.82 seconds
TestRunner_6lowpan-tester FAIL 22.93 seconds
IncrementalBuild PASS 25.60 seconds
Details
##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:
WARNING: held lock freed!
7.1.0-rc1-g5f2fcd0833d0 #1 Not tainted
-------------------------
memcheck-amd64-/34 is freeing memory ffff888002762000-ffff8880027627ff, with a lock still held there!
ffff888002762508 (&chan->lock#4){+.+.}-{4:4}, at: l2cap_conn_del+0x33b/0x660
5 locks held by memcheck-amd64-/34:
#0: ffff8880026e0e80 (&hdev->req_lock){+.+.}-{4:4}, at: hci_dev_do_close+0x5d/0x90
#1: ffff8880026e00b0 (&hdev->lock){+.+.}-{4:4}, at: hci_dev_close_sync+0x2ca/0xfa0
#2: ffffffffb92bc278 (hci_cb_list_lock){+.+.}-{4:4}, at: hci_conn_hash_flush+0xed/0x230
#3: ffff8880022ec2f0 (&conn->lock){+.+.}-{4:4}, at: l2cap_conn_del+0x9b/0x660
#4: ffff888002762508 (&chan->lock#4){+.+.}-{4:4}, at: l2cap_conn_del+0x33b/0x660
stack backtrace:
CPU: 0 UID: 0 PID: 34 Comm: memcheck-amd64- Not tainted 7.1.0-rc1-g5f2fcd0833d0 #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
debug_check_no_locks_freed+0x102/0x140
? l2cap_chan_del+0x220/0x770
kfree+0x22b/0x4c0
? _raw_write_unlock+0x1e/0x40
l2cap_chan_del+0x220/0x770
l2cap_conn_del+0x346/0x660
hci_conn_hash_flush+0x135/0x230
hci_dev_close_sync+0x4f8/0xfa0
hci_dev_do_close+0x65/0x90
hci_unregister_dev+0x254/0x510
vhci_release+0x183/0x240
__fput+0x356/0x9c0
? lock_is_held_type+0x9b/0x110
fput_close_sync+0xd6/0x180
? __pfx_fput_close_sync+0x10/0x10
__x64_sys_close+0x78/0xd0
do_syscall_64+0x9f/0x560
entry_SYSCALL_64_after_hwframe+0x74/0x7c
RIP: 0033:0x5805ccc9
Code: 00 e8 eb a4 fe ff 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <c3> 66 0f 1f 44 00 00 f3 0f 1e fa 8d 87 ff 0f 00 00 89 fa 89 ff 3d
RSP: 002b:0000001002db9d08 EFLAGS: 00000206 ORIG_RAX: 0000000000000003
RAX: ffffffffffffffda RBX: 0000001002386d90 RCX: 000000005805ccc9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007
...
BUG: KASAN: slab-use-after-free in l2cap_chan_del+0x6ee/0x770
Write of size 8 at addr ffff888002762000 by task memcheck-amd64-/34
CPU: 0 UID: 0 PID: 34 Comm: memcheck-amd64- Not tainted 7.1.0-rc1-g5f2fcd0833d0 #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
print_report+0x108/0x5c0
? __virt_addr_valid+0x21c/0x3f0
? l2cap_chan_del+0x6ee/0x770
kasan_report+0x94/0xc0
? l2cap_chan_del+0x6ee/0x770
l2cap_chan_del+0x6ee/0x770
l2cap_conn_del+0x346/0x660
hci_conn_hash_flush+0x135/0x230
hci_dev_close_sync+0x4f8/0xfa0
hci_dev_do_close+0x65/0x90
hci_unregister_dev+0x254/0x510
vhci_release+0x183/0x240
__fput+0x356/0x9c0
? lock_is_held_type+0x9b/0x110
fput_close_sync+0xd6/0x180
? __pfx_fput_close_sync+0x10/0x10
__x64_sys_close+0x78/0xd0
do_syscall_64+0x9f/0x560
entry_SYSCALL_64_after_hwframe+0x74/0x7c
RIP: 0033:0x5805ccc9
Code: 00 e8 eb a4 fe ff 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <c3> 66 0f 1f 44 00 00 f3 0f 1e fa 8d 87 ff 0f 00 00 89 fa 89 ff 3d
RSP: 002b:0000001002db9d08 EFLAGS: 00000206 ORIG_RAX: 0000000000000003
RAX: ffffffffffffffda RBX: 0000001002386d90 RCX: 000000005805ccc9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007
RBP: 0000000000000001 R08: 0000000005229e80 R09: 0000000000000040
R10: 00000000000002fa R11: 0000000000000206 R12: 0000001002386e20
R13: 0000001002008360 R14: 0000000000000003 R15: 0000001002db9d70
Total: 96, Passed: 96 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_smp-tester - FAIL
Desc: Run smp-tester with test-runner
Output:
WARNING: held lock freed!
7.1.0-rc1-g5f2fcd0833d0 #1 Not tainted
-------------------------
memcheck-amd64-/34 is freeing memory ffff8880021b6000-ffff8880021b67ff, with a lock still held there!
ffff8880021b6508 (&chan->lock#3){+.+.}-{4:4}, at: l2cap_conn_del+0x33b/0x660
5 locks held by memcheck-amd64-/34:
#0: ffff8880024e4e80 (&hdev->req_lock){+.+.}-{4:4}, at: hci_dev_do_close+0x5d/0x90
#1: ffff8880024e40b0 (&hdev->lock){+.+.}-{4:4}, at: hci_dev_close_sync+0x2ca/0xfa0
#2: ffffffffb6ebc278 (hci_cb_list_lock){+.+.}-{4:4}, at: hci_conn_hash_flush+0xed/0x230
#3: ffff8880022fb2f0 (&conn->lock){+.+.}-{4:4}, at: l2cap_conn_del+0x9b/0x660
#4: ffff8880021b6508 (&chan->lock#3){+.+.}-{4:4}, at: l2cap_conn_del+0x33b/0x660
stack backtrace:
CPU: 0 UID: 0 PID: 34 Comm: memcheck-amd64- Not tainted 7.1.0-rc1-g5f2fcd0833d0 #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
debug_check_no_locks_freed+0x102/0x140
? l2cap_chan_del+0x220/0x770
kfree+0x22b/0x4c0
? _raw_write_unlock+0x1e/0x40
l2cap_chan_del+0x220/0x770
l2cap_conn_del+0x346/0x660
hci_conn_hash_flush+0x135/0x230
hci_dev_close_sync+0x4f8/0xfa0
hci_dev_do_close+0x65/0x90
hci_unregister_dev+0x254/0x510
vhci_release+0x183/0x240
__fput+0x356/0x9c0
? lock_is_held_type+0x9b/0x110
fput_close_sync+0xd6/0x180
? __pfx_fput_close_sync+0x10/0x10
__x64_sys_close+0x78/0xd0
do_syscall_64+0x9f/0x560
entry_SYSCALL_64_after_hwframe+0x74/0x7c
RIP: 0033:0x5805ccc9
Code: 00 e8 eb a4 fe ff 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <c3> 66 0f 1f 44 00 00 f3 0f 1e fa 8d 87 ff 0f 00 00 89 fa 89 ff 3d
RSP: 002b:0000001002db5d08 EFLAGS: 00000206 ORIG_RAX: 0000000000000003
RAX: ffffffffffffffda RBX: 0000001002386d90 RCX: 000000005805ccc9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000000a
...
BUG: KASAN: slab-use-after-free in l2cap_chan_del+0x6ee/0x770
Write of size 8 at addr ffff8880021b6000 by task memcheck-amd64-/34
CPU: 0 UID: 0 PID: 34 Comm: memcheck-amd64- Not tainted 7.1.0-rc1-g5f2fcd0833d0 #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
print_report+0x108/0x5c0
? __virt_addr_valid+0x21c/0x3f0
? l2cap_chan_del+0x6ee/0x770
kasan_report+0x94/0xc0
? l2cap_chan_del+0x6ee/0x770
l2cap_chan_del+0x6ee/0x770
l2cap_conn_del+0x346/0x660
hci_conn_hash_flush+0x135/0x230
hci_dev_close_sync+0x4f8/0xfa0
hci_dev_do_close+0x65/0x90
hci_unregister_dev+0x254/0x510
vhci_release+0x183/0x240
__fput+0x356/0x9c0
? lock_is_held_type+0x9b/0x110
fput_close_sync+0xd6/0x180
? __pfx_fput_close_sync+0x10/0x10
__x64_sys_close+0x78/0xd0
do_syscall_64+0x9f/0x560
entry_SYSCALL_64_after_hwframe+0x74/0x7c
RIP: 0033:0x5805ccc9
Code: 00 e8 eb a4 fe ff 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <c3> 66 0f 1f 44 00 00 f3 0f 1e fa 8d 87 ff 0f 00 00 89 fa 89 ff 3d
RSP: 002b:0000001002db5d08 EFLAGS: 00000206 ORIG_RAX: 0000000000000003
RAX: ffffffffffffffda RBX: 0000001002386d90 RCX: 000000005805ccc9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000000a
RBP: 0000000000000001 R08: 0000000004c198e0 R09: 0000000000000040
R10: 0000000000000002 R11: 0000000000000206 R12: 0000001002386e20
R13: 0000001002008360 R14: 0000000000000003 R15: 0000001002db5d70
Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_6lowpan-tester - FAIL
Desc: Run 6lowpan-tester with test-runner
Output:
WARNING: held lock freed!
7.1.0-rc1-g5f2fcd0833d0 #1 Not tainted
-------------------------
memcheck-amd64-/34 is freeing memory ffff8880026af000-ffff8880026af7ff, with a lock still held there!
ffff8880026af508 (&chan->lock#4){+.+.}-{4:4}, at: l2cap_conn_del+0x33b/0x660
5 locks held by memcheck-amd64-/34:
#0: ffff8880025ece80 (&hdev->req_lock){+.+.}-{4:4}, at: hci_dev_do_close+0x5d/0x90
#1: ffff8880025ec0b0 (&hdev->lock){+.+.}-{4:4}, at: hci_dev_close_sync+0x2ca/0xfa0
#2: ffffffff84ebc278 (hci_cb_list_lock){+.+.}-{4:4}, at: hci_conn_hash_flush+0xed/0x230
#3: ffff888001fcbaf0 (&conn->lock){+.+.}-{4:4}, at: l2cap_conn_del+0x9b/0x660
#4: ffff8880026af508 (&chan->lock#4){+.+.}-{4:4}, at: l2cap_conn_del+0x33b/0x660
stack backtrace:
CPU: 0 UID: 0 PID: 34 Comm: memcheck-amd64- Not tainted 7.1.0-rc1-g5f2fcd0833d0 #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
debug_check_no_locks_freed+0x102/0x140
? l2cap_chan_del+0x220/0x770
kfree+0x22b/0x4c0
? _raw_write_unlock+0x1e/0x40
l2cap_chan_del+0x220/0x770
l2cap_conn_del+0x346/0x660
hci_conn_hash_flush+0x135/0x230
hci_dev_close_sync+0x4f8/0xfa0
hci_dev_do_close+0x65/0x90
hci_unregister_dev+0x254/0x510
vhci_release+0x183/0x240
__fput+0x356/0x9c0
? lock_is_held_type+0x9b/0x110
fput_close_sync+0xd6/0x180
? __pfx_fput_close_sync+0x10/0x10
__x64_sys_close+0x78/0xd0
do_syscall_64+0x9f/0x560
entry_SYSCALL_64_after_hwframe+0x74/0x7c
RIP: 0033:0x5805ccc9
Code: 00 e8 eb a4 fe ff 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <c3> 66 0f 1f 44 00 00 f3 0f 1e fa 8d 87 ff 0f 00 00 89 fa 89 ff 3d
RSP: 002b:0000001002cb5d08 EFLAGS: 00000206 ORIG_RAX: 0000000000000003
RAX: ffffffffffffffda RBX: 0000001002386d90 RCX: 000000005805ccc9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007
...
BUG: KASAN: slab-use-after-free in l2cap_chan_del+0x6ee/0x770
Write of size 8 at addr ffff8880026af000 by task memcheck-amd64-/34
CPU: 0 UID: 0 PID: 34 Comm: memcheck-amd64- Not tainted 7.1.0-rc1-g5f2fcd0833d0 #1 PREEMPT(lazy)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
<TASK>
print_report+0x108/0x5c0
? __virt_addr_valid+0x21c/0x3f0
? l2cap_chan_del+0x6ee/0x770
kasan_report+0x94/0xc0
? l2cap_chan_del+0x6ee/0x770
l2cap_chan_del+0x6ee/0x770
l2cap_conn_del+0x346/0x660
hci_conn_hash_flush+0x135/0x230
hci_dev_close_sync+0x4f8/0xfa0
hci_dev_do_close+0x65/0x90
hci_unregister_dev+0x254/0x510
vhci_release+0x183/0x240
__fput+0x356/0x9c0
? lock_is_held_type+0x9b/0x110
fput_close_sync+0xd6/0x180
? __pfx_fput_close_sync+0x10/0x10
__x64_sys_close+0x78/0xd0
do_syscall_64+0x9f/0x560
entry_SYSCALL_64_after_hwframe+0x74/0x7c
RIP: 0033:0x5805ccc9
Code: 00 e8 eb a4 fe ff 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <c3> 66 0f 1f 44 00 00 f3 0f 1e fa 8d 87 ff 0f 00 00 89 fa 89 ff 3d
RSP: 002b:0000001002cb5d08 EFLAGS: 00000206 ORIG_RAX: 0000000000000003
RAX: ffffffffffffffda RBX: 0000001002386d90 RCX: 000000005805ccc9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007
RBP: 0000000000000001 R08: 0000000004c205f0 R09: 0000000000000040
R10: 0000000000000002 R11: 0000000000000206 R12: 0000001002386e20
R13: 0000001002008360 R14: 0000000000000003 R15: 0000001002cb5d70
Total: 8, Passed: 8 (100.0%), Failed: 0, Not Run: 0
https://github.com/bluez/bluetooth-next/pull/256
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: Bluetooth: Fix data-race on dst/src in connect paths
From: bluez.test.bot @ 2026-05-29 18:23 UTC (permalink / raw)
To: linux-bluetooth, suunj1331
In-Reply-To: <20260529173347.43967-2-suunj1331@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3376 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=1103047
---Test result---
Test Summary:
CheckPatch FAIL 2.45 seconds
VerifyFixes PASS 0.13 seconds
VerifySignedoff PASS 0.13 seconds
GitLint FAIL 0.67 seconds
SubjectPrefix PASS 0.25 seconds
BuildKernel PASS 27.00 seconds
CheckAllWarning PASS 29.72 seconds
CheckSparse PASS 29.31 seconds
BuildKernel32 PASS 27.06 seconds
TestRunnerSetup PASS 556.66 seconds
TestRunner_iso-tester PASS 85.01 seconds
TestRunner_sco-tester PASS 34.65 seconds
IncrementalBuild PASS 27.62 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v1,1/2] Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#118:
race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1:
total: 0 errors, 1 warnings, 0 checks, 91 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/14601826.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.
[v1,2/2] Bluetooth: SCO: Fix data-race on dst in sco_connect
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#119:
race at unknown origin, with read to 0xffff88800e6b0dd0 of 1 bytes by task 315 on cpu 0:
WARNING: Please use correct Fixes: style 'Fixes: <12+ chars of sha1> ("<title line>")' - ie: 'Fixes: 9a8ec9e8ebb5 ("Bluetooth: SCO: Fix possible circular locking dependency on sco_connect_cfm")'
#131:
Fixes: 9a8ec9e8ebb5 ("Bluetooth: Fix three socket race condition bugs in sco.c")
total: 0 errors, 2 warnings, 0 checks, 26 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/14601827.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:
[v1,1/2] Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls
16: B1 Line exceeds max length (88>80): "race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1:"
[v1,2/2] Bluetooth: SCO: Fix data-race on dst in sco_connect
18: B1 Line exceeds max length (88>80): "race at unknown origin, with read to 0xffff88800e6b0dd0 of 1 bytes by task 315 on cpu 0:"
https://github.com/bluez/bluetooth-next/pull/257
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [v2] Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV
From: Paul Menzel @ 2026-05-29 18:25 UTC (permalink / raw)
To: Nils Helmig; +Cc: linux-bluetooth, marcel, luiz.dentz
In-Reply-To: <20260529133824.5835-1-nils.helmig@web.de>
Dear Nils,
Am 29.05.26 um 15:38 schrieb Nils Helmig:
> I saw that the merge request https://github.com/bluez/bluetooth-next/
> pull/127 is closed. Any news on this patch? Is there anything I
> should do?
I think you need to resend, as the state in patchwork in *New, archived*
[1].
Kind regards,
Paul
[1]:
https://patchwork.kernel.org/project/bluetooth/patch/20260425185659.13133-1-nils.helmig@web.de/
^ permalink raw reply
* Re: [GIT PULL] bluetooth 2026-05-28
From: Luiz Augusto von Dentz @ 2026-05-29 18:38 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Paolo Abeni, davem, linux-bluetooth, netdev
In-Reply-To: <20260529112024.2c0d2c51@kernel.org>
Hi Jakub,
On Fri, May 29, 2026 at 2:20 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 29 May 2026 09:35:20 +0200 Paolo Abeni wrote:
> > Even multiple PRs per week makes sense to me, if the average size is
> > still significant. I'm not sure about others maintainers opinion, please
> > don't take my last statement as "a please go ahead with this" before
> > more acks.
>
> That's a pretty costly fix. It takes me ~3h to generate the PR I suspect
> it takes you similar amount of time. So it's not going to help the
> patch review queue if we waste time generating multiple PRs.
>
> Luiz, simply run this bash script before you send the PR:
>
> github.com/linux-netdev/nipa/blob/master/tests/patch/verify_signedoff/verify_signedoff.sh
>
> it's not the first time you're missing SoBs
Ive already integrated it our CI:
https://github.com/bluez/action-ci/commit/c1b86bca7cacc936bea82b3ca8b2ee4b4fcb6e74
https://github.com/bluez/bluetooth-next/pull/257/checks?check_run_id=78559358818
I might be missing a local hook though, in this case it seems my SoB
was missing, maybe I could configure git am to always adds SoBs, that
said we don't use that on userspace portion of the stack.
--
Luiz Augusto von Dentz
^ permalink raw reply
* RE: [1/4] dt-bindings: bluetooth: qcom,qcc2072-bt: add bindings for QCC2072
From: bluez.test.bot @ 2026-05-29 20:29 UTC (permalink / raw)
To: linux-bluetooth, yepuri.siddu
In-Reply-To: <20260529175342.3363935-1-yepuri.siddu@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 2158 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=1103053
---Test result---
Test Summary:
CheckPatch FAIL 3.60 seconds
VerifyFixes PASS 4.63 seconds
VerifySignedoff PASS 0.72 seconds
GitLint FAIL 1.64 seconds
SubjectPrefix FAIL 0.44 seconds
BuildKernel PASS 25.11 seconds
CheckAllWarning PASS 28.10 seconds
CheckSparse PASS 26.48 seconds
BuildKernel32 PASS 24.42 seconds
TestRunnerSetup PASS 526.63 seconds
IncrementalBuild PASS 28.03 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[1/4] dt-bindings: bluetooth: qcom,qcc2072-bt: add bindings for QCC2072
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#176:
new file mode 100644
total: 0 errors, 1 warnings, 38 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/14601841.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:
[1/4] dt-bindings: bluetooth: qcom,qcc2072-bt: add bindings for QCC2072
15: B1 Line exceeds max length (88>80): " create mode 100644 Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml"
##############################
Test: SubjectPrefix - FAIL
Desc: Check subject contains "Bluetooth" prefix
Output:
"Bluetooth: " prefix is not specified in the subject
https://github.com/bluez/bluetooth-next/pull/258
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluetooth-next:master] BUILD SUCCESS 379b101059b44f64f6c5c022724f880a68fed15b
From: kernel test robot @ 2026-05-30 11:26 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: 379b101059b44f64f6c5c022724f880a68fed15b Bluetooth: bnep: reject short frames before parsing
elapsed time: 1170m
configs tested: 190
configs skipped: 3
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 clang-16
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260530 gcc-14.3.0
arc randconfig-002-20260530 gcc-14.3.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm allyesconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm randconfig-001-20260530 gcc-14.3.0
arm randconfig-002-20260530 gcc-14.3.0
arm randconfig-003-20260530 gcc-14.3.0
arm randconfig-004-20260530 gcc-14.3.0
arm rpc_defconfig clang-18
arm64 allmodconfig clang-19
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260530 gcc-8.5.0
arm64 randconfig-002-20260530 gcc-8.5.0
arm64 randconfig-003-20260530 gcc-8.5.0
arm64 randconfig-004-20260530 gcc-8.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260530 gcc-8.5.0
csky randconfig-002-20260530 gcc-8.5.0
hexagon allmodconfig clang-17
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260530 clang-23
hexagon randconfig-002-20260530 clang-23
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260530 clang-20
i386 buildonly-randconfig-002-20260530 clang-20
i386 buildonly-randconfig-003-20260530 clang-20
i386 buildonly-randconfig-004-20260530 clang-20
i386 buildonly-randconfig-005-20260530 clang-20
i386 buildonly-randconfig-006-20260530 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260530 clang-20
i386 randconfig-002-20260530 clang-20
i386 randconfig-003-20260530 clang-20
i386 randconfig-004-20260530 clang-20
i386 randconfig-005-20260530 clang-20
i386 randconfig-006-20260530 clang-20
i386 randconfig-007-20260530 clang-20
i386 randconfig-011-20260530 clang-20
i386 randconfig-012-20260530 clang-20
i386 randconfig-013-20260530 clang-20
i386 randconfig-014-20260530 clang-20
i386 randconfig-015-20260530 clang-20
i386 randconfig-016-20260530 clang-20
i386 randconfig-017-20260530 clang-20
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260530 clang-23
loongarch randconfig-002-20260530 clang-23
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k allyesconfig gcc-15.2.0
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260530 clang-23
nios2 randconfig-002-20260530 clang-23
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260530 gcc-8.5.0
parisc randconfig-002-20260530 gcc-8.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260530 gcc-8.5.0
powerpc randconfig-002-20260530 gcc-8.5.0
powerpc64 randconfig-001-20260530 gcc-8.5.0
powerpc64 randconfig-002-20260530 gcc-8.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260530 gcc-12.5.0
riscv randconfig-002-20260530 gcc-12.5.0
s390 allmodconfig clang-18
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260530 gcc-12.5.0
s390 randconfig-002-20260530 gcc-12.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh allyesconfig gcc-15.2.0
sh defconfig gcc-14
sh randconfig-001-20260530 gcc-12.5.0
sh randconfig-002-20260530 gcc-12.5.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260530 gcc-9.5.0
sparc randconfig-002-20260530 gcc-9.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260530 gcc-9.5.0
sparc64 randconfig-002-20260530 gcc-9.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260530 gcc-9.5.0
um randconfig-002-20260530 gcc-9.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260530 gcc-14
x86_64 buildonly-randconfig-002-20260530 gcc-14
x86_64 buildonly-randconfig-003-20260530 gcc-14
x86_64 buildonly-randconfig-004-20260530 gcc-14
x86_64 buildonly-randconfig-005-20260530 gcc-14
x86_64 buildonly-randconfig-006-20260530 gcc-14
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-011-20260530 gcc-14
x86_64 randconfig-012-20260530 gcc-14
x86_64 randconfig-013-20260530 gcc-14
x86_64 randconfig-014-20260530 gcc-14
x86_64 randconfig-015-20260530 gcc-14
x86_64 randconfig-016-20260530 gcc-14
x86_64 randconfig-071-20260530 gcc-14
x86_64 randconfig-072-20260530 gcc-14
x86_64 randconfig-073-20260530 gcc-14
x86_64 randconfig-074-20260530 gcc-14
x86_64 randconfig-075-20260530 gcc-14
x86_64 randconfig-076-20260530 gcc-14
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260530 gcc-9.5.0
xtensa randconfig-002-20260530 gcc-9.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: bluetooth: qcom,qcc2072-bt: add bindings for QCC2072
From: Krzysztof Kozlowski @ 2026-05-30 12:34 UTC (permalink / raw)
To: Yepuri Siddu
Cc: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Balakrishna Godavarthi, Rocky Liao, quic_mohamull,
quic_hbandi, rahul.samana, harshitha.reddy, dishank.garg,
linux-arm-msm, linux-bluetooth, devicetree, linux-kernel
In-Reply-To: <20260529175342.3363935-1-yepuri.siddu@oss.qualcomm.com>
On Fri, May 29, 2026 at 11:23:42PM +0530, Yepuri Siddu wrote:
> Document the YAML binding schema for the Qualcomm QCC2072 UART-based
> Bluetooth controller.
Where is the rest?
Also:
A nit, subject: drop second/last, redundant "bindings for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Unlike other Qualcomm Bluetooth chips, QCC2072 requires no external
> voltage regulators. The schema inherits common Qualcomm Bluetooth
> properties via qcom,bluetooth-common.yaml and serial peripheral
> interface properties for the UART link.
>
> Signed-off-by: Yepuri Siddu <yepuri.siddu@oss.qualcomm.com>
> ---
> .../net/bluetooth/qcom,qcc2072-bt.yaml | 38 +++++++++++++++++++
> 1 file changed, 38 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml
> new file mode 100644
> index 000000000000..8e2f15a75d62
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,qcc2072-bt.yaml
> @@ -0,0 +1,38 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/bluetooth/qcom,qcc2072-bt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm QCC2072 Bluetooth
> +
> +maintainers:
> + - Balakrishna Godavarthi <quic_bgodavar@quicinc.com>
> + - Rocky Liao <quic_rjliao@quicinc.com>
> +
> +description:
> + Qualcomm QCC2072 is a UART-based Bluetooth controller.
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,qcc2072-bt
> +
> +required:
> + - compatible
> +
Looks heavily incomplete. Devices do not work without power for example.
> +allOf:
> + - $ref: bluetooth-controller.yaml#
> + - $ref: qcom,bluetooth-common.yaml#
> + - $ref: /schemas/serial/serial-peripheral-props.yaml#
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + serial {
> + bluetooth {
> + compatible = "qcom,qcc2072-bt";
> + max-speed = <3200000>;
Also incomplete.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3] Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV
From: Nils Helmig @ 2026-05-30 12:39 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcel Holtmann, Luiz Augusto von Dentz, Nils Helmig
Add the vendor/product ID (0x37ad, 0x0600) to usb_device_id table
for Realtek 8761BUV.
The device info from /sys/kernel/debug/usb/devices as below.
T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=37ad ProdID=0600 Rev= 2.00
S: Manufacturer=
S: Product=TP-Link Bluetooth USB Adapter
S: SerialNumber=ACA7F14FD2A5
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Nils Helmig <nils.helmig@web.de>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a13f10c7a981..3aef21d4ccd3 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -845,6 +845,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x2b89, 0x6275), .driver_info = BTUSB_REALTEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x37ad, 0x0600), .driver_info = BTUSB_REALTEK |
+ BTUSB_WIDEBAND_SPEECH },
/* Additional Realtek 8821AE Bluetooth devices */
{ USB_DEVICE(0x0b05, 0x17dc), .driver_info = BTUSB_REALTEK },
--
2.54.0
^ permalink raw reply related
* RE: [v3] Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV
From: bluez.test.bot @ 2026-05-30 14:33 UTC (permalink / raw)
To: linux-bluetooth, nils.helmig
In-Reply-To: <20260530123934.4583-1-nils.helmig@web.de>
[-- 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=1103276
---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 25.92 seconds
CheckAllWarning PASS 28.54 seconds
CheckSparse PASS 27.08 seconds
BuildKernel32 PASS 25.31 seconds
TestRunnerSetup PASS 535.81 seconds
IncrementalBuild PASS 25.39 seconds
https://github.com/bluez/bluetooth-next/pull/259
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: btusb: Add TP-Link UB600 for Realtek 8761BUV
From: Paul Menzel @ 2026-05-30 14:55 UTC (permalink / raw)
To: Nils Helmig; +Cc: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <20260530123934.4583-1-nils.helmig@web.de>
Dear Nils,
Thank you for resending.
Am 30.05.26 um 14:39 schrieb Nils Helmig:
> Add the vendor/product ID (0x37ad, 0x0600) to usb_device_id table
> for Realtek 8761BUV.
>
> The device info from /sys/kernel/debug/usb/devices as below.
>
> T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=37ad ProdID=0600 Rev= 2.00
> S: Manufacturer=
> S: Product=TP-Link Bluetooth USB Adapter
> S: SerialNumber=ACA7F14FD2A5
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
>
> Signed-off-by: Nils Helmig <nils.helmig@web.de>
> ---
> drivers/bluetooth/btusb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index a13f10c7a981..3aef21d4ccd3 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -845,6 +845,8 @@ static const struct usb_device_id quirks_table[] = {
> BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x2b89, 0x6275), .driver_info = BTUSB_REALTEK |
> BTUSB_WIDEBAND_SPEECH },
> + { USB_DEVICE(0x37ad, 0x0600), .driver_info = BTUSB_REALTEK |
> + BTUSB_WIDEBAND_SPEECH },
>
> /* Additional Realtek 8821AE Bluetooth devices */
> { USB_DEVICE(0x0b05, 0x17dc), .driver_info = BTUSB_REALTEK },
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
^ permalink raw reply
* [Bug 221598] New: Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery
From: bugzilla-daemon @ 2026-05-30 15:18 UTC (permalink / raw)
To: linux-bluetooth
https://bugzilla.kernel.org/show_bug.cgi?id=221598
Bug ID: 221598
Summary: Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC
microphone stutters with bursty SCO RX delivery
Product: Drivers
Version: 2.5
Kernel Version: 6.12.90+deb13.1-rt-amd64, 6.12.90+deb13-amd64,
6.19.10-300.fc44.x86_64
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Bluetooth
Assignee: linux-bluetooth@vger.kernel.org
Reporter: apocarteres@gmail.com
Regression: No
Created attachment 310210
--> https://bugzilla.kernel.org/attachment.cgi?id=310210&action=edit
btsnoop captures and report draft
I am seeing severe HFP/mSBC microphone stutter with a Realtek RTL8821C
Bluetooth USB controller on Linux. The same PC and the same Bluetooth headsets
work correctly under Windows 11.
The problem reproduces on both Debian and Fedora live systems, so it does not
look specific to one distribution audio stack.
### Hardware
Bluetooth controller:
```
Bus 003 Device 007: ID 0bda:c821 Realtek Semiconductor Corp. Bluetooth Radio
Negotiated speed: Full Speed (12Mbps)
```
Controller details from Linux:
```
hci0: Type: Primary Bus: USB
BD Address: 64:57:25:4C:4E:BA
HCI Version: 4.2 (0x8) Revision: 0x75b8
LMP Version: 4.2 (0x8) Subversion: 0xf098
Manufacturer: Realtek Semiconductor Corporation (93)
```
Kernel log during initialization:
```
Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000c lmp_ver=08
lmp_subver=8821
Bluetooth: hci0: RTL: rom_version status=0 version=1
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_fw.bin
Bluetooth: hci0: RTL: loading rtl_bt/rtl8821c_config.bin
Bluetooth: hci0: RTL: cfg_sz 10, total sz 34926
Bluetooth: hci0: RTL: fw version 0x75b8f098
```
Headsets tested:
- JBL TOUR ONE M2
- Jabra headset, exact model unknown
Both headsets show the same problem on Linux and work normally on Windows 11 on
the same machine.
### Software tested
Debian:
```
Linux dev 6.12.90+deb13.1-rt-amd64 #1 SMP PREEMPT_RT Debian 6.12.90-2
(2026-05-27) x86_64 GNU/Linux
bluez 5.82-1.1
pipewire 1.4.2-1
wireplumber 0.5.8-2
firmware-realtek 20250410-2
```
The same issue was also reproduced on the non-RT Debian 6.12.90 kernel.
Fedora live:
```
Linux version 6.19.10-300.fc44.x86_64
Bluetooth subsystem version 2.22
```
The Fedora capture was made from a live Fedora Workstation 44 system.
### Actual behavior
In HFP/mSBC mode the microphone audio has severe stutter, dropouts and "jerky"
timing. Applications receive very poor audio. PipeWire/WirePlumber logs
repeated mSBC decode failures:
```
wireplumber: spa.bluez5.source.sco: decode failed: -3
```
Switching to CVSD avoids the mSBC decoder errors but the microphone still
stutters and the audio quality is too low to be useful.
### Expected behavior
The HFP microphone should work without dropouts, as it does on the same machine
and the same headsets under Windows 11.
### eSCO / mSBC negotiation
The btsnoop captures show eSCO with transparent air coding and 60 byte RX/TX
packet lengths. Example from the Fedora capture:
```
Setup Synchronous Connection:
Tx/Rx bandwidth: 8000
Max latency: 13
Air Coding Format: Transparent Data
Retransmission effort: Optimize for link quality
Synchronous Connect Complete:
Link type: eSCO
Transmission interval: 0x0c
Retransmission window: 0x06
RX packet length: 60
TX packet length: 60
Air mode: Transparent
```
The actual SCO packets in the captures are 72 byte packets:
```
SCO Data RX: Handle 2 flags 0x00 dlen 72
SCO Data TX: Handle 2 flags 0x00 dlen 72
```
### Capture timing summary
The relevant pattern is that incoming SCO packets are delivered in bursts:
about 20% of RX inter-arrival times are below 1 ms, followed by regular long
gaps above 15 ms. This is visible on both Debian and Fedora. TX timing is much
smoother and does not show the same sub-1 ms burst pattern in most captures.
Timing was computed from `btmon -r <capture>` timestamps for `SCO Data RX/TX`
lines.
```
Debian, bt-sco-bad.snoop:
RX n=1765 dlen=72 avg=9.003 ms min=0.001 max=20.154 lt1ms=20.0% gt15ms=10.0%
gt20ms=5.2%
TX n=1765 dlen=72 avg=8.998 ms min=0.022 max=21.657 lt1ms=9.2% gt15ms=8.1%
gt20ms=4.9%
Debian, bt-sco-bad1.snoop:
RX n=3069 dlen=72 avg=9.000 ms min=0.001 max=20.166 lt1ms=20.0% gt15ms=10.0%
gt20ms=4.2%
TX n=3066 dlen=72 avg=9.000 ms min=0.024 max=21.590 lt1ms=3.8% gt15ms=12.7%
gt20ms=2.2%
Debian, bt-sco-bad2.snoop:
RX n=1943 dlen=72 avg=8.996 ms min=0.002 max=20.136 lt1ms=20.2% gt15ms=10.2%
gt20ms=6.0%
TX n=1942 dlen=72 avg=8.999 ms min=5.016 max=16.256 lt1ms=0.0% gt15ms=16.2%
gt20ms=0.0%
Debian, bt-sco-bad3.snoop:
RX n=1850 dlen=72 avg=9.000 ms min=0.001 max=20.102 lt1ms=20.3% gt15ms=10.3%
gt20ms=1.8%
TX n=1850 dlen=72 avg=8.997 ms min=3.788 max=16.241 lt1ms=0.0% gt15ms=16.2%
gt20ms=0.0%
Debian, bt-sco-bad4.snoop:
RX n=5600 dlen=72 avg=9.000 ms min=0.001 max=20.159 lt1ms=20.0% gt15ms=10.0%
gt20ms=5.3%
TX n=5597 dlen=72 avg=9.000 ms min=4.876 max=16.386 lt1ms=0.0% gt15ms=16.2%
gt20ms=0.0%
Fedora live, fedora.cap:
RX n=2089 dlen=72 avg=8.249 ms min=0.001 max=18.447 lt1ms=20.0% gt15ms=10.0%
gt18ms=10.0%
TX n=1914 dlen=72 avg=8.998 ms min=6.215 max=15.234 lt1ms=0.0% gt15ms=10.6%
```
### Things already tested
- Same Bluetooth adapter and headsets work correctly on Windows 11.
- Reproduced with two different Bluetooth headsets.
- Reproduced on Debian 6.12 and Fedora live 6.19.
- Disabled USB autosuspend for `btusb`:
```
/sys/module/btusb/parameters/enable_autosuspend = N
```
- Unloaded/blacklisted the Wi-Fi side of the combo device (`rtw88_8821ce`): no
fix.
- Disabled nearby USB audio/camera devices on the same USB bus: no fix.
- Tried Debian PREEMPT_RT kernel: no fix.
- Tried `btusb force_scofix=1`: worse.
- Tried `btusb disable_scofix=1`: worse.
- Tried `btusb reset=0`: no durable fix.
- Tried disabling eSCO with `bluetooth.disable_esco=1`: microphone became
unavailable.
- Tried PipeWire/WirePlumber SCO/mSBC workarounds, including CVSD and hardware
offload experiments: no useful fix.
Current relevant module parameters:
```
/sys/module/bluetooth/parameters/disable_ertm = N
/sys/module/bluetooth/parameters/disable_esco = N
/sys/module/bluetooth/parameters/enable_ecred = Y
/sys/module/btusb/parameters/reset = Y
/sys/module/btusb/parameters/force_scofix = N
/sys/module/btusb/parameters/disable_scofix = N
/sys/module/btusb/parameters/enable_autosuspend = N
```
### Possibly related upstream reports / patches
This looks related to the Realtek SCO/WBS path in `btusb`/`btrtl`.
A very similar Realtek patch was posted but does not appear to be merged:
```
[PATCH v5] Bluetooth: btusb: Work around spotty SCO quality
https://patchew.org/linux/20221226074829.8682-1-hildawu%40realtek.com/
```
That patch targeted other Realtek USB IDs (`0bda:8771`, `0bda:8773`,
`0bda:8871`, `0bda:8873`), not `0bda:c821`, but the symptom family is close:
Realtek USB Bluetooth, WBS/SCO, spotty SCO quality, and packet handling around
WBS.
Possibly related Bugzilla entries:
```
Bug 219997 - [rtw89] Headset unusable because of delays and stutter
https://bugzilla.kernel.org/show_bug.cgi?id=219997
Bug 219992 - Linux logs warning `Bluetooth: hci0: SCO packet for unknown
connection handle 3`
https://bugzilla.kernel.org/show_bug.cgi?id=219992
```
These do not seem to be exact matches for this controller (`0bda:c821` /
RTL8821C), but they may be related to the same SCO/WBS area.
### Attachments available
The following captures are available and should be attached:
```
/home/apocarteres/bt-sco-bad.snoop
/home/apocarteres/bt-sco-bad1.snoop
/home/apocarteres/bt-sco-bad2.snoop
/home/apocarteres/bt-sco-bad3.snoop
/home/apocarteres/bt-sco-bad4.snoop
/opt/fedora.cap
```
Recommended minimum attachments:
```
/home/apocarteres/bt-sco-bad4.snoop
/opt/fedora.cap
```
`bt-sco-bad4.snoop` is a longer Debian capture. `fedora.cap` demonstrates that
the same bursty SCO RX pattern also happens on Fedora 6.19.
--
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 221598] Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery
From: bugzilla-daemon @ 2026-05-30 15:19 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221598-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221598
--- Comment #1 from Alexander Paderin (apocarteres@gmail.com) ---
Created attachment 310211
--> https://bugzilla.kernel.org/attachment.cgi?id=310211&action=edit
btsnoop captures and report draft
Archive contains the Debian and Fedora btsnoop captures referenced in the
report, plus the local report draft.
--
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 221598] Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery
From: bugzilla-daemon @ 2026-05-30 15:20 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221598-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221598
Alexander Paderin (apocarteres@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #310211|0 |1
is obsolete| |
--- Comment #2 from Alexander Paderin (apocarteres@gmail.com) ---
Comment on attachment 310211
--> https://bugzilla.kernel.org/attachment.cgi?id=310211
btsnoop captures and report draft
Marking this attachment obsolete because it is a duplicate of attachment
310210.
--
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 221598] Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery
From: bugzilla-daemon @ 2026-05-30 15:25 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221598-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221598
--- Comment #3 from Alexander Paderin (apocarteres@gmail.com) ---
Created attachment 310212
--> https://bugzilla.kernel.org/attachment.cgi?id=310212&action=edit
btmon capture on Debian (RT)
--
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 221598] Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery
From: bugzilla-daemon @ 2026-05-30 15:27 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221598-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221598
--- Comment #4 from Alexander Paderin (apocarteres@gmail.com) ---
Created attachment 310213
--> https://bugzilla.kernel.org/attachment.cgi?id=310213&action=edit
btmon capture on Fedora Live
--
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 221598] Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery
From: bugzilla-daemon @ 2026-05-30 15:32 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221598-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221598
Alexander Paderin (apocarteres@gmail.com) changed:
What |Removed |Added
----------------------------------------------------------------------------
Hardware|All |Intel
--
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 221598] Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery
From: bugzilla-daemon @ 2026-05-30 16:21 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221598-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221598
--- Comment #5 from Alexander Paderin (apocarteres@gmail.com) ---
Created attachment 310214
--> https://bugzilla.kernel.org/attachment.cgi?id=310214&action=edit
binary usbmon SCO/H2 analysis update
Archive with simultaneous btmon capture, binary usbmon JSONL.GZ capture,
analysis reports and scripts.
--
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 221598] Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery
From: bugzilla-daemon @ 2026-05-30 16:23 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221598-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221598
--- Comment #6 from Alexander Paderin (apocarteres@gmail.com) ---
Additional binary usbmon evidence
=================================
I captured the same HFP/mSBC failure with simultaneous btmon and binary usbmon.
New files:
```
captures/btmon-20260530-191225.snoop
captures/usbmon-bus3-dev7-ep3-20260530-191228.jsonl.gz
reports/captures-sco-analysis.md
reports/usbmon-bin-analysis.md
reports/usbmon-bin-anomalies.csv
```
The binary usbmon capture was taken from `/dev/usbmon3`, filtered to Bluetooth
device `3-007`, isochronous endpoint 3. It includes full ISO descriptors and
payload data, unlike the debugfs text usbmon log.
Important result:
```
usbmon-bus3-dev7-ep3-20260530-191228.jsonl.gz
RX USB IN completions:
reconstructed ISO fragments: 12675 x 25 bytes
reconstructed HCI SCO packets: 4225/4225 valid, handle 5
H2/mSBC markers: 5038
H2 bad sequence: 23
H2 same sequence: 21
H2 bad distance: 20
TX USB OUT submissions:
reconstructed ISO fragments: 12669 x 25 bytes
reconstructed HCI SCO packets: 4223/4223 valid, handle 5
H2/mSBC markers: 5068
H2 bad sequence: 0
H2 same sequence: 0
H2 bad distance: 0
```
The simultaneous btmon capture shows a matching RX-only problem:
```
btmon-20260530-191225.snoop
RX:
packets: 3963 x dlen 72
<1ms packet intervals: 20.0%
>15ms packet intervals: 10.0%
H2 bad sequence: 21
H2 same sequence: 20
H2 bad distance: 17
TX:
packets: 3961 x dlen 72
H2 bad sequence: 0
H2 same sequence: 0
H2 bad distance: 0
```
This suggests that the H2/mSBC sequence corruption is already visible in the
USB ISO IN data delivered to the host, before PipeWire/WirePlumber and before
userspace. It also makes the repeated near-identical btmon RX timestamps less
important by themselves: the USB IN side is batched in 10 ISO descriptors per
URB, so several 1 ms USB frames are naturally processed together by one URB
completion.
The remaining question appears to be whether the controller/firmware is
delivering duplicated/missing mSBC frames on RX, or whether the Linux
btusb/btrtl setup for this controller causes the controller to use bad SCO/eSCO
parameters. The next useful comparison would be a Windows USBPcap trace of the
same HFP/mSBC scenario, especially the vendor initialization commands, selected
USB alternate setting, and `Setup Synchronous Connection` parameters.
Attached archive: `bluetooth-rtl8821c-binary-usbmon-update-2026-05-30.tar.xz`
--
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
* [syzbot] [bluetooth?] memory leak in init_srcu_struct_fields
From: syzbot @ 2026-05-30 20:57 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel, luiz.dentz, marcel, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: f377d0025eb0 Merge tag 'sh-for-v7.1-tag2' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1737bb48580000
kernel config: https://syzkaller.appspot.com/x/.config?x=9645c21cfd1d3e8f
dashboard link: https://syzkaller.appspot.com/bug?extid=535ecc844591e50588a5
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=164ed748580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10e6576c580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/5d8163677f58/disk-f377d002.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/cf2fcdb8200b/vmlinux-f377d002.xz
kernel image: https://storage.googleapis.com/syzbot-assets/e9fb70799318/bzImage-f377d002.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+535ecc844591e50588a5@syzkaller.appspotmail.com
BUG: memory leak
unreferenced object 0xffff888111f49600 (size 512):
comm "syz.0.17", pid 5937, jiffies 4294945495
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 6e7d3fde):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4574 [inline]
slab_alloc_node mm/slub.c:4898 [inline]
__kmalloc_cache_noprof+0x371/0x480 mm/slub.c:5414
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
init_srcu_struct_fields+0x2c0/0x350 kernel/rcu/srcutree.c:207
hci_alloc_dev_priv+0x37/0x680 net/bluetooth/hci_core.c:2453
hci_alloc_dev include/net/bluetooth/hci_core.h:1763 [inline]
hci_uart_register_dev drivers/bluetooth/hci_ldisc.c:644 [inline]
hci_uart_set_proto drivers/bluetooth/hci_ldisc.c:720 [inline]
hci_uart_tty_ioctl+0x173/0x460 drivers/bluetooth/hci_ldisc.c:774
tty_ioctl+0xaca/0xd60 drivers/tty/tty_io.c:2801
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0xf4/0x140 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xee/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
BUG: memory leak
unreferenced object (percpu) 0x607e4d93d800 (size 384):
comm "syz.0.17", pid 5937, jiffies 4294945495
hex dump (first 32 bytes on cpu 0):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 593bdea7):
pcpu_alloc_noprof+0x7c7/0xed0 mm/percpu.c:1896
init_srcu_struct_fields+0x2eb/0x350 kernel/rcu/srcutree.c:224
hci_alloc_dev_priv+0x37/0x680 net/bluetooth/hci_core.c:2453
hci_alloc_dev include/net/bluetooth/hci_core.h:1763 [inline]
hci_uart_register_dev drivers/bluetooth/hci_ldisc.c:644 [inline]
hci_uart_set_proto drivers/bluetooth/hci_ldisc.c:720 [inline]
hci_uart_tty_ioctl+0x173/0x460 drivers/bluetooth/hci_ldisc.c:774
tty_ioctl+0xaca/0xd60 drivers/tty/tty_io.c:2801
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0xf4/0x140 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xee/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
BUG: memory leak
unreferenced object (percpu) 0x607e4d93d980 (size 384):
comm "syz.0.18", pid 5940, jiffies 4294945497
hex dump (first 32 bytes on cpu 0):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 593bdea7):
pcpu_alloc_noprof+0x7c7/0xed0 mm/percpu.c:1896
init_srcu_struct_fields+0x2eb/0x350 kernel/rcu/srcutree.c:224
hci_alloc_dev_priv+0x37/0x680 net/bluetooth/hci_core.c:2453
hci_alloc_dev include/net/bluetooth/hci_core.h:1763 [inline]
hci_uart_register_dev drivers/bluetooth/hci_ldisc.c:644 [inline]
hci_uart_set_proto drivers/bluetooth/hci_ldisc.c:720 [inline]
hci_uart_tty_ioctl+0x173/0x460 drivers/bluetooth/hci_ldisc.c:774
tty_ioctl+0xaca/0xd60 drivers/tty/tty_io.c:2801
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0xf4/0x140 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xee/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
BUG: memory leak
unreferenced object 0xffff88811d010a00 (size 512):
comm "syz.0.19", pid 5951, jiffies 4294945502
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 2d3d1dd8):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4574 [inline]
slab_alloc_node mm/slub.c:4898 [inline]
__kmalloc_cache_noprof+0x371/0x480 mm/slub.c:5414
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
init_srcu_struct_fields+0x2c0/0x350 kernel/rcu/srcutree.c:207
hci_alloc_dev_priv+0x37/0x680 net/bluetooth/hci_core.c:2453
hci_alloc_dev include/net/bluetooth/hci_core.h:1763 [inline]
hci_uart_register_dev drivers/bluetooth/hci_ldisc.c:644 [inline]
hci_uart_set_proto drivers/bluetooth/hci_ldisc.c:720 [inline]
hci_uart_tty_ioctl+0x173/0x460 drivers/bluetooth/hci_ldisc.c:774
tty_ioctl+0xaca/0xd60 drivers/tty/tty_io.c:2801
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0xf4/0x140 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xee/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
BUG: memory leak
unreferenced object (percpu) 0x607e4d93db00 (size 384):
comm "syz.0.19", pid 5951, jiffies 4294945502
hex dump (first 32 bytes on cpu 0):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace (crc 593bdea7):
pcpu_alloc_noprof+0x7c7/0xed0 mm/percpu.c:1896
init_srcu_struct_fields+0x2eb/0x350 kernel/rcu/srcutree.c:224
hci_alloc_dev_priv+0x37/0x680 net/bluetooth/hci_core.c:2453
hci_alloc_dev include/net/bluetooth/hci_core.h:1763 [inline]
hci_uart_register_dev drivers/bluetooth/hci_ldisc.c:644 [inline]
hci_uart_set_proto drivers/bluetooth/hci_ldisc.c:720 [inline]
hci_uart_tty_ioctl+0x173/0x460 drivers/bluetooth/hci_ldisc.c:774
tty_ioctl+0xaca/0xd60 drivers/tty/tty_io.c:2801
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0xf4/0x140 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xee/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [Bug 221598] Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery
From: bugzilla-daemon @ 2026-05-30 21:38 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221598-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221598
--- Comment #7 from Alexander Paderin (apocarteres@gmail.com) ---
Additional update after isolating user-space HCI traffic:
I found a strong practical mitigation/confounder: stopping/removing Blueman
significantly improves the HFP/mSBC microphone quality on this machine.
Before this test, Blueman UI processes were running:
- `blueman-manager`
- `blueman-applet`
- `blueman-tray`
The bad traces with Blueman running contained frequent HCI control traffic,
especially:
- `Read RSSI` (`0x1405`)
- `Read Transmit Power Level` (`0x0c2d`)
After stopping/removing Blueman, the same headset/machine produced much cleaner
captures. The subjective microphone stutter also became noticeably better.
Summary of RX mSBC/H2 continuity results:
| run | extra HCI polling | RX H2 markers | bad seq | bad seq/k | bad dist |
bad dist/k |
|---|---:|---:|---:|---:|---:|---:|
| old control | yes | 3486 | 21 | 6.02 | 23 | 6.60 |
| no-Blueman control 1 | no | 4301 | 6 | 1.39 | 15 | 3.49 |
| no-Blueman control 2 | no | 4312 | 6 | 1.39 | 6 | 1.39 |
| bad noisy watch-only run | yes | 3949 | 454 | 114.97 | 425 | 107.62 |
| bad noisy raw-open repeat | yes | 4812 | 453 | 94.14 | 385 | 80.01 |
TX remained clean in all runs (`bad_sequence=0`, `bad_distance=0`).
Important caveat: I then tried to reproduce the issue without Blueman by
injecting the same polling manually after eSCO setup. The stress script sent 25
pairs of:
- `Read RSSI` (`0x1405`)
- `Read Transmit Power Level` (`0x0c2d`)
That did not reproduce the catastrophic bad runs:
| run | polling | RX H2 markers | bad seq | bad seq/k | bad dist | bad dist/k |
|---|---:|---:|---:|---:|---:|---:|
| no-Blueman control 2 | no | 4312 | 6 | 1.39 | 6 | 1.39 |
| artificial HCI polling stress | 25 RSSI + 25 TX-power reads | 3778 | 16 |
4.24 | 13 | 3.44 |
So `Read RSSI` / `Read Transmit Power Level` alone is not proven to be the
direct root cause. The stronger conclusion is:
- Removing Blueman is a real practical mitigation on this RTL8821C/0bda:c821
system.
- Extra user-space HCI management/control traffic is a strong confounder and
can correlate with much worse RX mSBC continuity.
- The underlying failure still appears to be RX-only H2/mSBC continuity loss:
host TX stays clean, eSCO setup parameters remain normal, and RX still has some
breaks even in the clean no-Blueman baseline.
Relevant local captures/reports:
- `captures/sco-control-test-20260531-002158.snoop`
- `captures/sco-control-test-20260531-002431.snoop`
- `captures/hci-poll-stress-test-20260531-003222.snoop`
- `reports/control-no-blueman-20260531-002158-findings.md`
- `reports/control-no-blueman-repeat-20260531-002431-findings.md`
- `reports/hci-poll-stress-20260531-003222-findings.md`
--
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 221598] Bluetooth: btusb/btrtl RTL8821C 0bda:c821 HFP/mSBC microphone stutters with bursty SCO RX delivery
From: bugzilla-daemon @ 2026-05-30 22:12 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-221598-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=221598
--- Comment #8 from Alexander Paderin (apocarteres@gmail.com) ---
Additional update: loading the RTL8821CE Wi-Fi-side driver dramatically
improves Bluetooth HFP/mSBC RX stability on this RTL8821CE combo module.
Hardware topology:
- Bluetooth: Realtek `0bda:c821`, internal USB Full-Speed device, handled by
`btusb`
- Wi-Fi: Realtek RTL8821CE PCIe `10ec:c821`, handled by `rtw88_8821ce` /
`rtw_8821ce`
I ran the same near/far/near2 Bluetooth HFP microphone range test twice:
1. Wi-Fi driver not loaded.
2. Wi-Fi driver loaded manually, but Wi-Fi radio kept disabled in
NetworkManager.
State during the improved run:
```text
02:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8821CE
802.11ac PCIe Wireless Network Adapter [10ec:c821]
Kernel driver in use: rtw_8821ce
Kernel modules: rtw88_8821ce
WIFI-HW WIFI WWAN-HW WWAN
enabled disabled missing enabled
wlp2s0 DOWN
```
Kernel log also showed the Wi-Fi firmware initialized:
```text
rtw_8821ce 0000:02:00.0: Firmware version 24.11.0, H2C version 12
```
Results:
| run | Wi-Fi driver | phase | RSSI avg | RSSI min | RX markers | RX bad seq/k
| RX bad dist/k | TX bad seq | TX bad dist |
|---|---|---|---:|---:|---:|---:|---:|---:|---:|
| `range-sco-test-20260531-005925` | not loaded | near | -38.9 | -42 | 1976 |
1.01 | 3.54 | 0 | 0 |
| `range-sco-test-20260531-005925` | not loaded | far | -58.1 | -70 | 3528 |
123.30 | 103.74 | 0 | 0 |
| `range-sco-test-20260531-005925` | not loaded | near2 | -49.6 | -54 | 1936 |
38.74 | 31.51 | 0 | 0 |
| `range-sco-test-20260531-010648` | loaded, Wi-Fi radio off | near | -46.7 |
-52 | 1975 | 1.01 | 1.01 | 0 | 0 |
| `range-sco-test-20260531-010648` | loaded, Wi-Fi radio off | far | -53.9 |
-60 | 3989 | 2.51 | 2.51 | 0 | 0 |
| `range-sco-test-20260531-010648` | loaded, Wi-Fi radio off | near2 | -53.1 |
-64 | 1984 | 6.55 | 6.55 | 0 | 0 |
The important result is the far phase:
- RX bad sequence rate dropped from `123.30/k` to `2.51/k`.
- RX bad distance rate dropped from `103.74/k` to `2.51/k`.
- TX remained clean in both runs.
- RSSI no longer collapsed to `-70 dBm`; the improved run bottomed at `-60
dBm`.
Because Wi-Fi remained disabled and the interface stayed down, this improvement
does not appear to come from active Wi-Fi traffic. It appears to come from the
Wi-Fi-side driver/firmware initialization of the same RTL8821CE combo chip.
This strongly suggests that the Linux Bluetooth-only initialization path for
`0bda:c821` leaves the combo chip in a worse Bluetooth RX/range state than the
state after `rtw_8821ce` initializes the Wi-Fi side. The likely area is Realtek
combo-chip coexistence/RF/antenna-path/shared firmware state.
Practical workaround on this machine:
- keep `rtw88_8821ce` loadable and loaded at boot;
- keep Wi-Fi radio disabled if Wi-Fi is not needed.
Local captures/reports:
- `captures/range-sco-test-20260531-005925.snoop`
- `captures/range-sco-test-20260531-005925-metrics.csv`
- `reports/range-sco-test-20260531-005925-analysis.md`
- `captures/range-sco-test-20260531-010648.snoop`
- `captures/range-sco-test-20260531-010648-metrics.csv`
- `reports/range-sco-test-20260531-010648-analysis.md`
- `reports/rtl8821ce-wifi-driver-coex-range-comparison-20260531.md`
--
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
* [PATCH BlueZ v2 0/2] advertising: add property with advertisement Instance
From: Michal Dzik @ 2026-05-31 10:17 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Michal Dzik
I renamed Identifier to Instance and added support in client
Michal Dzik (2):
advertising: add property with advertisement Instance
client: add advertisement instance support
client/advertising.c | 38 +++++++++++++++++++++++++++++++
client/advertising.h | 1 +
client/main.c | 7 ++++++
doc/org.bluez.LEAdvertisement.rst | 6 +++++
src/advertising.c | 13 ++++++++++-
5 files changed, 64 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* [PATCH BlueZ v2 1/2] advertising: add property with advertisement Instance
From: Michal Dzik @ 2026-05-31 10:17 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Michal Dzik
In-Reply-To: <20260531101754.3325247-1-michal.dzik@streamunlimited.com>
Instance 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..dbfc5f0bc 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 Instance [read-write, optional]
+``````````````````````````````````````
+
+Instance 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 8970e65f7..c8b00a887 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -1390,8 +1390,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 Instance property */
+ if (g_dbus_proxy_get_property(client->proxy, "Instance",
+ &iter)) {
+ g_dbus_proxy_set_property_basic(client->proxy,
+ "Instance", 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
* [PATCH BlueZ v2 2/2] client: add advertisement instance support
From: Michal Dzik @ 2026-05-31 10:17 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Michal Dzik
In-Reply-To: <20260531101754.3325247-1-michal.dzik@streamunlimited.com>
---
client/advertising.c | 38 ++++++++++++++++++++++++++++++++++++++
client/advertising.h | 1 +
client/main.c | 7 +++++++
3 files changed, 46 insertions(+)
diff --git a/client/advertising.c b/client/advertising.c
index 5ca391635..a64d1895a 100644
--- a/client/advertising.c
+++ b/client/advertising.c
@@ -67,6 +67,7 @@ static struct ad {
uint16_t duration;
uint16_t timeout;
uint16_t discoverable_to;
+ uint8_t instance;
char **uuids[AD_TYPE_COUNT];
size_t uuids_len[AD_TYPE_COUNT];
char **solicit[AD_TYPE_COUNT];
@@ -233,6 +234,9 @@ static void print_ad(void)
if (ad.min_interval)
bt_shell_printf("Interval: %u-%u msec\n", ad.min_interval,
ad.max_interval);
+
+ if (ad.instance)
+ bt_shell_printf("Instance: %u\n", ad.instance);
}
static void register_reply(DBusMessage *message, void *user_data)
@@ -640,6 +644,32 @@ static gboolean get_secondary(const GDBusPropertyTable *property,
return TRUE;
}
+static gboolean get_instance(const GDBusPropertyTable *property,
+ DBusMessageIter *iter, void *user_data)
+{
+ dbus_message_iter_append_basic(iter, DBUS_TYPE_BYTE, &ad.instance);
+
+ return TRUE;
+}
+
+static void set_instance(const GDBusPropertyTable *property,
+ DBusMessageIter *iter,
+ GDBusPendingPropertySet id, void *user_data)
+{
+ uint8_t value;
+
+ if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_BYTE) {
+ g_dbus_pending_property_error(id,
+ "org.bluez.Error.InvalidArguments",
+ "Invalid argument type");
+ return;
+ }
+
+ dbus_message_iter_get_basic(iter, &value);
+ ad.instance = value;
+ g_dbus_pending_property_success(id);
+}
+
static gboolean min_interval_exists(const GDBusPropertyTable *property,
void *data)
{
@@ -700,6 +730,7 @@ static const GDBusPropertyTable ad_props[] = {
{ "MinInterval", "u", get_min_interval, NULL, min_interval_exists },
{ "MaxInterval", "u", get_max_interval, NULL, max_interval_exists },
{ "SecondaryChannel", "s", get_secondary, NULL, secondary_exists },
+ { "Instance", "y", get_instance, set_instance, NULL },
{ }
};
@@ -1446,3 +1477,10 @@ void ad_advertise_rsi(DBusConnection *conn, dbus_bool_t *value)
return bt_shell_noninteractive_quit(EXIT_SUCCESS);
}
+
+void ad_advertise_instance(void)
+{
+ bt_shell_printf("Instance: %u\n", ad.instance);
+
+ return bt_shell_noninteractive_quit(EXIT_SUCCESS);
+}
diff --git a/client/advertising.h b/client/advertising.h
index 8c3fd041b..89d95d67e 100644
--- a/client/advertising.h
+++ b/client/advertising.h
@@ -42,3 +42,4 @@ void ad_advertise_discoverable_timeout(DBusConnection *conn, long int *value);
void ad_advertise_secondary(DBusConnection *conn, const char *value);
void ad_advertise_interval(DBusConnection *conn, uint32_t *min, uint32_t *max);
void ad_advertise_rsi(DBusConnection *conn, dbus_bool_t *value);
+void ad_advertise_instance(void);
diff --git a/client/main.c b/client/main.c
index 6fb399277..9d9ac8b14 100644
--- a/client/main.c
+++ b/client/main.c
@@ -3206,6 +3206,11 @@ static void cmd_advertise_rsi(int argc, char *argv[])
ad_advertise_rsi(dbus_conn, &value);
}
+static void cmd_advertise_instance(int argc, char *argv[])
+{
+ ad_advertise_instance();
+}
+
static void ad_clear_uuids(void)
{
ad_disable_uuids(dbus_conn, AD_TYPE_AD);
@@ -3705,6 +3710,8 @@ static const struct bt_shell_menu advertise_menu = {
"Set/Get advertise interval range" },
{ "rsi", "[on/off]", cmd_advertise_rsi,
"Show/Enable/Disable RSI to be advertised", NULL },
+ { "instance", NULL, cmd_advertise_instance,
+ "Show advertisement instance number" },
{ "clear", "[uuids/service/manufacturer/config-name...]", cmd_ad_clear,
"Clear advertise config" },
{ } },
--
2.43.0
^ permalink raw reply related
* [bluez/bluez] 365197: advertising: add property with advertisement Instance
From: mdzik-sue @ 2026-05-31 10:35 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1103543
Home: https://github.com/bluez/bluez
Commit: 3651970e944775553e3cf9d08094c93ea7fe24a7
https://github.com/bluez/bluez/commit/3651970e944775553e3cf9d08094c93ea7fe24a7
Author: Michal Dzik <michal.dzik@streamunlimited.com>
Date: 2026-05-31 (Sun, 31 May 2026)
Changed paths:
M doc/org.bluez.LEAdvertisement.rst
M src/advertising.c
Log Message:
-----------
advertising: add property with advertisement Instance
Instance is an internal value, but it must be exposed to client app if
client app wants to use a advertisement in BAP broadcast.
Commit: c8e847f563925610f7642c63662f201ca0dc239f
https://github.com/bluez/bluez/commit/c8e847f563925610f7642c63662f201ca0dc239f
Author: Michal Dzik <michal.dzik@streamunlimited.com>
Date: 2026-05-31 (Sun, 31 May 2026)
Changed paths:
M client/advertising.c
M client/advertising.h
M client/main.c
Log Message:
-----------
client: add advertisement instance support
Compare: https://github.com/bluez/bluez/compare/3651970e9447%5E...c8e847f56392
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