[PATCH 11/13] wcn36xx: Do not suspend if scan in progress

[Bryan O'Donoghue]

On 11/01/2021 12:26, Kalle Valo wrote:
> Bryan O'Donoghue <bryan.odonoghue at linaro.org> writes:
> 
>> On 11/01/2021 11:31, Kalle Valo wrote:
>>> Bryan O'Donoghue <bryan.odonoghue at linaro.org> writes:
>>>
>>>> If a scan is in progress do not attempt to enter into suspend. Allow the
>>>> scan process to quiesce before proceeding.
>>>>
>>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue at linaro.org>
>>>
>>> Why? I would have considered the opposite and if we go to suspend we
>>> cancel the scan. No strong feelings, just don't see the need for scan
>>> results during suspend. But of course I might be missing something...
>>
>> We need to be switched to the AP's channel when calling the suspend
>> routine. During a s/w scan we switch off channel to scan for 100s of
>> milliseconds.
>>
>> If the suspend() routine is called while that is true, we suspend on
>> the wrong channel.
>>
>> So we would need to switch to the right channel explicitly in suspend
>> but, at the moment wcn36xx_config() for switching channels and I
>> thought it best to leave the channel switching logic in the one place.
>>
>> I'm not opposed in principle to
>>
>> - Entering suspend
>> - Switching to the last known active channel
>> - Suspending
> 
> Should this be fixed in mac80211? Otherwise every driver using software
> scan needs to have a workaround for this, right?
> 

I'll check.

I thought this problem was likely specific to wcn36xx but, conceptually 
I can't argue with you there.

Given I only see this behavior on Android and not on Debian - I test 
both - where Android tends to scan constantly - it is possible I'm the 
only one really triggering the bug given most drivers don't do s/w scan 
and probably wcn36xx is the only s/w scan being used on an Android 
system close to what we have upstream.

So yeah fair point, I'll see if the fix fits better at a higher level.

---
bod