Re: [PATCH 1/2] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support

Re: [PATCH 1/2] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support

[Javier Tia]

Hi Sean,

On Fri, Mar 7, 2026 Sean Wang wrote:
> BT and WiFi use separate firmware.
> I'm not sure why those WiFi sections are included in the binary.
> Another concern is whether it is appropriate to upload the firmware
> used in Windows to the linux-firmware repository,
> The firmware files are probably intended for dedicated OEMs.

The section filtering remains in v2 since the binary from the ASUS
driver package does contain mixed BT+WiFi sections. The firmware
upload question is being tracked separately in linux-firmware
MR !946.

On that topic - would it be possible for MediaTek to provide a
proper BT firmware binary for linux-firmware, or to sign off on
the one extracted from the ASUS driver package? That would resolve
the firmware provenance concern. If a formal submission from
MediaTek is required, could you help coordinate that?

> This is common logic for the other mediatek chips. It only takes
> longer on the first power-on.

[...]

> If the firmware download is properly handled in
> btmtk_setup_firmware_79xx, we don't need the extra bit.

Understood. The BTMTK_FIRMWARE_LOADED flag and skip logic are
removed in v2. Firmware persistence is handled by the existing
framework as you suggested.

v2 is sent with these changes addressed.

Best,
Javier

Re: [PATCH 1/2] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support

[Sean Wang]

Hi, Javier

On Wed, Mar 25, 2026 at 7:23 PM Javier Tia <floss@jetm.me> wrote:
>
> Hi Sean,
>
> On Fri, Mar 7, 2026 Sean Wang wrote:
> > BT and WiFi use separate firmware.
> > I'm not sure why those WiFi sections are included in the binary.
> > Another concern is whether it is appropriate to upload the firmware
> > used in Windows to the linux-firmware repository,
> > The firmware files are probably intended for dedicated OEMs.
>
> The section filtering remains in v2 since the binary from the ASUS
> driver package does contain mixed BT+WiFi sections. The firmware
> upload question is being tracked separately in linux-firmware
> MR !946.
>
> On that topic - would it be possible for MediaTek to provide a
> proper BT firmware binary for linux-firmware, or to sign off on
> the one extracted from the ASUS driver package? That would resolve
> the firmware provenance concern. If a formal submission from
> MediaTek is required, could you help coordinate that?
>

Yes, this has been under internal coordination for some time already.
I also hope we can have a Linux-dedicated firmware binary rather than
relying on one extracted from a Windows driver package, as that would
be a cleaner upstream path.
For now, the practical step is to make the driver-side handling robust
and consistent first, so it is ready once the proper firmware is
available.

> > This is common logic for the other mediatek chips. It only takes
> > longer on the first power-on.
>
> [...]
>
> > If the firmware download is properly handled in
> > btmtk_setup_firmware_79xx, we don't need the extra bit.
>
> Understood. The BTMTK_FIRMWARE_LOADED flag and skip logic are
> removed in v2. Firmware persistence is handled by the existing
> framework as you suggested.
>

Good, it looks better after removing BTMTK_FIRMWARE_LOADED flags

> v2 is sent with these changes addressed.
>
> Best,
> Javier

Re: [PATCH 1/2] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support

[Javier Tia]

Hi Sean,

Thank you for the review. I have a few questions before
preparing v2.

On Fri, Mar 7, 2026 Sean Wang wrote:
> BT and WiFi use separate firmware.
> I'm not sure why those WiFi sections are included in the binary.
> Another concern is whether it is appropriate to upload the firmware
> used in Windows to the linux-firmware repository,
> The firmware files are probably intended for dedicated OEMs.

Understood. The BT firmware we have came from an ASUS Windows
driver package because no official Linux firmware exists yet
for MT6639.

Regarding the section filtering: the MT6639 is a combo chip,
and the firmware binary we have contains 9 sections - some BT,
some not. Without filtering on (dlmodecrctype & 0xff) == 0x01,
the chip hangs irreversibly during download. I'd argue the
driver should handle mixed-section firmware correctly regardless
of source, since combo chip firmware may inherently contain
sections for multiple subsystems. But if MediaTek provides a
clean BT-only binary, the filtering becomes a no-op and can
be dropped.

