* Re: [PATCH] Bluetooth: btusb: Add support for TP-Link TL-UB250
From: Paul Menzel @ 2026-06-02 22:03 UTC (permalink / raw)
To: Cris; +Cc: marcel, luiz.dentz, linux-bluetooth, linux-kernel
In-Reply-To: <20260602135419.3092500-1-cxs1494089474@gmail.com>
Dear Cris,
Thank you for your patch.
Am 02.06.26 um 15:54 schrieb Cris:
> Add USB ID 2357:0607 for TP-Link TL-UB250.
>
> This is a Realtek RTL8761BUV based Bluetooth adapter.
>
> Without this entry the device is picked up by the generic Bluetooth USB
> class match and exposes hci0, but the Realtek setup path is not used and
> rtl8761bu firmware/config are not loaded.
>
> The controller reports Realtek Semiconductor Corporation as the
> manufacturer and LMP subversion 0x8761. With this entry added, btusb
> loads rtl_bt/rtl8761bu_fw.bin and rtl_bt/rtl8761bu_config.bin
> successfully.
>
> Use the same flags as the existing TP-Link 2357:0604 entry.
Please add the relevant part of `/sys/kernel/debug/usb/devices` to the
commit message [1]
> Cc: stable@vger.kernel.org
> Signed-off-by: Cris <cxs1494089474@gmail.com>
If possible, a full name would be nice.
> ---
> drivers/bluetooth/btusb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 3aef21d4c..3cbb3c22e 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -831,6 +831,8 @@ static const struct usb_device_id quirks_table[] = {
> BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x2357, 0x0604), .driver_info = BTUSB_REALTEK |
> BTUSB_WIDEBAND_SPEECH },
> + { USB_DEVICE(0x2357, 0x0607), .driver_info = BTUSB_REALTEK |
> + BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x0b05, 0x190e), .driver_info = BTUSB_REALTEK |
> BTUSB_WIDEBAND_SPEECH },
> { USB_DEVICE(0x2550, 0x8761), .driver_info = BTUSB_REALTEK |
With the commit message improved, please feel free to add:
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Kind regards,
Paul
[1]:
https://lore.kernel.org/linux-bluetooth/20260530123934.4583-1-nils.helmig@web.de/
^ permalink raw reply
* RE: Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: bluez.test.bot @ 2026-06-02 22:04 UTC (permalink / raw)
To: linux-bluetooth, i
In-Reply-To: <20260603-btmtk-remote-wakeup-v1-1-5c1006442f36@rong.moe>
[-- Attachment #1: Type: text/plain, Size: 2165 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=1104801
---Test result---
Test Summary:
CheckPatch PASS 0.73 seconds
VerifyFixes PASS 0.13 seconds
VerifySignedoff PASS 0.13 seconds
GitLint FAIL 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.53 seconds
CheckAllWarning PASS 28.28 seconds
CheckSparse PASS 26.92 seconds
BuildKernel32 PASS 26.17 seconds
TestRunnerSetup PASS 531.27 seconds
IncrementalBuild PASS 24.77 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
27: B1 Line exceeds max length (86>80): " [27505.196142] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
28: B1 Line exceeds max length (86>80): " [27510.576045] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
31: B1 Line exceeds max length (86>80): " [27515.948307] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
32: B1 Line exceeds max length (86>80): " [27521.324380] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
52: B1 Line exceeds max length (86>80): " [27569.196322] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
53: B1 Line exceeds max length (86>80): " [27574.572040] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
56: B1 Line exceeds max length (86>80): " [27579.948039] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
57: B1 Line exceeds max length (86>80): " [27585.324331] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command"
https://github.com/bluez/bluetooth-next/pull/276
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [v1] Bluetooth: MGMT: Fix backward compatibility with userspace
From: bluez.test.bot @ 2026-06-02 22:09 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260602205659.212834-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1718 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=1104852
---Test result---
Test Summary:
CheckPatch PASS 0.74 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint PASS 0.33 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 27.61 seconds
CheckAllWarning PASS 29.95 seconds
CheckSparse PASS 28.55 seconds
BuildKernel32 PASS 26.59 seconds
TestRunnerSetup PASS 590.34 seconds
TestRunner_mgmt-tester FAIL 223.41 seconds
TestRunner_mesh-tester FAIL 27.00 seconds
IncrementalBuild PASS 26.37 seconds
Details
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.253 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.645 seconds
Mesh - Send cancel - 2 Timed out 1.988 seconds
https://github.com/bluez/bluetooth-next/pull/277
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ,v1] advertising: Fix sending extra bytes with MGMT_OP_ADD_EXT_ADV_DATA
From: bluez.test.bot @ 2026-06-02 22:16 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260602204749.210857-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1192 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=1104846
---Test result---
Test Summary:
CheckPatch PASS 2.26 seconds
GitLint PASS 0.37 seconds
BuildEll PASS 20.58 seconds
BluezMake PASS 696.31 seconds
CheckSmatch WARNING 355.44 seconds
bluezmakeextell PASS 182.82 seconds
IncrementalBuild PASS 668.57 seconds
ScanBuild PASS 1026.46 seconds
Details
##############################
Test: CheckSmatch - WARNING
Desc: Run smatch tool with source
Output:
src/advertising.c: note: in included file:./src/shared/mgmt.h:95:25: error: redefinition of unsigned int enum mgmt_io_capabilitysrc/advertising.c: note: in included file:./src/shared/mgmt.h:95:25: error: redefinition of unsigned int enum mgmt_io_capability
https://github.com/bluez/bluez/pull/2167
---
Regards,
Linux Bluetooth
^ permalink raw reply
* RE: [BlueZ,v1,1/4] profiles/audio/bass: Use BASS_Modify_Source when assistant is active
From: bluez.test.bot @ 2026-06-02 22:27 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260602210022.213562-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1287 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=1104856
---Test result---
Test Summary:
CheckPatch PASS 1.75 seconds
GitLint FAIL 1.01 seconds
BuildEll PASS 20.78 seconds
BluezMake PASS 686.70 seconds
MakeCheck PASS 18.37 seconds
MakeDistcheck PASS 252.36 seconds
CheckValgrind PASS 298.96 seconds
CheckSmatch PASS 352.74 seconds
bluezmakeextell PASS 185.30 seconds
IncrementalBuild PASS 687.41 seconds
ScanBuild PASS 1066.94 seconds
Details
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
[BlueZ,v1,1/4] profiles/audio/bass: Use BASS_Modify_Source when assistant is active
1: T1 Title exceeds max length (83>80): "[BlueZ,v1,1/4] profiles/audio/bass: Use BASS_Modify_Source when assistant is active"
https://github.com/bluez/bluez/pull/2168
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [PATCH] Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: Jordan Walters @ 2026-06-02 23:34 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel
The hci_unregister_dev() function fails to disable the cmd_timer and ncmd_timer
before freeing the hci_dev structure. If an asynchronous event or timeout occurs
during device teardown, the timer callbacks may execute after the device has
been freed, leading to a KASAN slab-use-after-free panic.
This patch adds the necessary disable_delayed_work_sync() calls to securely flush
the timers before the teardown sequence proceeds.
Signed-off-by: Jordan Walters <gloambit@gloam.sh>
---
net/bluetooth/hci_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 28d7929dc59..1cbc666527c 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2671,6 +2671,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
disable_work_sync(&hdev->tx_work);
disable_work_sync(&hdev->power_on);
disable_work_sync(&hdev->error_reset);
+ disable_delayed_work_sync(&hdev->cmd_timer);
+ disable_delayed_work_sync(&hdev->ncmd_timer);
hci_cmd_sync_clear(hdev);
^ permalink raw reply related
* RE: Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: bluez.test.bot @ 2026-06-03 2:40 UTC (permalink / raw)
To: linux-bluetooth, jaggyaur
In-Reply-To: <20260602233414.209730-1-jaggyaur@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3383 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=1104912
---Test result---
Test Summary:
CheckPatch FAIL 0.73 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.14 seconds
GitLint FAIL 0.34 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.42 seconds
CheckAllWarning PASS 27.84 seconds
CheckSparse PASS 27.29 seconds
BuildKernel32 PASS 25.11 seconds
TestRunnerSetup PASS 528.65 seconds
TestRunner_l2cap-tester PASS 61.14 seconds
TestRunner_iso-tester PASS 81.68 seconds
TestRunner_bnep-tester PASS 19.35 seconds
TestRunner_mgmt-tester FAIL 212.14 seconds
TestRunner_rfcomm-tester PASS 25.82 seconds
TestRunner_sco-tester PASS 32.74 seconds
TestRunner_ioctl-tester PASS 26.06 seconds
TestRunner_mesh-tester FAIL 26.17 seconds
TestRunner_smp-tester PASS 23.85 seconds
TestRunner_userchan-tester PASS 20.29 seconds
TestRunner_6lowpan-tester PASS 22.90 seconds
IncrementalBuild PASS 25.01 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
Bluetooth: Fix Use-After-Free in hci_unregister_dev
WARNING: Prefer a maximum 75 chars per line (possible unwrapped commit description?)
#94:
The hci_unregister_dev() function fails to disable the cmd_timer and ncmd_timer
WARNING: From:/Signed-off-by: email address mismatch: 'From: Jordan Walters <jaggyaur@gmail.com>' != 'Signed-off-by: Jordan Walters <gloambit@gloam.sh>'
total: 0 errors, 2 warnings, 0 checks, 8 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14608047.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
##############################
Test: GitLint - FAIL
Desc: Run gitlint
Output:
Bluetooth: Fix Use-After-Free in hci_unregister_dev
8: B1 Line exceeds max length (81>80): "This patch adds the necessary disable_delayed_work_sync() calls to securely flush"
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.239 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.518 seconds
Mesh - Send cancel - 2 Timed out 1.991 seconds
https://github.com/bluez/bluetooth-next/pull/278
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v2] Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING
From: Jiajia Liu @ 2026-06-03 2:45 UTC (permalink / raw)
To: Paul Menzel
Cc: Luiz Augusto von Dentz, Marcel Holtmann, linux-bluetooth,
linux-kernel, Jiajia Liu
In-Reply-To: <95453e74-636d-4a9f-91c0-189366423180@molgen.mpg.de>
On Tue, Jun 02, 2026 at 11:53:29PM +0200, Paul Menzel wrote:
> [Cc: -brian.gix@intel.com (bouncing)]
>
> Dear Luiz,
>
>
> Am 02.06.26 um 18:43 schrieb Luiz Augusto von Dentz:
>
> > On Tue, Jun 2, 2026 at 10:41 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>
> > > Am 02.06.26 um 09:00 schrieb Jiajia Liu:
> > > > When hci_inquiry_complete_evt is called between le_scan_disable and
> > > > le_set_scan_enable_complete and no remote name needs to be resolved,
> > > > the interleaved discovery with SIMULTANEOUS quirk gets stuck in
> > > > DISCOVERY_FINDING. le_set_scan_enable_complete does not check inquiry
> > > > state. No one sets DISCOVERY_STOPPED in this process.
> > > >
> > > > Add state check in le_set_scan_enable_complete and change state if
> > > > the state is DISCOVERY_FINDING. Tested with AX201 (8087:0026) in Dell
> > >
> > > … change state to DISCOVERY_STOPPED …
> > >
> > > I’d add a new paragraph for the Tested part.
> > >
> > > > Vostro 13. Discovering disabled MGMT Event below is reported when
> > > > running into the above condition.
> > >
> > > Thank you for sharing the test device. Could you please document how to
> > > get into this state exactly? Some Xiaomi device?
> >
> > What are you talking about here by saying Xiaomi device? He literally
> > said Dell Vostro 13, a laptop, and this is a local only procedure,
> > there is no remote device involved here.
>
> In the trace below a Xiaomi device shows up, if I am not mistaken.
There should be no requirements for Bluetooth devices. To keep the serial
number of packet continuous, I didn't remove the Device Found MGMT Event.
It looks like someone's TV device.
The producer is Open the bluetooth panel of gnome-control-center and wait.
If the device list on the pannel is not flushed again and becomes empty,
it probably gets into this state. btmon or dynamic debug of
hci_discovery_set_state can confirm the state.
It think it depends on the timing of Inquiry Complete Event. There is a
very small time slot between disabling LE scan and disabling completion.
If Inquiry Complete Event arrives in the slot, there is a chance to hit
the state.
>
> > > > @ MGMT Command: Start Discovery (0x0023) {0x0001} [hci0] 10885.970873
> > > > Address type: 0x07
> > > > BR/EDR
> > > > LE Public
> > > > LE Random
> > > > ...
> > > > < HCI Command: LE Set Extended Scan Enable #38205 [hci0] 10886.131438
> > > > Extended scan: Enabled (0x01)
> > > > Filter duplicates: Enabled (0x01)
> > > > Duration: 0 msec (0x0000)
> > > > Period: 0.00 sec (0x0000)
> > > > > HCI Event: Command Complete (0x0e) plen 4 #38206 [hci0] 10886.133295
> > > > LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
> > > > Status: Success (0x00)
> > > > @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10886.133414
> > > > Address type: 0x07
> > > > BR/EDR
> > > > LE Public
> > > > LE Random
> > > > Discovery: Enabled (0x01)
> > > > < HCI Command: Inquiry (0x01|0x0001) plen 5 #38207 [hci0] 10886.133528
> > > > Access code: 0x9e8b33 (General Inquiry)
> > > > Length: 10.24s (0x08)
> > > > Num responses: 0
> > > > > HCI Event: Command Status (0x0f) plen 4 #38208 [hci0] 10886.141333
> > > > Inquiry (0x01|0x0001) ncmd 2
> > > > Status: Success (0x00)
> > > > ...
> > > > < HCI Command: LE Set Extended Scan Enable #38242 [hci0] 10896.381802
> > > > Extended scan: Disabled (0x00)
> > > > Filter duplicates: Disabled (0x00)
> > > > Duration: 0 msec (0x0000)
> > > > Period: 0.00 sec (0x0000)
> > > > > HCI Event: Inquiry Complete (0x01) plen 1 #38243 [hci0] 10896.383419
> > > > Status: Success (0x00)
> > > > > HCI Event: Command Complete (0x0e) plen 4 #38244 [hci0] 10896.394378
> > > > LE Set Extended Scan Enable (0x08|0x0042) ncmd 2
> > > > Status: Success (0x00)
> > > > @ MGMT Event: Device Found (0x0012) plen 22 {0x0001} [hci0] 10896.394497
> > > > LE Address: 88:12:AC:92:43:69
> > > > RSSI: -101 dBm (0x9b)
> > > > Flags: 0x00000004
> > > > Not Connectable
> > > > Data length: 8
> > > > Company: Xiaomi Inc. (911)
> > > > Data[0]:
> > > > 16-bit Service UUIDs (complete): 1 entry
> > > > Xiaomi Inc. (0xfdaa)
> > > > @ MGMT Event: Discovering (0x0013) plen 2 {0x0001} [hci0] 10896.394506
> > > > Address type: 0x07
> > > > BR/EDR
> > > > LE Public
> > > > LE Random
> > > > Discovery: Disabled (0x00)
> > > >
> > > > Fixes: 8ffde2a73f2c ("Bluetooth: Convert le_scan_disable timeout to hci_sync")
> > > > Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - move the handler to hci_event.c
> > > > - remove unnecessary bt_dev_dbg
> > > > - update commit message
> > > >
> > > > ---
> > > > net/bluetooth/hci_event.c | 7 +++++++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > > > index eea2f810aafa..1cd5f97daafe 100644
> > > > --- a/net/bluetooth/hci_event.c
> > > > +++ b/net/bluetooth/hci_event.c
> > > > @@ -1769,6 +1769,13 @@ static void le_set_scan_enable_complete(struct hci_dev *hdev, u8 enable)
> > > >
> > > > hci_dev_clear_flag(hdev, HCI_LE_SCAN);
> > > >
> > > > + if (hdev->discovery.type == DISCOV_TYPE_INTERLEAVED &&
> > > > + hci_test_quirk(hdev, HCI_QUIRK_SIMULTANEOUS_DISCOVERY) &&
> > > > + !test_bit(HCI_INQUIRY, &hdev->flags) &&
> > > > + hdev->discovery.state == DISCOVERY_FINDING) {
> > > > + hci_discovery_set_state(hdev, DISCOVERY_STOPPED);
> > > > + }
> > > > +
> > > > /* The HCI_LE_SCAN_INTERRUPTED flag indicates that we
> > > > * interrupted scanning due to a connect request. Mark
> > > > * therefore discovery as stopped.
>
>
> Kind regards,
>
> Paul
^ permalink raw reply
* [PATCH v2] Bluetooth: btusb: Add support for TP-Link TL-UB250
From: Cris @ 2026-06-03 3:58 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, luiz.dentz, linux-kernel, pmenzel, Cris
In-Reply-To: <20260602135419.3092500-1-cxs1494089474@gmail.com>
Add USB ID 2357:0607 for TP-Link TL-UB250.
This is a Realtek RTL8761BUV based Bluetooth adapter.
Without this entry the device is picked up by the generic Bluetooth USB
class match and exposes hci0, but the Realtek setup path is not used and
rtl8761bu firmware/config are not loaded.
The controller reports Realtek Semiconductor Corporation as the
manufacturer and LMP subversion 0x8761. With this entry added, btusb
loads rtl_bt/rtl8761bu_fw.bin and rtl_bt/rtl8761bu_config.bin
successfully.
Relevant part of /sys/kernel/debug/usb/devices:
T: Bus=01 Lev=02 Prnt=06 Port=00 Cnt=01 Dev#= 9 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2357 ProdID=0607 Rev= 2.00
S: Product=TP-Link TL-UB250 Adapter
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
Use the same flags as the existing TP-Link 2357:0604 entry.
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Cris <cxs1494089474@gmail.com>
---
Changes in v2:
- Add the relevant /sys/kernel/debug/usb/devices excerpt.
- Drop Cc stable to avoid the checkpatch warning without a Fixes tag.
- Add Reviewed-by from Paul Menzel.
drivers/bluetooth/btusb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 3aef21d4c..3cbb3c22e 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -831,6 +831,8 @@ static const struct usb_device_id quirks_table[] = {
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x2357, 0x0604), .driver_info = BTUSB_REALTEK |
BTUSB_WIDEBAND_SPEECH },
+ { USB_DEVICE(0x2357, 0x0607), .driver_info = BTUSB_REALTEK |
+ BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x0b05, 0x190e), .driver_info = BTUSB_REALTEK |
BTUSB_WIDEBAND_SPEECH },
{ USB_DEVICE(0x2550, 0x8761), .driver_info = BTUSB_REALTEK |
--
2.34.1
^ permalink raw reply related
* [PATCH v2] Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: Jordan Walters @ 2026-06-03 4:39 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel
The hci_unregister_dev() function fails to safely cancel the cmd_timer
and ncmd_timer before freeing the hci_dev structure. If an asynchronous
event or timeout occurs during device teardown, the timer callbacks
may execute after the device has been freed, leading to a KASAN
slab-use-after-free panic.
In v1, the timers were disabled too early in the teardown sequence,
which caused deadlocks in CI testing (mgmt-tester and mesh-tester)
because the HCI teardown process relies on these timers to safely
time out the HCI_OP_RESET command.
This patch adds cancel_delayed_work_sync() calls at the very end
of hci_unregister_dev() after all teardown procedures have completed,
guaranteeing the timers are fully flushed before the struct is freed.
Signed-off-by: Jordan Walters <jaggyaur@gmail.com>
---
net/bluetooth/hci_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 28d7929dc59..3db1b3738b5 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2698,6 +2698,9 @@ void hci_unregister_dev(struct hci_dev *hdev)
rfkill_unregister(hdev->rfkill);
rfkill_destroy(hdev->rfkill);
}
+ cancel_delayed_work_sync(&hdev->cmd_timer);
+ cancel_delayed_work_sync(&hdev->ncmd_timer);
+
hci_dev_put(hdev);
}
^ permalink raw reply related
* RE: [v2] Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: bluez.test.bot @ 2026-06-03 7:06 UTC (permalink / raw)
To: linux-bluetooth, jaggyaur
In-Reply-To: <20260603043925.228091-1-jaggyaur@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 551 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: net/bluetooth/hci_core.c:2698
error: net/bluetooth/hci_core.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
* RE: [v2] Bluetooth: btusb: Add support for TP-Link TL-UB250
From: bluez.test.bot @ 2026-06-03 7:30 UTC (permalink / raw)
To: linux-bluetooth, cxs1494089474
In-Reply-To: <20260603035818.926654-1-cxs1494089474@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 988 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1105002
---Test result---
Test Summary:
CheckPatch PASS 0.48 seconds
VerifyFixes PASS 0.09 seconds
VerifySignedoff PASS 0.08 seconds
GitLint PASS 0.19 seconds
SubjectPrefix PASS 0.06 seconds
BuildKernel PASS 24.83 seconds
CheckAllWarning PASS 27.63 seconds
CheckSparse PASS 26.29 seconds
BuildKernel32 PASS 24.07 seconds
TestRunnerSetup PASS 530.02 seconds
IncrementalBuild PASS 23.67 seconds
https://github.com/bluez/bluetooth-next/pull/279
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: btnxpuart: Fix use-after-free in probe error path
From: Neeraj Sanjay Kale @ 2026-06-03 7:33 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Zhao Dongdong
Cc: Amitkumar Karwar, marcel@holtmann.org,
linux-bluetooth@vger.kernel.org, Zhao Dongdong
In-Reply-To: <CABBYNZLQU_dqZkUP_EUcT5bYGif=dqC-sYEM+yV9Y=TrWwNWMg@mail.gmail.com>
Hi Luiz
Sorry for missing this patch and delay in reply.
> Hi,
>
> On Thu, May 14, 2026 at 8:54 PM Zhao Dongdong <winter91@foxmail.com>
> wrote:
> >
> > From: Zhao Dongdong <zhaodongdong@kylinos.cn>
> >
> > In nxp_serdev_probe(), if hci_register_dev() succeeds but ps_setup()
> > fails, the error path jumps to 'probe_fail' which only calls
> > hci_free_dev() and asserts the reset GPIO, but does NOT call
> > hci_unregister_dev() first.
> >
> > This leaves the HCI device registered in the system with its backing
> > memory freed, leading to a use-after-free when userspace subsequently
> > accesses the device (e.g. via hciconfig or bluetoothd).
> >
> > Fix by adding a 'probe_fail_unregister' label that calls
> > hci_unregister_dev() before falling through to the existing
> > 'probe_fail' label. The original 'probe_fail' label is preserved for
> > the case where hci_register_dev() itself fails (device was never
> > registered, so no unregister is needed).
> >
> > Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
> > ---
> > v3: fix gitlint WARNING
> > v2: fix SubjectPrefix
> > ---
> > drivers/bluetooth/btnxpuart.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/bluetooth/btnxpuart.c
> > b/drivers/bluetooth/btnxpuart.c index e7036a48ce48..a4d7747e5be0
> > 100644
> > --- a/drivers/bluetooth/btnxpuart.c
> > +++ b/drivers/bluetooth/btnxpuart.c
> > @@ -1907,13 +1907,15 @@ static int nxp_serdev_probe(struct
> serdev_device *serdev)
> > }
> >
> > if (ps_setup(hdev))
> > - goto probe_fail;
> > + goto probe_fail_unregister;
> >
> > hci_devcd_register(hdev, nxp_coredump, nxp_coredump_hdr,
> > nxp_coredump_notify);
> >
> > return 0;
> >
> > +probe_fail_unregister:
> > + hci_unregister_dev(hdev);
> > probe_fail:
> > reset_control_assert(nxpdev->pdn);
> > hci_free_dev(hdev);
> > --
> > 2.25.1
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsashiko
> .dev%2F%23%2Fpatchset%2Ftencent_4A1D33225C74DB33EFAE8A0B6E88456
> 7DD09%2540qq.com&data=05%7C02%7Cneeraj.sanjaykale%40nxp.com%7Cf
> 66f5f2142cf4f59b26108deb281843b%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C639144466498184318%7CUnknown%7CTWFpbGZsb3d8eyJF
> bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT
> WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=p2O4WrDwcUfvYYe7gl
> 9uo%2B1NotBcSNEHVetMDEy6ABk%3D&reserved=0
>
> Not sure if it is valid, but it probably worth checking since we can perhaps
> simplify the error path.
>
>
> --
> Luiz Augusto von Dentz
Regarding the AI review comment suggesting to move ps_setup() before hci_register_dev():
ps_setup() uses hdev throughout for logging (bt_dev_err/warn/info) and also sets psdata->hdev = hdev. Moving it before hci_register_dev() would require changing all bt_dev_* calls to dev_* variants using serdev->dev, which are trivial but unnecessary code changes.
It would also break any automation/test systems monitoring logs for patterns like "hci0: Error ...".
Also, ps_setup() is called immediately after hci_register_dev() with no scheduling or sleep in between. hdev->power_on is queued asynchronously and will only be processed after probe() completes. So there is no race condition as the AI review suggested.
The patch as submitted is safe to merge. Let us know otherwise.
Regards,
Neeraj
^ permalink raw reply
* [PATCH v3] Bluetooth: btnxpuart: Fix use-after-free in probe error path
From: Neeraj Sanjay Kale @ 2026-06-03 7:34 UTC (permalink / raw)
To: Zhao Dongdong, Amitkumar Karwar, marcel@holtmann.org
Cc: linux-bluetooth@vger.kernel.org, Zhao Dongdong
In-Reply-To: <tencent_F2E2AF1B6F510577B10C6897ED768BBBAF07@qq.com>
Hi Zhao Dongdong,
Thank you for the patch.
Reviewed-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Regards,
Neeraj
> From: Zhao Dongdong <zhaodongdong@kylinos.cn>
>
> In nxp_serdev_probe(), if hci_register_dev() succeeds but ps_setup() fails, the
> error path jumps to 'probe_fail' which only calls
> hci_free_dev() and asserts the reset GPIO, but does NOT call
> hci_unregister_dev() first.
>
> This leaves the HCI device registered in the system with its backing memory
> freed, leading to a use-after-free when userspace subsequently accesses the
> device (e.g. via hciconfig or bluetoothd).
>
> Fix by adding a 'probe_fail_unregister' label that calls
> hci_unregister_dev() before falling through to the existing 'probe_fail' label.
> The original 'probe_fail' label is preserved for the case where
> hci_register_dev() itself fails (device was never registered, so no unregister is
> needed).
>
> Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn>
> ---
> v3: fix gitlint WARNING
> v2: fix SubjectPrefix
> ---
> drivers/bluetooth/btnxpuart.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> index e7036a48ce48..a4d7747e5be0 100644
> --- a/drivers/bluetooth/btnxpuart.c
> +++ b/drivers/bluetooth/btnxpuart.c
> @@ -1907,13 +1907,15 @@ static int nxp_serdev_probe(struct serdev_device
> *serdev)
> }
>
> if (ps_setup(hdev))
> - goto probe_fail;
> + goto probe_fail_unregister;
>
> hci_devcd_register(hdev, nxp_coredump, nxp_coredump_hdr,
> nxp_coredump_notify);
>
> return 0;
>
> +probe_fail_unregister:
> + hci_unregister_dev(hdev);
> probe_fail:
> reset_control_assert(nxpdev->pdn);
> hci_free_dev(hdev);
> --
> 2.25.1
^ permalink raw reply
* [PATCH v3] Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: Jordan Walters @ 2026-06-03 7:51 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel
The hci_unregister_dev() function fails to safely cancel the cmd_timer
and ncmd_timer before freeing the hci_dev structure. If an asynchronous
event or timeout occurs during device teardown, the timer callbacks
may execute after the device has been freed, leading to a KASAN
slab-use-after-free panic.
This patch adds cancel_delayed_work_sync() calls at the end of
hci_unregister_dev() after all teardown procedures have completed.
This ensures the timers are fully flushed before the struct is freed,
preventing any use-after-free conditions.
Signed-off-by: Jordan Walters <jaggyaur@gmail.com>
---
net/bluetooth/hci_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 28d7929dc59..3db1b3738b5 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2698,6 +2698,9 @@ void hci_unregister_dev(struct hci_dev *hdev)
rfkill_unregister(hdev->rfkill);
rfkill_destroy(hdev->rfkill);
}
device_del(&hdev->dev);
+
+ cancel_delayed_work_sync(&hdev->cmd_timer);
+ cancel_delayed_work_sync(&hdev->ncmd_timer);
+
/* Actual cleanup is deferred until hci_release_dev(). */
hci_dev_put(hdev);
}
^ permalink raw reply related
* Re: [PATCH] Bluetooth: btmtk: Fix MT7925 WMT command timeout due to sleep protection
From: Chris Lu (陸稚泓) @ 2026-06-03 8:37 UTC (permalink / raw)
To: messinadm@gmail.com, linux-bluetooth@vger.kernel.org
Cc: luiz.dentz@gmail.com, Chris Lu (陸稚泓),
SS Wu (巫憲欣), marcel@holtmann.org,
Peter Tsao (曹珆彰)
In-Reply-To: <KL1PR03MB597680711115B27DA7D42571FA132@KL1PR03MB5976.apcprd03.prod.outlook.com>
Add linux-bluetooth to maillist
> From: Chris Lu (陸稚泓) <Chris.Lu@mediatek.com>
> Sent: Wednesday, June 3, 2026 3:50 PM
> To: messinadm@gmail.com
> Cc: luiz.dentz@gmail.com; SS Wu (巫憲欣) <ss.wu@mediatek.com>;
> marcel@holtmann.org; Peter Tsao (曹珆彰) <Peter.Tsao@mediatek.com>
> Subject: Re: [PATCH] Bluetooth: btmtk: Fix MT7925 WMT command timeout
> due to sleep protection
>
> Hi Danny,
>
> Thanks for your submission. I have some question about this patch.
>
> > -----Original Message-----
> > From: Danny Messina <messinadm@gmail.com>
> > Sent: Monday, June 1, 2026 2:07 AM
> > To: linux-bluetooth@vger.kernel.org
> > Cc: Peter Tsao (曹珆彰) <Peter.Tsao@mediatek.com>;
> > marcel@holtmann.org;
> > Luiz Augusto von Dentz <luiz.dentz@gmail.com>
> > Subject: [PATCH] Bluetooth: btmtk: Fix MT7925 WMT command timeout
> > due
> > to sleep protection
> >
> >
> > External email : Please do not click links or open attachments
> > until
> > you have verified the sender or the content.
> >
> > The MediaTek MT7925 USB Bluetooth device (0e8d:0717) fails to
> > initialize
> > with repeated "Execution of wmt command timed out" errors:
> >
> > Bluetooth: hci0: Execution of wmt command timed out
> > Bluetooth: hci0: Failed to send wmt patch dwnld (-110)
> > Bluetooth: hci0: Failed to set up firmware (-110)
> >
> > USB capture (usbmon) confirms WMT commands reach the device — the
> > Control OUT transfer completes with status 0 — but the device
> > never
> > responds on any endpoint. The control IN polling URB returns zero
> > bytes
> > indefinitely until HCI_INIT_TIMEOUT expires.
> >
> > The root cause is the MT7925 BT core's sleep protection register
> > (0x18011100, bit 1 = SLPPROT_BYPASS). When SLPPROT is active the
> > BT
> > processor ignores incoming WMT commands.
> >
> > Two additional issues compound this:
> >
> > 1. After repeated driver load/unload cycles without a hardware
> > reset,
> > the BT subsystem's WMT state machine becomes stuck. A
> > subsystem
> > reset via btmtk_usb_subsys_reset() restores it to a workable
> > state.
> >
> > 2. After btmtk_setup_firmware_79xx() activates the downloaded
> > firmware
> > (which ends with a 100ms activation delay), the chip re-
> > enables
> > SLPPROT. The subsequent FUNC_CTRL WMT command therefore also
> > times
> > out unless SLPPROT is bypassed again.
> >
> > Fix this for dev_id 0x7925 in btmtk_usb_setup():
> > 1. Call btmtk_usb_subsys_reset() to clear any stuck WMT state.
> > 2. Set 0x18011100 |= BIT(1) before firmware download.
> > 3. Set 0x18011100 |= BIT(1) again before FUNC_CTRL.
> >
>
> Could you share how you identified which register/value need to be
> modified on MT7925 with such situation and why performed reset at
> this specific point helps avoid the setup issue?
>
> > Tested on a System76 Thelio desktop with MT7925 PCIe combo card,
> > USB ID 0e8d:0717, kernel 6.18.7.
> >
> > Signed-off-by: Danny Messina <messinadm@gmail.com>
> > ---
> > drivers/bluetooth/btmtk.c | 33 +++++++++++++++++++++++++++++++++
> > 1 file changed, 33 insertions(+)
> >
> > diff --git a/drivers/bluetooth/btmtk.c
> > b/drivers/bluetooth/btmtk.c
> > --- a/drivers/bluetooth/btmtk.c
> > +++ b/drivers/bluetooth/btmtk.c
> > @@ -1326,6 +1326,24 @@
> > case 0x7922:
> > case 0x7925:
> > case 0x7961:
> > + if (dev_id == 0x7925) {
> > + u32 val = 0;
> > +
> > + /* Reset BT subsystem to clear any stuck
> > WMT
> > state */
> > + err = btmtk_usb_subsys_reset(hdev, dev_id);
> > + if (err < 0)
> > + bt_dev_warn(hdev, "BT subsys reset
> > failed (%d), continuing", err);
> > +
> > + /* Bypass sleep protection so WMT commands
> > reach the BT core */
> > + err = btmtk_usb_uhw_reg_read(hdev,
> > 0x18011100,
> > &val);
> > + if (err < 0)
> > + return err;
> > + val |= BIT(1);
> > + err = btmtk_usb_uhw_reg_write(hdev,
> > 0x18011100, val);
> > + if (err < 0)
> > + return err;
> > + }
> > +
> > btmtk_fw_get_filename(fw_bin_name,
> > sizeof(fw_bin_name), dev_id,
> > fw_version, fw_flavor);
> >
> > @@ -1342,6 +1360,19 @@
> > if (err < 0)
> > return err;
> >
> > + /* Re-bypass sleep protection after firmware
> > activation for MT7925 */
> > + if (dev_id == 0x7925) {
> > + u32 val = 0;
> > +
> > + err = btmtk_usb_uhw_reg_read(hdev,
> > 0x18011100,
> > &val);
> > + if (err < 0)
> > + return err;
> > + val |= BIT(1);
> > + err = btmtk_usb_uhw_reg_write(hdev,
> > 0x18011100, val);
> > + if (err < 0)
> > + return err;
> > + }
> > +
> > /* Enable Bluetooth protocol */
> > param = 1;
> > wmt_params.op = BTMTK_WMT_FUNC_CTRL;
>
> I'd also like to share some relevant background on this change:
>
> MediaTek Bluetooth team previously implemented a similar reset before
> firmware download to ensure the controller was always in an initial
> state. However, it was later reported by kernel community that this
> caused USB enumeration failures on other devices, so the change was
> reverted (commit 33634e2ab "Bluetooth: btmtk: Remove the resetting
> step before downloading the fw").
>
> In April this year, I submitted a fix addressing setup failures on
> MediaTek Bluetooth devices, which has been included since kernel
> v7.1- rc. Could you try reproducing the issue with a recent kernel to
> see whether the problem still occurs?
>
> Looking forward to your feedback.
>
> Best regards,
> Chris Lu
^ permalink raw reply
* [PATCH v4] Bluetooth: hci_core: Fix UAF in hci_unregister_dev()
From: Jordan Walters @ 2026-06-03 8:50 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel
hci_unregister_dev() does not disable cmd_timer and ncmd_timer
before the hci_dev structure is freed. If a timeout fires
during device teardown, the callback dereferences freed memory
(including the hdev->reset function pointer), leading to a
use-after-free.
Add disable_delayed_work_sync() calls alongside the existing
disable_work_sync() calls to ensure both timers are fully
quiesced before teardown proceeds.
Signed-off-by: Jordan Walters <jaggyaur@gmail.com>
---
v4: v3 accidentally resent older fix using cancel_delayed_work_sync.
This is the correct version using disable_delayed_work_sync.
net/bluetooth/hci_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 28d7929dc59..1cbc666527c 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2671,6 +2671,8 @@ void hci_unregister_dev(struct hci_dev *hdev)
disable_work_sync(&hdev->tx_work);
disable_work_sync(&hdev->power_on);
disable_work_sync(&hdev->error_reset);
+ disable_delayed_work_sync(&hdev->cmd_timer);
+ disable_delayed_work_sync(&hdev->ncmd_timer);
hci_cmd_sync_clear(hdev);
--
2.49.0
^ permalink raw reply related
* RE: [v3] Bluetooth: Fix Use-After-Free in hci_unregister_dev
From: bluez.test.bot @ 2026-06-03 12:05 UTC (permalink / raw)
To: linux-bluetooth, jaggyaur
In-Reply-To: <20260603075134.246832-1-jaggyaur@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 478 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: corrupt patch at line 23
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
* Re: [PATCH] Bluetooth: btmtk: Fix MT7925 WMT command timeout due to sleep protection
From: Danny Messina @ 2026-06-03 12:27 UTC (permalink / raw)
To: Chris Lu (陸稚泓)
Cc: linux-bluetooth@vger.kernel.org, luiz.dentz@gmail.com,
SS Wu (巫憲欣), marcel@holtmann.org,
Peter Tsao (曹珆彰)
In-Reply-To: <3333c9b420af0b81c0ed21b969ca6e67b9701a84.camel@mediatek.com>
Hi Chris,
Thanks for the background, very helpful.
On register identification: I used usbmon to confirm WMT commands were
physically reaching the device with Control OUT completing
successfully, but the device returned zero bytes on every control IN
poll for the full 10-second timeout. After reading through btmtk.c and
adding printks to trace the exact failure point, I found a December
2023 patch submission by Peter Tsao titled "Bluetooth: btusb: Fix
MT7925 fail to send download patch command" which referenced writing
to register 0x18011100 to prevent the device entering sleep state
during firmware download. Testing confirmed this resolved the WMT
timeout on my hardware. The second bypass before FUNC_CTRL was
discovered when firmware download succeeded but FUNC_CTRL subsequently
timed out, indicating the chip re-enables sleep protection during the
100ms firmware activation delay.
On the subsystem reset: I was not aware of commit 33634e2ab. In my
testing the reset was necessary to recover from repeated failed
initialization attempts, as rmmod/modprobe without a cold power cycle
left the chip unresponsive to the SLPPROT bypass alone. I defer to
your judgment on whether it belongs here.
On your v7.1-rc fix: This was reproduced on a fresh install of Pop!_OS
24.04 running kernel 6.18.7. I don't have a v7 kernel available at the
moment but will see if I can reproduce the issue there and report
back.
Happy to provide any additional debugging output in the meantime.
Best regards,
Danny Messina
On Wed, Jun 3, 2026 at 4:37 AM Chris Lu (陸稚泓) <Chris.Lu@mediatek.com> wrote:
>
> Add linux-bluetooth to maillist
>
> > From: Chris Lu (陸稚泓) <Chris.Lu@mediatek.com>
> > Sent: Wednesday, June 3, 2026 3:50 PM
> > To: messinadm@gmail.com
> > Cc: luiz.dentz@gmail.com; SS Wu (巫憲欣) <ss.wu@mediatek.com>;
> > marcel@holtmann.org; Peter Tsao (曹珆彰) <Peter.Tsao@mediatek.com>
> > Subject: Re: [PATCH] Bluetooth: btmtk: Fix MT7925 WMT command timeout
> > due to sleep protection
> >
> > Hi Danny,
> >
> > Thanks for your submission. I have some question about this patch.
> >
> > > -----Original Message-----
> > > From: Danny Messina <messinadm@gmail.com>
> > > Sent: Monday, June 1, 2026 2:07 AM
> > > To: linux-bluetooth@vger.kernel.org
> > > Cc: Peter Tsao (曹珆彰) <Peter.Tsao@mediatek.com>;
> > > marcel@holtmann.org;
> > > Luiz Augusto von Dentz <luiz.dentz@gmail.com>
> > > Subject: [PATCH] Bluetooth: btmtk: Fix MT7925 WMT command timeout
> > > due
> > > to sleep protection
> > >
> > >
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
> > >
> > > The MediaTek MT7925 USB Bluetooth device (0e8d:0717) fails to
> > > initialize
> > > with repeated "Execution of wmt command timed out" errors:
> > >
> > > Bluetooth: hci0: Execution of wmt command timed out
> > > Bluetooth: hci0: Failed to send wmt patch dwnld (-110)
> > > Bluetooth: hci0: Failed to set up firmware (-110)
> > >
> > > USB capture (usbmon) confirms WMT commands reach the device — the
> > > Control OUT transfer completes with status 0 — but the device
> > > never
> > > responds on any endpoint. The control IN polling URB returns zero
> > > bytes
> > > indefinitely until HCI_INIT_TIMEOUT expires.
> > >
> > > The root cause is the MT7925 BT core's sleep protection register
> > > (0x18011100, bit 1 = SLPPROT_BYPASS). When SLPPROT is active the
> > > BT
> > > processor ignores incoming WMT commands.
> > >
> > > Two additional issues compound this:
> > >
> > > 1. After repeated driver load/unload cycles without a hardware
> > > reset,
> > > the BT subsystem's WMT state machine becomes stuck. A
> > > subsystem
> > > reset via btmtk_usb_subsys_reset() restores it to a workable
> > > state.
> > >
> > > 2. After btmtk_setup_firmware_79xx() activates the downloaded
> > > firmware
> > > (which ends with a 100ms activation delay), the chip re-
> > > enables
> > > SLPPROT. The subsequent FUNC_CTRL WMT command therefore also
> > > times
> > > out unless SLPPROT is bypassed again.
> > >
> > > Fix this for dev_id 0x7925 in btmtk_usb_setup():
> > > 1. Call btmtk_usb_subsys_reset() to clear any stuck WMT state.
> > > 2. Set 0x18011100 |= BIT(1) before firmware download.
> > > 3. Set 0x18011100 |= BIT(1) again before FUNC_CTRL.
> > >
> >
> > Could you share how you identified which register/value need to be
> > modified on MT7925 with such situation and why performed reset at
> > this specific point helps avoid the setup issue?
> >
> > > Tested on a System76 Thelio desktop with MT7925 PCIe combo card,
> > > USB ID 0e8d:0717, kernel 6.18.7.
> > >
> > > Signed-off-by: Danny Messina <messinadm@gmail.com>
> > > ---
> > > drivers/bluetooth/btmtk.c | 33 +++++++++++++++++++++++++++++++++
> > > 1 file changed, 33 insertions(+)
> > >
> > > diff --git a/drivers/bluetooth/btmtk.c
> > > b/drivers/bluetooth/btmtk.c
> > > --- a/drivers/bluetooth/btmtk.c
> > > +++ b/drivers/bluetooth/btmtk.c
> > > @@ -1326,6 +1326,24 @@
> > > case 0x7922:
> > > case 0x7925:
> > > case 0x7961:
> > > + if (dev_id == 0x7925) {
> > > + u32 val = 0;
> > > +
> > > + /* Reset BT subsystem to clear any stuck
> > > WMT
> > > state */
> > > + err = btmtk_usb_subsys_reset(hdev, dev_id);
> > > + if (err < 0)
> > > + bt_dev_warn(hdev, "BT subsys reset
> > > failed (%d), continuing", err);
> > > +
> > > + /* Bypass sleep protection so WMT commands
> > > reach the BT core */
> > > + err = btmtk_usb_uhw_reg_read(hdev,
> > > 0x18011100,
> > > &val);
> > > + if (err < 0)
> > > + return err;
> > > + val |= BIT(1);
> > > + err = btmtk_usb_uhw_reg_write(hdev,
> > > 0x18011100, val);
> > > + if (err < 0)
> > > + return err;
> > > + }
> > > +
> > > btmtk_fw_get_filename(fw_bin_name,
> > > sizeof(fw_bin_name), dev_id,
> > > fw_version, fw_flavor);
> > >
> > > @@ -1342,6 +1360,19 @@
> > > if (err < 0)
> > > return err;
> > >
> > > + /* Re-bypass sleep protection after firmware
> > > activation for MT7925 */
> > > + if (dev_id == 0x7925) {
> > > + u32 val = 0;
> > > +
> > > + err = btmtk_usb_uhw_reg_read(hdev,
> > > 0x18011100,
> > > &val);
> > > + if (err < 0)
> > > + return err;
> > > + val |= BIT(1);
> > > + err = btmtk_usb_uhw_reg_write(hdev,
> > > 0x18011100, val);
> > > + if (err < 0)
> > > + return err;
> > > + }
> > > +
> > > /* Enable Bluetooth protocol */
> > > param = 1;
> > > wmt_params.op = BTMTK_WMT_FUNC_CTRL;
> >
> > I'd also like to share some relevant background on this change:
> >
> > MediaTek Bluetooth team previously implemented a similar reset before
> > firmware download to ensure the controller was always in an initial
> > state. However, it was later reported by kernel community that this
> > caused USB enumeration failures on other devices, so the change was
> > reverted (commit 33634e2ab "Bluetooth: btmtk: Remove the resetting
> > step before downloading the fw").
> >
> > In April this year, I submitted a fix addressing setup failures on
> > MediaTek Bluetooth devices, which has been included since kernel
> > v7.1- rc. Could you try reproducing the issue with a recent kernel to
> > see whether the problem still occurs?
> >
> > Looking forward to your feedback.
> >
> > Best regards,
> > Chris Lu
>
>
> *********** MEDIATEK Confidentiality Notice ***********
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or
> otherwise exempt from disclosure under applicable laws. It is
> intended to be conveyed only to the designated recipient(s). Any
> use, dissemination, distribution, printing, retaining or copying
> of this e-mail (including its attachments) by unintended recipient(s)
> is strictly prohibited and may be unlawful. If you are not an
> intended recipient of this e-mail, or believe that you have received
> this e-mail in error, please notify the sender immediately
> (by replying to this e-mail), delete any and all copies of this
> e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
^ permalink raw reply
* [PATCH] Bluetooth: L2CAP: Fix UAF in l2cap_chan_timeout
From: Marco Elver @ 2026-06-03 12:27 UTC (permalink / raw)
To: elver
Cc: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth,
linux-kernel, kasan-dev, stable, Siwei Zhang,
Luiz Augusto von Dentz
l2cap_chan_timeout() accesses chan->conn without holding a reference to
the connection object. If l2cap_conn_del() races and tears down the
connection while the timer is waiting for locks, it can result in a
use-after-free when the timer wakes up and attempts to acquire
conn->lock:
| BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 [inline]
| BUG: KASAN: slab-use-after-free in atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]
| BUG: KASAN: slab-use-after-free in __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]
| BUG: KASAN: slab-use-after-free in mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318
| Write of size 8 at addr ffff8881298d9550 by task kworker/2:1/83
|
| CPU: 2 UID: 0 PID: 83 Comm: kworker/2:1 Not tainted 7.1.0-rc6-next-20260601-dirty #6 PREEMPT(full)
| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
| Workqueue: events l2cap_chan_timeout
| Call Trace:
| <TASK>
| instrument_atomic_read_write include/linux/instrumented.h:112 [inline]
| atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]
| __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]
| mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318
| l2cap_chan_timeout+0x5d/0x1b0 net/bluetooth/l2cap_core.c:422
| process_one_work kernel/workqueue.c:3326 [inline]
| process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409
| worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490
| kthread+0x346/0x430 kernel/kthread.c:436
| ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158
| ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
| </TASK>
|
| Allocated by task 320:
| l2cap_conn_add+0xa7/0x820 net/bluetooth/l2cap_core.c:7075
| l2cap_connect_cfm+0xdb/0xd70 net/bluetooth/l2cap_core.c:7452
| hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline]
| hci_remote_features_evt+0x52f/0x9f0 net/bluetooth/hci_event.c:3760
| hci_event_func net/bluetooth/hci_event.c:7796 [inline]
| hci_event_packet+0x561/0xa70 net/bluetooth/hci_event.c:7847
| hci_rx_work+0x370/0x890 net/bluetooth/hci_core.c:4040
| process_one_work kernel/workqueue.c:3326 [inline]
| process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409
| worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490
| kthread+0x346/0x430 kernel/kthread.c:436
| ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158
| ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
|
| Freed by task 322:
| hci_disconn_cfm include/net/bluetooth/hci_core.h:2154 [inline]
| hci_conn_hash_flush+0x101/0x1f0 net/bluetooth/hci_conn.c:2736
| hci_dev_close_sync+0x889/0xde0 net/bluetooth/hci_sync.c:5405
| hci_dev_do_close net/bluetooth/hci_core.c:502 [inline]
| hci_unregister_dev+0x1f7/0x370 net/bluetooth/hci_core.c:2679
| vhci_release+0x12a/0x180 drivers/bluetooth/hci_vhci.c:690
| __fput+0x369/0x890 fs/file_table.c:510
| task_work_run+0x160/0x1d0 kernel/task_work.c:233
| get_signal+0xf5b/0x1120 kernel/signal.c:2810
| arch_do_signal_or_restart+0x4d/0x600 arch/x86/kernel/signal.c:337
| __exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
| exit_to_user_mode_loop+0x85/0x510 kernel/entry/common.c:98
| __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
| syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
| syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
| do_syscall_64+0x263/0x3d0 arch/x86/entry/syscall_64.c:100
| entry_SYSCALL_64_after_hwframe+0x77/0x7f
|
| Last potentially related work creation:
| hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline]
| hci_remote_features_evt+0x52f/0x9f0 net/bluetooth/hci_event.c:3760
| hci_event_func net/bluetooth/hci_event.c:7796 [inline]
| hci_event_packet+0x561/0xa70 net/bluetooth/hci_event.c:7847
| hci_rx_work+0x370/0x890 net/bluetooth/hci_core.c:4040
| process_one_work kernel/workqueue.c:3326 [inline]
| process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409
| worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490
| kthread+0x346/0x430 kernel/kthread.c:436
| ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158
| ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
|
| The buggy address belongs to the object at ffff8881298d9400
| which belongs to the cache kmalloc-512 of size 512
| The buggy address is located 336 bytes inside of
| freed 512-byte region [ffff8881298d9400, ffff8881298d9600)
Fix it by holding a reference to the connection when the channel timer
is scheduled, and releasing it when the timer is either canceled or
executes to completion.
Since l2cap_chan_del() nullifies chan->conn to disassociate the channel
during teardown, the timer handler might read NULL from chan->conn even
if it held a reference. To address this, introduce a `timer_conn` field
to `struct l2cap_chan` to store the connection pointer associated with
the active timer. The timer handler uses this field to acquire locks and
release the connection reference, and skips channel closing operations
if chan->conn has already been nullified by teardown.
Fixes: 75780ca4c6a8 ("Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()")
Cc: <stable@vger.kernel.org>
Cc: Siwei Zhang <oss@fourdim.xyz>
Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Assisted-by: Gemini:gemini-3.1-pro-preview
Reported-by: https://sashiko.dev/#/patchset/20260521021249.3258069-1-oss%40fourdim.xyz
Signed-off-by: Marco Elver <elver@google.com>
---
include/net/bluetooth/l2cap.h | 18 ++++++++++++++++--
net/bluetooth/l2cap_core.c | 26 +++++++++++++++-----------
2 files changed, 31 insertions(+), 13 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index e0a1f2293679..83719777512e 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -514,6 +514,7 @@ struct l2cap_seq_list {
struct l2cap_chan {
struct l2cap_conn *conn;
+ struct l2cap_conn *timer_conn; /* for chan_timer */
struct kref kref;
atomic_t nesting;
@@ -835,6 +836,9 @@ static inline void l2cap_chan_unlock(struct l2cap_chan *chan)
mutex_unlock(&chan->lock);
}
+struct l2cap_conn *l2cap_conn_get(struct l2cap_conn *conn);
+void l2cap_conn_put(struct l2cap_conn *conn);
+
static inline void l2cap_set_timer(struct l2cap_chan *chan,
struct delayed_work *work, long timeout)
{
@@ -843,8 +847,13 @@ static inline void l2cap_set_timer(struct l2cap_chan *chan,
/* If delayed work cancelled do not hold(chan)
since it is already done with previous set_timer */
- if (!cancel_delayed_work(work))
+ if (!cancel_delayed_work(work)) {
l2cap_chan_hold(chan);
+ if (work == &chan->chan_timer && chan->conn) {
+ l2cap_conn_get(chan->conn);
+ chan->timer_conn = chan->conn;
+ }
+ }
schedule_delayed_work(work, timeout);
}
@@ -857,8 +866,13 @@ static inline bool l2cap_clear_timer(struct l2cap_chan *chan,
/* put(chan) if delayed work cancelled otherwise it
is done in delayed work function */
ret = cancel_delayed_work(work);
- if (ret)
+ if (ret) {
+ if (work == &chan->chan_timer && chan->timer_conn) {
+ l2cap_conn_put(chan->timer_conn);
+ chan->timer_conn = NULL;
+ }
l2cap_chan_put(chan);
+ }
return ret;
}
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index c4ccfbda9d78..491b03bf6903 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -406,7 +406,7 @@ static void l2cap_chan_timeout(struct work_struct *work)
{
struct l2cap_chan *chan = container_of(work, struct l2cap_chan,
chan_timer.work);
- struct l2cap_conn *conn = chan->conn;
+ struct l2cap_conn *conn = chan->timer_conn;
int reason;
BT_DBG("chan %p state %s", chan, state_to_string(chan->state));
@@ -421,23 +421,27 @@ static void l2cap_chan_timeout(struct work_struct *work)
* this work. No need to call l2cap_chan_hold(chan) here again.
*/
l2cap_chan_lock(chan);
+ chan->timer_conn = NULL;
+
+ if (chan->conn) {
+ if (chan->state == BT_CONNECTED || chan->state == BT_CONFIG)
+ reason = ECONNREFUSED;
+ else if (chan->state == BT_CONNECT &&
+ chan->sec_level != BT_SECURITY_SDP)
+ reason = ECONNREFUSED;
+ else
+ reason = ETIMEDOUT;
- if (chan->state == BT_CONNECTED || chan->state == BT_CONFIG)
- reason = ECONNREFUSED;
- else if (chan->state == BT_CONNECT &&
- chan->sec_level != BT_SECURITY_SDP)
- reason = ECONNREFUSED;
- else
- reason = ETIMEDOUT;
-
- l2cap_chan_close(chan, reason);
+ l2cap_chan_close(chan, reason);
- chan->ops->close(chan);
+ chan->ops->close(chan);
+ }
l2cap_chan_unlock(chan);
l2cap_chan_put(chan);
mutex_unlock(&conn->lock);
+ l2cap_conn_put(conn);
}
struct l2cap_chan *l2cap_chan_create(void)
--
2.54.0.1013.g208068f2d8-goog
^ permalink raw reply related
* RE: [v4] Bluetooth: hci_core: Fix UAF in hci_unregister_dev()
From: bluez.test.bot @ 2026-06-03 12:39 UTC (permalink / raw)
To: linux-bluetooth, jaggyaur
In-Reply-To: <20260603085047.256779-1-jaggyaur@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2472 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=1105168
---Test result---
Test Summary:
CheckPatch PASS 0.72 seconds
VerifyFixes PASS 0.14 seconds
VerifySignedoff PASS 0.13 seconds
GitLint PASS 0.33 seconds
SubjectPrefix PASS 0.13 seconds
BuildKernel PASS 25.12 seconds
CheckAllWarning PASS 27.85 seconds
CheckSparse PASS 26.29 seconds
BuildKernel32 PASS 24.34 seconds
TestRunnerSetup PASS 519.77 seconds
TestRunner_l2cap-tester FAIL 58.96 seconds
TestRunner_iso-tester PASS 75.65 seconds
TestRunner_bnep-tester PASS 19.41 seconds
TestRunner_mgmt-tester FAIL 209.19 seconds
TestRunner_rfcomm-tester PASS 25.68 seconds
TestRunner_sco-tester PASS 32.57 seconds
TestRunner_ioctl-tester PASS 26.29 seconds
TestRunner_mesh-tester FAIL 25.39 seconds
TestRunner_smp-tester PASS 23.55 seconds
TestRunner_userchan-tester PASS 19.76 seconds
TestRunner_6lowpan-tester PASS 22.67 seconds
IncrementalBuild PASS 24.73 seconds
Details
##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:
Total: 96, Passed: 95 (99.0%), Failed: 1, Not Run: 0
Failed Test Cases
L2CAP BR/EDR Server - Set PHY 3M Failed 0.251 seconds
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4
Failed Test Cases
Read Exp Feature - Success Failed 0.241 seconds
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0
Failed Test Cases
Mesh - Send cancel - 1 Timed out 2.048 seconds
Mesh - Send cancel - 2 Timed out 1.988 seconds
https://github.com/bluez/bluetooth-next/pull/280
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH] Bluetooth: L2CAP: Fix UAF in l2cap_chan_timeout
From: Marco Elver @ 2026-06-03 13:15 UTC (permalink / raw)
To: elver
Cc: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth,
linux-kernel, kasan-dev, stable, Siwei Zhang,
Luiz Augusto von Dentz
In-Reply-To: <20260603123111.2334409-1-elver@google.com>
On Wed, 3 Jun 2026 at 14:31, Marco Elver <elver@google.com> wrote:
>
> l2cap_chan_timeout() accesses chan->conn without holding a reference to
> the connection object. If l2cap_conn_del() races and tears down the
> connection while the timer is waiting for locks, it can result in a
> use-after-free when the timer wakes up and attempts to acquire
> conn->lock:
>
> | BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 [inline]
> | BUG: KASAN: slab-use-after-free in atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]
> | BUG: KASAN: slab-use-after-free in __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]
> | BUG: KASAN: slab-use-after-free in mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318
> | Write of size 8 at addr ffff8881298d9550 by task kworker/2:1/83
> |
> | CPU: 2 UID: 0 PID: 83 Comm: kworker/2:1 Not tainted 7.1.0-rc6-next-20260601-dirty #6 PREEMPT(full)
> | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
> | Workqueue: events l2cap_chan_timeout
> | Call Trace:
> | <TASK>
> | instrument_atomic_read_write include/linux/instrumented.h:112 [inline]
> | atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]
> | __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]
> | mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318
> | l2cap_chan_timeout+0x5d/0x1b0 net/bluetooth/l2cap_core.c:422
> | process_one_work kernel/workqueue.c:3326 [inline]
> | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409
> | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490
> | kthread+0x346/0x430 kernel/kthread.c:436
> | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158
> | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> | </TASK>
> |
> | Allocated by task 320:
> | l2cap_conn_add+0xa7/0x820 net/bluetooth/l2cap_core.c:7075
> | l2cap_connect_cfm+0xdb/0xd70 net/bluetooth/l2cap_core.c:7452
> | hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline]
> | hci_remote_features_evt+0x52f/0x9f0 net/bluetooth/hci_event.c:3760
> | hci_event_func net/bluetooth/hci_event.c:7796 [inline]
> | hci_event_packet+0x561/0xa70 net/bluetooth/hci_event.c:7847
> | hci_rx_work+0x370/0x890 net/bluetooth/hci_core.c:4040
> | process_one_work kernel/workqueue.c:3326 [inline]
> | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409
> | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490
> | kthread+0x346/0x430 kernel/kthread.c:436
> | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158
> | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> |
> | Freed by task 322:
> | hci_disconn_cfm include/net/bluetooth/hci_core.h:2154 [inline]
> | hci_conn_hash_flush+0x101/0x1f0 net/bluetooth/hci_conn.c:2736
> | hci_dev_close_sync+0x889/0xde0 net/bluetooth/hci_sync.c:5405
> | hci_dev_do_close net/bluetooth/hci_core.c:502 [inline]
> | hci_unregister_dev+0x1f7/0x370 net/bluetooth/hci_core.c:2679
> | vhci_release+0x12a/0x180 drivers/bluetooth/hci_vhci.c:690
> | __fput+0x369/0x890 fs/file_table.c:510
> | task_work_run+0x160/0x1d0 kernel/task_work.c:233
> | get_signal+0xf5b/0x1120 kernel/signal.c:2810
> | arch_do_signal_or_restart+0x4d/0x600 arch/x86/kernel/signal.c:337
> | __exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
> | exit_to_user_mode_loop+0x85/0x510 kernel/entry/common.c:98
> | __exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
> | syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
> | syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
> | do_syscall_64+0x263/0x3d0 arch/x86/entry/syscall_64.c:100
> | entry_SYSCALL_64_after_hwframe+0x77/0x7f
> |
> | Last potentially related work creation:
> | hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline]
> | hci_remote_features_evt+0x52f/0x9f0 net/bluetooth/hci_event.c:3760
> | hci_event_func net/bluetooth/hci_event.c:7796 [inline]
> | hci_event_packet+0x561/0xa70 net/bluetooth/hci_event.c:7847
> | hci_rx_work+0x370/0x890 net/bluetooth/hci_core.c:4040
> | process_one_work kernel/workqueue.c:3326 [inline]
> | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409
> | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490
> | kthread+0x346/0x430 kernel/kthread.c:436
> | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158
> | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> |
> | The buggy address belongs to the object at ffff8881298d9400
> | which belongs to the cache kmalloc-512 of size 512
> | The buggy address is located 336 bytes inside of
> | freed 512-byte region [ffff8881298d9400, ffff8881298d9600)
>
> Fix it by holding a reference to the connection when the channel timer
> is scheduled, and releasing it when the timer is either canceled or
> executes to completion.
>
> Since l2cap_chan_del() nullifies chan->conn to disassociate the channel
> during teardown, the timer handler might read NULL from chan->conn even
> if it held a reference. To address this, introduce a `timer_conn` field
> to `struct l2cap_chan` to store the connection pointer associated with
> the active timer. The timer handler uses this field to acquire locks and
> release the connection reference, and skips channel closing operations
> if chan->conn has already been nullified by teardown.
>
> Fixes: 75780ca4c6a8 ("Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()")
> Cc: <stable@vger.kernel.org>
> Cc: Siwei Zhang <oss@fourdim.xyz>
> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> Assisted-by: Gemini:gemini-3.1-pro-preview
> Reported-by: https://sashiko.dev/#/patchset/20260521021249.3258069-1-oss%40fourdim.xyz
> Signed-off-by: Marco Elver <elver@google.com>
Sigh, Sashiko points out more problems here:
https://sashiko.dev/#/patchset/20260603123111.2334409-1-elver%40google.com
> Can this lockless read of chan->timer_conn cause a use-after-free or double
> free if another thread re-arms the timer concurrently?
I haven't analyzed this further yet, so consider this patch a
bug-report-only. If anyone finds a better fix sooner, please go ahead.
> ---
> include/net/bluetooth/l2cap.h | 18 ++++++++++++++++--
> net/bluetooth/l2cap_core.c | 26 +++++++++++++++-----------
> 2 files changed, 31 insertions(+), 13 deletions(-)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index e0a1f2293679..83719777512e 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -514,6 +514,7 @@ struct l2cap_seq_list {
>
> struct l2cap_chan {
> struct l2cap_conn *conn;
> + struct l2cap_conn *timer_conn; /* for chan_timer */
> struct kref kref;
> atomic_t nesting;
>
> @@ -835,6 +836,9 @@ static inline void l2cap_chan_unlock(struct l2cap_chan *chan)
> mutex_unlock(&chan->lock);
> }
>
> +struct l2cap_conn *l2cap_conn_get(struct l2cap_conn *conn);
> +void l2cap_conn_put(struct l2cap_conn *conn);
> +
> static inline void l2cap_set_timer(struct l2cap_chan *chan,
> struct delayed_work *work, long timeout)
> {
> @@ -843,8 +847,13 @@ static inline void l2cap_set_timer(struct l2cap_chan *chan,
>
> /* If delayed work cancelled do not hold(chan)
> since it is already done with previous set_timer */
> - if (!cancel_delayed_work(work))
> + if (!cancel_delayed_work(work)) {
> l2cap_chan_hold(chan);
> + if (work == &chan->chan_timer && chan->conn) {
> + l2cap_conn_get(chan->conn);
> + chan->timer_conn = chan->conn;
> + }
> + }
>
> schedule_delayed_work(work, timeout);
> }
> @@ -857,8 +866,13 @@ static inline bool l2cap_clear_timer(struct l2cap_chan *chan,
> /* put(chan) if delayed work cancelled otherwise it
> is done in delayed work function */
> ret = cancel_delayed_work(work);
> - if (ret)
> + if (ret) {
> + if (work == &chan->chan_timer && chan->timer_conn) {
> + l2cap_conn_put(chan->timer_conn);
> + chan->timer_conn = NULL;
> + }
> l2cap_chan_put(chan);
> + }
>
> return ret;
> }
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index c4ccfbda9d78..491b03bf6903 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -406,7 +406,7 @@ static void l2cap_chan_timeout(struct work_struct *work)
> {
> struct l2cap_chan *chan = container_of(work, struct l2cap_chan,
> chan_timer.work);
> - struct l2cap_conn *conn = chan->conn;
> + struct l2cap_conn *conn = chan->timer_conn;
> int reason;
>
> BT_DBG("chan %p state %s", chan, state_to_string(chan->state));
> @@ -421,23 +421,27 @@ static void l2cap_chan_timeout(struct work_struct *work)
> * this work. No need to call l2cap_chan_hold(chan) here again.
> */
> l2cap_chan_lock(chan);
> + chan->timer_conn = NULL;
> +
> + if (chan->conn) {
> + if (chan->state == BT_CONNECTED || chan->state == BT_CONFIG)
> + reason = ECONNREFUSED;
> + else if (chan->state == BT_CONNECT &&
> + chan->sec_level != BT_SECURITY_SDP)
> + reason = ECONNREFUSED;
> + else
> + reason = ETIMEDOUT;
>
> - if (chan->state == BT_CONNECTED || chan->state == BT_CONFIG)
> - reason = ECONNREFUSED;
> - else if (chan->state == BT_CONNECT &&
> - chan->sec_level != BT_SECURITY_SDP)
> - reason = ECONNREFUSED;
> - else
> - reason = ETIMEDOUT;
> -
> - l2cap_chan_close(chan, reason);
> + l2cap_chan_close(chan, reason);
>
> - chan->ops->close(chan);
> + chan->ops->close(chan);
> + }
>
> l2cap_chan_unlock(chan);
> l2cap_chan_put(chan);
>
> mutex_unlock(&conn->lock);
> + l2cap_conn_put(conn);
> }
>
> struct l2cap_chan *l2cap_chan_create(void)
> --
> 2.54.0.1013.g208068f2d8-goog
>
^ permalink raw reply
* Re: [PATCH v2] profile: Set L2CAP IMTU for external profile listeners
From: Wei Deng @ 2026-06-03 13:31 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: linux-bluetooth, luiz.von.dentz, cheng.jiang, jinwang.li,
shuai.zhang
In-Reply-To: <CABBYNZKZhamDmBjpKW3GjtF3jrNfLXUTzYaNyz1vbdrgM_Lu4A@mail.gmail.com>
Hi Luiz,
On Tue, Jun 2, 2026 at 10:42 AM Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:
>
> Actually there are no options, it's built from `default_setting`,
> which doesn't set any MTU for some reason. For the OBEX profiles it
> probably makes sense to add an MTU field so it gets properly set.
Thanks for the clarification. Agreed -- I'll add an imtu field to
default_settings and populate it only for the OBEX profiles (OPP, FTP,
PSE, MAS, MNS), then have ext_start_servers() apply it via bt_io_set()
only when the field is set, so non-OBEX listeners keep their current
behavior.
I'll send V3 with that approach shortly.
--
Best Regards,
Wei Deng
^ permalink raw reply
* RE: [PATCH v1] Bluetooth: btintel_pcie: Add support for smart trigger dump
From: K, Kiran @ 2026-06-03 13:33 UTC (permalink / raw)
To: Paul Menzel
Cc: linux-bluetooth@vger.kernel.org, Srivatsa, Ravishankar,
Devegowda, Chandrashekar, Tumkur Narayan, Chethan
In-Reply-To: <1854c81e-ae4e-434c-a034-0b9fce554b66@molgen.mpg.de>
Hi Paul,
Thanks for the comments.
>-----Original Message-----
>From: Paul Menzel <pmenzel@molgen.mpg.de>
>Sent: Thursday, October 16, 2025 12:06 PM
>To: K, Kiran <kiran.k@intel.com>; Vijay Satija <vijay.satija@intel.com>
>Cc: linux-bluetooth@vger.kernel.org; Srivatsa, Ravishankar
><ravishankar.srivatsa@intel.com>; Devegowda, Chandrashekar
><chandrashekar.devegowda@intel.com>; Tumkur Narayan, Chethan
><chethan.tumkur.narayan@intel.com>
>Subject: Re: [PATCH v1] Bluetooth: btintel_pcie: Add support for smart trigger
>dump
>
>Dear Kiran, dear Vijay,
>
>
>Thank you for the patch.
>
>Am 16.10.25 um 07:57 schrieb Kiran K:
>> Based on the debug configuration, firmware can raise MSIX interrupt
>> with
>
>MSI-X
>
>> firmware trigger cause bit set on specific events like Disconnection,
>> Connection Timeout, Page Timeout etc.
>>
>> Upon receiving an MSIX interrupt with the firmware trigger cause bit
>
>MSI-X
>
>> set, the driver performs the following actions:
>>
>> 1. Reads Device Memory: Retrieves data from the device memory,
>> constructs an HCI vendor event, and sends it to the monitor. This
>> event includes details about the trigger, such as connection timeout or
>> page timeout.
>>
>> 2. Dumps Device Coredump: Generates a coredump containing firmware
>> traces for further analysis.
>
>Please give an example how to retrieve the coredump.
I will update the commit message in v2.
>
>Maybe also paste the new debug logs.
I will include the HCI traces.
>
>> Signed-off-by: Vijay Satija <vijay.satija@intel.com>
>> Signed-off-by: Kiran K <kiran.k@intel.com>
>> ---
>> drivers/bluetooth/btintel.h | 1 +
>> drivers/bluetooth/btintel_pcie.c | 154
>+++++++++++++++++++++++++++++++
>> drivers/bluetooth/btintel_pcie.h | 9 +-
>> 3 files changed, 163 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/bluetooth/btintel.h b/drivers/bluetooth/btintel.h
>> index 431998049e68..bb2bf0b17336 100644
>> --- a/drivers/bluetooth/btintel.h
>> +++ b/drivers/bluetooth/btintel.h
>> @@ -53,6 +53,7 @@ struct intel_tlv {
>> } __packed;
>>
>> #define BTINTEL_HCI_OP_RESET 0xfc01
>> +#define BTINTEL_HCI_OP_DEBUG 0xfcd9
>>
>> #define BTINTEL_CNVI_BLAZARI 0x900
>> #define BTINTEL_CNVI_BLAZARIW 0x901
>> diff --git a/drivers/bluetooth/btintel_pcie.c
>> b/drivers/bluetooth/btintel_pcie.c
>> index 6d3963bd56a9..438c67f317b5 100644
>> --- a/drivers/bluetooth/btintel_pcie.c
>> +++ b/drivers/bluetooth/btintel_pcie.c
>> @@ -121,6 +121,21 @@ struct btintel_pcie_removal {
>> struct work_struct work;
>> };
>>
>> +struct btintel_pcie_trigger_evt {
>> + u8 type;
>> + u8 len;
>> + __le32 addr;
>> + __le32 size;
>> +} __packed;
>> +
>> +struct btintel_pcie_fwtrigger_evt {
>> + __le32 reserved;
>> + u8 type; /* Debug Trigger event */
>> + __le16 len;
>> + u8 event_type;
>> + __le16 event_id;
>> +} __packed;
>> +
>> static LIST_HEAD(btintel_pcie_recovery_list);
>> static DEFINE_SPINLOCK(btintel_pcie_recovery_lock);
>>
>> @@ -677,6 +692,11 @@ static int btintel_pcie_read_dram_buffers(struct
>btintel_pcie_data *data)
>> sizeof(*tlv) + strlen(vendor) +
>> sizeof(*tlv) + strlen(driver);
>>
>> + if (data->dmp_hdr.trigger_reason ==
>BTINTEL_PCIE_TRIGGER_REASON_FW_ASSERT) {
>> + data_len += sizeof(*tlv) + sizeof(data->dmp_hdr.event_type);
>> + data_len += sizeof(*tlv) + sizeof(data->dmp_hdr.event_id);
>> + }
>> +
>> /*
>> * sizeof(u32) - signature
>> * sizeof(data_len) - to store tlv data size @@ -724,6 +744,15 @@
>> static int btintel_pcie_read_dram_buffers(struct btintel_pcie_data *data)
>> p = btintel_pcie_copy_tlv(p, BTINTEL_CNVI_TOP, &data-
>>dmp_hdr.cnvi_top,
>> sizeof(data->dmp_hdr.cnvi_top));
>>
>> + if (data->dmp_hdr.trigger_reason ==
>BTINTEL_PCIE_TRIGGER_REASON_FW_ASSERT) {
>> + p = btintel_pcie_copy_tlv(p, BTINTEL_EVENT_TYPE,
>> + &data->dmp_hdr.event_type,
>> + sizeof(data->dmp_hdr.event_type));
>> + p = btintel_pcie_copy_tlv(p, BTINTEL_EVENT_ID,
>> + &data->dmp_hdr.event_id,
>> + sizeof(data->dmp_hdr.event_id));
>> + }
>> +
>> memcpy(p, dbgc->bufs[0].data, dbgc->count *
>BTINTEL_PCIE_DBGC_BUFFER_SIZE);
>> dev_coredumpv(&hdev->dev, pdata, dump_size, GFP_KERNEL);
>> return 0;
>> @@ -1298,6 +1327,75 @@ static void btintel_pcie_read_hwexp(struct
>btintel_pcie_data *data)
>> kfree(buf);
>> }
>>
>> +static int btintel_pcie_dump_fwtrigger_event(struct btintel_pcie_data
>> +*data) {
>> + struct btintel_pcie_fwtrigger_evt *evt;
>> + struct hci_event_hdr *hdr;
>> + struct sk_buff *skb;
>> + int len, err;
>
>Make `len` `unsigned int`?
Ack.
>
>> + u32 val;
>> + u8 *buf;
>> +
>> + if (!data->debug_evt_size || !data->debug_evt_addr)
>> + return -EINVAL;
>> +
>> + len = data->debug_evt_size;
>> +
>> + buf = kzalloc(len, GFP_KERNEL);
>> + if (!buf)
>> + return -ENOMEM;
>> +
>> + btintel_pcie_mac_init(data);
>> +
>> + err = btintel_pcie_read_device_mem(data, buf, data->debug_evt_addr,
>> + data->debug_evt_size);
>> + if (err)
>> + goto exit_on_error;
>> +
>> + evt = (void *)buf;
>> + data->dmp_hdr.event_type = evt->event_type;
>> + data->dmp_hdr.event_id = le16_to_cpu(evt->event_id);
>
>Please just use one space before the = above.
>
Ack.
>
>Kind regards,
>
>Paul
>
>
>> +
>> + bt_dev_dbg(data->hdev, "event type: 0x%2.2x event id: 0x%4.4x",
>> + data->dmp_hdr.event_type, data->dmp_hdr.event_id);
>> +
>> + skb = bt_skb_alloc(sizeof(*hdr) + len, GFP_KERNEL);
>> + if (!skb) {
>> + err = -ENOMEM;
>> + goto exit_on_error;
>> + }
>> + hci_skb_pkt_type(skb) = HCI_EVENT_PKT;
>> + hdr = skb_put(skb, sizeof(*hdr));
>> + hdr->evt = 0xff;
>> + hdr->plen = len;
>> + skb_put_data(skb, buf, len);
>> +
>> + /* copy Intel specific pcie packet type */
>> + val = BTINTEL_PCIE_HCI_EVT_PKT;
>> + memcpy(skb_push(skb, BTINTEL_PCIE_HCI_TYPE_LEN), &val,
>> + BTINTEL_PCIE_HCI_TYPE_LEN);
>> +
>> + btintel_pcie_recv_frame(data, skb);
>> +
>> +exit_on_error:
>> + kfree(buf);
>> + return err;
>> +}
>> +
>> +static void btintel_pcie_msix_fw_trigger_handler(struct
>> +btintel_pcie_data *data) {
>> + bt_dev_dbg(data->hdev, "Received firmware smart trigger cause");
>> +
>> + if (test_and_set_bit(BTINTEL_PCIE_FWTRIGGER_DUMP_INPROGRESS,
>&data->flags))
>> + return;
>> +
>> + /* Trigger device core dump when there is FW assert */
>> + if (!test_and_set_bit(BTINTEL_PCIE_COREDUMP_INPROGRESS, &data-
>>flags))
>> + data->dmp_hdr.trigger_reason =
>> +BTINTEL_PCIE_TRIGGER_REASON_FW_ASSERT;
>> +
>> + queue_work(data->workqueue, &data->rx_work); }
>> +
>> static void btintel_pcie_msix_hw_exp_handler(struct btintel_pcie_data *data)
>> {
>> bt_dev_err(data->hdev, "Received hw exception interrupt"); @@
>> -1321,6 +1419,11 @@ static void btintel_pcie_rx_work(struct work_struct
>*work)
>> struct btintel_pcie_data, rx_work);
>> struct sk_buff *skb;
>>
>> + if (test_bit(BTINTEL_PCIE_FWTRIGGER_DUMP_INPROGRESS, &data-
>>flags)) {
>> + btintel_pcie_dump_fwtrigger_event(data);
>> + clear_bit(BTINTEL_PCIE_FWTRIGGER_DUMP_INPROGRESS,
>&data->flags);
>> + }
>> +
>> if (test_bit(BTINTEL_PCIE_COREDUMP_INPROGRESS, &data->flags)) {
>> btintel_pcie_dump_traces(data->hdev);
>> clear_bit(BTINTEL_PCIE_COREDUMP_INPROGRESS, &data-
>>flags); @@
>> -1467,6 +1570,9 @@ static irqreturn_t btintel_pcie_irq_msix_handler(int irq,
>void *dev_id)
>> if (intr_hw & BTINTEL_PCIE_MSIX_HW_INT_CAUSES_GP1)
>> btintel_pcie_msix_gp1_handler(data);
>>
>> + if (intr_hw & BTINTEL_PCIE_MSIX_HW_INT_CAUSES_FWTRIG)
>> + btintel_pcie_msix_fw_trigger_handler(data);
>> +
>> /* This interrupt is triggered by the firmware after updating
>> * boot_stage register and image_response register
>> */
>> @@ -1555,6 +1661,7 @@ static struct btintel_pcie_causes_list causes_list[] = {
>> { BTINTEL_PCIE_MSIX_FH_INT_CAUSES_1,
> BTINTEL_PCIE_CSR_MSIX_FH_INT_MASK, 0x01 },
>> { BTINTEL_PCIE_MSIX_HW_INT_CAUSES_GP0,
> BTINTEL_PCIE_CSR_MSIX_HW_INT_MASK, 0x20 },
>> { BTINTEL_PCIE_MSIX_HW_INT_CAUSES_HWEXP,
>BTINTEL_PCIE_CSR_MSIX_HW_INT_MASK, 0x23 },
>> + { BTINTEL_PCIE_MSIX_HW_INT_CAUSES_FWTRIG,
>BTINTEL_PCIE_CSR_MSIX_HW_INT_MASK, 0x25 },
>> };
>>
>> /* This function configures the interrupt masks for both
>> HW_INT_CAUSES and @@ -2031,6 +2138,49 @@ static void
>btintel_pcie_synchronize_irqs(struct btintel_pcie_data *data)
>> synchronize_irq(data->msix_entries[i].vector);
>> }
>>
>> +static int btintel_pcie_get_debug_info_addr(struct hci_dev *hdev) {
>> + struct btintel_pcie_data *data = hci_get_drvdata(hdev);
>> + struct btintel_pcie_trigger_evt *evt;
>> + u8 param[1] = {0x10};
>> + struct sk_buff *skb;
>> + int err = 0;
>> +
>> + skb = __hci_cmd_sync(hdev, BTINTEL_HCI_OP_DEBUG, 1, param,
>> + HCI_CMD_TIMEOUT);
>> + if (IS_ERR(skb)) {
>> + bt_dev_err(hdev, "Reading Intel read debug info address
>command failed (%ld)",
>> + PTR_ERR(skb));
>> + /* Not all Intel products supports this command */
>> + if (PTR_ERR(skb) == -EOPNOTSUPP)
>> + return 0;
>> + return PTR_ERR(skb);
>> + }
>> +
>> + /* Check the status */
>> + if (skb->data[0]) {
>> + bt_dev_err(hdev, "Reading Intel read debug info command failed
>(0x%2.2x)",
>> + skb->data[0]);
>> + err = -EIO;
>> + goto exit_error;
>> + }
>> +
>> + /* Consume Command Complete Status field */
>> + skb_pull(skb, 1);
>> +
>> + evt = (void *)skb->data;
>> +
>> + data->debug_evt_addr = le32_to_cpu(evt->addr);
>> + data->debug_evt_size = le32_to_cpu(evt->size);
>> +
>> + bt_dev_dbg(hdev, "config type: %u config len: %u debug event addr:
>0x%8.8x size: 0x%8.8x",
>> + evt->type, evt->len, data->debug_evt_addr,
>> + data->debug_evt_size);
>> +exit_error:
>> + kfree_skb(skb);
>> + return err;
>> +}
>> +
>> static int btintel_pcie_setup_internal(struct hci_dev *hdev)
>> {
>> struct btintel_pcie_data *data = hci_get_drvdata(hdev); @@ -2128,6
>> +2278,10 @@ static int btintel_pcie_setup_internal(struct hci_dev *hdev)
>> if (ver_tlv.img_type == 0x02 || ver_tlv.img_type == 0x03)
>> data->dmp_hdr.fw_git_sha1 = ver_tlv.git_sha1;
>>
>> + err = btintel_pcie_get_debug_info_addr(hdev);
>> + if (err)
>> + goto exit_error;
>> +
>> btintel_print_fseq_info(hdev);
>> exit_error:
>> kfree_skb(skb);
>> diff --git a/drivers/bluetooth/btintel_pcie.h
>> b/drivers/bluetooth/btintel_pcie.h
>> index 04b21f968ad3..ef9983891f4b 100644
>> --- a/drivers/bluetooth/btintel_pcie.h
>> +++ b/drivers/bluetooth/btintel_pcie.h
>> @@ -101,6 +101,7 @@ enum msix_hw_int_causes {
>> BTINTEL_PCIE_MSIX_HW_INT_CAUSES_GP0 = BIT(0), /*
>cause 32 */
>> BTINTEL_PCIE_MSIX_HW_INT_CAUSES_GP1 = BIT(1), /*
>cause 33 */
>> BTINTEL_PCIE_MSIX_HW_INT_CAUSES_HWEXP = BIT(3), /*
>cause 35 */
>> + BTINTEL_PCIE_MSIX_HW_INT_CAUSES_FWTRIG = BIT(5), /*
>cause 37 */
>> };
>>
>> /* PCIe device states
>> @@ -118,6 +119,7 @@ enum {
>> BTINTEL_PCIE_CORE_HALTED,
>> BTINTEL_PCIE_HWEXP_INPROGRESS,
>> BTINTEL_PCIE_COREDUMP_INPROGRESS,
>> + BTINTEL_PCIE_FWTRIGGER_DUMP_INPROGRESS,
>> BTINTEL_PCIE_RECOVERY_IN_PROGRESS,
>> BTINTEL_PCIE_SETUP_DONE
>> };
>> @@ -133,7 +135,9 @@ enum btintel_pcie_tlv_type {
>> BTINTEL_DUMP_TIME,
>> BTINTEL_FW_BUILD,
>> BTINTEL_VENDOR,
>> - BTINTEL_DRIVER
>> + BTINTEL_DRIVER,
>> + BTINTEL_EVENT_TYPE,
>> + BTINTEL_EVENT_ID
>> };
>>
>> /* causes for the MBOX interrupts */ @@ -429,6 +433,8 @@ struct
>> btintel_pcie_dump_header {
>> u32 wrap_ctr;
>> u16 trigger_reason;
>> int state;
>> + u8 event_type;
>> + u16 event_id;
>> };
>>
>> /* struct btintel_pcie_data
>> @@ -513,6 +519,7 @@ struct btintel_pcie_data {
>> u32 alive_intr_ctxt;
>> struct btintel_pcie_dbgc dbgc;
>> struct btintel_pcie_dump_header dmp_hdr;
>> + u32 debug_evt_addr, debug_evt_size;
>> };
>>
>> static inline u32 btintel_pcie_rd_reg32(struct btintel_pcie_data
>> *data,
Thanks,
Kiran
^ permalink raw reply
* [PATCH v3 RESEND 5/5] Bluetooth: btusb: clean up probe error handling
From: Johan Hovold @ 2026-06-03 14:36 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Marcel Holtmann
Cc: linux-bluetooth, linux-kernel, Johan Hovold
In-Reply-To: <20260603143643.2514595-1-johan@kernel.org>
Clean up probe error handling by using dedicated error labels with an
"err" prefix.
Note that the endpoint lookup helper returns -ENXIO when endpoints are
missing which is functionally equivalent to returning -ENODEV.
Signed-off-by: Johan Hovold <johan@kernel.org>
---
drivers/bluetooth/btusb.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 450c8746bea6..83fbb5d2bf4a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -4090,10 +4090,8 @@ static int btusb_probe(struct usb_interface *intf,
err = usb_find_common_endpoints(intf->cur_altsetting, &data->bulk_rx_ep,
&data->bulk_tx_ep, &data->intr_ep, NULL);
- if (err) {
- kfree(data);
- return -ENODEV;
- }
+ if (err)
+ goto err_free_data;
if (id->driver_info & BTUSB_AMP) {
data->cmdreq_type = USB_TYPE_CLASS | 0x01;
@@ -4149,8 +4147,8 @@ static int btusb_probe(struct usb_interface *intf,
hdev = hci_alloc_dev_priv(priv_size);
if (!hdev) {
- kfree(data);
- return -ENOMEM;
+ err = -ENOMEM;
+ goto err_free_data;
}
hdev->bus = HCI_USB;
@@ -4164,7 +4162,7 @@ static int btusb_probe(struct usb_interface *intf,
GPIOD_OUT_LOW);
if (IS_ERR(reset_gpio)) {
err = PTR_ERR(reset_gpio);
- goto out_free_dev;
+ goto err_free_hdev;
} else if (reset_gpio) {
data->reset_gpio = reset_gpio;
}
@@ -4180,7 +4178,7 @@ static int btusb_probe(struct usb_interface *intf,
#ifdef CONFIG_PM
err = btusb_config_oob_wake(hdev);
if (err)
- goto out_free_dev;
+ goto err_put_reset;
/* Marvell devices may need a specific chip configuration */
if (id->driver_info & BTUSB_MARVELL && data->oob_wake_irq) {
@@ -4437,11 +4435,14 @@ static int btusb_probe(struct usb_interface *intf,
device_init_wakeup(&data->udev->dev, false);
free_irq(data->oob_wake_irq, data);
}
-out_free_dev:
+err_put_reset:
if (data->reset_gpio)
gpiod_put(data->reset_gpio);
+err_free_hdev:
hci_free_dev(hdev);
+err_free_data:
kfree(data);
+
return err;
}
--
2.53.0
^ permalink raw reply related
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