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

[Javier Tia <floss@jetm.me>]

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