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@xxxxxxxx> wrote:
> > > 
> > > Hi Chris,
> > > 
> > > 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)"
> > > <Chris.Lu@xxxxxxxxxxxx> 写道：
> > > > 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