user/sven/linux.git/drivers/bluetooth/btmtksdio.c, branch next/master

Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support

2026-03-31T14:24:22Z

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: add MT7902 SDIO support

2026-03-12T17:56:18Z

Add MT7902 Bluetooth SDIO support by introducing chip data and registering the device ID. Runtime PM is not yet supported by the driver, but normal operation is unaffected. Signed-off-by: Sean Wang Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtksdio: Use pm_ptr instead of #ifdef CONFIG_PM

2026-01-29T18:23:06Z

This increases build coverage and allows to drop an #ifdef. Signed-off-by: Uwe Kleine-König Signed-off-by: Luiz Augusto von Dentz

Bluetooth: Remove redundant pm_runtime_mark_last_busy() calls

2025-12-01T21:00:07Z

pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtksdio: Add pmctrl handling for BT closed state during reset

2025-10-24T14:20:50Z

This patch adds logic to handle power management control when the Bluetooth function is closed during the SDIO reset sequence. Specifically, if BT is closed before reset, the driver enables the SDIO function and sets driver pmctrl. After reset, if BT remains closed, the driver sets firmware pmctrl and disables the SDIO function. These changes ensure proper power management and device state consistency across the reset flow. Fixes: 8fafe702253d ("Bluetooth: mt7921s: support bluetooth reset mechanism") Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: remove duplicate h4_recv_buf() in header

2025-09-27T15:37:01Z

The "h4_recv.h" header contains a duplicate h4_recv_buf() that is nearly but not quite identical to the h4_recv_buf() in hci_h4.c. This duplicated header was added in commit 07eb96a5a7b0 ("Bluetooth: bpa10x: Use separate h4_recv_buf helper"). I wasn't able to find any explanation for duplicating the code in the discussion: https://lore.kernel.org/all/20180320181855.37297-1-marcel@holtmann.org/ https://lore.kernel.org/all/20180324091954.73229-2-marcel@holtmann.org/ Unfortunately, in the years since, several other drivers have come to also rely on this duplicated function, probably by accident. This is, at the very least, *extremely* confusing. It's also caused real issues when it's become out-of-sync, see the following: ef564119ba83 ("Bluetooth: hci_h4: Add support for ISO packets") 61b27cdf025b ("Bluetooth: hci_h4: Add support for ISO packets in h4_recv.h") This is the full diff between the two implementations today: --- orig.c +++ copy.c @@ -1,117 +1,100 @@ { - struct hci_uart *hu = hci_get_drvdata(hdev); - u8 alignment = hu->alignment ? hu->alignment : 1; - /* Check for error from previous call */ if (IS_ERR(skb)) skb = NULL; while (count) { int i, len; - /* remove padding bytes from buffer */ - for (; hu->padding && count > 0; hu->padding--) { - count--; - buffer++; - } - if (!count) - break; - if (!skb) { for (i = 0; i < pkts_count; i++) { if (buffer[0] != (&pkts[i])->type) continue; skb = bt_skb_alloc((&pkts[i])->maxlen, GFP_ATOMIC); if (!skb) return ERR_PTR(-ENOMEM); hci_skb_pkt_type(skb) = (&pkts[i])->type; hci_skb_expect(skb) = (&pkts[i])->hlen; break; } /* Check for invalid packet type */ if (!skb) return ERR_PTR(-EILSEQ); count -= 1; buffer += 1; } len = min_t(uint, hci_skb_expect(skb) - skb->len, count); skb_put_data(skb, buffer, len); count -= len; buffer += len; /* Check for partial packet */ if (skb->len < hci_skb_expect(skb)) continue; for (i = 0; i < pkts_count; i++) { if (hci_skb_pkt_type(skb) == (&pkts[i])->type) break; } if (i >= pkts_count) { kfree_skb(skb); return ERR_PTR(-EILSEQ); } if (skb->len == (&pkts[i])->hlen) { u16 dlen; switch ((&pkts[i])->lsize) { case 0: /* No variable data length */ dlen = 0; break; case 1: /* Single octet variable length */ dlen = skb->data[(&pkts[i])->loff]; hci_skb_expect(skb) += dlen; if (skb_tailroom(skb) < dlen) { kfree_skb(skb); return ERR_PTR(-EMSGSIZE); } break; case 2: /* Double octet variable length */ dlen = get_unaligned_le16(skb->data + (&pkts[i])->loff); hci_skb_expect(skb) += dlen; if (skb_tailroom(skb) < dlen) { kfree_skb(skb); return ERR_PTR(-EMSGSIZE); } break; default: /* Unsupported variable length */ kfree_skb(skb); return ERR_PTR(-EILSEQ); } if (!dlen) { - hu->padding = (skb->len + 1) % alignment; - hu->padding = (alignment - hu->padding) % alignment; - /* No more data, complete frame */ (&pkts[i])->recv(hdev, skb); skb = NULL; } } else { - hu->padding = (skb->len + 1) % alignment; - hu->padding = (alignment - hu->padding) % alignment; - /* Complete frame */ (&pkts[i])->recv(hdev, skb); skb = NULL; } } return skb; } -EXPORT_SYMBOL_GPL(h4_recv_buf) As I read this: If alignment is one, and padding is zero, padding remains zero throughout the loop. So it seems to me that the two functions behave strictly identically in that case. All the duplicated defines are also identical, as is the duplicated h4_recv_pkt structure declaration. All four drivers which use the duplicated function use the default alignment of one, and the default padding of zero. I therefore conclude the duplicate function may be safely replaced with the core one. I raised this in an RFC a few months ago, and didn't get much interest: https://lore.kernel.org/all/CABBYNZ+ONkYtq2fR-8PtL3X-vetvJ0BdP4MTw9cNpjLDzG3HUQ@mail.gmail.com/ ...but I'm still wary I've missed something, and I'd really appreciate more eyeballs on it. I tested this successfully on btnxpuart a few months ago, but unfortunately I no longer have access to that hardware. Cc: Marcel Holtmann Signed-off-by: Calvin Owens Reviewed-by: Paul Menzel Signed-off-by: Luiz Augusto von Dentz

Bluetooth: hci_dev: replace 'quirks' integer by 'quirk_flags' bitmap

2025-07-16T19:37:53Z

The 'quirks' member already ran out of bits on some platforms some time ago. Replace the integer member by a bitmap in order to have enough bits in future. Replace raw bit operations by accessor macros. Fixes: ff26b2dd6568 ("Bluetooth: Add quirk for broken READ_VOICE_SETTING") Fixes: 127881334eaa ("Bluetooth: Add quirk for broken READ_PAGE_SCAN_TYPE") Suggested-by: Pauli Virtanen Tested-by: Ivan Pravdin Signed-off-by: Kiran K Signed-off-by: Christian Eggers Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtksdio: Fix wakeup source leaks on device unbind

2025-05-21T14:27:36Z

Device can be unbound or probe can fail, so driver must also release memory for the wakeup source. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtksdio: Do close if SDIO card removed without close

2025-04-25T19:03:19Z

To prevent Bluetooth SDIO card from be physically removed suddenly, driver needs to ensure btmtksdio_close is called before btmtksdio_remove to disable interrupts and txrx workqueue. Fixes: 6ac4233afb9a ("Bluetooth: btmtksdio: Prevent enabling interrupts after IRQ handler removal") Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz

Bluetooth: btmtksdio: Check function enabled before doing close

2025-04-25T19:03:19Z

Check BTMTKSDIO_FUNC_ENABLED flag before doing close to prevent btmtksdio_close been called twice. Fixes: 6ac4233afb9a ("Bluetooth: btmtksdio: Prevent enabling interrupts after IRQ handler removal") Signed-off-by: Chris Lu Signed-off-by: Luiz Augusto von Dentz