Re: [PATCH v2 2/2] wifi: rtw88: ps: Trigger firmware recovery when failing to leave LPS state

[Luka Gejak]

Hi Kalpesh,

Thanks for the patch. I know this is already applied, but I have two
comments.

November 3, 2026 at 4:14 AM, "Kalpesh Solanki" <skalpesh942@xxxxxxxxx> wrote:

> diff --git a/drivers/net/wireless/realtek/rtw88/ps.c b/drivers/net/wireless/realtek/rtw88/ps.c
> index add5a20b8432..8dba60f3464c 100644
> --- a/drivers/net/wireless/realtek/rtw88/ps.c
> +++ b/drivers/net/wireless/realtek/rtw88/ps.c
> @@ -166,6 +166,7 @@ static void rtw_fw_leave_lps_check(struct rtw_dev *rtwdev)
>               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_recovery(rtwdev);
>       }
>  }

As far as I can see, this timeout doesn't always mean the firmware is
stuck. The comment in __rtw_fw_leave_lps_check_reg() says REG_TCR is
only restored once the AP has acked the null frame, and 3a2dd6b7cadf
("rtw88: check firmware leave lps successfully") says that frame can
take much longer in a noisy environment. That is why the old code just
cleared the bit and warned.

So if I read it right, a busy channel or a weak link now ends in the
WARN() in __fw_recovery_work() and a full ieee80211_restart_hw(). The
watchdog leaves LPS every two seconds on an idle link, and
BCN_FILTER_NOTIFY_BEACON_LOSS leaves it right when the AP may be gone.
This also reaches USB and SDIO now, which had no way to trigger
rtw_fw_recovery() before.

rtw89 only recovers after RTW89_PS_HANG_MAX_CNT failures in a row.
Would you be willing to send a follow up that does the same here?

There also seems to be a path where the recovery never completes.
rtw_leave_lps() also runs from ieee80211_set_disassoc() through
rtw_recalc_lps(). If the check times out there while the last interface
goes down, or on a suspend without WoWLAN, the queued work runs before
drv_stop(). mac80211 then never calls drv_reconfig_complete() with
IEEE80211_RECONFIG_TYPE_RESTART, so RTW_FLAG_RESTARTING stays set and
rtw_fw_recovery() does nothing until the driver is reloaded, also for
real firmware crashes. Maybe rtw_ops_stop() could clear it as well?

Best regards,
Luka Gejak