* [RFC PATCHv3 0/2] mac80211: cfg80211: dynamic ps timeout based on pm-qos
From: Juuso Oikarinen @ 2010-04-16 9:14 UTC (permalink / raw)
To: linux-wireless
These patches propose a way to adjust the dynamic ps timeout in the mac80211
based on the pm-qos network latency value. This allows user space to influence
the level of power saving performed by the mac80211.
These patches will the current 100ms timeout for the default network
latency value (2000s), so that for non-adjusted pm-qos the functionality will
remain as it is currently. Dynamic ps is disabled for any larger latency
values, and a timeout of 300s is used for latency values smaller than 50ms.
v3 of these patches ad a 50s dynamic ps configuration.
As wext still has an interface to adjust the dynamic ps timeout from userspace,
the wext configuration will override the above, to remain backwards
compatible.
Comments are appreciated.
Juuso Oikarinen (2):
mac80211: Determine dynamic PS timeout based on ps-qos network
latency
cfg80211: Remove default dynamic PS timeout value
include/net/mac80211.h | 5 ++++-
net/mac80211/cfg.c | 4 ++--
net/mac80211/main.c | 2 ++
net/mac80211/mlme.c | 14 ++++++++++++++
net/wireless/core.c | 3 ++-
5 files changed, 24 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCH] wireless: rt2x00: rt2800usb: delete Allwin devices
From: Xose Vazquez Perez @ 2010-04-16 10:16 UTC (permalink / raw)
To: linux-wireless; +Cc: users, linville, IvDoorn, gwingerde, xose.vazquez
Common sense says:
(0x8516, 0x2070) is RT2070
(0x8516, 0x2770) is RT2770
(0x8516, 0x2870) is RT2870
[...]
but Allwin doesn't sell USB dongles nor PCI boards, only voip-routers
http://www.allwin.com.tw/eng/modules/tinyd0/content/index.php?id=1
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index df7666f..41de405 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1019,14 +1019,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] wl1251: add support for dedicated IRQ line
From: Grazvydas Ignotas @ 2010-04-16 10:22 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless, Kalle Valo, Bob Copeland, Grazvydas Ignotas
wl1251 has WLAN_IRQ pin for generating interrupts to host processor,
which is mandatory in SPI mode and optional in SDIO mode (which can
use SDIO interrupts instead). However TI recommends using deditated
IRQ line for SDIO too.
Add support for using dedicated interrupt line with SDIO, but also leave
ability to switch to SDIO interrupts in case it's needed.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
drivers/net/wireless/wl12xx/wl1251_sdio.c | 56 ++++++++++++++++++++++++++---
include/linux/spi/wl12xx.h | 2 +
2 files changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1251_sdio.c b/drivers/net/wireless/wl12xx/wl1251_sdio.c
index 7409c34..d234285 100644
--- a/drivers/net/wireless/wl12xx/wl1251_sdio.c
+++ b/drivers/net/wireless/wl12xx/wl1251_sdio.c
@@ -25,6 +25,7 @@
#include <linux/mmc/sdio_ids.h>
#include <linux/platform_device.h>
#include <linux/spi/wl12xx.h>
+#include <linux/irq.h>
#include "wl1251.h"
@@ -134,18 +135,36 @@ static void wl1251_sdio_disable_irq(struct wl1251 *wl)
sdio_release_host(func);
}
+/* Interrupts when using dedicated WLAN_IRQ pin */
+static irqreturn_t wl1251_line_irq(int irq, void *cookie)
+{
+ struct wl1251 *wl = cookie;
+
+ ieee80211_queue_work(wl->hw, &wl->irq_work);
+
+ return IRQ_HANDLED;
+}
+
+static void wl1251_enable_line_irq(struct wl1251 *wl)
+{
+ return enable_irq(wl->irq);
+}
+
+static void wl1251_disable_line_irq(struct wl1251 *wl)
+{
+ return disable_irq(wl->irq);
+}
+
static void wl1251_sdio_set_power(bool enable)
{
}
-static const struct wl1251_if_operations wl1251_sdio_ops = {
+static struct wl1251_if_operations wl1251_sdio_ops = {
.read = wl1251_sdio_read,
.write = wl1251_sdio_write,
.write_elp = wl1251_sdio_write_elp,
.read_elp = wl1251_sdio_read_elp,
.reset = wl1251_sdio_reset,
- .enable_irq = wl1251_sdio_enable_irq,
- .disable_irq = wl1251_sdio_disable_irq,
};
static int wl1251_platform_probe(struct platform_device *pdev)
@@ -191,6 +210,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
goto release;
sdio_set_block_size(func, 512);
+ sdio_release_host(func);
SET_IEEE80211_DEV(hw, &func->dev);
wl->if_priv = func;
@@ -199,17 +219,41 @@ static int wl1251_sdio_probe(struct sdio_func *func,
if (wl12xx_board_data != NULL) {
wl->set_power = wl12xx_board_data->set_power;
+ wl->irq = wl12xx_board_data->irq;
wl->use_eeprom = wl12xx_board_data->use_eeprom;
}
- sdio_release_host(func);
+ if (wl->irq) {
+ ret = request_irq(wl->irq, wl1251_line_irq, 0, "wl1251", wl);
+ if (ret < 0) {
+ wl1251_error("request_irq() failed: %d", ret);
+ goto disable;
+ }
+
+ set_irq_type(wl->irq, IRQ_TYPE_EDGE_RISING);
+ disable_irq(wl->irq);
+
+ wl1251_sdio_ops.enable_irq = wl1251_enable_line_irq;
+ wl1251_sdio_ops.disable_irq = wl1251_disable_line_irq;
+
+ wl1251_info("using dedicated interrupt line");
+ } else {
+ wl1251_sdio_ops.enable_irq = wl1251_sdio_enable_irq;
+ wl1251_sdio_ops.disable_irq = wl1251_sdio_disable_irq;
+
+ wl1251_info("using SDIO interrupt");
+ }
+
ret = wl1251_init_ieee80211(wl);
if (ret)
- goto disable;
+ goto out_free_irq;
sdio_set_drvdata(func, wl);
return ret;
+out_free_irq:
+ if (wl->irq)
+ free_irq(wl->irq, wl);
disable:
sdio_claim_host(func);
sdio_disable_func(func);
@@ -222,6 +266,8 @@ static void __devexit wl1251_sdio_remove(struct sdio_func *func)
{
struct wl1251 *wl = sdio_get_drvdata(func);
+ if (wl->irq)
+ free_irq(wl->irq, wl);
wl1251_free_hw(wl);
sdio_claim_host(func);
diff --git a/include/linux/spi/wl12xx.h b/include/linux/spi/wl12xx.h
index aed64ed..a223ecb 100644
--- a/include/linux/spi/wl12xx.h
+++ b/include/linux/spi/wl12xx.h
@@ -26,6 +26,8 @@
struct wl12xx_platform_data {
void (*set_power)(bool enable);
+ /* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */
+ int irq;
bool use_eeprom;
};
--
1.6.3.3
^ permalink raw reply related
* ath9k: corrupt frames forwarded to mac80211 as decrypted (was: ath9k: receive stops working in AP-mode and 802.11n)
From: Johan Hovold @ 2010-04-16 10:48 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Tor Krill
In-Reply-To: <20100331191058.GD18913@lundinova.se>
Hi,
I now know why 802.11n receive stalls; ath9k is passing corrupt frames to
mac80211.
The corrupt frames are marked as decrypted so the receive PN is updated to a
random number. Later non-corrupt frames with correct PNs are consequently
deemed out-of-sequence and are dropped. Connection is restored at re-keying as
this resets the queue PN.
I noted that some of the corrupt frames may be caught in the driver by closer
inspection of the associated rx status. By modifying the receive processing I
am able to catch most corrupt frames. Unfortunately, there are still some that
seem impossible to identify without actually looking at the actual frames.
An example of such a frame is:
00000000: 88 41 30 00 00 80 48 68 08 0f 00 21 6a 56 2c 36
00000010: 00 22 02 00 0b 63 20 52 00 00 20 21 21 05 00 20
00000020: 8a 39 7b 1f 0f 11 07 9e bd 53 80 33 3b 8c 98 00
00000030: ef 5f da 7c 9a d6 3d d7 59 ac e0 21 44 88 63 d7
00000040: 21 34 b7 9a 89 8e cf 9e 46 1c ee d6 81 56 25 59
00000050: d2 ec ac 33 e6 12 3d c5 02 61 2d 80 8d 30 44 1e
00000060: 79 74 79 79 62 25 ba ec 04 4d 54 dc
with associated status
rxstatus8 = 1e989103
Here nothing in the frame status indicates an error; the frame has no error
flags set, the frame-ok flag is set, and so on. Still the frame is indeed
corrupt; the last four octets of the CCMP-header (bytes 0x20..0x23) should
be {00,00,00,00} rather than {8a,39,7b,1f} as the correct PN is 0x0521 (not
0x1f7b398a0521).
The corrupt frames all seem to have the upper half of the CCMP-header, data
and MIC corrupted, whereas the FCS (last four bytes) seem to be correct in the
sense that they match what I see in the air (and is verified by wireshark).
One explanation for all of this could be that the corrupt packet is what the
hardware is expected to return should it's processing fail (e.g. due to
checksum error). Then the problem is merely that the status field sometimes
get corrupted (some frames with corrupt PN do indeed come with matching
rxstatus). Comments in the code concerning corrupt status fields also point in
this direction.
Another explanation could be that the status is actually correct but for some
reason the returned frame is corrupted. Perhaps it's a combination of both
corrupt status and frame.
Any ideas about what may be going on here?
As I mentioned above I can catch most corrupt frames with the following changes
to the rx processing:
ath9k: clean up rx skb post-process logic
ath9k: do not mark frames with RXKEY_IX_INVALID as decrypted
ath9k: do not mark frames with RX_DECRYPT_BUSY as decrypted
ath9k: do not mark frames with RX_KEY_MISS as decrypted
ath9k: check error flags even if rx frame is marked ok
ath9k: clear mic error flag on encrypted frames
drivers/net/wireless/ath/ath9k/common.c | 16 ++++++++--------
drivers/net/wireless/ath/ath9k/mac.c | 26 +++++++++++++-------------
drivers/net/wireless/ath/ath9k/mac.h | 1 +
3 files changed, 22 insertions(+), 21 deletions(-)
The last change reduces the number of false MIC-errors that leads hostapd to
trigger countermeasures.
I might be violating the semantics of the error flags with some of these
changes, but it does make sense if indeed the status flags are getting
corrupted. For instance, if the FrameOK flag is erroneously set the remaining
error flags would never be checked. My change make sure the error flags are
always checked. Of course this may also, if the error flags get set due to status
corruption, lead to occasional false negatives which would have to be resend,
but this is better than passing false positives to mac80211 which breaks
communication completely.
I'm responding to this mail with the aforementioned patches against linux-next
from 20100413.
I'm still using AR9280.
Thanks,
Johan Hovold
^ permalink raw reply
* [RFC][PATCH 1/6] ath9k: clean up rx skb post-process logic
From: Johan Hovold @ 2010-04-16 10:52 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Tor Krill, Johan Hovold
In-Reply-To: <20100416104850.GA13329@lundinova.se>
Refactor IEEE80211_FCTL_PROTECTED and decryption error test.
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
drivers/net/wireless/ath/ath9k/common.c | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index 09effde..0cd10dc 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -255,15 +255,15 @@ void ath9k_cmn_rx_skb_postprocess(struct ath_common *common,
keyix = rx_stats->rs_keyix;
- if (!(keyix == ATH9K_RXKEYIX_INVALID) && !decrypt_error &&
- ieee80211_has_protected(fc)) {
- rxs->flag |= RX_FLAG_DECRYPTED;
- } else if (ieee80211_has_protected(fc)
- && !decrypt_error && skb->len >= hdrlen + 4) {
- keyix = skb->data[hdrlen + 3] >> 6;
-
- if (test_bit(keyix, common->keymap))
+ if (ieee80211_has_protected(fc) && !decrypt_error) {
+ if (keyix != ATH9K_RXKEYIX_INVALID) {
rxs->flag |= RX_FLAG_DECRYPTED;
+ } else if (skb->len >= hdrlen + 4) {
+ keyix = skb->data[hdrlen + 3] >> 6;
+
+ if (test_bit(keyix, common->keymap))
+ rxs->flag |= RX_FLAG_DECRYPTED;
+ }
}
if (ah->sw_mgmt_crypto &&
(rxs->flag & RX_FLAG_DECRYPTED) &&
--
1.7.0.3
^ permalink raw reply related
* [RFC][PATCH 2/6] ath9k: do not mark frames with RXKEY_IX_INVALID as decrypted
From: Johan Hovold @ 2010-04-16 10:52 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Tor Krill, Johan Hovold
In-Reply-To: <20100416104850.GA13329@lundinova.se>
Frames tagged by hardware with ATH9K_RXKEYIX_INVALID should not
incorrectly be marked decrypted (even if key index in frame is valid).
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
The current code overrides the hardware flag indicating that the key index is
invalid and falsely mark this frame as decrypted.
00000000: 88 41 30 00 00 80 48 68 08 0f 00 21 6a 56 2c 36
00000010: 00 22 02 00 0b 63 20 0d 00 00 20 00 d1 20 00 20
00000020: b1 5b a7 c5 96 be cf a3 16 3b 35 a0 bb 59 ea d2
00000030: 17 10 28 b0 07 67 14 ff d7 6f 77 5c f1 01 f0 04
00000040: 8d 03 47 68 9d b2 bd b4 64 bb cd 58 e9 ff 82 d2
00000050: f3 d0 38 b1 75 a2 2f d2 d6 b7 70 ec 95 22 71 32
00000060: 54 c0 c4 6d 1f 0d 19 32 22 e9 c2 9c
rxstatus8 = 3bbc20a3
set: AR_RxFrameOK | AR_MichaelErr
cleared: AR_CRCErr | AR_DecryptCRCErr | AR_PHYErr | AR_RxKeyIdxValid
drivers/net/wireless/ath/ath9k/common.c | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index 0cd10dc..af22e7a 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -256,14 +256,8 @@ void ath9k_cmn_rx_skb_postprocess(struct ath_common *common,
keyix = rx_stats->rs_keyix;
if (ieee80211_has_protected(fc) && !decrypt_error) {
- if (keyix != ATH9K_RXKEYIX_INVALID) {
+ if (keyix != ATH9K_RXKEYIX_INVALID)
rxs->flag |= RX_FLAG_DECRYPTED;
- } else if (skb->len >= hdrlen + 4) {
- keyix = skb->data[hdrlen + 3] >> 6;
-
- if (test_bit(keyix, common->keymap))
- rxs->flag |= RX_FLAG_DECRYPTED;
- }
}
if (ah->sw_mgmt_crypto &&
(rxs->flag & RX_FLAG_DECRYPTED) &&
--
1.7.0.3
^ permalink raw reply related
* [RFC][PATCH 3/6] ath9k: do not mark frames with RX_DECRYPT_BUSY as decrypted
From: Johan Hovold @ 2010-04-16 10:52 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Tor Krill, Johan Hovold
In-Reply-To: <20100416104850.GA13329@lundinova.se>
Frames tagged by hardware with ATH9K_RX_DECRYPT_BUSY should not
incorrectly be marked decrypted.
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
Some corrupt frames such as the one below have DecryptBusyErr flag set even
though frame is marked ok and without DecryptCRCErr set.
00000000: 88 41 30 00 00 80 48 68 08 0f 00 21 6a 56 2c 36
00000010: 00 22 02 00 0b 63 e0 2b 00 00 e0 00 bd 42 00 20
00000020: ef 44 5c a5 45 62 c2 2d af c3 cc ef ec cb d0 83
00000030: a7 7f fd bc 7d f1 c4 5e 72 82 81 fc ff 1a 9d 85
00000040: 63 cd 36 ae a4 12 6e fb b7 6a 77 71 4a 06 e6 ae
00000050: a6 40 ad b1 76 b7 de ff 7c bd cf b1 ef 3d 93 bf
00000060: 68 a0 af c1 a2 14 84 a4 4c 9e 5e 3e
rxstatus8 = de461103
set: AR_RxFrameOK | AR_RxKeyIdxValid | AR_DecryptBusyErr | Ar_KeyMiss
cleared: AR_CRCErr | AR_DecryptCRCErr | AR_PHYErr | AR_MichaelErr
drivers/net/wireless/ath/ath9k/common.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index af22e7a..dd4be54 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -255,7 +255,8 @@ void ath9k_cmn_rx_skb_postprocess(struct ath_common *common,
keyix = rx_stats->rs_keyix;
- if (ieee80211_has_protected(fc) && !decrypt_error) {
+ if (ieee80211_has_protected(fc) && !decrypt_error &&
+ !(rx_stats->rs_flags & ATH9K_RX_DECRYPT_BUSY)) {
if (keyix != ATH9K_RXKEYIX_INVALID)
rxs->flag |= RX_FLAG_DECRYPTED;
}
--
1.7.0.3
^ permalink raw reply related
* [RFC][PATCH 4/6] ath9k: do not mark frames with RX_KEY_MISS as decrypted
From: Johan Hovold @ 2010-04-16 10:52 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Tor Krill, Johan Hovold
In-Reply-To: <20100416104850.GA13329@lundinova.se>
Frames tagged by hardware with ATH9K_RX_KEY_MISS should not
incorrectly be marked decrypted.
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
The frame below has no error flags set besides KeyMiss and would be marked
decrypted by the current code.
00000000: 88 41 30 00 00 80 48 68 08 0f 00 21 6a 56 2c 36
00000010: 00 22 02 00 0b 63 10 a4 00 00 10 00 40 0a 00 20
00000020: 81 62 6d de 46 89 96 96 97 ec cf aa e3 77 73 07
00000030: 17 e8 76 91 73 fd ea a9 29 62 e4 c3 17 46 39 0a
00000040: 52 7f 26 39 2d 4c 22 7c 0e 91 78 95 ff 1d d0 18
00000050: ef 6a af 99 42 74 70 c1 d4 8b 56 16 9b 90 f3 9a
00000060: ff 52 5d 1c 77 ee 83 34 f6 14 1c da
rxstatus8 = b9accfc3
set: AR_RxFrameOK | AR_RxKeyIdxValid | AR_KeyMiss
cleared: AR_CRCErr | AR_DecryptCRCErr | AR_PHYErr | AR_MichaelErr | AR_DecryptBusyErr
drivers/net/wireless/ath/ath9k/common.c | 3 ++-
drivers/net/wireless/ath/ath9k/mac.c | 2 ++
drivers/net/wireless/ath/ath9k/mac.h | 1 +
3 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index dd4be54..1623af1 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -256,7 +256,8 @@ void ath9k_cmn_rx_skb_postprocess(struct ath_common *common,
keyix = rx_stats->rs_keyix;
if (ieee80211_has_protected(fc) && !decrypt_error &&
- !(rx_stats->rs_flags & ATH9K_RX_DECRYPT_BUSY)) {
+ !(rx_stats->rs_flags & ATH9K_RX_DECRYPT_BUSY) &&
+ !(rx_stats->rs_flags & ATH9K_RX_KEY_MISS)) {
if (keyix != ATH9K_RXKEYIX_INVALID)
rxs->flag |= RX_FLAG_DECRYPTED;
}
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 4a2060e..891a294 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -922,6 +922,8 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_flags |= ATH9K_RX_DELIM_CRC_POST;
if (ads.ds_rxstatus8 & AR_DecryptBusyErr)
rs->rs_flags |= ATH9K_RX_DECRYPT_BUSY;
+ if (ads.ds_rxstatus8 & AR_KeyMiss)
+ rs->rs_flags |= ATH9K_RX_KEY_MISS;
if ((ads.ds_rxstatus8 & AR_RxFrameOK) == 0) {
if (ads.ds_rxstatus8 & AR_CRCErr)
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 68dbd7a..ba3c98e 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -189,6 +189,7 @@ struct ath_htc_rx_status {
#define ATH9K_RX_DELIM_CRC_PRE 0x10
#define ATH9K_RX_DELIM_CRC_POST 0x20
#define ATH9K_RX_DECRYPT_BUSY 0x40
+#define ATH9K_RX_KEY_MISS 0x80
#define ATH9K_RXKEYIX_INVALID ((u8)-1)
#define ATH9K_TXKEYIX_INVALID ((u32)-1)
--
1.7.0.3
^ permalink raw reply related
* [RFC][PATCH 5/6] ath9k: check error flags even if rx frame is marked ok
From: Johan Hovold @ 2010-04-16 10:52 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Tor Krill, Johan Hovold
In-Reply-To: <20100416104850.GA13329@lundinova.se>
Check error flags even if frame is marked ok by hardware as this flag
may have been incorrectly set.
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
00000000: 88 41 30 00 00 80 48 68 08 af 00 b9 49 c3 e1 3f
00000010: 5a 9d 51 71 09 63 00 50 00 00 00 00 ff 54 00 20
00000020: 36 9d 46 02 90 31 2c e8 68 06 84 6e b5 00 29 e8
00000030: ef e3 6f a0 ee 99 7c 7e d8 7d 12 aa de 5c 20 69
00000040: d6 6a ad c4 99 bb c1 e4 c3 ba bd 77 51 7f a2 a5
00000050: 01 e4 81 a0 be 40 54 45 70 e4 cc 11 58 f8 ad 45
00000060: 84 1c 72 36 a1 fd b7 33 ad aa 4f 8b
rxstatus8 = 5994daab
Here AR_RxFrameOK is set even though AR_DecryptCRCErr and AR_MichaelErr are
set.
Note that this also happens for frames with non-corrupt PNs, e.g.:
FrameOK with error: c79e7573
FrameOK with error: 264786bf
FrameOK with error: f3a2446f
FrameOK with error: 2c054c4f
drivers/net/wireless/ath/ath9k/mac.c | 22 ++++++++++------------
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 891a294..2b4295b 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -925,18 +925,16 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
if (ads.ds_rxstatus8 & AR_KeyMiss)
rs->rs_flags |= ATH9K_RX_KEY_MISS;
- if ((ads.ds_rxstatus8 & AR_RxFrameOK) == 0) {
- if (ads.ds_rxstatus8 & AR_CRCErr)
- rs->rs_status |= ATH9K_RXERR_CRC;
- else if (ads.ds_rxstatus8 & AR_PHYErr) {
- rs->rs_status |= ATH9K_RXERR_PHY;
- phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
- rs->rs_phyerr = phyerr;
- } else if (ads.ds_rxstatus8 & AR_DecryptCRCErr)
- rs->rs_status |= ATH9K_RXERR_DECRYPT;
- else if (ads.ds_rxstatus8 & AR_MichaelErr)
- rs->rs_status |= ATH9K_RXERR_MIC;
- }
+ if (ads.ds_rxstatus8 & AR_CRCErr)
+ rs->rs_status |= ATH9K_RXERR_CRC;
+ else if (ads.ds_rxstatus8 & AR_PHYErr) {
+ rs->rs_status |= ATH9K_RXERR_PHY;
+ phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
+ rs->rs_phyerr = phyerr;
+ } else if (ads.ds_rxstatus8 & AR_DecryptCRCErr)
+ rs->rs_status |= ATH9K_RXERR_DECRYPT;
+ else if (ads.ds_rxstatus8 & AR_MichaelErr)
+ rs->rs_status |= ATH9K_RXERR_MIC;
return 0;
}
--
1.7.0.3
^ permalink raw reply related
* [RFC][PATCH 6/6] ath9k: clear mic error flag on encrypted frames
From: Johan Hovold @ 2010-04-16 10:52 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Tor Krill, Johan Hovold
In-Reply-To: <20100416104850.GA13329@lundinova.se>
It does not make sense to forward MIC-errors on non-decrypted frames.
Signed-off-by: Johan Hovold <johan.hovold@lundinova.se>
---
drivers/net/wireless/ath/ath9k/common.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index 1623af1..6efb388 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -255,11 +255,15 @@ void ath9k_cmn_rx_skb_postprocess(struct ath_common *common,
keyix = rx_stats->rs_keyix;
- if (ieee80211_has_protected(fc) && !decrypt_error &&
- !(rx_stats->rs_flags & ATH9K_RX_DECRYPT_BUSY) &&
- !(rx_stats->rs_flags & ATH9K_RX_KEY_MISS)) {
- if (keyix != ATH9K_RXKEYIX_INVALID)
+ if (ieee80211_has_protected(fc)) {
+ if (!decrypt_error &&
+ !(rx_stats->rs_flags & ATH9K_RX_DECRYPT_BUSY) &&
+ !(rx_stats->rs_flags & ATH9K_RX_KEY_MISS) &&
+ keyix != ATH9K_RXKEYIX_INVALID) {
rxs->flag |= RX_FLAG_DECRYPTED;
+ }
+ if (!(rxs->flag & RX_FLAG_DECRYPTED))
+ rxs->flag &= ~RX_FLAG_MMIC_ERROR;
}
if (ah->sw_mgmt_crypto &&
(rxs->flag & RX_FLAG_DECRYPTED) &&
--
1.7.0.3
^ permalink raw reply related
* Re: [PATCH] wireless: rt2x00: rt2800usb: delete Allwin devices
From: Ivo Van Doorn @ 2010-04-16 11:17 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: linux-wireless, users, linville, gwingerde
In-Reply-To: <1271413005-2509-1-git-send-email-xose.vazquez@gmail.com>
On Fri, Apr 16, 2010 at 12:16 PM, Xose Vazquez Perez
<xose.vazquez@gmail.com> wrote:
> Common sense says:
> (0x8516, 0x2070) is RT2070
> (0x8516, 0x2770) is RT2770
> (0x8516, 0x2870) is RT2870
> [...]
>
> but Allwin doesn't sell USB dongles nor PCI boards, only voip-routers
> http://www.allwin.com.tw/eng/modules/tinyd0/content/index.php?id=1
But how about the case where the company name is wrong and the ID's are valid?
That means we only should update the comment, rather then deleting the ID's.
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
> ---
> drivers/net/wireless/rt2x00/rt2800usb.c | 8 --------
> 1 files changed, 0 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
> index df7666f..41de405 100644
> --- a/drivers/net/wireless/rt2x00/rt2800usb.c
> +++ b/drivers/net/wireless/rt2x00/rt2800usb.c
> @@ -1019,14 +1019,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
* Re: [ath9k-devel] [RFC][PATCH 2/6] ath9k: do not mark frames with RXKEY_IX_INVALID as decrypted
From: Jouni Malinen @ 2010-04-16 11:32 UTC (permalink / raw)
To: Johan Hovold; +Cc: ath9k-devel@lists.ath9k.org, linux-wireless@vger.kernel.org
In-Reply-To: <1271415135-18317-2-git-send-email-johan.hovold@lundinova.se>
On Fri, 2010-04-16 at 03:52 -0700, Johan Hovold wrote:
> Frames tagged by hardware with ATH9K_RXKEYIX_INVALID should not
> incorrectly be marked decrypted (even if key index in frame is valid).
Have you tested this with static WEP configuration? Or broadcast RX with
WPA? There must be a reason for that odd looking code being there in the
first place and I can now only think of it being needed when the default
keys are used.
- Jouni
^ permalink raw reply
* Re: [PATCH] wl1251: add support for dedicated IRQ line
From: Bob Copeland @ 2010-04-16 12:15 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: John W. Linville, linux-wireless, Kalle Valo
In-Reply-To: <1271413332-2979-1-git-send-email-notasas@gmail.com>
On Fri, Apr 16, 2010 at 01:22:12PM +0300, Grazvydas Ignotas wrote:
> wl1251 has WLAN_IRQ pin for generating interrupts to host processor,
> which is mandatory in SPI mode and optional in SDIO mode (which can
> use SDIO interrupts instead). However TI recommends using deditated
> IRQ line for SDIO too.
>
> Add support for using dedicated interrupt line with SDIO, but also leave
> ability to switch to SDIO interrupts in case it's needed.
>
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Thanks, looks good to me!
Reviewed-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: John W. Linville @ 2010-04-16 13:37 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless
In-Reply-To: <p2ub170af451004152320y64c4615ub3d7186d936cdc62@mail.gmail.com>
On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
> John, I posted some time ago following patches:
>
> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
> [PATCH 1/2] ssb: Use relative offsets for SPROM
> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>
> while Michael has some doubts about "ssb: Look for SPROM at different
> offset on higher rev CC" I explained to him that what he does not like
> was fixed in next 2 posted patches.
>
> AFAIR you got some device with this recently-discovered location of
> SPROM. Could you test my set if it makes your card working? If so,
> could you take that patches to your tree?
Sorry, been busy w/ other things. FWIW, my implementation based on
the RE work from Larry did not work on the box in question, and my
implementation wasn't substantially different from yours. Anyway,
I'll try to confirm this soon w/ your patches and to collect more
information for Larry.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [RFC PATCH] mac80211: Prevent running sta_cleanup timer unnecessarily
From: John W. Linville @ 2010-04-16 13:41 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless
In-Reply-To: <1271403308-23416-2-git-send-email-juuso.oikarinen@nokia.com>
On Fri, Apr 16, 2010 at 10:35:08AM +0300, Juuso Oikarinen wrote:
> The sta_cleanup timer is used to periodically expire buffered frames from the
> tx buf. The timer is executing periodically, regardless of the need for it.
> This is wasting resources.
>
> Fix this simply by not restarting the sta_cleanup timer if the tx buffer was
> empty. Restart the timer when there is some more tx-traffic.
>
> Cc: Janne Ylälehto <janne.ylalehto@nokia.com>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Seems reasonable to me...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] wireless: rt2x00: rt2800usb: delete Allwin devices
From: John W. Linville @ 2010-04-16 13:43 UTC (permalink / raw)
To: Ivo Van Doorn; +Cc: Xose Vazquez Perez, linux-wireless, users, gwingerde
In-Reply-To: <u2ja32f33a41004160417jfcf1db3bw62d464405fead085@mail.gmail.com>
On Fri, Apr 16, 2010 at 01:17:07PM +0200, Ivo Van Doorn wrote:
> On Fri, Apr 16, 2010 at 12:16 PM, Xose Vazquez Perez
> <xose.vazquez@gmail.com> wrote:
> > Common sense says:
> > (0x8516, 0x2070) is RT2070
> > (0x8516, 0x2770) is RT2770
> > (0x8516, 0x2870) is RT2870
> > [...]
> >
> > but Allwin doesn't sell USB dongles nor PCI boards, only voip-routers
> > http://www.allwin.com.tw/eng/modules/tinyd0/content/index.php?id=1
>
> But how about the case where the company name is wrong and the ID's are valid?
> That means we only should update the comment, rather then deleting the ID's.
Or the case where someone ports Linux to those voip routers...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] iwlwifi: check scan request ie_len
From: Stanislaw Gruszka @ 2010-04-16 13:46 UTC (permalink / raw)
To: linux-wireless; +Cc: Reinette Chatre, wey-yi.w.guy, Stanislaw Gruszka
In mac80211 we always check both scan_req->ie and scan_req->ie_len
against zero before usage, in iwlwifi we should do the same.
Remove not needed "left -= ie_len" while at it.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlwifi/iwl-scan.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-scan.c b/drivers/net/wireless/iwlwifi/iwl-scan.c
index d817c9c..83e6291 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@ -644,10 +644,10 @@ u16 iwl_fill_probe_req(struct iwl_priv *priv, struct ieee80211_mgmt *frame,
if (WARN_ON(left < ie_len))
return len;
- if (ies)
+ if (ies && ie_len) {
memcpy(pos, ies, ie_len);
- len += ie_len;
- left -= ie_len;
+ len += ie_len;
+ }
return (u16)len;
}
--
1.6.2.5
^ permalink raw reply related
* [PATCH] iwlwifi: initialize iwl_wimax_coex_cmd.flags
From: Stanislaw Gruszka @ 2010-04-16 13:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Reinette Chatre, wey-yi.w.guy, Stanislaw Gruszka
iwl_wimax_coex_cmd.flags can be really uninitialized, so fix
that.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlwifi/iwl-core.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index f09bff8..2e489cd 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -2382,11 +2382,11 @@ EXPORT_SYMBOL(iwl_free_txq_mem);
int iwl_send_wimax_coex(struct iwl_priv *priv)
{
- struct iwl_wimax_coex_cmd uninitialized_var(coex_cmd);
+ struct iwl_wimax_coex_cmd coex_cmd;
if (priv->cfg->support_wimax_coexist) {
/* UnMask wake up src at associated sleep */
- coex_cmd.flags |= COEX_FLAGS_ASSOC_WA_UNMASK_MSK;
+ coex_cmd.flags = COEX_FLAGS_ASSOC_WA_UNMASK_MSK;
/* UnMask wake up src at unassociated sleep */
coex_cmd.flags |= COEX_FLAGS_UNASSOC_WA_UNMASK_MSK;
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 1/2] ath5k: Use high bitrates for ACK/CTS
From: Stanislaw Gruszka @ 2010-04-16 13:59 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linville, ath5k-devel, linux-wireless
In-Reply-To: <20100412073847.28215.87571.stgit@tt-desk>
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 ...
Stanislaw
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: Rafał Miłecki @ 2010-04-16 15:51 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20100416133711.GB8554@tuxdriver.com>
W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
<linville@tuxdriver.com> napisał:
> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>> John, I posted some time ago following patches:
>>
>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>>
>> while Michael has some doubts about "ssb: Look for SPROM at different
>> offset on higher rev CC" I explained to him that what he does not like
>> was fixed in next 2 posted patches.
>>
>> AFAIR you got some device with this recently-discovered location of
>> SPROM. Could you test my set if it makes your card working? If so,
>> could you take that patches to your tree?
>
> Sorry, been busy w/ other things. FWIW, my implementation based on
> the RE work from Larry did not work on the box in question, and my
> implementation wasn't substantially different from yours. Anyway,
> I'll try to confirm this soon w/ your patches and to collect more
> information for Larry.
Ah, I didn't know you got own implementation. Had to miss it.
Larry do you have any ideas what else may we do incorrectly?
John: may be worth checking if your card matched this new condition
and if driver actually used "new" offset.
--
Rafał
^ permalink raw reply
* Re: [PATCH PING] ssb patches for SPROM location
From: Larry Finger @ 2010-04-16 16:22 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: John W. Linville, linux-wireless
In-Reply-To: <m2wb170af451004160851veaed6df6r2e8ec0528f66685e@mail.gmail.com>
On 04/16/2010 10:51 AM, Rafał Miłecki wrote:
> W dniu 16 kwietnia 2010 15:37 użytkownik John W. Linville
> <linville@tuxdriver.com> napisał:
>> On Fri, Apr 16, 2010 at 08:20:51AM +0200, Rafał Miłecki wrote:
>>> John, I posted some time ago following patches:
>>>
>>> [RFT][PATCH] ssb: Look for SPROM at different offset on higher rev CC
>>> [PATCH 1/2] ssb: Use relative offsets for SPROM
>>> [PATCH 2/2] ssb: Fix order of definitions and some text space indents
>>>
>>> while Michael has some doubts about "ssb: Look for SPROM at different
>>> offset on higher rev CC" I explained to him that what he does not like
>>> was fixed in next 2 posted patches.
>>>
>>> AFAIR you got some device with this recently-discovered location of
>>> SPROM. Could you test my set if it makes your card working? If so,
>>> could you take that patches to your tree?
>>
>> Sorry, been busy w/ other things. FWIW, my implementation based on
>> the RE work from Larry did not work on the box in question, and my
>> implementation wasn't substantially different from yours. Anyway,
>> I'll try to confirm this soon w/ your patches and to collect more
>> information for Larry.
>
> Ah, I didn't know you got own implementation. Had to miss it.
>
> Larry do you have any ideas what else may we do incorrectly?
No. AFAICT, we have implemented it correctly. Any additional info would
be welcome.
Larry
^ permalink raw reply
* Re: [PATCH] iwlwifi: check scan request ie_len
From: reinette chatre @ 2010-04-16 17:12 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org, Guy, Wey-Yi W
In-Reply-To: <1271425601-32518-1-git-send-email-sgruszka@redhat.com>
On Fri, 2010-04-16 at 06:46 -0700, Stanislaw Gruszka wrote:
> In mac80211 we always check both scan_req->ie and scan_req->ie_len
> against zero before usage, in iwlwifi we should do the same.
>
> Remove not needed "left -= ie_len" while at it.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [PATCH] iwlwifi: initialize iwl_wimax_coex_cmd.flags
From: reinette chatre @ 2010-04-16 18:04 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless@vger.kernel.org, Guy, Wey-Yi W
In-Reply-To: <1271425676-32552-1-git-send-email-sgruszka@redhat.com>
On Fri, 2010-04-16 at 06:47 -0700, Stanislaw Gruszka wrote:
> iwl_wimax_coex_cmd.flags can be really uninitialized, so fix
> that.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
Thank you
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [ath9k_htc] Current patches against 2.6.34-rc3-git4
From: Sedat Dilek @ 2010-04-16 18:07 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless@vger.kernel.org, Vivek Natarajan,
Luis R. Rodriguez
In-Reply-To: <19389.36279.77368.650461@gargle.gargle.HOWL>
Thanks for the informations.
Compat-wireless is broken ATM (see IRC backlog below).
>From #linux-wireless/freenode (German local-time - UTC+2):
...
[06:52:54] <mcgrof> User-level discussions about wireless LANs on
Linux | compat-wireless-2.6 only available for kernels >= 2.6.23
(bleeding edge broken right now though)
...
[19:13:41] <jensp> fivetwentysix: He says that he removed the atheros
driver from compat-wireless and replaced it with
http://git.kernel.org/?p=linux/kernel/git/mcgrof/ath9k_htc.git;a=summary
...
I was more interested in following the ath9k_htc development -
especially against Linus-tree.
A GIT repository like in [1] w/could be helpful and if it is
"official" (don't know the status, last commit was before 7 weeks)
worth updating in [2]?
- Sedat -
[1] http://git.kernel.org/?p=linux/kernel/git/mcgrof/ath9k_htc.git;a=summary
[2] http://wireless.kernel.org/en/users/Drivers/ath9k_htc/
On Thu, Apr 8, 2010 at 10:03 AM, Sujith <Sujith.Manoharan@atheros.com> wrote:
> Sedat Dilek wrote:
>> Hi,
>>
>> I (hope I) collected all ath9k_htc patches pending in [1].
>> Unfortunately, my (quilt) series break against Linux 2.6.34-rc3-git4.
>> Any hints?
>
> An easier way to get the latest wireless drivers would be to use
> compat-wireless.
>
> See: http://linuxwireless.org/en/users/Download/
>
> Sujith
>
^ permalink raw reply
* Re: 2.6.33 iwl5350 firmware crash
From: reinette chatre @ 2010-04-16 18:26 UTC (permalink / raw)
To: Andrew Lutomirski; +Cc: ilw@linux.intel.com, linux-wireless@vger.kernel.org
In-Reply-To: <g2rcb0375e11004151408m4a74639cz28e6129054824543@mail.gmail.com>
On Thu, 2010-04-15 at 14:08 -0700, Andrew Lutomirski wrote:
> [74944.425130] iwlagn 0000:03:00.0: Microcode SW error detected.
> Restarting 0x2000000.
> [74944.425154] iwlagn 0000:03:00.0: Start IWL Error Log Dump:
> [74944.425160] iwlagn 0000:03:00.0: Status: 0x000212E4, count: 5
> [74944.425291] iwlagn 0000:03:00.0: Desc
> Time data1 data2 line
> [74944.425301] iwlagn 0000:03:00.0: NMI_INTERRUPT_WDG (#04)
> 1638059893 0x00000002 0x07030000 3664
[...]
> [74981.401945] ------------[ cut here ]------------
> [74981.401980] WARNING: at net/mac80211/agg-tx.c:152
> ___ieee80211_stop_tx_ba_session+0x87/0x8c [mac80211]()
Please see https://bugzilla.kernel.org/show_bug.cgi?id=15374 - it has
patches that will help aggregation recovery after this NMI problem.
Unfortunately there is nothing we can do at this time to the firmware
error. I'll try to get these patches into 2.6.34 today.
Reinette
^ 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