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

[Chris Lu (陸稚泓)]

Hi Rong,

Thanks for your understanding. We hope to find a better way to handle
this issue.


Hi Luiz,

Regarding this issue, MediaTek Bluetooth team has already initialed an
internal investigation for problematic combination and will seek
assistance from AMD SOC team to investigate the root cause of this
issue.

However, since this change has impact on MTK products, may I submit a
patch to remove it first? 

If the investigation determines the issue lies within MTK BT
driver/firmware, we'll submit a separate solution to fix it.


On Sat, 2026-06-27 at 03:56 +0800, Rong Zhang wrote:
> 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> 
> 
> 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

Thanks,
Chris Lu