On Wed, 2008-12-03 at 11:31 +0100, Henning Rogge wrote:
> What do you think about the idea to export the 802.11n transmission rate
> through the old WExt interface, so iwconfig will show the correct rate too ?
> But for this the "mcs to bitrate" tables would have to be moved to some other
> file, so wext.c can access them too (which one ?).
No, that can't possibly work right, sorry.
> + * @NL80211_STA_INFO_SIGNAL: signal strength of last received package (u8,
> dBm)
s8? should be signed, no?
> + * @NL80211_STA_INFO_RX_BITRATE: bitrate of last received unicast packet
> + * (u16, 100 kbit/s)
I don't really like this. I know we cannot report the real information
yet because we don't even have the driver/mac80211 api but let's add rx
rate reporting when we have the HT information too.
> + * @NL80211_STA_INFO_TX_BITRATE: current unicast tx rate (u16, 100 kbit/s)
> + * @NL80211_STA_INFO_TX_BITRATE_40_MHZ: dual channel transmission (flag)
> + * @NL80211_STA_INFO_TX_BITRATE_MCS: 802.11n MCS index of tx rate (u8)
> + * @NL80211_STA_INFO_TX_BITRATE_SHORT_GI: 802.11n with 400ns GI, 800ns
> + * otherwise, should be ignored if TX_BITRATE_MCS is not set (flag)
I'm not sure I like the bitrate being used as prefix and final name, can
we have maybe TXRATE_ as prefix and use TXRATE_RATE, TXRATE_40, ...?
> +/* 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
> +};
I definitely don't like this, ick, please put that into userspace.
> + if (sta->local->hw.flags & IEEE80211_HW_SIGNAL_DBM) {
> + sinfo->filled |= STATION_INFO_SIGNAL;
> + sinfo->signal = sta->last_signal;
> + }
Good plan to report only when dBm are available, I like that.
> + sinfo->rx_bitrate = sta->last_rxrate_unicast;
> +
> + sinfo->tx_bitrate_flags = sta->last_tx_rate.flags &
> + (IEEE80211_TX_RC_MCS |
> + IEEE80211_TX_RC_40_MHZ_WIDTH |
> + IEEE80211_TX_RC_SHORT_GI);
That looks very odd. Are you sure it's using the same rate flags? And if
it is, that's wrong, because cfg80211 must not rely on mac80211 flags.
> + if (!(sta->last_tx_rate.flags & IEEE80211_TX_RC_MCS)) {
> + struct ieee80211_supported_band *sband;
> + sband = sta->local->hw.wiphy->bands[sta->local->hw.conf.channel->band];
> + sinfo->tx_bitrate = sband->bitrates[sta->last_tx_rate.idx].bitrate;
> + sinfo->tx_bitrate_mcs = 0;
I don't think you should initialise mcs here.
Some places also need work on the coding style.
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
