From: Zong-Zhe Yang <[email protected]>
The usage of fw_crash debugfs is to write 1 to it to trigger fw crash
simulation and to read from it to check the state. When zero is read,
it is supposed to mean fw crash/restart process is done. Then, some
test plans can be designed for crash/restart.
e.g.
step 1. trigger fw crash simulation
step 2. poll the state until zero is read
step 3. check connection by ping test
However, in certain connection cases, triggering fw crash simulation
will take a while. If the state is queried too early before restart
begins processing, it may mistakenly think restart process has been
done. If some tests are started at this time, something unexpected
might happen due to the follow-up restart process.
To avoid that, let fw_crash also show non-zero when a simulation
is still triggering.
Signed-off-by: Zong-Zhe Yang <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
---
v2: modify title and commit log to have better explanation.
---
drivers/net/wireless/realtek/rtw88/debug.c | 5 ++++-
drivers/net/wireless/realtek/rtw88/main.c | 1 +
drivers/net/wireless/realtek/rtw88/main.h | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtw88/debug.c b/drivers/net/wireless/realtek/rtw88/debug.c
index babf7fb238cc..682b23502e6e 100644
--- a/drivers/net/wireless/realtek/rtw88/debug.c
+++ b/drivers/net/wireless/realtek/rtw88/debug.c
@@ -886,6 +886,7 @@ static ssize_t rtw_debugfs_set_fw_crash(struct file *filp,
mutex_lock(&rtwdev->mutex);
rtw_leave_lps_deep(rtwdev);
+ set_bit(RTW_FLAG_RESTART_TRIGGERING, rtwdev->flags);
rtw_write8(rtwdev, REG_HRCV_MSG, 1);
mutex_unlock(&rtwdev->mutex);
@@ -897,7 +898,9 @@ static int rtw_debugfs_get_fw_crash(struct seq_file *m, void *v)
struct rtw_debugfs_priv *debugfs_priv = m->private;
struct rtw_dev *rtwdev = debugfs_priv->rtwdev;
- seq_printf(m, "%d\n", test_bit(RTW_FLAG_RESTARTING, rtwdev->flags));
+ seq_printf(m, "%d\n",
+ test_bit(RTW_FLAG_RESTART_TRIGGERING, rtwdev->flags) ||
+ test_bit(RTW_FLAG_RESTARTING, rtwdev->flags));
return 0;
}
diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index cee2acabb042..a0d4d6e31fb4 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -564,6 +564,7 @@ static void __fw_recovery_work(struct rtw_dev *rtwdev)
int ret = 0;
set_bit(RTW_FLAG_RESTARTING, rtwdev->flags);
+ clear_bit(RTW_FLAG_RESTART_TRIGGERING, rtwdev->flags);
ret = rtw_fwcd_prep(rtwdev);
if (ret)
diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wireless/realtek/rtw88/main.h
index 723316347876..bbdd535b64e7 100644
--- a/drivers/net/wireless/realtek/rtw88/main.h
+++ b/drivers/net/wireless/realtek/rtw88/main.h
@@ -363,6 +363,7 @@ enum rtw_flags {
RTW_FLAG_BUSY_TRAFFIC,
RTW_FLAG_WOWLAN,
RTW_FLAG_RESTARTING,
+ RTW_FLAG_RESTART_TRIGGERING,
NUM_OF_RTW_FLAGS,
};
--
2.25.1
Ping-Ke Shih <[email protected]> wrote:
> From: Zong-Zhe Yang <[email protected]>
>
> The usage of fw_crash debugfs is to write 1 to it to trigger fw crash
> simulation and to read from it to check the state. When zero is read,
> it is supposed to mean fw crash/restart process is done. Then, some
> test plans can be designed for crash/restart.
> e.g.
> step 1. trigger fw crash simulation
> step 2. poll the state until zero is read
> step 3. check connection by ping test
>
> However, in certain connection cases, triggering fw crash simulation
> will take a while. If the state is queried too early before restart
> begins processing, it may mistakenly think restart process has been
> done. If some tests are started at this time, something unexpected
> might happen due to the follow-up restart process.
>
> To avoid that, let fw_crash also show non-zero when a simulation
> is still triggering.
>
> Signed-off-by: Zong-Zhe Yang <[email protected]>
> Signed-off-by: Ping-Ke Shih <[email protected]>
Patch applied to wireless-drivers-next.git, thanks.
6cd4b59ddb1a rtw88: refine fw_crash debugfs to show non-zero while triggering
--
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches