On Mar 18, 2009, at 13:36 , Johannes Berg wrote:
On Wed, 2009-03-18 at 14:31 +0100, Ivo van Doorn wrote:
->config() coming after it makes no sense either but we haven't even
tried to avoid that so far... In fact, it is perfectly legal for
->config() to be called after ->config_interface() when, for
example,
you change the channel. Not that I disagree -- we should be
setting the
beacon interval before enabling beaconing...
True, the problem however is that when enabling the radio it is
possible/likely
that a lot of settings will be lost. For rt2x00 we must reset
almost all registers
to make sure everything is set correctly again.
Yeah, that makes sense... I just don't know how to handle it.
What exactly is the problem here? The fact that we don't enable the
radio until after having configured beaconing? I'm not sure how to
solve
this, to be honest.
Neither do I, perhaps we should make sure that a call to config()
when
the enabled_radio field has changed should trigger additional
reconfigurations
as well. But I don't really like such a solution.. :(
We could do that, but there's no limit to what that would be, up to
requiring basically a call to __ieee80211_resume() (from pm.c)...
Perhaps should check if a beacon was provided while the radio was
off,
and either request a new beacon or upload the previously provided
beacon when
the radio is being enabled.
I'm thinking that will be necessary, imagine we integrate rfkill in
mac80211 like we should, and set radio_enabled = false while being an
IBSS member?
OTOH, this problem hitting a number of drivers suggests we should
find a
generic fix.
johannes
Thank you Johannes and Ivo for helping to narrow down this problem.
Would
storing the beacon configuration in the driver before clearing the
registers and then
reloading it be an adequate short-term solution for fixing this issue
on rt2x00? Some
other drivers (b43, ath5k) seem to overcome this shortcoming in the
way the function
calls are ordered. Although a generic fix would be great, fixing this
on rt2x00 would
greatly increase the number of devices supporting mesh point mode.
Antonio Marques
--
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
