* Re: Bluetooth: btusb: Add VID/PID 0489:e156 for MediaTek MT7902
From: Kirill Shubin @ 2026-05-03 8:43 UTC (permalink / raw)
To: Sean Wang
Cc: sean.wang, luiz.von.dentz, linux-bluetooth,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <CAGp9LzqXKwJf7=bFuv_gW9yFH7uBuXva398TC=XOrZkyd-ermQ@mail.gmail.com>
Hi Sean,
On Sat, May 2, 2026, Sean Wang wrote:
> Could you help get the USB device information from your test machine
> as the following and reply to the mail?
Sure, here is the full information for 0489:e156 from
/sys/kernel/debug/usb/devices:
T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=05 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e156 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=000000000
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
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=125us
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
I: If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us
I:* If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
> I will send the patch including the VID/PID
> thanks
Thanks for your help!
Best regards,
Kirill Shubin
вс, 3 мая 2026 г. в 02:17, Sean Wang <sean.wang@kernel.org>:
>
> Hi Кирилл,
>
> Could you help get the USB device information from your test machine
> as the following and reply to the mail?
>
> The information in /sys/kernel/debug/usb/devices about the Bluetooth
> device is listed as the below.
>
> T: Bus=07 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
> D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=13d3 ProdID=3596 Rev= 1.00
> S: Manufacturer=MediaTek Inc.
> S: Product=Wireless_Device
> S: SerialNumber=000000000
> C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
> A: FirstIf#= 0 IfCount= 3 Cls=e0(wlcon) Sub=01 Prot=01
> 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=125us
> E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
> E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
> E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
> E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
> E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
> E: Ad=03(O) 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=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
> I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
> E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
> I:* If#= 2 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
> E: Ad=8a(I) Atr=03(Int.) MxPS= 64 Ivl=125us
> E: Ad=0a(O) Atr=03(Int.) MxPS= 64 Ivl=125us
> I: If#= 2 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
> E: Ad=8a(I) Atr=03(Int.) MxPS= 512 Ivl=125us
> E: Ad=0a(O) Atr=03(Int.) MxPS= 512 Ivl=125us
>
> I will send the patch including the VID/PID
> thanks
>
> On Sat, May 2, 2026 at 12:20 PM Кирилл <kirill.kz.902@gmail.com> wrote:
> >
> > Hi Sean,
> >
> > Following your MT7902 series, here is one more VID/PID variant
> > that is currently not recognized by btusb: 0489:e156 (Foxconn).
> >
> > Adding the entry below makes Bluetooth work on v7.1-rc1:
> >
> > /* Additional MediaTek MT7902 Bluetooth devices */
> > { USB_DEVICE(0x0489, 0xe156), .driver_info = BTUSB_MEDIATEK |
> > BTUSB_WIDEBAND_SPEECH },
> >
> > dmesg after loading the patched module:
> >
> > Bluetooth: hci0: HW/SW Version: 0x008a008a,
> > Build Time: 20250826211444
> >
> > /sys/kernel/debug/usb/devices:
> >
> > T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=05 Dev#=6 Spd=480 MxCh=0
> > D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=1
> > P: Vendor=0489 ProdID=e156 Rev= 1.00
> > S: Manufacturer=MediaTek Inc.
> > S: Product=Wireless_Device
> > C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=100mA
> >
> > Could you include this VID/PID in the next MT7902 round?
> >
> > Tested-by: Kirill Shubin <kirill.kz.902@gmail.com>
> >
> > Thanks,
> > Kirill
> >
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-03 9:41 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1076877
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-03 10:35 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1076884
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-03 13:10 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1076973
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [Bug 220237] Bluetooth: MediaTek MT7925 (0e8d:7925) fails to load firmware with timeout (-110)
From: bugzilla-daemon @ 2026-05-03 19:23 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <bug-220237-62941@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=220237
jens.nitschke@mailbox.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jens.nitschke@mailbox.org
--- Comment #4 from jens.nitschke@mailbox.org ---
Device: HP OmniBook X Flip 14-fk0178ng
BIOS: F.10 (2025-10-22)
OS: CachyOS (Arch-based)
Kernel: 7.0.3-1-cachyos
WiFi/BT chip: MediaTek MT7925 (PCIe ID: 14c3:7925, Subsystem: 8c38)
I can confirm this issue on my device. The Bluetooth USB interface never
enumerates successfully. WiFi works fine via mt7925e driver.
Key symptoms from dmesg:
usb 3-5: device descriptor read/64, error -110
xhci_hcd 0000:65:00.0: Timeout while waiting for setup device command
usb 3-5: device not accepting address, error -62
The BT device never appears in lsusb or rfkill. No hci0 interface is created.
Workarounds that had no effect:
pcie_aspm=off
usbcore.autosuspend=-1
xhci_hcd.quirks=0x80000
Early loading of mt7925e via initramfs
linux-firmware up to date, firmware files present in
/lib/firmware/mediatek/mt7925/
--
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
* [SECURITY] BlueZ sdp.c signed integer underflow in SDP sequence parsing (8.1 HIGH)
From: admin @ 2026-05-03 23:24 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
To: linux-bluetooth@vger.kernel.org Subject: [SECURITY] BlueZ sdp.c signed integer underflow in SDP sequence parsing (8.1 HIGH)
linux-bluetooth,
Reporting a residual signed integer underflow in BlueZ 5.86 HEAD that
was not fully addressed by commit 31e4fb1.
AFFECTED FILE: lib/bluetooth/sdp.c lines 1213, 1262, 1392
ROOT CAUSE:
bt_get_be32() returns uint32_t. The result is stored into an int*
target, sign-extending values >0x7FFFFFFF to negative. High-level
paths in extract_seq() and sdp_extract_pdu() have seqlen<0 guards,
but the residual paths introduced or left unpatched in 5.86 HEAD
remain unprotected. An adjacent attacker sending a crafted SDP
response with an oversized sequence length field triggers negative
seqlen, bypassing subsequent size checks and corrupting heap metadata.
ATTACK:
Pre-pairing, no authentication required. Auto-triggered on Bluetooth
device discovery. Adjacent attacker sends malformed SDP PDU during
scan — signed underflow — heap corruption — potential RCE or DoS
in bluetoothd.
CVSS 3.1: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 8.1 HIGH
CWE-191: Integer Underflow
REMEDIATION:
Add seqlen<0 guards at lines 1213, 1262, 1392. Store bt_get_be32()
result in uint32_t and validate against INT_MAX before signed cast.
Also reported to security@bluez.org.
Martin Brodeur Ottawa Canada
Independent security researcher
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-04 0:12 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1077174
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH v2] sysfs: return -ENOENT from move/rename when kobj->sd is NULL
From: Conor Kotwasinski @ 2026-05-04 5:07 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J . Wysocki
Cc: Danilo Krummrich, driver-core, linux-kernel, linux-bluetooth,
syzbot+d1db96f72a452dc9cbd2, syzbot+faeac5b54ba997a96278,
Conor Kotwasinski
In-Reply-To: <20260416150600.2148935-1-conorkotwasinski2024@u.northwestern.edu>
sysfs_move_dir_ns() and sysfs_rename_dir_ns() pass kobj->sd to
kernfs_rename_ns() unconditionally. If sysfs_remove_dir() has already
cleared kobj->sd, the NULL flows through and kernfs_rename_ns()
dereferences it via rcu_access_pointer(kn->__parent), which KASAN
surfaces as a stack-segment fault on the shadow lookup:
Oops: stack segment: 0000 [#1] SMP KASAN PTI
RIP: 0010:kernfs_rename_ns+0x3a/0x7a0 fs/kernfs/dir.c:1752
Call Trace:
kobject_move+0x525/0x6e0 lib/kobject.c:569
device_move+0xe0/0x730 drivers/base/core.c:4606
hci_conn_del_sysfs+0xb8/0x1a0 net/bluetooth/hci_sysfs.c:75
hci_conn_cleanup net/bluetooth/hci_conn.c:173 [inline]
hci_conn_del+0xc36/0x1240 net/bluetooth/hci_conn.c:1234
hci_conn_hash_flush+0x191/0x260 net/bluetooth/hci_conn.c:2638
hci_dev_close_sync+0x821/0x1100 net/bluetooth/hci_sync.c:5327
hci_dev_do_close net/bluetooth/hci_core.c:501 [inline]
hci_unregister_dev+0x21a/0x5b0 net/bluetooth/hci_core.c:2715
syzbot has reported 35 hits with this signature across net, net-next
and linux-next between July 2025 and January 2026, via both vhci
release and HCIDEVRESET ioctl.
Return -ENOENT in that case, consistent with sysfs_create_dir_ns().
The underlying ordering problem in bluetooth -- device_move() called
after the target's sysfs has been torn down -- is a separate issue.
Reported-by: syzbot+d1db96f72a452dc9cbd2@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/687c6966.a70a0220.693ce.00a5.GAE@google.com/
Reported-by: syzbot+faeac5b54ba997a96278@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=faeac5b54ba997a96278
Fixes: 324a56e16e44 ("kernfs: s/sysfs_dirent/kernfs_node/ and rename its friends accordingly")
Cc: stable@vger.kernel.org
Signed-off-by: Conor Kotwasinski <conorkotwasinski2024@u.northwestern.edu>
---
fs/sysfs/dir.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
index ffdcd4153c58..6664fae288c9 100644
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@ -108,6 +108,9 @@ int sysfs_rename_dir_ns(struct kobject *kobj, const char *new_name,
struct kernfs_node *parent;
int ret;
+ if (!kobj->sd)
+ return -ENOENT;
+
parent = kernfs_get_parent(kobj->sd);
ret = kernfs_rename_ns(kobj->sd, parent, new_name, new_ns);
kernfs_put(parent);
@@ -120,6 +123,9 @@ int sysfs_move_dir_ns(struct kobject *kobj, struct kobject *new_parent_kobj,
struct kernfs_node *kn = kobj->sd;
struct kernfs_node *new_parent;
+ if (!kn)
+ return -ENOENT;
+
new_parent = new_parent_kobj && new_parent_kobj->sd ?
new_parent_kobj->sd : sysfs_root_kn;
base-commit: 36f35b8df6972167102a1c3d4361e0afb6a84534
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v2] sysfs: return -ENOENT from move/rename when kobj->sd is NULL
From: Greg Kroah-Hartman @ 2026-05-04 6:22 UTC (permalink / raw)
To: Conor Kotwasinski
Cc: Rafael J . Wysocki, Danilo Krummrich, driver-core, linux-kernel,
linux-bluetooth, syzbot+d1db96f72a452dc9cbd2,
syzbot+faeac5b54ba997a96278
In-Reply-To: <20260504050736.17672-1-conorkotwasinski2024@u.northwestern.edu>
On Mon, May 04, 2026 at 01:07:36AM -0400, Conor Kotwasinski wrote:
> sysfs_move_dir_ns() and sysfs_rename_dir_ns() pass kobj->sd to
> kernfs_rename_ns() unconditionally. If sysfs_remove_dir() has already
> cleared kobj->sd, the NULL flows through and kernfs_rename_ns()
> dereferences it via rcu_access_pointer(kn->__parent), which KASAN
> surfaces as a stack-segment fault on the shadow lookup:
>
> Oops: stack segment: 0000 [#1] SMP KASAN PTI
> RIP: 0010:kernfs_rename_ns+0x3a/0x7a0 fs/kernfs/dir.c:1752
> Call Trace:
> kobject_move+0x525/0x6e0 lib/kobject.c:569
> device_move+0xe0/0x730 drivers/base/core.c:4606
> hci_conn_del_sysfs+0xb8/0x1a0 net/bluetooth/hci_sysfs.c:75
> hci_conn_cleanup net/bluetooth/hci_conn.c:173 [inline]
> hci_conn_del+0xc36/0x1240 net/bluetooth/hci_conn.c:1234
> hci_conn_hash_flush+0x191/0x260 net/bluetooth/hci_conn.c:2638
> hci_dev_close_sync+0x821/0x1100 net/bluetooth/hci_sync.c:5327
> hci_dev_do_close net/bluetooth/hci_core.c:501 [inline]
> hci_unregister_dev+0x21a/0x5b0 net/bluetooth/hci_core.c:2715
>
> syzbot has reported 35 hits with this signature across net, net-next
> and linux-next between July 2025 and January 2026, via both vhci
> release and HCIDEVRESET ioctl.
>
> Return -ENOENT in that case, consistent with sysfs_create_dir_ns().
> The underlying ordering problem in bluetooth -- device_move() called
> after the target's sysfs has been torn down -- is a separate issue.
>
> Reported-by: syzbot+d1db96f72a452dc9cbd2@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/all/687c6966.a70a0220.693ce.00a5.GAE@google.com/
> Reported-by: syzbot+faeac5b54ba997a96278@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=faeac5b54ba997a96278
> Fixes: 324a56e16e44 ("kernfs: s/sysfs_dirent/kernfs_node/ and rename its friends accordingly")
> Cc: stable@vger.kernel.org
> Signed-off-by: Conor Kotwasinski <conorkotwasinski2024@u.northwestern.edu>
> ---
> fs/sysfs/dir.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> index ffdcd4153c58..6664fae288c9 100644
> --- a/fs/sysfs/dir.c
> +++ b/fs/sysfs/dir.c
> @@ -108,6 +108,9 @@ int sysfs_rename_dir_ns(struct kobject *kobj, const char *new_name,
> struct kernfs_node *parent;
> int ret;
>
> + if (!kobj->sd)
> + return -ENOENT;
> +
> parent = kernfs_get_parent(kobj->sd);
> ret = kernfs_rename_ns(kobj->sd, parent, new_name, new_ns);
> kernfs_put(parent);
> @@ -120,6 +123,9 @@ int sysfs_move_dir_ns(struct kobject *kobj, struct kobject *new_parent_kobj,
> struct kernfs_node *kn = kobj->sd;
> struct kernfs_node *new_parent;
>
> + if (!kn)
> + return -ENOENT;
> +
> new_parent = new_parent_kobj && new_parent_kobj->sd ?
> new_parent_kobj->sd : sysfs_root_kn;
>
>
> base-commit: 36f35b8df6972167102a1c3d4361e0afb6a84534
> --
> 2.50.1 (Apple Git-155)
>
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/process/submitting-patches.rst for what
needs to be done here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* RE: [v2] sysfs: return -ENOENT from move/rename when kobj->sd is NULL
From: bluez.test.bot @ 2026-05-04 7:29 UTC (permalink / raw)
To: linux-bluetooth, conorkotwasinski2024
In-Reply-To: <20260504050736.17672-1-conorkotwasinski2024@u.northwestern.edu>
[-- Attachment #1: Type: text/plain, Size: 3265 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=1089086
---Test result---
Test Summary:
CheckPatch PASS 0.66 seconds
GitLint PASS 0.28 seconds
SubjectPrefix FAIL 0.10 seconds
BuildKernel PASS 26.76 seconds
CheckAllWarning PASS 28.73 seconds
CheckSparse PASS 27.73 seconds
BuildKernel32 PASS 25.43 seconds
TestRunnerSetup PASS 525.64 seconds
TestRunner_l2cap-tester FAIL 6.55 seconds
TestRunner_iso-tester PASS 295.63 seconds
TestRunner_bnep-tester FAIL 6.40 seconds
TestRunner_mgmt-tester FAIL 8.76 seconds
TestRunner_rfcomm-tester PASS 28.75 seconds
TestRunner_sco-tester PASS 68.04 seconds
TestRunner_ioctl-tester FAIL 37.27 seconds
TestRunner_mesh-tester PASS 26.90 seconds
TestRunner_smp-tester PASS 6.41 seconds
TestRunner_userchan-tester FAIL 6.57 seconds
TestRunner_6lowpan-tester PASS 22.78 seconds
IncrementalBuild PASS 24.00 seconds
Details
##############################
Test: SubjectPrefix - FAIL
Desc: Check subject contains "Bluetooth" prefix
Output:
"Bluetooth: " prefix is not specified in the subject
##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:
No test result found
##############################
Test: TestRunner_bnep-tester - FAIL
Desc: Run bnep-tester with test-runner
Output:
No test result found
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
No test result found
##############################
Test: TestRunner_ioctl-tester - FAIL
Desc: Run ioctl-tester with test-runner
Output:
Total: 28, Passed: 0 (0.0%), Failed: 11, Not Run: 17
Failed Test Cases
Device List Timed out -30.851 seconds
Device Info Timed out -6.202 seconds
Reset Stat Timed out -6.205 seconds
Set Link Mode - ACCEPT Timed out -6.208 seconds
Set Pkt Type - DM Timed out -14.396 seconds
Set Pkt Type - DH Timed out -14.399 seconds
Set Pkt Type - HV Timed out -14.403 seconds
Set Pkt Type - 2-DH Timed out -14.406 seconds
Set Pkt Type - 2-DH Timed out -14.409 seconds
Set Pkt Type - ALL Timed out -14.412 seconds
Set ACL MTU - 1 Timed out -14.414 seconds
##############################
Test: TestRunner_userchan-tester - FAIL
Desc: Run userchan-tester with test-runner
Output:
No test result found
https://github.com/bluez/bluetooth-next/pull/142
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [PATCH v1] bluetooth: btintel: Add Bluetooth SAR revision 2 support
From: K, Kiran @ 2026-05-04 9:42 UTC (permalink / raw)
To: Paul Menzel
Cc: linux-bluetooth@vger.kernel.org, Srivatsa, Ravishankar,
Tumkur Narayan, Chethan, Ravindra
In-Reply-To: <4c66feb9-e596-4ba2-98d3-b2365484fe2f@molgen.mpg.de>
Hi Paul,
Thanks for the comments.
>Subject: Re: [PATCH v1] bluetooth: btintel: Add Bluetooth SAR revision 2
>support
>
>Dear Kiran,
>
>
>Thank you for the patch.
>
>Am 30.04.26 um 18:51 schrieb Kiran K:
>> BRDS revision 2 introduces per-chain (Chain A and Chain B) TX power
>> limits across five sub-bands (2.4G, 5.2G, 5.8/5.9G, 6G-low, 6G-high),
>> replacing the single-chain per-modulation model of revisions 0 and 1.
>>
>> - Add btintel_set_sar_rev2() which sends the full Rev2 DDC sequence:
>> 0x019e inc-power-mode enable flag (1 byte)
>> 0x0311 2.4 GHz sub-band limits (2 bytes)
>> 0x0312 5.2 GHz sub-band limits (2 bytes)
>> 0x0313 5.8/5.9 GHz sub-band limits (2 bytes)
>> 0x0314 5.8/5.9 GHz sub-band limits again (2 bytes, duplicate FW reg)
>> 0x0315 6 GHz low sub-band limits (2 bytes)
>> 0x0316 6 GHz high sub-band limits (2 bytes)
>> followed by the SAR-init-complete command (0xfe25).
>
>Please detail how to test it, and please also paste the new debug messages.
Note that ODMs configure the SAR revision and the corresponding per-chain limits directly in coreboot/BIOS. Hardware verification of the actual transmit power levels (per chain and per sub-band) requires a CMW500.
I will include debug logs in v2 version of patch.
>
>> Signed-off-by: Ravindra <ravindra@intel.com>
>> Signed-off-by: Kiran K <kiran.k@intel.com>
>> ---
>> drivers/bluetooth/btintel.c | 154
>+++++++++++++++++++++++++++++++++++-
>> drivers/bluetooth/btintel.h | 18 +++++
>> 2 files changed, 171 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c
>> index 5e9cac090bd8..97d897623c94 100644
>> --- a/drivers/bluetooth/btintel.c
>> +++ b/drivers/bluetooth/btintel.c
>> @@ -51,6 +51,7 @@ enum {
>> #define BTINTEL_BT_DOMAIN 0x12
>> #define BTINTEL_SAR_LEGACY 0
>> #define BTINTEL_SAR_INC_PWR 1
>> +#define BTINTEL_SAR_REV2 2
>> #define BTINTEL_SAR_INC_PWR_SUPPORTED 0
>>
>> #define CMD_WRITE_BOOT_PARAMS 0xfc0e
>> @@ -3104,6 +3105,111 @@ static int btintel_set_mutual_sar(struct hci_dev
>*hdev, struct btintel_sar_inc_p
>> return 0;
>> }
>>
>> +/* btintel_send_sar_rev2_band - send DDC command for one Rev2
>> +sub-band
>> + *
>> + * Each DDC 0x0311-0x0316 carries 2 bytes: [ChainA_value, ChainB_value].
>> + * cmd->len = 4 (2 id + 2 data)
>> + * HCI total = 5 bytes (1 len + 4)
>> + */
>> +static int btintel_send_sar_rev2_band(struct hci_dev *hdev,
>> + struct btintel_cp_ddc_write *cmd,
>> + u16 id, u8 chain_a, u8 chain_b) {
>> + cmd->len = 4;
>> + cmd->id = cpu_to_le16(id);
>> + cmd->data[0] = chain_a;
>> + cmd->data[1] = chain_b;
>> + return btintel_send_sar_ddc(hdev, cmd, 5); }
>> +
>> +static int btintel_set_sar_rev2(struct hci_dev *hdev,
>> + struct btintel_sar_rev2 *sar)
>> +{
>> + struct btintel_cp_ddc_write *cmd;
>> + struct sk_buff *skb;
>> + u8 buffer[64];
>> + bool enable;
>> + int ret;
>> +
>> + cmd = (void *)buffer;
>> +
>> + /* DDC 0x019e: enable/disable increased power mode SAR (1 byte) */
>> + cmd->len = 3;
>> + cmd->id = cpu_to_le16(0x019e);
>> + cmd->data[0] = (sar->inc_power_mode ==
>BTINTEL_SAR_INC_PWR_SUPPORTED) ?
>> + 0x01 : 0x00;
>> + ret = btintel_send_sar_ddc(hdev, cmd, 4);
>> + if (ret)
>> + return ret;
>> +
>> + /* DDC 0x0311-0x0316: per sub-band ChainA + ChainB limits */
>> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0311,
>> + sar->chain_a.subband_2g4,
>> + sar->chain_b.subband_2g4);
>> + if (ret)
>> + return ret;
>> +
>> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0312,
>> + sar->chain_a.subband_5g2,
>> + sar->chain_b.subband_5g2);
>> + if (ret)
>> + return ret;
>> +
>> + /* 0x0313 and 0x0314 both carry the 5G8/5G9 value */
>> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0313,
>> + sar->chain_a.subband_5g8_5g9,
>> + sar->chain_b.subband_5g8_5g9);
>> + if (ret)
>> + return ret;
>> +
>> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0314,
>> + sar->chain_a.subband_5g8_5g9,
>> + sar->chain_b.subband_5g8_5g9);
>> + if (ret)
>> + return ret;
>> +
>> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0315,
>> + sar->chain_a.subband_6g1,
>> + sar->chain_b.subband_6g1);
>> + if (ret)
>> + return ret;
>> +
>> + ret = btintel_send_sar_rev2_band(hdev, cmd, 0x0316,
>> + sar->chain_a.subband_6g3,
>> + sar->chain_b.subband_6g3);
>> + if (ret)
>> + return ret;
>> +
>> + /* Notify firmware that SAR initialisation is complete */
>> + enable = true;
>> + skb = __hci_cmd_sync(hdev, 0xfe25, 1, &enable,
>HCI_CMD_TIMEOUT);
>> + if (IS_ERR(skb)) {
>> + bt_dev_warn(hdev, "Failed to send Intel SAR Rev2 Enable
>(%ld)",
>> + PTR_ERR(skb));
>> + return PTR_ERR(skb);
>> + }
>> +
>> + kfree_skb(skb);
>> + return 0;
>> +}
>> +
>> +static int btintel_sar_rev2_send_to_device(struct hci_dev *hdev,
>> + struct btintel_sar_rev2 *sar,
>> + struct intel_version_tlv *ver) {
>> + u16 cnvi = ver->cnvi_top & 0xfff;
>> + u16 cnvr = ver->cnvr_top & 0xfff;
>> +
>> + if (cnvi < BTINTEL_CNVI_BLAZARI || cnvr != BTINTEL_CNVR_WHP2) {
>> + bt_dev_dbg(hdev, "BT SAR Rev2 not supported on this
>platform (cnvi=0x%x cnvr=0x%x)",
>> + cnvi, cnvr);
>> + return -EOPNOTSUPP;
>> + }
>> +
>> + bt_dev_info(hdev, "Applying Bluetooth SAR Rev2");
>> + return btintel_set_sar_rev2(hdev, sar); }
>> +
>> static int btintel_sar_send_to_device(struct hci_dev *hdev, struct
>btintel_sar_inc_pwr *sar,
>> struct intel_version_tlv *ver)
>> {
>> @@ -3130,6 +3236,7 @@ static int btintel_acpi_set_sar(struct hci_dev
>*hdev, struct intel_version_tlv *
>> {
>> union acpi_object *bt_pkg, *buffer = NULL;
>> struct btintel_sar_inc_pwr sar;
>> + struct btintel_sar_rev2 sar_rev2;
>> acpi_status status;
>> u8 revision;
>> int ret;
>> @@ -3150,14 +3257,59 @@ static int btintel_acpi_set_sar(struct hci_dev
>*hdev, struct intel_version_tlv *
>> goto error;
>> }
>>
>> + if (buffer->package.elements[0].type != ACPI_TYPE_INTEGER) {
>> + bt_dev_warn(hdev, "BT_SAR: unexpected ACPI type for
>revision field");
>> + ret = -EINVAL;
>> + goto error;
>> + }
>> +
>> revision = buffer->package.elements[0].integer.value;
>>
>> - if (revision > BTINTEL_SAR_INC_PWR) {
>> + if (revision > BTINTEL_SAR_REV2) {
>> bt_dev_dbg(hdev, "BT_SAR: revision: 0x%2.2x not supported",
>revision);
>> ret = -EOPNOTSUPP;
>> goto error;
>> }
>>
>> + if (revision == BTINTEL_SAR_REV2 && bt_pkg->package.count == 13) {
>> + memset(&sar_rev2, 0, sizeof(sar_rev2));
>> + sar_rev2.revision = revision;
>> + sar_rev2.bt_sar_bios = bt_pkg-
>>package.elements[1].integer.value;
>> + sar_rev2.inc_power_mode =
>> +bt_pkg->package.elements[2].integer.value;
>> +
>> + sar_rev2.chain_a.subband_2g4 = bt_pkg-
>>package.elements[3].integer.value;
>> + sar_rev2.chain_a.subband_5g2 = bt_pkg-
>>package.elements[4].integer.value;
>> + sar_rev2.chain_a.subband_5g8_5g9 = bt_pkg-
>>package.elements[5].integer.value;
>> + sar_rev2.chain_a.subband_6g1 = bt_pkg-
>>package.elements[6].integer.value;
>> + sar_rev2.chain_a.subband_6g3 = bt_pkg-
>>package.elements[7].integer.value;
>> +
>> + sar_rev2.chain_b.subband_2g4 = bt_pkg-
>>package.elements[8].integer.value;
>> + sar_rev2.chain_b.subband_5g2 = bt_pkg-
>>package.elements[9].integer.value;
>> + sar_rev2.chain_b.subband_5g8_5g9 = bt_pkg-
>>package.elements[10].integer.value;
>> + sar_rev2.chain_b.subband_6g1 = bt_pkg-
>>package.elements[11].integer.value;
>> + sar_rev2.chain_b.subband_6g3 = bt_pkg-
>>package.elements[12].integer.value;
>
>gemini/gemini-3.1-pro-preview has a comment [1]:
>
>> Is it safe to assume elements 1 through 12 are all of type
>> ACPI_TYPE_INTEGER here?
>> I see an explicit type check was added just above for the revision
>> field at buffer->package.elements[0], but elements 1 through 12 in
>> bt_pkg are accessed without similar validation.
>> If the ACPI table provides a string or buffer for any of these
>> elements, could the kernel incorrectly read overlapping union fields
>> (such as string lengths or
>> pointers) as integers and send corrupted sub-band limits to the firmware?
>
>
>> +
>> + bt_dev_dbg(hdev, "BT SAR Rev2: revision=%u bt_sar_bios=%u
>inc_power_mode=%u",
>> + sar_rev2.revision, sar_rev2.bt_sar_bios,
>sar_rev2.inc_power_mode);
>> + bt_dev_dbg(hdev, "BT SAR Rev2 Chain A: 2g4=%u 5g2=%u
>5g8_5g9=%u 6g1=%u 6g3=%u",
>> + sar_rev2.chain_a.subband_2g4,
>sar_rev2.chain_a.subband_5g2,
>> + sar_rev2.chain_a.subband_5g8_5g9,
>sar_rev2.chain_a.subband_6g1,
>> + sar_rev2.chain_a.subband_6g3);
>> + bt_dev_dbg(hdev, "BT SAR Rev2 Chain B: 2g4=%u 5g2=%u
>5g8_5g9=%u 6g1=%u 6g3=%u",
>> + sar_rev2.chain_b.subband_2g4,
>sar_rev2.chain_b.subband_5g2,
>> + sar_rev2.chain_b.subband_5g8_5g9,
>sar_rev2.chain_b.subband_6g1,
>> + sar_rev2.chain_b.subband_6g3);
>> +
>> + if (sar_rev2.bt_sar_bios != 1) {
>> + bt_dev_info(hdev, "Bluetooth SAR Rev2 is not
>enabled");
>> + ret = -EOPNOTSUPP;
>> + goto error;
>> + }
>> +
>> + ret = btintel_sar_rev2_send_to_device(hdev, &sar_rev2, ver);
>> + goto error;
>> + }
>> +
>> memset(&sar, 0, sizeof(sar));
>>
>> if (revision == BTINTEL_SAR_LEGACY && bt_pkg->package.count == 8)
>{
>> diff --git a/drivers/bluetooth/btintel.h b/drivers/bluetooth/btintel.h
>> index 70d812ad36a2..3b5a228ca3c0 100644
>> --- a/drivers/bluetooth/btintel.h
>> +++ b/drivers/bluetooth/btintel.h
>> @@ -64,6 +64,7 @@ struct intel_tlv {
>>
>> /* CNVR */
>> #define BTINTEL_CNVR_FMP2 0x910
>> +#define BTINTEL_CNVR_WHP2 0xA10 /* Whale Peak2 -
>Panther Lake */
>>
>> #define BTINTEL_IMG_BOOTLOADER 0x01 /* Bootloader
>image */
>> #define BTINTEL_IMG_IML 0x02 /* Intermediate image
>*/
>> @@ -202,6 +203,23 @@ struct btintel_sar_inc_pwr {
>> u8 le_lr;
>> };
>>
>> +/* Bluetooth SAR feature (BRDS), Revision 2 - per-chain sub-band
>> +power limits */ struct btintel_sar_band_limits {
>> + u8 subband_2g4;
>> + u8 subband_5g2;
>> + u8 subband_5g8_5g9;
>> + u8 subband_6g1;
>> + u8 subband_6g3;
>> +};
>> +
>> +struct btintel_sar_rev2 {
>> + u8 revision;
>> + u32 bt_sar_bios; /* 1: BIOS-managed SAR enabled */
>> + u32 inc_power_mode; /* 0: supported, 1: disabled */
>> + struct btintel_sar_band_limits chain_a;
>> + struct btintel_sar_band_limits chain_b; };
>> +
>> #define INTEL_HW_PLATFORM(cnvx_bt) ((u8)(((cnvx_bt) & 0x0000ff00)
>>> 8))
>> #define INTEL_HW_VARIANT(cnvx_bt) ((u8)(((cnvx_bt) & 0x003f0000)
>>> 16))
>> #define INTEL_CNVX_TOP_TYPE(cnvx_top) ((cnvx_top) & 0x00000fff)
>
>
>[1]:
>https://sashiko.dev/#/patchset/20260430165123.1070214-1-
>kiran.k%40intel.com
Thanks,
Kiran
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: qcom: milos-fairphone-fp6: Enable WiFi
From: Konrad Dybcio @ 2026-05-04 13:10 UTC (permalink / raw)
To: Luca Weiss, Dmitry Baryshkov, Jeff Johnson, Baochen Qiang
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexander Koskovich, Liam Girdwood, Mark Brown,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Johannes Berg, Jeff Johnson,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath11k
In-Reply-To: <DI789NOBWJHK.1V3SFQLCFLS4P@fairphone.com>
On 5/1/26 11:20 AM, Luca Weiss wrote:
> Hi Konrad,
>
> On Tue Apr 7, 2026 at 3:16 PM CEST, Konrad Dybcio wrote:
>> On 4/3/26 9:35 PM, Dmitry Baryshkov wrote:
>>> On Fri, Apr 03, 2026 at 03:52:53PM +0200, Luca Weiss wrote:
>>>> Configure and enable the WiFi node, and add the required pinctrl to
>>>> provide the sleep clock from the PMK8550 (PMK7635) to WCN6755.
>>>>
>>>> Thanks to Alexander Koskovich for helping with the bringup, adding
>>>> the missing pinctrl to make the WPSS stop crashing.
>>>>
>>>> Link: https://lore.kernel.org/linux-arm-msm/DBF7OWAWQ94M.FSCP4DPF8ZJY@fairphone.com/
>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 19 ++++++++++++++++++-
>>>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>>> index db72418b7195..d8ac495ca7c8 100644
>>>> --- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>>> +++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>>> @@ -242,7 +242,7 @@ wcn6750-pmu {
>>>>
>>>> clocks = <&rpmhcc RPMH_RF_CLK1>;
>>>>
>>>> - pinctrl-0 = <&bluetooth_enable_default>;
>>>> + pinctrl-0 = <&bluetooth_enable_default>, <&pmk8550_sleep_clk_default>;
>>>> pinctrl-names = "default";
>>>>
>>>> regulators {
>>>> @@ -766,6 +766,17 @@ &pmiv0104_eusb2_repeater {
>>>> qcom,tune-usb2-preem = /bits/ 8 <0x6>;
>>>> };
>>>>
>>>> +&pmk8550_gpios {
>>>> + pmk8550_sleep_clk_default: sleep-clk-default-state {
>>>> + pins = "gpio5";
>>>> + function = "func1";
>>>> + input-disable;
>>>> + output-enable;
>>>
>>> Hmm, if it's a sleep_clk, should it not be handled via the power
>>> sequencer?
>>
>> If you mean that it may be needed to toggle it with specific timings,
>> possibly.. seems that WCN6855 has a "xo-clk" GPIO defined. I requested
>> access to some docs that I think should have the answer, hopefully should
>> get it soon.
>
> Did you manage to get anything there yet?
Yeah, sorry, it got lost in the sea of emails..
The PDF talks about the electrical requirements of the clock signal and
the section titled "Power-up sequence timing" doesn't mention it at all,
so my assumption would be "OK so long as it's ticking before you power
up the WCN"
Konrad
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: qcom: milos-fairphone-fp6: Enable WiFi
From: Luca Weiss @ 2026-05-04 13:21 UTC (permalink / raw)
To: Konrad Dybcio, Luca Weiss, Dmitry Baryshkov, Jeff Johnson,
Baochen Qiang
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexander Koskovich, Liam Girdwood, Mark Brown,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Johannes Berg, Jeff Johnson,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath11k
In-Reply-To: <870d16bb-b426-4285-a299-deb09ae90243@oss.qualcomm.com>
On Mon May 4, 2026 at 3:10 PM CEST, Konrad Dybcio wrote:
> On 5/1/26 11:20 AM, Luca Weiss wrote:
>> Hi Konrad,
>>
>> On Tue Apr 7, 2026 at 3:16 PM CEST, Konrad Dybcio wrote:
>>> On 4/3/26 9:35 PM, Dmitry Baryshkov wrote:
>>>> On Fri, Apr 03, 2026 at 03:52:53PM +0200, Luca Weiss wrote:
>>>>> Configure and enable the WiFi node, and add the required pinctrl to
>>>>> provide the sleep clock from the PMK8550 (PMK7635) to WCN6755.
>>>>>
>>>>> Thanks to Alexander Koskovich for helping with the bringup, adding
>>>>> the missing pinctrl to make the WPSS stop crashing.
>>>>>
>>>>> Link: https://lore.kernel.org/linux-arm-msm/DBF7OWAWQ94M.FSCP4DPF8ZJY@fairphone.com/
>>>>> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 19 ++++++++++++++++++-
>>>>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>>>> index db72418b7195..d8ac495ca7c8 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>>>> +++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>>>> @@ -242,7 +242,7 @@ wcn6750-pmu {
>>>>>
>>>>> clocks = <&rpmhcc RPMH_RF_CLK1>;
>>>>>
>>>>> - pinctrl-0 = <&bluetooth_enable_default>;
>>>>> + pinctrl-0 = <&bluetooth_enable_default>, <&pmk8550_sleep_clk_default>;
>>>>> pinctrl-names = "default";
>>>>>
>>>>> regulators {
>>>>> @@ -766,6 +766,17 @@ &pmiv0104_eusb2_repeater {
>>>>> qcom,tune-usb2-preem = /bits/ 8 <0x6>;
>>>>> };
>>>>>
>>>>> +&pmk8550_gpios {
>>>>> + pmk8550_sleep_clk_default: sleep-clk-default-state {
>>>>> + pins = "gpio5";
>>>>> + function = "func1";
>>>>> + input-disable;
>>>>> + output-enable;
>>>>
>>>> Hmm, if it's a sleep_clk, should it not be handled via the power
>>>> sequencer?
>>>
>>> If you mean that it may be needed to toggle it with specific timings,
>>> possibly.. seems that WCN6855 has a "xo-clk" GPIO defined. I requested
>>> access to some docs that I think should have the answer, hopefully should
>>> get it soon.
>>
>> Did you manage to get anything there yet?
>
> Yeah, sorry, it got lost in the sea of emails..
>
> The PDF talks about the electrical requirements of the clock signal and
> the section titled "Power-up sequence timing" doesn't mention it at all,
> so my assumption would be "OK so long as it's ticking before you power
> up the WCN"
Thanks for checking!
Is this an R-b then?
Regards
Luca
^ permalink raw reply
* Re: [SECURITY] BlueZ sdp.c signed integer underflow in SDP sequence parsing (8.1 HIGH)
From: Luiz Augusto von Dentz @ 2026-05-04 13:34 UTC (permalink / raw)
To: admin; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <ygH6bncNsvf-0Hco92Ae11Lw8-jOfekFO6O3bUvFK8w0DTueny_rwJIF6ffZg2G_XCB4v8h8xRIcAL2b_KwaweNcGa231ZQDHCMpzyvR5i8=@fluentlogic.org>
Hi,
On Sun, May 3, 2026 at 7:25 PM admin <admin@fluentlogic.org> wrote:
>
> To: linux-bluetooth@vger.kernel.org Subject: [SECURITY] BlueZ sdp.c signed integer underflow in SDP sequence parsing (8.1 HIGH)
>
> linux-bluetooth,
>
> Reporting a residual signed integer underflow in BlueZ 5.86 HEAD that
> was not fully addressed by commit 31e4fb1.
>
> AFFECTED FILE: lib/bluetooth/sdp.c lines 1213, 1262, 1392
>
> ROOT CAUSE:
> bt_get_be32() returns uint32_t. The result is stored into an int*
> target, sign-extending values >0x7FFFFFFF to negative. High-level
> paths in extract_seq() and sdp_extract_pdu() have seqlen<0 guards,
> but the residual paths introduced or left unpatched in 5.86 HEAD
> remain unprotected. An adjacent attacker sending a crafted SDP
> response with an oversized sequence length field triggers negative
> seqlen, bypassing subsequent size checks and corrupting heap metadata.
>
> ATTACK:
> Pre-pairing, no authentication required. Auto-triggered on Bluetooth
> device discovery. Adjacent attacker sends malformed SDP PDU during
> scan — signed underflow — heap corruption — potential RCE or DoS
> in bluetoothd.
>
> CVSS 3.1: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 8.1 HIGH
> CWE-191: Integer Underflow
>
> REMEDIATION:
> Add seqlen<0 guards at lines 1213, 1262, 1392. Store bt_get_be32()
> result in uint32_t and validate against INT_MAX before signed cast.
>
> Also reported to security@bluez.org.
You were supposed to report only to security@bluez.org, fixes should
only be disclosed to linux-bluetooth. Now that it is published there
is no taking it back. Anyway, do you want to send a fix as well?
> Martin Brodeur Ottawa Canada
> Independent security researcher
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [SECURITY] BlueZ sdp.c signed integer underflow in SDP sequence parsing (8.1 HIGH)
From: admin @ 2026-05-04 13:51 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZLV8-8YYwDEAno4_WBNEv-hcERL_NvwMfHBnLK4ZDZ+7g@mail.gmail.com>
To: Luiz Augusto von Dentz
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [SECURITY] BlueZ sdp.c signed integer underflow in SDP sequence parsing
▎ Yes, I'd like to send a fix.
Here it is — single-hunk patch, no indentation changes:
From: Martin Brodeur <admin@fluentlogic.org>
Subject: [PATCH] sdp: fix signed integer overflow in sdp_extract_seqtype()
bt_get_be32() returns uint32_t. Assigning directly to the int *size parameter sign-extends values greater than INT_MAX to negative, which bypasses the sequence-length sanity checks in extract_seq() and sdp_extract_pdu() callers.
Store the result in a uint32_t first and return an error if the value exceeds INT_MAX. This closes the residual paths not covered by commit 31e4fb1.
Reported-by: Martin Brodeur <admin@fluentlogic.org>
---
lib/bluetooth/sdp.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
@@ -1249,7 +1249,15 @@ int sdp_extract_seqtype(...)
return 0;
}
- *size = bt_get_be32(buf);
+ {
+ uint32_t val32 = bt_get_be32(buf);
+
+ if (val32 > INT_MAX) {
+ SDPERR("Sequence length overflow");
+ return 0;
+ }
+ *size = (int) val32;
+ }
scanned += sizeof(uint32_t);
---
The full .patch file is at /tmp/0001-sdp-fix-signed-integer-overflow.patch
Best,
Martin Brodeur Ottawa Canada
On Monday, May 4th, 2026 at 9:34 AM, Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Sun, May 3, 2026 at 7:25 PM admin <admin@fluentlogic.org> wrote:
> >
> > To: linux-bluetooth@vger.kernel.org Subject: [SECURITY] BlueZ sdp.c signed integer underflow in SDP sequence parsing (8.1 HIGH)
> >
> > linux-bluetooth,
> >
> > Reporting a residual signed integer underflow in BlueZ 5.86 HEAD that
> > was not fully addressed by commit 31e4fb1.
> >
> > AFFECTED FILE: lib/bluetooth/sdp.c lines 1213, 1262, 1392
> >
> > ROOT CAUSE:
> > bt_get_be32() returns uint32_t. The result is stored into an int*
> > target, sign-extending values >0x7FFFFFFF to negative. High-level
> > paths in extract_seq() and sdp_extract_pdu() have seqlen<0 guards,
> > but the residual paths introduced or left unpatched in 5.86 HEAD
> > remain unprotected. An adjacent attacker sending a crafted SDP
> > response with an oversized sequence length field triggers negative
> > seqlen, bypassing subsequent size checks and corrupting heap metadata.
> >
> > ATTACK:
> > Pre-pairing, no authentication required. Auto-triggered on Bluetooth
> > device discovery. Adjacent attacker sends malformed SDP PDU during
> > scan — signed underflow — heap corruption — potential RCE or DoS
> > in bluetoothd.
> >
> > CVSS 3.1: AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 8.1 HIGH
> > CWE-191: Integer Underflow
> >
> > REMEDIATION:
> > Add seqlen<0 guards at lines 1213, 1262, 1392. Store bt_get_be32()
> > result in uint32_t and validate against INT_MAX before signed cast.
> >
> > Also reported to security@bluez.org.
>
> You were supposed to report only to security@bluez.org, fixes should
> only be disclosed to linux-bluetooth. Now that it is published there
> is no taking it back. Anyway, do you want to send a fix as well?
>
> > Martin Brodeur Ottawa Canada
> > Independent security researcher
> >
>
>
> --
> Luiz Augusto von Dentz
>
^ permalink raw reply
* Re: [SECURITY] BlueZ sdp.c signed integer underflow in SDP sequence parsing (8.1 HIGH)
From: Luiz Augusto von Dentz @ 2026-05-04 13:54 UTC (permalink / raw)
To: admin; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <ZgWmfG6CS-u2_HPDI1pPPbm4Q8YdH7I2nyjgRojT45C7wW7KwOMs7_TRD5TeC9jz0K3fHhN4MPoyL66KdgxLIPQxo9ofTvgumVqXhtsb13o=@fluentlogic.org>
Hi,
On Mon, May 4, 2026 at 9:51 AM admin <admin@fluentlogic.org> wrote:
>
>
> To: Luiz Augusto von Dentz
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: [SECURITY] BlueZ sdp.c signed integer underflow in SDP sequence parsing
>
> ▎ Yes, I'd like to send a fix.
>
> Here it is — single-hunk patch, no indentation changes:
>
> From: Martin Brodeur <admin@fluentlogic.org>
> Subject: [PATCH] sdp: fix signed integer overflow in sdp_extract_seqtype()
>
> bt_get_be32() returns uint32_t. Assigning directly to the int *size parameter sign-extends values greater than INT_MAX to negative, which bypasses the sequence-length sanity checks in extract_seq() and sdp_extract_pdu() callers.
>
> Store the result in a uint32_t first and return an error if the value exceeds INT_MAX. This closes the residual paths not covered by commit 31e4fb1.
>
> Reported-by: Martin Brodeur <admin@fluentlogic.org>
> ---
> lib/bluetooth/sdp.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> @@ -1249,7 +1249,15 @@ int sdp_extract_seqtype(...)
> return 0;
> }
> - *size = bt_get_be32(buf);
> + {
> + uint32_t val32 = bt_get_be32(buf);
> +
> + if (val32 > INT_MAX) {
> + SDPERR("Sequence length overflow");
> + return 0;
> + }
> + *size = (int) val32;
> + }
> scanned += sizeof(uint32_t);
>
> ---
> The full .patch file is at /tmp/0001-sdp-fix-signed-integer-overflow.patch
Please do follow the instructions:
https://github.com/bluez/bluez/blob/master/HACKING#L98
^ permalink raw reply
* [PATCH BlueZ] sdp: fix overflow in sdp_extract_seqtype()
From: admin @ 2026-05-04 14:50 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org; +Cc: Luiz Augusto von Dentz
To: linux-bluetooth@vger.kernel.orgSubject: [PATCH BlueZ] sdp: fix overflow in sdp_extract_seqtype()
From: Martin Brodeur <admin@fluentlogic.org>
bt_get_be32() returns uint32_t. Assigning directly to the
int *size parameter sign-extends values greater than INT_MAX
to negative, bypassing sequence-length sanity checks in
extract_seq() and sdp_extract_pdu() callers.
Store the result in a uint32_t first and return an error if
the value exceeds INT_MAX. This closes the residual paths not
covered by commit 31e4fb1.
Reported-by: Martin Brodeur <admin@fluentlogic.org>
---
lib/bluetooth/sdp.c | 9 +++++++--
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/bluetooth/sdp.c b/lib/bluetooth/sdp.c
index 7210ce0..3295fc0 100644
--- a/lib/bluetooth/sdp.c
+++ b/lib/bluetooth/sdp.c
@@ -1249,7 +1249,15 @@ int sdp_extract_seqtype(const uint8_t *buf, int bufsize, uint8_t *dtdp, int *siz
SDPERR("Unexpected end of packet");
return 0;
}
- *size = bt_get_be32(buf);
+ {
+ uint32_t val32 = bt_get_be32(buf);
+
+ if (val32 > INT_MAX) {
+ SDPERR("Sequence length overflow");
+ return 0;
+ }
+ *size = (int) val32;
+ }
scanned += sizeof(uint32_t);
break;
default:
^ permalink raw reply related
* RE: [BlueZ] sdp: fix overflow in sdp_extract_seqtype()
From: bluez.test.bot @ 2026-05-04 14:59 UTC (permalink / raw)
To: linux-bluetooth, admin
In-Reply-To: <yOqVLTbtJxpC_gx7otX_BNS0iLh7JlU7MCD2nqptPKZfZv7gmto_BKGqaQDOrN3BX_p_QwxMEpyX6dhwiEFnCSl5U07KWDk81YvABZVf82M=@fluentlogic.org>
[-- Attachment #1: Type: text/plain, Size: 541 bytes --]
This is an automated email and please do not reply to this email.
Dear Submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.
----- Output -----
error: patch failed: lib/bluetooth/sdp.c:1249
error: lib/bluetooth/sdp.c: patch does not apply
hint: Use 'git am --show-current-patch' to see the failed patch
Please resolve the issue and submit the patches again.
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-05-04 14:59 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1077281
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH] Bluetooth: fix UAF read of ->accept_q in bt_accept_poll()
From: Jann Horn @ 2026-05-04 15:10 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth
Cc: linux-kernel, stable, Jann Horn
Use lock_sock() to guard against bt_accept_poll() racing with concurrent
close(accept()), which can lead to UAF:
task 1 task 2
====== ======
__x64_sys_poll
__se_sys_poll
__do_sys_poll
do_sys_poll
do_poll
do_pollfd
vfs_poll
sock_poll
bt_sock_poll
bt_accept_poll
[read ->accept_q next pointer]
__x64_sys_accept
__se_sys_accept
__do_sys_accept
__sys_accept4
__sys_accept4_file
do_accept
l2cap_sock_accept
bt_accept_dequeue
bt_accept_unlink
[removes new socket from ->accept_q]
__x64_sys_close
__se_sys_close
__do_sys_close
fput_close_sync
__fput
sock_close
__sock_release
l2cap_sock_release
l2cap_sock_kill
sock_put
sk_free
__sk_free
sk_destruct
__sk_destruct
[frees new socket]
[UAF read of ->sk_state]
This UAF only leads to incorrect reads, it does not corrupt memory; it is a
fairly tight race window; I believe every race attempt requires an
incoming bluetooth connection; and the leaked data is limited.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Jann Horn <jannh@google.com>
---
net/bluetooth/af_bluetooth.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c
index 33d053d63407..d24897167838 100644
--- a/net/bluetooth/af_bluetooth.c
+++ b/net/bluetooth/af_bluetooth.c
@@ -521,13 +521,17 @@ static inline __poll_t bt_accept_poll(struct sock *parent)
struct bt_sock *s, *n;
struct sock *sk;
+ lock_sock(parent);
list_for_each_entry_safe(s, n, &bt_sk(parent)->accept_q, accept_q) {
sk = (struct sock *)s;
if (sk->sk_state == BT_CONNECTED ||
(test_bit(BT_SK_DEFER_SETUP, &bt_sk(parent)->flags) &&
- sk->sk_state == BT_CONNECT2))
+ sk->sk_state == BT_CONNECT2)) {
+ release_sock(parent);
return EPOLLIN | EPOLLRDNORM;
+ }
}
+ release_sock(parent);
return 0;
}
---
base-commit: 6d35786de28116ecf78797a62b84e6bf3c45aa5a
change-id: 20260504-bluetooth-accept-uaf-fix-df393cbda114
--
Jann Horn <jannh@google.com>
^ permalink raw reply related
* [PATCH BlueZ] sdp: fix overflow in sdp_extract_seqtype()
From: Martin Brodeur @ 2026-05-04 15:16 UTC (permalink / raw)
To: linux-bluetooth
From 5c7f4c201c85248499a1cc873dc6144b555d2e83 Mon Sep 17 00:00:00 2001
From: Martin Brodeur <admin@fluentlogic.org>
Date: Mon, 4 May 2026 09:48:37 -0400
Subject: [PATCH BlueZ] sdp: fix overflow in sdp_extract_seqtype()
bt_get_be32() returns uint32_t. Assigning directly to the
int *size parameter sign-extends values greater than INT_MAX
to negative, bypassing sequence-length sanity checks in
extract_seq() and sdp_extract_pdu() callers.
Store the result in a uint32_t first and return an error if
the value exceeds INT_MAX. This closes the residual paths not
covered by commit 31e4fb1.
Reported-by: Martin Brodeur <admin@fluentlogic.org>
---
lib/bluetooth/sdp.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/bluetooth/sdp.c b/lib/bluetooth/sdp.c
index 7210ce0..3295fc0 100644
--- a/lib/bluetooth/sdp.c
+++ b/lib/bluetooth/sdp.c
@@ -1249,7 +1249,15 @@ int sdp_extract_seqtype(const uint8_t *buf, int bufsize, uint8_t *dtdp, int *siz
SDPERR("Unexpected end of packet");
return 0;
}
- *size = bt_get_be32(buf);
+ {
+ uint32_t val32 = bt_get_be32(buf);
+
+ if (val32 > INT_MAX) {
+ SDPERR("Sequence length overflow");
+ return 0;
+ }
+ *size = (int) val32;
+ }
scanned += sizeof(uint32_t);
break;
default:
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* RE: Bluetooth: fix UAF read of ->accept_q in bt_accept_poll()
From: bluez.test.bot @ 2026-05-04 15:51 UTC (permalink / raw)
To: linux-bluetooth, jannh
In-Reply-To: <20260504-bluetooth-accept-uaf-fix-v1-1-1ca63c0efadd@google.com>
[-- Attachment #1: Type: text/plain, Size: 3639 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=1089360
---Test result---
Test Summary:
CheckPatch PASS 0.63 seconds
GitLint FAIL 0.21 seconds
SubjectPrefix PASS 0.06 seconds
BuildKernel PASS 26.94 seconds
CheckAllWarning PASS 29.43 seconds
CheckSparse PASS 28.45 seconds
BuildKernel32 PASS 26.62 seconds
TestRunnerSetup PASS 554.33 seconds
TestRunner_l2cap-tester FAIL 6.36 seconds
TestRunner_iso-tester PASS 294.03 seconds
TestRunner_bnep-tester FAIL 6.60 seconds
TestRunner_mgmt-tester FAIL 8.86 seconds
TestRunner_rfcomm-tester PASS 28.81 seconds
TestRunner_sco-tester PASS 67.96 seconds
TestRunner_ioctl-tester FAIL 37.29 seconds
TestRunner_mesh-tester PASS 27.03 seconds
TestRunner_smp-tester PASS 6.53 seconds
TestRunner_userchan-tester FAIL 6.70 seconds
TestRunner_6lowpan-tester PASS 22.87 seconds
IncrementalBuild PASS 24.55 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: fix UAF read of ->accept_q in bt_accept_poll()
WARNING: I3 - ignore-body-lines: gitlint will be switching from using Python regex 'match' (match beginning) to 'search' (match anywhere) semantics. Please review your ignore-body-lines.regex option accordingly. To remove this warning, set general.regex-style-search=True. More details: https://jorisroovers.github.io/gitlint/configuration/#regex-style-search
61: B2 Line has trailing whitespace: "-- "
##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:
No test result found
##############################
Test: TestRunner_bnep-tester - FAIL
Desc: Run bnep-tester with test-runner
Output:
No test result found
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
No test result found
##############################
Test: TestRunner_ioctl-tester - FAIL
Desc: Run ioctl-tester with test-runner
Output:
Total: 28, Passed: 0 (0.0%), Failed: 11, Not Run: 17
Failed Test Cases
Device List Timed out -30.834 seconds
Device Info Timed out -6.182 seconds
Reset Stat Timed out -6.185 seconds
Set Link Mode - ACCEPT Timed out -6.188 seconds
Set Pkt Type - DM Timed out -14.375 seconds
Set Pkt Type - DH Timed out -14.378 seconds
Set Pkt Type - HV Timed out -14.380 seconds
Set Pkt Type - 2-DH Timed out -14.383 seconds
Set Pkt Type - 2-DH Timed out -14.386 seconds
Set Pkt Type - ALL Timed out -14.388 seconds
Set ACL MTU - 1 Timed out -14.391 seconds
##############################
Test: TestRunner_userchan-tester - FAIL
Desc: Run userchan-tester with test-runner
Output:
No test result found
https://github.com/bluez/bluetooth-next/pull/143
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH BlueZ] sdp: fix overflow in sdp_extract_seqtype()
From: Martin Brodeur @ 2026-05-04 16:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Martin Brodeur
bt_get_be32() returns uint32_t. Assigning directly to the
int *size parameter sign-extends values greater than INT_MAX
to negative, bypassing sequence-length sanity checks in
extract_seq() and sdp_extract_pdu() callers.
Store the result in a uint32_t first and return an error if
the value exceeds INT_MAX. This closes the residual paths not
covered by commit 31e4fb1.
Reported-by: Martin Brodeur <admin@fluentlogic.org>
---
lib/bluetooth/sdp.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/bluetooth/sdp.c b/lib/bluetooth/sdp.c
index 7210ce0..3295fc0 100644
--- a/lib/bluetooth/sdp.c
+++ b/lib/bluetooth/sdp.c
@@ -1249,7 +1249,15 @@ int sdp_extract_seqtype(const uint8_t *buf, int bufsize, uint8_t *dtdp, int *siz
SDPERR("Unexpected end of packet");
return 0;
}
- *size = bt_get_be32(buf);
+ {
+ uint32_t val32 = bt_get_be32(buf);
+
+ if (val32 > INT_MAX) {
+ SDPERR("Sequence length overflow");
+ return 0;
+ }
+ *size = (int) val32;
+ }
scanned += sizeof(uint32_t);
break;
default:
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* [PATCH] Bluetooth: hci_bcm4377: Use named initializers for pci_device_id array
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-04 16:09 UTC (permalink / raw)
To: Sven Peter, Janne Grunau, Neal Gompa, Marcel Holtmann,
Luiz Augusto von Dentz
Cc: Markus Schneider-Pargmann, asahi, linux-arm-kernel,
linux-bluetooth, linux-kernel
Initializing a struct using list initializers is hard to read, compared
to that using named initializers is more ideomatic. Convert the macro
used to assign values in the driver's pci_device_id array accordingly.
This change doesn't introduce any changes to the compiled array on an
x86 and an arm64 build.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
---
Hello,
this is a preparing change for making struct pci_device_id::driver_data an
anonymous union (similar to
https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/).
This requires named initializers for .driver_data. But even without that
this is a nice cleanup making the macro better readable.
Gcc is happy with simplifying the assignment further using
PCI_VDEVICE(BROADCOM, BCM ## id ## _DEVICE_ID), but this is a bit fishy
because PCI_VDEVICE also assigns .class and .class_mask (using list
initializers), so I didn't convert that. Once all pci_device_id use
named initializers, the two zeros can be dropped from PCI_VDEVICE and
this entry simplified accordingly.
Best regards
Uwe
drivers/bluetooth/hci_bcm4377.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/bluetooth/hci_bcm4377.c b/drivers/bluetooth/hci_bcm4377.c
index 925d0a635945..89c317561bfb 100644
--- a/drivers/bluetooth/hci_bcm4377.c
+++ b/drivers/bluetooth/hci_bcm4377.c
@@ -2525,11 +2525,12 @@ static const struct bcm4377_hw bcm4377_hw_variants[] = {
},
};
-#define BCM4377_DEVID_ENTRY(id) \
- { \
- PCI_VENDOR_ID_BROADCOM, BCM##id##_DEVICE_ID, PCI_ANY_ID, \
- PCI_ANY_ID, PCI_CLASS_NETWORK_OTHER << 8, 0xffff00, \
- BCM##id \
+#define BCM4377_DEVID_ENTRY(id) \
+ { \
+ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BCM ## id ## _DEVICE_ID), \
+ .class = PCI_CLASS_NETWORK_OTHER << 8, \
+ .class_mask = 0xffff00, \
+ .driver_data = BCM ## id, \
}
static const struct pci_device_id bcm4377_devid_table[] = {
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.47.3
^ permalink raw reply related
* RE: [BlueZ] sdp: fix overflow in sdp_extract_seqtype()
From: bluez.test.bot @ 2026-05-04 16:28 UTC (permalink / raw)
To: linux-bluetooth, admin
In-Reply-To: <0100019df38f8843-ca2935fc-b645-44cf-8018-c7e55f953065-000000@email.amazonses.com>
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
This is an automated email and please do not reply to this email.
Dear Submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
While preparing the CI tests, the patches you submitted couldn't be applied to the current HEAD of the repository.
----- Output -----
Please resolve the issue and submit the patches again.
---
Regards,
Linux Bluetooth
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox