On 29 July 2014 11:20, Kalle Valo <[email protected]> wrote: > Michal Kazior <[email protected]> writes: > >> This aims at fixing some rare scan bugs related to >> firmware reporting unexpected scan event >> sequences. >> >> One such bug was if spectral scan phyerr reporting >> prevented firmware from properly propagating scan >> events to host. This leadsl to scan timeout. After >> that next scan would trigger scan completed event >> first (before scan started event) leading to >> ar->scan.in_progress and timeout timer states to >> be overwritten incorrectly and making the very >> next scan to hang forever. >> >> Reported-by: Janusz Dziedzic <[email protected]> >> Signed-off-by: Michal Kazior <[email protected]> > >> +enum ath10k_scan_state { >> + ATH10K_SCAN_IDLE, >> + ATH10K_SCAN_STARTING, >> + ATH10K_SCAN_RUNNING, >> + ATH10K_SCAN_RUNNING_AND_ABORTING, >> +}; > > Can't we just call the last state just as ATH10K_SCAN_ABORTING? I think > I understand why you added the word "running" there but IMHO that's not > needed.
I'll change that. >> @@ -2323,8 +2348,6 @@ void ath10k_halt(struct ath10k *ar) >> ath10k_monitor_stop(ar); >> } >> >> - del_timer_sync(&ar->scan.timeout); >> - ath10k_reset_scan((unsigned long)ar); >> ath10k_peer_cleanup_all(ar); >> ath10k_core_stop(ar); >> ath10k_hif_power_down(ar); > > Why you don't call ath10k_scan_reset() here? I would have assumed that > you do that. Hmm.. Good catch. Anyway I need to work on this patch a little bit more and fix another corner case. Michał _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
