[PATCH v3 0/2] wifi: rtw88: firmware recovery fixes and LPS hang handling

[PATCH v3 0/2] wifi: rtw88: firmware recovery fixes and LPS hang handling

[Kalpesh Solanki]

This series addresses firmware recovery issues in rtw88.

Patch 1/2 from the v2 series (DMI quirk for HP Laptop 15s-fr5xxx) was
already applied to rtw-next. In this v3 series, patch 2/2 is replaced
and an additional fix is included based on feedback from Luka Gejak:

1. Patch 1/2 clears RTW_FLAG_RESTARTING in rtw_ops_stop() to fix a
   pre-existing bug where recovery remains permanently disabled if the
   interface is stopped or suspended before drv_reconfig_complete() is
   called.

2. Patch 2/2 replaces the previous LPS leave recovery change: instead
   of immediately triggering hardware restart on a single timeout (which
   causes spurious resets on noisy links or beacon loss), it introduces
   a consecutive hang counter (RTW_PS_HANG_MAX_CNT = 3) matching rtw89.
   The counter is reset on success and in rtw_core_start().

Changes in v3:
- Note: v2 patch 1/2 (DMI quirk) is already applied in rtw-next.
- Add patch 1/2 to clear RTW_FLAG_RESTARTING in rtw_ops_stop()
  with Fixes tag.
- In patch 2/2:
  - Count consecutive failures before triggering recovery
    (RTW_PS_HANG_MAX_CNT = 3).
  - Reset ps_hang_cnt on successful LPS leave and in rtw_core_start().
  - Suppress raw register dump on transient failures to avoid log spam.

Kalpesh Solanki (2):
  wifi: rtw88: clear RTW_FLAG_RESTARTING in rtw_ops_stop()
  wifi: rtw88: ps: trigger firmware recovery only after consecutive LPS
    leave failures

 drivers/net/wireless/realtek/rtw88/mac80211.c | 1 +
 drivers/net/wireless/realtek/rtw88/main.c     | 2 ++
 drivers/net/wireless/realtek/rtw88/main.h     | 1 +
 drivers/net/wireless/realtek/rtw88/ps.c       | 9 ++++++++-
 drivers/net/wireless/realtek/rtw88/ps.h       | 1 +
 5 files changed, 13 insertions(+), 1 deletion(-)

-- 
2.53.0

[PATCH v3 1/2] wifi: rtw88: clear RTW_FLAG_RESTARTING in rtw_ops_stop()

[Kalpesh Solanki]

When mac80211 stops or suspends the device without WoWLAN,
drv_reconfig_complete() is never invoked with
IEEE80211_RECONFIG_TYPE_RESTART. If firmware recovery was queued or
running during this transition, RTW_FLAG_RESTARTING remains set
permanently, preventing all subsequent firmware recoveries until the
driver is reloaded.

Clear RTW_FLAG_RESTARTING in rtw_ops_stop() so that the driver always
starts with a clean recovery state when the interface is brought back
up.

Fixes: 5c831644e1f4 ("rtw88: handle and recover when firmware crash")
Cc: stable@vger.kernel.org
Signed-off-by: Kalpesh Solanki <skalpesh942@gmail.com>
---
v3:
 - New patch in v3 addressing the pre-existing RTW_FLAG_RESTARTING gap.

 drivers/net/wireless/realtek/rtw88/mac80211.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c
index 5e40cf06a9e..7c86da9e939 100644
--- a/drivers/net/wireless/realtek/rtw88/mac80211.c
+++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
@@ -67,6 +67,7 @@ static void rtw_ops_stop(struct ieee80211_hw *hw, bool suspend)
 	struct rtw_dev *rtwdev = hw->priv;
 
 	mutex_lock(&rtwdev->mutex);
+	clear_bit(RTW_FLAG_RESTARTING, rtwdev->flags);
 	rtw_core_stop(rtwdev);
 	mutex_unlock(&rtwdev->mutex);
 }
-- 
2.53.0

Re: [PATCH v3 1/2] wifi: rtw88: clear RTW_FLAG_RESTARTING in rtw_ops_stop()

[Luka Gejak]

Hi Kalpesh,

Thanks for the new version. One comment below.

November 8, 2026 at 9:51 AM, "Kalpesh Solanki" <skalpesh942@gmail.com> wrote:

> diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c
> index 5e40cf06a9e3..7c86da9e9396 100644
> --- a/drivers/net/wireless/realtek/rtw88/mac80211.c
> +++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
> @@ -67,6 +67,7 @@ static void rtw_ops_stop(struct ieee80211_hw *hw, bool suspend)
>       struct rtw_dev *rtwdev = hw->priv;
>
>       mutex_lock(&rtwdev->mutex);
> +     clear_bit(RTW_FLAG_RESTARTING, rtwdev->flags);
>       rtw_core_stop(rtwdev);
>       mutex_unlock(&rtwdev->mutex);
>  }

As far as I can see one case still doesn't get here, and I missed it
when I suggested rtw_ops_stop(). If the restart fails in drv_start(),
local->started is false by the time
cfg80211_shutdown_all_interfaces() closes the interfaces, so drv_stop()
returns early:

        if (WARN_ON(!local->started))
                return;

So the flag stays set after a failed restart, which seems a likely way
for a recovery to end on hardware that is really stuck. The next time
the interface comes up, recovery would stay blocked until it is stopped
again. Maybe rtw_ops_start() could clear it as well when
rtw_core_start() fails?

Best regards,
Luka Gejak

[PATCH v3 2/2] wifi: rtw88: ps: trigger firmware recovery only after consecutive LPS leave failures

[Kalpesh Solanki]

A single timeout in rtw_fw_leave_lps_check() does not always indicate a
frozen firmware; in noisy RF environments or during beacon loss, the
802.11 null data frame ACK can be delayed or dropped. Immediately
triggering firmware recovery and a full hardware restart on a single
timeout causes unnecessary disconnections and kernel warning traces on
idle links.

Follow rtw89 by introducing a consecutive failure counter (ps_hang_cnt)
and only triggering rtw_fw_recovery() after RTW_PS_HANG_MAX_CNT (3)
consecutive failures. Reset the counter to 0 on every successful LPS
leave and in rtw_core_start() so that cold starts and hardware restarts
always begin with a clean slate. Suppress raw register dumps on
transient failures to prevent log flooding.

Signed-off-by: Kalpesh Solanki <skalpesh942@gmail.com>
---
v3:
 - Replace previous single-timeout recovery with consecutive failure counter
   (RTW_PS_HANG_MAX_CNT = 3), mirroring rtw89.
 - Reset ps_hang_cnt on successful LPS leave and in rtw_core_start().
 - Suppress debug dump on transient failures to prevent log spam.
v2:
 - Rebase onto rtw-next.

 drivers/net/wireless/realtek/rtw88/main.c | 2 ++
 drivers/net/wireless/realtek/rtw88/main.h | 1 +
 drivers/net/wireless/realtek/rtw88/ps.c   | 9 ++++++++-
 drivers/net/wireless/realtek/rtw88/ps.h   | 1 +
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index f7708ad17b6..0aabd4e273e 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -1531,6 +1531,8 @@ int rtw_core_start(struct rtw_dev *rtwdev)
 
 	set_bit(RTW_FLAG_RUNNING, rtwdev->flags);
 
+	rtwdev->ps_hang_cnt = 0;
+
 	return 0;
 }
 
diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wireless/realtek/rtw88/main.h
index 6ecbeb4ffe4..525f17590ad 100644
--- a/drivers/net/wireless/realtek/rtw88/main.h
+++ b/drivers/net/wireless/realtek/rtw88/main.h
@@ -2113,6 +2113,7 @@ struct rtw_dev {
 	/* lps power state & handler work */
 	struct rtw_lps_conf lps_conf;
 	bool ps_enabled;
+	u8 ps_hang_cnt;
 	bool beacon_loss;
 	struct completion lps_leave_check;
 
diff --git a/drivers/net/wireless/realtek/rtw88/ps.c b/drivers/net/wireless/realtek/rtw88/ps.c
index add5a20b843..864e2be243e 100644
--- a/drivers/net/wireless/realtek/rtw88/ps.c
+++ b/drivers/net/wireless/realtek/rtw88/ps.c
@@ -165,7 +165,14 @@ static void rtw_fw_leave_lps_check(struct rtw_dev *rtwdev)
 	if (ret) {
 		rtw_write32_clr(rtwdev, REG_TCR, BIT_PWRMGT_HWDATA_EN);
 		rtw_warn(rtwdev, "firmware failed to leave lps state\n");
-		rtw_fw_dump_dbg_info(rtwdev);
+
+		rtwdev->ps_hang_cnt++;
+		if (rtwdev->ps_hang_cnt >= RTW_PS_HANG_MAX_CNT) {
+			rtw_fw_dump_dbg_info(rtwdev);
+			rtw_fw_recovery(rtwdev);
+		}
+	} else {
+		rtwdev->ps_hang_cnt = 0;
 	}
 }
 
diff --git a/drivers/net/wireless/realtek/rtw88/ps.h b/drivers/net/wireless/realtek/rtw88/ps.h
index 5ae83d2526c..b088fad7cd8 100644
--- a/drivers/net/wireless/realtek/rtw88/ps.h
+++ b/drivers/net/wireless/realtek/rtw88/ps.h
@@ -14,6 +14,7 @@
 
 #define LEAVE_LPS_TRY_CNT	5
 #define LEAVE_LPS_TIMEOUT	msecs_to_jiffies(100)
+#define RTW_PS_HANG_MAX_CNT	3
 
 int rtw_enter_ips(struct rtw_dev *rtwdev);
 int rtw_leave_ips(struct rtw_dev *rtwdev);
-- 
2.53.0

Re: [PATCH v3 2/2] wifi: rtw88: ps: trigger firmware recovery only after consecutive LPS leave failures

[Luka Gejak]

Hi Kalpesh,

I also have a couple of comments for this patch.

November 8, 2026 at 9:51 AM, "Kalpesh Solanki" <skalpesh942@gmail.com> wrote:

> diff --git a/drivers/net/wireless/realtek/rtw88/ps.c b/drivers/net/wireless/realtek/rtw88/ps.c
> index add5a20b8432..864e2be243ea 100644
> --- a/drivers/net/wireless/realtek/rtw88/ps.c
> +++ b/drivers/net/wireless/realtek/rtw88/ps.c
> @@ -165,7 +165,14 @@ static void rtw_fw_leave_lps_check(struct rtw_dev *rtwdev)
>       if (ret) {
>               rtw_write32_clr(rtwdev, REG_TCR, BIT_PWRMGT_HWDATA_EN);
>               rtw_warn(rtwdev, "firmware failed to leave lps state\n");
> -             rtw_fw_dump_dbg_info(rtwdev);

rtw_fw_dump_dbg_info() returns right away unless RTW_DBG_FW is set, so I
don't think it can flood the log in normal use, and the rtw_warn() above
still prints on every failure. With that debug mask on, the dump from
the first failure seems useful too. Could it stay where it was?

> +
> +             rtwdev->ps_hang_cnt++;
> +             if (rtwdev->ps_hang_cnt >= RTW_PS_HANG_MAX_CNT) {
> +                     rtw_fw_dump_dbg_info(rtwdev);
> +                     rtw_fw_recovery(rtwdev);

This still reaches USB and SDIO, and as far as I can see
__fw_recovery_work() can't run there yet. It clears the keys from an
atomic iterator:

        __fw_recovery_work()
          rtw_iterate_keys_atomic()
            ieee80211_iter_keys_atomic()    /* holds local->key_lock */
              rtw_reset_key_iter()
                rtw_sec_clear_cam()
                  rtw_write32()

On USB that write ends in usb_control_msg() and on SDIO it needs
sdio_claim_host(), so I think both sleep with the spinlock held.
78d5bf925f30 ("wifi: rtw88: iterate over vif/sta list non-atomically")
moved other iterators away from this for USB, but until now nothing
outside PCI could get to the recovery code.

Would it be ok to only call rtw_fw_recovery() on PCI for now, with a
rtw_hci_type() check? USB and SDIO never had this recovery anyway.

This can also run during a disconnect. ieee80211_set_disassoc() leaves
LPS before it removes the AP station, so if that is the third failure,
the recovery work can remove the station first and rtw_ops_sta_remove()
then removes it again. If I read it right, sta_cnt underflows and
si->mask is freed twice if a bitrate mask was set. Maybe
rtw_sta_remove() could skip a station that was already reset?

Best regards,
Luka Gejak