On Thu, Dec 16, 2010 at 9:44 AM, Luis R. Rodriguez
<lrodriguez@xxxxxxxxxxx> wrote:
> On Thu, Dec 16, 2010 at 08:02:27AM -0800, Paul Stewart wrote:
>> On Thu, Dec 16, 2010 at 4:53 AM, Johannes Berg
>> <johannes@xxxxxxxxxxxxxxxx> wrote:
>> > On Thu, 2010-12-16 at 04:46 -0800, Paul Stewart wrote:
>> > Not really -- the driver may throw away all internal state, mac80211
>> > will (attempt to) restore it all through drv_config() with changed = ~0.
>> > Evidently ath9k has some magic that makes this fail?
>>
>> The magic in question is as follows (ath9k_config()):
>>
>> Â Â if (changed & IEEE80211_CONF_CHANGE_IDLE) {
>> Â Â Â Â bool enable_radio;
>> Â Â Â Â bool all_wiphys_idle;
>> Â Â Â Â bool idle = !!(conf->flags & IEEE80211_CONF_IDLE);
>>
>> Â Â Â Â spin_lock_bh(&sc->wiphy_lock);
>> Â Â Â Â all_wiphys_idle = Âath9k_all_wiphys_idle(sc);
>> Â Â Â Âath9k_set_wiphy_idle(aphy, idle);
>>
>> Â Â Â Â enable_radio = (!idle && all_wiphys_idle);
>>
>> Â Â Â Â /*
>> Â Â Â Â Â* After we unlock here its possible another wiphy
>> Â Â Â Â Â* can be re-renabled so to account for that we will
>> Â Â Â Â Â* only disable the radio toward the end of this routine
>> Â Â Â Â Â* if by then all wiphys are still idle.
>> Â Â Â Â Â*/
>> Â Â Â Â spin_unlock_bh(&sc->wiphy_lock);
>>
>> Â Â Â Â if (enable_radio) {
>> Â Â Â Â Â Â sc->ps_idle = false;
>> Â Â Â Â Â Â ath_radio_enable(sc, hw);
>> Â Â Â Â Â Â ath_dbg(common, ATH_DBG_CONFIG,
>> Â Â Â Â Â Â Â Â Â Â "not-idle: enabling radio\n");
>> Â Â Â Â }
>> Â Â }
>>
>> So, ath9k enables and disables the radio based on ps_idle (the
>> internal state), but that's not re-evaluated unless the wiphys
>> actually change. ÂIn this case they do not change because ath9k was
>> never informed that the wiphy went idle (all_wiphys_idle evaluates to
>> false). ÂOne solution would be to do an ah9k_set_wiphy_idle(aphy,
>> true) in ath9k_stop() instead of Luis' previous suggestion of setting
>> sc->ps_idle directly. ÂPerhaps in January when I return from vacation
>> I'll test this to make sure that performs as intended in the
>> suspend-resume-while-associated case. ÂIt's a little bit of a lie to
>> do it in this case since in fact as far as mac80211 is concerned, the
>> wiphy is not idle in this case.
>
> Try this:
>
> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> index c68205d..3de3dbf 100644
> --- a/drivers/net/wireless/ath/ath9k/main.c
> +++ b/drivers/net/wireless/ath/ath9k/main.c
> @@ -1350,6 +1350,7 @@ static void ath9k_stop(struct ieee80211_hw *hw)
> Â Â Â Âath9k_ps_restore(sc);
>
> Â Â Â Âsc->ps_idle = true;
> + Â Â Â ath9k_set_wiphy_idle(aphy, true);
> Â Â Â Âath_radio_disable(sc, hw);
>
> Â Â Â Âsc->sc_flags |= SC_OP_INVALID;
> diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
> index 7ca8499..4538283 100644
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -310,6 +310,7 @@ static int ath_pci_resume(struct device *device)
> Â Â Â Âath9k_hw_set_gpio(sc->sc_ah, sc->sc_ah->led_pin, 1);
>
> Â Â Â Âsc->ps_idle = true;
> + Â Â Â ath9k_set_wiphy_idle(aphy, true);
> Â Â Â Âath_radio_disable(sc, hw);
>
> Â Â Â Âreturn 0;
If this does not work then yes, I will argue that mac80211 is not
turning us on when it needs to. I was concered about the resume case
given that mac80211 only calls drv_start() when open_count is > 0. So
we'll see.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
