kernel/git/stable/linux.git/drivers/bluetooth/btmtk.c, branch linux-7.2.y

Bluetooth: btmtk: Fix short read errors in btmtk_usb_reg_read()

2026-07-28T20:13:48+00:00

If btmtk_usb_reg_read() gets a "short" read from a device, it will accidentally treat that as a "real" read and populate the returned value with some unknown and probably totally invalid data. Fix this logic error up by calling usb_control_msg_recv() which guarantees a "full" read happens, and then simplify the error checking for when btmtk_usb_reg_read() is called (it's really just btmtk_usb_id_get() that calls btmtk_usb_reg_read(), so fix up those return sites. Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtk: Fix short read errors in btmtk_usb_uhw_reg_read()

2026-07-28T20:13:48+00:00

If btmtk_usb_uhw_reg_read() gets a "short" read from a device, it will accidentally treat that as a "real" read and populate the returned value with some unknown and probably totally invalid data. Fix this logic error up by calling usb_control_msg_recv() which guarantees a "full" read happens, and then simplify the error checking for when btmtk_usb_uhw_reg_read() is called. Note, one caller of btmtk_usb_uhw_reg_read() does not check the return value, but as we pre-initialize the return value as 0, an incorrect read will not do anything wrong. Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Luiz Augusto von Dentz

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