[BUG] wifi: mt76: mt7925u: probe with driver mt7925u failed with error -110

[BUG] wifi: mt76: mt7925u: probe with driver mt7925u failed with error -110

[Nick]

Reference: https://github.com/morrownr/USB-WiFi/issues/688#issuecomment-3999038526

The above thread is rather lengthy as we have been working on this
issue since Dec. 25.

Testing with a Netgear A9000 USB WiFi adapter (mt7925u driver). Kernel
7.0 rc2 and a x86_64 system. Additional testing with older kernels was
also performed with the same results.

Problem description:

Cold boot shows the adapter coming up and operating normally.

Removing the adapter from the USB port and replacing it shows the
adapter coming up and operating normally.

A warm reboot does not provide a WiFi interface and shows the
following in the system log:

mt7925u 2-3.2:1.0: probe with driver mt7925u failed with error -110

Using the commands rmmod and modeprobe do not provide a WiFi interface.

Thoughts: The problem likely is not the module teardown. The problem
seems to be that the firmware (or the mt7925u driver) leaves the
adapter in a strange state such that a power cycle of the adapter
hardware is needed before the mt7925u driver can properly initialize
it a second time.

Also: Testing with an adapter that uses the mt7921u driver does not
show this problem.

Re: [BUG] wifi: mt76: mt7925u: probe with driver mt7925u failed with error -110

[Sean Wang]

On Thu, Mar 5, 2026 at 12:28 PM Nick <morrownr@gmail.com> wrote:
>
> Reference: https://github.com/morrownr/USB-WiFi/issues/688#issuecomment-3999038526
>
> The above thread is rather lengthy as we have been working on this
> issue since Dec. 25.
>
> Testing with a Netgear A9000 USB WiFi adapter (mt7925u driver). Kernel
> 7.0 rc2 and a x86_64 system. Additional testing with older kernels was
> also performed with the same results.
>
> Problem description:
>
> Cold boot shows the adapter coming up and operating normally.
>
> Removing the adapter from the USB port and replacing it shows the
> adapter coming up and operating normally.
>
> A warm reboot does not provide a WiFi interface and shows the
> following in the system log:
>
> mt7925u 2-3.2:1.0: probe with driver mt7925u failed with error -110
>
> Using the commands rmmod and modeprobe do not provide a WiFi interface.
>
> Thoughts: The problem likely is not the module teardown. The problem
> seems to be that the firmware (or the mt7925u driver) leaves the
> adapter in a strange state such that a power cycle of the adapter
> hardware is needed before the mt7925u driver can properly initialize
> it a second time.
>

Hi Nick,

Could you enable debug logs and check whether the driver can still
read the correct chip ID after a warm reboot, and at which step the
initialization fails before the -110 error? Thanks for continuing to
test and gather this useful information.

         Sean

> Also: Testing with an adapter that uses the mt7921u driver does not
> show this problem.
>

Re: [BUG] wifi: mt76: mt7925u: probe with driver mt7925u failed with error -110

[Nick]

> > Reference: https://github.com/morrownr/USB-WiFi/issues/688#issuecomment-3999038526
> >
> > The above thread is rather lengthy as we have been working on this
> > issue since Dec. 25.
> >
> > Testing with a Netgear A9000 USB WiFi adapter (mt7925u driver). Kernel
> > 7.0 rc2 and a x86_64 system. Additional testing with older kernels was
> > also performed with the same results.
> >
> > Problem description:
> >
> > Cold boot shows the adapter coming up and operating normally.
> >
> > Removing the adapter from the USB port and replacing it shows the
> > adapter coming up and operating normally.
> >
> > A warm reboot does not provide a WiFi interface and shows the
> > following in the system log:
> >
> > mt7925u 2-3.2:1.0: probe with driver mt7925u failed with error -110
> >
> > Using the commands rmmod and modeprobe do not provide a WiFi interface.
> >
> > Thoughts: The problem likely is not the module teardown. The problem
> > seems to be that the firmware (or the mt7925u driver) leaves the
> > adapter in a strange state such that a power cycle of the adapter
> > hardware is needed before the mt7925u driver can properly initialize
> > it a second time.
> >
>
> Hi Nick,
>
> Could you enable debug logs and check whether the driver can still
> read the correct chip ID after a warm reboot, and at which step the
> initialization fails before the -110 error? Thanks for continuing to
> test and gather this useful information.
>
>          Sean

Hi Sean,

Github user @exct has performed the testing requested and provides the
following report:

mt7925u Probe Failure Debug Report
Adapter: Netgear A9000 (USB ID 0846:9072, MediaTek MT7925)
Kernel: 6.19.6-2-cachyos

Summary
The driver can read the correct chip ID after a warm reload. The
failure occurs before firmware is loaded, inside
mt792xu_wfsys_reset(), which times out waiting for the WiFi subsystem
to reinitialize. -ETIMEDOUT (-110) is returned and the probe aborts.

Findings

Question: Chip ID readable after warm reload?
Answer: Yes — MT_HW_CHIPID = 0x7925, MT_HW_REV = 0x8a00

Question: Which step fails?
Answer: mt792xu_wfsys_reset() — WFSYS_INIT_DONE never asserted

Question: Does it reach mt792xu_mcu_power_on()?
Answer: No

Question: Does it reach mt7925_run_firmware()?
Answer: No

Probe Sequence Trace

mt7925u_probe()
  ├─ mt76_alloc_device()             OK
  ├─ __mt76u_init()                  OK
  ├─ read MT_HW_CHIPID (0x70010200)  → 0x00007925  ✓
  ├─ read MT_HW_REV    (0x70010204)  → 0x00008a00  ✓
  ├─ read MT_CONN_ON_MISC (0x7c0600f0) → 0x00000003  ← FW_N9_RDY is SET
  ├─ enters mt792xu_wfsys_reset()    ← triggered because FW_N9_RDY = 1
  │    ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST  (assert reset)
  │    ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST  (deassert reset)
  │    ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
  │    ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
  │    └─ ... timeout after ~212 ms → return -ETIMEDOUT
  └─ goto error:  (mt76u_queues_deinit + mt76_free_device)

Root Cause

After rmmod, the firmware leaves FW_N9_RDY asserted in
MT_CONN_ON_MISC. On re-probe, the driver correctly detects this and
calls mt792xu_wfsys_reset() to recover. However, the WiFi subsystem
never signals completion — WFSYS_INIT_DONE in
MT_UDMA_CONN_INFRA_STATUS (reg 0x74000a20) stays 0x00000000 throughout
the retry loop. The subsystem is stuck in a state that the software
reset path cannot recover from. Only a full USB power cycle clears it.

Hope this helps,

Nick

Re: [BUG] wifi: mt76: mt7925u: probe with driver mt7925u failed with error -110

[Sean Wang]

Hi Nick,

Thanks for the detailed report  this is very helpful. I don't  have an
MT7925 USB device to detail look into the issue, but based on the
trace I wrote a small change to try a different MT7925 reset sequence.
please help test.

--- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
+++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
@@ -234,6 +234,36 @@ int mt792xu_dma_init(struct mt792x_dev *dev, bool resume)
 }
 EXPORT_SYMBOL_GPL(mt792xu_dma_init);

