Michal Kazior <michal.kazior@xxxxxxxxx> 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 <janusz.dziedzic@xxxxxxxxx>
> Signed-off-by: Michal Kazior <michal.kazior@xxxxxxxxx>
> +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.
> @@ -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.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
