Re: rt2x00 mesh support

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]