> -----Original Message----- > From: Brian Norris <briannorris@xxxxxxxxxxxx> > Sent: Wednesday, April 10, 2019 7:25 AM > To: Wen Gong <wgong@xxxxxxxxxxxxxxxx> > Cc: Michał Kazior <kazikcz@xxxxxxxxx>; Wen Gong > <wgong@xxxxxxxxxxxxxx>; linux-wireless <linux-wireless@xxxxxxxxxxxxxxx>; > ath10k@xxxxxxxxxxxxxxxxxxx > Subject: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in > simulate fw crash > > On Mon, Apr 8, 2019 at 10:09 PM Wen Gong <wgong@xxxxxxxxxxxxxxxx> > wrote: > > > From: Michał Kazior <kazikcz@xxxxxxxxx> > > > 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. > > In case you're talking about the test framework we run for ChromeOS > validation, no, it's not hard at all to change. As long as there's a > good reason. > > I haven't closely followed this, but judging by the above summary, > it's probably more reasonable for our test framework to only simulate > FW crashes after the driver returns to "ready" (or at least, if we do > crash-in-crash, don't expect the driver to recover?). I expect we can > work with whatever mechanism you implement for that (exposing the > "state", or providing a new simulate_fw_crash mode). > If ChromeOS is easy to change tool, I think I will change the mechanism of the simulate_fw_crash. Then all tools will work normally. > Brian
