[PATCH 1/2] mt76: connac: fix txpower_cur not updated in mt76_connac_mcu_set_rate_txpower()

[Sean Wang]

On Wed, Mar 11, 2026 at 3:58 PM bryam vargas
<bryamestebanvargas at gmail.com> wrote:
>
> From 9fabc33e722f321b4048ada6d4667ddacbb1495a Mon Sep 17 00:00:00 2001
> From: bryam <bryamestebanvargas at gmail.com>
> Date: Mon, 9 Mar 2026 12:25:37 -0500
> Subject: [PATCH v2 2/2] mt76: mt7921u: trigger USB reset only on wfsys timeout
>
> Instead of unconditionally scheduling a USB device reset at the start
> of the reset sequence, trigger it only when mt792xu_wfsys_reset()
> returns -ETIMEDOUT, which indicates the chip is in a latched state
> (SEFI - Single Event Functional Interrupt) where register writes over

how do you know that `-ETIMEDOUT` means the chip entered a latched
state or a SEFI condition?

> USB become silent no-ops.
>
> This avoids the race condition where usb_queue_reset_device() was
> scheduled asynchronously while the driver continued normal reset
> operations on the same device.
>
> Tested-on: Minisforum NAB9 (MT7921U USB adapter) at 2400m altitude,
>            Bogota, Colombia. Cosmic radiation causes periodic SEFI
>            events; USB reset restores connectivity without intervention.
>
> Signed-off-by: Bryam Vargas <bryamestebanvargas at gmail.com>
> ---
>  .../net/wireless/mediatek/mt76/mt7921/usb.c   | 32 +++++++++----------
>  .../net/wireless/mediatek/mt76/mt792x_usb.c   | 16 ++++------
>  2 files changed, 23 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
> b/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
> index 8c8c78f..44c7437 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7921/usb.c
> @@ -86,33 +86,33 @@ static int mt7921u_mcu_init(struct mt792x_dev *dev)
>
>  static int mt7921u_mac_reset(struct mt792x_dev *dev)
>  {
> -    struct usb_interface *intf = to_usb_interface(dev->mt76.dev);
>      int err;
>
>      mt76_txq_schedule_all(&dev->mphy);
>      mt76_worker_disable(&dev->mt76.tx_worker);
> -
>      set_bit(MT76_RESET, &dev->mphy.state);
>      set_bit(MT76_MCU_RESET, &dev->mphy.state);
> -
>      wake_up(&dev->mt76.mcu.wait);
>      skb_queue_purge(&dev->mt76.mcu.res_q);
> -
>      mt76u_stop_rx(&dev->mt76);
>      mt76u_stop_tx(&dev->mt76);
>
> -    /* When the chip enters a latched state (SEFI - Single Event
> -     * Functional Interrupt, e.g. from cosmic radiation at altitude),
> -     * all register writes over USB become silent no-ops.
> -     * usb_queue_reset_device() electrically resets the chip via the
> -     * USB hub regardless of internal state -- identical to probe().
> -     * Async variant required to avoid deadlock in workqueue context.
> -     */
> -    dev_warn(dev->mt76.dev,
> -         "mt7921u: scheduling USB reset for chip recovery\n");
> -    usb_queue_reset_device(intf);
> -

I also cannot find these changes in the current codebase. What tree
did you build this patch on?

> -    mt792xu_wfsys_reset(dev);
> +    err = mt792xu_wfsys_reset(dev);
> +    if (err == -ETIMEDOUT) {
> +        /* Chip is in a latched state (SEFI - Single Event Functional
> +         * Interrupt, e.g. from cosmic radiation at altitude).
> +         * Register writes over USB become silent no-ops; schedule an
> +         * electrical USB reset via the hub as last resort.
> +         * usb_queue_reset_device() is async to avoid deadlock in
> +         * workqueue context.

The comment does not make sense to me. A timeout in
`mt792xu_wfsys_reset()` is not sufficient evidence to conclude the
device is in a latched state, and definitely not enough to attribute
it to SEFI or cosmic radiation.

> +         */
> +        struct usb_interface *intf = to_usb_interface(dev->mt76.dev);
> +
> +        dev_warn(dev->mt76.dev,
> +             "mt7921u: wfsys reset timed out, scheduling USB reset\n");
> +        usb_queue_reset_device(intf);

That is not the way I suggested. This also still keeps the same
fundamental problem from v1. usb_queue_reset_device() is asynchronous
and you are still injecting a USB-level reset into an ongoing reset
flow to interfere with the MAC reset recovery path. Gating it on
-ETIMEDOUT changes when it happens, but does not eliminate the race
itself.

I do not think we should add this recovery path without first
understanding the actual failure. In some cases this may not even be a
device reset issue, but a USB bus/topology stability issue,  Suggest
file a bug with complete logs and reproduction details first.

> +        goto out;
> +    }
>
>      clear_bit(MT76_MCU_RESET, &dev->mphy.state);
>      err = mt76u_resume_rx(&dev->mt76);
> diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> index cfd385e..4737384 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> @@ -269,7 +269,6 @@ EXPORT_SYMBOL_GPL(mt792xu_wfsys_reset);
>
>  int mt792xu_init_reset(struct mt792x_dev *dev)
>  {
> -    struct usb_interface *intf = to_usb_interface(dev->mt76.dev);
>
>      set_bit(MT76_RESET, &dev->mphy.state);
>
> @@ -279,15 +278,14 @@ int mt792xu_init_reset(struct mt792x_dev *dev)
>      mt76u_stop_rx(&dev->mt76);
>      mt76u_stop_tx(&dev->mt76);
>
> -    /* Same rationale as mt7921u_mac_reset(): if the chip is in a
> -     * latched state (SEFI), register writes over USB are no-ops.
> -     * Schedule a USB port reset before software reset sequence.
> -     */
> -    dev_warn(dev->mt76.dev,
> -         "mt7921u: scheduling USB device reset (init_reset path)\n");
> -    usb_queue_reset_device(intf);
> +    if (mt792xu_wfsys_reset(dev) == -ETIMEDOUT) {
> +        struct usb_interface *intf = to_usb_interface(dev->mt76.dev);
> +
> +        dev_warn(dev->mt76.dev,
> +             "mt792xu: wfsys reset timed out, scheduling USB reset\n");
> +        usb_queue_reset_device(intf);
> +    }
>
> -    mt792xu_wfsys_reset(dev);
>
>      clear_bit(MT76_RESET, &dev->mphy.state);
>
> --
> 2.43.0