ath9k: Fix MCC scanning
authorSujith Manoharan <c_manoha@qca.qualcomm.com>
Fri, 5 Sep 2014 04:20:57 +0000 (09:50 +0530)
committerJohn W. Linville <linville@tuxdriver.com>
Tue, 9 Sep 2014 19:27:22 +0000 (15:27 -0400)
commit367b341edbebc405d80fecd28ff973dfb7390d65
tree3d467024f0df09bbb63bda62dbdb0adfa6aa2bd6
parentda0162f3f0012465cc6d77c4d416fabb182713ad
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>
drivers/net/wireless/ath/ath9k/ath9k.h
drivers/net/wireless/ath/ath9k/channel.c