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@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 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.