Three questions:

1. Is MediaTek planning to release official MT6639/MT7927 BT
   firmware for linux-firmware? A clean BT-only binary would
   simplify the driver code.

2. The WiFi side has the same firmware dependency. The WiFi
   series I sent to linux-wireless [1] uses
   WIFI_MT6639_PATCH_MCU_2_1_hdr.bin and
   WIFI_RAM_CODE_MT6639_2_1.bin under mediatek/mt6639/. Is
   there a plan for official WiFi firmware submission, and
   would the path be mediatek/mt6639/ or something else
   (e.g. mediatek/mt7927/)?

3. Luiz requires a MediaTek engineer Signed-off-by on the
   btmtk patch confirming the changes work as intended. Would
   you be able to review and sign off on v2, or point me to
   the right person at MediaTek for BT driver changes?

I plan to decouple the driver patches from firmware
availability - the btmtk/btusb changes are valid independent
of which firmware binary ends up in linux-firmware. The
linux-firmware MR !946 can track separately.

> This is common logic for the other mediatek chips. It only takes
> longer on the first power-on.

> If the firmware download is properly handled in
> btmtk_setup_firmware_79xx, we don't need the extra bit.

Got it. I'll drop the BTMTK_FIRMWARE_LOADED flag in v2 and
let btmtk_setup_firmware_79xx handle persistence the same way
it does for other chips.

[1] https://lore.kernel.org/linux-wireless/20260319-mt7927-wifi-support-v2-v2-0-d627a7fad70d@jetm.me/

Best,
Javier

Re: [PATCH 1/2] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support

[Javier Tia]

Hi Luiz,

On Thu, Mar 5, 2026 Luiz Augusto von Dentz wrote:
> Ditto, we will probably some evidence this was actually tested on
> systems e.g. dmesg of the pre/post change, also in this case
> specifically we need a mediatek engineer to confim, with a
> Signed-off-by, that these changes works as intended.

Here is the dmesg evidence from my system (ASUS ROG Crosshair X870E
Hero, 0489:e13a, kernel 6.19.6).

Pre-patch (vanilla 6.19.6 btusb/btmtk, no MT6639 support):

  Bluetooth: hci0: Unsupported hardware variant (00006639)
  Bluetooth: hci0: Device setup failed (-22)

Post-patch (this series applied):

  Bluetooth: hci0: HW/SW Version: 0x00000000, Build Time: 20250606201235
  Bluetooth: hci0: Device setup in 8287370 usecs
  Bluetooth: hci0: AOSP extensions version v1.00

bluetoothctl shows the controller is fully operational:

  Controller 78:46:5C:9B:C2:C2 (public)
    Manufacturer: 0x0046 (70)
    Name: jetm-rog-crosshair-hero-x870e
    Powered: yes

This has been tested on 6 different boards across multiple distros.
The DKMS package [1] has been the primary driver for all MT7927
Bluetooth users since January.

Deren, Mingyen, Sean - could you please review the btmtk changes in
this patch and provide a Signed-off-by or Reviewed-by if the
implementation looks correct? Luiz requires a MediaTek engineer to
confirm these changes work as intended before merging.

For context: the BT firmware (BT_RAM_CODE_MT6639_2_1_hdr.bin) was
extracted from MediaTek's mtkwlan.dat combo blob shipped in the ASUS
Windows driver package (V5603998). The extraction uses a Python script
that parses the container format and pulls out the BT firmware
section. The firmware has been submitted to linux-firmware as GitLab
MR !946 [2].

The driver changes (firmware naming, section filtering, persistence
skip, CONNV3 reset) were developed by studying the Windows driver USB
captures and the existing btmtk code paths for MT7925/MT7961.

[1] https://github.com/jetm/mediatek-mt7927-dkms
[2] https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/946

Javier

[PATCH 0/2] Bluetooth: Add MediaTek MT7927 (MT6639) support

