On 11/01/2021 12:26, Kalle Valo wrote:

Bryan O'Donoghue [off-list ref] writes:

quoted

On 11/01/2021 11:31, Kalle Valo wrote:

quoted

Bryan O'Donoghue [off-list ref] writes:

quoted

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@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