[PATCH] Bluetooth: btmtk: set HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN for MT6639

[PATCH] Bluetooth: btmtk: set HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN for MT6639

[Silviu Sandulache]

The MediaTek MT6639 Bluetooth controller (the BT half of the MT7925/MT7927
WiFi 7 combo silicon shipped on motherboards such as the ASUS ProArt
X870E-CREATOR WIFI) advertises support for HCI Enhanced Setup Synchronous
Connection (opcode 0x043D) in its supported-commands bitmap, but rejects
the command at runtime.

This breaks HFP wideband-speech (mSBC): when a Bluetooth headset is
connected and the kernel attempts to set up an mSBC eSCO link, the
controller responds with an error and the kernel logs:

  Bluetooth: hciN: HCI Enhanced Setup Synchronous Connection command \
      is advertised, but not supported.

User-visible symptom: the headset microphone captures pure silence in
HFP mode, while A2DP playback works normally. This reproduces on every
MT6639-based machine seen so far.

A Bluetooth HCI trace captured on Windows on the same hardware (ASUS
X870E-CREATOR with the MediaTek WHQL driver, recorded via the ETW
BTHPORT provider during an HFP wideband recording session) shows that
the Windows driver works around the same firmware bug by issuing the
classic Setup Synchronous Connection command (opcode 0x0428) with
Transparent air-mode parameters. The classic command sets up an mSBC
eSCO link successfully, and the headset streams 16 kHz mono wideband
audio over it as expected.

HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN exists in the BR/EDR HCI core
for exactly this case: when set, hci_setup_sync_conn() falls back to
the classic Setup Synchronous Connection command with the same
parameters. Setting the quirk for MT6639 makes Linux do what Windows
does, restoring wideband HFP.

The change is scoped to dev_id == 0x6639 to keep it hardware-confirmed
on the chip where the bug has been reproduced and the Windows fallback
has been observed. Sibling MT79xx variants (MT7921 / MT7922 / MT7925 /
MT7961) exhibit the same dmesg signature in community bug reports; if
the same fallback proves correct for them, extending the quirk to
those chip IDs is straightforward follow-up.

Verification on an ASUS ProArt X870E-CREATOR WIFI:

  - Before patch: profile switch to headset-head-unit (mSBC) is
    accepted by PipeWire, but the kernel issues HCI_OP_ENHANCED_SETUP_
    SYNC_CONN (0x043D), the controller refuses it, no eSCO link is
    established, the mic captures pure silence.
  - After patch: the kernel issues HCI_OP_SETUP_SYNC_CONN (0x0428)
    with Air Coding Format = Transparent. The controller responds
    Synchronous Connect Complete: Status Success, Link type eSCO,
    Air mode Transparent. SCO data flows over the link.

Signed-off-by: Silviu Sandulache <silviu.sandulache@gmail.com>
---
 drivers/bluetooth/btmtk.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index ab34f1d..4bd2e6c 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1417,6 +1417,19 @@ int btmtk_usb_setup(struct hci_dev *hdev)
 		hci_set_msft_opcode(hdev, 0xFD30);
 		hci_set_aosp_capable(hdev);
 
+		/* MT6639 firmware advertises the HCI Enhanced Setup
+		 * Synchronous Connection command (opcode 0x043D) in its
+		 * supported-commands bitmap, but actually rejects it at
+		 * runtime, breaking mSBC wideband HFP (the headset mic
+		 * captures pure silence). The Windows MediaTek driver
+		 * works around this by falling back to the classic Setup
+		 * Synchronous Connection command (opcode 0x0428); setting
+		 * this quirk makes the BR/EDR core do the same fallback.
+		 */
+		if (dev_id == 0x6639)
+			hci_set_quirk(hdev,
+				      HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN);
+
 		/* Clear BTMTK_FIRMWARE_DL_RETRY if setup successfully */
 		test_and_clear_bit(BTMTK_FIRMWARE_DL_RETRY, &btmtk_data->flags);
 
-- 
2.54.0

RE: Bluetooth: btmtk: set HCI_QUIRK_BROKEN_ENHANCED_SETUP_SYNC_CONN for MT6639

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

This is automated email and please do not reply to this email!

Dear submitter,

Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1092685

---Test result---

Test Summary:
CheckPatch                    PASS      0.55 seconds
GitLint                       PASS      0.23 seconds
SubjectPrefix                 PASS      0.08 seconds
BuildKernel                   PASS      25.33 seconds
CheckAllWarning               PASS      28.30 seconds
CheckSparse                   PASS      28.08 seconds
BuildKernel32                 PASS      25.05 seconds
TestRunnerSetup               PASS      549.88 seconds
IncrementalBuild              PASS      25.94 seconds



https://github.com/bluez/bluetooth-next/pull/164

---
Regards,
Linux Bluetooth