On Tue, Dec 02, 2008 at 05:25:36AM -0800, Henning Rogge wrote:
> diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
> index e08c8bc..3a83e97 100644
> --- a/include/linux/nl80211.h
> +++ b/include/linux/nl80211.h
> @@ -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?
> 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?
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:
adm8211.c:1865: dev->flags = IEEE80211_HW_SIGNAL_UNSPEC;
rtl818x/rtl8187_dev.c:1416: dev->flags |= IEEE80211_HW_SIGNAL_UNSPEC;
rtl818x/rtl8180_dev.c:900: IEEE80211_HW_SIGNAL_UNSPEC;
zd1211rw/zd_mac.c:972: IEEE80211_HW_SIGNAL_DB;
I guess this is the iffy part... I'll see if zd1211rw can somehow use
dBm though.
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 16423f9..77f0b1e 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -17,6 +17,41 @@
> #include "rate.h"
> #include "mesh.h"
>
> +/* bitrate of 802.11n ht20 connections with 800ns guard interval in 100kbit/s
> */
> +const u16 ieee80211n_ht20_gi800[] = {
> + 65, 130, 195, 260, 390, 520, 585, 650,
> + 130, 260, 390, 520, 780, 1040, 1170, 1300,
> + 195, 390, 585, 780, 1170, 1560, 1755, 1950,
> + 260, 520, 780, 1040, 1560, 2080, 2340, 2600
> +};
> +
> +/* bitrate of 802.11n ht20 connections with 400ns guard interval
> + * in 100kbit/s per spatial stream */
> +const u16 ieee80211n_ht20_gi400[] = {
> + 72, 144, 217, 289, 433, 578, 650, 722,
> + 144, 289, 433, 578, 867, 1156, 1300, 1440,
> + 217, 433, 650, 867, 1300, 1733, 1950, 2167,
> + 289, 578, 867, 1157, 1733, 2311, 2600, 2889
> +};
> +
> +/* bitrate of 802.11n ht40 connections with 800ns guard interval
> + * in 100kbit/s per spatial stream */
> +const u16 ieee80211n_ht40_gi800[] = {
> + 135, 270, 405, 540, 810, 1080, 1215, 1350,
> + 270, 540, 810, 1080, 1620, 2160, 2430, 2700,
> + 405, 810, 1215, 1620, 2430, 3240, 3645, 4050,
> + 540, 1080, 1620, 2160, 3240, 4320, 4860, 5400
> +};
> +
> +/* bitrate of 802.11n ht40 connections with 400ns guard interval
> + * in 100kbit/s per spatial stream */
> +const u16 ieee80211n_ht40_gi400[] = {
> + 150, 300, 450, 600, 900, 1200, 1350, 1500,
> + 300, 600, 900, 1200, 1800, 2400, 2700, 3000,
> + 450, 900, 1350, 1800, 2700, 3600, 4050, 4500,
> + 600, 1200, 1800, 2400, 3600, 4800, 5400, 6000
> +};
> +
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.
Any thoughts?
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
