ath9k: fix regression on beacon loss after bgscan

ath9k: fix regression on beacon loss after bgscan

When we return to the home channel we were never reseting our beacon
timers, this was casued by the fact that the scanning flag was still
on even after we returned to our home channel. There are also other
reasons why we would get a reset and if we are not off channel
we always need to resynch our beacon timers, because a reset will
clear them.

This bug is a regression introduced on 2.6.36. The order of the
changes are as follows:

0d6bb758 - Sat Jul 31 - ath9k: prevent calibration during off-channel activity
4f46d1c3 - Tue Jul 27 - Revert "mac80211: fix sw scan bracketing"
b2778b9a - Fri Jun 18 - mac80211: fix sw scan bracketing

mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
        --contains 0d6bb758b012f32fafd973e5eb59b642e4187669
v2.6.36-rc1~43^2~34^2~22

mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
        --contains 4f46d1c3b259a341b37af28b2d31c45a9d3efb1f
v2.6.36-rc1~571^2~64^2~13

mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
        --contains b2778b9a86d0a57201aa14ef154bc738e0675127
v2.6.36-rc1~571^2~107^2~187

So 0d6bb758 would have worked if 4f46d1c3 was not committed but
it was so this means 0d6bb758 was broken since it assumed that
when we were in the channel change routine the scan flag would
be lifted. As it turns out the scan flag will be set when we
are already on the home channel.

For more details refer to:

http://code.google.com/p/chromium-os/issues/detail?id=5715

These issues will need to be considered for our solution on
reshifting the scan complete callback location on mac80211 on
current development kernel work.

This patch has stable fixes which apply down to [2.6.36+]

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>