On 11/01/2021 12:26, Kalle Valo wrote:
Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx> writes:
On 11/01/2021 11:31, Kalle Valo wrote:
Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx> 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@xxxxxxxxxx>
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
