* Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Eric Biggers @ 2026-06-23 16:49 UTC (permalink / raw)
To: Bastien Nocera
Cc: linux-crypto, Herbert Xu, Marcel Holtmann, Luiz Augusto von Dentz,
linux-doc, linux-api, linux-kernel, netdev, Linus Torvalds,
linux-bluetooth, ell
In-Reply-To: <7d08a6df54279e9915f5df6bd4e5e5dde52b4fe1.camel@hadess.net>
On Tue, Jun 23, 2026 at 02:44:28PM +0200, Bastien Nocera wrote:
> Hey,
>
> Replying to this older patch.
>
> On Wed, 2026-04-29 at 18:15 -0700, Eric Biggers wrote:
> <snip>
> > This isn't intended to change anything overnight. After all, most Linux
> > distros won't be able to disable the kconfig options quite yet, mainly
> > because of iwd. But this should create a bit more impetus for these
> > userspace programs to be fixed, and the documentation update should also
> > help prevent more users from appearing.
>
> There are 2 other users that I know of: bluez, and the ell library
> (used by iwd and bluez).
>
> From what I could tell, bluetoothd uses AF_ALG for cryptography:
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/shared/crypto.c
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/tools/mesh-gatt/crypto.c
>
> It uses "ecb(aes)" and "cmac(aes)" as algorithms.
>
> Finally, it also uses them both again:
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/mesh/crypto.c
> through ell:
> https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c
>
> Because that's a question that also came up, bluetoothd also uses the
> CAP_NET_ADMIN capability.
>
> I'll let Luiz and Marcel take it over from here.
>
We're aware of that and are taking it into account in the allowlist:
https://lore.kernel.org/linux-crypto/20260622234803.6982-1-ebiggers@kernel.org/
If you have any feedback on the allowlist, please respond to that patch.
- Eric
^ permalink raw reply
* Re: [PATCH BlueZ v2] a2dp: Fix handling of codec capability storage
From: Bastien Nocera @ 2026-06-23 16:49 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZLWKRTnFEg3vuoqs0yzD4nEQW6Pajn7WdQf-pT6KtvPSw@mail.gmail.com>
On Tue, 2026-06-23 at 10:30 -0400, Luiz Augusto von Dentz wrote:
> Hi Bastien,
>
> On Tue, Jun 23, 2026 at 8:18 AM Bastien Nocera <hadess@hadess.net>
> wrote:
> >
> > On Mon, 2026-06-22 at 11:56 -0400, Luiz Augusto von Dentz wrote:
> > > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> > >
> > > Codec capability is one byte long (max 255) the storage format is
> > > 02hhx which means each byte ends up as 2 characters so the buffer
> > > needs to be doubled in order to handle capabilities of that size.
> > >
> > > Reported-by: p0her (_@p0her_) in TeamH4C working with TrendAI
> > > Zero
> > > Day Initiative
> > > Reported-by: Michael Bommarito <michael.bommarito@gmail.com>
> > > ---
> > > profiles/audio/a2dp.c | 10 +++++-----
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c
> > > index a5e002784c02..c8adc3122563 100644
> > > --- a/profiles/audio/a2dp.c
> > > +++ b/profiles/audio/a2dp.c
> > > @@ -971,7 +971,7 @@ static void store_remote_sep(void *data, void
> > > *user_data)
> > > {
> > > struct a2dp_remote_sep *sep = data;
> > > GKeyFile *key_file = user_data;
> > > - char seid[4], value[256];
> > > + char seid[4], value[9 + 512];
> >
> > What's the "9" value from? Shouldn't it be 11 for the length of:
> > "%02hhx:%02hhx:%02hhx:"
>
> 3 * 2 (%02hhx) + 3 (:) = 9
If you're doing a fixup, might be a good idea to add as a comment,
thanks!
>
> > The "Try loading with delay_reporting first" variant?
> >
> > > struct avdtp_service_capability *service =
> > > avdtp_get_codec(sep->sep);
> > > struct avdtp_media_codec_capability *codec;
> > > unsigned int i;
> > > @@ -2373,7 +2373,7 @@ static void load_remote_sep(struct
> > > a2dp_channel
> > > *chan, GKeyFile *key_file,
> > > uint8_t codec;
> > > uint8_t delay_reporting;
> > > GSList *l = NULL;
> > > - char caps[256];
> > > + char caps[513];
> > > uint8_t data[128];
> > > int i, size;
> > >
> > > @@ -2386,10 +2386,10 @@ static void load_remote_sep(struct
> > > a2dp_channel *chan, GKeyFile *key_file,
> > > continue;
> > >
> > > /* Try loading with delay_reporting first */
> > > - if (sscanf(value, "%02hhx:%02hhx:%02hhx:%s", &type,
> > > &codec,
> > > + if (sscanf(value, "%02hhx:%02hhx:%02hhx:%512s",
> > > &type, &codec,
> > > &delay_reporting, caps) !=
> > > 4) {
> > > /* Try old format */
> > > - if (sscanf(value, "%02hhx:%02hhx:%s",
> > > &type,
> > > &codec,
> > > + if (sscanf(value, "%02hhx:%02hhx:%512s",
> > > &type, &codec,
> > >
> > > caps
> > > ) != 3) {
> > > warn("Unable to load Endpoint: seid
> > > %u", rseid);
> > > g_free(value);
> > > @@ -2398,7 +2398,7 @@ static void load_remote_sep(struct
> > > a2dp_channel
> > > *chan, GKeyFile *key_file,
> > > delay_reporting = false;
> > > }
> > >
> > > - for (i = 0, size = strlen(caps); i < size; i += 2)
> > > {
> > > + for (i = 0, size = strlen(caps); i < size && i >=
> > > 2;
> > > i += 2) {
> > > uint8_t *tmp = data + i / 2;
> > >
> > > if (sscanf(caps + i, "%02hhx", tmp) != 1) {
>
>
^ permalink raw reply
* [PATCH] Bluetooth: MGMT: Fix adv monitor add failure cleanup
From: Cen Zhang @ 2026-06-23 16:13 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, baijiaju1990, zzzccc427
hci_add_adv_monitor() publishes a new adv_monitor in
hdev->adv_monitors_idr before the powered MSFT setup step. The MSFT
offload add path can then fail either locally before the controller add
command completes, or in the MSFT add callback. In the current queued
management add flow, hci_cmd_sync_work() still invokes
mgmt_add_adv_patterns_monitor_complete() with the original pending command
after msft_add_monitor_pattern() returns.
The buggy scenario involves two paths, with each column showing the order
within that path:
MSFT add handling MGMT completion
1. insert monitor and handle 1. receive sync error
2. send MSFT add command 2. call add-monitor completion
3. callback sees bad response 3. load cmd->user_data
4. callback frees monitor 4. read monitor->handle
Local MSFT setup failures have the other half of the same ownership bug:
they return an error after the IDR insertion, but no later code removes the
failed monitor from the IDR.
Keep ownership with the pending management command until its completion.
For normal management adds, the MSFT add callback now records successful
controller state and returns errors to its caller. The management
completion frees the monitor on non-success after copying the response
handle, while resume/reregister callback-error cleanup remains in the
MSFT callback. The success path keeps the existing bookkeeping.
Validation reproduced this kernel report:
BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth]
Call Trace:
<TASK>
dump_stack_lvl+0x66/0xa0
print_report+0xce/0x5f0
? mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth]
? srso_alias_return_thunk+0x5/0xfbef5
? __virt_addr_valid+0x19f/0x330
? mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth]
kasan_report+0xe0/0x110
? mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth]
mgmt_add_adv_patterns_monitor_complete+0xfb/0x260 [bluetooth]
? srso_alias_return_thunk+0x5/0xfbef5
? 0xffffffffc00d00da
? __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [bluetooth]
? __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [bluetooth]
? hci_cmd_sync_work+0x1ab/0x210 [bluetooth]
hci_cmd_sync_work+0x1c0/0x210 [bluetooth]
? __pfx_mgmt_add_adv_patterns_monitor_complete+0x10/0x10 [bluetooth]
process_one_work+0x4fd/0xbc0
? __pfx_process_one_work+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? srso_alias_return_thunk+0x5/0xfbef5
? __list_add_valid_or_report+0x37/0xf0
? __pfx_hci_cmd_sync_work+0x10/0x10 [bluetooth]
? srso_alias_return_thunk+0x5/0xfbef5
worker_thread+0x2d8/0x570
? __pfx_worker_thread+0x10/0x10
kthread+0x1ad/0x1f0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x3c9/0x540
? __pfx_ret_from_fork+0x10/0x10
? srso_alias_return_thunk+0x5/0xfbef5
? __switch_to+0x2e9/0x730
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Allocated by task 471 on cpu 3 at 285.205389s:
kasan_save_stack+0x33/0x60
kasan_save_track+0x17/0x60
__kasan_kmalloc+0xaa/0xb0
add_adv_patterns_monitor_rssi+0xd5/0x230 [bluetooth]
hci_sock_sendmsg+0x96b/0xf80 [bluetooth]
__sys_sendto+0x2bc/0x2d0
__x64_sys_sendto+0x76/0x90
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 454 on cpu 2 at 285.217112s:
kasan_save_stack+0x33/0x60
kasan_save_track+0x17/0x60
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x5f/0x80
kfree+0x313/0x590
msft_add_monitor_sync+0x54a/0x570 [bluetooth]
hci_add_adv_monitor+0x133/0x180 [bluetooth]
hci_cmd_sync_work+0x187/0x210 [bluetooth]
process_one_work+0x4fd/0xbc0
worker_thread+0x2d8/0x570
kthread+0x1ad/0x1f0
ret_from_fork+0x3c9/0x540
ret_from_fork_asm+0x1a/0x30
Fixes: a2a4dedf88ab ("Bluetooth: advmon offload MSFT add monitor")
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---
net/bluetooth/mgmt.c | 2 ++
net/bluetooth/msft.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index d23ca1dd0893..e5403c58a957 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -5375,6 +5375,8 @@ static void mgmt_add_adv_patterns_monitor_complete(struct hci_dev *hdev,
if (monitor->state == ADV_MONITOR_STATE_NOT_REGISTERED)
monitor->state = ADV_MONITOR_STATE_REGISTERED;
hci_update_passive_scan(hdev);
+ } else {
+ hci_free_adv_monitor(hdev, monitor);
}
mgmt_cmd_complete(cmd->sk, cmd->hdev->id, cmd->opcode,
diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c
index 2f008167cbaa..d7badce8746c 100644
--- a/net/bluetooth/msft.c
+++ b/net/bluetooth/msft.c
@@ -291,7 +291,7 @@ static int msft_le_monitor_advertisement_cb(struct hci_dev *hdev, u16 opcode,
monitor->state = ADV_MONITOR_STATE_OFFLOADED;
unlock:
- if (status)
+ if (status && msft->resuming)
hci_free_adv_monitor(hdev, monitor);
hci_dev_unlock(hdev);
--
2.43.0
^ permalink raw reply related
* [PATCH] Bluetooth: 6lowpan: hold L2CAP conn across debugfs control
From: Cen Zhang @ 2026-06-23 16:12 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, baijiaju1990, zzzccc427
get_l2cap_conn() looks up an LE hci_conn under hdev protection, but
then drops that protection before reading hcon->l2cap_data and before
lowpan_control_write() later dereferences conn->hcon. A disconnect or
device close can tear down the same L2CAP connection in that window.
The buggy scenario involves two paths, with each column showing the order
within that path:
6LoWPAN control write: HCI disconnect/device close:
1. get_l2cap_conn() finds hcon 1. hci_disconn_cfm() dispatches
and hcon->l2cap_data. the L2CAP disconnect callback.
2. get_l2cap_conn() drops hdev 2. l2cap_conn_del() clears
protection and returns conn. hcon->l2cap_data and drops the
L2CAP connection reference.
3. lowpan_control_write() reads 3. hci_conn_del() removes and drops
conn->hcon. the HCI connection.
Take a reference to the L2CAP connection with
l2cap_conn_hold_unless_zero() while hdev is still locked, and drop that
reference after the debugfs command's last use of conn. This mirrors the
existing L2CAP ACL receive-side handoff and keeps the connection
dereferenceable after leaving hdev protection. Export the existing helper
so the bluetooth_6lowpan module can use the same lifetime primitive.
Validation reproduced this kernel report:
BUG: KASAN: slab-use-after-free in lowpan_control_write+0x374/0x520
The buggy address belongs to the object at ffff888111b9d000 which belongs
to the cache kmalloc-1k of size 1024
The buggy address is located 0 bytes inside of freed 1024-byte region
[ffff888111b9d000, ffff888111b9d400)
Read of size 8
Call trace:
dump_stack_lvl+0x66/0xa0
print_report+0xce/0x5f0
lowpan_control_write+0x374/0x520 (net/bluetooth/6lowpan.c:1131)
srso_alias_return_thunk+0x5/0xfbef5
__virt_addr_valid+0x19f/0x330
kasan_report+0xe0/0x110
__debugfs_file_get+0xf7/0x400
full_proxy_write+0x9e/0xd0
vfs_write+0x1b0/0x810
ksys_write+0xd2/0x170
dnotify_flush+0x32/0x220
do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Allocated by task stack:
kasan_save_stack+0x33/0x60
kasan_save_track+0x17/0x60
__kasan_kmalloc+0xaa/0xb0
l2cap_conn_add+0x45/0x520
l2cap_chan_connect+0xac6/0xd90
l2cap_sock_connect+0x216/0x350
__sys_connect+0x101/0x130
__x64_sys_connect+0x40/0x50
do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task stack:
kasan_save_stack+0x33/0x60
kasan_save_track+0x17/0x60
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x5f/0x80
kfree+0x313/0x590
hci_conn_hash_flush+0xc0/0x140
hci_dev_close_sync+0x41a/0xb00
hci_dev_close+0x12f/0x160
hci_sock_ioctl+0x157/0x570
sock_do_ioctl+0xf7/0x210
sock_ioctl+0x32f/0x490
__x64_sys_ioctl+0xc7/0x110
do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)
entry_SYSCALL_64_after_hwframe+0x77/0x7f
kasan_record_aux_stack+0xa7/0xc0
insert_work+0x32/0x100
__queue_work+0x262/0xa60
queue_work_on+0xad/0xb0
l2cap_connect_cfm+0x4ef/0x670
hci_le_remote_feat_complete_evt+0x247/0x430
hci_event_packet+0x360/0x6f0
hci_rx_work+0x2ae/0x7a0
process_one_work+0x4fd/0xbc0
worker_thread+0x2d8/0x570
kthread+0x1ad/0x1f0
ret_from_fork+0x3c9/0x540
ret_from_fork_asm+0x1a/0x30
Fixes: 6b8d4a6a0314 ("Bluetooth: 6LoWPAN: Use connected oriented channel instead of fixed one")
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---
net/bluetooth/6lowpan.c | 21 +++++++++++++++------
net/bluetooth/l2cap_core.c | 1 +
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index cb1e329d66fd..2fa1cc3de796 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -1029,16 +1029,19 @@ static int get_l2cap_conn(char *buf, bdaddr_t *addr, u8 *addr_type,
hci_dev_lock(hdev);
hcon = hci_conn_hash_lookup_le(hdev, addr, le_addr_type);
- hci_dev_unlock(hdev);
- hci_dev_put(hdev);
-
- if (!hcon)
+ if (!hcon) {
+ hci_dev_unlock(hdev);
+ hci_dev_put(hdev);
return -ENOENT;
+ }
- *conn = (struct l2cap_conn *)hcon->l2cap_data;
+ *conn = l2cap_conn_hold_unless_zero(hcon->l2cap_data);
BT_DBG("conn %p dst %pMR type %u", *conn, &hcon->dst, hcon->dst_type);
+ hci_dev_unlock(hdev);
+ hci_dev_put(hdev);
+
return 0;
}
@@ -1185,18 +1188,22 @@ static ssize_t lowpan_control_write(struct file *fp,
if (conn) {
struct lowpan_peer *peer;
- if (!is_bt_6lowpan(conn->hcon))
+ if (!is_bt_6lowpan(conn->hcon)) {
+ l2cap_conn_put(conn);
return -EINVAL;
+ }
peer = lookup_peer(conn);
if (peer) {
BT_DBG("6LoWPAN connection already exists");
+ l2cap_conn_put(conn);
return -EALREADY;
}
BT_DBG("conn %p dst %pMR type %d user %u", conn,
&conn->hcon->dst, conn->hcon->dst_type,
addr_type);
+ l2cap_conn_put(conn);
}
ret = bt_6lowpan_connect(&addr, addr_type);
@@ -1212,6 +1219,8 @@ static ssize_t lowpan_control_write(struct file *fp,
return ret;
ret = bt_6lowpan_disconnect(conn, addr_type);
+ if (conn)
+ l2cap_conn_put(conn);
if (ret < 0)
return ret;
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 62133eef9d2f..ed668a782d3d 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -7702,6 +7702,7 @@ struct l2cap_conn *l2cap_conn_hold_unless_zero(struct l2cap_conn *c)
return c;
}
+EXPORT_SYMBOL(l2cap_conn_hold_unless_zero);
int l2cap_recv_acldata(struct hci_dev *hdev, u16 handle,
struct sk_buff *skb, u16 flags)
--
2.43.0
^ permalink raw reply related
* [PATCH] Bluetooth: 6lowpan: avoid untracked enable work
From: Cen Zhang @ 2026-06-23 16:12 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-bluetooth, baijiaju1990, zzzccc427
lowpan_enable_set() allocates a temporary work item and schedules
do_enable_set() on system_wq, then returns to debugfs. The debugfs active
operation has ended at that point, but the worker still executes module
text and manipulates enable_6lowpan and listen_chan.
bt_6lowpan_exit() removes the debugfs files and immediately closes and
puts listen_chan. It has no pointer to the queued work item, so it cannot
cancel or flush it before tearing down the state that the worker uses.
The buggy scenario involves two paths, with each column showing the order
within that path:
debugfs enable write module exit
1. lowpan_enable_set() allocates 1. bt_6lowpan_exit() removes
set_enable work the debugfs file
2. schedule_work() queues 2. bt_6lowpan_exit() closes
do_enable_set() and puts listen_chan
3. the write operation returns 3. module teardown can continue
4. do_enable_set() later runs
against stale state
Run the enable state transition synchronously in lowpan_enable_set()
instead. The simple debugfs setter can sleep, and this file already handles
the 6LoWPAN control write synchronously under the same set_lock. Once the
setter returns, debugfs removal covers the whole operation and exit can no
longer race with an untracked work item.
Validation reproduced this kernel report:
BUG: KASAN: slab-use-after-free in do_enable_set+0x113/0x2e0
Workqueue: events do_enable_set [bluetooth_6lowpan]
The buggy address belongs to the object at ffff888109cb8000
Fixes: 90305829635d ("Bluetooth: 6lowpan: Converting rwlocks to use RCU")
Assisted-by: Codex:gpt-5.5
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
---
net/bluetooth/6lowpan.c | 27 ++++-----------------------
1 file changed, 4 insertions(+), 23 deletions(-)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index cb1e329d66fd..249feca42501 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -1093,23 +1093,15 @@ static void disconnect_all_peers(void)
} while (nchans);
}
-struct set_enable {
- struct work_struct work;
- bool flag;
-};
-
-static void do_enable_set(struct work_struct *work)
+static void do_enable_set(bool flag)
{
- struct set_enable *set_enable = container_of(work,
- struct set_enable, work);
-
- if (!set_enable->flag || enable_6lowpan != set_enable->flag)
+ if (!flag || enable_6lowpan != flag)
/* Disconnect existing connections if 6lowpan is
* disabled
*/
disconnect_all_peers();
- enable_6lowpan = set_enable->flag;
+ enable_6lowpan = flag;
mutex_lock(&set_lock);
if (listen_chan) {
@@ -1121,22 +1113,11 @@ static void do_enable_set(struct work_struct *work)
listen_chan = bt_6lowpan_listen();
mutex_unlock(&set_lock);
-
- kfree(set_enable);
}
static int lowpan_enable_set(void *data, u64 val)
{
- struct set_enable *set_enable;
-
- set_enable = kzalloc_obj(*set_enable);
- if (!set_enable)
- return -ENOMEM;
-
- set_enable->flag = !!val;
- INIT_WORK(&set_enable->work, do_enable_set);
-
- schedule_work(&set_enable->work);
+ do_enable_set(!!val);
return 0;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 12/13] Bluetooth: btqca: Fix undetected error HCI status in qca_send_reset()
From: Luiz Augusto von Dentz @ 2026-06-23 15:15 UTC (permalink / raw)
To: Zijun Hu
Cc: Marcel Holtmann, Rocky Liao, Bartosz Golaszewski,
Ben Young Tae Kim, Balakrishna Godavarthi, Matthias Kaehlcke,
Zijun Hu, linux-bluetooth, linux-kernel, Luiz Augusto von Dentz,
linux-arm-msm
In-Reply-To: <20260622-bt_bugfix-v1-12-11f936d84e72@oss.qualcomm.com>
Hi Zijun,
On Mon, Jun 22, 2026 at 10:52 AM Zijun Hu <zijun.hu@oss.qualcomm.com> wrote:
>
> qca_send_reset() uses __hci_cmd_sync() which returns an skb but never
> reads the HCI status byte from skb->data[0], so a non-zero error status
> returned by the controller is silently ignored.
>
> Fix by replacing qca_send_reset() with __hci_reset_sync() which
> properly extracts and converts the HCI status byte to a negative errno.
>
> Fixes: 83e81961ff7e ("Bluetooth: btqca: Introduce generic QCA ROME support")
> Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
> ---
> drivers/bluetooth/btqca.c | 22 ++--------------------
> 1 file changed, 2 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> index 04ebe290bc78..875216e15603 100644
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
> @@ -190,25 +190,6 @@ static int qca_send_patch_config_cmd(struct hci_dev *hdev)
> return err;
> }
>
> -static int qca_send_reset(struct hci_dev *hdev)
> -{
> - struct sk_buff *skb;
> - int err;
> -
> - bt_dev_dbg(hdev, "QCA HCI_RESET");
> -
> - skb = __hci_cmd_sync(hdev, HCI_OP_RESET, 0, NULL, HCI_INIT_TIMEOUT);
> - if (IS_ERR(skb)) {
> - err = PTR_ERR(skb);
> - bt_dev_err(hdev, "QCA Reset failed (%d)", err);
> - return err;
> - }
> -
> - kfree_skb(skb);
> -
> - return 0;
> -}
> -
> static int qca_read_fw_board_id(struct hci_dev *hdev, u16 *bid)
> {
> u8 cmd;
> @@ -990,7 +971,8 @@ int qca_uart_setup(struct hci_dev *hdev, uint8_t baudrate,
> }
>
> /* Perform HCI reset */
> - err = qca_send_reset(hdev);
> + bt_dev_dbg(hdev, "QCA HCI_RESET");
> + err = __hci_reset_sync(hdev);
So All the fuss about the reset is just to use it here? Actually the
distinction between -err and status is rather important. The first
means the command didn't run (timeout, cancel, etc), or it did run but
returned a status != 0. If you want to capture both then you must use
if (err). And yes there are parts of the code that test for < 0, but
that is either a bug or they are intentionally ignoring the reset
status as it is probably a non-recoverable error at that point.
> if (err < 0) {
> bt_dev_err(hdev, "QCA Failed to run HCI_RESET (%d)", err);
> return err;
>
> --
> 2.34.1
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1
From: Luiz Augusto von Dentz @ 2026-06-23 15:04 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, Herbert Xu, linux-kernel, linux-doc,
linux-bluetooth, iwd, linux-hardening, Milan Broz,
Demi Marie Obenour, Andy Lutomirski
In-Reply-To: <20260622234803.6982-1-ebiggers@kernel.org>
Hi Eric,
On Mon, Jun 22, 2026 at 7:50 PM Eric Biggers <ebiggers@kernel.org> wrote:
>
> AF_ALG is a frequent source of vulnerabilities and a maintenance
> nightmare. It exposes far more functionality to userspace than ever
> should have been exposed, especially to unprivileged processes. Recent
> exploits have targeted kernel internal implementation details like
> "authencesn" that have zero use case for userspace access.
>
> Fortunately, AF_ALG is rarely used in practice, as userspace crypto
> libraries exist. And when it is used, only some functionality is known
> to be used, and many users are known to hold capabilities already.
> iwd for example requires CAP_NET_ADMIN and has a known algorithm list
> (https://lore.kernel.org/linux-crypto/bcbbef00-5881-421b-8892-7be6c04b832d@gmail.com/).
>
> Thus, let's restrict the set of allowed algorithms by default, depending
> on the capabilities held.
>
> Add a sysctl /proc/sys/crypto/af_alg_restrict with meaning:
>
> 0: unrestricted
> 1: limited functionality
> 2: completely disabled
>
> Set the default value to 1, which enables an algorithm allowlist for
> unprivileged processes and a slightly longer allowlist for privileged
> processes.
>
> Note that the list may be tweaked in the future. However, the common
> use cases such as iwd and bluez are taken into account already. I've
> tested that iwd still works with the default value of 1.
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> Documentation/admin-guide/sysctl/crypto.rst | 36 +++++++++++
> Documentation/crypto/userspace-if.rst | 13 +++-
> crypto/af_alg.c | 72 +++++++++++++++++++--
> crypto/algif_aead.c | 11 ++++
> crypto/algif_hash.c | 24 +++++++
> crypto/algif_rng.c | 9 +++
> crypto/algif_skcipher.c | 20 ++++++
> include/crypto/if_alg.h | 8 +++
> 8 files changed, 184 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/admin-guide/sysctl/crypto.rst b/Documentation/admin-guide/sysctl/crypto.rst
> index b707bd314a64..9a1bd53287f4 100644
> --- a/Documentation/admin-guide/sysctl/crypto.rst
> +++ b/Documentation/admin-guide/sysctl/crypto.rst
> @@ -5,10 +5,46 @@
> These files show up in ``/proc/sys/crypto/``, depending on the
> kernel configuration:
>
> .. contents:: :local:
>
> +.. _af_alg_restrict:
> +
> +af_alg_restrict
> +===============
> +
> +Controls the level of restriction of AF_ALG.
> +
> +AF_ALG is a deprecated and rarely-used userspace interface that is a
> +frequent source of vulnerabilities. It also unnecessarily exposes a
> +large number of kernel implementation details. For more information
> +about AF_ALG, see :ref:`Documentation/crypto/userspace-if.rst
> +<crypto_userspace_interface>`.
> +
> +Starting in Linux v7.3, AF_ALG supports only a limited set of
> +algorithms by default. This sysctl allows the system administrator to
> +remove this restriction when needed for compatibility reasons, or to
> +go further and disable AF_ALG entirely. The default value is 1.
> +
> +=== ==================================================================
> +0 AF_ALG is unrestricted.
> +
> +1 AF_ALG is supported with a limited list of algorithms. The list
> + is designed for compatibility with known users such as iwd and
> + bluez that haven't yet been fixed to use userspace crypto code.
Is the expectation that we go shopping for userspace crypto here? This
would mean the Bluetooth stack would use 2 different crypto stacks:
the kernel for module parts and a userspace library for components
like bluetoothd, resulting in 2 different sources to audit. So, while
I agree we should restrict it to just the algorithms in use and with
capabilities, I don't think we should assume the current userspace
users are broken and need fixing.
> + Specifically, there is an allowlist for unprivileged processes
> + and a somewhat longer allowlist for processes that hold
> + CAP_SYS_ADMIN or CAP_NET_ADMIN in the initial user namespace.
> +
> + Attempts to bind() an AF_ALG socket with a disallowed algorithm
> + fail with ENOENT.
> +
> +2 AF_ALG is completely disabled. Attempts to create an AF_ALG
> + socket fail with EAFNOSUPPORT.
> +=== ==================================================================
> +
> fips_enabled
> ============
>
> Read-only flag that indicates whether FIPS mode is enabled.
>
> diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
> index ab93300c8e04..d6194346e366 100644
> --- a/Documentation/crypto/userspace-if.rst
> +++ b/Documentation/crypto/userspace-if.rst
> @@ -1,5 +1,7 @@
> +.. _crypto_userspace_interface:
> +
> User Space Interface
> ====================
>
> Introduction
> ------------
> @@ -10,13 +12,18 @@ code.
>
> AF_ALG is insecure and is deprecated. Originally added to the kernel in 2010,
> most kernel developers now consider it to be a mistake. Support for hardware
> accelerators, which was the original purpose of AF_ALG, has been removed.
>
> -AF_ALG continues to be supported only for backwards compatibility. On systems
> -where no programs using AF_ALG remain, the support for it should be disabled by
> -disabling ``CONFIG_CRYPTO_USER_API_*``.
> +AF_ALG continues to be supported only for backwards compatibility.
> +
> +Starting in Linux v7.3, the set of algorithms supported by AF_ALG is limited by
> +default. See :ref:`/proc/sys/crypto/af_alg_restrict <af_alg_restrict>`.
> +
> +On systems where no programs using AF_ALG remain, the support for it should be
> +disabled entirely by setting ``/proc/sys/crypto/af_alg_restrict`` to 2 or by
> +disabling ``CONFIG_CRYPTO_USER_API_*`` in the kernel configuration.
>
> Deprecation
> -----------
>
> AF_ALG was originally intended to provide userspace programs access to crypto
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
> index cce000e8590e..34b801568fba 100644
> --- a/crypto/af_alg.c
> +++ b/crypto/af_alg.c
> @@ -6,10 +6,11 @@
> *
> * Copyright (c) 2010 Herbert Xu <herbert@gondor.apana.org.au>
> */
>
> #include <linux/atomic.h>
> +#include <linux/capability.h>
> #include <crypto/if_alg.h>
> #include <linux/crypto.h>
> #include <linux/init.h>
> #include <linux/kernel.h>
> #include <linux/key.h>
> @@ -20,14 +21,32 @@
> #include <linux/rwsem.h>
> #include <linux/sched.h>
> #include <linux/sched/signal.h>
> #include <linux/security.h>
> #include <linux/string.h>
> +#include <linux/sysctl.h>
> +#include <linux/user_namespace.h>
> #include <keys/user-type.h>
> #include <keys/trusted-type.h>
> #include <keys/encrypted-type.h>
>
> +static int af_alg_restrict = 1;
> +
> +static const struct ctl_table af_alg_table[] = {
> + {
> + .procname = "af_alg_restrict",
> + .data = &af_alg_restrict,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec_minmax,
> + .extra1 = SYSCTL_ZERO,
> + .extra2 = SYSCTL_TWO,
> + },
> +};
> +
> +static struct ctl_table_header *af_alg_header;
> +
> struct alg_type_list {
> const struct af_alg_type *type;
> struct list_head list;
> };
>
> @@ -108,10 +127,43 @@ int af_alg_unregister_type(const struct af_alg_type *type)
>
> return err;
> }
> EXPORT_SYMBOL_GPL(af_alg_unregister_type);
>
> +static bool af_alg_capable(void)
> +{
> + return ns_capable_noaudit(&init_user_ns, CAP_NET_ADMIN) ||
> + capable(CAP_SYS_ADMIN);
> +}
> +
> +int af_alg_check_restriction(const char *name,
> + const struct af_alg_allowlist_entry allowlist[])
> +{
> + int level = READ_ONCE(af_alg_restrict);
> +
> + if (level == 0)
> + return 0;
> + if (level == 1) {
> + for (const struct af_alg_allowlist_entry *ent = allowlist;
> + ent->name; ent++) {
> + if (strcmp(name, ent->name) == 0 &&
> + (!ent->privileged || af_alg_capable()))
> + return 0;
> + }
> + }
> + /*
> + * Use -ENOENT (the error code for "algorithm not found") instead of
> + * -EACCES or -EPERM, for the highest chance of correctly triggering
> + * fallback code paths in userspace programs.
> + *
> + * Don't log a warning, since it would be noisy. iwd tries to bind a
> + * bunch of algorithms that it never uses.
> + */
> + return -ENOENT;
> +}
> +EXPORT_SYMBOL_GPL(af_alg_check_restriction);
> +
> static void alg_do_release(const struct af_alg_type *type, void *private)
> {
> if (!type)
> return;
>
> @@ -504,10 +556,13 @@ static int alg_create(struct net *net, struct socket *sock, int protocol,
> int kern)
> {
> struct sock *sk;
> int err;
>
> + if (READ_ONCE(af_alg_restrict) == 2)
> + return -EAFNOSUPPORT;
> +
> if (sock->type != SOCK_SEQPACKET)
> return -ESOCKTNOSUPPORT;
> if (protocol != 0)
> return -EPROTONOSUPPORT;
>
> @@ -1220,31 +1275,36 @@ int af_alg_get_rsgl(struct sock *sk, struct msghdr *msg, int flags,
> }
> EXPORT_SYMBOL_GPL(af_alg_get_rsgl);
>
> static int __init af_alg_init(void)
> {
> - int err = proto_register(&alg_proto, 0);
> + int err;
> +
> + af_alg_header = register_sysctl("crypto", af_alg_table);
>
> + err = proto_register(&alg_proto, 0);
> if (err)
> - goto out;
> + goto out_unregister_sysctl;
>
> err = sock_register(&alg_family);
> - if (err != 0)
> + if (err)
> goto out_unregister_proto;
>
> -out:
> - return err;
> + return 0;
>
> out_unregister_proto:
> proto_unregister(&alg_proto);
> - goto out;
> +out_unregister_sysctl:
> + unregister_sysctl_table(af_alg_header);
> + return err;
> }
>
> static void __exit af_alg_exit(void)
> {
> sock_unregister(PF_ALG);
> proto_unregister(&alg_proto);
> + unregister_sysctl_table(af_alg_header);
> }
>
> module_init(af_alg_init);
> module_exit(af_alg_exit);
> MODULE_DESCRIPTION("Crypto userspace interface");
> diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
> index 787aac8aeb24..b9217f9086aa 100644
> --- a/crypto/algif_aead.c
> +++ b/crypto/algif_aead.c
> @@ -32,10 +32,15 @@
> #include <linux/mm.h>
> #include <linux/module.h>
> #include <linux/net.h>
> #include <net/sock.h>
>
> +static const struct af_alg_allowlist_entry aead_allowlist[] = {
> + { "ccm(aes)", true }, /* bluez */
> + {},
> +};
> +
> static inline bool aead_sufficient_data(struct sock *sk)
> {
> struct alg_sock *ask = alg_sk(sk);
> struct sock *psk = ask->parent;
> struct alg_sock *pask = alg_sk(psk);
> @@ -342,10 +347,16 @@ static struct proto_ops algif_aead_ops_nokey = {
> .poll = af_alg_poll,
> };
>
> static void *aead_bind(const char *name)
> {
> + int err;
> +
> + err = af_alg_check_restriction(name, aead_allowlist);
> + if (err)
> + return ERR_PTR(err);
> +
> return crypto_alloc_aead(name, 0, AF_ALG_CRYPTOAPI_MASK);
> }
>
> static void aead_release(void *private)
> {
> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
> index 5452ad6c1506..a8d958d51ece 100644
> --- a/crypto/algif_hash.c
> +++ b/crypto/algif_hash.c
> @@ -14,10 +14,28 @@
> #include <linux/mm.h>
> #include <linux/module.h>
> #include <linux/net.h>
> #include <net/sock.h>
>
> +static const struct af_alg_allowlist_entry hash_allowlist[] = {
> + { "cmac(aes)", true }, /* iwd, bluez */
> + { "hmac(md5)", true }, /* iwd */
> + { "hmac(sha1)", true }, /* iwd */
> + { "hmac(sha224)", true }, /* iwd */
> + { "hmac(sha256)", true }, /* iwd */
> + { "hmac(sha384)", true }, /* iwd */
> + { "hmac(sha512)", true }, /* iwd, sha512hmac */
> + { "md4", true }, /* iwd */
> + { "md5", true }, /* iwd */
> + { "sha1", false }, /* iwd, iproute2 < 7.0 */
> + { "sha224", true }, /* iwd */
> + { "sha256", true }, /* iwd */
> + { "sha384", true }, /* iwd */
> + { "sha512", true }, /* iwd */
> + {},
> +};
> +
> struct hash_ctx {
> struct af_alg_sgl sgl;
>
> u8 *result;
>
> @@ -380,10 +398,16 @@ static struct proto_ops algif_hash_ops_nokey = {
> .accept = hash_accept_nokey,
> };
>
> static void *hash_bind(const char *name)
> {
> + int err;
> +
> + err = af_alg_check_restriction(name, hash_allowlist);
> + if (err)
> + return ERR_PTR(err);
> +
> return crypto_alloc_ahash(name, 0, AF_ALG_CRYPTOAPI_MASK);
> }
>
> static void hash_release(void *private)
> {
> diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
> index 4dfe7899f8fa..bd522915d56d 100644
> --- a/crypto/algif_rng.c
> +++ b/crypto/algif_rng.c
> @@ -48,10 +48,14 @@
>
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("Stephan Mueller <smueller@chronox.de>");
> MODULE_DESCRIPTION("User-space interface for random number generators");
>
> +static const struct af_alg_allowlist_entry rng_allowlist[] = {
> + {},
> +};
> +
> struct rng_ctx {
> #define MAXSIZE 128
> unsigned int len;
> struct crypto_rng *drng;
> u8 *addtl;
> @@ -199,10 +203,15 @@ static struct proto_ops __maybe_unused algif_rng_test_ops = {
>
> static void *rng_bind(const char *name)
> {
> struct rng_parent_ctx *pctx;
> struct crypto_rng *rng;
> + int err;
> +
> + err = af_alg_check_restriction(name, rng_allowlist);
> + if (err)
> + return ERR_PTR(err);
>
> pctx = kzalloc_obj(*pctx);
> if (!pctx)
> return ERR_PTR(-ENOMEM);
>
> diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
> index df20bdfe1f1f..2b8069667974 100644
> --- a/crypto/algif_skcipher.c
> +++ b/crypto/algif_skcipher.c
> @@ -32,10 +32,24 @@
> #include <linux/mm.h>
> #include <linux/module.h>
> #include <linux/net.h>
> #include <net/sock.h>
>
> +static const struct af_alg_allowlist_entry skcipher_allowlist[] = {
> + { "adiantum(xchacha12,aes)", false }, /* cryptsetup */
> + { "adiantum(xchacha20,aes)", false }, /* cryptsetup */
> + { "cbc(aes)", true }, /* iwd */
> + { "cbc(des)", true }, /* iwd */
> + { "cbc(des3_ede)", true }, /* iwd */
> + { "ctr(aes)", true }, /* iwd */
> + { "ecb(aes)", true }, /* iwd, bluez */
> + { "ecb(des)", true }, /* iwd */
> + { "hctr2(aes)", false }, /* cryptsetup */
> + { "xts(aes)", false }, /* cryptsetup benchmark */
> + {},
> +};
> +
> static int skcipher_sendmsg(struct socket *sock, struct msghdr *msg,
> size_t size)
> {
> struct sock *sk = sock->sk;
> struct alg_sock *ask = alg_sk(sk);
> @@ -307,10 +321,16 @@ static struct proto_ops algif_skcipher_ops_nokey = {
> .poll = af_alg_poll,
> };
>
> static void *skcipher_bind(const char *name)
> {
> + int err;
> +
> + err = af_alg_check_restriction(name, skcipher_allowlist);
> + if (err)
> + return ERR_PTR(err);
> +
> return crypto_alloc_skcipher(name, 0, AF_ALG_CRYPTOAPI_MASK);
> }
>
> static void skcipher_release(void *private)
> {
> diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
> index 7643ba954125..4e9ed8e73403 100644
> --- a/include/crypto/if_alg.h
> +++ b/include/crypto/if_alg.h
> @@ -159,13 +159,21 @@ struct af_alg_ctx {
> unsigned int len;
>
> unsigned int inflight;
> };
>
> +struct af_alg_allowlist_entry {
> + const char *name;
> + bool privileged;
> +};
> +
> int af_alg_register_type(const struct af_alg_type *type);
> int af_alg_unregister_type(const struct af_alg_type *type);
>
> +int af_alg_check_restriction(const char *name,
> + const struct af_alg_allowlist_entry allowlist[]);
> +
> int af_alg_release(struct socket *sock);
> void af_alg_release_parent(struct sock *sk);
> int af_alg_accept(struct sock *sk, struct socket *newsock,
> struct proto_accept_arg *arg);
>
>
> base-commit: 1dc18801be29bc54709aa355b8acd80e183b03cd
> --
> 2.54.0
>
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: btusb: Add IMC Networks MT7922 device 0x13d3:0x3625
From: Paul Menzel @ 2026-06-23 14:48 UTC (permalink / raw)
To: Gustavo Evgucci
Cc: linux-bluetooth, marcel, Luiz Augusto von Dentz, linux-bluetooth,
LKML
In-Reply-To: <20260623114937.6385-1-monesss315@gmail.com>
Dear Gustavo,
Thank you for your patch. Just a note to add all listed MAINTAINERS
entries to the receivers (`scripts/get_maintainer.pl
drivers/bluetooth/btusb.c`).
Am 23.06.26 um 13:49 schrieb monesss315:
> From: Gustavo Evgucci <monesss315@gmail.com>
>
> The IMC Networks MT7922 Bluetooth adapter with USB ID 13d3:3625 is not
> recognized as a MediaTek device because it is missing from the btusb
> device ID table. As a result, btmtk firmware loading is never triggered
> and the HCI reset command times out with -ETIMEDOUT.
>
> Add the device with BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH flags,
> consistent with the neighboring 13d3:3627, 13d3:3628 and 13d3:3630
> entries which use the same chip.
>
> Tested on: MediaTek MT7922 (Wi-Fi 6E combo card, IMC Networks BT USB
> interface), kernel 7.0.11-arch1-1.
It’s common to add the output of `/sys/kernel/debug/usb/devices` to the
commit message, cf `git log drivers/bluetooth/btusb.c`.
> Signed-off-by: Gustavo Evgucci <monesss315@gmail.com>
> ---
> drivers/bluetooth/btusb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -755,6 +755,8 @@ static const struct usb_device_id btusb_table[] = {
> BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x13d3, 0x3613), .driver_info = BTUSB_MEDIATEK |
> BTUSB_WIDEBAND_SPEECH },
> + { USB_DEVICE(0x13d3, 0x3625), .driver_info = BTUSB_MEDIATEK |
> + BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x13d3, 0x3627), .driver_info = BTUSB_MEDIATEK |
> BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x13d3, 0x3628), .driver_info = BTUSB_MEDIATEK |
Feel free to add:
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH V2 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Frank Li @ 2026-06-23 14:32 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl, imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260623030736.1421537-2-sherry.sun@oss.nxp.com>
On Tue, Jun 23, 2026 at 11:07:28AM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> suspend to preserve wakeup capability of the devices and also not to power
> on the devices in the init path.
> This allows controller power-off to be skipped when some devices(e.g. M.2
> cards key E without auxiliary power) required to support PCIe L2 link state
> and wake-up mechanisms.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 36 +++++++++++++++++----------
> 1 file changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 0fa716d1ed75..ff5a9565dbbf 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -1382,16 +1382,20 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> }
> }
>
> - ret = pci_pwrctrl_create_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to create pwrctrl devices\n");
> - goto err_reg_disable;
> + if (!pci->suspended) {
> + ret = pci_pwrctrl_create_devices(dev);
Is possible move pci_pwrctrl_create_devices() of pci_pwrctrl_create_devices
and call it direct at probe() function, like other regulator_get function.
Frank
> + if (ret) {
> + dev_err(dev, "failed to create pwrctrl devices\n");
> + goto err_reg_disable;
> + }
> }
>
> - ret = pci_pwrctrl_power_on_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to power on pwrctrl devices\n");
> - goto err_pwrctrl_destroy;
> + if (!pp->skip_pwrctrl_off) {
> + ret = pci_pwrctrl_power_on_devices(dev);
> + if (ret) {
> + dev_err(dev, "failed to power on pwrctrl devices\n");
> + goto err_pwrctrl_destroy;
> + }
> }
>
> ret = imx_pcie_clk_enable(imx_pcie);
> @@ -1460,9 +1464,10 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> err_clk_disable:
> imx_pcie_clk_disable(imx_pcie);
> err_pwrctrl_power_off:
> - pci_pwrctrl_power_off_devices(dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(dev);
> err_pwrctrl_destroy:
> - if (ret != -EPROBE_DEFER)
> + if (ret != -EPROBE_DEFER && !pci->suspended)
> pci_pwrctrl_destroy_devices(dev);
> err_reg_disable:
> if (imx_pcie->vpcie)
> @@ -1482,7 +1487,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp *pp)
> }
> imx_pcie_clk_disable(imx_pcie);
>
> - pci_pwrctrl_power_off_devices(pci->dev);
> + if (!pci->pp.skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(pci->dev);
> if (imx_pcie->vpcie)
> regulator_disable(imx_pcie->vpcie);
> }
> @@ -1990,12 +1996,16 @@ static int imx_pcie_probe(struct platform_device *pdev)
> static void imx_pcie_shutdown(struct platform_device *pdev)
> {
> struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> + struct dw_pcie *pci = imx_pcie->pci;
> + struct dw_pcie_rp *pp = &pci->pp;
>
> /* bring down link, so bootloader gets clean state in case of reboot */
> imx_pcie_assert_core_reset(imx_pcie);
> imx_pcie_assert_perst(imx_pcie, true);
> - pci_pwrctrl_power_off_devices(&pdev->dev);
> - pci_pwrctrl_destroy_devices(&pdev->dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(&pdev->dev);
> + if (!pci->suspended)
> + pci_pwrctrl_destroy_devices(&pdev->dev);
> }
>
> static const struct imx_pcie_drvdata drvdata[] = {
> --
> 2.50.1
>
>
^ permalink raw reply
* Re: [PATCH BlueZ v2] a2dp: Fix handling of codec capability storage
From: Luiz Augusto von Dentz @ 2026-06-23 14:30 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth
In-Reply-To: <95343429b8f06e1c88e2c642471f6f8495e11280.camel@hadess.net>
Hi Bastien,
On Tue, Jun 23, 2026 at 8:18 AM Bastien Nocera <hadess@hadess.net> wrote:
>
> On Mon, 2026-06-22 at 11:56 -0400, Luiz Augusto von Dentz wrote:
> > From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> >
> > Codec capability is one byte long (max 255) the storage format is
> > 02hhx which means each byte ends up as 2 characters so the buffer
> > needs to be doubled in order to handle capabilities of that size.
> >
> > Reported-by: p0her (_@p0her_) in TeamH4C working with TrendAI Zero
> > Day Initiative
> > Reported-by: Michael Bommarito <michael.bommarito@gmail.com>
> > ---
> > profiles/audio/a2dp.c | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c
> > index a5e002784c02..c8adc3122563 100644
> > --- a/profiles/audio/a2dp.c
> > +++ b/profiles/audio/a2dp.c
> > @@ -971,7 +971,7 @@ static void store_remote_sep(void *data, void
> > *user_data)
> > {
> > struct a2dp_remote_sep *sep = data;
> > GKeyFile *key_file = user_data;
> > - char seid[4], value[256];
> > + char seid[4], value[9 + 512];
>
> What's the "9" value from? Shouldn't it be 11 for the length of:
> "%02hhx:%02hhx:%02hhx:"
3 * 2 (%02hhx) + 3 (:) = 9
> The "Try loading with delay_reporting first" variant?
>
> > struct avdtp_service_capability *service =
> > avdtp_get_codec(sep->sep);
> > struct avdtp_media_codec_capability *codec;
> > unsigned int i;
> > @@ -2373,7 +2373,7 @@ static void load_remote_sep(struct a2dp_channel
> > *chan, GKeyFile *key_file,
> > uint8_t codec;
> > uint8_t delay_reporting;
> > GSList *l = NULL;
> > - char caps[256];
> > + char caps[513];
> > uint8_t data[128];
> > int i, size;
> >
> > @@ -2386,10 +2386,10 @@ static void load_remote_sep(struct
> > a2dp_channel *chan, GKeyFile *key_file,
> > continue;
> >
> > /* Try loading with delay_reporting first */
> > - if (sscanf(value, "%02hhx:%02hhx:%02hhx:%s", &type,
> > &codec,
> > + if (sscanf(value, "%02hhx:%02hhx:%02hhx:%512s",
> > &type, &codec,
> > &delay_reporting, caps) !=
> > 4) {
> > /* Try old format */
> > - if (sscanf(value, "%02hhx:%02hhx:%s", &type,
> > &codec,
> > + if (sscanf(value, "%02hhx:%02hhx:%512s",
> > &type, &codec,
> > caps
> > ) != 3) {
> > warn("Unable to load Endpoint: seid
> > %u", rseid);
> > g_free(value);
> > @@ -2398,7 +2398,7 @@ static void load_remote_sep(struct a2dp_channel
> > *chan, GKeyFile *key_file,
> > delay_reporting = false;
> > }
> >
> > - for (i = 0, size = strlen(caps); i < size; i += 2) {
> > + for (i = 0, size = strlen(caps); i < size && i >= 2;
> > i += 2) {
> > uint8_t *tmp = data + i / 2;
> >
> > if (sscanf(caps + i, "%02hhx", tmp) != 1) {
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH V2 3/8] Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq
From: Frank Li @ 2026-06-23 14:24 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl, imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260623030736.1421537-4-sherry.sun@oss.nxp.com>
On Tue, Jun 23, 2026 at 11:07:30AM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> Power supply to the M.2 Bluetooth device attached to the host using M.2
> connector is controlled using the 'uart' pwrseq device. So add support for
> getting the pwrseq device if the OF graph link is present. Once obtained,
> pwrseq_power_on() is called to power up the M.2 Bluetooth card. The power
> sequencer descriptor is obtained via devm_pwrseq_get(), so the power-off
> and cleanup are handled automatically when the device is unbound.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/bluetooth/btnxpuart.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> index e7036a48ce48..438ccaa2b56d 100644
> --- a/drivers/bluetooth/btnxpuart.c
> +++ b/drivers/bluetooth/btnxpuart.c
> @@ -9,6 +9,8 @@
>
> #include <linux/serdev.h>
> #include <linux/of.h>
> +#include <linux/of_graph.h>
> +#include <linux/pwrseq/consumer.h>
> #include <linux/skbuff.h>
> #include <linux/unaligned.h>
> #include <linux/firmware.h>
> @@ -1866,6 +1868,18 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
> return err;
> }
>
> + if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
> + struct pwrseq_desc *pwrseq;
> +
> + pwrseq = devm_pwrseq_get(&serdev->ctrl->dev, "uart");
> + if (IS_ERR(pwrseq))
> + return PTR_ERR(pwrseq);
> +
> + err = pwrseq_power_on(pwrseq);
> + if (err)
> + return err;
> + }
> +
> /* Initialize and register HCI device */
> hdev = hci_alloc_dev();
> if (!hdev) {
> --
> 2.50.1
>
>
^ permalink raw reply
* RE: Bluetooth: btusb: Add IMC Networks MT7922 device 0x13d3:0x3625
From: bluez.test.bot @ 2026-06-23 12:46 UTC (permalink / raw)
To: linux-bluetooth, monesss315
In-Reply-To: <20260623114937.6385-1-monesss315@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1181 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=1115344
---Test result---
Test Summary:
CheckPatch PASS 0.91 seconds
VerifyFixes PASS 0.15 seconds
VerifySignedoff PASS 0.17 seconds
GitLint PASS 0.46 seconds
SubjectPrefix PASS 0.23 seconds
BuildKernel PASS 19.93 seconds
CheckAllWarning PASS 21.83 seconds
CheckSparse PASS 27.75 seconds
BuildKernel32 PASS 19.44 seconds
CheckKernelLLVM SKIP 0.00 seconds
TestRunnerSetup PASS 417.08 seconds
IncrementalBuild PASS 19.35 seconds
Details
##############################
Test: CheckKernelLLVM - SKIP
Desc: Build kernel with LLVM + context analysis
Output:
Clang not found
https://github.com/bluez/bluetooth-next/pull/339
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Bastien Nocera @ 2026-06-23 12:44 UTC (permalink / raw)
To: Eric Biggers, linux-crypto, Herbert Xu, Marcel Holtmann,
Luiz Augusto von Dentz
Cc: linux-doc, linux-api, linux-kernel, netdev, Linus Torvalds,
linux-bluetooth, ell
In-Reply-To: <20260430011544.31823-1-ebiggers@kernel.org>
Hey,
Replying to this older patch.
On Wed, 2026-04-29 at 18:15 -0700, Eric Biggers wrote:
<snip>
> This isn't intended to change anything overnight. After all, most Linux
> distros won't be able to disable the kconfig options quite yet, mainly
> because of iwd. But this should create a bit more impetus for these
> userspace programs to be fixed, and the documentation update should also
> help prevent more users from appearing.
There are 2 other users that I know of: bluez, and the ell library
(used by iwd and bluez).
From what I could tell, bluetoothd uses AF_ALG for cryptography:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/shared/crypto.c
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/tools/mesh-gatt/crypto.c
It uses "ecb(aes)" and "cmac(aes)" as algorithms.
Finally, it also uses them both again:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/mesh/crypto.c
through ell:
https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c
Because that's a question that also came up, bluetoothd also uses the
CAP_NET_ADMIN capability.
I'll let Luiz and Marcel take it over from here.
Cheers
^ permalink raw reply
* Re: [PATCH BlueZ v2] a2dp: Fix handling of codec capability storage
From: Bastien Nocera @ 2026-06-23 12:18 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <20260622155621.675255-1-luiz.dentz@gmail.com>
On Mon, 2026-06-22 at 11:56 -0400, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> Codec capability is one byte long (max 255) the storage format is
> 02hhx which means each byte ends up as 2 characters so the buffer
> needs to be doubled in order to handle capabilities of that size.
>
> Reported-by: p0her (_@p0her_) in TeamH4C working with TrendAI Zero
> Day Initiative
> Reported-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> profiles/audio/a2dp.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/profiles/audio/a2dp.c b/profiles/audio/a2dp.c
> index a5e002784c02..c8adc3122563 100644
> --- a/profiles/audio/a2dp.c
> +++ b/profiles/audio/a2dp.c
> @@ -971,7 +971,7 @@ static void store_remote_sep(void *data, void
> *user_data)
> {
> struct a2dp_remote_sep *sep = data;
> GKeyFile *key_file = user_data;
> - char seid[4], value[256];
> + char seid[4], value[9 + 512];
What's the "9" value from? Shouldn't it be 11 for the length of:
"%02hhx:%02hhx:%02hhx:"
The "Try loading with delay_reporting first" variant?
> struct avdtp_service_capability *service =
> avdtp_get_codec(sep->sep);
> struct avdtp_media_codec_capability *codec;
> unsigned int i;
> @@ -2373,7 +2373,7 @@ static void load_remote_sep(struct a2dp_channel
> *chan, GKeyFile *key_file,
> uint8_t codec;
> uint8_t delay_reporting;
> GSList *l = NULL;
> - char caps[256];
> + char caps[513];
> uint8_t data[128];
> int i, size;
>
> @@ -2386,10 +2386,10 @@ static void load_remote_sep(struct
> a2dp_channel *chan, GKeyFile *key_file,
> continue;
>
> /* Try loading with delay_reporting first */
> - if (sscanf(value, "%02hhx:%02hhx:%02hhx:%s", &type,
> &codec,
> + if (sscanf(value, "%02hhx:%02hhx:%02hhx:%512s",
> &type, &codec,
> &delay_reporting, caps) !=
> 4) {
> /* Try old format */
> - if (sscanf(value, "%02hhx:%02hhx:%s", &type,
> &codec,
> + if (sscanf(value, "%02hhx:%02hhx:%512s",
> &type, &codec,
> caps
> ) != 3) {
> warn("Unable to load Endpoint: seid
> %u", rseid);
> g_free(value);
> @@ -2398,7 +2398,7 @@ static void load_remote_sep(struct a2dp_channel
> *chan, GKeyFile *key_file,
> delay_reporting = false;
> }
>
> - for (i = 0, size = strlen(caps); i < size; i += 2) {
> + for (i = 0, size = strlen(caps); i < size && i >= 2;
> i += 2) {
> uint8_t *tmp = data + i / 2;
>
> if (sscanf(caps + i, "%02hhx", tmp) != 1) {
^ permalink raw reply
* [PATCH] Bluetooth: btusb: Add IMC Networks MT7922 device 0x13d3:0x3625
From: monesss315 @ 2026-06-23 11:49 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo Evgucci
From: Gustavo Evgucci <monesss315@gmail.com>
The IMC Networks MT7922 Bluetooth adapter with USB ID 13d3:3625 is not
recognized as a MediaTek device because it is missing from the btusb
device ID table. As a result, btmtk firmware loading is never triggered
and the HCI reset command times out with -ETIMEDOUT.
Add the device with BTUSB_MEDIATEK | BTUSB_WIDEBAND_SPEECH flags,
consistent with the neighboring 13d3:3627, 13d3:3628 and 13d3:3630
entries which use the same chip.
Tested on: MediaTek MT7922 (Wi-Fi 6E combo card, IMC Networks BT USB
interface), kernel 7.0.11-arch1-1.
Signed-off-by: Gustavo Evgucci <monesss315@gmail.com>
---
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -755,6 +755,8 @@ static const struct usb_device_id btusb_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x13d3, 0x3613), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x13d3, 0x3625), .driver_info = BTUSB_MEDIATEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x13d3, 0x3627), .driver_info = BTUSB_MEDIATEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x13d3, 0x3628), .driver_info = BTUSB_MEDIATEK |
--
2.x.x
^ permalink raw reply
* [bluez/bluez] c62fba: shared/rap: Fix step payload pointer in parse_step
From: prathibhamadugonde @ 2026-06-23 11:47 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1115319
Home: https://github.com/bluez/bluez
Commit: c62fba1e317d2fd3e80682726ddf4a275db2ae85
https://github.com/bluez/bluez/commit/c62fba1e317d2fd3e80682726ddf4a275db2ae85
Author: Prathibha Madugonde <prathibha.madugonde@oss.qualcomm.com>
Date: 2026-06-23 (Tue, 23 Jun 2026)
Changed paths:
M src/shared/rap.c
Log Message:
-----------
shared/rap: Fix step payload pointer in parse_step
util_iov_pull advances iov_base before returning the new pointer, so
mode_iov.iov_base was set to the start of the *next* step's data.
Every step was therefore parsed using its successor's bytes.
Switch to util_iov_pull_mem which saves the original base, advances
iov, and returns the pre-advance pointer — correctly pointing to the
current step's payload.
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH BlueZ v1] shared/rap: Fix step payload pointer in parse_step
From: Prathibha Madugonde @ 2026-06-23 11:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.dentz, quic_mohamull, quic_hbandi, quic_anubhavg
From: Prathibha Madugonde <prathibha.madugonde@oss.qualcomm.com>
util_iov_pull advances iov_base before returning the new pointer, so
mode_iov.iov_base was set to the start of the *next* step's data.
Every step was therefore parsed using its successor's bytes.
Switch to util_iov_pull_mem which saves the original base, advances
iov, and returns the pre-advance pointer — correctly pointing to the
current step's payload.
---
src/shared/rap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/rap.c b/src/shared/rap.c
index ecf7df5a7..dfb272d3a 100644
--- a/src/shared/rap.c
+++ b/src/shared/rap.c
@@ -2326,7 +2326,7 @@ static bool parse_step(struct bt_rap *rap, struct iovec *iov,
DBG(rap, " Step %u: mode=%u payload_len=%zu",
step_idx, step_mode, step_payload_len);
- payload = util_iov_pull(iov, step_payload_len);
+ payload = util_iov_pull_mem(iov, step_payload_len);
if (!payload) {
DBG(rap, "Insufficient data for step %u payload "
"(need %zu, have %zu)",
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 08/13] Bluetooth: hci_sync: Fix return value of hci_reset_sync()
From: Zijun Hu @ 2026-06-23 10:48 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Marcel Holtmann, Rocky Liao, Bartosz Golaszewski,
Ben Young Tae Kim, Balakrishna Godavarthi, Matthias Kaehlcke,
Zijun Hu, linux-bluetooth, linux-kernel, Luiz Augusto von Dentz,
linux-arm-msm
In-Reply-To: <CABBYNZ+z6XcZXejs18fbX-MSFBmaGC0Reoqn549N-8sn==z2Ug@mail.gmail.com>
On 6/22/2026 11:35 PM, Luiz Augusto von Dentz wrote:
>> diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
>> index fce9f9526cb5..601d44ef975f 100644
>> --- a/net/bluetooth/hci_sync.c
>> +++ b/net/bluetooth/hci_sync.c
>> @@ -3678,8 +3678,10 @@ int hci_reset_sync(struct hci_dev *hdev)
>>
>> err = __hci_cmd_sync_status(hdev, HCI_OP_RESET, 0, NULL,
>> HCI_CMD_TIMEOUT);
>> + if (err < 0)
>> + return err;
>>
>> - return err;
>> + return -bt_to_errno(err);
>> }
> There seem to be 2 consecutive changes to hci_reset_sync that conflict
> with each other, also the expectation should be that positive errors
> are HCI errors and negative errors are stack generated ones, so the
> callers should really check `err` and not `err < 0`.
Hi Luiz,
Checking the full call chains:
- hci_reset_sync() → hci_init0_sync() [if (err)] → hci_unconf_init_sync() [if (err < 0)]
- hci_reset_sync() → hci_init1_sync() [if (err)] → hci_init_sync() [if (err < 0)]
A positive HCI status from hci_reset_sync() propagates through
hci_init0_sync()/hci_init1_sync() but is then silently ignored by
hci_unconf_init_sync()/hci_init_sync() due to their if (err < 0)
checks.
Will not change hci_reset_sync(). Any suggestion on how to fix it?
^ permalink raw reply
* Re: [PATCH 13/13] Bluetooth: btqca: Fix qca_set_bdaddr() using wrong HCI event type
From: Zijun Hu @ 2026-06-23 10:16 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Zijun Hu, linux-bluetooth, linux-kernel, Luiz Augusto von Dentz,
linux-arm-msm, Marcel Holtmann, Luiz Augusto von Dentz,
Rocky Liao, Ben Young Tae Kim, Balakrishna Godavarthi,
Matthias Kaehlcke
In-Reply-To: <CAMRc=Mc_hjCPe+aLQhK-ProNuh=4-43mPqqmQNQ81Lu4Do=fGA@mail.gmail.com>
On 6/23/2026 5:04 PM, Bartosz Golaszewski wrote:
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
> Looks good but should go in the front of the series and land upstream earlier.
Thanks for the R-b. Will do it in v2.
^ permalink raw reply
* Re: [PATCH 12/13] Bluetooth: btqca: Fix undetected error HCI status in qca_send_reset()
From: Zijun Hu @ 2026-06-23 10:13 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Zijun Hu, linux-bluetooth, linux-kernel, Luiz Augusto von Dentz,
linux-arm-msm, Marcel Holtmann, Luiz Augusto von Dentz,
Rocky Liao, Ben Young Tae Kim, Balakrishna Godavarthi,
Matthias Kaehlcke
In-Reply-To: <CAMRc=MemaY=ON2q-Cuzis0sZ9WfqjvBsFzxxCYRZrXeFPNJ0_w@mail.gmail.com>
On 6/23/2026 5:03 PM, Bartosz Golaszewski wrote:
>> Fixes: 83e81961ff7e ("Bluetooth: btqca: Introduce generic QCA ROME support")
>> Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
>> ---
> I think the fix should go in the front of the series. Even if it requires the
> new function.
Agreed on the reordering. However, handling HCI status errors for the
reset command needs more discussion before we can finalize the approach,
so the fix may be further optimized accordingly.
^ permalink raw reply
* Re: [PATCH 11/13] Bluetooth: btusb: Move struct btusb_data and macros into btusb.h
From: Zijun Hu @ 2026-06-23 10:09 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Zijun Hu, linux-bluetooth, linux-kernel, Luiz Augusto von Dentz,
linux-arm-msm, Marcel Holtmann, Luiz Augusto von Dentz,
Rocky Liao, Ben Young Tae Kim, Balakrishna Godavarthi,
Matthias Kaehlcke
In-Reply-To: <CAMRc=McmkN=Oho2A+XWgvrRG3QfF61HaPkeCperSaiCzqOc1Dw@mail.gmail.com>
On 6/23/2026 5:02 PM, Bartosz Golaszewski wrote:
> On Mon, 22 Jun 2026 16:52:24 +0200, Zijun Hu <zijun.hu@oss.qualcomm.com> said:
>> btusb.c is growing large as vendor-specific code accumulates. Ideally,
>> btusb.c contains only the default implementation while vendor-specific
>> code lives in separate files for easier maintenance.
>>
>> The newly added btusb.h also reduces unnecessary data copies in hooks
>> like btusb_mtk_setup().
>>
>> Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
>> ---
> I would be ok with this if you added a user of this new header in the subsequent
> patches but I don't see these so I'll hold off my R-b until you can show the
> need for one.
Right. Will drop this patch in v2 and bring it back together with its user
when necessary.
^ permalink raw reply
* Re: [PATCH 04/13] Bluetooth: btusb: QCA: Do not populate devcoredump fields on ATH3012 or QCA_ROME
From: Zijun Hu @ 2026-06-23 9:50 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Rocky Liao,
Bartosz Golaszewski, Ben Young Tae Kim, Balakrishna Godavarthi,
Matthias Kaehlcke, Zijun Hu, linux-bluetooth, linux-kernel,
Luiz Augusto von Dentz, linux-arm-msm
In-Reply-To: <l2ri4yxwtxv3r2upconhgsblespvushzeaqcvwvqulracmvfr4@qsmzp36emi7x>
On 6/22/2026 11:31 PM, Dmitry Baryshkov wrote:
>> Devcoredump is disabled on ATH3012 or QCA_ROME, but btusb_setup_qca()
>> used by both unconditionally populates those two devcoredump fields.
>>
>> Fix by populating devcoredump fields only for BTUSB_QCA_WCN6855 devices,
>> which are the only ones that enable devcoredump.
> Why? Wouldn't it be better to enable devcoredump for all platforms?
BTUSB_QCA_WCN6855 marks the first generation of QCA BT SoCs for which
devcoredump is enabled; all later generations are enabled too. ATH3012
and QCA_ROME are much older chips that predate devcoredump in the
Bluetooth core driver — there is no requirement to enable it for them
and it is not clear whether they even support it.
Will optimize the commit message in v2.
^ permalink raw reply
* Re: [PATCH 01/13] Bluetooth: btusb: Initialize @priv_size at declaration in btusb_probe()
From: Zijun Hu @ 2026-06-23 9:33 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Marcel Holtmann, Luiz Augusto von Dentz, Rocky Liao,
Bartosz Golaszewski, Ben Young Tae Kim, Balakrishna Godavarthi,
Matthias Kaehlcke, Zijun Hu, linux-bluetooth, linux-kernel,
Luiz Augusto von Dentz, linux-arm-msm
In-Reply-To: <xzps6lqo2k2w2onzleg4baycsnzsejiwhhefilk5rt5e547u6y@orl7l3yklhuh>
On 6/22/2026 11:30 PM, Dmitry Baryshkov wrote:
> On Mon, Jun 22, 2026 at 07:52:14AM -0700, Zijun Hu wrote:
>> Initialize @priv_size at declaration to reduce a redundant assignment.
> This is obvious from the commit. Please tell us, why?
It is simpler: one statement completes both declaration and assignment.
More flexible: initializing at declaration makes the variable immediately
usable from that point, so any new priv_size += can be freely inserted
without caring about where the separate priv_size = 0 sits.
Will improve the commit message in v2.
^ permalink raw reply
* [bluetooth-next:master] BUILD SUCCESS 8047d832767fdefd118b56be37ab550db56a443c
From: kernel test robot @ 2026-06-23 9:27 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: 8047d832767fdefd118b56be37ab550db56a443c Bluetooth: hci_sync: Remove unused hci_cmd_sync_dequeue_once()
elapsed time: 823m
configs tested: 201
configs skipped: 2
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 allyesconfig gcc-16.1.0
arc defconfig gcc-16.1.0
arc randconfig-001-20260623 clang-23
arc randconfig-002-20260623 clang-23
arm allnoconfig gcc-16.1.0
arm allyesconfig clang-23
arm defconfig gcc-16.1.0
arm randconfig-001-20260623 clang-23
arm randconfig-002-20260623 clang-23
arm randconfig-003-20260623 clang-23
arm randconfig-004-20260623 clang-23
arm spitz_defconfig gcc-16.1.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-16.1.0
arm64 defconfig gcc-16.1.0
arm64 randconfig-001-20260623 gcc-14.3.0
arm64 randconfig-002-20260623 gcc-14.3.0
arm64 randconfig-003-20260623 gcc-14.3.0
arm64 randconfig-004-20260623 gcc-14.3.0
csky allmodconfig gcc-16.1.0
csky allnoconfig gcc-16.1.0
csky defconfig gcc-16.1.0
csky randconfig-001-20260623 gcc-14.3.0
csky randconfig-002-20260623 gcc-14.3.0
hexagon allmodconfig gcc-16.1.0
hexagon allnoconfig gcc-16.1.0
hexagon defconfig gcc-16.1.0
hexagon randconfig-001 gcc-11.5.0
hexagon randconfig-001-20260623 gcc-11.5.0
hexagon randconfig-001-20260623 gcc-8.5.0
hexagon randconfig-002 gcc-11.5.0
hexagon randconfig-002-20260623 gcc-11.5.0
hexagon randconfig-002-20260623 gcc-8.5.0
i386 allmodconfig clang-22
i386 allnoconfig gcc-16.1.0
i386 allyesconfig clang-22
i386 buildonly-randconfig-001-20260623 gcc-14
i386 buildonly-randconfig-002-20260623 gcc-14
i386 buildonly-randconfig-003-20260623 gcc-14
i386 buildonly-randconfig-004-20260623 gcc-14
i386 buildonly-randconfig-005-20260623 gcc-14
i386 buildonly-randconfig-006-20260623 gcc-14
i386 defconfig gcc-16.1.0
i386 randconfig-001-20260623 clang-22
i386 randconfig-002-20260623 clang-22
i386 randconfig-003-20260623 clang-22
i386 randconfig-004-20260623 clang-22
i386 randconfig-005-20260623 clang-22
i386 randconfig-006-20260623 clang-22
i386 randconfig-007-20260623 clang-22
i386 randconfig-011 gcc-14
i386 randconfig-011-20260623 gcc-14
i386 randconfig-012 gcc-14
i386 randconfig-012-20260623 gcc-14
i386 randconfig-013 gcc-14
i386 randconfig-013-20260623 gcc-14
i386 randconfig-014 gcc-14
i386 randconfig-014-20260623 gcc-14
i386 randconfig-015 gcc-14
i386 randconfig-015-20260623 gcc-14
i386 randconfig-016 gcc-14
i386 randconfig-016-20260623 gcc-14
i386 randconfig-017 gcc-14
i386 randconfig-017-20260623 gcc-14
loongarch allmodconfig clang-19
loongarch allmodconfig clang-23
loongarch allnoconfig gcc-16.1.0
loongarch defconfig clang-23
loongarch randconfig-001 gcc-11.5.0
loongarch randconfig-001-20260623 gcc-11.5.0
loongarch randconfig-001-20260623 gcc-8.5.0
loongarch randconfig-002 gcc-11.5.0
loongarch randconfig-002-20260623 gcc-11.5.0
loongarch randconfig-002-20260623 gcc-8.5.0
m68k allmodconfig gcc-16.1.0
m68k allnoconfig gcc-16.1.0
m68k allyesconfig clang-23
m68k defconfig clang-23
m68k m5249evb_defconfig gcc-16.1.0
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 gcc-11.5.0
nios2 randconfig-001-20260623 gcc-11.5.0
nios2 randconfig-001-20260623 gcc-8.5.0
nios2 randconfig-002 gcc-11.5.0
nios2 randconfig-002-20260623 gcc-11.5.0
nios2 randconfig-002-20260623 gcc-8.5.0
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 allyesconfig gcc-16.1.0
parisc defconfig gcc-16.1.0
parisc randconfig-001-20260623 gcc-11.5.0
parisc randconfig-002-20260623 gcc-11.5.0
parisc64 defconfig clang-23
powerpc allmodconfig gcc-16.1.0
powerpc allnoconfig clang-23
powerpc ppc44x_defconfig clang-17
powerpc randconfig-001-20260623 gcc-11.5.0
powerpc randconfig-002-20260623 gcc-11.5.0
powerpc64 randconfig-001-20260623 gcc-11.5.0
powerpc64 randconfig-002-20260623 gcc-11.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-23
riscv defconfig gcc-16.1.0
riscv randconfig-001-20260623 gcc-8.5.0
riscv randconfig-002-20260623 gcc-8.5.0
s390 allmodconfig clang-17
s390 allmodconfig clang-23
s390 allnoconfig clang-23
s390 allyesconfig gcc-16.1.0
s390 defconfig gcc-16.1.0
s390 randconfig-001-20260623 gcc-8.5.0
s390 randconfig-002-20260623 gcc-8.5.0
sh allmodconfig gcc-16.1.0
sh allnoconfig clang-23
sh allyesconfig clang-17
sh allyesconfig gcc-16.1.0
sh defconfig gcc-14
sh randconfig-001-20260623 gcc-8.5.0
sh randconfig-002-20260623 gcc-8.5.0
sparc allnoconfig clang-23
sparc defconfig gcc-16.1.0
sparc randconfig-001-20260623 gcc-8.5.0
sparc randconfig-002-20260623 gcc-8.5.0
sparc64 allmodconfig clang-20
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260623 gcc-8.5.0
sparc64 randconfig-002-20260623 gcc-8.5.0
um allmodconfig clang-17
um allmodconfig clang-23
um allnoconfig clang-23
um allyesconfig gcc-16.1.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260623 gcc-8.5.0
um randconfig-002-20260623 gcc-8.5.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-20260623 clang-22
x86_64 buildonly-randconfig-002-20260623 clang-22
x86_64 buildonly-randconfig-003-20260623 clang-22
x86_64 buildonly-randconfig-004-20260623 clang-22
x86_64 buildonly-randconfig-005-20260623 clang-22
x86_64 buildonly-randconfig-006-20260623 clang-22
x86_64 defconfig gcc-14
x86_64 kexec clang-22
x86_64 randconfig-001 gcc-14
x86_64 randconfig-001-20260623 gcc-14
x86_64 randconfig-002 gcc-14
x86_64 randconfig-002-20260623 gcc-14
x86_64 randconfig-003 gcc-14
x86_64 randconfig-003-20260623 gcc-14
x86_64 randconfig-004 gcc-14
x86_64 randconfig-004-20260623 gcc-14
x86_64 randconfig-005 gcc-14
x86_64 randconfig-005-20260623 gcc-14
x86_64 randconfig-006 gcc-14
x86_64 randconfig-006-20260623 gcc-14
x86_64 randconfig-011-20260623 gcc-14
x86_64 randconfig-012-20260623 gcc-14
x86_64 randconfig-013-20260623 gcc-14
x86_64 randconfig-014-20260623 gcc-14
x86_64 randconfig-015-20260623 gcc-14
x86_64 randconfig-016-20260623 gcc-14
x86_64 randconfig-071-20260623 gcc-14
x86_64 randconfig-072-20260623 gcc-14
x86_64 randconfig-073-20260623 gcc-14
x86_64 randconfig-074-20260623 gcc-14
x86_64 randconfig-075-20260623 gcc-14
x86_64 randconfig-076-20260623 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-20260623 gcc-8.5.0
xtensa randconfig-002-20260623 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH 13/13] Bluetooth: btqca: Fix qca_set_bdaddr() using wrong HCI event type
From: Bartosz Golaszewski @ 2026-06-23 9:04 UTC (permalink / raw)
To: Zijun Hu
Cc: Zijun Hu, linux-bluetooth, linux-kernel, Luiz Augusto von Dentz,
linux-arm-msm, Marcel Holtmann, Luiz Augusto von Dentz,
Rocky Liao, Bartosz Golaszewski, Ben Young Tae Kim,
Balakrishna Godavarthi, Matthias Kaehlcke
In-Reply-To: <20260622-bt_bugfix-v1-13-11f936d84e72@oss.qualcomm.com>
On Mon, 22 Jun 2026 16:52:26 +0200, Zijun Hu <zijun.hu@oss.qualcomm.com> said:
> EDL_WRITE_BD_ADDR_OPCODE (0xFC14) returns a command complete event,
> not a VSE, but qca_set_bdaddr() waits for HCI_EV_VENDOR.
>
> Fix by passing 0 as the event parameter to __hci_cmd_sync_ev() to
> wait for the command complete event instead.
>
> Fixes: 5c0a1001c8be ("Bluetooth: hci_qca: Add helper to set device address")
> Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
> ---
> drivers/bluetooth/btqca.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
> index 875216e15603..f3487de813c2 100644
> --- a/drivers/bluetooth/btqca.c
> +++ b/drivers/bluetooth/btqca.c
> @@ -1011,8 +1011,7 @@ int qca_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr)
> baswap(&bdaddr_swapped, bdaddr);
>
> skb = __hci_cmd_sync_ev(hdev, EDL_WRITE_BD_ADDR_OPCODE, 6,
> - &bdaddr_swapped, HCI_EV_VENDOR,
> - HCI_INIT_TIMEOUT);
> + &bdaddr_swapped, 0, HCI_INIT_TIMEOUT);
> if (IS_ERR(skb)) {
> err = PTR_ERR(skb);
> bt_dev_err(hdev, "QCA Change address cmd failed (%d)", err);
>
> --
> 2.34.1
>
>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Looks good but should go in the front of the series and land upstream earlier.
Bart
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox