kernel/linux.git/drivers/bluetooth/btmtk.c, branch v7.1

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

Bluetooth: btmtk: refactor endpoint lookup

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

Use the common USB helper for looking up bulk and interrupt endpoints instead of open coding. Signed-off-by: Johan Hovold Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: add MT7902 MCU support

2026-04-10T14:24:37+00:00

Add MT7902 device ID and firmware filename to enable MCU firmware loading. Signed-off-by: Sean Wang Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: Add reset mechanism if downloading firmware failed

2026-04-10T14:21:39+00:00

Add a new flag 'BTMTK_FIRMWARE_DL_RETRY'. If an error occurs during mt79xx firmware download process, this flag will be set and cleared after a reset. If the flag is already set and firmware still cannot be loaded successfully after a reset, no further reset attempts will be made. In other words, if there is a problem during firmware download, only one reset will be attempted. Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: add status check in mt79xx firmware setup

2026-04-10T14:21:19+00:00

To prevent abnormal controller states, it is necessary to check status in another part of the mt79xx firmware setup. During this process, receiving the 'BTMTK_WMT_PATCH_PROGRESS' status is unexpected. If this occurs, it should be treated as an error, and driver must be prevented from continuing execution. Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz