[PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

[PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

[Rong Zhang]

These NICs are often reported to lose their Bluetooth interfaces, i.e,
their USB interfaces suddenly become completely unresponsive, causing
the USB core to reset them, only to find that they are no longer
accessible. A power cycle is required to make the Bluetooth interfaces
recover.

After some investigations, I found that their USB autosuspend remote
wakeup capabilities are so broken that they are precisely the culprit
behind the issue:

  [27452.608056] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020
  [27452.702018] usb 3-5: usb wakeup-resume
  [27452.716038] usb 3-5: Waited 0ms for CONNECT
  [27452.716642] usb 3-5: finish resume
  /* usbmon showed that the device was completely unresponsive to any
     URBs after the remote wakeup */
  [27457.836030] usb 3-5: retry with reset-resume
  [27457.956046] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
  [27463.332047] usb 3-5: device descriptor read/64, error -110
  [27478.948117] usb 3-5: device descriptor read/64, error -110
  [27479.172430] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
  [27484.332035] usb 3-5: device descriptor read/64, error -110
  [27499.940039] usb 3-5: device descriptor read/64, error -110
  [27500.164060] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
  [27505.196142] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27510.576045] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27510.784038] usb 3-5: device not accepting address 4, error -62
  [27510.912215] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
  [27515.948307] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27521.324380] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27521.525107] usb 3-5: device not accepting address 4, error -62
  [27521.525928] usb usb3-port5: logical disconnect
  [27521.525996] usb 3-5: gone after usb resume? status -19
  [27521.526230] usb 3-5: can't resume, status -19
  [27521.526434] usb usb3-port5: logical disconnect
  [27521.526469] usb usb3-port5: resume, status -19
  [27521.526493] usb usb3-port5: status 0503, change 0004, 480 Mb/s
  [27521.526528] usb 3-5: USB disconnect, device number 4
  [27521.526736] usb 3-5: unregistering device
  [27521.804029] usb 3-5: new high-speed USB device number 5 using xhci_hcd
  [27527.076067] usb 3-5: device descriptor read/64, error -110
  [27542.692027] usb 3-5: device descriptor read/64, error -110
  [27542.916047] usb 3-5: new high-speed USB device number 6 using xhci_hcd
  [27548.068043] usb 3-5: device descriptor read/64, error -110
  [27563.684073] usb 3-5: device descriptor read/64, error -110
  [27563.792133] usb usb3-port5: attempt power cycle
  [27563.924381] hub 3-0:1.0: port_wait_reset: err = -11
  [27563.925213] usb usb3-port5: not enabled, trying reset again...
  [27564.184398] usb 3-5: new high-speed USB device number 7 using xhci_hcd
  [27569.196322] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27574.572040] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27574.776053] usb 3-5: device not accepting address 7, error -62
  [27574.900165] usb 3-5: new high-speed USB device number 8 using xhci_hcd
  [27579.948039] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27585.324331] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
  [27585.528040] usb 3-5: device not accepting address 8, error -62
  [27585.528389] usb usb3-port5: unable to enumerate USB device
  [27585.528424] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020

To reproduce the issue, these conditions must be met:
- a noisy radio environment (cafe or office) to cause frequent remote
  wakeup events
- no Bluetooth device is connected, so autosuspend is not prohibited
- the Bluetooth interface is opened, so remote wakeup is enabled when
  the device runs into autosuspend

Then I can reproduce the issue within sereval hours each time.

Increasing TRSMRCY or setting USB_QUIRK_RESET doesn't help at all.

Since the remote wakeup capability is super broken, just disable it to
get rid of the troubles. The device can still be autosuspended when
the bluetooth interface is closed, which won't break the device as
remote wakeup is unneeded in this case.

Link: https://bbs.archlinux.org/viewtopic.php?id=308169
Link: https://bbs.bee-link.com/d/7694-gtr9-pro-ai-max-395-usb-issues
Signed-off-by: Rong Zhang <i@rong.moe>
---
 drivers/bluetooth/btmtk.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 8ff66b276af0..3d2a8598892b 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1379,6 +1379,16 @@ int btmtk_usb_setup(struct hci_dev *hdev)
 		break;
 	case 0x7922:
 	case 0x7925:
+		/*
+		 * A remote wakeup could cause the device completely unresponsive, and
+		 * recovering from such a state needs a power cycle.
+		 *
+		 * Since the remote wakeup capability is super broken, just disable it
+		 * to get rid of the troubles. The device can still be autosuspended
+		 * when the bluetooth interface is closed.
+		 */
+		device_set_wakeup_capable(&btmtk_data->udev->dev, false);
+		fallthrough;
 	case 0x7961:
 	case 0x7902:
 	case 0x6639:

---
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
change-id: a4222333-btmtk-remote-wakeup-494f4c97af88

Thanks,
Rong

Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Wed, 03 Jun 2026 02:38:10 +0800 you wrote:
> These NICs are often reported to lose their Bluetooth interfaces, i.e,
> their USB interfaces suddenly become completely unresponsive, causing
> the USB core to reset them, only to find that they are no longer
> accessible. A power cycle is required to make the Bluetooth interfaces
> recover.
> 
> After some investigations, I found that their USB autosuspend remote
> wakeup capabilities are so broken that they are precisely the culprit
> behind the issue:
> 
> [...]

Here is the summary with links:
  - Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
    https://git.kernel.org/bluetooth/bluetooth-next/c/247570151789

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

[Chris Lu (陸稚泓)]

Hi Luiz,

Could we revert this change?

Sorry, MediaTek wasn't aware someone submitted this change and it had
already been merged.

MTK believes this issue is strongly related to the platform's USB hub
behavior, The product lines MTK directly support haven't reported such
issue. 

Disable wake capability would severely impact wake on Bluetooth on
MTK's official product lines. Furthermore, this patch looks like a
workaround. There should be a better way to handle this issue. We hope
this change can be reverted.


On Wed, 2026-06-03 at 17:50 +0000, patchwork-bot+bluetooth@kernel.org
wrote:
> Hello:
> 
> This patch was applied to bluetooth/bluetooth-next.git (master)
> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
> 
> On Wed, 03 Jun 2026 02:38:10 +0800 you wrote:
> > These NICs are often reported to lose their Bluetooth interfaces,
> > i.e,
> > their USB interfaces suddenly become completely unresponsive,
> > causing
> > the USB core to reset them, only to find that they are no longer
> > accessible. A power cycle is required to make the Bluetooth
> > interfaces
> > recover.
> > 
> > After some investigations, I found that their USB autosuspend
> > remote
> > wakeup capabilities are so broken that they are precisely the
> > culprit
> > behind the issue:
> > 
> > [...]
> 
> Here is the summary with links:
>   - Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
>     https://git.kernel.org/bluetooth/bluetooth-next/c/247570151789
> 
> You are awesome, thank you!


Best Regards,
Chris Lu

Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

[Rong Zhang]

Hi Chris,

于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)" <Chris.Lu@mediatek.com> 写道：
>Hi Luiz,
>
>Could we revert this change?

Please don't. The fundamental goal of the patch is to make MT7922/MT7925 *usable* on affected platforms.

Moreover, almost all recent AMD platforms ship with MT7922/MT7925, reverting this patch affects quite a lot of users. Almost every AMD platform I've met suffers from the issue, and there are plenty of bug reports.

Intel platforms never ship with MTK WLAN NICs, so I can't tell if the issue is reproducible on them.

>
>Sorry, MediaTek wasn't aware someone submitted this change and it had
>already been merged.
>
>MTK believes this issue is strongly related to the platform's USB hub
>behavior, 

Still, I believe that there are some interoperability issues in MT7922/MT7925's hardware or firmware, as reinitializing the XHCI root hub (by logically removing it from the PCI bus and probing it again) doesn't make it recover at all.

> The product lines MTK directly support haven't reported such
>issue.

...or did you mean none of the existing AMD platforms are supported by MTK?

>
>Disable wake capability would severely impact wake on Bluetooth on
>MTK's official product lines.

Could you kindly explain "MTK's official product lines"?

> Furthermore, this patch looks like a
>workaround. There should be a better way to handle this issue. We hope
>this change can be reverted.

The issue is severe on affected platforms by making the Bluetooth interface completely gone. IMHO, we must figure out the "better way" before reverting it, or else it's more like burying your head into sand by shouting "works fine on our platforms" (TM).

That being said, I think we can narrow the range of the quirk down to AMD platforms only. Does it make sense to you? If so, I will submit a patch for this.

Thanks,
Rong

>
>
>On Wed, 2026-06-03 at 17:50 +0000, patchwork-bot+bluetooth@kernel.org
>wrote:
>> Hello:
>> 
>> This patch was applied to bluetooth/bluetooth-next.git (master)
>> by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
>> 
>> On Wed, 03 Jun 2026 02:38:10 +0800 you wrote:
>> > These NICs are often reported to lose their Bluetooth interfaces,
>> > i.e,
>> > their USB interfaces suddenly become completely unresponsive,
>> > causing
>> > the USB core to reset them, only to find that they are no longer
>> > accessible. A power cycle is required to make the Bluetooth
>> > interfaces
>> > recover.
>> > 
>> > After some investigations, I found that their USB autosuspend
>> > remote
>> > wakeup capabilities are so broken that they are precisely the
>> > culprit
>> > behind the issue:
>> > 
>> > [...]
>> 
>> Here is the summary with links:
>>   - Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
>>     https://git.kernel.org/bluetooth/bluetooth-next/c/247570151789
>> 
>> You are awesome, thank you!
>
>
>Best Regards,
>Chris Lu

Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

[Luiz Augusto von Dentz]

Hi,


On Fri, Jun 26, 2026 at 7:19 AM Rong Zhang <i@rong.moe> wrote:
>
> Hi Chris,
>
> 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)" <Chris.Lu@mediatek.com> 写道：
> >Hi Luiz,
> >
> >Could we revert this change?
>
> Please don't. The fundamental goal of the patch is to make MT7922/MT7925 *usable* on affected platforms.
>
> Moreover, almost all recent AMD platforms ship with MT7922/MT7925, reverting this patch affects quite a lot of users. Almost every AMD platform I've met suffers from the issue, and there are plenty of bug reports.
>
> Intel platforms never ship with MTK WLAN NICs, so I can't tell if the issue is reproducible on them.

We cannot really remove it anymore, since it has already been pulled.
Therefore, I strongly prefer that the issue is fixed somehow or if
there is no other way then a proper revert patch must be sent, since I
don't have any hardware with this controller I cannot really test this
myself.

> >
> >Sorry, MediaTek wasn't aware someone submitted this change and it had
> >already been merged.
> >
> >MTK believes this issue is strongly related to the platform's USB hub
> >behavior,
>
> Still, I believe that there are some interoperability issues in MT7922/MT7925's hardware or firmware, as reinitializing the XHCI root hub (by logically removing it from the PCI bus and probing it again) doesn't make it recover at all.
>
> > The product lines MTK directly support haven't reported such
> >issue.
>
> ...or did you mean none of the existing AMD platforms are supported by MTK?
>
> >
> >Disable wake capability would severely impact wake on Bluetooth on
> >MTK's official product lines.
>
> Could you kindly explain "MTK's official product lines"?
>
> > Furthermore, this patch looks like a
> >workaround. There should be a better way to handle this issue. We hope
> >this change can be reverted.
>
> The issue is severe on affected platforms by making the Bluetooth interface completely gone. IMHO, we must figure out the "better way" before reverting it, or else it's more like burying your head into sand by shouting "works fine on our platforms" (TM).
>
> That being said, I think we can narrow the range of the quirk down to AMD platforms only. Does it make sense to you? If so, I will submit a patch for this.

Ok, then you guys please coordinate. I don't want to start requiring
Sign-Off-By (SOB) from driver authors because this instance shows that
response time can be very long. Therefore, the best way forward in my
opinion, is to have the issue fixed in a way that works for both of
you.

Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

[Chris Lu (陸稚泓)]

Hi Rong and Luiz,

On Fri, 2026-06-26 at 12:54 -0400, Luiz Augusto von Dentz wrote:
> Hi,
> 
> 
> On Fri, Jun 26, 2026 at 7:19 AM Rong Zhang <i@rong.moe> wrote:
> > 
> > Hi Chris,
> > 
> > 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)"
> > <Chris.Lu@mediatek.com> 写道：
> > > Hi Luiz,
> > > 
> > > Could we revert this change?
> > 
> > Please don't. The fundamental goal of the patch is to make
> > MT7922/MT7925 *usable* on affected platforms.
> > 
> > Moreover, almost all recent AMD platforms ship with MT7922/MT7925,
> > reverting this patch affects quite a lot of users. Almost every AMD
> > platform I've met suffers from the issue, and there are plenty of
> > bug reports.
> > 
> > Intel platforms never ship with MTK WLAN NICs, so I can't tell if
> > the issue is reproducible on them.
> 
We still have non-AMD platforms with MT7922/7925, where 
"wakeup by Bluetooth" is an essential feature. In other word, this
change will have a serious impact to them.

> We cannot really remove it anymore, since it has already been pulled.
> Therefore, I strongly prefer that the issue is fixed somehow or if
> there is no other way then a proper revert patch must be sent, since
> I
> don't have any hardware with this controller I cannot really test
> this
> myself.
> 
Got  it.
> > > 
> > > Sorry, MediaTek wasn't aware someone submitted this change and it
> > > had
> > > already been merged.
> > > 
> > > MTK believes this issue is strongly related to the platform's USB
> > > hub
> > > behavior,
> > 
> > Still, I believe that there are some interoperability issues in
> > MT7922/MT7925's hardware or firmware, as reinitializing the XHCI
> > root hub (by logically removing it from the PCI bus and probing it
> > again) doesn't make it recover at all.
> > 
> > > The product lines MTK directly support haven't reported such
> > > issue.
> > 
> > ...or did you mean none of the existing AMD platforms are supported
> > by MTK?
> > 
I'll report it to corresponding department to see if they have such
issue. (I'm not from Bluetooth with AMD platform support team)

> > > 
> > > Disable wake capability would severely impact wake on Bluetooth
> > > on
> > > MTK's official product lines.
> > 
> > Could you kindly explain "MTK's official product lines"?
> > 
Some products are module makers selling our modules to downstream
customers directly.

> > > Furthermore, this patch looks like a
> > > workaround. There should be a better way to handle this issue. We
> > > hope
> > > this change can be reverted.
> > 
> > The issue is severe on affected platforms by making the Bluetooth
> > interface completely gone. IMHO, we must figure out the "better
> > way" before reverting it, or else it's more like burying your head
> > into sand by shouting "works fine on our platforms" (TM).
> > 
> > That being said, I think we can narrow the range of the quirk down
> > to AMD platforms only. Does it make sense to you? If so, I will
> > submit a patch for this.
> 
As I mentioned above, we have many platforms using the kernel driver,
not just AMD,

If this change can be limited to specific platform , it would be the
best way so far.

> Ok, then you guys please coordinate. I don't want to start requiring
> Sign-Off-By (SOB) from driver authors because this instance shows
> that
> response time can be very long. Therefore, the best way forward in my
> opinion, is to have the issue fixed in a way that works for both of
> you.

Of course, Mediatek BT team also agree that any issue need to be
resolved, However, original issue for this change requires further
verification of Hardware/firmware and even USB behavior. A device that
can reproduce the issue stably is required in order to experiment and
identify the root cause.

As mentioned, I'll deliver internally to relate support team. If they
have similar settings, MTK will attempt to reproduce it and provide an
official solution.

Thanks very much for your input and understanding.

Best Regards,
Chris Lu

Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

[Rong Zhang]

Hi Chris, Luiz,

On Fri, 2026-06-26 at 17:56 +0000, Chris Lu (陸稚泓) wrote:
> Hi Rong and Luiz,
> 
> On Fri, 2026-06-26 at 12:54 -0400, Luiz Augusto von Dentz wrote:
> > Hi,
> > 
> > 
> > On Fri, Jun 26, 2026 at 7:19 AM Rong Zhang <i@rong.moe> wrote:
> > > 
> > > Hi Chris,
> > > 
> > > 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)"
> > > <Chris.Lu@mediatek.com> 写道：
> > > > Hi Luiz,
> > > > 
> > > > Could we revert this change?
> > > 
> > > Please don't. The fundamental goal of the patch is to make
> > > MT7922/MT7925 *usable* on affected platforms.
> > > 
> > > Moreover, almost all recent AMD platforms ship with MT7922/MT7925,
> > > reverting this patch affects quite a lot of users. Almost every AMD
> > > platform I've met suffers from the issue, and there are plenty of
> > > bug reports.
> > > 
> > > Intel platforms never ship with MTK WLAN NICs, so I can't tell if
> > > the issue is reproducible on them.
> > 
> We still have non-AMD platforms with MT7922/7925, where 
> "wakeup by Bluetooth" is an essential feature. In other word, this
> change will have a serious impact to them.

