On 20/11/2020 08:12, Loic Poulain wrote:
On Fri, 20 Nov 2020 at 03:13, Bryan O'Donoghue
<bryan.odonoghue@xxxxxxxxxx> wrote:
Run scan_init only once. There's no need to run this command multiple times
if it has already been run once.
The software scan algorithm can end up repeatedly calling scan_init on each
loop resulting in between four and eight milliseconds of lost time on each
callout.
Subtract the overhead now.
This command defines parameters like the BSSID we want to inform,
etc... So this can change depending on the scan is done while
connected or not.
So you're saying a scan is started and our connection state toggles from
non-connected to connected.
Possible I guess.
Moreover in the connected case, the scans are
interleaved with normal data listening period, and AFAIU, init/stop
scan allow to submit a null data packet with PS/non-PS bit when
mac80211 leaves the operating channel to scanning another one (so that
AP does no submit packet to it). So at first glance, this patch would
break that, right?
I agree with that logic, and actually looking at downstream - we see
that downstream doesn't set the notification byte before starting a scan
on a new channel
connected:
[ 63.475897] BOD WDI_SendMsg/23794 message = 0x04 version = 0x01 len
0x00000030 // WLAN_HAL_INIT_SCAN_REQ
[ 63.475902] SMD <<< 00000000: 04 00 01 00 30 00 00 00 02 00 00 00 00
00 00 00 00 00 00 00 00 ff ff ff c8 9f 7a 21 c0 ff ff ff
[ 63.475907] SMD <<< 00000020: d4 2e 7c 00 c0 ff ff ff 00 54 93 6d c0
22 22 00
[ 63.478242] SMD >>> 00000000: 05 00 00 00 0c 00 00 00 00 00 00 00
type=04 00 version=01 00 length=30 00 00 00
mode=02 00 00 00
bssid=00 000 00 00 00 00
notify=00
...
which I accept is actually a bug downstream, conceptually at any rate.
I need to ensure a scan isn't in process when we go into suspend but,
there's no reason to skip the scan_init() command for that.
flagging != skipping
Let's forget this one.
---
bod
