summaryrefslogtreecommitdiff
path: root/drivers/bcma
diff options
context:
space:
mode:
authorSujith Manoharan <c_manoha@qca.qualcomm.com>2014-09-05 08:20:57 +0400
committerJohn W. Linville <linville@tuxdriver.com>2014-09-09 23:27:22 +0400
commit367b341edbebc405d80fecd28ff973dfb7390d65 (patch)
tree3d467024f0df09bbb63bda62dbdb0adfa6aa2bd6 /drivers/bcma
parentda0162f3f0012465cc6d77c4d416fabb182713ad (diff)
downloadlinux-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')
0 files changed, 0 insertions, 0 deletions