RE: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in simulate fw crash

From: Wen Gong <wgong@qti.qualcomm.com>
To: Brian Norris <briannorris@chromium.org>
Cc: "Michał Kazior" <kazikcz@gmail.com>,
	"Wen Gong" <wgong@codeaurora.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	"ath10k@lists.infradead.org" <ath10k@lists.infradead.org>
Subject: RE: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in simulate fw crash
Date: Wed, 10 Apr 2019 02:45:29 +0000	[thread overview]
Message-ID: <b073fa90e9a3437c9846ce2d22fab15f@aptaiexm02f.ap.qualcomm.com> (raw)
In-Reply-To: <CA+ASDXP1Ftpi93p=Bp2w1rRd3xVtNn_+diwkKTMXbTqK0B3ahA@mail.gmail.com>

> -----Original Message-----
> From: Brian Norris <briannorris@chromium.org>
> Sent: Wednesday, April 10, 2019 7:25 AM
> To: Wen Gong <wgong@qti.qualcomm.com>
> Cc: Michał Kazior <kazikcz@gmail.com>; Wen Gong
> <wgong@codeaurora.org>; linux-wireless <linux-wireless@vger.kernel.org>;
> ath10k@lists.infradead.org
> 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@qti.qualcomm.com>
> wrote:
> > > From: Michał Kazior <kazikcz@gmail.com>
> > > 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