Re: [PATCH] Bluetooth: btmtk: Fix MT7925 WMT command timeout due to sleep protection

["Chris Lu (陸稚泓)" <Chris.Lu@mediatek.com>]

Hi Danny,

Thanks for your explanation.

I'll check with Peter internally regarding the purpose of the
change "Bluetooth: btusb: Fix MT7925 fail to send download patch
command" at that time and why it wasn't followed up afterward and also
evaluate whether to resubmit the patch.

On Wed, 2026-06-03 at 08:27 -0400, Danny Messina wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> Hi Chris,
> 
> Thanks for the background, very helpful.
> 
> On register identification: I used usbmon to confirm WMT commands
> were
> physically reaching the device with Control OUT completing
> successfully, but the device returned zero bytes on every control IN
> poll for the full 10-second timeout. After reading through btmtk.c
> and
> adding printks to trace the exact failure point, I found a December
> 2023 patch submission by Peter Tsao titled "Bluetooth: btusb: Fix
> MT7925 fail to send download patch command" which referenced writing
> to register 0x18011100 to prevent the device entering sleep state
> during firmware download. Testing confirmed this resolved the WMT
> timeout on my hardware. The second bypass before FUNC_CTRL was
> discovered when firmware download succeeded but FUNC_CTRL
> subsequently
> timed out, indicating the chip re-enables sleep protection during the
> 100ms firmware activation delay.
> 
> On the subsystem reset: I was not aware of commit 33634e2ab. In my
> testing the reset was necessary to recover from repeated failed
> initialization attempts, as rmmod/modprobe without a cold power cycle
> left the chip unresponsive to the SLPPROT bypass alone. I defer to
> your judgment on whether it belongs here.
> 
> On your v7.1-rc fix: This was reproduced on a fresh install of
> Pop!_OS
> 24.04 running kernel 6.18.7. I don't have a v7 kernel available at
> the
> moment but will see if I can reproduce the issue there and report
> back.
> 
> Happy to provide any additional debugging output in the meantime.
> 
> Best regards,
> Danny Messina
> 
> 
> On Wed, Jun 3, 2026 at 4:37 AM Chris Lu (陸稚泓) <Chris.Lu@mediatek.com>
> wrote:
> > 
> > Add linux-bluetooth to maillist
> > 
> > > From: Chris Lu (陸稚泓) <Chris.Lu@mediatek.com>
> > > Sent: Wednesday, June 3, 2026 3:50 PM
> > > To: messinadm@gmail.com
> > > Cc: luiz.dentz@gmail.com; SS Wu (巫憲欣) <ss.wu@mediatek.com>;
> > > marcel@holtmann.org; Peter Tsao (曹珆彰) <Peter.Tsao@mediatek.com>
> > > Subject: Re: [PATCH] Bluetooth: btmtk: Fix MT7925 WMT command
> > > timeout
> > > due to sleep protection
> > > 
> > > Hi Danny,
> > > 
> > > Thanks for your submission. I have some question about this
> > > patch.
> > > 
> > > > -----Original Message-----
> > > > From: Danny Messina <messinadm@gmail.com>
> > > > Sent: Monday, June 1, 2026 2:07 AM
> > > > To: linux-bluetooth@vger.kernel.org
> > > > Cc: Peter Tsao (曹珆彰) <Peter.Tsao@mediatek.com>;
> > > > marcel@holtmann.org;
> > > > Luiz Augusto von Dentz <luiz.dentz@gmail.com>
> > > > Subject: [PATCH] Bluetooth: btmtk: Fix MT7925 WMT command
> > > > timeout
> > > > due
> > > > to sleep protection
> > > > 
> > > > 
> > > > External email : Please do not click links or open attachments
> > > > until
> > > > you have verified the sender or the content.
> > > > 
> > > >   The MediaTek MT7925 USB Bluetooth device (0e8d:0717) fails to
> > > > initialize
> > > >   with repeated "Execution of wmt command timed out" errors:
> > > > 
> > > >     Bluetooth: hci0: Execution of wmt command timed out
> > > >     Bluetooth: hci0: Failed to send wmt patch dwnld (-110)
> > > >     Bluetooth: hci0: Failed to set up firmware (-110)
> > > > 
> > > >   USB capture (usbmon) confirms WMT commands reach the device —
> > > > the
> > > >   Control OUT transfer completes with status 0 — but the device
> > > > never
> > > >   responds on any endpoint. The control IN polling URB returns
> > > > zero
> > > > bytes
> > > >   indefinitely until HCI_INIT_TIMEOUT expires.
> > > > 
> > > >   The root cause is the MT7925 BT core's sleep protection
> > > > register
> > > >   (0x18011100, bit 1 = SLPPROT_BYPASS). When SLPPROT is active
> > > > the
> > > > BT
> > > >   processor ignores incoming WMT commands.
> > > > 
> > > >   Two additional issues compound this:
> > > > 
> > > >   1. After repeated driver load/unload cycles without a
> > > > hardware
> > > > reset,
> > > >      the BT subsystem's WMT state machine becomes stuck. A
> > > > subsystem
> > > >      reset via btmtk_usb_subsys_reset() restores it to a
> > > > workable
> > > > state.
> > > > 
> > > >   2. After btmtk_setup_firmware_79xx() activates the downloaded
> > > > firmware
> > > >      (which ends with a 100ms activation delay), the chip re-
> > > > enables
> > > >      SLPPROT. The subsequent FUNC_CTRL WMT command therefore
> > > > also
> > > > times
> > > >      out unless SLPPROT is bypassed again.
> > > > 
> > > >   Fix this for dev_id 0x7925 in btmtk_usb_setup():
> > > >     1. Call btmtk_usb_subsys_reset() to clear any stuck WMT
> > > > state.
> > > >     2. Set 0x18011100 |= BIT(1) before firmware download.
> > > >     3. Set 0x18011100 |= BIT(1) again before FUNC_CTRL.
> > > > 
> > > 
> > > Could you share how you identified which register/value need to
> > > be
> > > modified on MT7925 with such situation and why performed reset at
> > > this specific point helps avoid the setup issue?
> > > 
> > > >   Tested on a System76 Thelio desktop with MT7925 PCIe combo
> > > > card,
> > > >   USB ID 0e8d:0717, kernel 6.18.7.
> > > > 
> > > >   Signed-off-by: Danny Messina <messinadm@gmail.com>
> > > >   ---
> > > >    drivers/bluetooth/btmtk.c | 33
> > > > +++++++++++++++++++++++++++++++++
> > > >    1 file changed, 33 insertions(+)
> > > > 
> > > >   diff --git a/drivers/bluetooth/btmtk.c
> > > > b/drivers/bluetooth/btmtk.c
> > > >   --- a/drivers/bluetooth/btmtk.c
> > > >   +++ b/drivers/bluetooth/btmtk.c
> > > >   @@ -1326,6 +1326,24 @@
> > > >         case 0x7922:
> > > >         case 0x7925:
> > > >         case 0x7961:
> > > >   +             if (dev_id == 0x7925) {
> > > >   +                     u32 val = 0;
> > > >   +
> > > >   +                     /* Reset BT subsystem to clear any
> > > > stuck
> > > > WMT
> > > > state */
> > > >   +                     err = btmtk_usb_subsys_reset(hdev,
> > > > dev_id);
> > > >   +                     if (err < 0)
> > > >   +                             bt_dev_warn(hdev, "BT subsys
> > > > reset
> > > > failed (%d), continuing", err);
> > > >   +
> > > >   +                     /* Bypass sleep protection so WMT
> > > > commands
> > > > reach the BT core */
> > > >   +                     err = btmtk_usb_uhw_reg_read(hdev,
> > > > 0x18011100,
> > > > &val);
> > > >   +                     if (err < 0)
> > > >   +                             return err;
> > > >   +                     val |= BIT(1);
> > > >   +                     err = btmtk_usb_uhw_reg_write(hdev,
> > > > 0x18011100, val);
> > > >   +                     if (err < 0)
> > > >   +                             return err;
> > > >   +             }
> > > >   +
> > > >                 btmtk_fw_get_filename(fw_bin_name,
> > > > sizeof(fw_bin_name), dev_id,
> > > >                                       fw_version, fw_flavor);
> > > > 
> > > >   @@ -1342,6 +1360,19 @@
> > > >                 if (err < 0)
> > > >                         return err;
> > > > 
> > > >   +             /* Re-bypass sleep protection after firmware
> > > > activation for MT7925 */
> > > >   +             if (dev_id == 0x7925) {
> > > >   +                     u32 val = 0;
> > > >   +
> > > >   +                     err = btmtk_usb_uhw_reg_read(hdev,
> > > > 0x18011100,
> > > > &val);
> > > >   +                     if (err < 0)
> > > >   +                             return err;
> > > >   +                     val |= BIT(1);
> > > >   +                     err = btmtk_usb_uhw_reg_write(hdev,
> > > > 0x18011100, val);
> > > >   +                     if (err < 0)
> > > >   +                             return err;
> > > >   +             }
> > > >   +
> > > >                 /* Enable Bluetooth protocol */
> > > >                 param = 1;
> > > >                 wmt_params.op = BTMTK_WMT_FUNC_CTRL;
> > > 
> > > I'd also like to share some relevant background on this change:
> > > 
> > > MediaTek Bluetooth team previously implemented a similar reset
> > > before
> > > firmware download to ensure the controller was always in an
> > > initial
> > > state. However, it was later reported by kernel community that
> > > this
> > > caused USB enumeration failures on other devices, so the change
> > > was
> > > reverted (commit 33634e2ab "Bluetooth: btmtk: Remove the
> > > resetting
> > > step before downloading the fw").
> > > 
> > > In April this year, I submitted a fix addressing setup failures
> > > on
> > > MediaTek Bluetooth devices, which has been included since kernel
> > > v7.1- rc. Could you try reproducing the issue with a recent
> > > kernel to
> > > see whether the problem still occurs?
> > > 
> > > Looking forward to your feedback.
> > > 
> > > Best regards,
> > > Chris Lu
> > 
> > 
> > *********** MEDIATEK Confidentiality Notice ***********
> > The information contained in this e-mail message (including any
> > attachments) may be confidential, proprietary, privileged, or
> > otherwise exempt from disclosure under applicable laws. It is
> > intended to be conveyed only to the designated recipient(s). Any
> > use, dissemination, distribution, printing, retaining or copying
> > of this e-mail (including its attachments) by unintended
> > recipient(s)
> > is strictly prohibited and may be unlawful. If you are not an
> > intended recipient of this e-mail, or believe that you have
> > received
> > this e-mail in error, please notify the sender immediately
> > (by replying to this e-mail), delete any and all copies of this
> > e-mail (including any attachments) from your system, and do not
> > disclose the content of this e-mail to any other person. Thank you!

Chris Lu