[Javier Tia]

This series adds Bluetooth support for the MediaTek MT7927 (Filogic 380)
combo WiFi 7 + BT 5.4 module. The BT subsystem uses hardware variant
0x6639 and connects via USB.

The MT7927 is shipping in motherboards and PCIe add-in cards from ASUS,
Gigabyte, Lenovo, and TP-Link since mid-2024. Without these patches,
users see "Unsupported hardware variant (00006639)" or the BT subsystem
hangs during firmware download.

Jean-François Marlière independently identified the same three root
causes and posted an analysis to the list in February [1], though the
patch diff was not included in that message. This series provides the
complete, split patches addressing the same issues.

The series consists of two patches:

  [1/2] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
  [2/2] Bluetooth: btusb: Add USB device IDs for MediaTek MT7927 (MT6639)

Three driver changes are needed for MT6639:

1. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
   "1_1" used by MT7925 and other variants. The firmware path is
   mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin.

2. Section filtering: The firmware binary contains 9 sections, but only
   sections with (dlmodecrctype & 0xff) == 0x01 are Bluetooth-related.
   Sending WiFi/other sections causes an irreversible BT subsystem hang.
   The filter is gated on dev_id == 0x6639 to avoid affecting other chips.

3. Firmware persistence: Firmware persists across BT soft power cycles
   (WMT_FUNC_CTRL=0 does not clear it). Skip re-download on subsequent
   setups to avoid a ~2.6s delay.

The firmware blob (BT_RAM_CODE_MT6639_2_1_hdr.bin) is being submitted
separately to linux-firmware via GitLab MR.

Tested on:
- ASUS ROG Crosshair X870E Hero (USB 0489:e13a)
- Arch Linux 6.19.6, BlueZ 5.82

The companion WiFi support for MT7927 (mt76/mt7925e driver) is being
submitted separately to linux-wireless.

[1] https://lore.kernel.org/linux-bluetooth/496b0f8505eb6ffb19fdbee6f963c62aa6790fba.camel@marliere.fr/

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221096
Link: https://github.com/openwrt/mt76/issues/927

Javier Tia (2):
  Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support
  Bluetooth: btusb: Add USB device IDs for MediaTek MT7927 (MT6639)

 drivers/bluetooth/btmtk.c | 32 ++++++++++++++++++++++++++++++--
 drivers/bluetooth/btmtk.h |  1 +
 drivers/bluetooth/btusb.c | 10 ++++++++++
 3 files changed, 41 insertions(+), 2 deletions(-)

[PATCH 1/2] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support

[Javier Tia]

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. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
   "1_1" used by MT7925 and other variants. The firmware path is
   mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin.

2. 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.

