: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in
> simulate fw crash
>
> 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.
>
New patch uploaded
https://patchwork.kernel.org/patch/10897587/
[v2] ath10k: Remove ATH10K_STATE_RESTARTED in simulate fw crash
> -Original Message-
> From: Brian Norris
> Sent: Wednesday, April 10, 2019 7:25 AM
> To: Wen Gong
> Cc: Michał Kazior ; Wen Gong
> ; linux-wireless ;
> ath10k@lists.infradead.org
> Subject: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in
> simulate
On Mon, Apr 8, 2019 at 10:09 PM Wen Gong wrote:
> > From: Michał Kazior
> > 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
> > sim
> From: Michał Kazior
> Sent: Tuesday, April 9, 2019 1:27 AM
> To: Wen Gong
> Cc: Wen Gong ; linux-wireless wirel...@vger.kernel.org>; ath10k@lists.infradead.org
> Subject: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in
> simulate fw crash
>
> > &
.org
> > Subject: RE: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in
> > simulate fw crash
> >
> > >
> > > If it's still bothering you then please consider a crash counter
> > > threshold so that, e.g. after 5 crash-while-restarting it's
> -Original Message-
> From: Wen Gong
> Sent: Monday, April 1, 2019 2:11 PM
> To: 'Michał Kazior'
> Cc: Wen Gong ; linux-wireless wirel...@vger.kernel.org>; ath10k@lists.infradead.org
> Subject: RE: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_R
> -Original Message-
> From: Michał Kazior
> Sent: Monday, January 7, 2019 4:36 PM
> To: Wen Gong
> Cc: Wen Gong ; linux-wireless wirel...@vger.kernel.org>; ath10k@lists.infradead.org
> Subject: [EXT] Re: [PATCH] ath10k: Remove ATH10K_STATE_RESTARTED in
> si
Kalle Valo writes:
>> This change's purpose is to disallow user to trigger fw crash if the fw is
>> not in a
>> Normal state.
>>
>> If the fw is in recovering state triggered by user's command or by fw, then
>> it will
>> disallow user to run command to trigger fw crash again until fw become to
Wen Gong writes:
>> > > > It is because the state has not changed to ATH10K_STATE_ON
>> > > > immediately, then it will have more than two simulate crash
>> > > > process running meanwhile, and complete/wakeup some field twice,
>> > > > it destroy the normal recovery process.
>> > >
>> > > This w
> >
> > > > It is because the state has not changed to ATH10K_STATE_ON
> > > > immediately, then it will have more than two simulate crash
> > > > process running meanwhile, and complete/wakeup some field twice,
> > > > it destroy the normal recovery process.
> > >
> > > This was intended to allow
On Mon, 7 Jan 2019 at 08:16, Wen Gong wrote:
>
> > > It is because the state has not changed to ATH10K_STATE_ON
> > > immediately, then it will have more than two simulate crash process
> > > running meanwhile, and complete/wakeup some field twice, it destroy
> > > the normal recovery process.
> >
> > It is because the state has not changed to ATH10K_STATE_ON
> > immediately, then it will have more than two simulate crash process
> > running meanwhile, and complete/wakeup some field twice, it destroy
> > the normal recovery process.
>
> This was intended to allow testing not only firmware c
On Wed, 14 Nov 2018 at 03:51, Wen Gong wrote:
>
> When test simulate firmware crash, it is easy to trigger error.
> command:
> echo soft > /sys/kernel/debug/ieee80211/phyxx/ath10k/simulate_fw_crash.
>
> If input more than two times continuously, then it will have error.
> Error message:
> ath10k_p
When test simulate firmware crash, it is easy to trigger error.
command:
echo soft > /sys/kernel/debug/ieee80211/phyxx/ath10k/simulate_fw_crash.
If input more than two times continuously, then it will have error.
Error message:
ath10k_pci :02:00.0: failed to set vdev 1 RX wake policy: -108
ath
14 matches
Mail list logo
