* Request for releasing b43-fwcutter
From: Rafał Miłecki @ 2010-04-19 14:54 UTC (permalink / raw)
To: Michael Buesch; +Cc: b43-dev, linux-wireless
Hi Michael,
Could you consider releasing new version of b43-fwcutter, as we
already have LP-PHY support in kernel, please? AFAIK ppl need to use
git version currently to extract firmware.
--
Rafał
^ permalink raw reply
* Re: b43 'hardware blocked' but only keyboard/led touch button
From: Matthew Garrett @ 2010-04-19 14:51 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Dan Williams, Larry Finger, linux-wireless
In-Reply-To: <20100419115329.GA5306@frolo.macqel>
On Mon, Apr 19, 2010 at 01:53:29PM +0200, Philippe De Muyter wrote:
> and the blue/red led doesn't change color, and wifi state does not change
> either.
What's the output of the rfkill command now?
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* Re: [RFC PATCHv3 2/2] cfg80211: Remove default dynamic PS timeout value
From: Johannes Berg @ 2010-04-19 14:43 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1271409274-17162-3-git-send-email-juuso.oikarinen@nokia.com>
On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> Now that the mac80211 is choosing dynamic ps timeouts based on the ps-qos
> network latency configuration, configure a default value of -1 as the dynamic
> ps timeout in cfg80211. This value allows the mac80211 to determine the value
> to be used.
>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> net/wireless/core.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/net/wireless/core.c b/net/wireless/core.c
> index 6ac70c1..37d0e0a 100644
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -705,7 +705,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block * nb,
> wdev->ps = true;
> else
> wdev->ps = false;
> - wdev->ps_timeout = 100;
> + /* allow mac80211 to determine the timeout */
> + wdev->ps_timeout = -1;
> if (rdev->ops->set_power_mgmt)
> if (rdev->ops->set_power_mgmt(wdev->wiphy, dev,
> wdev->ps,
Does that need some API doc updates to indicate, as part of the cfg80211
API, that -1 means some way of setting it by default?
Or actually, wouldn't it make sense to move the pm_qos logic here (into
cfg80211)?
johannes
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Johannes Berg @ 2010-04-19 14:42 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1271409274-17162-2-git-send-email-juuso.oikarinen@nokia.com>
On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> Determine the dynamic PS timeout based on the configured ps-qos network
> latency. For backwards wext compatibility, allow the dynamic PS timeout
> configured by the cfg80211 to overrule the automatically determined value.
This seems OK, but I fear that you'll write applications setting the
pm_qos network latency just to affect this parameter?
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
> include/net/mac80211.h | 5 ++++-
> net/mac80211/cfg.c | 4 ++--
> net/mac80211/main.c | 2 ++
> net/mac80211/mlme.c | 14 ++++++++++++++
> 4 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index dcf3c5f..243e4ab 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -661,6 +661,9 @@ enum ieee80211_smps_mode {
> * @dynamic_ps_timeout: The dynamic powersave timeout (in ms), see the
> * powersave documentation below. This variable is valid only when
> * the CONF_PS flag is set.
> + * @dynamic_ps_forced_timeout: The dynamic powersave timeout (in ms) configured
> + * by cfg80211 (essentially, wext) If set, this value overrules the value
> + * chosen by mac80211 based on ps qos network latency.
> *
> * @power_level: requested transmit power (in dBm)
> *
> @@ -680,7 +683,7 @@ enum ieee80211_smps_mode {
> */
> struct ieee80211_conf {
> u32 flags;
> - int power_level, dynamic_ps_timeout;
> + int power_level, dynamic_ps_timeout, dynamic_ps_forced_timeout;
> int max_sleep_period;
>
> u16 listen_interval;
> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
> index 7dd7cda..9a1a91c 100644
> --- a/net/mac80211/cfg.c
> +++ b/net/mac80211/cfg.c
> @@ -1388,11 +1388,11 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
> return -EOPNOTSUPP;
>
> if (enabled == sdata->u.mgd.powersave &&
> - timeout == conf->dynamic_ps_timeout)
> + timeout == conf->dynamic_ps_forced_timeout)
> return 0;
>
> sdata->u.mgd.powersave = enabled;
> - conf->dynamic_ps_timeout = timeout;
> + conf->dynamic_ps_forced_timeout = timeout;
>
> /* no change, but if automatic follow powersave */
> mutex_lock(&sdata->u.mgd.mtx);
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index 4afe851..ebcca0e 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -569,6 +569,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
>
> local->hw.conf.listen_interval = local->hw.max_listen_interval;
>
> + local->hw.conf.dynamic_ps_forced_timeout = -1;
> +
> result = sta_info_start(local);
> if (result < 0)
> goto fail_sta_info;
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 35d8502..6402997 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -476,6 +476,7 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
> {
> struct ieee80211_sub_if_data *sdata, *found = NULL;
> int count = 0;
> + int timeout;
>
> if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_PS)) {
> local->ps_sdata = NULL;
> @@ -509,6 +510,19 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
> beaconint_us = ieee80211_tu_to_usec(
> found->vif.bss_conf.beacon_int);
>
> + timeout = local->hw.conf.dynamic_ps_forced_timeout;
> + if (timeout < 0) {
> + if (latency <= 50000)
> + timeout = 300;
> + else if (latency <= 2000000000)
> + timeout = 100;
> + else if (latency <= 2100000000)
> + timeout = 50;
> + else
> + timeout = 0;
Is it even possible to set it larger than 2000 seconds?
johannes
^ permalink raw reply
* Re: [PATCH 8/9] ath9k: add support for Tx and Rx STBC
From: Felix Fietkau @ 2010-04-19 12:28 UTC (permalink / raw)
To: Björn Smedman
Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com,
lrodriguez@atheros.com
In-Reply-To: <g2i133e8d7e1004190522n7dff80c3v1238a9f72cff734f@mail.gmail.com>
On 19.04.2010, at 14:22, Björn Smedman <bjorn.smedman@venatech.se>
wrote:
> Hi all,
>
> Is STBC not supported on any chipsets other than
> AR_SREV_9280_10_OR_LATER(ah)?
Right. AR9160 and older do not support this - at least according to
sources and datasheets.
- Felix
^ permalink raw reply
* Re: [PATCH 8/9] ath9k: add support for Tx and Rx STBC
From: Björn Smedman @ 2010-04-19 12:22 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <1271602602-8538-8-git-send-email-nbd@openwrt.org>
Hi all,
Is STBC not supported on any chipsets other than AR_SREV_9280_10_OR_LATER(ah)?
/Björn
On Sun, Apr 18, 2010 at 4:56 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> Supported only for single stream rates by the hardware
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> ---
> drivers/net/wireless/ath/ath9k/init.c | 6 ++++++
> drivers/net/wireless/ath/ath9k/mac.h | 8 +++++++-
> drivers/net/wireless/ath/ath9k/xmit.c | 2 ++
> 3 files changed, 15 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
> index 2c0630e..8c79548 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -216,6 +216,12 @@ static void setup_ht_cap(struct ath_softc *sc,
> else
> max_streams = 2;
>
> + if (AR_SREV_9280_10_OR_LATER(ah)) {
> + if (max_streams >= 2)
> + ht_info->cap |= IEEE80211_HT_CAP_TX_STBC;
> + ht_info->cap |= (1 << IEEE80211_HT_CAP_RX_STBC_SHIFT);
> + }
> +
> /* set up supported mcs set */
> memset(&ht_info->mcs, 0, sizeof(ht_info->mcs));
> tx_streams = count_streams(common->tx_chainmask, max_streams);
> diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
> index 66d0d5e..00f3e0c 100644
> --- a/drivers/net/wireless/ath/ath9k/mac.h
> +++ b/drivers/net/wireless/ath/ath9k/mac.h
> @@ -37,6 +37,8 @@
> AR_2040_##_index : 0) \
> |((_series)[_index].RateFlags & ATH9K_RATESERIES_HALFGI ? \
> AR_GI##_index : 0) \
> + |((_series)[_index].RateFlags & ATH9K_RATESERIES_STBC ? \
> + AR_STBC##_index : 0) \
> |SM((_series)[_index].ChSel, AR_ChainSel##_index))
>
> #define CCK_SIFS_TIME 10
> @@ -434,7 +436,10 @@ struct ar5416_desc {
> #define AR_ChainSel3_S 17
> #define AR_RTSCTSRate 0x0ff00000
> #define AR_RTSCTSRate_S 20
> -#define AR_TxCtlRsvd70 0xf0000000
> +#define AR_STBC0 0x10000000
> +#define AR_STBC1 0x20000000
> +#define AR_STBC2 0x40000000
> +#define AR_STBC3 0x80000000
>
> #define AR_TxRSSIAnt00 0x000000ff
> #define AR_TxRSSIAnt00_S 0
> @@ -647,6 +652,7 @@ enum ath9k_rx_filter {
> #define ATH9K_RATESERIES_RTS_CTS 0x0001
> #define ATH9K_RATESERIES_2040 0x0002
> #define ATH9K_RATESERIES_HALFGI 0x0004
> +#define ATH9K_RATESERIES_STBC 0x0008
>
> struct ath9k_11n_rate_series {
> u32 Tries;
> diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
> index 2237658..b0d345a 100644
> --- a/drivers/net/wireless/ath/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath/ath9k/xmit.c
> @@ -1607,6 +1607,8 @@ static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf)
> series[i].Rate = rix | 0x80;
> series[i].PktDuration = ath_pkt_duration(sc, rix, bf,
> is_40, is_sgi, is_sp);
> + if (rix < 8 && (tx_info->flags & IEEE80211_TX_CTL_STBC))
> + series[i].RateFlags |= ATH9K_RATESERIES_STBC;
> continue;
> }
>
> --
> 1.6.4.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Venatech AB
Ideon Innovation
Ole Römers väg 12
SE-22370 LUND
Sweden
+46 (0) 46 286 86 20
info@venatech.se
http://www.venatech.se
^ permalink raw reply
* Re: b43 'hardware blocked' but only keyboard/led touch button
From: Philippe De Muyter @ 2010-04-19 11:53 UTC (permalink / raw)
To: Matthew Garrett; +Cc: Dan Williams, Larry Finger, linux-wireless
In-Reply-To: <20100330193129.GA31847@srcf.ucam.org>
On Tue, Mar 30, 2010 at 08:31:29PM +0100, Matthew Garrett wrote:
> On Tue, Mar 30, 2010 at 09:26:29PM +0200, Philippe De Muyter wrote:
>
> > I must also add that I currently cannot boot without acpi=off
>
> That's your bug, then.
I now boot with acpi.
Summary : I have a hp pavilion dv6-1300sb laptop with a b43 wifi device,
and a touchkey to disable or enable wifi with a red/blue led as feedback.
hp-wmi is loaded
when I touch the wifi key, I get the following messages (with 2.6.34-rc4) :
[ 256.039395] atkbd.c: Unknown key pressed (translated set 2, code 0x94 on isa0060/serio0).
[ 256.039408] atkbd.c: Use 'setkeycodes e014 <keycode>' to make it known.
[ 256.062313] atkbd.c: Unknown key released (translated set 2, code 0x94 on isa0060/serio0).
[ 256.062321] atkbd.c: Use 'setkeycodes e014 <keycode>' to make it known.
and the blue/red led doesn't change color, and wifi state does not change
either.
Any hint ?
Philippe
^ permalink raw reply
* Re: [PATCH] mac80211: fix stopping RX BA session from timer
From: Kalle Valo @ 2010-04-19 11:22 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, linux-wireless
In-Reply-To: <1271667624.3873.12.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> Kalle reported that his system deadlocks since my
> recent work in this area. The reason quickly became
> apparent: we try to cancel_timer_sync() a timer
> from within itself. Fix that by making the function
> aware of the context it is called from.
I have now tested this for an hour and I can't reproduce the problem
anymore, earlier I was able to reproduce at least within a minute or
so. So I'm confident that the problem I saw is this fixed by this
patch.
Thank you very much for fixing this so quickly.
> Reported-by: Kalle Valo <kvalo@adurom.com>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Tested-by: Kalle Valo <kvalo@adurom.com>
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 7/9] mac80211: add flags for STBC (Space-Time Block Coding)
From: Felix Fietkau @ 2010-04-19 10:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <1271672347.3873.18.camel@jlt3.sipsolutions.net>
On 2010-04-19 12:19 PM, Johannes Berg wrote:
> On Mon, 2010-04-19 at 12:14 +0200, Felix Fietkau wrote:
>> On 2010-04-19 11:09 AM, Johannes Berg wrote:
>> > On Mon, 2010-04-19 at 11:06 +0200, Felix Fietkau wrote:
>> >> On 2010-04-19 10:59 AM, Johannes Berg wrote:
>> >> > On Mon, 2010-04-19 at 10:45 +0200, Felix Fietkau wrote:
>> >> >> On 2010-04-19 7:57 AM, Johannes Berg wrote:
>> >> >> > On Sun, 2010-04-18 at 18:05 +0200, Felix Fietkau wrote:
>> >> >> >
>> >> >> >> >> + * @IEEE80211_TX_CTL_STBC: tells the driver to use Space-Time Block Coding
>> >> >> >> >> + * (STBC) for this frame.
>> >> >> >> >> */
>> >> >> >> >> enum mac80211_tx_control_flags {
>> >> >> >> >> IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
>> >> >> >> >> @@ -299,6 +301,7 @@ enum mac80211_tx_control_flags {
>> >> >> >> >> IEEE80211_TX_INTFL_HAS_RADIOTAP = BIT(20),
>> >> >> >> >> IEEE80211_TX_INTFL_NL80211_FRAME_TX = BIT(21),
>> >> >> >> >> IEEE80211_TX_CTL_LDPC = BIT(22),
>> >> >> >> >> + IEEE80211_TX_CTL_STBC = BIT(23),
>> >> >> >> >
>> >> >> >> > What if the # of streams is different? That doesn't look sufficient.
>> >> >> >
>> >> >> >> Hm, you're right. I initially thought the combination of the MCS index
>> >> >> >> and the STBC flag would be enough, but there are still some corner cases.
>> >> >> >
>> >> >> > Hm actually I guess that should be sufficient? What corner case are you
>> >> >> > thinking of?
>> >> >> Support for multi-rate retry and STBC with more than one stream on one
>> >> >> side, using rates from both MCS0-7 and MCS8-15 in the rate series.
>> >> >> Rx STBC for only one stream on the other side.
>> >> >
>> >> > So the flag should be per rate entry instead, no?
>> >
>> >> Well, I think if we use two bits in the tx control flags, we don't need
>> >> it to be per rate entry.
>> >
>> > But then you can't probe stbc properly, can you?
>> I'm not sure we even need to probe STBC. In all of the drivers that I've
>> looked at, it's always enabled if the peer supports it.
>> I'm not aware of any situation where it would make the reception worse,
>> aside from hardware damage of course ;)
>
> Ok ... I guess two bits then so you don't have to look up sta capability
> when doing the hw programming?
Right. I'll send a new series later.
- Felix
^ permalink raw reply
* Re: [PATCH 7/9] mac80211: add flags for STBC (Space-Time Block Coding)
From: Johannes Berg @ 2010-04-19 10:19 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <4BCC2D1E.4000408@openwrt.org>
On Mon, 2010-04-19 at 12:14 +0200, Felix Fietkau wrote:
> On 2010-04-19 11:09 AM, Johannes Berg wrote:
> > On Mon, 2010-04-19 at 11:06 +0200, Felix Fietkau wrote:
> >> On 2010-04-19 10:59 AM, Johannes Berg wrote:
> >> > On Mon, 2010-04-19 at 10:45 +0200, Felix Fietkau wrote:
> >> >> On 2010-04-19 7:57 AM, Johannes Berg wrote:
> >> >> > On Sun, 2010-04-18 at 18:05 +0200, Felix Fietkau wrote:
> >> >> >
> >> >> >> >> + * @IEEE80211_TX_CTL_STBC: tells the driver to use Space-Time Block Coding
> >> >> >> >> + * (STBC) for this frame.
> >> >> >> >> */
> >> >> >> >> enum mac80211_tx_control_flags {
> >> >> >> >> IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
> >> >> >> >> @@ -299,6 +301,7 @@ enum mac80211_tx_control_flags {
> >> >> >> >> IEEE80211_TX_INTFL_HAS_RADIOTAP = BIT(20),
> >> >> >> >> IEEE80211_TX_INTFL_NL80211_FRAME_TX = BIT(21),
> >> >> >> >> IEEE80211_TX_CTL_LDPC = BIT(22),
> >> >> >> >> + IEEE80211_TX_CTL_STBC = BIT(23),
> >> >> >> >
> >> >> >> > What if the # of streams is different? That doesn't look sufficient.
> >> >> >
> >> >> >> Hm, you're right. I initially thought the combination of the MCS index
> >> >> >> and the STBC flag would be enough, but there are still some corner cases.
> >> >> >
> >> >> > Hm actually I guess that should be sufficient? What corner case are you
> >> >> > thinking of?
> >> >> Support for multi-rate retry and STBC with more than one stream on one
> >> >> side, using rates from both MCS0-7 and MCS8-15 in the rate series.
> >> >> Rx STBC for only one stream on the other side.
> >> >
> >> > So the flag should be per rate entry instead, no?
> >
> >> Well, I think if we use two bits in the tx control flags, we don't need
> >> it to be per rate entry.
> >
> > But then you can't probe stbc properly, can you?
> I'm not sure we even need to probe STBC. In all of the drivers that I've
> looked at, it's always enabled if the peer supports it.
> I'm not aware of any situation where it would make the reception worse,
> aside from hardware damage of course ;)
Ok ... I guess two bits then so you don't have to look up sta capability
when doing the hw programming?
johannes
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: Use high bitrates for ACK/CTS
From: Gábor Stefanik @ 2010-04-19 10:14 UTC (permalink / raw)
To: Bruno Randolf; +Cc: Stanislaw Gruszka, linville, ath5k-devel, linux-wireless
In-Reply-To: <201004190924.25709.br1@einfach.org>
On Mon, Apr 19, 2010 at 2:24 AM, Bruno Randolf <br1@einfach.org> wrote:
> On Friday 16 April 2010 22:59:07 Stanislaw Gruszka wrote:
>> On Mon, 12 Apr 2010 16:38:47 +0900
>>
>> Bruno Randolf <br1@einfach.org> wrote:
>> > There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB
>> > and AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower
>> > bitrates for ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah,
>> > false) actually resulted in high bitrates, which i think is what we want
>> > anyways. Cleared the confusion and added some documentation.
>>
>> I thought ACK and other control frames have to be modulated at slow/robust
>> bitrates, but can't remember where I read that ...
>
> this has been discussed on ath5k-devel before. i'm copying it here. please let
> me know if i missed something...
>
> (https://lists.ath5k.org/pipermail/ath5k-devel/2010-March/003391.html)
>
> control frames have to be sent at one of the lower bitrates - one of the
> "basic rates". in G mode these are 1, 2, 5.5, 11, 6, 12, 24Mbps.
Aren't basic rates defined so as to exclude any OFDM rates? I.e. are
6M, 12M and 24M really basic rates?
>
> this is from the 802.11g spec:
> "a STA responding to a received frame shall transmit its Control Response
> (either CTS or ACK) frames at the highest rate in the BSSBasicRateSet that is
> less than or equal to the rate of the immediately previous frame in the frame
> exchange sequence (as defined in 9.7)"
>
> basically we have to make a tradeoff here: using lower rates for ACK/CTS will
> improve reliability, but lower performance. for example i could get only
> 10Mbps truput with ACK/CTS at the lowest bitrates and RTS/CTS enabled
> (iwconfig wlan0 rts 250) and i can get more than 20Mbps with higher bitrates.
> so i think it's worth to use high bitrates. actually also this should be
> tuneable for the user, too...
>
> bruno
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: [PATCH 7/9] mac80211: add flags for STBC (Space-Time Block Coding)
From: Felix Fietkau @ 2010-04-19 10:14 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <1271668150.3873.17.camel@jlt3.sipsolutions.net>
On 2010-04-19 11:09 AM, Johannes Berg wrote:
> On Mon, 2010-04-19 at 11:06 +0200, Felix Fietkau wrote:
>> On 2010-04-19 10:59 AM, Johannes Berg wrote:
>> > On Mon, 2010-04-19 at 10:45 +0200, Felix Fietkau wrote:
>> >> On 2010-04-19 7:57 AM, Johannes Berg wrote:
>> >> > On Sun, 2010-04-18 at 18:05 +0200, Felix Fietkau wrote:
>> >> >
>> >> >> >> + * @IEEE80211_TX_CTL_STBC: tells the driver to use Space-Time Block Coding
>> >> >> >> + * (STBC) for this frame.
>> >> >> >> */
>> >> >> >> enum mac80211_tx_control_flags {
>> >> >> >> IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
>> >> >> >> @@ -299,6 +301,7 @@ enum mac80211_tx_control_flags {
>> >> >> >> IEEE80211_TX_INTFL_HAS_RADIOTAP = BIT(20),
>> >> >> >> IEEE80211_TX_INTFL_NL80211_FRAME_TX = BIT(21),
>> >> >> >> IEEE80211_TX_CTL_LDPC = BIT(22),
>> >> >> >> + IEEE80211_TX_CTL_STBC = BIT(23),
>> >> >> >
>> >> >> > What if the # of streams is different? That doesn't look sufficient.
>> >> >
>> >> >> Hm, you're right. I initially thought the combination of the MCS index
>> >> >> and the STBC flag would be enough, but there are still some corner cases.
>> >> >
>> >> > Hm actually I guess that should be sufficient? What corner case are you
>> >> > thinking of?
>> >> Support for multi-rate retry and STBC with more than one stream on one
>> >> side, using rates from both MCS0-7 and MCS8-15 in the rate series.
>> >> Rx STBC for only one stream on the other side.
>> >
>> > So the flag should be per rate entry instead, no?
>
>> Well, I think if we use two bits in the tx control flags, we don't need
>> it to be per rate entry.
>
> But then you can't probe stbc properly, can you?
I'm not sure we even need to probe STBC. In all of the drivers that I've
looked at, it's always enabled if the peer supports it.
I'm not aware of any situation where it would make the reception worse,
aside from hardware damage of course ;)
- Felix
^ permalink raw reply
* Re: [PATCH] wireless: rt2x00: rt2800usb: identify Allwin devices
From: Ivo van Doorn @ 2010-04-19 10:10 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: linux-wireless, users, linville, gwingerde
In-Reply-To: <1271670856-2532-1-git-send-email-xose.vazquez@gmail.com>
On Monday 19 April 2010, Xose Vazquez Perez wrote:
> Applied common sense, no info from the manufacturer:
>
> (0x8516, 0x2070) is RT2070
> (0x8516, 0x2770) is RT2770
> (0x8516, 0x2870) is RT2870
> [...]
>
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
^ permalink raw reply
* Re: [PATCH] wireless: rt2x00: rt2800usb: delete Allwin devices
From: Xose Vazquez Perez @ 2010-04-19 9:58 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: John W. Linville, Ivo Van Doorn, linux-wireless, users
In-Reply-To: <4BC8D44A.2040903@gmail.com>
On 04/16/2010 11:19 PM, Gertjan van Wingerde wrote:
> And finally, these devices are still mentioned in the Ralink windows driver,
> so we must assume that they actually exist.
some devices in the windows drivers are experimental(never produced/shipped).
> However, the common sense approach may be appropriate, so moving these devices
> to the correct section does seem okay.
done.
--
«Allá muevan feroz guerra, ciegos reyes por un palmo más de tierra;
que yo aquí tengo por mío cuanto abarca el mar bravío, a quien nadie
impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor,
que no sienta mi derecho y dé pecho a mi valor.»
^ permalink raw reply
* [PATCH] wireless: rt2x00: rt2800usb: identify Allwin devices
From: Xose Vazquez Perez @ 2010-04-19 9:54 UTC (permalink / raw)
To: linux-wireless; +Cc: users, linville, IvDoorn, gwingerde, xose.vazquez
Applied common sense, no info from the manufacturer:
(0x8516, 0x2070) is RT2070
(0x8516, 0x2770) is RT2770
(0x8516, 0x2870) is RT2870
[...]
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index df7666f..95c8a61 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -806,6 +806,10 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x07b8, 0x2870), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x07b8, 0x2770), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x1482, 0x3c09), USB_DEVICE_DATA(&rt2800usb_ops) },
+ /* Allwin */
+ { USB_DEVICE(0x8516, 0x2070), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x8516, 0x2770), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x8516, 0x2870), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Amit */
{ USB_DEVICE(0x15c5, 0x0008), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Askey */
@@ -912,6 +916,10 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x07b8, 0x3072), USB_DEVICE_DATA(&rt2800usb_ops) },
/* AirTies */
{ USB_DEVICE(0x1eda, 0x2310), USB_DEVICE_DATA(&rt2800usb_ops) },
+ /* Allwin */
+ { USB_DEVICE(0x8516, 0x3070), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x8516, 0x3071), USB_DEVICE_DATA(&rt2800usb_ops) },
+ { USB_DEVICE(0x8516, 0x3072), USB_DEVICE_DATA(&rt2800usb_ops) },
/* ASUS */
{ USB_DEVICE(0x0b05, 0x1784), USB_DEVICE_DATA(&rt2800usb_ops) },
/* AzureWave */
@@ -996,6 +1004,8 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x5a57, 0x5257), USB_DEVICE_DATA(&rt2800usb_ops) },
#endif
#ifdef CONFIG_RT2800USB_RT35XX
+ /* Allwin */
+ { USB_DEVICE(0x8516, 0x3572), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Askey */
{ USB_DEVICE(0x1690, 0x0744), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Cisco */
@@ -1019,14 +1029,6 @@ static struct usb_device_id rt2800usb_device_table[] = {
* Unclear what kind of devices these are (they aren't supported by the
* vendor driver).
*/
- /* Allwin */
- { USB_DEVICE(0x8516, 0x2070), USB_DEVICE_DATA(&rt2800usb_ops) },
- { USB_DEVICE(0x8516, 0x2770), USB_DEVICE_DATA(&rt2800usb_ops) },
- { USB_DEVICE(0x8516, 0x2870), USB_DEVICE_DATA(&rt2800usb_ops) },
- { USB_DEVICE(0x8516, 0x3070), USB_DEVICE_DATA(&rt2800usb_ops) },
- { USB_DEVICE(0x8516, 0x3071), USB_DEVICE_DATA(&rt2800usb_ops) },
- { USB_DEVICE(0x8516, 0x3072), USB_DEVICE_DATA(&rt2800usb_ops) },
- { USB_DEVICE(0x8516, 0x3572), USB_DEVICE_DATA(&rt2800usb_ops) },
/* Amigo */
{ USB_DEVICE(0x0e0b, 0x9031), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x0e0b, 0x9041), USB_DEVICE_DATA(&rt2800usb_ops) },
--
1.6.6.1
^ permalink raw reply related
* [PATCH] mac80211: document IEEE80211_CONF_CHANGE_QoS
From: Stanislaw Gruszka @ 2010-04-19 9:24 UTC (permalink / raw)
To: linux-wireless
Cc: Reinette Chatre, John W. Linville, wey-yi.w.guy, Johannes Berg
In-Reply-To: <1271495090.5157.4.camel@jlt3.sipsolutions.net>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index dcf3c5f..97b2222 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -610,6 +610,7 @@ enum ieee80211_conf_flags {
* @IEEE80211_CONF_CHANGE_RETRY_LIMITS: retry limits changed
* @IEEE80211_CONF_CHANGE_IDLE: Idle flag changed
* @IEEE80211_CONF_CHANGE_SMPS: Spatial multiplexing powersave mode changed
+ * @IEEE80211_CONF_CHANGE_QoS: Quality of service was enabled or disabled
*/
enum ieee80211_conf_changed {
IEEE80211_CONF_CHANGE_SMPS = BIT(1),
^ permalink raw reply related
* Re: [PATCH 7/9] mac80211: add flags for STBC (Space-Time Block Coding)
From: Johannes Berg @ 2010-04-19 9:09 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <4BCC1D1A.7020705@openwrt.org>
On Mon, 2010-04-19 at 11:06 +0200, Felix Fietkau wrote:
> On 2010-04-19 10:59 AM, Johannes Berg wrote:
> > On Mon, 2010-04-19 at 10:45 +0200, Felix Fietkau wrote:
> >> On 2010-04-19 7:57 AM, Johannes Berg wrote:
> >> > On Sun, 2010-04-18 at 18:05 +0200, Felix Fietkau wrote:
> >> >
> >> >> >> + * @IEEE80211_TX_CTL_STBC: tells the driver to use Space-Time Block Coding
> >> >> >> + * (STBC) for this frame.
> >> >> >> */
> >> >> >> enum mac80211_tx_control_flags {
> >> >> >> IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
> >> >> >> @@ -299,6 +301,7 @@ enum mac80211_tx_control_flags {
> >> >> >> IEEE80211_TX_INTFL_HAS_RADIOTAP = BIT(20),
> >> >> >> IEEE80211_TX_INTFL_NL80211_FRAME_TX = BIT(21),
> >> >> >> IEEE80211_TX_CTL_LDPC = BIT(22),
> >> >> >> + IEEE80211_TX_CTL_STBC = BIT(23),
> >> >> >
> >> >> > What if the # of streams is different? That doesn't look sufficient.
> >> >
> >> >> Hm, you're right. I initially thought the combination of the MCS index
> >> >> and the STBC flag would be enough, but there are still some corner cases.
> >> >
> >> > Hm actually I guess that should be sufficient? What corner case are you
> >> > thinking of?
> >> Support for multi-rate retry and STBC with more than one stream on one
> >> side, using rates from both MCS0-7 and MCS8-15 in the rate series.
> >> Rx STBC for only one stream on the other side.
> >
> > So the flag should be per rate entry instead, no?
> Well, I think if we use two bits in the tx control flags, we don't need
> it to be per rate entry.
But then you can't probe stbc properly, can you?
> We don't have any space left for more per rate entry flags ;)
separate problem ;)
johannes
^ permalink raw reply
* Re: [PATCH 7/9] mac80211: add flags for STBC (Space-Time Block Coding)
From: Felix Fietkau @ 2010-04-19 9:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <1271667582.3873.11.camel@jlt3.sipsolutions.net>
On 2010-04-19 10:59 AM, Johannes Berg wrote:
> On Mon, 2010-04-19 at 10:45 +0200, Felix Fietkau wrote:
>> On 2010-04-19 7:57 AM, Johannes Berg wrote:
>> > On Sun, 2010-04-18 at 18:05 +0200, Felix Fietkau wrote:
>> >
>> >> >> + * @IEEE80211_TX_CTL_STBC: tells the driver to use Space-Time Block Coding
>> >> >> + * (STBC) for this frame.
>> >> >> */
>> >> >> enum mac80211_tx_control_flags {
>> >> >> IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
>> >> >> @@ -299,6 +301,7 @@ enum mac80211_tx_control_flags {
>> >> >> IEEE80211_TX_INTFL_HAS_RADIOTAP = BIT(20),
>> >> >> IEEE80211_TX_INTFL_NL80211_FRAME_TX = BIT(21),
>> >> >> IEEE80211_TX_CTL_LDPC = BIT(22),
>> >> >> + IEEE80211_TX_CTL_STBC = BIT(23),
>> >> >
>> >> > What if the # of streams is different? That doesn't look sufficient.
>> >
>> >> Hm, you're right. I initially thought the combination of the MCS index
>> >> and the STBC flag would be enough, but there are still some corner cases.
>> >
>> > Hm actually I guess that should be sufficient? What corner case are you
>> > thinking of?
>> Support for multi-rate retry and STBC with more than one stream on one
>> side, using rates from both MCS0-7 and MCS8-15 in the rate series.
>> Rx STBC for only one stream on the other side.
>
> So the flag should be per rate entry instead, no?
Well, I think if we use two bits in the tx control flags, we don't need
it to be per rate entry.
We don't have any space left for more per rate entry flags ;)
- Felix
^ permalink raw reply
* [RFC] mac80211: allow creating/destroying agg sessions from debugfs
From: Johannes Berg @ 2010-04-19 9:04 UTC (permalink / raw)
To: linux-wireless
This is useful for debugging.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
Not sure we want it in the tree?
drivers/net/wireless/mac80211_hwsim.c | 3 +
net/mac80211/debugfs_sta.c | 65 +++++++++++++++++++++++++++++++++-
2 files changed, 66 insertions(+), 2 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2010-04-19 10:53:52.000000000 +0200
+++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2010-04-19 10:54:37.000000000 +0200
@@ -1287,7 +1287,8 @@ static int __init init_mac80211_hwsim(vo
hw->flags = IEEE80211_HW_MFP_CAPABLE |
IEEE80211_HW_SIGNAL_DBM |
IEEE80211_HW_SUPPORTS_STATIC_SMPS |
- IEEE80211_HW_SUPPORTS_DYNAMIC_SMPS;
+ IEEE80211_HW_SUPPORTS_DYNAMIC_SMPS |
+ IEEE80211_HW_AMPDU_AGGREGATION;
/* ask mac80211 to reserve space for magic */
hw->vif_data_size = sizeof(struct hwsim_vif_priv);
--- wireless-testing.orig/net/mac80211/debugfs_sta.c 2010-04-19 10:53:52.000000000 +0200
+++ wireless-testing/net/mac80211/debugfs_sta.c 2010-04-19 10:54:37.000000000 +0200
@@ -39,6 +39,13 @@ static const struct file_operations sta_
.open = mac80211_open_file_generic, \
}
+#define STA_OPS_RW(name) \
+static const struct file_operations sta_ ##name## _ops = { \
+ .read = sta_##name##_read, \
+ .write = sta_##name##_write, \
+ .open = mac80211_open_file_generic, \
+}
+
#define STA_FILE(name, field, format) \
STA_READ_##format(name, field) \
STA_OPS(name)
@@ -156,7 +163,63 @@ static ssize_t sta_agg_status_read(struc
return simple_read_from_buffer(userbuf, count, ppos, buf, p - buf);
}
-STA_OPS(agg_status);
+
+static ssize_t sta_agg_status_write(struct file *file, const char __user *userbuf,
+ size_t count, loff_t *ppos)
+{
+ char _buf[12], *buf = _buf;
+ struct sta_info *sta = file->private_data;
+ bool start, tx;
+ unsigned long tid;
+ int ret;
+
+ if (count > sizeof(_buf))
+ return -EINVAL;
+
+ if (copy_from_user(buf, userbuf, count))
+ return -EFAULT;
+
+ buf[sizeof(_buf) - 1] = '\0';
+
+ if (strncmp(buf, "tx ", 3) == 0) {
+ buf += 3;
+ tx = true;
+ } else if (strncmp(buf, "rx ", 3) == 0) {
+ buf += 3;
+ tx = false;
+ } else
+ return -EINVAL;
+
+ if (strncmp(buf, "start ", 6) == 0) {
+ buf += 6;
+ start = true;
+ if (!tx)
+ return -EINVAL;
+ } else if (strncmp(buf, "stop ", 5) == 0) {
+ buf += 5;
+ start = false;
+ } else
+ return -EINVAL;
+
+ tid = simple_strtoul(buf, NULL, 0);
+
+ if (tid >= STA_TID_NUM)
+ return -EINVAL;
+
+ if (tx) {
+ if (start)
+ ret = ieee80211_start_tx_ba_session(&sta->sta, tid);
+ else
+ ret = ieee80211_stop_tx_ba_session(&sta->sta, tid,
+ WLAN_BACK_RECIPIENT);
+ } else {
+ __ieee80211_stop_rx_ba_session(sta, tid, WLAN_BACK_RECIPIENT, 3);
+ ret = 0;
+ }
+
+ return ret ?: count;
+}
+STA_OPS_RW(agg_status);
static ssize_t sta_ht_capa_read(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
^ permalink raw reply
* [PATCH] mac80211: add missing newline
From: Johannes Berg @ 2010-04-19 9:03 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
One HT debugging printk is missing a newline,
add it.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/agg-tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-testing.orig/net/mac80211/agg-tx.c 2010-04-19 10:53:23.000000000 +0200
+++ wireless-testing/net/mac80211/agg-tx.c 2010-04-19 10:53:52.000000000 +0200
@@ -185,7 +185,7 @@ static void sta_addba_resp_timer_expired
spin_unlock_bh(&sta->lock);
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "timer expired on tid %d but we are not "
- "(or no longer) expecting addBA response there",
+ "(or no longer) expecting addBA response there\n",
tid);
#endif
return;
^ permalink raw reply
* Re: [RFC] mac80211: sample survey implementation for mac80211 & hwsim
From: Johannes Berg @ 2010-04-19 9:02 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <201004191023.57987.holgerschurig@gmail.com>
How does this work with multiple channels? And how about knowing how old
the info is?
> +static inline int drv_get_survey(struct ieee80211_local *local, int idx,
> + struct survey_info *survey)
> +{
> + int ret = -EOPNOTSUPP;
> + if (local->ops->conf_tx)
> + ret = local->ops->get_survey(&local->hw, idx, survey);
> + /* trace_drv_get_survey(local, idx, survey, ret); */
Lazy huh? :)
johannes
^ permalink raw reply
* [PATCH] mac80211: fix stopping RX BA session from timer
From: Johannes Berg @ 2010-04-19 9:00 UTC (permalink / raw)
To: Kalle Valo; +Cc: John W. Linville, linux-wireless
In-Reply-To: <87wrw3lxjh.fsf@purkki.valot.fi>
Kalle reported that his system deadlocks since my
recent work in this area. The reason quickly became
apparent: we try to cancel_timer_sync() a timer
from within itself. Fix that by making the function
aware of the context it is called from.
Reported-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
Please apply after Kalle confirms it fixes the problem.
net/mac80211/agg-rx.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
--- wireless-testing.orig/net/mac80211/agg-rx.c 2010-04-19 10:49:25.000000000 +0200
+++ wireless-testing/net/mac80211/agg-rx.c 2010-04-19 10:51:57.000000000 +0200
@@ -18,8 +18,9 @@
#include "ieee80211_i.h"
#include "driver-ops.h"
-void __ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
- u16 initiator, u16 reason)
+static void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
+ u16 initiator, u16 reason,
+ bool from_timer)
{
struct ieee80211_local *local = sta->local;
struct tid_ampdu_rx *tid_rx;
@@ -69,10 +70,17 @@ void __ieee80211_stop_rx_ba_session(stru
spin_unlock_bh(&sta->lock);
- del_timer_sync(&tid_rx->session_timer);
+ if (!from_timer)
+ del_timer_sync(&tid_rx->session_timer);
kfree(tid_rx);
}
+void __ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
+ u16 initiator, u16 reason)
+{
+ ___ieee80211_stop_rx_ba_session(sta, tid, initiator, reason, false);
+}
+
/*
* After accepting the AddBA Request we activated a timer,
* resetting it after each frame that arrives from the originator.
@@ -91,8 +99,8 @@ static void sta_rx_agg_session_timer_exp
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "rx session timer expired on tid %d\n", (u16)*ptid);
#endif
- __ieee80211_stop_rx_ba_session(sta, *ptid, WLAN_BACK_RECIPIENT,
- WLAN_REASON_QSTA_TIMEOUT);
+ ___ieee80211_stop_rx_ba_session(sta, *ptid, WLAN_BACK_RECIPIENT,
+ WLAN_REASON_QSTA_TIMEOUT, true);
}
static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *da, u16 tid,
^ permalink raw reply
* Re: [PATCH 7/9] mac80211: add flags for STBC (Space-Time Block Coding)
From: Johannes Berg @ 2010-04-19 8:59 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, lrodriguez
In-Reply-To: <4BCC1844.4030607@openwrt.org>
On Mon, 2010-04-19 at 10:45 +0200, Felix Fietkau wrote:
> On 2010-04-19 7:57 AM, Johannes Berg wrote:
> > On Sun, 2010-04-18 at 18:05 +0200, Felix Fietkau wrote:
> >
> >> >> + * @IEEE80211_TX_CTL_STBC: tells the driver to use Space-Time Block Coding
> >> >> + * (STBC) for this frame.
> >> >> */
> >> >> enum mac80211_tx_control_flags {
> >> >> IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
> >> >> @@ -299,6 +301,7 @@ enum mac80211_tx_control_flags {
> >> >> IEEE80211_TX_INTFL_HAS_RADIOTAP = BIT(20),
> >> >> IEEE80211_TX_INTFL_NL80211_FRAME_TX = BIT(21),
> >> >> IEEE80211_TX_CTL_LDPC = BIT(22),
> >> >> + IEEE80211_TX_CTL_STBC = BIT(23),
> >> >
> >> > What if the # of streams is different? That doesn't look sufficient.
> >
> >> Hm, you're right. I initially thought the combination of the MCS index
> >> and the STBC flag would be enough, but there are still some corner cases.
> >
> > Hm actually I guess that should be sufficient? What corner case are you
> > thinking of?
> Support for multi-rate retry and STBC with more than one stream on one
> side, using rates from both MCS0-7 and MCS8-15 in the rate series.
> Rx STBC for only one stream on the other side.
So the flag should be per rate entry instead, no?
johannes
^ permalink raw reply
* Re: [RFC] mac80211: sample survey implementation for mac80211 & hwsim
From: Holger Schurig @ 2010-04-19 8:58 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <201004191023.57987.holgerschurig@gmail.com>
Oh, that should have been [PATCH].
So much to copying subject lines from quilt patches without really reading.
--
DH3HS, http://www.holgerschurig.de
^ permalink raw reply
* [PATCH 2.6.34] mac80211: remove bogus TX agg state assignment
From: Johannes Berg @ 2010-04-19 8:48 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
When the addba timer expires but has no work to do,
it should not affect the state machine. If it does,
TX will not see the successfully established and we
can also crash trying to re-establish the session.
Cc: stable@kernel.org [2.6.32, 2.6.33]
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/agg-tx.c | 1 -
1 file changed, 1 deletion(-)
--- wireless-testing.orig/net/mac80211/agg-tx.c 2010-04-19 10:42:55.000000000 +0200
+++ wireless-testing/net/mac80211/agg-tx.c 2010-04-19 10:43:12.000000000 +0200
@@ -183,7 +183,6 @@ static void sta_addba_resp_timer_expired
HT_AGG_STATE_REQ_STOP_BA_MSK)) !=
HT_ADDBA_REQUESTED_MSK) {
spin_unlock_bh(&sta->lock);
- *state = HT_AGG_STATE_IDLE;
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "timer expired on tid %d but we are not "
"(or no longer) expecting addBA response there",
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox