Re: [RFC] ath9k: fix listening to idle requests

[Vasanthakumar Thiagarajan <vasanth@atheros.com>]

On Fri, Oct 30, 2009 at 02:22:26AM +0530, Luis Rodriguez wrote:
> The way idle configuration detection was implemented as
> busted due to the fact that it assumed the ath9k virtual wiphy,
> the aphy, would be marked as inactive if it was not used but
> it turns out an aphy is always active if its the only wiphy
> present. We need to distinguish between aphy activity and
> idleness so we now add an idle bool for the aphy and mark
> it as such based on the passed IEEE80211_CONF_CHANGE_IDLE
> from mac80211.
> 
> Previous to all_wiphys_idle would never be true when using
> only one device so we never really were using
> IEEE80211_CONF_CHANGE_IDLE -- we never turned the radio
> off or on upon IEEE80211_CONF_CHANGE_IDLE changes as radio
> changes depended on all_wiphys_idle being true either to
> turn the radio on or off. Since it was always false for
> one device this code was doing nothing.
> 
> Reported-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> 
> Vasanth, what do you think?

Still we will have issue when bringing up a sec wiphy while the
primary wiphy is in idle state. ath9k_start() does not brought up
the newly created wiphy interface when the state of at least one
previously created interface is in ACTIVE state. Unless already
brought up interfaces are put down we hit this situation whenever
we try to bring up a new secondary wiphy interface. So with this
patch the actual h/w will remain radio disabled state even after
a new interface is in active state. We need to bring the h/w into
active state if all old interfaces are in idle state in
ath9k_start(). 
 
Vasanth