* [PATCH 6/6] ath: Fix WEP hardware encryption
From: Bruno Randolf @ 2011-01-25 4:15 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
In-Reply-To: <20110125041522.6944.22566.stgit@localhost6.localdomain6>
In AP mode hardware encryption for WEP was not used on the RX side because
there was a mismatch in the key indices. The key index in the WLAN header is
0-3 while the hardware key cache was configured for key indices >= 4. This is
ok for transmit but received packets were not decrypted in HW and therefore
mac80211 had to decrypt them in SW - this can be easily seen by adding some
debug prints in mac80211/wep.c (around line 296). I have noticed it by watching
the system CPU load under high traffic.
This patch configures WEP keys into the "standard" key indices 0-4 which were
reserved for that.
Tested with ath5k on a 600MHz mips board the difference is ~15% CPU load (with
this patch) vs. ~45% CPU load (before) when the AP receives 28Mbps of WEP
encrypted data.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/key.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/key.c b/drivers/net/wireless/ath/key.c
index 5d465e5..5748dae 100644
--- a/drivers/net/wireless/ath/key.c
+++ b/drivers/net/wireless/ath/key.c
@@ -465,6 +465,16 @@ int ath_key_config(struct ath_common *common,
hk.kv_len = key->keylen;
memcpy(hk.kv_val, key->key, key->keylen);
+ /* set WEP keys directly to index */
+ if ((key->cipher == WLAN_CIPHER_SUITE_WEP40 ||
+ key->cipher == WLAN_CIPHER_SUITE_WEP104) && key->keyidx < 4) {
+ ret = ath_hw_set_keycache_entry(common, key->keyidx, &hk, NULL);
+ if (!ret)
+ return -EIO;
+ set_bit(key->keyidx, common->keymap);
+ return key->keyidx;
+ }
+
if (!(key->flags & IEEE80211_KEY_FLAG_PAIRWISE)) {
switch (vif->type) {
case NL80211_IFTYPE_AP:
@@ -541,10 +551,8 @@ EXPORT_SYMBOL(ath_key_config);
void ath_key_delete(struct ath_common *common, struct ieee80211_key_conf *key)
{
ath_hw_keyreset(common, key->hw_key_idx);
- if (key->hw_key_idx < IEEE80211_WEP_NKID)
- return;
-
clear_bit(key->hw_key_idx, common->keymap);
+
if (key->cipher != WLAN_CIPHER_SUITE_TKIP)
return;
^ permalink raw reply related
* [PATCH 5/6] ath9k: Remove unused IEEE80211_WEP_NKID
From: Bruno Randolf @ 2011-01-25 4:15 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
In-Reply-To: <20110125041522.6944.22566.stgit@localhost6.localdomain6>
IEEE80211_WEP_NKID is not used in ath9k any more since the key handling code
has been moved to ath/.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 -
drivers/net/wireless/ath/ath9k/common.h | 2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index dab0271..3472b84 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -537,7 +537,6 @@ struct ath_ant_comb {
#define ATH_CABQ_READY_TIME 80 /* % of beacon interval */
#define ATH_MAX_SW_RETRIES 10
#define ATH_CHAN_MAX 255
-#define IEEE80211_WEP_NKID 4 /* number of key ids */
#define ATH_TXPOWER_MAX 100 /* .5 dBm units */
#define ATH_RATE_DUMMY_MARKER 0
diff --git a/drivers/net/wireless/ath/ath9k/common.h b/drivers/net/wireless/ath/ath9k/common.h
index a126bdd..4c7020b 100644
--- a/drivers/net/wireless/ath/ath9k/common.h
+++ b/drivers/net/wireless/ath/ath9k/common.h
@@ -23,8 +23,6 @@
/* Common header for Atheros 802.11n base driver cores */
-#define IEEE80211_WEP_NKID 4
-
#define WME_NUM_TID 16
#define WME_BA_BMP_SIZE 64
#define WME_MAX_BA WME_BA_BMP_SIZE
^ permalink raw reply related
* [PATCH 4/6] ath5k: Enable 802.11j 4.9GHz frequencies
From: Bruno Randolf @ 2011-01-25 4:15 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
In-Reply-To: <20110125041522.6944.22566.stgit@localhost6.localdomain6>
This enables 4.9GHz frequencies in ath5k if they are allowed as indicated by
the regulatory domain code. Currently this is MKK9_MKKC (0xfe).
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/ath5k/caps.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/caps.c b/drivers/net/wireless/ath/ath5k/caps.c
index 39baee1..f77e8a7 100644
--- a/drivers/net/wireless/ath/ath5k/caps.c
+++ b/drivers/net/wireless/ath/ath5k/caps.c
@@ -57,9 +57,8 @@ int ath5k_hw_set_capabilities(struct ath5k_hw *ah)
* XXX current ieee80211 implementation because the IEEE
* XXX channel mapping does not support negative channel
* XXX numbers (2312MHz is channel -19). Of course, this
- * XXX doesn't matter because these channels are out of range
- * XXX but some regulation domains like MKK (Japan) will
- * XXX support frequencies somewhere around 4.8GHz.
+ * XXX doesn't matter because these channels are out of the
+ * XXX legal range.
*/
/*
@@ -67,8 +66,10 @@ int ath5k_hw_set_capabilities(struct ath5k_hw *ah)
*/
if (AR5K_EEPROM_HDR_11A(ee_header)) {
- /* 4920 */
- caps->cap_range.range_5ghz_min = 5005;
+ if (ath_is_49ghz_allowed(caps->cap_eeprom.ee_regdomain))
+ caps->cap_range.range_5ghz_min = 4920;
+ else
+ caps->cap_range.range_5ghz_min = 5005;
caps->cap_range.range_5ghz_max = 6100;
/* Set supported modes */
^ permalink raw reply related
* [PATCH 3/6] ath: Add function to check if 4.9GHz channels are allowed
From: Bruno Randolf @ 2011-01-25 4:15 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
In-Reply-To: <20110125041522.6944.22566.stgit@localhost6.localdomain6>
This adds a helper function to ath/regd.c which can be asked if 4.9GHz channels
are allowed for a given regulatory domain code. This keeps the knowledge of
regdomains and defines like MKK9_MKKC in one place. I'm passing the regdomain
code instead of the ath_regulatory structure because this needs to be called
quite early in the driver inititalization where ath_regulatory is not available
yet in ath5k.
I'm using MKK9_MKKC only because this is the regdomain in the 802.11j enabled
sample cards we got from our vendor. I found some hints in HAL code that this
is used by Atheros to indicate 4.9GHz channels support and that there might be
other domain codes as well, but as I don't have any documentation I'm just
putting in what I need right now. It can be extended later.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/regd.c | 7 +++++++
drivers/net/wireless/ath/regd.h | 1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index 2b14775..f828f29 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -158,6 +158,13 @@ ieee80211_regdomain *ath_world_regdomain(struct ath_regulatory *reg)
}
}
+bool ath_is_49ghz_allowed(u16 regdomain)
+{
+ /* possibly more */
+ return regdomain == MKK9_MKKC;
+}
+EXPORT_SYMBOL(ath_is_49ghz_allowed);
+
/* Frequency is one where radar detection is required */
static bool ath_is_radar_freq(u16 center_freq)
{
diff --git a/drivers/net/wireless/ath/regd.h b/drivers/net/wireless/ath/regd.h
index 345dd97..172f63f 100644
--- a/drivers/net/wireless/ath/regd.h
+++ b/drivers/net/wireless/ath/regd.h
@@ -250,6 +250,7 @@ enum CountryCode {
};
bool ath_is_world_regd(struct ath_regulatory *reg);
+bool ath_is_49ghz_allowed(u16 redomain);
int ath_regd_init(struct ath_regulatory *reg, struct wiphy *wiphy,
int (*reg_notifier)(struct wiphy *wiphy,
struct regulatory_request *request));
^ permalink raw reply related
* [PATCH 2/6] ath5k: Use local variable for capabilities
From: Bruno Randolf @ 2011-01-25 4:15 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
In-Reply-To: <20110125041522.6944.22566.stgit@localhost6.localdomain6>
Shorten some lines and make code more readable.
Signed-off-by: Bruno Randolf <br1@einfach.org>
---
drivers/net/wireless/ath/ath5k/caps.c | 39 +++++++++++++++------------------
1 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/caps.c b/drivers/net/wireless/ath/ath5k/caps.c
index 31cad80..39baee1 100644
--- a/drivers/net/wireless/ath/ath5k/caps.c
+++ b/drivers/net/wireless/ath/ath5k/caps.c
@@ -32,23 +32,24 @@
*/
int ath5k_hw_set_capabilities(struct ath5k_hw *ah)
{
+ struct ath5k_capabilities *caps = &ah->ah_capabilities;
u16 ee_header;
/* Capabilities stored in the EEPROM */
- ee_header = ah->ah_capabilities.cap_eeprom.ee_header;
+ ee_header = caps->cap_eeprom.ee_header;
if (ah->ah_version == AR5K_AR5210) {
/*
* Set radio capabilities
* (The AR5110 only supports the middle 5GHz band)
*/
- ah->ah_capabilities.cap_range.range_5ghz_min = 5120;
- ah->ah_capabilities.cap_range.range_5ghz_max = 5430;
- ah->ah_capabilities.cap_range.range_2ghz_min = 0;
- ah->ah_capabilities.cap_range.range_2ghz_max = 0;
+ caps->cap_range.range_5ghz_min = 5120;
+ caps->cap_range.range_5ghz_max = 5430;
+ caps->cap_range.range_2ghz_min = 0;
+ caps->cap_range.range_2ghz_max = 0;
/* Set supported modes */
- __set_bit(AR5K_MODE_11A, ah->ah_capabilities.cap_mode);
+ __set_bit(AR5K_MODE_11A, caps->cap_mode);
} else {
/*
* XXX The tranceiver supports frequencies from 4920 to 6100GHz
@@ -67,12 +68,11 @@ int ath5k_hw_set_capabilities(struct ath5k_hw *ah)
if (AR5K_EEPROM_HDR_11A(ee_header)) {
/* 4920 */
- ah->ah_capabilities.cap_range.range_5ghz_min = 5005;
- ah->ah_capabilities.cap_range.range_5ghz_max = 6100;
+ caps->cap_range.range_5ghz_min = 5005;
+ caps->cap_range.range_5ghz_max = 6100;
/* Set supported modes */
- __set_bit(AR5K_MODE_11A,
- ah->ah_capabilities.cap_mode);
+ __set_bit(AR5K_MODE_11A, caps->cap_mode);
}
/* Enable 802.11b if a 2GHz capable radio (2111/5112) is
@@ -81,32 +81,29 @@ int ath5k_hw_set_capabilities(struct ath5k_hw *ah)
(AR5K_EEPROM_HDR_11G(ee_header) &&
ah->ah_version != AR5K_AR5211)) {
/* 2312 */
- ah->ah_capabilities.cap_range.range_2ghz_min = 2412;
- ah->ah_capabilities.cap_range.range_2ghz_max = 2732;
+ caps->cap_range.range_2ghz_min = 2412;
+ caps->cap_range.range_2ghz_max = 2732;
if (AR5K_EEPROM_HDR_11B(ee_header))
- __set_bit(AR5K_MODE_11B,
- ah->ah_capabilities.cap_mode);
+ __set_bit(AR5K_MODE_11B, caps->cap_mode);
if (AR5K_EEPROM_HDR_11G(ee_header) &&
ah->ah_version != AR5K_AR5211)
- __set_bit(AR5K_MODE_11G,
- ah->ah_capabilities.cap_mode);
+ __set_bit(AR5K_MODE_11G, caps->cap_mode);
}
}
/* Set number of supported TX queues */
if (ah->ah_version == AR5K_AR5210)
- ah->ah_capabilities.cap_queues.q_tx_num =
- AR5K_NUM_TX_QUEUES_NOQCU;
+ caps->cap_queues.q_tx_num = AR5K_NUM_TX_QUEUES_NOQCU;
else
- ah->ah_capabilities.cap_queues.q_tx_num = AR5K_NUM_TX_QUEUES;
+ caps->cap_queues.q_tx_num = AR5K_NUM_TX_QUEUES;
/* newer hardware has PHY error counters */
if (ah->ah_mac_srev >= AR5K_SREV_AR5213A)
- ah->ah_capabilities.cap_has_phyerr_counters = true;
+ caps->cap_has_phyerr_counters = true;
else
- ah->ah_capabilities.cap_has_phyerr_counters = false;
+ caps->cap_has_phyerr_counters = false;
return 0;
}
^ permalink raw reply related
* [PATCH 1/6] ath5k: ath5k_setup_channels cleanup and whitespace
From: Bruno Randolf @ 2011-01-25 4:15 UTC (permalink / raw)
To: linville; +Cc: ath5k-devel, linux-wireless
Remove useless test_bit - it's not going to happen because of the way this
function is called only when that bit is set.
And fix some whitespace.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Acked-by: Bob Copeland <me@bobcopeland.com>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
---
Has this been lost from my last series?
---
drivers/net/wireless/ath/ath5k/base.c | 11 +++--------
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 14377ac..dae0bdc 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -262,21 +262,16 @@ static bool ath5k_is_standard_channel(short chan, enum ieee80211_band band)
}
static unsigned int
-ath5k_setup_channels(struct ath5k_hw *ah,
- struct ieee80211_channel *channels,
- unsigned int mode,
- unsigned int max)
+ath5k_setup_channels(struct ath5k_hw *ah, struct ieee80211_channel *channels,
+ unsigned int mode, unsigned int max)
{
unsigned int count, size, chfreq, freq, ch;
enum ieee80211_band band;
- if (!test_bit(mode, ah->ah_modes))
- return 0;
-
switch (mode) {
case AR5K_MODE_11A:
/* 1..220, but 2GHz frequencies are filtered by check_channel */
- size = 220 ;
+ size = 220;
chfreq = CHANNEL_5GHZ;
band = IEEE80211_BAND_5GHZ;
break;
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: Fix power save usage count imbalance on deinit
From: Paul Stewart @ 2011-01-25 0:03 UTC (permalink / raw)
To: Rajkumar Manoharan
Cc: Luis R. Rodriguez, Rajkumar Manoharan,
linux-wireless@vger.kernel.org
In-Reply-To: <20110123072116.GA7170@vmraj-lnx.users.atheros.com>
This change doesn't regress the issue with scan-during-suspend. The
other regression you should test for is that the system really does
continue to honor powersave after a suspend-resume cycle (verify
null-functions and drop in power consumption). You should be able to
do that yourself, and I'd suggest testing for this case as well before
committing any changes to powersave.
--
Paul
On Sat, Jan 22, 2011 at 11:21 PM, Rajkumar Manoharan
<rmanoharan@atheros.com> wrote:
> On Fri, Jan 21, 2011 at 04:32:20AM +0530, Luis R. Rodriguez wrote:
>> On Wed, Jan 19, 2011 at 11:51 PM, Rajkumar Manoharan
>> <rmanoharan@atheros.com> wrote:
>> > On Thu, Jan 20, 2011 at 12:54:56AM +0530, Luis R. Rodriguez wrote:
>> >> On Wed, Jan 19, 2011 at 7:47 AM, Rajkumar Manoharan
>> >> <rmanoharan@atheros.com> wrote:
>> >> > Upon unloading the driver, the ps_usecount is incremented
>> >> > before configuring gpio registers in deinit_device.
>> >> > But it is failed to restore the ps_usecount after that.
>> >> > The problem is that the chip is moved to FULL SLEEP
>> >> > by radio_disable when mac80211 is reporting as idle
>> >> > though ps_usecount is not zero.
>> >> >
>> >> > This patch retores ps_usecount properly and ensures that
>> >> > the chip is always moved to full sleep only if ps usage
>> >> > counte is zero which helps in debugging. And also fixes
>> >> > the following warning.
>> >> >
>> >> > ath: DMA failed to stop in 10 ms AR_CR=0xdeadbeef AR_DIAG_SW=0xdeadbeef
>> >> > ath: Could not stop RX, we could be confusing the DMA engine when we
>> >> > start RX up
>> >> > ------------[ cut here ]------------
>> >> > WARNING: at drivers/net/wireless/ath/ath9k/recv.c:536
>> >> > ath_stoprecv+0xf4/0x100 [ath9k]()
>> >> >
>> >>
>> >> Are you sure this hunk does not regress the suspend/resume case when
>> >> using the new dbus API?
>> >>
>> > I verfied the suspend/resume case with AR9280 card. But I don't
>> > understand how the new dbus API is related with this patch?
>>
>> Paul, if you get a chance to give this a spin before it gets merged
>> it'd be appreciated.
> Paul,
> Did you get a chance to evaluate this patch? Shall we proceed further?
>
> --
> Rajkumar
>
^ permalink raw reply
* Re: Kernel Panic wlc_mac80211.c Line 6093
From: Henry Ptasinski @ 2011-01-24 22:23 UTC (permalink / raw)
To: Jamie Kitson
Cc: Arend Van Spriel, linux-wireless@vger.kernel.org, Brett Rudley,
Henry Ptasinski, rvossen
In-Reply-To: <AANLkTikB9=xKS0jX7Rz9qLOctaY+Rxv-9HH3p=Ydza85@mail.gmail.com>
On Mon, Jan 24, 2011 at 01:47:37PM -0800, Jamie Kitson wrote:
> > too quote a gremlin: feed me (with any debug experiences you may have).
>
> Well for some reason when I got home today my machine crashed every
> time it was bringing the wireless interface up until I disabled the
> brcm80211 module, even without the noapic option. The crash looks a
> little different:
>
> http://farm6.static.flickr.com/5216/5385766744_632eb67670_b.jpg
>
> Did you notice that someone on that Arch thread suggested that it
> might be solved by using n mode only on the wireless router?
>
> https://bbs.archlinux.org/viewtopic.php?pid=882237#p882237
Thanks, a little more data to work with.
Roland has a lead on a locking issue that will hopefully resolve the MP
crashes. However, it does look like there are a couple different issues, and
testing mixed vs. 11n-only networks may shed some more light on the other
issue.
- Henry
^ permalink raw reply
* wl12xx tree rebased
From: Luciano Coelho @ 2011-01-24 22:13 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
I have rebased the wl12xx master and wl12xx-next branches with latest
wireless-testing and wireless-next, respectively, as a base.
Please update your local trees.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v2] mac80211: Optimize scans on current operating channel.
From: Ben Greear @ 2011-01-24 22:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295774293.3639.15.camel@jlt3.sipsolutions.net>
On 01/23/2011 01:18 AM, Johannes Berg wrote:
> Also, are you sure the filter configuration works correctly this way? If
> you can, I'd like to look at a binary trace of the commands going to the
> device with this change: "trace-cmd record -e mac80211".
I uploaded two trace files. One that scans the single operating
channel, and a second that scans all channels. This is with my -v2
patch applied, using ath9k as the driver. There are two virtual
STA interfaces configured on this system for this test.
http://www.candelatech.com/~greearb/trace-scan-all.dat.bz2
http://www.candelatech.com/~greearb/trace-scan-one.dat.bz2
Please let me know what you think.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: [PATCH] brcm80211: fix error report string
From: Brett Rudley @ 2011-01-24 21:57 UTC (permalink / raw)
To: Rafał Miłecki, Gustavo F. Padovan
Cc: Henry Ptasinski, Dowan Kim, vossen@broadcom.com, Arend Van Spriel,
linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTi=GqWNd6yu0CeWAzt9ZRgCDkFRgwMExZiqEUr3Z@mail.gmail.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSYWZhxYIgTWnFgmVja2kgW21h
aWx0bzp6YWplYzVAZ21haWwuY29tXQ0KPiBTZW50OiBNb25kYXksIEphbnVhcnkgMjQsIDIwMTEg
MToxNyBQTQ0KPiBUbzogR3VzdGF2byBGLiBQYWRvdmFuDQo+IENjOiBCcmV0dCBSdWRsZXk7IEhl
bnJ5IFB0YXNpbnNraTsgRG93YW4gS2ltOyB2b3NzZW5AYnJvYWRjb20uY29tOyBBcmVuZA0KPiBW
YW4gU3ByaWVsOyBsaW51eC13aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6
IFtQQVRDSF0gYnJjbTgwMjExOiBmaXggZXJyb3IgcmVwb3J0IHN0cmluZw0KPiANCj4gMjAxMS8x
LzI0IEd1c3Rhdm8gRi4gUGFkb3ZhbiA8cGFkb3ZhbkBwcm9mdXNpb24ubW9iaT46DQo+ID4gU2ln
bmVkLW9mZi1ieTogR3VzdGF2byBGLiBQYWRvdmFuIDxwYWRvdmFuQHByb2Z1c2lvbi5tb2JpPg0K
PiA+IC0tLQ0KPiA+IMKgZHJpdmVycy9zdGFnaW5nL2JyY204MDIxMS9zeXMvd2xjX21hYzgwMjEx
LmMgfCDCoCDCoDIgKy0NCj4gPiDCoDEgZmlsZXMgY2hhbmdlZCwgMSBpbnNlcnRpb25zKCspLCAx
IGRlbGV0aW9ucygtKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvc3RhZ2luZy9icmNt
ODAyMTEvc3lzL3dsY19tYWM4MDIxMS5jDQo+IGIvZHJpdmVycy9zdGFnaW5nL2JyY204MDIxMS9z
eXMvd2xjX21hYzgwMjExLmMNCj4gPiBpbmRleCA1ZWI0MWQ2Li5lZTFiY2M1IDEwMDY0NA0KPiA+
IC0tLSBhL2RyaXZlcnMvc3RhZ2luZy9icmNtODAyMTEvc3lzL3dsY19tYWM4MDIxMS5jDQo+ID4g
KysrIGIvZHJpdmVycy9zdGFnaW5nL2JyY204MDIxMS9zeXMvd2xjX21hYzgwMjExLmMNCj4gPiBA
QCAtNjkxMCw3ICs2OTEwLDcgQEAgcHJlcF9tYWM4MDIxMV9zdGF0dXMoc3RydWN0IHdsY19pbmZv
ICp3bGMsDQo+IGQxMXJ4aGRyX3QgKnJ4aCwgc3RydWN0IHNrX2J1ZmYgKnAsDQo+ID4gwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqBwcmVhbWJsZSA9IDA7DQo+ID4gwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqBpZiAoSVNfQ0NLKHJzcGVjKSkgew0KPiA+IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
IMKgIMKgaWYgKHJ4aC0+UGh5UnhTdGF0dXNfMCAmIFBSWFMwX1NIT1JUSCkNCj4gPiAtIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFdMX0VSUk9SKCJTaG9ydCBD
Q0tcbiIpOw0KPiA+ICsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgV0xfRVJST1IoIiVzOiBTaG9ydCBDQ0tcbiwgX19mdW5jX18iKTsNCj4gDQo+IEkgaGF2ZSBu
byBpZGVhIGhvdyBXTF9FUlJPUiB3b3JrcywgYnV0IGFyZSB5b3Ugc3VyZSBvZiB0aGF0Pw0KPiAN
Cj4gWW91IHdyb3RlOg0KPiAiJXM6IFNob3J0IENDS1xuLCBfX2Z1bmNfXyINCj4gDQo+IERpZG4n
dCB5b3UgbWVhbjoNCj4gIiVzOiBTaG9ydCBDQ0tcbiIsIF9fZnVuY19fDQo+ID8NCj4gDQoNClJh
ZmFsJ3Mgc3VnZ2VzdGlvbiBpcyBjb3JyZWN0LCB0aGUgcGF0Y2ggd2FzIGluY29ycmVjdC4NCihH
b29kIGV5ZXMsIFJhZmFsKQ0KDQpCcmV0dA0KDQo+IC0tDQo+IFJhZmHFgg0KDQo=
^ permalink raw reply
* Re: Kernel Panic wlc_mac80211.c Line 6093
From: Jamie Kitson @ 2011-01-24 21:47 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless@vger.kernel.org, Brett Rudley
In-Reply-To: <op.vpte6up33ri7v4@arend-laptop>
> too quote a gremlin: feed me (with any debug experiences you may have).
Well for some reason when I got home today my machine crashed every
time it was bringing the wireless interface up until I disabled the
brcm80211 module, even without the noapic option. The crash looks a
little different:
http://farm6.static.flickr.com/5216/5385766744_632eb67670_b.jpg
Did you notice that someone on that Arch thread suggested that it
might be solved by using n mode only on the wireless router?
https://bbs.archlinux.org/viewtopic.php?pid=882237#p882237
Jamie
^ permalink raw reply
* Re: [PATCH] wl12xx: disable auto-arp
From: Luciano Coelho @ 2011-01-24 21:45 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295893143-6981-1-git-send-email-eliad@wizery.com>
On Mon, 2011-01-24 at 19:19 +0100, Eliad Peller wrote:
> The auto-arp feature sometimes has unexpected side effects (e.g. firmware
> crashes, no ARP replies, etc.)
> disable it until it will be solved.
>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
Damn that we're having problems with this feature again. :( It looked so
promising!
Anyway, applied this, let's hope the issue can be fixed in the near
future.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCHv4] wl12xx: Increase scan channel dwell time for passive scans
From: Luciano Coelho @ 2011-01-24 21:36 UTC (permalink / raw)
To: juuso.oikarinen@nokia.com; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295848914-3765-1-git-send-email-juuso.oikarinen@nokia.com>
On Mon, 2011-01-24 at 07:01 +0100, juuso.oikarinen@nokia.com wrote:
> From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
>
> Below, mTU is milli-TU (TU/1000).
>
> The passive scan channel dwell time currently used is 30-60mTU. A typical
> beacon interval for AP's is 100TU. This leads to a ~30% worst-case probability
> of finding an AP via passive scanning.
>
> For 5GHz bands for DFS frequencies passive scanning is the only scanning
> option. Hence for these, the probability of finding an AP is very low.
>
> To fix this, increase the passive channel scan dwell times (also the early
> leave value, as 5GHz channels are still typically very silent.) Use a value
> of 100TU, because that covers most typical AP configurations.
>
> Based on testing the probability of finding an AP (100TU beacon interval) on
> a single scan round are as follows (based on 100 iterations):
>
> dwell min/max (TU) | probability
> ---------------------+------------
> 30/60 | 35%
> 60/60 | 56%
> 80/80 | 77%
> 100/100 | 100%
>
> Total scan times now and after the change:
>
> Region | Before (s) | After (s)
> -------+------------+----------
> 00 | 0.77 | 1.48
> FI | 0.95 | 2.01
> US | 0.91 | 1.76
>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
> ---
Applied and removed the mention to milli-TUs, as agreed on IRC.
Thanks Juuso!
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] brcm80211: fix error report string
From: Gustavo F. Padovan @ 2011-01-24 21:35 UTC (permalink / raw)
To: brudley, henryp, dowan, rvossen, arend; +Cc: linux-wireless
In-Reply-To: <AANLkTi=GqWNd6yu0CeWAzt9ZRgCDkFRgwMExZiqEUr3Z@mail.gmail.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
drivers/staging/brcm80211/sys/wlc_mac80211.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/brcm80211/sys/wlc_mac80211.c b/drivers/staging/brcm80211/sys/wlc_mac80211.c
index 5eb41d6..a23dc5c 100644
--- a/drivers/staging/brcm80211/sys/wlc_mac80211.c
+++ b/drivers/staging/brcm80211/sys/wlc_mac80211.c
@@ -6910,7 +6910,7 @@ prep_mac80211_status(struct wlc_info *wlc, d11rxhdr_t *rxh, struct sk_buff *p,
preamble = 0;
if (IS_CCK(rspec)) {
if (rxh->PhyRxStatus_0 & PRXS0_SHORTH)
- WL_ERROR("Short CCK\n");
+ WL_ERROR("%s: Short CCK\n", __func__);
rx_status->flag |= RX_FLAG_SHORTPRE;
} else if (IS_OFDM(rspec)) {
rx_status->flag |= RX_FLAG_SHORTPRE;
--
1.7.4.rc2
^ permalink raw reply related
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Arik Nemtsov @ 2011-01-24 21:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295869283.3639.7.camel@jlt3.sipsolutions.net>
On Mon, Jan 24, 2011 at 13:41, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
>> Support passing SSID and probe-response template to drivers.
>> This data can be used to offload the beacon -> probe-req -> probe-resp
>> process to HW.
>
> I still think you should add a wiphy flag and advertise it in nl80211 to
> advertise and request this behaviour. That will allow hostapd (and
> mac80211 in IBSS mode) to not reply to probe requests when they aren't
> filtered out by the device, and will allow hostapd/wpa_s to also
> restrict its operation to non-P2P etc. as Jouni pointed out. For P2P
> then that will have to be extended more I guess, and the firmware
> functionality be improved -- or even disabled.
>
Well a wiphy flag won't do here. Probe requests may be filtered in
some modes (AP-mode) but needed in others (p2p?).
I think flexibility is a nice added bonus here. A FW can decide to
handle most standard probe-requests and simply not pass them up.
Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
The current patches leave this policy in the hands of the driver/fw.
Regards,
Arik
^ permalink raw reply
* Re: [PATCH] brcm80211: fix error report string
From: Rafał Miłecki @ 2011-01-24 21:17 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: brudley, henryp, dowan, vossen, arend, linux-wireless
In-Reply-To: <1295894723-28346-1-git-send-email-padovan@profusion.mobi>
2011/1/24 Gustavo F. Padovan <padovan@profusion.mobi>:
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> drivers/staging/brcm80211/sys/wlc_mac80211.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/staging/brcm80211/sys/wlc_mac80211.c b/drivers/staging/brcm80211/sys/wlc_mac80211.c
> index 5eb41d6..ee1bcc5 100644
> --- a/drivers/staging/brcm80211/sys/wlc_mac80211.c
> +++ b/drivers/staging/brcm80211/sys/wlc_mac80211.c
> @@ -6910,7 +6910,7 @@ prep_mac80211_status(struct wlc_info *wlc, d11rxhdr_t *rxh, struct sk_buff *p,
> preamble = 0;
> if (IS_CCK(rspec)) {
> if (rxh->PhyRxStatus_0 & PRXS0_SHORTH)
> - WL_ERROR("Short CCK\n");
> + WL_ERROR("%s: Short CCK\n, __func__");
I have no idea how WL_ERROR works, but are you sure of that?
You wrote:
"%s: Short CCK\n, __func__"
Didn't you mean:
"%s: Short CCK\n", __func__
?
--
Rafał
^ permalink raw reply
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Arik Nemtsov @ 2011-01-24 21:16 UTC (permalink / raw)
To: Jouni Malinen
Cc: linux-wireless, Luciano Coelho, Johannes Berg, John W. Linville
In-Reply-To: <20110124094433.GA5487@jm.kir.nu>
On Mon, Jan 24, 2011 at 11:44, Jouni Malinen <j@w1.fi> wrote:
> On Sun, Jan 23, 2011 at 11:02:53PM +0200, Arik Nemtsov wrote:
>> Support passing SSID and probe-response template to drivers.
>> This data can be used to offload the beacon -> probe-req -> probe-resp
>> process to HW.
>
> What is the expected driver behavior for passing the SSID as a separate
> attribute vs. passing the SSID as an IE within the Probe Response
> template? Is the SSID-as-attr ever used to fill in a Probe Response by
> the driver/firmware? Or is the driver/firmware only allowed to use the
> full Probe Response template (with DA and timestamp updated)? It would
> be useful to get this documented so that it is clear for people working
> with both a driver and user space applications that could use the new
> interface.
The SSID-as-attr not used for the probe-resp template. It is used by
FW to filter out which probe-reqs should be responded to when
operating with a hidden SSID.
The wl12xx FW updates the timestamp and DA. I mentioned in the
documentation of ieee80211_proberesp_get (and various other parts)
that the DA should be set manually and that this should be used as a
template (which also implies timestamp should be set). If some part is
unclear can you point out a specific patch?
>
> We should also document the need for special Probe Request processing
> for WPS and P2P and have capability flags indicating whether the driver
> needs the SSID and/or Probe Response template and whether it supports
> various special rules for Probe Request processing (remove P2P IE from
> Probe Response template if Probe Request does not include it, do not
> reply to Probe Request if there is no match for Requested Device Type,
> do not reply if there is no match for P2P Device Address). hostapd (or
> wpa_supplicant AP mode) would then automatically disable use of P2P
> and/or WPS if the driver/firmware does not have necessary capabilities
> to implement this correctly.
>
For WPS (without p2p), it appears the probe-resp doesn't depend on the
probe-req (in hostapd code).
I also explicitly made sure this scenario works since this is a good
example for a use-case when the probe-response is different from the
beacon.
Perhaps we can start with these AP-mode only patches and expand the
functionality when it is needed for p2p?
It may be hard to predict what other special handling will be needed
for offloading p2p probe-resps to FW (when such FW is available).
Note that the current patch doesn't remove existing functionality - a
driver/FW operating in p2p mode can simply choose not to use the
template and just pass probe-requests up.
Regards,
Arik
^ permalink raw reply
* Re: [PATCH] wl12xx: wrong values are returned in gpio_power_write()
From: Luciano Coelho @ 2011-01-24 21:15 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295778327-20545-1-git-send-email-eliad@wizery.com>
On Sun, 2011-01-23 at 11:25 +0100, Eliad Peller wrote:
> Return values were assigned to incorrect var / weren't assigned.
> fix it, and defer mutex_lock after the sanity checks.
>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
Looks good. Applied, thanks!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v3 0/2] wl12xx: BA Initiator & receiver support
From: Luciano Coelho @ 2011-01-24 21:05 UTC (permalink / raw)
To: Levi, Shahar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295764043-29918-1-git-send-email-shahar_levi@ti.com>
On Sun, 2011-01-23 at 07:27 +0100, Levi, Shahar wrote:
> That series gather two patches:
> [PATCH v7] wl12xx: BA initiator support
> [PATCH v5] wl12xx: BA receiver support
>
> Add 80211n BA initiator & receiver session support wl1271 driver.
> BA initiator session management included in FW independently.
> Include supported FW version auto detection mechanism.
>
> Limitation:
> - For now only one BA per direction is supported
>
> Shahar Levi (2):
> wl12xx: BA initiator support
> wl12xx: BA receiver support
>
> drivers/net/wireless/wl12xx/acx.c | 85 ++++++++++++++++++++++++++++++++++
> drivers/net/wireless/wl12xx/acx.h | 62 ++++++++++++++++++++++++-
> drivers/net/wireless/wl12xx/boot.c | 24 ++++++++-
> drivers/net/wireless/wl12xx/conf.h | 6 ++
> drivers/net/wireless/wl12xx/init.c | 41 ++++++++++++++++
> drivers/net/wireless/wl12xx/main.c | 72 +++++++++++++++++++++++++++--
> drivers/net/wireless/wl12xx/wl12xx.h | 16 ++++++-
> 7 files changed, 296 insertions(+), 10 deletions(-)
Applied, thanks!
--
Cheers,
Luca.
^ permalink raw reply
* problem calling the supplicant
From: Chuck Crisler @ 2011-01-24 20:57 UTC (permalink / raw)
To: linux-wireless
I have found a problem that is causing my communication with the supplicant
to get confused. I call the supplicant via wpa_ctrl_request(). Sometimes the
commands actually timeout. When that happens, the call to select() returns 0
which causes the wpa_ctrl_request to return -2. From then onward, the
response to all commands is the actual response to the previous command.
That causes my state machine to fail. What should I be doing when this
timeout situation occurs? It looks like I could simply make a subsequent
call into the ctrl_request with a NULL command (with length == 0) to get it
to execute the select() again, though I may want to modify
wpa_ctrl_request() to skip the send() if there is a NULL command. I know
that my missing response will ultimately be returned. Has anyone else seen
anything like this?
Thank you,
Chuck Crisler
^ permalink raw reply
* Re: [PATCH v2 2/6] nl80211: Pass probe response data to drivers
From: Arik Nemtsov @ 2011-01-24 20:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295868924.3639.2.camel@jlt3.sipsolutions.net>
On Mon, Jan 24, 2011 at 13:35, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
>> Allow usermode to pass probe-response data. This data can be used as a
>> template probe-response offloading.
>
> Why use a separate command for this, and not do it like the SSID? I also
Its only relevant to AP-mode (at least for now) so bss_conf didn't
seem appropriate.
Also since its a dynamically allocated buffer it should be protected by RCU.
> was under the impression you wanted both (which is somewhat redundant
> since you can parse the SSID out of the probe response), so shouldn't
> they both be required (or none, for compatibility)?
The FW requires both the real SSID and a probe-response template.
Passing the SSID separately looked cleaner.
About compatibility - good point there. Currently the probe response
template is set according to the beacon for compatibility. As for SSID
- with the current wl12xx we'll set an empty SSID when a
non-supporting hostapd is encountered. I'll fix that (in a v3). Other
than that, we should be able to operate with either one configured.
>
> Also, should cfg80211 pretend it knows the SSID/probe response when
> userspace didn't set it (from the beacon) so that mac80211 or the
> low-level drivers don't need to worry?
Well in the current patches sent to hostapd the probe response is
always set with the beacon, so this shouldn't happen in AP mode.
Its not supported in these patches for other modes..
Regards,
Arik
^ permalink raw reply
* [PATCH] ath9k: fix tx queue index confusion in debugfs code
From: Felix Fietkau @ 2011-01-24 20:29 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez, Ben Greear
Various places printing tx queue information used various different ways to
get a tx queue index for printing statistics. Most of these ways were wrong.
ATH_TXQ_AC_* cannot be used as an index for sc->tx.txq, because it is only
used internally for queue assignment.
One place used WME_AC_* as a queue index for sc->debug.stats.txstats, however
this array uses the ath9k_hw queue number as well.
Fix all of this by always using the ath9k_hw queue number as an index, and
always looking it up by going through sc->tx.txq_map.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: Ben Greear <greearb@candelatech.com>
---
drivers/net/wireless/ath/ath9k/debug.c | 37 ++++++++++++++++---------------
drivers/net/wireless/ath/ath9k/debug.h | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
3 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index f517c0c..9cdc41b 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -450,14 +450,15 @@ static const struct file_operations fops_wiphy = {
.llseek = default_llseek,
};
+#define PR_QNUM(_n) sc->tx.txq_map[_n]->axq_qnum
#define PR(str, elem) \
do { \
len += snprintf(buf + len, size - len, \
"%s%13u%11u%10u%10u\n", str, \
- sc->debug.stats.txstats[WME_AC_BE].elem, \
- sc->debug.stats.txstats[WME_AC_BK].elem, \
- sc->debug.stats.txstats[WME_AC_VI].elem, \
- sc->debug.stats.txstats[WME_AC_VO].elem); \
+ sc->debug.stats.txstats[PR_QNUM(WME_AC_BE)].elem, \
+ sc->debug.stats.txstats[PR_QNUM(WME_AC_BK)].elem, \
+ sc->debug.stats.txstats[PR_QNUM(WME_AC_VI)].elem, \
+ sc->debug.stats.txstats[PR_QNUM(WME_AC_VO)].elem); \
if (len >= size) \
goto done; \
} while(0)
@@ -466,10 +467,10 @@ static const struct file_operations fops_wiphy = {
do { \
len += snprintf(buf + len, size - len, \
"%s%13u%11u%10u%10u\n", str, \
- (unsigned int)(sc->tx.txq[ATH_TXQ_AC_BE].elem), \
- (unsigned int)(sc->tx.txq[ATH_TXQ_AC_BK].elem), \
- (unsigned int)(sc->tx.txq[ATH_TXQ_AC_VI].elem), \
- (unsigned int)(sc->tx.txq[ATH_TXQ_AC_VO].elem)); \
+ (unsigned int)(sc->tx.txq_map[WME_AC_BE]->elem), \
+ (unsigned int)(sc->tx.txq_map[WME_AC_BK]->elem), \
+ (unsigned int)(sc->tx.txq_map[WME_AC_VI]->elem), \
+ (unsigned int)(sc->tx.txq_map[WME_AC_VO]->elem)); \
if (len >= size) \
goto done; \
} while(0)
@@ -478,10 +479,10 @@ do { \
do { \
len += snprintf(buf + len, size - len, \
"%s%13i%11i%10i%10i\n", str, \
- list_empty(&sc->tx.txq[ATH_TXQ_AC_BE].elem), \
- list_empty(&sc->tx.txq[ATH_TXQ_AC_BK].elem), \
- list_empty(&sc->tx.txq[ATH_TXQ_AC_VI].elem), \
- list_empty(&sc->tx.txq[ATH_TXQ_AC_VO].elem)); \
+ list_empty(&sc->tx.txq_map[WME_AC_BE]->elem), \
+ list_empty(&sc->tx.txq_map[WME_AC_BK]->elem), \
+ list_empty(&sc->tx.txq_map[WME_AC_VI]->elem), \
+ list_empty(&sc->tx.txq_map[WME_AC_VO]->elem)); \
if (len >= size) \
goto done; \
} while (0)
@@ -528,10 +529,10 @@ static ssize_t read_file_xmit(struct file *file, char __user *user_buf,
PR("hw-tx-proc-desc: ", txprocdesc);
len += snprintf(buf + len, size - len,
"%s%11p%11p%10p%10p\n", "txq-memory-address:",
- &(sc->tx.txq[ATH_TXQ_AC_BE]),
- &(sc->tx.txq[ATH_TXQ_AC_BK]),
- &(sc->tx.txq[ATH_TXQ_AC_VI]),
- &(sc->tx.txq[ATH_TXQ_AC_VO]));
+ &(sc->tx.txq_map[WME_AC_BE]),
+ &(sc->tx.txq_map[WME_AC_BK]),
+ &(sc->tx.txq_map[WME_AC_VI]),
+ &(sc->tx.txq_map[WME_AC_VO]));
if (len >= size)
goto done;
@@ -751,9 +752,9 @@ static ssize_t read_file_misc(struct file *file, char __user *user_buf,
}
void ath_debug_stat_tx(struct ath_softc *sc, struct ath_buf *bf,
- struct ath_tx_status *ts)
+ struct ath_tx_status *ts, struct ath_txq *txq)
{
- int qnum = skb_get_queue_mapping(bf->bf_mpdu);
+ int qnum = txq->axq_qnum;
TX_STAT_INC(qnum, tx_pkts_all);
sc->debug.stats.txstats[qnum].tx_bytes_all += bf->bf_mpdu->len;
diff --git a/drivers/net/wireless/ath/ath9k/debug.h b/drivers/net/wireless/ath/ath9k/debug.h
index 980c9fa..1bdc6d4 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -175,7 +175,7 @@ int ath9k_init_debug(struct ath_hw *ah);
void ath_debug_stat_interrupt(struct ath_softc *sc, enum ath9k_int status);
void ath_debug_stat_tx(struct ath_softc *sc, struct ath_buf *bf,
- struct ath_tx_status *ts);
+ struct ath_tx_status *ts, struct ath_txq *txq);
void ath_debug_stat_rx(struct ath_softc *sc, struct ath_rx_status *rs);
#else
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 1afbd22..85c3d0a 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1913,7 +1913,7 @@ static void ath_tx_complete_buf(struct ath_softc *sc, struct ath_buf *bf,
else
complete(&sc->paprd_complete);
} else {
- ath_debug_stat_tx(sc, bf, ts);
+ ath_debug_stat_tx(sc, bf, ts, txq);
ath_tx_complete(sc, skb, tx_flags,
bf->bf_state.bfs_ftype, txq);
}
--
1.7.3.2
^ permalink raw reply related
* ath5k: issues with AHB support on ubiquiti bullet 2 (AR2315)
From: Hugh Davenport @ 2011-01-24 20:27 UTC (permalink / raw)
To: ath5k-devel; +Cc: linux-wireless
Hey all,
I'm just letting you know that I have been having issues getting the the
AHB support with the ath5k driver working (from compat-wireless 2011-01-05).
I'm testing it on an ubiquiti bullet 2 device which internally is a
AR2315 WiSoC. I am using openwrt backfire with the mac80211 package
patched to use a later version of compat-wireless (ie one with AHB
support in ath5k). I had to modify some of the patches in openwrt so
they applied cleanly, but don't think any affected the ath5k (and would
cause the problem i have).
Basically the issue is this. When I try to load the module as is in the
source tree, the system hangs and module never loads (device restarts
itself).
I tried a bit of debugging (sorry about any newbie techniques here, im
new to kernel debugging) by just printing and returning errors after
every main function called. The problem seemed to be with the first time
it called ath5k_hw_reg_write, which from my tracing seemed to be in th
wisoc reset function in the following chain.
ath5k_hw_reg_write (ath5k.h)
ath5k_hw_wisoc_reset (reset.c)
ath5k_hw_nic_wakeup (reset.c)
ath5k_hw_init (attach.c)
ath5k_init_softc (base.c)
ath_ahb_probe (ahb.c)
I then tried out a few things in the vain attempt to get it to load the
module, one which seemed to work is taking out the ioremap_nocache call
in ath_ahb_probe, and set mem to be res->start (on my system this is
0xb0000000 (the same as what madwifi tells me as well)). With this /fix/
the module now loads, gives the output below, but i can't bring the
interface up (device crashes again).
Atheros AR2315 chip found (MAC: 0x87, PHY: 0x48)
continuing traces when bring interface up brings me to another
ath5k_hw_reg_write call in the following chain
ath5k_hw_reg_write (ath5k.h)
ath5k_hw_start_rx_dma (dma.c)
ath5k_rx_start (base.c)
ath5k_reset (base.c)
ath5k_init_hw (base.c)
ath5k_start (mac80211-ops.c)
I am sorry about the long email, but I thought the more info you guys
have, the better.
If you have any ideas I can try, any more testing you may need me to do,
or anything that could help me get it working, let me know, and i'll do
my best to get anything done asap.
Cheers,
Hugh Davenport
^ permalink raw reply
* Re: [PATCH v2] wl12xx: Add channel 14 to list of supported 2ghz channels
From: Luciano Coelho @ 2011-01-24 20:19 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295379592-6223-1-git-send-email-arik@wizery.com>
On Tue, 2011-01-18 at 20:39 +0100, Arik Nemtsov wrote:
> Channel 14 is only supported in Japan (JP country code in).
> The FW limits tranmissions to CCK only on this channel.
>
> Tested in both STA and AP modes to work correctly.
>
> Signed-off-by: Arik Nemtsov <arik@wizery.com>
> ---
Applied to wl12xx. Thank you!
--
Cheers,
Luca.
^ 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