Re: RFC Patch v2: Add signal strength to nl80211station info

[Henning Rogge <hrogge@googlemail.com>]

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

> > @@ -404,6 +404,10 @@ enum nl80211_sta_flags {
> >   * @NL80211_STA_INFO_TX_BYTES: total transmitted bytes (u32, to this
> > station) * @__NL80211_STA_INFO_AFTER_LAST: internal
> >   * @NL80211_STA_INFO_MAX: highest possible station info attribute
> > + * @NL80211_STA_INFO_SIGNAL: signal strength of last received package
> > (u8, dBm)
> Shouldn't this be s8?
I did not find macros for nl80211 to add signed values... so its just "say 
it's signed, but use the unsigned macro" ? If yes I will change the 
documentation.

> > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> > index 1d57835..cdf9433 100644
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -167,6 +167,9 @@ struct station_parameters {
> >   * @STATION_INFO_LLID: @llid filled
> >   * @STATION_INFO_PLID: @plid filled
> >   * @STATION_INFO_PLINK_STATE: @plink_state filled
> > + * @STATION_INFO_SIGNAL: @signal filled
>
> Can you extend this to indicate drivers which enable this must
> pass the singal in dBm (IEEE80211_HW_SIGNAL_DBM for mac80211 drivers)
> as that is what cfg80211 expects?
The flag is only set if the driver sets the IEEE80211_HW_SIGNAL_DBM flag.
cfg.c:
+       if (sta->local->hw.flags & IEEE80211_HW_SIGNAL_DBM) {
+         sinfo->filled |= STATION_INFO_SIGNAL;
+         sinfo->signal = sta->last_signal;
+       }

But it might be better to explain this in the documentation.

> This is important as mac80211 drivers not using IEEE80211_HW_SIGNAL_DBM
> will luck out of getting signal reports. This means these drivers won't
> get signal reports right now:
I know... (did search for the HW_SIGNAL flags in the drivers)

> I guess this is the iffy part... I'll see if zd1211rw can somehow use
> dBm though.
That would be good I think.

> Awesome stuff, now come to think of it, perhaps its best we let
> userspace do the calculation and we just give it the last RX/TX
> guard interval and the MCS index? Technically speaking it seems
> we don't have duplicate rates though so a reverse map is possible
> but it seems useful to just provide the information directly.
 the problem of this approach would be that every userspace calculation would 
have to do this calculation on it's own. Whats about transmitting "basic 
datarate", "number of spatial streams" and "flags" (short/long GI, 20/40 Mhz 
width) to userspace ? This way it would be just a multiplication to get the 
total bandwith, but it still can easily be reverse mapped into MCS with some 
arithmetics.

Henning


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]