[PATCH v2] Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform
Luiz Augusto von Dentz
luiz.dentz at gmail.com
Tue Sep 1 10:05:58 PDT 2026
Hi Rong,
On Tue, Sep 1, 2026 at 12:42 PM Rong Zhang <i at rong.moe> wrote:
>
> Hi Luiz,
>
> Gentle ping.
>
> On Wed, 2026-07-01 at 23:43 +0800, Rong Zhang wrote:
> > It is reported that a remote wakeup could cause MT7922/MT7925's btusb
> > interface completely unresponsive. Resetting the xHCI root hub doesn't
> > help at all, and recovering from such a state needs a power cycle.
> >
> > All reports seen to be relevant to Ryzen-based laptops. These NICs are
> > usually used as OEM components thanks to some sort of reference designs.
> > Their popularity on other platforms is unclear. While there is still a
> > chance that the quirk may exist on other platforms, be cautious and only
> > apply the quirk to direct children of Ryzen platforms's root hubs for
> > the time being. In most cases the root hub is on the SoC or PCH, which
> > needs the quirk. Unfortunately, this can't distinguish root hubs on PCIe
> > add-in cards. Such roughness should be acceptable, as PCIe USB
> > controller add-in cards are less commonly used nowadays. On the other
> > hand, applying the quirk doesn't hurt any functionalities either, as the
> > device can still be used as a wakeup source if desired. Theoretically,
> > we could retrieve the root hub's PCI vendor ID with some hierarchy
> > magic, but that's too intrusive...
> >
> > Meanwhile, though device_set_wakeup_capable(false) is the correct fix
> > for other NICs with fake remote wakeup capabilities, doing so for
> > MT7922/MT7925 effectively prevents it from being used as wakeup
> > sources as per userspace requests. Hence, return -EBUSY on runtime
> > suspend to prevent the interface from being autosuspended while it's
> > still opened, which has the same effect as
> > device_set_wakeup_capable(false), since disabling remote wakeup simply
> > causes the USB core to gate runtime autosuspend as well due to
> > needs_remote_wakeup == 1. The interface can be safely autosuspended as
> > long as remote wakeup is disabled, i.e., after closing the HCI device.
> >
> > Specifically, the interface may still take the advantage of remote
> > wakeup in order to wake up the system from sleep if userspace has
> > enabled it as a wakeup source.
> >
> > Fixes: e31d761628ad ("Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925")
> > Signed-off-by: Rong Zhang <i at rong.moe>
>
> Could you kindly take a look at the patch?
>
> Chris Lu from MediaTek has relied with a "LGTM" to the patch, and there
> is already a Tested-by from Rafael Passos. Additionally, based on
> Rafael's debugging observations, the issue does exist on AMD PCHs, so
> matching X86_FEATURE_ZEN is appropriate.
Please resubmit so it can be retested, since it has already been
archived for being over 30 days old.
> Thanks,
> Rong
>
> > ---
> > Changes in v2:
> > - Only apply the quirk to to direct children of Ryzen platforms's root
> > hubs
> > - Theoretically, we could retrieve the root hub's PCI vendor ID with
> > some hierarchy magic to further limit the range down to only root
> > hubs on the SoC or PCH, but that's too intrusive -- the hierarchy
> > magic really made me nervous once I saw what I have wrote, so I gave
> > it up
> > - Link to v1: https://patch.msgid.link/20260629-btmtk-ryzen-remote-wakeup-v1-1-1d2f1cee6d22@rong.moe
> > ---
> > drivers/bluetooth/btmtk.c | 10 -------
> > drivers/bluetooth/btusb.c | 73 ++++++++++++++++++++++++++++++++++++++++++++---
> > 2 files changed, 69 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> > index 02a96342e964..4614434dd57b 100644
> > --- a/drivers/bluetooth/btmtk.c
> > +++ b/drivers/bluetooth/btmtk.c
> > @@ -1381,16 +1381,6 @@ 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:
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 08c0a99a62c5..eef6e3b43bf9 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -6,6 +6,7 @@
> > * Copyright (C) 2005-2008 Marcel Holtmann <marcel at holtmann.org>
> > */
> >
> > +#include <linux/cpufeature.h>
> > #include <linux/dmi.h>
> > #include <linux/module.h>
> > #include <linux/usb.h>
> > @@ -957,6 +958,7 @@ struct qca_dump_info {
> > #define BTUSB_USE_ALT3_FOR_WBS 15
> > #define BTUSB_ALT6_CONTINUOUS_TX 16
> > #define BTUSB_HW_SSR_ACTIVE 17
> > +#define BTUSB_WAKEUP_BROKEN 18
> >
> > struct btusb_data {
> > struct hci_dev *hdev;
> > @@ -2936,10 +2938,25 @@ static int btusb_send_frame_mtk(struct hci_dev *hdev, struct sk_buff *skb)
> > }
> > }
> >
> > +static inline bool platform_is_ryzen(void)
> > +{
> > +#ifdef CONFIG_X86
> > + return boot_cpu_has(X86_FEATURE_ZEN);
> > +#else
> > + return false;
> > +#endif
> > +}
> > +
> > +static inline bool is_direct_child_of_root_hub(struct usb_device *udev)
> > +{
> > + return udev->parent == udev->bus->root_hub;
> > +}
> > +
> > static int btusb_mtk_setup(struct hci_dev *hdev)
> > {
> > struct btusb_data *data = hci_get_drvdata(hdev);
> > struct btmtk_data *btmtk_data = hci_get_priv(hdev);
> > + int err;
> >
> > /* MediaTek WMT vendor cmd requiring below USB resources to
> > * complete the handshake.
> > @@ -2956,7 +2973,40 @@ static int btusb_mtk_setup(struct hci_dev *hdev)
> > btusb_mtk_claim_iso_intf(data);
> > }
> >
> > - return btmtk_usb_setup(hdev);
> > + err = btmtk_usb_setup(hdev);
> > + if (err)
> > + return err;
> > +
> > + switch (btmtk_data->dev_id) {
> > + case 0x7922:
> > + case 0x7925:
> > + /*
> > + * All reports seen to be relevant to Ryzen-based laptops. These
> > + * NICs are usually used as OEM components thanks to some sort
> > + * of reference designs.
> > + *
> > + * Their popularity on other platforms is unclear. While there
> > + * is still a chance that the quirk may exist on other
> > + * platforms, be cautious and only apply the quirk to direct
> > + * children of Ryzen platforms's root hubs for the time being.
> > + *
> > + * In most cases the root hub is on the SoC or PCH, which needs
> > + * the quirk. Unfortunately, this can't distinguish root hubs on
> > + * PCIe add-in cards. Such roughness should be acceptable, as
> > + * PCIe USB controller add-in cards are less commonly used
> > + * nowadays. On the other hand, applying the quirk doesn't hurt
> > + * any functionalities either, as the device can still be used
> > + * as a wakeup source if desired.
> > + *
> > + * Theoretically, we could retrieve the root hub's PCI vendor ID
> > + * with some hierarchy magic, but that's too intrusive...
> > + */
> > + if (platform_is_ryzen() && is_direct_child_of_root_hub(data->udev))
> > + set_bit(BTUSB_WAKEUP_BROKEN, &data->flags);
> > + break;
> > + }
> > +
> > + return 0;
> > }
> >
> > static int btusb_mtk_shutdown(struct hci_dev *hdev)
> > @@ -4532,11 +4582,26 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
> >
> > BT_DBG("intf %p", intf);
> >
> > - /* Don't auto-suspend if there are connections or discovery in
> > - * progress; external suspend calls shall never fail.
> > + /*
> > + * It is reported that remote wakeup events could sometimes cause some
> > + * adapters completely unresponsive. Resetting the xHCI root hub doesn't
> > + * help at all, and recovering from such a state needs a power cycle.
> > + * Since disabling remote wakeup simply causes the USB core to gate
> > + * runtime autosuspend as well due to needs_remote_wakeup == 1, let's do
> > + * this ourselves to make our life easier. The interface can be safely
> > + * autosuspended as long as remote wakeup is disabled, i.e., after
> > + * closing the HCI device.
> > + *
> > + * Don't auto-suspend if there are connections or discovery in progress.
> > + *
> > + * External suspend calls shall never fail. Specifically, a device with
> > + * broken remote wakeup may still take the advantage of remote wakeup in
> > + * order to wake up the system from sleep if userspace has enabled it as
> > + * a wakeup source.
> > */
> > if (PMSG_IS_AUTO(message) &&
> > - (hci_conn_count(data->hdev) || hci_discovery_active(data->hdev)))
> > + ((test_bit(BTUSB_WAKEUP_BROKEN, &data->flags) && data->intf->needs_remote_wakeup) ||
> > + hci_conn_count(data->hdev) || hci_discovery_active(data->hdev)))
> > return -EBUSY;
> >
> > if (data->suspend_count++)
> >
> > ---
> > base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
> > change-id: 230ba8c9-btmtk-ryzen-remote-wakeup-055a407682ef
> >
> > Thanks,
> > Rong
--
Luiz Augusto von Dentz
More information about the linux-arm-kernel
mailing list