3. Firmware persistence: MT6639 firmware persists across BT soft power
   cycles (WMT_FUNC_CTRL=0 does not clear firmware). Skip re-download on
   subsequent setups to avoid a ~2.6s delay on each BT power toggle.

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
Assisted-by: Claude Code <noreply@anthropic.com> [claude-opus-4-6]
Signed-off-by: Javier Tia <floss@jetm.me>
---
 drivers/bluetooth/btmtk.c | 32 ++++++++++++++++++++++++++++++--
 drivers/bluetooth/btmtk.h |  1 +
 2 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 2507d587f28a..3821fde9e361 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -112,7 +112,11 @@ static void btmtk_coredump_notify(struct hci_dev *hdev, int state)
 void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, u32 fw_ver,
 			   u32 fw_flavor)
 {
-	if (dev_id == 0x7925)
+	if (dev_id == 0x6639)
+		snprintf(buf, size,
+			 "mediatek/mt%04x/BT_RAM_CODE_MT%04x_2_%x_hdr.bin",
+			 dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
+	else if (dev_id == 0x7925)
 		snprintf(buf, size,
 			 "mediatek/mt%04x/BT_RAM_CODE_MT%04x_1_%x_hdr.bin",
 			 dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
@@ -130,6 +134,7 @@ EXPORT_SYMBOL_GPL(btmtk_fw_get_filename);
 int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
 			      wmt_cmd_sync_func_t wmt_cmd_sync)
 {
+	struct btmtk_data *data = hci_get_priv(hdev);
 	struct btmtk_hci_wmt_params wmt_params;
 	struct btmtk_patch_header *hdr;
 	struct btmtk_global_desc *globaldesc = NULL;
@@ -166,6 +171,14 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
 		section_offset = le32_to_cpu(sectionmap->secoffset);
 		dl_size = le32_to_cpu(sectionmap->bin_info_spec.dlsize);
 
+		/* MT6639: only download sections where dlmode byte0 == 0x01,
+		 * matching the Windows driver behavior which skips WiFi/other
+		 * sections that would cause the chip to hang.
+		 */
+		if (data->dev_id == 0x6639 && dl_size > 0 &&
+		    (le32_to_cpu(sectionmap->bin_info_spec.dlmodecrctype) & 0xff) != 0x01)
+			continue;
+
 		if (dl_size > 0) {
 			retry = 20;
 			while (retry > 0) {
@@ -852,7 +865,7 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
 		if (err < 0)
 			return err;
 		msleep(100);
-	} else if (dev_id == 0x7925) {
+	} else if (dev_id == 0x7925 || dev_id == 0x6639) {
 		err = btmtk_usb_uhw_reg_read(hdev, MTK_BT_RESET_REG_CONNV3, &val);
 		if (err < 0)
 			return err;
@@ -1339,9 +1352,20 @@ int btmtk_usb_setup(struct hci_dev *hdev)
 	case 0x7925:
 	case 0x7961:
 	case 0x7902:
+	case 0x6639:
 		btmtk_fw_get_filename(fw_bin_name, sizeof(fw_bin_name), dev_id,
 				      fw_version, fw_flavor);
 
+		/* MT6639: firmware persists across BT soft power cycles
+		 * (shutdown only sends WMT_FUNC_CTRL=0). Skip re-download
+		 * on subsequent setups to avoid ~2.6s delay.
+		 */
+		if (dev_id == 0x6639 &&
+		    test_bit(BTMTK_FIRMWARE_LOADED, &btmtk_data->flags)) {
+			bt_dev_info(hdev, "MT6639: firmware already loaded, skipping download");
+			goto skip_fw_setup_79xx;
+		}
+
 		err = btmtk_setup_firmware_79xx(hdev, fw_bin_name,
 						btmtk_usb_hci_wmt_sync);
 		if (err < 0) {
@@ -1352,6 +1376,10 @@ int btmtk_usb_setup(struct hci_dev *hdev)
 			return err;
 		}
 
+		if (dev_id == 0x6639)
+			set_bit(BTMTK_FIRMWARE_LOADED, &btmtk_data->flags);
+
+skip_fw_setup_79xx:
 		/* It's Device EndPoint Reset Option Register */
 		err = btmtk_usb_uhw_reg_write(hdev, MTK_EP_RST_OPT,
 					      MTK_EP_RST_IN_OUT_OPT);
diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
index adaf385626ee..6645bcadb523 100644
--- a/drivers/bluetooth/btmtk.h
+++ b/drivers/bluetooth/btmtk.h
@@ -8,6 +8,7 @@
 #define FIRMWARE_MT7902		"mediatek/BT_RAM_CODE_MT7902_1_1_hdr.bin"
 #define FIRMWARE_MT7961		"mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin"
 #define FIRMWARE_MT7925		"mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin"
+#define FIRMWARE_MT7927		"mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin"
 
 #define HCI_EV_WMT 0xe4
 #define HCI_WMT_MAX_EVENT_SIZE		64
-- 
2.53.0

Re: [PATCH 1/2] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support

[Luiz Augusto von Dentz]

Hi Javier,

On Thu, Mar 5, 2026 at 11:33 AM Javier Tia <floss@jetm.me> wrote:
>
> 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. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
>    "1_1" used by MT7925 and other variants. The firmware path is
>    mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin.
>
> 2. 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.
>
> 3. Firmware persistence: MT6639 firmware persists across BT soft power
>    cycles (WMT_FUNC_CTRL=0 does not clear firmware). Skip re-download on
>    subsequent setups to avoid a ~2.6s delay on each BT power toggle.
>
> 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
> Assisted-by: Claude Code <noreply@anthropic.com> [claude-opus-4-6]

Ditto, we will probably some evidence this was actually tested on
systems e.g. dmesg of the pre/post change, also in this case
specifically we need a mediatek engineer to confim, with a
Signed-off-by, that these changes works as intended.

> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
>  drivers/bluetooth/btmtk.c | 32 ++++++++++++++++++++++++++++++--
>  drivers/bluetooth/btmtk.h |  1 +
>  2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> index 2507d587f28a..3821fde9e361 100644
> --- a/drivers/bluetooth/btmtk.c
> +++ b/drivers/bluetooth/btmtk.c
> @@ -112,7 +112,11 @@ static void btmtk_coredump_notify(struct hci_dev *hdev, int state)
>  void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, u32 fw_ver,
>                            u32 fw_flavor)
>  {
> -       if (dev_id == 0x7925)
> +       if (dev_id == 0x6639)
> +               snprintf(buf, size,
> +                        "mediatek/mt%04x/BT_RAM_CODE_MT%04x_2_%x_hdr.bin",
> +                        dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
> +       else if (dev_id == 0x7925)
>                 snprintf(buf, size,
>                          "mediatek/mt%04x/BT_RAM_CODE_MT%04x_1_%x_hdr.bin",
>                          dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
> @@ -130,6 +134,7 @@ EXPORT_SYMBOL_GPL(btmtk_fw_get_filename);
>  int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
>                               wmt_cmd_sync_func_t wmt_cmd_sync)
>  {
> +       struct btmtk_data *data = hci_get_priv(hdev);
>         struct btmtk_hci_wmt_params wmt_params;
>         struct btmtk_patch_header *hdr;
>         struct btmtk_global_desc *globaldesc = NULL;
> @@ -166,6 +171,14 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
>                 section_offset = le32_to_cpu(sectionmap->secoffset);
>                 dl_size = le32_to_cpu(sectionmap->bin_info_spec.dlsize);
>
> +               /* MT6639: only download sections where dlmode byte0 == 0x01,
> +                * matching the Windows driver behavior which skips WiFi/other
> +                * sections that would cause the chip to hang.
> +                */
> +               if (data->dev_id == 0x6639 && dl_size > 0 &&
> +                   (le32_to_cpu(sectionmap->bin_info_spec.dlmodecrctype) & 0xff) != 0x01)
> +                       continue;
> +
>                 if (dl_size > 0) {
>                         retry = 20;
>                         while (retry > 0) {
> @@ -852,7 +865,7 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
>                 if (err < 0)
>                         return err;
>                 msleep(100);
> -       } else if (dev_id == 0x7925) {
> +       } else if (dev_id == 0x7925 || dev_id == 0x6639) {
>                 err = btmtk_usb_uhw_reg_read(hdev, MTK_BT_RESET_REG_CONNV3, &val);
>                 if (err < 0)
>                         return err;
> @@ -1339,9 +1352,20 @@ int btmtk_usb_setup(struct hci_dev *hdev)
>         case 0x7925:
>         case 0x7961:
>         case 0x7902:
> +       case 0x6639:
>                 btmtk_fw_get_filename(fw_bin_name, sizeof(fw_bin_name), dev_id,
>                                       fw_version, fw_flavor);
>
> +               /* MT6639: firmware persists across BT soft power cycles
> +                * (shutdown only sends WMT_FUNC_CTRL=0). Skip re-download
> +                * on subsequent setups to avoid ~2.6s delay.
> +                */
> +               if (dev_id == 0x6639 &&
> +                   test_bit(BTMTK_FIRMWARE_LOADED, &btmtk_data->flags)) {
> +                       bt_dev_info(hdev, "MT6639: firmware already loaded, skipping download");
> +                       goto skip_fw_setup_79xx;
> +               }
> +
>                 err = btmtk_setup_firmware_79xx(hdev, fw_bin_name,
>                                                 btmtk_usb_hci_wmt_sync);
>                 if (err < 0) {
> @@ -1352,6 +1376,10 @@ int btmtk_usb_setup(struct hci_dev *hdev)
>                         return err;
>                 }
>
> +               if (dev_id == 0x6639)
> +                       set_bit(BTMTK_FIRMWARE_LOADED, &btmtk_data->flags);
> +
> +skip_fw_setup_79xx:
>                 /* It's Device EndPoint Reset Option Register */
>                 err = btmtk_usb_uhw_reg_write(hdev, MTK_EP_RST_OPT,
>                                               MTK_EP_RST_IN_OUT_OPT);
> diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
> index adaf385626ee..6645bcadb523 100644
> --- a/drivers/bluetooth/btmtk.h
> +++ b/drivers/bluetooth/btmtk.h
> @@ -8,6 +8,7 @@
>  #define FIRMWARE_MT7902                "mediatek/BT_RAM_CODE_MT7902_1_1_hdr.bin"
>  #define FIRMWARE_MT7961                "mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin"
>  #define FIRMWARE_MT7925                "mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin"
> +#define FIRMWARE_MT7927                "mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin"
>
>  #define HCI_EV_WMT 0xe4
>  #define HCI_WMT_MAX_EVENT_SIZE         64
> --
> 2.53.0
>


-- 
Luiz Augusto von Dentz

Re: [PATCH 1/2] Bluetooth: btmtk: Add MT6639 (MT7927) Bluetooth support

[Sean Wang]

Hi Javier,

On Thu, Mar 5, 2026 at 10:33 AM Javier Tia <floss@jetm.me> wrote:
>
> 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. Firmware naming: MT6639 uses firmware version prefix "2_1" instead of
>    "1_1" used by MT7925 and other variants. The firmware path is
>    mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin.
>
> 2. 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.
>
> 3. Firmware persistence: MT6639 firmware persists across BT soft power
>    cycles (WMT_FUNC_CTRL=0 does not clear firmware). Skip re-download on
>    subsequent setups to avoid a ~2.6s delay on each BT power toggle.
>
> 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
> Assisted-by: Claude Code <noreply@anthropic.com> [claude-opus-4-6]
> Signed-off-by: Javier Tia <floss@jetm.me>
> ---
>  drivers/bluetooth/btmtk.c | 32 ++++++++++++++++++++++++++++++--
>  drivers/bluetooth/btmtk.h |  1 +
>  2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> index 2507d587f28a..3821fde9e361 100644
> --- a/drivers/bluetooth/btmtk.c
> +++ b/drivers/bluetooth/btmtk.c
> @@ -112,7 +112,11 @@ static void btmtk_coredump_notify(struct hci_dev *hdev, int state)
>  void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id, u32 fw_ver,
>                            u32 fw_flavor)
>  {
> -       if (dev_id == 0x7925)
> +       if (dev_id == 0x6639)
> +               snprintf(buf, size,
> +                        "mediatek/mt%04x/BT_RAM_CODE_MT%04x_2_%x_hdr.bin",
> +                        dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
> +       else if (dev_id == 0x7925)
>                 snprintf(buf, size,
>                          "mediatek/mt%04x/BT_RAM_CODE_MT%04x_1_%x_hdr.bin",
>                          dev_id & 0xffff, dev_id & 0xffff, (fw_ver & 0xff) + 1);
> @@ -130,6 +134,7 @@ EXPORT_SYMBOL_GPL(btmtk_fw_get_filename);
>  int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
>                               wmt_cmd_sync_func_t wmt_cmd_sync)
>  {
> +       struct btmtk_data *data = hci_get_priv(hdev);
>         struct btmtk_hci_wmt_params wmt_params;
>         struct btmtk_patch_header *hdr;
>         struct btmtk_global_desc *globaldesc = NULL;
> @@ -166,6 +171,14 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
>                 section_offset = le32_to_cpu(sectionmap->secoffset);
>                 dl_size = le32_to_cpu(sectionmap->bin_info_spec.dlsize);
>
> +               /* MT6639: only download sections where dlmode byte0 == 0x01,
> +                * matching the Windows driver behavior which skips WiFi/other
> +                * sections that would cause the chip to hang.
> +                */

BT and WiFi use separate firmware.
I’m not sure why those WiFi sections are included in the binary.
Another concern is whether it is appropriate to upload the firmware
used in Windows to the linux-firmware repository,
The firmware files are probably intended for dedicated OEMs.

> +               if (data->dev_id == 0x6639 && dl_size > 0 &&
> +                   (le32_to_cpu(sectionmap->bin_info_spec.dlmodecrctype) & 0xff) != 0x01)
> +                       continue;
> +
>                 if (dl_size > 0) {
>                         retry = 20;
>                         while (retry > 0) {
> @@ -852,7 +865,7 @@ int btmtk_usb_subsys_reset(struct hci_dev *hdev, u32 dev_id)
>                 if (err < 0)
>                         return err;
>                 msleep(100);
> -       } else if (dev_id == 0x7925) {
> +       } else if (dev_id == 0x7925 || dev_id == 0x6639) {
>                 err = btmtk_usb_uhw_reg_read(hdev, MTK_BT_RESET_REG_CONNV3, &val);
>                 if (err < 0)
>                         return err;
> @@ -1339,9 +1352,20 @@ int btmtk_usb_setup(struct hci_dev *hdev)
>         case 0x7925:
>         case 0x7961:
>         case 0x7902:
> +       case 0x6639:
>                 btmtk_fw_get_filename(fw_bin_name, sizeof(fw_bin_name), dev_id,
>                                       fw_version, fw_flavor);
>
> +               /* MT6639: firmware persists across BT soft power cycles
> +                * (shutdown only sends WMT_FUNC_CTRL=0). Skip re-download
> +                * on subsequent setups to avoid ~2.6s delay.
> +                */

This is common logic for the other mediatek chips. It only takes
longer on the first power-on.

> +               if (dev_id == 0x6639 &&
> +                   test_bit(BTMTK_FIRMWARE_LOADED, &btmtk_data->flags)) {
> +                       bt_dev_info(hdev, "MT6639: firmware already loaded, skipping download");
> +                       goto skip_fw_setup_79xx;
> +               }
> +
>                 err = btmtk_setup_firmware_79xx(hdev, fw_bin_name,
>                                                 btmtk_usb_hci_wmt_sync);
>                 if (err < 0) {
> @@ -1352,6 +1376,10 @@ int btmtk_usb_setup(struct hci_dev *hdev)
>                         return err;
>                 }
>
> +               if (dev_id == 0x6639)
> +                       set_bit(BTMTK_FIRMWARE_LOADED, &btmtk_data->flags);

If the firmware download is properly handled in
btmtk_setup_firmware_79xx, we don't need the extra bit.

> +
> +skip_fw_setup_79xx:
>                 /* It's Device EndPoint Reset Option Register */
>                 err = btmtk_usb_uhw_reg_write(hdev, MTK_EP_RST_OPT,
>                                               MTK_EP_RST_IN_OUT_OPT);
> diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
> index adaf385626ee..6645bcadb523 100644
> --- a/drivers/bluetooth/btmtk.h
> +++ b/drivers/bluetooth/btmtk.h
> @@ -8,6 +8,7 @@
>  #define FIRMWARE_MT7902                "mediatek/BT_RAM_CODE_MT7902_1_1_hdr.bin"
>  #define FIRMWARE_MT7961                "mediatek/BT_RAM_CODE_MT7961_1_2_hdr.bin"
>  #define FIRMWARE_MT7925                "mediatek/mt7925/BT_RAM_CODE_MT7925_1_1_hdr.bin"
> +#define FIRMWARE_MT7927                "mediatek/mt6639/BT_RAM_CODE_MT6639_2_1_hdr.bin"
>
>  #define HCI_EV_WMT 0xe4
>  #define HCI_WMT_MAX_EVENT_SIZE         64
> --
> 2.53.0
>