[PATCH 1/2] ath10k: introduce a stricter scan state machine

[Michal Kazior]

On 29 July 2014 11:20, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> 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 at tieto.com>
>> Signed-off-by: Michal Kazior <michal.kazior at tieto.com>
>
>> +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ł