> From: Michał Kazior <kazikcz@xxxxxxxxx> > Sent: Tuesday, April 9, 2019 1:27 AM > To: Wen Gong <wgong@xxxxxxxxxxxxxxxx> > Cc: Wen Gong <wgong@xxxxxxxxxxxxxx>; linux-wireless <linux- > wireless@xxxxxxxxxxxxxxx>; ath10k@xxxxxxxxxxxxxxxxxxx > Subject: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in > simulate fw crash > > > > Hi Michal, > > > There have a stress test case for the simulate fw crash, it will simulate fw > > > crash > > > in a very short time for each test, this will trigger the stress test fail. > > > The simulate fw crash process should not be run parallel, after this patch, > the > > > Stress test case will pass. > > > > > > > > Hi Michał, > > Do you have some new comments? > > My original use case was to be able to exercise the driver's > robustness in handling nested fw crashes, IOW crash-within-a-crash. > > Your test case, as far as I understand, intends to perform > consecutive, non-nested fw crash simulation stress test. > > Both of these are mutually exclusive and your patch fixes your test > case at the expense of breaking my original case. > > To satisfy both I would suggest you either expose ar->state via > debugfs and make your test procedure wait for that to get back into ON > state before simulating a crash again, or to extend the set of current > simulate_fw_crash commands (currently just: soft, hard, assert, > hw-restart) to something that allows expressing the intent whether > crash-in-crash prevention is intended (your case) or not (my original > case). > > This could be for example something like this: > echo soft wait-ready > simulate_fw_crash > > The "wait-ready" extra keyword would imply crash-in-crash prevention. > This would keep existing tools working (both behavior and syntax) and > would allow your test case to be implemented. > Is it easy to change your existing tools? I want to change it to: echo soft skip-ready > simulate_fw_crash The "skip-ready" extra keyword would imply crash-in-crash, *not* prevention. My test tools is hard to change. > > Michał
