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

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

[Danny Messina]

  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.

  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;

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

[Chris Lu (陸稚泓)]

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

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

[Danny Messina]

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!

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

[Chris Lu (陸稚泓)]

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

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

[Danny Messina]

Hi Chris,

Thanks -- I retested on v7.1-rc and the WMT command timeout no longer
reproduces.

Test setup:
  - Kernel: 7.1.0-rc6 (Fedora, 7.1.0-0.rc6.260604g...fc45)
  - HW: MT7925 (RZ717), BT iface USB 0e8d:0717
  - Firmware build time: 20260414
  - BlueZ: 5.86

Previously (6.18.7) setup failed with -110 on the wmt patch download
and "Execution of wmt command timed out". On 7.1.0-rc6 none of those
appear; hci0 completes setup (AOSP v1.00, MGMT 1.23), bluetoothd runs,
and an MX Ergo S Plus paired and works as a BT HID device. mt7925e
Wi-Fi associates and scans on the same boot.

Your change resolves the timeout. Your change resolves the timeout, so
I'll withdraw my patch as superseded.

Thanks,
Danny