* 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: [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: [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: 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
* 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: Philippe De Muyter @ 2010-04-19 15:00 UTC (permalink / raw)
To: Matthew Garrett; +Cc: Dan Williams, Larry Finger, linux-wireless
In-Reply-To: <20100419145107.GB8017@srcf.ucam.org>
On Mon, Apr 19, 2010 at 03:51:07PM +0100, Matthew Garrett wrote:
> 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?
Sorry, I cannot answer before friday (not my laptop).
Philippe
^ permalink raw reply
* Re: b43 'hardware blocked' but only keyboard/led touch button
From: Matthew Garrett @ 2010-04-19 15:06 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Dan Williams, Larry Finger, linux-wireless
In-Reply-To: <20100419150050.GA28290@frolo.macqel>
On Mon, Apr 19, 2010 at 05:00:50PM +0200, Philippe De Muyter wrote:
> On Mon, Apr 19, 2010 at 03:51:07PM +0100, Matthew Garrett wrote:
> > 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?
>
> Sorry, I cannot answer before friday (not my laptop).
No problem. The best command to run will be
rfkill list
and then just attach the output.
Thanks,
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* [PATCH] ath9k-htc: speedup disconnect handling
From: tom.leiming @ 2010-04-19 15:44 UTC (permalink / raw)
To: Sujith.Manoharan, lrodriguez; +Cc: linux-wireless, linville, Ming Lei
From: Ming Lei <tom.leiming@gmail.com>
This patch detects the disconnect in wmi register write path,
then speedup the disconnect handling.
---
drivers/net/wireless/ath/ath9k/hw.c | 2 ++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/wmi.c | 8 ++++++++
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 9aa40df..bcc48ff 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -111,6 +111,8 @@ bool ath9k_hw_wait(struct ath_hw *ah, u32 reg, u32 mask, u32 val, u32 timeout)
BUG_ON(timeout < AH_TIME_QUANTUM);
for (i = 0; i < (timeout / AH_TIME_QUANTUM); i++) {
+ if (AR_SREV_9271(ah) && ah->htc_disconnected)
+ break;
if ((REG_READ(ah, reg) & mask) == val)
return true;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 8158e8e..6b22158 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -635,6 +635,7 @@ struct ath_hw {
u32 ah_flags;
bool htc_reset_init;
+ bool htc_disconnected;
enum nl80211_iftype opmode;
enum ath9k_power_mode power_mode;
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index dc6c6fc..fbd44c7 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -279,6 +279,9 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
if (!wmi)
return -EINVAL;
+ if (ah->htc_disconnected)
+ return -ENODEV;
+
skb = alloc_skb(headroom + cmd_len, GFP_ATOMIC);
if (!skb)
return -ENOMEM;
@@ -324,6 +327,11 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
return 0;
out:
+ if (ret == -ENODEV) {
+ ah->htc_disconnected = 1;
+ ath_print(common, ATH_DBG_WMI,"HTC disconnected!\n");
+ }
+
ath_print(common, ATH_DBG_WMI,
"WMI failure for: %s\n", wmi_cmd_to_name(cmd_id));
mutex_unlock(&wmi->op_mutex);
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH v3 42/97] ath9k: Make bf_desc of ath_buf opaque
From: Pavel Roskin @ 2010-04-19 15:53 UTC (permalink / raw)
To: Felix Fietkau
Cc: Luis R. Rodriguez, linville, linux-wireless,
Vasanthakumar Thiagarajan
In-Reply-To: <4BC8E027.1030807@openwrt.org>
On Sat, 2010-04-17 at 00:09 +0200, Felix Fietkau wrote:
> > The obvious downside is that bf_desc becomes compatible with pointers of
> > any type.
> Because on AR9300 where it's used, it points to a struct ar9003_txc instead.
OK, fair enough.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Request for releasing b43-fwcutter
From: Michael Buesch @ 2010-04-19 15:53 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: b43-dev, linux-wireless
In-Reply-To: <k2kb170af451004190754udb8e9960h8a3cfe703566e76f@mail.gmail.com>
On Monday 19 April 2010 16:54:23 Rafał Miłecki wrote:
> 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.
Good idea. I released b43-fwcutter-013.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] mac80211: document IEEE80211_CONF_CHANGE_QoS
From: Pavel Roskin @ 2010-04-19 15:57 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Reinette Chatre, John W. Linville, wey-yi.w.guy,
Johannes Berg
In-Reply-To: <20100419092451.GA2696@dhcp-lab-161.englab.brq.redhat.com>
On Mon, 2010-04-19 at 11:24 +0200, Stanislaw Gruszka wrote:
> 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
Let's make it uppercase, please. The actual code is already uppercase.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [rt2x00] rt3070 fails to initialize with rt2800usb
From: Walter @ 2010-04-19 16:13 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: linux-wireless, users
> Thats odd, in compar-wireless, it already contains the
> lines:
>
> #ifdef CONFIG_RT2800USB_RT30XX
> <..snip..>
> /* Ralink */
> { USB_DEVICE(0x148f, 0x2070),
> USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x148f, 0x3070),
> USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x148f, 0x3071),
> USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x148f, 0x3072),
> USB_DEVICE_DATA(&rt2800usb_ops) },
> <..snip..>
> #endif
>
> So adding the USB ID does not need to be added.
>
> Ivo
It is odd. I followed exactly the same logic you have, but I'm adamant the module doesn't recognize the VID of card as it is. Lets get factual:
compat-wireless from March 28th. default install (make && make install) here is the output when the rt2800usb is loaded:
[21902.553231] Generic kernel compatibility enabled based on linux-next next-20100113
[21902.596351] cfg80211: Calling CRDA to update world regulatory domain
[21902.695076] usbcore: registered new interface driver rt2800usb
[21902.714019] cfg80211: World regulatory domain updated:
[21902.714026] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[21902.714032] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[21902.714036] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[21902.714041] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[21902.714045] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[21902.714050] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
modinfo rt2800usb |grep 3070 -- returns nothing
as soon as I add the 148f:rt3070 to:
/* Ralink */
{ USB_DEVICE(0x148f, 0x2770), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x148f, 0x2870), USB_DEVICE_DATA(&rt2800usb_ops) },
{ USB_DEVICE(0x148f, 0x3070), USB_DEVICE_DATA(&rt2800usb_ops) }, <--- manually added
/* Samsung */
rt2800usb recognizes the chip and initializes all operations:
[22310.272382] usb 5-2.4: new high speed USB device using ehci_hcd and address 10
[22310.381269] usb 5-2.4: configuration #1 chosen from 1 choice
[22310.416482] phy1: Selected rate control algorithm 'minstrel'
[22310.417403] Registered led device: rt2800usb-phy1::radio
[22310.417456] Registered led device: rt2800usb-phy1::assoc
[22310.417505] Registered led device: rt2800usb-phy1::quality
[22310.479159] udev: renamed network interface wlan0 to wlan2
[22310.483779] rt2800usb 5-2.4:1.0: firmware: requesting rt2870.bin
Now, modinfo rt2800usb |grep 3070 -- shows its OK:
alias: usb:v148Fp3070d*dc*dsc*dp*ic*isc*ip*
This is a longstanding bug from at least few months or so, I thought you were experimenting/adjusting the code and I figured it would be temporary, but it has been so long that I thought I had to report this now.
Walter.
^ permalink raw reply
* Re: [rt2x00] rt3070 fails to initialize with rt2800usb
From: Ivo van Doorn @ 2010-04-19 16:25 UTC (permalink / raw)
To: Walter; +Cc: linux-wireless, users
In-Reply-To: <79507.95340.qm@web56807.mail.re3.yahoo.com>
On Monday 19 April 2010, Walter wrote:
> > Thats odd, in compar-wireless, it already contains the
> > lines:
> >
> > #ifdef CONFIG_RT2800USB_RT30XX
> > <..snip..>
> > /* Ralink */
> > { USB_DEVICE(0x148f, 0x2070),
> > USB_DEVICE_DATA(&rt2800usb_ops) },
> > { USB_DEVICE(0x148f, 0x3070),
> > USB_DEVICE_DATA(&rt2800usb_ops) },
> > { USB_DEVICE(0x148f, 0x3071),
> > USB_DEVICE_DATA(&rt2800usb_ops) },
> > { USB_DEVICE(0x148f, 0x3072),
> > USB_DEVICE_DATA(&rt2800usb_ops) },
> > <..snip..>
> > #endif
> >
> > So adding the USB ID does not need to be added.
> >
> > Ivo
>
> It is odd. I followed exactly the same logic you have, but I'm adamant the module doesn't recognize the VID of card as it is. Lets get factual:
>
> compat-wireless from March 28th. default install (make && make install) here is the output when the rt2800usb is loaded:
>
> [21902.553231] Generic kernel compatibility enabled based on linux-next next-20100113
> [21902.596351] cfg80211: Calling CRDA to update world regulatory domain
> [21902.695076] usbcore: registered new interface driver rt2800usb
> [21902.714019] cfg80211: World regulatory domain updated:
> [21902.714026] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> [21902.714032] (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [21902.714036] (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [21902.714041] (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> [21902.714045] (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> [21902.714050] (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>
> modinfo rt2800usb |grep 3070 -- returns nothing
>
> as soon as I add the 148f:rt3070 to:
>
> /* Ralink */
> { USB_DEVICE(0x148f, 0x2770), USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x148f, 0x2870), USB_DEVICE_DATA(&rt2800usb_ops) },
> { USB_DEVICE(0x148f, 0x3070), USB_DEVICE_DATA(&rt2800usb_ops) }, <--- manually added
> /* Samsung */
>
> rt2800usb recognizes the chip and initializes all operations:
>
> [22310.272382] usb 5-2.4: new high speed USB device using ehci_hcd and address 10
> [22310.381269] usb 5-2.4: configuration #1 chosen from 1 choice
> [22310.416482] phy1: Selected rate control algorithm 'minstrel'
> [22310.417403] Registered led device: rt2800usb-phy1::radio
> [22310.417456] Registered led device: rt2800usb-phy1::assoc
> [22310.417505] Registered led device: rt2800usb-phy1::quality
> [22310.479159] udev: renamed network interface wlan0 to wlan2
> [22310.483779] rt2800usb 5-2.4:1.0: firmware: requesting rt2870.bin
>
> Now, modinfo rt2800usb |grep 3070 -- shows its OK:
>
> alias: usb:v148Fp3070d*dc*dsc*dp*ic*isc*ip*
>
>
> This is a longstanding bug from at least few months or so, I thought you were experimenting/adjusting the code and I figured it would be temporary, but it has been so long that I thought I had to report this now.
>
> Walter.
Just checked the wireless-compat package, but are you sure that the config file contains:
CONFIG_RT2800USB_RT30XX=y
and not the default:
# CONFIG_RT2800USB_RT30XX=y
Note the prefixed '#' which should be removed to enable the configuration option.
Ivo
^ permalink raw reply
* Re: rc80211_minstrel.c:70 WARNING with 2.6.34-rc4
From: Pavel Roskin @ 2010-04-19 16:34 UTC (permalink / raw)
To: Richard Zidlicky; +Cc: linux-wireless
In-Reply-To: <20100418085653.GA7345@linux-m68k.org>
On Sun, 2010-04-18 at 10:56 +0200, Richard Zidlicky wrote:
> Hi,
>
> I am getting tons of these http://www.kerneloops.org/submitresult.php?number=3048061,
> appears every packet triggers that.
The warning comes from the function rix_to_ndx() in rc80211_minstrel.c:
/* convert mac80211 rate index to local array index */
static inline int
rix_to_ndx(struct minstrel_sta_info *mi, int rix)
{
int i = rix;
for (i = rix; i >= 0; i--)
if (mi->r[i].rix == rix)
break;
WARN_ON(i < 0);
return i;
}
> Can provide lots of debugging info.
My impression is that WARN_ON is not warranted in that function, but it
would be interesting to know how you got to that point.
What driver are you using? What is the mode for the interface? What is
your hardware? Is there anything unusual you do that triggers the
warning? Are you using 5 GHz band by any chance? Are you using
2.6.34-rc4 or it's compat-wireless compiled for another kernel?
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Request for releasing b43-fwcutter
From: Rafał Miłecki @ 2010-04-19 16:45 UTC (permalink / raw)
To: Michael Buesch; +Cc: b43-dev, linux-wireless
In-Reply-To: <201004191753.44213.mb@bu3sch.de>
W dniu 19 kwietnia 2010 17:53 użytkownik Michael Buesch <mb@bu3sch.de> napisał:
> On Monday 19 April 2010 16:54:23 Rafał Miłecki wrote:
>> 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.
>
> Good idea. I released b43-fwcutter-013.
Thanks, http://wireless.kernel.org/en/users/Drivers/b43 updated.
--
Rafał
^ permalink raw reply
* Re: rc80211_minstrel.c:70 WARNING with 2.6.34-rc4
From: Richard Zidlicky @ 2010-04-19 17:41 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless
In-Reply-To: <1271694855.9026.51.camel@mj>
Hi,
> > I am getting tons of these http://www.kerneloops.org/submitresult.php?number=3048061,
> > appears every packet triggers that.
>
> The warning comes from the function rix_to_ndx() in rc80211_minstrel.c:
>
> /* convert mac80211 rate index to local array index */
> static inline int
> rix_to_ndx(struct minstrel_sta_info *mi, int rix)
> {
> int i = rix;
> for (i = rix; i >= 0; i--)
> if (mi->r[i].rix == rix)
> break;
> WARN_ON(i < 0);
> return i;
> }
>
> > Can provide lots of debugging info.
>
> My impression is that WARN_ON is not warranted in that function, but it
> would be interesting to know how you got to that point.
I am using the rt73usb, WEP, adhoc, fixed rate(11M) on both ends:
wlan0 IEEE 802.11bg ESSID:"XXXXXXXX"
Mode:Ad-Hoc Frequency:2.442 GHz Cell: F6:B2:CB:FC:62:6C
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key: XXXXXXXXXX
Power Management:on
It is 2.6.34-rc4, no compat-wireless.
As of unusual circumstances - the rt73usb driver has some bug that causes
very high retransmit rates. On the opposite end the ath5k driver complains "cant
handle jumbo frames".
I had it perfectly working some time ago but need to figure out which off the many
patches did it and apply it to the new kernel.
This might stress minstrel more than needed but otoh it was my impression that the
warning was triggered by every single packet.
Let me know if you want any more info.
Richard
^ permalink raw reply
* Re: rc80211_minstrel.c:70 WARNING with 2.6.34-rc4
From: Felix Fietkau @ 2010-04-19 17:41 UTC (permalink / raw)
To: Richard Zidlicky; +Cc: Pavel Roskin, linux-wireless
In-Reply-To: <20100419174100.GA5312@linux-m68k.org>
On 2010-04-19 7:41 PM, Richard Zidlicky wrote:
>
> Hi,
>
>> > I am getting tons of these http://www.kerneloops.org/submitresult.php?number=3048061,
>> > appears every packet triggers that.
>>
>> The warning comes from the function rix_to_ndx() in rc80211_minstrel.c:
>>
>> /* convert mac80211 rate index to local array index */
>> static inline int
>> rix_to_ndx(struct minstrel_sta_info *mi, int rix)
>> {
>> int i = rix;
>> for (i = rix; i >= 0; i--)
>> if (mi->r[i].rix == rix)
>> break;
>> WARN_ON(i < 0);
>> return i;
>> }
>>
>> > Can provide lots of debugging info.
>>
>> My impression is that WARN_ON is not warranted in that function, but it
>> would be interesting to know how you got to that point.
>
> I am using the rt73usb, WEP, adhoc, fixed rate(11M) on both ends:
>
> wlan0 IEEE 802.11bg ESSID:"XXXXXXXX"
> Mode:Ad-Hoc Frequency:2.442 GHz Cell: F6:B2:CB:FC:62:6C
> Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key: XXXXXXXXXX
> Power Management:on
>
> It is 2.6.34-rc4, no compat-wireless.
>
> As of unusual circumstances - the rt73usb driver has some bug that causes
> very high retransmit rates. On the opposite end the ath5k driver complains "cant
> handle jumbo frames".
> I had it perfectly working some time ago but need to figure out which off the many
> patches did it and apply it to the new kernel.
> This might stress minstrel more than needed but otoh it was my impression that the
> warning was triggered by every single packet.
>
> Let me know if you want any more info.
This warning typically shows up, whenever the driver reports a rate to
minstrel in the tx status that is not part of the supported/negotiated
rate set - that's the reason the index lookup above fails.
- Felix
^ permalink raw reply
* [PATCH] mac80211: pass HT changes to driver when off channel
From: Reinette Chatre @ 2010-04-19 17:46 UTC (permalink / raw)
To: johannes; +Cc: linville, linux-wireless, Reinette Chatre
From: Reinette Chatre <reinette.chatre@intel.com>
Since "mac80211: make off-channel work generic" drivers have not been
notified of configuration changes after association or authentication. This
caused more dependence on current state to ensure driver will be notified
when configuration changes occur. One such problem arises if off-channel is
in progress when HT information changes. Since HT is only enabled on the
"oper_channel" the driver will never be notified of this change. Usually
the driver is notified soon after of a BSS information change
(BSS_CHANGED_HT) ... but since the driver did not get a notification that
this is a HT channel the new BSS information does not make sense.
Fix this by also changing the off-channel information when HT is enabled
and thus cause driver to be notified correctly.
This fixes a problem in 4965 when associated with 5GHz 40MHz channel.
Without this patch the system can associate but is unable to transfer any
data, not even ping.
See http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2158
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
net/mac80211/mlme.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 35d8502..3133681 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -175,6 +175,8 @@ static u32 ieee80211_enable_ht(struct ieee80211_sub_if_data *sdata,
ht_changed = conf_is_ht(&local->hw.conf) != enable_ht ||
channel_type != local->hw.conf.channel_type;
+ if (local->tmp_channel)
+ local->tmp_channel_type = channel_type;
local->oper_channel_type = channel_type;
if (ht_changed) {
--
1.6.3.3
^ permalink raw reply related
* Re: iwlagn unexpected AddBA Req
From: reinette chatre @ 2010-04-19 17:50 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <m2p43e72e891004012145s2f344f7fo9b12044e9b895c06@mail.gmail.com>
On Thu, 2010-04-01 at 21:45 -0700, Luis R. Rodriguez wrote:
> [ 117.491303] unexpected AddBA Req from 00:22:6b:56:fd:e9 on tid 0
> [ 178.467383] unexpected AddBA Req from 00:22:6b:56:fd:e9 on tid 0
> [ 239.447236] unexpected AddBA Req from 00:22:6b:56:fd:e9 on tid 0
>
> I get a lof of these at spurious times against my WRT610N using
> today's wireless-testing on iwlagn.
If you still have this setup available, could you please try out the
recent patch "mac80211: pass HT changes to driver when off
channel" (http://thread.gmane.org/gmane.linux.kernel.wireless.general/49855 ) ?
Thank you
Reinette
^ permalink raw reply
* Re: rc80211_minstrel.c:70 WARNING with 2.6.34-rc4
From: Richard Zidlicky @ 2010-04-19 17:55 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Pavel Roskin, linux-wireless
In-Reply-To: <4BCC95CC.7030109@openwrt.org>
On Mon, Apr 19, 2010 at 07:41:32PM +0200, Felix Fietkau wrote:
> This warning typically shows up, whenever the driver reports a rate to
> minstrel in the tx status that is not part of the supported/negotiated
> rate set - that's the reason the index lookup above fails.
can that happen when both ends are configured to a fixed rate of 11M?
Richard
^ permalink raw reply
* [PATCH v2 3/9] ath9k: update the MCS mask for MCS16 and above
From: Felix Fietkau @ 2010-04-19 17:57 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
In-Reply-To: <1271699857-12366-2-git-send-email-nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index fcbb4a8..5d3d563 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -19,7 +19,7 @@
#define BITS_PER_BYTE 8
#define OFDM_PLCP_BITS 22
-#define HT_RC_2_MCS(_rc) ((_rc) & 0x0f)
+#define HT_RC_2_MCS(_rc) ((_rc) & 0x1f)
#define HT_RC_2_STREAMS(_rc) ((((_rc) & 0x78) >> 3) + 1)
#define L_STF 8
#define L_LTF 8
--
1.6.4.2
^ permalink raw reply related
* [PATCH v2 5/9] ath9k: reduce the bits_per_symbol table size, support more streams
From: Felix Fietkau @ 2010-04-19 17:57 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
In-Reply-To: <1271699857-12366-4-git-send-email-nbd@openwrt.org>
Instead of increasing bits_per_symbol for supporting more streams, keep
it single-stream only and multiply the values by the numer of streams.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 19 ++++++-------------
1 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 4078982..2237658 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -34,7 +34,7 @@
#define OFDM_SIFS_TIME 16
-static u32 bits_per_symbol[][2] = {
+static u16 bits_per_symbol[][2] = {
/* 20MHz 40MHz */
{ 26, 54 }, /* 0: BPSK */
{ 52, 108 }, /* 1: QPSK 1/2 */
@@ -44,14 +44,6 @@ static u32 bits_per_symbol[][2] = {
{ 208, 432 }, /* 5: 64-QAM 2/3 */
{ 234, 486 }, /* 6: 64-QAM 3/4 */
{ 260, 540 }, /* 7: 64-QAM 5/6 */
- { 52, 108 }, /* 8: BPSK */
- { 104, 216 }, /* 9: QPSK 1/2 */
- { 156, 324 }, /* 10: QPSK 3/4 */
- { 208, 432 }, /* 11: 16-QAM 1/2 */
- { 312, 648 }, /* 12: 16-QAM 3/4 */
- { 416, 864 }, /* 13: 64-QAM 2/3 */
- { 468, 972 }, /* 14: 64-QAM 3/4 */
- { 520, 1080 }, /* 15: 64-QAM 5/6 */
};
#define IS_HT_RATE(_rate) ((_rate) & 0x80)
@@ -601,7 +593,7 @@ static int ath_compute_num_delims(struct ath_softc *sc, struct ath_atx_tid *tid,
u32 nsymbits, nsymbols;
u16 minlen;
u8 flags, rix;
- int width, half_gi, ndelim, mindelim;
+ int width, streams, half_gi, ndelim, mindelim;
/* Select standard number of delimiters based on frame length alone */
ndelim = ATH_AGGR_GET_NDELIM(frmlen);
@@ -641,7 +633,8 @@ static int ath_compute_num_delims(struct ath_softc *sc, struct ath_atx_tid *tid,
if (nsymbols == 0)
nsymbols = 1;
- nsymbits = bits_per_symbol[rix][width];
+ streams = HT_RC_2_STREAMS(rix);
+ nsymbits = bits_per_symbol[rix % 8][width] * streams;
minlen = (nsymbols * nsymbits) / BITS_PER_BYTE;
if (frmlen < minlen) {
@@ -1533,8 +1526,9 @@ static u32 ath_pkt_duration(struct ath_softc *sc, u8 rix, struct ath_buf *bf,
pktlen = bf_isaggr(bf) ? bf->bf_al : bf->bf_frmlen;
/* find number of symbols: PLCP + data */
+ streams = HT_RC_2_STREAMS(rix);
nbits = (pktlen << 3) + OFDM_PLCP_BITS;
- nsymbits = bits_per_symbol[rix][width];
+ nsymbits = bits_per_symbol[rix % 8][width] * streams;
nsymbols = (nbits + nsymbits - 1) / nsymbits;
if (!half_gi)
@@ -1543,7 +1537,6 @@ static u32 ath_pkt_duration(struct ath_softc *sc, u8 rix, struct ath_buf *bf,
duration = SYMBOL_TIME_HALFGI(nsymbols);
/* addup duration for legacy/ht training and signal fields */
- streams = HT_RC_2_STREAMS(rix);
duration += L_STF + L_LTF + L_SIG + HT_SIG + HT_STF + HT_LTF(streams);
return duration;
--
1.6.4.2
^ permalink raw reply related
* [PATCH v2 8/9] ath9k: add support for Tx and Rx STBC
From: Felix Fietkau @ 2010-04-19 17:57 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
In-Reply-To: <1271699857-12366-7-git-send-email-nbd@openwrt.org>
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
^ permalink raw reply related
* [PATCH v2 7/9] mac80211: add flags for STBC (Space-Time Block Coding)
From: Felix Fietkau @ 2010-04-19 17:57 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
In-Reply-To: <1271699857-12366-6-git-send-email-nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
include/linux/ieee80211.h | 1 +
include/net/mac80211.h | 4 ++++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 1252ba1..97b2eae 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -876,6 +876,7 @@ struct ieee80211_ht_cap {
#define IEEE80211_HT_CAP_SGI_40 0x0040
#define IEEE80211_HT_CAP_TX_STBC 0x0080
#define IEEE80211_HT_CAP_RX_STBC 0x0300
+#define IEEE80211_HT_CAP_RX_STBC_SHIFT 8
#define IEEE80211_HT_CAP_DELAY_BA 0x0400
#define IEEE80211_HT_CAP_MAX_AMSDU 0x0800
#define IEEE80211_HT_CAP_DSSSCCK40 0x1000
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 75056dd..3d85b0a 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -275,6 +275,8 @@ struct ieee80211_bss_conf {
* MLME command (internal to mac80211 to figure out whether to send TX
* status to user space)
* @IEEE80211_TX_CTL_LDPC: tells the driver to use LDPC for this frame
+ * @IEEE80211_TX_CTL_STBC: Enables Space-Time Block Coding (STBC) for this
+ * frame and selects the maximum number of streams that it can use.
*/
enum mac80211_tx_control_flags {
IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
@@ -299,6 +301,8 @@ 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) | BIT(24),
+#define IEEE80211_TX_CTL_STBC_SHIFT 23
};
/**
--
1.6.4.2
^ permalink raw reply related
* [PATCH v2 4/9] ath9k: update the ath_max_4ms_framelen table
From: Felix Fietkau @ 2010-04-19 17:57 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
In-Reply-To: <1271699857-12366-3-git-send-email-nbd@openwrt.org>
Include MCS0-31 and also add SGI for HT20. This makes it
possible to support more different rate combinations with
newer hardware.
Based on a patch by Selvam. T.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 41 +++++++++++++++++++++-----------
1 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 5d3d563..4078982 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -71,24 +71,36 @@ static void ath_tx_rc_status(struct ath_buf *bf, struct ath_tx_status *ts,
int nbad, int txok, bool update_rc);
enum {
- MCS_DEFAULT,
+ MCS_HT20,
+ MCS_HT20_SGI,
MCS_HT40,
MCS_HT40_SGI,
};
-static int ath_max_4ms_framelen[3][16] = {
- [MCS_DEFAULT] = {
- 3216, 6434, 9650, 12868, 19304, 25740, 28956, 32180,
- 6430, 12860, 19300, 25736, 38600, 51472, 57890, 64320,
+static int ath_max_4ms_framelen[4][32] = {
+ [MCS_HT20] = {
+ 3212, 6432, 9648, 12864, 19300, 25736, 28952, 32172,
+ 6424, 12852, 19280, 25708, 38568, 51424, 57852, 64280,
+ 9628, 19260, 28896, 38528, 57792, 65532, 65532, 65532,
+ 12828, 25656, 38488, 51320, 65532, 65532, 65532, 65532,
+ },
+ [MCS_HT20_SGI] = {
+ 3572, 7144, 10720, 14296, 21444, 28596, 32172, 35744,
+ 7140, 14284, 21428, 28568, 42856, 57144, 64288, 65532,
+ 10700, 21408, 32112, 42816, 64228, 65532, 65532, 65532,
+ 14256, 28516, 42780, 57040, 65532, 65532, 65532, 65532,
},
[MCS_HT40] = {
- 6684, 13368, 20052, 26738, 40104, 53476, 60156, 66840,
- 13360, 26720, 40080, 53440, 80160, 106880, 120240, 133600,
+ 6680, 13360, 20044, 26724, 40092, 53456, 60140, 65532,
+ 13348, 26700, 40052, 53400, 65532, 65532, 65532, 65532,
+ 20004, 40008, 60016, 65532, 65532, 65532, 65532, 65532,
+ 26644, 53292, 65532, 65532, 65532, 65532, 65532, 65532,
},
[MCS_HT40_SGI] = {
- /* TODO: Only MCS 7 and 15 updated, recalculate the rest */
- 6684, 13368, 20052, 26738, 40104, 53476, 60156, 74200,
- 13360, 26720, 40080, 53440, 80160, 106880, 120240, 148400,
+ 7420, 14844, 22272, 29696, 44544, 59396, 65532, 65532,
+ 14832, 29668, 44504, 59340, 65532, 65532, 65532, 65532,
+ 22232, 44464, 65532, 65532, 65532, 65532, 65532, 65532,
+ 29616, 59232, 65532, 65532, 65532, 65532, 65532, 65532,
}
};
@@ -538,12 +550,13 @@ static u32 ath_lookup_rate(struct ath_softc *sc, struct ath_buf *bf,
break;
}
- if (rates[i].flags & IEEE80211_TX_RC_SHORT_GI)
- modeidx = MCS_HT40_SGI;
- else if (rates[i].flags & IEEE80211_TX_RC_40_MHZ_WIDTH)
+ if (rates[i].flags & IEEE80211_TX_RC_40_MHZ_WIDTH)
modeidx = MCS_HT40;
else
- modeidx = MCS_DEFAULT;
+ modeidx = MCS_HT20;
+
+ if (rates[i].flags & IEEE80211_TX_RC_SHORT_GI)
+ modeidx++;
frmlen = ath_max_4ms_framelen[modeidx][rates[i].idx];
max_4ms_framelen = min(max_4ms_framelen, frmlen);
--
1.6.4.2
^ permalink raw reply related
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