On Tue, Dec 02, 2008 at 12:46:06PM -0800, Henning Rogge wrote:
> > > @@ -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.
Ah no, nevermind me, netlink doesn't have singed values.
> > > 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.
Right.
> > 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.
True..
> Whats about transmitting "basic
> datarate"
What's that?
> , "number of spatial streams"
No need for this one, the HT mode (ht20 or ht40) and MCS index would
give us that.
> and "flags" (short/long GI, 20/40 Mhz width) to userspace ?
Well... see below.
> 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.
I believe to get the throughput you need a lot more info than this, hence
why the table is so big and why you have array index for each MCS index
for each HT mode and guard interval.
So... what if we pass the throughput as you have it but also pass the
other stuff (flags, and MCS index) just so all userspace apps that
want to get last TX/RX guard interval, HT20/HT40, and MCS index
doesn't have to have a funky reverse map to get the flags and MCS index?
Luis
--
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
