summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2025-04-11 11:40:54 +0300
committerJohannes Berg <johannes.berg@intel.com>2025-04-11 17:07:47 +0300
commit5f05c14e7c198415abe936514a6905f8b545b63b (patch)
treecdc7dc7de77352bf438664cec7f0fb986468ae5d /tools/perf/scripts/python
parenta0f0dc96de03ffeefc2a177b7f8acde565cb77f4 (diff)
downloadlinux-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