On Thu, 2010-03-18 at 17:10 +0100, ext Johannes Berg wrote:
> On Thu, 2010-03-18 at 07:19 +0200, Juuso Oikarinen wrote:
> > On Wed, 2010-03-17 at 17:17 +0100, ext Johannes Berg wrote:
> > > On Wed, 2010-03-17 at 15:01 +0200, Juuso Oikarinen wrote:
> > >
> > > > +/**
> > > > + * enum nl80211_cqm_state - current state in relation to set threshold
> > > > + * @NL80211_CQM_STATE_ABOVE: the level is above the configured threshold
> > > > + * @NL80211_CQM_STATE_BELOW: the level is below the configured threshold
> > > > + */
> > > > +enum nl80211_cqm_state {
> > > > + NL80211_CQM_STATE_ABOVE,
> > > > + NL80211_CQM_STATE_BELOW,
> > > > +};
> > >
> > > Thoughts about removing this and just exporting the actual (smoothed?)
> > > RSSI instead in the event? Or do you simply not get that from the hw?
> >
> > On the wl1271 we actually do get the value that triggered the event, but
> > on the wl1251, for instance, we do not get it. On the wl1271 we get to
> > decide the above/below on the host based on the reading, but the wl1251
> > will just tell the host that now the RSSI went below, and now it just
> > went above.
> >
> > Our thinking is that the above/below information is sufficient to make a
> > decisions about roaming. Adding the literal value will give trouble with
> > HW not supporting it.
>
> Ok, that's fair. I don't want to hurt wl1251 by doing this. But then
> maybe it could just retrieve the value from the last beacon?
Alas, we cannot. The wl1251/71 atleast have beacon filtering, so the
host is not receiving beacons at all, and hence, does not have a
up-to-date RSSI value. Actually, the host does not get a decent RSSI
from anywhere, unless there happens to be some non-beacon inbound data
at just that moment.
And also, because there is fluctuation, sending the RSSI value from a
theoretical last beacon may not reflect the true reason of the trigger.
Userspace might not get the right idea for the cause of the event.
> > If you feel the actual value of the RSSI would be important, we could
> > add it as an optional field to the notifcation in addition to the
> > above/below.
>
> No ... I don't actually strongly feel that the actual value is all that
> relevant, although we'll only know when we implement roaming algorithms
> in userspace. Maybe it would be advantageous to keep this out of the
> tree for a while longer while you implement the userspace portion? But I
> don't know how much you've thought about how to use this so maybe you
> know it'll work :) And OTOH you kinda know it has to work since that's
> what you get from the hw...
The N900 has this same mechanism in it, and it's been used there
relatively successfully. So even in practice, this works.
> Anyhow, back to this patch again: For some reason I just don't like the
> above/below thing all that much. I think in part that's because on the
> one hand you say it can be extended, but on the other you call this
> nl80211_cqm_state.
>
> How about we call it nl80211_cqm_rssi_threshold_event or something like
> that? Yeah it's a long and verbose name, but I think it's better than
> "state"? The states you have at least are not really tied to the RSSI
> stuff.
Yes, I can call it whatever feels good to you and others. The name in
itself, I believe, is not an issue!
> I could, for example, imagine also using this to let userspace know
> about beacon loss events when they become too frequent. It's possible
> that this happens while the RSSI is still high, due to interference,
> after all.
Yes, that is a good idea, for later :)
-Juuso
> johannes
>
--
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