+static int mt7925u_wfsys_reset(struct mt792x_dev *dev)
+{
+    u32 val;
+    int i;
+
+#define MT7925_CBTOP_RGU_WF_SUBSYS_RST        0x70028600
+#define MT7925_WFSYS_SW_INIT_DONE_ADDR        0x184c1604
+#define MT7925_WFSYS_SW_INIT_DONE        0x00001d1e
+
+    val = mt792xu_uhw_rr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST);
+    val |= MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH;
+    mt792xu_uhw_wr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST, val);
+
+    msleep(20);
+
+    val = mt792xu_uhw_rr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST);
+    val &= ~MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH;
+    mt792xu_uhw_wr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST, val);
+
+    for (i = 0; i < MT792x_WFSYS_INIT_RETRY_COUNT; i++) {
+        val = mt792xu_uhw_rr(&dev->mt76, MT7925_WFSYS_SW_INIT_DONE_ADDR);
+        if (val == MT7925_WFSYS_SW_INIT_DONE)
+            return 0;
+
+        msleep(100);
+    }
+
+    return -ETIMEDOUT;
+}
+
 int mt792xu_wfsys_reset(struct mt792x_dev *dev)
 {
     u32 val;
@@ -241,6 +271,9 @@ int mt792xu_wfsys_reset(struct mt792x_dev *dev)

     mt792xu_epctl_rst_opt(dev, false);

+    if (is_mt7925(&dev->mt76))
+        return mt7925u_wfsys_reset(dev);
+
     val = mt792xu_uhw_rr(&dev->mt76, MT_CBTOP_RGU_WF_SUBSYS_RST);


On Fri, Mar 6, 2026 at 1:24 PM Nick <morrownr@gmail.com> wrote:
>
> > > Reference: https://github.com/morrownr/USB-WiFi/issues/688#issuecomment-3999038526
> > >
> > > The above thread is rather lengthy as we have been working on this
> > > issue since Dec. 25.
> > >
> > > Testing with a Netgear A9000 USB WiFi adapter (mt7925u driver). Kernel
> > > 7.0 rc2 and a x86_64 system. Additional testing with older kernels was
> > > also performed with the same results.
> > >
> > > Problem description:
> > >
> > > Cold boot shows the adapter coming up and operating normally.
> > >
> > > Removing the adapter from the USB port and replacing it shows the
> > > adapter coming up and operating normally.
> > >
> > > A warm reboot does not provide a WiFi interface and shows the
> > > following in the system log:
> > >
> > > mt7925u 2-3.2:1.0: probe with driver mt7925u failed with error -110
> > >
> > > Using the commands rmmod and modeprobe do not provide a WiFi interface.
> > >
> > > Thoughts: The problem likely is not the module teardown. The problem
> > > seems to be that the firmware (or the mt7925u driver) leaves the
> > > adapter in a strange state such that a power cycle of the adapter
> > > hardware is needed before the mt7925u driver can properly initialize
> > > it a second time.
> > >
> >
> > Hi Nick,
> >
> > Could you enable debug logs and check whether the driver can still
> > read the correct chip ID after a warm reboot, and at which step the
> > initialization fails before the -110 error? Thanks for continuing to
> > test and gather this useful information.
> >
> >          Sean
>
> Hi Sean,
>
> Github user @exct has performed the testing requested and provides the
> following report:
>
> mt7925u Probe Failure Debug Report
> Adapter: Netgear A9000 (USB ID 0846:9072, MediaTek MT7925)
> Kernel: 6.19.6-2-cachyos
>
> Summary
> The driver can read the correct chip ID after a warm reload. The
> failure occurs before firmware is loaded, inside
> mt792xu_wfsys_reset(), which times out waiting for the WiFi subsystem
> to reinitialize. -ETIMEDOUT (-110) is returned and the probe aborts.
>
> Findings
>
> Question: Chip ID readable after warm reload?
> Answer: Yes — MT_HW_CHIPID = 0x7925, MT_HW_REV = 0x8a00
>
> Question: Which step fails?
> Answer: mt792xu_wfsys_reset() — WFSYS_INIT_DONE never asserted
>
> Question: Does it reach mt792xu_mcu_power_on()?
> Answer: No
>
> Question: Does it reach mt7925_run_firmware()?
> Answer: No
>
> Probe Sequence Trace
>
> mt7925u_probe()
>   ├─ mt76_alloc_device()             OK
>   ├─ __mt76u_init()                  OK
>   ├─ read MT_HW_CHIPID (0x70010200)  → 0x00007925  ✓
>   ├─ read MT_HW_REV    (0x70010204)  → 0x00008a00  ✓
>   ├─ read MT_CONN_ON_MISC (0x7c0600f0) → 0x00000003  ← FW_N9_RDY is SET
>   ├─ enters mt792xu_wfsys_reset()    ← triggered because FW_N9_RDY = 1
>   │    ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST  (assert reset)
>   │    ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST  (deassert reset)
>   │    ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
>   │    ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
>   │    └─ ... timeout after ~212 ms → return -ETIMEDOUT
>   └─ goto error:  (mt76u_queues_deinit + mt76_free_device)
>
> Root Cause
>
> After rmmod, the firmware leaves FW_N9_RDY asserted in
> MT_CONN_ON_MISC. On re-probe, the driver correctly detects this and
> calls mt792xu_wfsys_reset() to recover. However, the WiFi subsystem
> never signals completion — WFSYS_INIT_DONE in
> MT_UDMA_CONN_INFRA_STATUS (reg 0x74000a20) stays 0x00000000 throughout
> the retry loop. The subsystem is stuck in a state that the software
> reset path cannot recover from. Only a full USB power cycle clears it.
>
> Hope this helps,
>
> Nick

Re: [BUG] wifi: mt76: mt7925u: probe with driver mt7925u failed with error -110

[Nick]

On Fri, Mar 6, 2026 at 6:46 PM Sean Wang <sean.wang@kernel.org> wrote:
>
> Hi Nick,
>
> Thanks for the detailed report  this is very helpful. I don't  have an
> MT7925 USB device to detail look into the issue, but based on the
> trace I wrote a small change to try a different MT7925 reset sequence.
> please help test.
>
> --- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> @@ -234,6 +234,36 @@ int mt792xu_dma_init(struct mt792x_dev *dev, bool resume)
>  }
>  EXPORT_SYMBOL_GPL(mt792xu_dma_init);
>
> +static int mt7925u_wfsys_reset(struct mt792x_dev *dev)
> +{
> +    u32 val;
> +    int i;
> +
> +#define MT7925_CBTOP_RGU_WF_SUBSYS_RST        0x70028600
> +#define MT7925_WFSYS_SW_INIT_DONE_ADDR        0x184c1604
> +#define MT7925_WFSYS_SW_INIT_DONE        0x00001d1e
> +
> +    val = mt792xu_uhw_rr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST);
> +    val |= MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH;
> +    mt792xu_uhw_wr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST, val);
> +
> +    msleep(20);
> +
> +    val = mt792xu_uhw_rr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST);
> +    val &= ~MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH;
> +    mt792xu_uhw_wr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST, val);
> +
> +    for (i = 0; i < MT792x_WFSYS_INIT_RETRY_COUNT; i++) {
> +        val = mt792xu_uhw_rr(&dev->mt76, MT7925_WFSYS_SW_INIT_DONE_ADDR);
> +        if (val == MT7925_WFSYS_SW_INIT_DONE)
> +            return 0;
> +
> +        msleep(100);
> +    }
> +
> +    return -ETIMEDOUT;
> +}
> +
>  int mt792xu_wfsys_reset(struct mt792x_dev *dev)
>  {
>      u32 val;
> @@ -241,6 +271,9 @@ int mt792xu_wfsys_reset(struct mt792x_dev *dev)
>
>      mt792xu_epctl_rst_opt(dev, false);
>
> +    if (is_mt7925(&dev->mt76))
> +        return mt7925u_wfsys_reset(dev);
> +
>      val = mt792xu_uhw_rr(&dev->mt76, MT_CBTOP_RGU_WF_SUBSYS_RST);
>
>

Sean,

Testing complete. Results are good. You can show the following:

Tested-by: Nick Morrow <morrownr@gmail.com>
Tested-by: Satadru Pramanik <satadru@gmail.com>

Thank you for working on this issue. If it is possible for your patch to go
directly in to be in one of the next rc's, that would be great and setting
it to backport would also be much appreciated.

Nick Morrow

> On Fri, Mar 6, 2026 at 1:24 PM Nick <morrownr@gmail.com> wrote:
> >
> > > > Reference: https://github.com/morrownr/USB-WiFi/issues/688#issuecomment-3999038526
> > > >
> > > > The above thread is rather lengthy as we have been working on this
> > > > issue since Dec. 25.
> > > >
> > > > Testing with a Netgear A9000 USB WiFi adapter (mt7925u driver). Kernel
> > > > 7.0 rc2 and a x86_64 system. Additional testing with older kernels was
> > > > also performed with the same results.
> > > >
> > > > Problem description:
> > > >
> > > > Cold boot shows the adapter coming up and operating normally.
> > > >
> > > > Removing the adapter from the USB port and replacing it shows the
> > > > adapter coming up and operating normally.
> > > >
> > > > A warm reboot does not provide a WiFi interface and shows the
> > > > following in the system log:
> > > >
> > > > mt7925u 2-3.2:1.0: probe with driver mt7925u failed with error -110
> > > >
> > > > Using the commands rmmod and modeprobe do not provide a WiFi interface.
> > > >
> > > > Thoughts: The problem likely is not the module teardown. The problem
> > > > seems to be that the firmware (or the mt7925u driver) leaves the
> > > > adapter in a strange state such that a power cycle of the adapter
> > > > hardware is needed before the mt7925u driver can properly initialize
> > > > it a second time.
> > > >
> > >
> > > Hi Nick,
> > >
> > > Could you enable debug logs and check whether the driver can still
> > > read the correct chip ID after a warm reboot, and at which step the
> > > initialization fails before the -110 error? Thanks for continuing to
> > > test and gather this useful information.
> > >
> > >          Sean
> >
> > Hi Sean,
> >
> > Github user @exct has performed the testing requested and provides the
> > following report:
> >
> > mt7925u Probe Failure Debug Report
> > Adapter: Netgear A9000 (USB ID 0846:9072, MediaTek MT7925)
> > Kernel: 6.19.6-2-cachyos
> >
> > Summary
> > The driver can read the correct chip ID after a warm reload. The
> > failure occurs before firmware is loaded, inside
> > mt792xu_wfsys_reset(), which times out waiting for the WiFi subsystem
> > to reinitialize. -ETIMEDOUT (-110) is returned and the probe aborts.
> >
> > Findings
> >
> > Question: Chip ID readable after warm reload?
> > Answer: Yes — MT_HW_CHIPID = 0x7925, MT_HW_REV = 0x8a00
> >
> > Question: Which step fails?
> > Answer: mt792xu_wfsys_reset() — WFSYS_INIT_DONE never asserted
> >
> > Question: Does it reach mt792xu_mcu_power_on()?
> > Answer: No
> >
> > Question: Does it reach mt7925_run_firmware()?
> > Answer: No
> >
> > Probe Sequence Trace
> >
> > mt7925u_probe()
> >   ├─ mt76_alloc_device()             OK
> >   ├─ __mt76u_init()                  OK
> >   ├─ read MT_HW_CHIPID (0x70010200)  → 0x00007925  ✓
> >   ├─ read MT_HW_REV    (0x70010204)  → 0x00008a00  ✓
> >   ├─ read MT_CONN_ON_MISC (0x7c0600f0) → 0x00000003  ← FW_N9_RDY is SET
> >   ├─ enters mt792xu_wfsys_reset()    ← triggered because FW_N9_RDY = 1
> >   │    ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST  (assert reset)
> >   │    ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST  (deassert reset)
> >   │    ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
> >   │    ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
> >   │    └─ ... timeout after ~212 ms → return -ETIMEDOUT
> >   └─ goto error:  (mt76u_queues_deinit + mt76_free_device)
> >
> > Root Cause
> >
> > After rmmod, the firmware leaves FW_N9_RDY asserted in
> > MT_CONN_ON_MISC. On re-probe, the driver correctly detects this and
> > calls mt792xu_wfsys_reset() to recover. However, the WiFi subsystem
> > never signals completion — WFSYS_INIT_DONE in
> > MT_UDMA_CONN_INFRA_STATUS (reg 0x74000a20) stays 0x00000000 throughout
> > the retry loop. The subsystem is stuck in a state that the software
> > reset path cannot recover from. Only a full USB power cycle clears it.
> >
> > Hope this helps,
> >
> > Nick

Re: [BUG] wifi: mt76: mt7925u: probe with driver mt7925u failed with error -110

[Sean Wang]

On Mon, Mar 9, 2026 at 7:31 PM Nick <morrownr@gmail.com> wrote:
>
> On Fri, Mar 6, 2026 at 6:46 PM Sean Wang <sean.wang@kernel.org> wrote:
> >
> > Hi Nick,
> >
> > Thanks for the detailed report  this is very helpful. I don't  have an
> > MT7925 USB device to detail look into the issue, but based on the
> > trace I wrote a small change to try a different MT7925 reset sequence.
> > please help test.
> >
> > --- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> > +++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> > @@ -234,6 +234,36 @@ int mt792xu_dma_init(struct mt792x_dev *dev, bool resume)
> >  }
> >  EXPORT_SYMBOL_GPL(mt792xu_dma_init);
> >
> > +static int mt7925u_wfsys_reset(struct mt792x_dev *dev)
> > +{
> > +    u32 val;
> > +    int i;
> > +
> > +#define MT7925_CBTOP_RGU_WF_SUBSYS_RST        0x70028600
> > +#define MT7925_WFSYS_SW_INIT_DONE_ADDR        0x184c1604
> > +#define MT7925_WFSYS_SW_INIT_DONE        0x00001d1e
> > +
> > +    val = mt792xu_uhw_rr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST);
> > +    val |= MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH;
> > +    mt792xu_uhw_wr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST, val);
> > +
> > +    msleep(20);
> > +
> > +    val = mt792xu_uhw_rr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST);
> > +    val &= ~MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH;
> > +    mt792xu_uhw_wr(&dev->mt76, MT7925_CBTOP_RGU_WF_SUBSYS_RST, val);
> > +
> > +    for (i = 0; i < MT792x_WFSYS_INIT_RETRY_COUNT; i++) {
> > +        val = mt792xu_uhw_rr(&dev->mt76, MT7925_WFSYS_SW_INIT_DONE_ADDR);
> > +        if (val == MT7925_WFSYS_SW_INIT_DONE)
> > +            return 0;
> > +
> > +        msleep(100);
> > +    }
> > +
> > +    return -ETIMEDOUT;
> > +}
> > +
> >  int mt792xu_wfsys_reset(struct mt792x_dev *dev)
> >  {
> >      u32 val;
> > @@ -241,6 +271,9 @@ int mt792xu_wfsys_reset(struct mt792x_dev *dev)
> >
> >      mt792xu_epctl_rst_opt(dev, false);
> >
> > +    if (is_mt7925(&dev->mt76))
> > +        return mt7925u_wfsys_reset(dev);
> > +
> >      val = mt792xu_uhw_rr(&dev->mt76, MT_CBTOP_RGU_WF_SUBSYS_RST);
> >
> >
>
> Sean,
>
> Testing complete. Results are good. You can show the following:
>
> Tested-by: Nick Morrow <morrownr@gmail.com>
> Tested-by: Satadru Pramanik <satadru@gmail.com>
>
> Thank you for working on this issue. If it is possible for your patch to go
> directly in to be in one of the next rc's, that would be great and setting
> it to backport would also be much appreciated.
>
> Nick Morrow
>

Hi Nick,

Thanks for testing!

I’ve already sent the patches upstream with a few small cosmetic
tweaks. If you have a chance to test the latest version again, that
would be great. If it still looks good, you can just reply with the
Tested-by tags below. I think we can let Johannes know if it is okay
to wireless.git directly I also CC’d stable so the fix can make its
way into the stable trees.

      Sean

> > On Fri, Mar 6, 2026 at 1:24 PM Nick <morrownr@gmail.com> wrote:
> > >
> > > > > Reference: https://github.com/morrownr/USB-WiFi/issues/688#issuecomment-3999038526
> > > > >
> > > > > The above thread is rather lengthy as we have been working on this
> > > > > issue since Dec. 25.
> > > > >
> > > > > Testing with a Netgear A9000 USB WiFi adapter (mt7925u driver). Kernel
> > > > > 7.0 rc2 and a x86_64 system. Additional testing with older kernels was
> > > > > also performed with the same results.
> > > > >
> > > > > Problem description:
> > > > >
> > > > > Cold boot shows the adapter coming up and operating normally.
> > > > >
> > > > > Removing the adapter from the USB port and replacing it shows the
> > > > > adapter coming up and operating normally.
> > > > >
> > > > > A warm reboot does not provide a WiFi interface and shows the
> > > > > following in the system log:
> > > > >
> > > > > mt7925u 2-3.2:1.0: probe with driver mt7925u failed with error -110
> > > > >
> > > > > Using the commands rmmod and modeprobe do not provide a WiFi interface.
> > > > >
> > > > > Thoughts: The problem likely is not the module teardown. The problem
> > > > > seems to be that the firmware (or the mt7925u driver) leaves the
> > > > > adapter in a strange state such that a power cycle of the adapter
> > > > > hardware is needed before the mt7925u driver can properly initialize
> > > > > it a second time.
> > > > >
> > > >
> > > > Hi Nick,
> > > >
> > > > Could you enable debug logs and check whether the driver can still
> > > > read the correct chip ID after a warm reboot, and at which step the
> > > > initialization fails before the -110 error? Thanks for continuing to
> > > > test and gather this useful information.
> > > >
> > > >          Sean
> > >
> > > Hi Sean,
> > >
> > > Github user @exct has performed the testing requested and provides the
> > > following report:
> > >
> > > mt7925u Probe Failure Debug Report
> > > Adapter: Netgear A9000 (USB ID 0846:9072, MediaTek MT7925)
> > > Kernel: 6.19.6-2-cachyos
> > >
> > > Summary
> > > The driver can read the correct chip ID after a warm reload. The
> > > failure occurs before firmware is loaded, inside
> > > mt792xu_wfsys_reset(), which times out waiting for the WiFi subsystem
> > > to reinitialize. -ETIMEDOUT (-110) is returned and the probe aborts.
> > >
> > > Findings
> > >
> > > Question: Chip ID readable after warm reload?
> > > Answer: Yes — MT_HW_CHIPID = 0x7925, MT_HW_REV = 0x8a00
> > >
> > > Question: Which step fails?
> > > Answer: mt792xu_wfsys_reset() — WFSYS_INIT_DONE never asserted
> > >
> > > Question: Does it reach mt792xu_mcu_power_on()?
> > > Answer: No
> > >
> > > Question: Does it reach mt7925_run_firmware()?
> > > Answer: No
> > >
> > > Probe Sequence Trace
> > >
> > > mt7925u_probe()
> > >   ├─ mt76_alloc_device()             OK
> > >   ├─ __mt76u_init()                  OK
> > >   ├─ read MT_HW_CHIPID (0x70010200)  → 0x00007925  ✓
> > >   ├─ read MT_HW_REV    (0x70010204)  → 0x00008a00  ✓
> > >   ├─ read MT_CONN_ON_MISC (0x7c0600f0) → 0x00000003  ← FW_N9_RDY is SET
> > >   ├─ enters mt792xu_wfsys_reset()    ← triggered because FW_N9_RDY = 1
> > >   │    ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST  (assert reset)
> > >   │    ├─ write MT_CBTOP_RGU_WF_SUBSYS_RST  (deassert reset)
> > >   │    ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
> > >   │    ├─ poll MT_UDMA_CONN_INFRA_STATUS (0x74000a20) → 0x00000000
> > >   │    └─ ... timeout after ~212 ms → return -ETIMEDOUT
> > >   └─ goto error:  (mt76u_queues_deinit + mt76_free_device)
> > >
> > > Root Cause
> > >
> > > After rmmod, the firmware leaves FW_N9_RDY asserted in
> > > MT_CONN_ON_MISC. On re-probe, the driver correctly detects this and
> > > calls mt792xu_wfsys_reset() to recover. However, the WiFi subsystem
> > > never signals completion — WFSYS_INIT_DONE in
> > > MT_UDMA_CONN_INFRA_STATUS (reg 0x74000a20) stays 0x00000000 throughout
> > > the retry loop. The subsystem is stuck in a state that the software
> > > reset path cannot recover from. Only a full USB power cycle clears it.
> > >
> > > Hope this helps,
> > >
> > > Nick