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). Brian
