diff options
author | Johannes Berg <johannes.berg@intel.com> | 2025-04-11 11:40:54 +0300 |
---|---|---|
committer | Johannes Berg <johannes.berg@intel.com> | 2025-04-11 17:07:47 +0300 |
commit | 5f05c14e7c198415abe936514a6905f8b545b63b (patch) | |
tree | cdc7dc7de77352bf438664cec7f0fb986468ae5d /tools/perf/scripts/python | |
parent | a0f0dc96de03ffeefc2a177b7f8acde565cb77f4 (diff) | |
download | linux-5f05c14e7c198415abe936514a6905f8b545b63b.tar.xz |
wifi: iwlwifi: pcie: set state to no-FW before reset handshake
The reset handshake attempts to kill the firmware, and it'll go
into a pretty much dead state once we do that. However, if it
times out, then we'll attempt to dump the firmware to be able
to see why it didn't respond. During this dump, we cannot treat
it as if it was still running, since we just tried to kill it,
otherwise dumping will attempt to send a DBGC stop command. As
this command will time out, we'll go into a reset loop.
For now, fix this by setting the trans->state to say firmware
isn't running before doing the reset handshake. In the longer
term, we should clean up the way this state is handled.
It's not entirely clear but it seems likely that this issue was
introduced by my rework of the error handling, prior to that it
would've been synchronous at that point and (I think) not have
attempted to reset since it was already doing down.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219967
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219968
Fixes: 7391b2a4f7db ("wifi: iwlwifi: rework firmware error handling")
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250411104054.63aa4f56894d.Ife70cfe997db03f0d07fdef2b164695739a05a63@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions