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
Attachment:
signature.asc
Description: This is a digitally signed message part