Oh, perhaps I missed something before. Your words were a bit unclear to
me at first glance.

You previous reply said "wake on Bluetooth". I interpreted it as USB
remote wakeup upon Bluetooch device connection.

"Wakeup by Bluetooth" is clearer. You meant using the Bluetooth
interface as a wakeup source to wake up the system from sleep, right?

Hmm, it makes more sense to me.

My patch was inspired by commit f4292e2faf52 ("Bluetooth: btusb: Make
the CSR clone chip force-suspend workaround more generic"). The
mentioned commit is correct as the quirky chips can't perform remote
wakeup at all.

If MT7922/MT7925 can reliably wake up the system from sleep, my patch
could be a burden. I won't insist anymore if you'd like to revert it.

> 
> > We cannot really remove it anymore, since it has already been pulled.
> > Therefore, I strongly prefer that the issue is fixed somehow or if
> > there is no other way then a proper revert patch must be sent, since
> > I
> > don't have any hardware with this controller I cannot really test
> > this
> > myself.
> > 
> Got  it.
> > > > 
> > > > Sorry, MediaTek wasn't aware someone submitted this change and it
> > > > had
> > > > already been merged.
> > > > 
> > > > MTK believes this issue is strongly related to the platform's USB
> > > > hub
> > > > behavior,
> > > 
> > > Still, I believe that there are some interoperability issues in
> > > MT7922/MT7925's hardware or firmware, as reinitializing the XHCI
> > > root hub (by logically removing it from the PCI bus and probing it
> > > again) doesn't make it recover at all.
> > > 
> > > > The product lines MTK directly support haven't reported such
> > > > issue.
> > > 
> > > ...or did you mean none of the existing AMD platforms are supported
> > > by MTK?
> > > 
> I'll report it to corresponding department to see if they have such
> issue. (I'm not from Bluetooth with AMD platform support team)
> 
> > > > 
> > > > Disable wake capability would severely impact wake on Bluetooth
> > > > on
> > > > MTK's official product lines.
> > > 
> > > Could you kindly explain "MTK's official product lines"?
> > > 
> Some products are module makers selling our modules to downstream
> customers directly.
> 
> > > > Furthermore, this patch looks like a
> > > > workaround. There should be a better way to handle this issue. We
> > > > hope
> > > > this change can be reverted.
> > > 
> > > The issue is severe on affected platforms by making the Bluetooth
> > > interface completely gone. IMHO, we must figure out the "better
> > > way" before reverting it, or else it's more like burying your head
> > > into sand by shouting "works fine on our platforms" (TM).
> > > 
> > > That being said, I think we can narrow the range of the quirk down
> > > to AMD platforms only. Does it make sense to you? If so, I will
> > > submit a patch for this.
> > 
> As I mentioned above, we have many platforms using the kernel driver,
> not just AMD,
> 
> If this change can be limited to specific platform , it would be the
> best way so far.

I plan to submit another patch to properly fix it next week. In general,
I will:

- narrow the quirk down to AMD platforms only
- disable USB remote wakeup for runtime autosuspend only
- leave the wakeup source as is, so users can enable "wakeup by
Bluetooth" even on AMD platforms if they really want it

Hopefully it will minimize the impact of the workaround.

Thanks,
Rong

> 
> > Ok, then you guys please coordinate. I don't want to start requiring
> > Sign-Off-By (SOB) from driver authors because this instance shows
> > that
> > response time can be very long. Therefore, the best way forward in my
> > opinion, is to have the issue fixed in a way that works for both of
> > you.
> 
> Of course, Mediatek BT team also agree that any issue need to be
> resolved, However, original issue for this change requires further
> verification of Hardware/firmware and even USB behavior. A device that
> can reproduce the issue stably is required in order to experiment and
> identify the root cause.
> 
> As mentioned, I'll deliver internally to relate support team. If they
> have similar settings, MTK will attempt to reproduce it and provide an
> official solution.
> 
> Thanks very much for your input and understanding.
> 
> Best Regards,
> Chris Lu