kernel/linux.git/drivers/bluetooth/btmtk.c, branch v7.2-rc5

Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path

2026-06-11T18:24:40+00:00

When btmtk_isopkt_pad() fails, the previously allocated URB is not freed, leaking the urb structure. Add usb_free_urb() before returning the error. Fixes: ceac1cb0259d ("Bluetooth: btusb: mediatek: add ISO data transmission functions") Signed-off-by: Zhao Dongdong Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

2026-06-11T18:24:39+00:00

These NICs are often reported to lose their Bluetooth interfaces, i.e, their USB interfaces suddenly become completely unresponsive, causing the USB core to reset them, only to find that they are no longer accessible. A power cycle is required to make the Bluetooth interfaces recover. After some investigations, I found that their USB autosuspend remote wakeup capabilities are so broken that they are precisely the culprit behind the issue: [27452.608056] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020 [27452.702018] usb 3-5: usb wakeup-resume [27452.716038] usb 3-5: Waited 0ms for CONNECT [27452.716642] usb 3-5: finish resume /* usbmon showed that the device was completely unresponsive to any URBs after the remote wakeup */ [27457.836030] usb 3-5: retry with reset-resume [27457.956046] usb 3-5: reset high-speed USB device number 4 using xhci_hcd [27463.332047] usb 3-5: device descriptor read/64, error -110 [27478.948117] usb 3-5: device descriptor read/64, error -110 [27479.172430] usb 3-5: reset high-speed USB device number 4 using xhci_hcd [27484.332035] usb 3-5: device descriptor read/64, error -110 [27499.940039] usb 3-5: device descriptor read/64, error -110 [27500.164060] usb 3-5: reset high-speed USB device number 4 using xhci_hcd [27505.196142] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27510.576045] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27510.784038] usb 3-5: device not accepting address 4, error -62 [27510.912215] usb 3-5: reset high-speed USB device number 4 using xhci_hcd [27515.948307] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27521.324380] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27521.525107] usb 3-5: device not accepting address 4, error -62 [27521.525928] usb usb3-port5: logical disconnect [27521.525996] usb 3-5: gone after usb resume? status -19 [27521.526230] usb 3-5: can't resume, status -19 [27521.526434] usb usb3-port5: logical disconnect [27521.526469] usb usb3-port5: resume, status -19 [27521.526493] usb usb3-port5: status 0503, change 0004, 480 Mb/s [27521.526528] usb 3-5: USB disconnect, device number 4 [27521.526736] usb 3-5: unregistering device [27521.804029] usb 3-5: new high-speed USB device number 5 using xhci_hcd [27527.076067] usb 3-5: device descriptor read/64, error -110 [27542.692027] usb 3-5: device descriptor read/64, error -110 [27542.916047] usb 3-5: new high-speed USB device number 6 using xhci_hcd [27548.068043] usb 3-5: device descriptor read/64, error -110 [27563.684073] usb 3-5: device descriptor read/64, error -110 [27563.792133] usb usb3-port5: attempt power cycle [27563.924381] hub 3-0:1.0: port_wait_reset: err = -11 [27563.925213] usb usb3-port5: not enabled, trying reset again... [27564.184398] usb 3-5: new high-speed USB device number 7 using xhci_hcd [27569.196322] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27574.572040] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27574.776053] usb 3-5: device not accepting address 7, error -62 [27574.900165] usb 3-5: new high-speed USB device number 8 using xhci_hcd [27579.948039] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27585.324331] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command [27585.528040] usb 3-5: device not accepting address 8, error -62 [27585.528389] usb usb3-port5: unable to enumerate USB device [27585.528424] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020 To reproduce the issue, these conditions must be met: - a noisy radio environment (cafe or office) to cause frequent remote wakeup events - no Bluetooth device is connected, so autosuspend is not prohibited - the Bluetooth interface is opened, so remote wakeup is enabled when the device runs into autosuspend Then I can reproduce the issue within sereval hours each time. Increasing TRSMRCY or setting USB_QUIRK_RESET doesn't help at all. Since the remote wakeup capability is super broken, just disable it to get rid of the troubles. The device can still be autosuspended when the bluetooth interface is closed, which won't break the device as remote wakeup is unneeded in this case. Link: https://bbs.archlinux.org/viewtopic.php?id=308169 Link: https://bbs.bee-link.com/d/7694-gtr9-pro-ai-max-395-usb-issues Signed-off-by: Rong Zhang Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: remove extra copy in cmd array init

2026-06-11T18:24:39+00:00

In btmtk_setup_firmware_79xx, the data length indicated by wmt_params.dlen in the cmd buffer is MTK_SEC_MAP_NEED_SEND_SIZE + 1. Except for the first byte, the remaining length is MTK_SEC_MAP_NEED_SEND_SIZE. memcpy copied one more byte to cmd + 1 than the remaining length. Align the length passed to memcpy to avoid exceeding current section map. Signed-off-by: Jiajia Liu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: add event filter to filter specific event

2026-06-11T18:24:37+00:00

Add an event filter to filter event with specific opcode to prevent BT stack from receiving unexpected event. Event with opcode 0xfc5d is generated when MediaTek's Bluetooth enable firmware logs and is not expected to be sent to userspace. Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: fix urb->setup_packet leak in error paths

2026-05-20T20:35:47+00:00

The setup_packet of control urb is not freed if usb_submit_urb fails or the submitted urb is killed. Add free in these two paths. Fixes: a1c49c434e150 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices") Signed-off-by: Jiajia Liu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: accept too short WMT FUNC_CTRL events

2026-05-14T13:54:06+00:00

MT7925 (USB ID 0e8d:e025) on fw version 20260106153314 sends WMT FUNC_CTRL events that are missing the status field. Prior to commit 006b9943b982 ("Bluetooth: btmtk: validate WMT event SKB length before struct access") the status was read from out-of-bounds of SKB data, which usually would result to success with BTMTK_WMT_ON_UNDONE, although I don't know the intent here. The bounds check added in that commit returns with error instead, producing "Bluetooth: hci0: Failed to send wmt func ctrl (-22)" and makes the device unusable. Fix the regression by interpreting too short packet as status BTMTK_WMT_ON_UNDONE, which makes the device work normally again. Fixes: 634a4408c061 ("Bluetooth: btmtk: validate WMT event SKB length before struct access") Signed-off-by: Pauli Virtanen Tested-by: Mikhail Gavrilov # MT7922 (0489:e0e2) Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: validate WMT event SKB length before struct access

2026-05-06T20:22:19+00:00

btmtk_usb_hci_wmt_sync() casts the WMT event response SKB data to struct btmtk_hci_wmt_evt (7 bytes) and struct btmtk_hci_wmt_evt_funcc (9 bytes) without first checking that the SKB contains enough data. A short firmware response causes out-of-bounds reads from SKB tailroom. Use skb_pull_data() to validate and advance past the base WMT event header. For the FUNC_CTRL case, pull the additional status field bytes before accessing them. Fixes: d019930b0049 ("Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: hide unused btmtk_mt6639_devs[] array

2026-04-13T13:19:27+00:00

When USB support is disabled, the array is not referenced anywhere, causing a warning: drivers/bluetooth/btmtk.c:35:3: error: 'btmtk_mt6639_devs' defined but not used [-Werror=unused-const-variable=] 35 | } btmtk_mt6639_devs[] = { | ^~~~~~~~~~~~~~~~~ Move it into the #ifdef block. Fixes: 28b7c5a6db74 ("Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support") Signed-off-by: Arnd Bergmann Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: fix ISO interface setup for single alt setting

2026-04-13T13:18:16+00:00

Some MT6639 Bluetooth USB interfaces (e.g. IMC Networks 13d3:3588 on ASUS ROG STRIX X870E-E and ProArt X870E-Creator boards) expose only a single alternate setting (alt 0) on the ISO interface. The driver unconditionally requests alt setting 1, which fails with EINVAL on these devices, causing a ~20 second initialization delay and no LE audio support. Check the number of available alternate settings before selecting one. If only alt 0 exists, use it; otherwise request alt 1 as before. Closes: https://github.com/jetm/mediatek-mt7927-dkms/pull/39 Signed-off-by: Javier Tia Reported-by: Ryan Gilbert Tested-by: Ryan Gilbert Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support

2026-04-13T13:18:16+00:00

The MediaTek MT7927 (Filogic 380) combo WiFi 7 + BT 5.4 module uses hardware variant 0x6639 for its Bluetooth subsystem. Without this patch, the chip fails with "Unsupported hardware variant (00006639)" or hangs during firmware download. Three changes are needed to support MT6639: 1. CHIPID workaround: On some boards the BT USB MMIO register reads 0x0000 for dev_id, causing the driver to skip the 0x6639 init path. Force dev_id to 0x6639 only when the USB VID/PID matches a known MT6639 device, avoiding misdetection if a future chip also reads zero. This follows the WiFi-side pattern that uses PCI device IDs to scope the same workaround. 2. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of "1_1" used by MT7925 and other variants. The firmware path is mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin, using the mt7927 directory to match the WiFi firmware convention. The filename will likely change to use MT7927 once MediaTek submits a dedicated Linux firmware binary. 3. Section filtering: The MT6639 firmware binary contains 9 sections, but only sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related. Sending the remaining WiFi/other sections causes an irreversible BT subsystem hang requiring a full power cycle. This matches the Windows driver behavior observed via USB captures. Also add 0x6639 to the reset register (CONNV3) and firmware setup switch cases alongside the existing 0x7925 handling. Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096 Link: https://github.com/openwrt/mt76/issues/927 Reported-by: Ryan Gilbert Signed-off-by: Javier Tia Signed-off-by: Luiz Augusto von Dentz