> -Original Message-
> From: ath10k On Behalf Of Wen Gong
> Sent: Wednesday, April 10, 2019 10:45 AM
> To: Brian Norris
> Cc: Michał Kazior ; linux-wireless wirel...@vger.kernel.org>; ath10k@lists.infradead.org; Wen Gong
>
> Subject: [EXT] RE
> -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
> >
> 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
>
> >
> 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 going to
> >
> -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_RESTARTED i
> -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
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
> >
> > > > 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
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:
>
13 matches
Mail list logo
