diff options
author | Sujith Manoharan <c_manoha@qca.qualcomm.com> | 2014-09-05 08:20:57 +0400 |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2014-09-09 23:27:22 +0400 |
commit | 367b341edbebc405d80fecd28ff973dfb7390d65 (patch) | |
tree | 3d467024f0df09bbb63bda62dbdb0adfa6aa2bd6 /drivers/bcma/Makefile | |
parent | da0162f3f0012465cc6d77c4d416fabb182713ad (diff) | |
download | linux-367b341edbebc405d80fecd28ff973dfb7390d65.tar.xz |
ath9k: Fix MCC scanning
Scanning is curently broken when two channel contexts
are active. For example in a P2P-GO/STA setup, the
offchannel timer allows HZ / 10 to elapse before initiating
a switch to the next scan channel from the current operating
channel, which in this case would be the P2P-GO context.
But, the channel context timer might decide to switch
to the STA context when an SWBA comes early and a beacon
is sent out. Since pending offchannel requests are processed
in EVENT_BEACON_PREPARE, this causes inconsistent scanning.
Fix this by making sure that a context switch happens
before processing the pending offchannel request. This
also makes sure that active channel contexts will always
have higher priority than offchannel operations and the
scan sequence looks like this:
p2p-go, sta, p2p-go, offchannel, p2p-go, sta, p2p-go, offchannel,.....
The oper-channel is p2p-go, so the STA context has to
switch to p2p-go again before switching offchannel.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'drivers/bcma/Makefile')
0 files changed, 0 insertions, 0 deletions