Re: [PATCH v2] Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform

[Rong Zhang]

Hi Rafael,

于 2026年7月7日 GMT+08:00 02:21:57，Rafael Passos <rafael at rcpassos.me> 写道：
>On Mon Jul 6, 2026 at 12:08 PM -03, Rong Zhang wrote:
>> Hi Rafael, 
>>
>> 于 2026年7月6日 GMT+08:00 22:53:17，Rafael Passos <rafael at rcpassos.me> 写道：
>>>Tested-by: Rafael Passos <rafael at rcpassos.me>
>>
>> Thanks a lot for your testing!
>>
>> Your issue sounds related to the remote wakeup issue I am addressing. After triggering the remote wakeup bug, rebooting the platform without a power cycle [1] always causes a failure in USB enumeration before the driver path.
>
>In my case, just the power cycle was not sufficient. I had to also
>change settings in BIOS [1], and only then it came back.
>Even after reverting all settings to the same state as before.
>
>I was hoping to fix this in Kernel, but I don't see a way forward.
>If you have any other ideas or patches to test, send them my way!
>I will gladly help.
>
>[1] I turned off sr-iov, resize-bar & disabled "Bluetooth On/Off".
>In a previous attempt, fast-boot and TPM were also disabled.

Hmm, interesting. My speculation is that it doesn't matter which options are changed, but some changed options cause the BIOS to reinitialize something. Does resetting the BIOS settings to default help?

Could you provide more details about your device's USB and PCI topology? Does the NIC's USB connect to one of the USB root hubs of the SoC (i.e., CPU) or the chipset?

And I guess your device runs into the issue without any precursor? Once boot, try running the script below to capture more clues into dmesg, and wait for the issue to appear.

    #!/bin/sh

    ddcmd()
    {
        echo "$*" | sudo tee /proc/dynamic_debug/control;
    }

    ddcmd file drivers/usb/core/hub.c +p
    ddcmd file drivers/usb/core/driver.c +p
    ddcmd func handle_tx_event +p

I would do the below experiments if I had a buggy device like that. Some extra hardware is required though.

Connect another NIC (w/ Bluetooth interface) to the same M.2 port after triggering the enumeration failure, and see if the enumeration failure persists.

Connect a passive M.2 (A+E key) to USB2.0 adapter card to the same M.2 port after triggering the enumeration failure, connect a USB2.0 device to the adapter card, and see if the enumeration failure persists.

Connect the MTK NIC to a PCIe port using a passive PCIe to M.2 (A/E key) adapter card, such a card usually routes the USB signal from the M.2 interface to a 9-pin cable. Connect the 9-pin connector to the motherboard's USB expansion port, and try triggering the enumeration failure. Now connect the 9-pin connector to a dedicated PCIe USB controller card, and see if the enumeration failure persists.

All mentioned extra hardware is cheap and easy to get in China. Though I guess it would be a completely different story in some other regions... Trying one of these experiments should be sufficient, so you can make your decision based on hardware availability.

Thanks,
Rong

>
>Thanks,
>Rafael Passos