* Cross compilation compat-wireless in kernel-2.6.35 for powerpc
From: Suman Pandit @ 2013-05-24 6:24 UTC (permalink / raw)
To: linux-wireless
"WARNING: CONFIG_CFG80211_WEXT will be deactivated or not working because
kernel was compiled with CONFIG_WIRELESS_EXT=n. Tools using wext interface
like iwconfig will not work. To activate it build your kernel e.g. with
CONFIG_LIBIPW=m."
./scripts/gen-compat-autoconf.sh config.mk > include/linux/compat_autoconf.h
^ permalink raw reply
* Re: skb_under_panic in ath9k
From: Marc Kleine-Budde @ 2013-05-24 8:47 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, ath9k-devel
In-Reply-To: <519D405B.2080806@blackshift.org>
[-- Attachment #1: Type: text/plain, Size: 6067 bytes --]
added ath9k-devel to Cc
On 05/23/2013 12:02 AM, Marc Kleine-Budde wrote:
> Hello,
>
> I'm on a kirkwood based armv5 system with an USB attached TP-Link
> TL-WN821N - Atheros AR7010+AR9287, [1]. the wlan is running in AP mode
> with hostapd-1.0. The kernel is v3.8.12 from debian (3.8-1-kirkwood #1
> Debian 3.8.12-1).
>
> The system crashes repeatedly after about one week with the following
> oops:
>
> [633625.401875] skbuff: skb_under_panic: text:bf501028 len:128 put:8 head:d2788800 data:d27887fe tail:0xd278887e end:0xd2788f40 dev:wlan1
> [633625.414180] ------------[ cut here ]------------
> [633625.418909] kernel BUG at /build/buildd-linux_3.8.12-1-armel-7F6kBx/linux-3.8.12/net/core/skbuff.c:145!
> [633625.428430] Internal error: Oops - BUG: 0 [#1] ARM
> [633625.433322] Modules linked in:
> [...]
> [633625.583170] CPU: 0 Not tainted (3.8-1-kirkwood #1 Debian 3.8.12-1)
> [633625.589821] PC is at skb_push+0x6c/0x84
> [633625.593763] LR is at skb_push+0x6c/0x84
> [633625.597707] pc : [<c0282990>] lr : [<c0282990>] psr: 20000013
> [633625.597707] sp : c04c1d50 ip : 000008f8 fp : df04ea54
> [633625.609404] r10: 00000002 r9 : 00000008 r8 : df00dca8
> [633625.614734] r7 : 00000006 r6 : c04410a0 r5 : d278887e r4 : d2788800
> [633625.621378] r3 : c04d328c r2 : 20000093 r1 : 00000001 r0 : 00000079
> [633625.628015] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
> [633625.635443] Control: 0005317f Table: 1f224000 DAC: 00000017
> [633625.641295] Process swapper (pid: 0, stack limit = 0xc04c01b8)
> [633625.647241] Stack: (0xc04c1d50 to 0xc04c2000)
> [633625.657414] 1d40: 00000008 d2788800 d27887fe d278887e
> [633625.666101] 1d60: d2788f40 df04e000 df00dc00 df2e0c00 00000078 bf501028 df2e0c00 dfba3120
> [633625.675025] 1d80: d278882a df04e9a0 00000000 bf504110 dfb3ce20 00000201 00000000 00084502
> [633625.683954] 1da0: 00000001 df2e0c00 dfba3120 00000008 00000002 c04c1df4 00000000 00000001
> [633625.693553] 1dc0: 0000006a bf5058b0 00000000 c04c1df4 c04c1e30 dfba2300 c151ff18 df04e9a0
> [633625.702041] 1de0: c04c1e30 bf37560c 0000000c 00004288 c04c1e2c c151ff18 0000006a df2e0c00
> [633625.710540] 1e00: dfba2300 00000000 0000006a df04e462 00000000 00000001 60000013 bf375760
> [633625.718904] 1e20: 00000001 c14c19a0 c14c0460 00000000 c04c1e30 c04c1e30 00000000 dfba2300
> [633625.727374] 1e40: df04e460 c151fc00 de5af200 00000002 00000002 dfba2300 dfba2308 dfba28a8
> [633625.787263] 1e60: c04c1e7c dfba28ac df2e0c00 bf376d58 c0508ae0 00000000 0000012c 00000080
> [633625.798914] 1e80: 03c66eab c0508ae8 c04d4c68 c04d3494 00000000 00000000 00000006 00000100
> [633625.810249] 1ea0: c052b3a0 00000009 c052b3c0 c0026e2c 00000001 00000018 c04c0000 c0026644
> [633625.818620] 1ec0: c04d8f74 c1484260 1144b25a c04d8f74 00000000 00200000 c04c1f4c 00000013
> [633625.831230] 1ee0: 00000000 fed20200 c04c1f4c 00000000 56251311 c04d0420 00000000 c0026a2c
> [633625.842695] 1f00: 00002000 c000f28c c004e27c c0271318 20000013 c000df94 c04c1f60 60000013
> [633625.853824] 1f20: 000e32dc 0002404f b5def004 0002404f c04d0698 00000000 00000000 56251311
> [633625.864745] 1f40: c04d0420 00000000 00000003 c04c1f60 c004e27c c0271318 20000013 ffffffff
> [633625.875714] 1f60: b5ed22e0 0002404f 0084d405 00000000 00000000 c04d0698 00000000 c04d0698
> [633625.886646] 1f80: 00000000 c04d0420 004b8074 c0270e88 c04d0698 00000000 c050918c c0271014
> [633625.898317] 1fa0: c04c0000 c0509b28 c04cc1cc c096f0e0 00004000 c000f484 c04c8c20 00000000
> [633625.909787] 1fc0: c04b9650 c0498764 ffffffff ffffffff c0498284 00000000 00000000 c04b9650
> [633625.918159] 1fe0: 00000000 00053175 c04c8048 c04b964c c04cc1c4 00008040 00000000 00000000
> [633625.926557] [<c0282990>] (skb_push+0x6c/0x84) from [<bf501028>] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc])
> [633625.937158] [<bf501028>] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc]) from [<bf504110>] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc])
> [633625.949877] [<bf504110>] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc]) from [<bf5058b0>] (ath9k_htc_tx+0x98/0xcc [ath9k_htc])
> [633625.961458] [<bf5058b0>] (ath9k_htc_tx+0x98/0xcc [ath9k_htc]) from [<bf37560c>] (__ieee80211_tx+0x210/0x2a8 [mac80211])
> [633625.972695] [<bf37560c>] (__ieee80211_tx+0x210/0x2a8 [mac80211]) from [<bf375760>] (ieee80211_tx+0xbc/0xc4 [mac80211])
> [633625.983816] [<bf375760>] (ieee80211_tx+0xbc/0xc4 [mac80211]) from [<bf376d58>] (ieee80211_tx_pending+0xf0/0x194 [mac80211])
> [633625.995326] [<bf376d58>] (ieee80211_tx_pending+0xf0/0x194 [mac80211]) from [<c0026e2c>] (tasklet_action+0x84/0xcc)
> [633626.005905] [<c0026e2c>] (tasklet_action+0x84/0xcc) from [<c0026644>] (__do_softirq+0xdc/0x204)
> [633626.014750] [<c0026644>] (__do_softirq+0xdc/0x204) from [<c0026a2c>] (irq_exit+0x40/0x8c)
> [633626.023103] [<c0026a2c>] (irq_exit+0x40/0x8c) from [<c000f28c>] (handle_IRQ+0x64/0x84)
> [633626.031193] [<c000f28c>] (handle_IRQ+0x64/0x84) from [<c000df94>] (__irq_svc+0x34/0x78)
> [633626.039412] [<c000df94>] (__irq_svc+0x34/0x78) from [<c0271318>] (cpuidle_wrap_enter+0x54/0x9c)
> [633626.048331] [<c0271318>] (cpuidle_wrap_enter+0x54/0x9c) from [<c0270e88>] (cpuidle_enter_state+0x14/0x68)
> [633626.058162] [<c0270e88>] (cpuidle_enter_state+0x14/0x68) from [<c0271014>] (cpuidle_idle_call+0x138/0x25c)
> [633626.067998] [<c0271014>] (cpuidle_idle_call+0x138/0x25c) from [<c000f484>] (cpu_idle+0x68/0xc8)
> [633626.076852] [<c000f484>] (cpu_idle+0x68/0xc8) from [<c0498764>] (start_kernel+0x2b4/0x30c)
> [633626.146230] Code: e58dc014 e59f1014 e59f0014 eb0308b0 (e7f001f2)
> [633626.152520] ---[ end trace ee5dbceea3381e46 ]---
> [633626.157249] Kernel panic - not syncing: Fatal exception in interrupt
>
> Has the problem been fixed already? I can update the kernel to a recent
> version if needed.
>
> regards,
> Marc
>
> [1] lsusb:
> Bus 001 Device 004: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH] mwl8k: Fix the firmware hang issue for 8764
From: Nishant Sarmukadam @ 2013-05-24 9:12 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless, Lennert Buytenhek, Nishant Sarmukadam,
Yogesh Ashok Powar
The firmware hang issue is not seen very often,
though it is still seen sometimes (once in 12
hours in local tests). The changes in the driver
,to interrupt the firmware, are needed when we
detect that firmware is stuck and when the host
queues are full and we begin to drop packets.
This is to ensure that the firmware does not
miss any PPA_RDY interrupts to cause the firmware
restart dont miss PPA_READY interrupt for SC2
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
---
drivers/net/wireless/mwl8k.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 6820fce..a3707fd 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -1548,7 +1548,7 @@ static int mwl8k_tx_wait_empty(struct ieee80211_hw *hw)
if (!priv->pending_tx_pkts)
return 0;
- retry = 0;
+ retry = 1;
rc = 0;
spin_lock_bh(&priv->tx_lock);
@@ -1572,13 +1572,19 @@ static int mwl8k_tx_wait_empty(struct ieee80211_hw *hw)
spin_lock_bh(&priv->tx_lock);
- if (timeout) {
+ if (timeout || !priv->pending_tx_pkts) {
WARN_ON(priv->pending_tx_pkts);
if (retry)
wiphy_notice(hw->wiphy, "tx rings drained\n");
break;
}
+ if (retry) {
+ mwl8k_tx_start(priv);
+ retry = 0;
+ continue;
+ }
+
if (priv->pending_tx_pkts < oldcount) {
wiphy_notice(hw->wiphy,
"waiting for tx rings to drain (%d -> %d pkts)\n",
@@ -2055,6 +2061,7 @@ mwl8k_txq_xmit(struct ieee80211_hw *hw,
mwl8k_remove_stream(hw, stream);
spin_unlock(&priv->stream_lock);
}
+ mwl8k_tx_start(priv);
spin_unlock_bh(&priv->tx_lock);
pci_unmap_single(priv->pdev, dma, skb->len,
PCI_DMA_TODEVICE);
--
1.8.0.3
^ permalink raw reply related
* [PATCH v4 1/3] mac80211: add STBC flag for radiotap
From: Oleksij Rempel @ 2013-05-24 10:05 UTC (permalink / raw)
To: ath9k-devel, linux-wireless, johannes; +Cc: Oleksij Rempel
In-Reply-To: <1369250674.8207.26.camel@jlt4.sipsolutions.net>
Some chips can tell us if received frame was
encoded with STBC or not. To make this information available
in user space we can use updated radiotap specification:
http://www.radiotap.org/defined-fields/MCS
This patch will set number of STBC encoded spatial streams (Nss).
The HAVE_STBC flag should be provided by driver.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
include/net/ieee80211_radiotap.h | 7 +++++++
include/net/mac80211.h | 4 ++++
net/mac80211/rx.c | 4 ++++
3 files changed, 15 insertions(+)
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..c6d07cb 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -269,6 +269,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04
#define IEEE80211_RADIOTAP_MCS_HAVE_FMT 0x08
#define IEEE80211_RADIOTAP_MCS_HAVE_FEC 0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC 0x20
#define IEEE80211_RADIOTAP_MCS_BW_MASK 0x03
#define IEEE80211_RADIOTAP_MCS_BW_20 0
@@ -278,6 +279,12 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_SGI 0x04
#define IEEE80211_RADIOTAP_MCS_FMT_GF 0x08
#define IEEE80211_RADIOTAP_MCS_FEC_LDPC 0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60
+#define IEEE80211_RADIOTAP_MCS_STBC_1 1
+#define IEEE80211_RADIOTAP_MCS_STBC_2 2
+#define IEEE80211_RADIOTAP_MCS_STBC_3 3
+
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5
/* For IEEE80211_RADIOTAP_AMPDU_STATUS */
#define IEEE80211_RADIOTAP_AMPDU_REPORT_ZEROLEN 0x0001
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 885898a..16705a9 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -805,6 +805,7 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
* on this subframe
* @RX_FLAG_AMPDU_DELIM_CRC_KNOWN: The delimiter CRC field is known (the CRC
* is stored in the @ampdu_delimiter_crc field)
+ * @RX_FLAG_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3
*/
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
@@ -832,8 +833,11 @@ enum mac80211_rx_flags {
RX_FLAG_80MHZ = BIT(23),
RX_FLAG_80P80MHZ = BIT(24),
RX_FLAG_160MHZ = BIT(25),
+ RX_FLAG_STBC_MASK = BIT(26) | BIT(27),
};
+#define RX_FLAG_STBC_SHIFT 26
+
/**
* struct ieee80211_rx_status - receive status
*
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 8e29526..811dd64 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -258,6 +258,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
pos += 2;
if (status->flag & RX_FLAG_HT) {
+ unsigned int stbc;
rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_MCS);
*pos++ = local->hw.radiotap_mcs_details;
*pos = 0;
@@ -267,6 +268,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
*pos |= IEEE80211_RADIOTAP_MCS_BW_40;
if (status->flag & RX_FLAG_HT_GF)
*pos |= IEEE80211_RADIOTAP_MCS_FMT_GF;
+ stbc = status->flag & RX_FLAG_STBC_MASK;
+ *pos |= (stbc >> RX_FLAG_STBC_SHIFT)
+ << IEEE80211_RADIOTAP_MCS_STBC_SHIFT;
pos++;
*pos++ = status->rate_idx;
}
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v4 1/3] mac80211: add STBC flag for radiotap
From: Johannes Berg @ 2013-05-24 10:08 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1369389945-805-1-git-send-email-linux@rempel-privat.de>
On Fri, 2013-05-24 at 12:05 +0200, Oleksij Rempel wrote:
> Some chips can tell us if received frame was
> encoded with STBC or not. To make this information available
> in user space we can use updated radiotap specification:
> http://www.radiotap.org/defined-fields/MCS
>
> This patch will set number of STBC encoded spatial streams (Nss).
> The HAVE_STBC flag should be provided by driver.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH v4 1/3] mac80211: add STBC flag for radiotap
From: Oleksij Rempel @ 2013-05-24 10:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1369390088.8290.5.camel@jlt4.sipsolutions.net>
Am 24.05.2013 12:08, schrieb Johannes Berg:
> On Fri, 2013-05-24 at 12:05 +0200, Oleksij Rempel wrote:
>> Some chips can tell us if received frame was
>> encoded with STBC or not. To make this information available
>> in user space we can use updated radiotap specification:
>> http://www.radiotap.org/defined-fields/MCS
>>
>> This patch will set number of STBC encoded spatial streams (Nss).
>> The HAVE_STBC flag should be provided by driver.
>
> Applied, thanks.
>
thank you.
--
Regards,
Oleksij
^ permalink raw reply
* [PATCH 1/2] ath9k: remove useless flag conversation.
From: Oleksij Rempel @ 2013-05-24 10:18 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Oleksij Rempel
In-Reply-To: <1369390711-992-1-git-send-email-linux@rempel-privat.de>
some flags used only outside of ath9k - In this case we can use
"enum mac80211_rx_flags" and pass it upstream without extra
conversation.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++--
drivers/net/wireless/ath/ath9k/mac.c | 11 +++++++----
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/recv.c | 5 +----
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 301bf72..5163abd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -469,6 +469,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_status = 0;
rxs->rs_flags = 0;
+ rxs->flag = 0;
rxs->rs_datalen = rxsp->status2 & AR_DataLen;
rxs->rs_tstamp = rxsp->status3;
@@ -493,8 +494,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_isaggr = (rxsp->status11 & AR_RxAggr) ? 1 : 0;
rxs->rs_moreaggr = (rxsp->status11 & AR_RxMoreAggr) ? 1 : 0;
rxs->rs_antenna = (MS(rxsp->status4, AR_RxAntenna) & 0x7);
- rxs->rs_flags = (rxsp->status4 & AR_GI) ? ATH9K_RX_GI : 0;
- rxs->rs_flags |= (rxsp->status4 & AR_2040) ? ATH9K_RX_2040 : 0;
+ rxs->flag |= (rxsp->status4 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rxs->flag |= (rxsp->status4 & AR_2040) ? RX_FLAG_40MHZ : 0;
rxs->evm0 = rxsp->status6;
rxs->evm1 = rxsp->status7;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..a52081d 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_status = 0;
rs->rs_flags = 0;
+ rs->flag = 0;
rs->rs_datalen = ads.ds_rxstatus1 & AR_DataLen;
rs->rs_tstamp = ads.AR_RcvTimestamp;
@@ -586,10 +587,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_moreaggr =
(ads.ds_rxstatus8 & AR_RxMoreAggr) ? 1 : 0;
rs->rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
- rs->rs_flags =
- (ads.ds_rxstatus3 & AR_GI) ? ATH9K_RX_GI : 0;
- rs->rs_flags |=
- (ads.ds_rxstatus3 & AR_2040) ? ATH9K_RX_2040 : 0;
+
+ /* directly mapped flags for ieee80211_rx_status */
+ rs->flag |=
+ (ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rs->flag |=
+ (ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0;
if (ads.ds_rxstatus8 & AR_PreDelimCRCErr)
rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..3f1e775 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -149,6 +149,7 @@ struct ath_rx_status {
u32 evm2;
u32 evm3;
u32 evm4;
+ u32 flag; /* see enum mac80211_rx_flags */
};
struct ath_htc_rx_status {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 8be2b5d..b4b758d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -868,10 +868,7 @@ static int ath9k_process_rate(struct ath_common *common,
if (rx_stats->rs_rate & 0x80) {
/* HT rate */
rxs->flag |= RX_FLAG_HT;
- if (rx_stats->rs_flags & ATH9K_RX_2040)
- rxs->flag |= RX_FLAG_40MHZ;
- if (rx_stats->rs_flags & ATH9K_RX_GI)
- rxs->flag |= RX_FLAG_SHORT_GI;
+ rxs->flag |= rx_stats->flag;
rxs->rate_idx = rx_stats->rs_rate & 0x7f;
return 0;
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH 0/2] ath9k: STBC Rx monitoring
From: Oleksij Rempel @ 2013-05-24 10:18 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Oleksij Rempel
In-Reply-To: <1368949136-6079-1-git-send-email-linux@rempel-privat.de>
this are two remaining patches to allow STBC Rx monitoring
on ath9k devices.
This patches depend on currently applied:
[PATCH v4 1/3] mac80211: add STBC flag for radiotap
Oleksij Rempel (2):
ath9k: remove useless flag conversation.
ath9k: check for Rx-STBC flag and pass it to ieee80211
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++--
drivers/net/wireless/ath/ath9k/init.c | 9 +++++++--
drivers/net/wireless/ath/ath9k/mac.c | 16 ++++++++++++----
drivers/net/wireless/ath/ath9k/mac.h | 4 +++-
drivers/net/wireless/ath/ath9k/recv.c | 5 +----
5 files changed, 26 insertions(+), 13 deletions(-)
--
1.8.1.2
^ permalink raw reply
* [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
From: Oleksij Rempel @ 2013-05-24 10:18 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Oleksij Rempel
In-Reply-To: <1369390711-992-1-git-send-email-linux@rempel-privat.de>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
drivers/net/wireless/ath/ath9k/init.c | 9 +++++++--
drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index aba4151..7739b05 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
IEEE80211_HW_SUPPORTS_RC_TABLE;
- if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
- hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+ if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
+ hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ hw->radiotap_mcs_details |=
+ IEEE80211_RADIOTAP_MCS_HAVE_STBC;
+ }
if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || ath9k_modparam_nohwcrypt)
hw->flags |= IEEE80211_HW_MFP_CAPABLE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index a52081d..d055e38 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -593,6 +593,11 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
(ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
rs->flag |=
(ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0;
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ rs->flag |=
+ (ads.ds_rxstatus3 & AR_STBC) ?
+ /* we can only Nss=1 STBC */
+ (1 << RX_FLAG_STBC_SHIFT) : 0;
if (ads.ds_rxstatus8 & AR_PreDelimCRCErr)
rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 3f1e775..b02dfce 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -534,7 +534,8 @@ struct ar5416_desc {
#define AR_2040 0x00000002
#define AR_Parallel40 0x00000004
#define AR_Parallel40_S 2
-#define AR_RxStatusRsvd30 0x000000f8
+#define AR_STBC 0x00000008 /* on ar9280 and later */
+#define AR_RxStatusRsvd30 0x000000f0
#define AR_RxAntenna 0xffffff00
#define AR_RxAntenna_S 8
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
From: Johannes Berg @ 2013-05-24 10:29 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1369390711-992-3-git-send-email-linux@rempel-privat.de>
On Fri, 2013-05-24 at 12:18 +0200, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
> ---
> drivers/net/wireless/ath/ath9k/init.c | 9 +++++++--
> drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
> drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
> index aba4151..7739b05 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
> IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> IEEE80211_HW_SUPPORTS_RC_TABLE;
>
> - if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
> - hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
> + hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> +
> + if (AR_SREV_9280_20_OR_LATER(ah))
> + hw->radiotap_mcs_details |=
> + IEEE80211_RADIOTAP_MCS_HAVE_STBC;
> + }
Are you sure this is right? It seems that if other devices don't support
STBC they can report all frames to be w/o STBC. Or do they support STBC
but don't report it?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
From: Oleksij Rempel @ 2013-05-24 10:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1369391399.8290.6.camel@jlt4.sipsolutions.net>
Am 24.05.2013 12:29, schrieb Johannes Berg:
> On Fri, 2013-05-24 at 12:18 +0200, Oleksij Rempel wrote:
>> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>> ---
>> drivers/net/wireless/ath/ath9k/init.c | 9 +++++++--
>> drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
>> drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
>> 3 files changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
>> index aba4151..7739b05 100644
>> --- a/drivers/net/wireless/ath/ath9k/init.c
>> +++ b/drivers/net/wireless/ath/ath9k/init.c
>> @@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
>> IEEE80211_HW_REPORTS_TX_ACK_STATUS |
>> IEEE80211_HW_SUPPORTS_RC_TABLE;
>>
>> - if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
>> - hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
>> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
>> + hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
>> +
>> + if (AR_SREV_9280_20_OR_LATER(ah))
>> + hw->radiotap_mcs_details |=
>> + IEEE80211_RADIOTAP_MCS_HAVE_STBC;
>> + }
>
> Are you sure this is right? It seems that if other devices don't support
> STBC they can report all frames to be w/o STBC. Or do they support STBC
> but don't report it?
They support STBC but don't report it. First device whhic can report it
is ar9280.
--
Regards,
Oleksij
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
From: Oleksij Rempel @ 2013-05-24 11:35 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1369390711-992-3-git-send-email-linux@rempel-privat.de>
Am 24.05.2013 12:18, schrieb Oleksij Rempel:
> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
> ---
> drivers/net/wireless/ath/ath9k/init.c | 9 +++++++--
> drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
> drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
> index aba4151..7739b05 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
> IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> IEEE80211_HW_SUPPORTS_RC_TABLE;
>
> - if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
> - hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
> + hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> +
> + if (AR_SREV_9280_20_OR_LATER(ah))
> + hw->radiotap_mcs_details |=
> + IEEE80211_RADIOTAP_MCS_HAVE_STBC;
comment for my self. i forgot to include <net/ieee80211_radiotap.h>
for IEEE80211_RADIOTAP_MCS_HAVE_STBC. This patch is broken.
--
Regards,
Oleksij
^ permalink raw reply
* Re: [PATCH] B43: Handle DMA RX descriptor underrun
From: John W. Linville @ 2013-05-24 16:49 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless, b43-dev, m, piotras, Larry.Finger,
Thommy Jakobsson
In-Reply-To: <alpine.DEB.2.02.1305132025560.1278@kelly.ryd.net>
On Mon, May 13, 2013 at 08:27:08PM +0200, Thommy Jakobsson wrote:
>
>
> On Sun, 5 May 2013, Rafa? Mi?ecki wrote:
>
> > I think we may want turning this interrupt anyway, but I wonder if
> > there is another issue we just hide a bit better.
> >
> Any news on the testing Rafael? Did you have any more questions about the
> solution? Just let me know if I can help
>
> //Thommy
Ping? Should I drop this one?
--
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 V7 1/3] cfg80211: introduce critical protocol indication from user-space
From: Arend van Spriel @ 2013-05-24 16:43 UTC (permalink / raw)
To: Dan Williams; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <1369333809.25066.6.camel@dcbw.foobar.com>
On 05/23/2013 08:30 PM, Dan Williams wrote:
> On Thu, 2013-04-18 at 15:49 +0200, Arend van Spriel wrote:
>> Some protocols need a more reliable connection to complete
>> successful in reasonable time. This patch adds a user-space
>> API to indicate the wireless driver that a critical protocol
>> is about to commence and when it is done, using nl80211 primitives
>> NL80211_CMD_CRIT_PROTOCOL_START and NL80211_CRIT_PROTOCOL_STOP.
>>
>> There can be only on critical protocol session started per
>> registered cfg80211 device.
>
> Ok, so while implementing support for this in NetworkManager, I ran into
> a few questions some issues.
Hi Dan,
Thanks for your feedback.
> 1) Why have a new attribute? Why not just use NL80211_ATTR_DURATION
> like all the other commands do?
I guess it was overlooked. The only difference is that this attribute is
u32. I have not problem changing it.
> 2) Why have a restriction on a single critical protocol at a time? Even
> if this is the case *now*, just for sake of time, we should pass the
> protocol to the _STOP command to allow for multiples in the future.
>
> Yeah, you won't have EAPOL running at the same time as DHCP, but think
> about it from userspace's perspective:
>
> a) process A starts critical protocol like EAPOL
> b) process A forgets to stop critical protocol
> c) process B starts critical protocol DHCP, oops, error!
> d) process B has to clear old critical protocol
> e) process B starts critical protocol DHCP
> f) process A realizes it forgot (b) and stops protocol
>
> I think there's a lot of opportunity for races here. This would at
> least be reduced if the START/STOP commands were paired for a specific
> protocol, and if something requested a STOP for a protocol that's
> currently not started, it was rejected.
I guess you are right if the processes mentioned above share the same
netlink socket. That is why the netlink portid is used as a flag that a
critical protocol has been started. Just scrolled down and found we are
not checking the portid in nl80211_crit_proto_stop(). That needs to be
fixed or .... we should reconsider based on your feedback. I am not
fully convinced there will be a need for multiple protocols.
> Better yet, why not just have an internal array of all the protocols
> with their max duration and start time, and the stack manages when each
> protocol gets stopped? (unless you think drivers will have different
> behavior on a per-protocol basis, eg they'd do something different with
> DHCP than with EAPOL...?)
Not sure if I understand. Does 'start time' mean a fixed time after link
being established. The whole idea was that user-space tools would know
when a protocol would complete. I do not see how putting static numbers
into an array would be 'better yet'.
Regards,
Arend
>> The driver can support this by implementing the cfg80211 callbacks
>> .crit_proto_start() and .crit_proto_stop(). Examples of protocols
>> that can benefit from this are DHCP, EAPOL, APIPA. Exactly how the
>> link can/should be made more reliable is up to the driver. Things
>> to consider are avoid scanning, no multi-channel operations, and
>> alter coexistence schemes.
>>
>> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
>> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
>> Signed-off-by: Arend van Spriel <arend@broadcom.com>
>> ---
>> Hi Johannes,
>>
>> Not sure whether you made the minor fixes already as you offered
>> to do so. I saw the change pop-up in your repo a couple of nights
>> ago, but it disappeared the next morning after another fetch.
>>
>> I also made related changes in our brcmfmac driver. Can you take
>> them through your tree as well.
>>
>> Regards,
>> Arend
>>
>> Changelog:
>> ----------
>> V7:
>> - remove crit_proto_started field from wireless_dev.
>> - remove CRIT_PROTO_STOPPED_EVENT definition.
>> - allow always calling cfg80211_crit_proto_stopped().
>> V6:
>> - added crit_proto_stopped event message.
>> - use nlportid as flag for critical protocol being active.
>> - return error when duration is over specified limit.
>> - remove logic from rdev_* inline wrappers.
>> - added more documentation.
>> - some renaming of identifiers.
>> V5:
>> - change return type for .crit_prot_stop() to void.
>> - correct limiting the duration.
>> V4:
>> - added cfg80211_crit_proto_stopped() for drivers to use.
>> - added back protocol identifier for drivers to use.
>> - reject starting critical protocol session when already started.
>> - critical protocol session tracked per registered device.
>> V3:
>> - remove protocol identifier.
>> - remove delayed work from cfg80211.
>> - guard maximum limit for duration.
>> - do .crit_proto_stop() upon netlink socket release.
>> V2:
>> - subject changed. Below previous subject is given for reference:
>> [RFC] cfg80211: configuration of Bluetooth coexistence mode
>> - introduced dedicated nl80211 API.
>> V1:
>> - initial proposal.
>> ---
>> include/net/cfg80211.h | 23 +++++++++
>> include/uapi/linux/nl80211.h | 39 ++++++++++++++
>> net/wireless/core.h | 3 ++
>> net/wireless/mlme.c | 5 ++
>> net/wireless/nl80211.c | 117 ++++++++++++++++++++++++++++++++++++++++++
>> net/wireless/rdev-ops.h | 24 ++++++++-
>> net/wireless/trace.h | 35 +++++++++++++
>> 7 files changed, 245 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>> index dff96d8..26b5b69 100644
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -2002,6 +2002,12 @@ struct cfg80211_update_ft_ies_params {
>> * @update_ft_ies: Provide updated Fast BSS Transition information to the
>> * driver. If the SME is in the driver/firmware, this information can be
>> * used in building Authentication and Reassociation Request frames.
>> + *
>> + * @crit_proto_start: Indicates a critical protocol needs more link reliability
>> + * for a given duration (milliseconds). The protocol is provided so the
>> + * driver can take the most appropriate actions.
>> + * @crit_proto_stop: Indicates critical protocol no longer needs increased link
>> + * reliability. This operation can not fail.
>> */
>> struct cfg80211_ops {
>> int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
>> @@ -2231,6 +2237,12 @@ struct cfg80211_ops {
>> struct cfg80211_chan_def *chandef);
>> int (*update_ft_ies)(struct wiphy *wiphy, struct net_device *dev,
>> struct cfg80211_update_ft_ies_params *ftie);
>> + int (*crit_proto_start)(struct wiphy *wiphy,
>> + struct wireless_dev *wdev,
>> + enum nl80211_crit_proto_id protocol,
>> + u16 duration);
>> + void (*crit_proto_stop)(struct wiphy *wiphy,
>> + struct wireless_dev *wdev);
>> };
>>
>> /*
>> @@ -4137,6 +4149,17 @@ void cfg80211_report_wowlan_wakeup(struct wireless_dev *wdev,
>> struct cfg80211_wowlan_wakeup *wakeup,
>> gfp_t gfp);
>>
>> +/**
>> + * cfg80211_crit_proto_stopped() - indicate critical protocol stopped by driver.
>> + *
>> + * @wdev: the wireless device for which critical protocol is stopped.
>> + *
>> + * This function can be called by the driver to indicate it has reverted
>> + * operation back to normal. One reason could be that the duration given
>> + * by .crit_proto_start() has expired.
>> + */
>> +void cfg80211_crit_proto_stopped(struct wireless_dev *wdev, gfp_t gfp);
>> +
>> /* Logging, debugging and troubleshooting/diagnostic helpers. */
>>
>> /* wiphy_printk helpers, similar to dev_printk */
>> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
>> index 79da871..d1e48b5 100644
>> --- a/include/uapi/linux/nl80211.h
>> +++ b/include/uapi/linux/nl80211.h
>> @@ -639,6 +639,13 @@
>> * with the relevant Information Elements. This event is used to report
>> * received FT IEs (MDIE, FTIE, RSN IE, TIE, RICIE).
>> *
>> + * @NL80211_CMD_CRIT_PROTOCOL_START: Indicates user-space will start running
>> + * a critical protocol that needs more reliability in the connection to
>> + * complete.
>> + *
>> + * @NL80211_CMD_CRIT_PROTOCOL_STOP: Indicates the connection reliability can
>> + * return back to normal.
>> + *
>> * @NL80211_CMD_MAX: highest used command number
>> * @__NL80211_CMD_AFTER_LAST: internal use
>> */
>> @@ -798,6 +805,9 @@ enum nl80211_commands {
>> NL80211_CMD_UPDATE_FT_IES,
>> NL80211_CMD_FT_EVENT,
>>
>> + NL80211_CMD_CRIT_PROTOCOL_START,
>> + NL80211_CMD_CRIT_PROTOCOL_STOP,
>> +
>> /* add new commands above here */
>>
>> /* used to define NL80211_CMD_MAX below */
>> @@ -1414,6 +1424,11 @@ enum nl80211_commands {
>> * @NL80211_ATTR_IE_RIC: Resource Information Container Information
>> * Element
>> *
>> + * @NL80211_ATTR_CRIT_PROT_ID: critical protocol identifier requiring increased
>> + * reliability, see &enum nl80211_crit_proto_id (u16).
>> + * @NL80211_ATTR_MAX_CRIT_PROT_DURATION: duration in milliseconds in which
>> + * the connection should have increased reliability (u16).
>> + *
>> * @NL80211_ATTR_MAX: highest attribute number currently defined
>> * @__NL80211_ATTR_AFTER_LAST: internal use
>> */
>> @@ -1709,6 +1724,9 @@ enum nl80211_attrs {
>> NL80211_ATTR_MDID,
>> NL80211_ATTR_IE_RIC,
>>
>> + NL80211_ATTR_CRIT_PROT_ID,
>> + NL80211_ATTR_MAX_CRIT_PROT_DURATION,
>> +
>> /* add attributes here, update the policy in nl80211.c */
>>
>> __NL80211_ATTR_AFTER_LAST,
>> @@ -3682,4 +3700,25 @@ enum nl80211_protocol_features {
>> NL80211_PROTOCOL_FEATURE_SPLIT_WIPHY_DUMP = 1 << 0,
>> };
>>
>> +/**
>> + * enum nl80211_crit_proto_id - nl80211 critical protocol identifiers
>> + *
>> + * @NL80211_CRIT_PROTO_UNSPEC: protocol unspecified.
>> + * @NL80211_CRIT_PROTO_DHCP: BOOTP or DHCPv6 protocol.
>> + * @NL80211_CRIT_PROTO_EAPOL: EAPOL protocol.
>> + * @NL80211_CRIT_PROTO_APIPA: APIPA protocol.
>> + * @NUM_NL80211_CRIT_PROTO: must be kept last.
>> + */
>> +enum nl80211_crit_proto_id {
>> + NL80211_CRIT_PROTO_UNSPEC,
>> + NL80211_CRIT_PROTO_DHCP,
>> + NL80211_CRIT_PROTO_EAPOL,
>> + NL80211_CRIT_PROTO_APIPA,
>> + /* add other protocols before this one */
>> + NUM_NL80211_CRIT_PROTO
>> +};
>> +
>> +/* maximum duration for critical protocol measures */
>> +#define NL80211_CRIT_PROTO_MAX_DURATION 5000 /* msec */
>> +
>> #endif /* __LINUX_NL80211_H */
>> diff --git a/net/wireless/core.h b/net/wireless/core.h
>> index d5d06fd..eac5308 100644
>> --- a/net/wireless/core.h
>> +++ b/net/wireless/core.h
>> @@ -88,6 +88,9 @@ struct cfg80211_registered_device {
>>
>> struct delayed_work dfs_update_channels_wk;
>>
>> + /* netlink port which started critical protocol (0 means not started) */
>> + u32 crit_proto_nlportid;
>> +
>> /* must be last because of the way we do wiphy_priv(),
>> * and it should at least be aligned to NETDEV_ALIGN */
>> struct wiphy wiphy __aligned(NETDEV_ALIGN);
>> diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
>> index 390198b..0c7b7dd 100644
>> --- a/net/wireless/mlme.c
>> +++ b/net/wireless/mlme.c
>> @@ -648,6 +648,11 @@ void cfg80211_mlme_unregister_socket(struct wireless_dev *wdev, u32 nlportid)
>>
>> spin_unlock_bh(&wdev->mgmt_registrations_lock);
>>
>> + if (nlportid && rdev->crit_proto_nlportid == nlportid) {
>> + rdev->crit_proto_nlportid = 0;
>> + rdev_crit_proto_stop(rdev, wdev);
>> + }
>> +
>> if (nlportid == wdev->ap_unexpected_nlportid)
>> wdev->ap_unexpected_nlportid = 0;
>> }
>> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
>> index f924d45..96ba1eb 100644
>> --- a/net/wireless/nl80211.c
>> +++ b/net/wireless/nl80211.c
>> @@ -1417,6 +1417,10 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *dev,
>> }
>> CMD(start_p2p_device, START_P2P_DEVICE);
>> CMD(set_mcast_rate, SET_MCAST_RATE);
>> + if (split) {
>> + CMD(crit_proto_start, CRIT_PROTOCOL_START);
>> + CMD(crit_proto_stop, CRIT_PROTOCOL_STOP);
>> + }
>>
>> #ifdef CONFIG_NL80211_TESTMODE
>> CMD(testmode_cmd, TESTMODE);
>> @@ -8196,6 +8200,64 @@ static int nl80211_update_ft_ies(struct sk_buff *skb, struct genl_info *info)
>> return rdev_update_ft_ies(rdev, dev, &ft_params);
>> }
>>
>> +static int nl80211_crit_protocol_start(struct sk_buff *skb,
>> + struct genl_info *info)
>> +{
>> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> + struct wireless_dev *wdev = info->user_ptr[1];
>> + enum nl80211_crit_proto_id proto = NL80211_CRIT_PROTO_UNSPEC;
>> + u16 duration;
>> + int ret;
>> +
>> + if (!rdev->ops->crit_proto_start)
>> + return -EOPNOTSUPP;
>> +
>> + if (WARN_ON(!rdev->ops->crit_proto_stop))
>> + return -EINVAL;
>> +
>> + if (rdev->crit_proto_nlportid)
>> + return -EBUSY;
>> +
>> + /* determine protocol if provided */
>> + if (info->attrs[NL80211_ATTR_CRIT_PROT_ID])
>> + proto = nla_get_u16(info->attrs[NL80211_ATTR_CRIT_PROT_ID]);
>> +
>> + if (proto >= NUM_NL80211_CRIT_PROTO)
>> + return -EINVAL;
>> +
>> + /* timeout must be provided */
>> + if (!info->attrs[NL80211_ATTR_MAX_CRIT_PROT_DURATION])
>> + return -EINVAL;
>> +
>> + duration =
>> + nla_get_u16(info->attrs[NL80211_ATTR_MAX_CRIT_PROT_DURATION]);
>> +
>> + if (duration > NL80211_CRIT_PROTO_MAX_DURATION)
>> + return -ERANGE;
>> +
>> + ret = rdev_crit_proto_start(rdev, wdev, proto, duration);
>> + if (!ret)
>> + rdev->crit_proto_nlportid = info->snd_portid;
>> +
>> + return ret;
>> +}
>> +
>> +static int nl80211_crit_protocol_stop(struct sk_buff *skb,
>> + struct genl_info *info)
>> +{
>> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> + struct wireless_dev *wdev = info->user_ptr[1];
>> +
>> + if (!rdev->ops->crit_proto_stop)
>> + return -EOPNOTSUPP;
>> +
>> + if (rdev->crit_proto_nlportid) {
>> + rdev->crit_proto_nlportid = 0;
>> + rdev_crit_proto_stop(rdev, wdev);
>> + }
>> + return 0;
>> +}
>> +
>> #define NL80211_FLAG_NEED_WIPHY 0x01
>> #define NL80211_FLAG_NEED_NETDEV 0x02
>> #define NL80211_FLAG_NEED_RTNL 0x04
>> @@ -8885,6 +8947,22 @@ static struct genl_ops nl80211_ops[] = {
>> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
>> NL80211_FLAG_NEED_RTNL,
>> },
>> + {
>> + .cmd = NL80211_CMD_CRIT_PROTOCOL_START,
>> + .doit = nl80211_crit_protocol_start,
>> + .policy = nl80211_policy,
>> + .flags = GENL_ADMIN_PERM,
>> + .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
>> + NL80211_FLAG_NEED_RTNL,
>> + },
>> + {
>> + .cmd = NL80211_CMD_CRIT_PROTOCOL_STOP,
>> + .doit = nl80211_crit_protocol_stop,
>> + .policy = nl80211_policy,
>> + .flags = GENL_ADMIN_PERM,
>> + .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
>> + NL80211_FLAG_NEED_RTNL,
>> + }
>> };
>>
>> static struct genl_multicast_group nl80211_mlme_mcgrp = {
>> @@ -10630,6 +10708,45 @@ void cfg80211_ft_event(struct net_device *netdev,
>> }
>> EXPORT_SYMBOL(cfg80211_ft_event);
>>
>> +void cfg80211_crit_proto_stopped(struct wireless_dev *wdev, gfp_t gfp)
>> +{
>> + struct cfg80211_registered_device *rdev;
>> + struct sk_buff *msg;
>> + void *hdr;
>> + u32 nlportid;
>> +
>> + rdev = wiphy_to_dev(wdev->wiphy);
>> + if (!rdev->crit_proto_nlportid)
>> + return;
>> +
>> + nlportid = rdev->crit_proto_nlportid;
>> + rdev->crit_proto_nlportid = 0;
>> +
>> + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
>> + if (!msg)
>> + return;
>> +
>> + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_CRIT_PROTOCOL_STOP);
>> + if (!hdr)
>> + goto nla_put_failure;
>> +
>> + if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) ||
>> + nla_put_u64(msg, NL80211_ATTR_WDEV, wdev_id(wdev)))
>> + goto nla_put_failure;
>> +
>> + genlmsg_end(msg, hdr);
>> +
>> + genlmsg_unicast(wiphy_net(&rdev->wiphy), msg, nlportid);
>> + return;
>> +
>> + nla_put_failure:
>> + if (hdr)
>> + genlmsg_cancel(msg, hdr);
>> + nlmsg_free(msg);
>> +
>> +}
>> +EXPORT_SYMBOL(cfg80211_crit_proto_stopped);
>> +
>> /* initialisation/exit functions */
>>
>> int nl80211_init(void)
>> diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
>> index d77e1c1..9f15f0a 100644
>> --- a/net/wireless/rdev-ops.h
>> +++ b/net/wireless/rdev-ops.h
>> @@ -875,7 +875,7 @@ static inline void rdev_stop_p2p_device(struct cfg80211_registered_device *rdev,
>> trace_rdev_stop_p2p_device(&rdev->wiphy, wdev);
>> rdev->ops->stop_p2p_device(&rdev->wiphy, wdev);
>> trace_rdev_return_void(&rdev->wiphy);
>> -}
>> +}
>>
>> static inline int rdev_set_mac_acl(struct cfg80211_registered_device *rdev,
>> struct net_device *dev,
>> @@ -901,4 +901,26 @@ static inline int rdev_update_ft_ies(struct cfg80211_registered_device *rdev,
>> return ret;
>> }
>>
>> +static inline int rdev_crit_proto_start(struct cfg80211_registered_device *rdev,
>> + struct wireless_dev *wdev,
>> + enum nl80211_crit_proto_id protocol,
>> + u16 duration)
>> +{
>> + int ret;
>> +
>> + trace_rdev_crit_proto_start(&rdev->wiphy, wdev, protocol, duration);
>> + ret = rdev->ops->crit_proto_start(&rdev->wiphy, wdev,
>> + protocol, duration);
>> + trace_rdev_return_int(&rdev->wiphy, ret);
>> + return ret;
>> +}
>> +
>> +static inline void rdev_crit_proto_stop(struct cfg80211_registered_device *rdev,
>> + struct wireless_dev *wdev)
>> +{
>> + trace_rdev_crit_proto_stop(&rdev->wiphy, wdev);
>> + rdev->ops->crit_proto_stop(&rdev->wiphy, wdev);
>> + trace_rdev_return_void(&rdev->wiphy);
>> +}
>> +
>> #endif /* __CFG80211_RDEV_OPS */
>> diff --git a/net/wireless/trace.h b/net/wireless/trace.h
>> index ccadef2..499c982 100644
>> --- a/net/wireless/trace.h
>> +++ b/net/wireless/trace.h
>> @@ -1805,6 +1805,41 @@ TRACE_EVENT(rdev_update_ft_ies,
>> WIPHY_PR_ARG, NETDEV_PR_ARG, __entry->md)
>> );
>>
>> +TRACE_EVENT(rdev_crit_proto_start,
>> + TP_PROTO(struct wiphy *wiphy, struct wireless_dev *wdev,
>> + enum nl80211_crit_proto_id protocol, u16 duration),
>> + TP_ARGS(wiphy, wdev, protocol, duration),
>> + TP_STRUCT__entry(
>> + WIPHY_ENTRY
>> + WDEV_ENTRY
>> + __field(u16, proto)
>> + __field(u16, duration)
>> + ),
>> + TP_fast_assign(
>> + WIPHY_ASSIGN;
>> + WDEV_ASSIGN;
>> + __entry->proto = protocol;
>> + __entry->duration = duration;
>> + ),
>> + TP_printk(WIPHY_PR_FMT ", " WDEV_PR_FMT ", proto=%x, duration=%u",
>> + WIPHY_PR_ARG, WDEV_PR_ARG, __entry->proto, __entry->duration)
>> +);
>> +
>> +TRACE_EVENT(rdev_crit_proto_stop,
>> + TP_PROTO(struct wiphy *wiphy, struct wireless_dev *wdev),
>> + TP_ARGS(wiphy, wdev),
>> + TP_STRUCT__entry(
>> + WIPHY_ENTRY
>> + WDEV_ENTRY
>> + ),
>> + TP_fast_assign(
>> + WIPHY_ASSIGN;
>> + WDEV_ASSIGN;
>> + ),
>> + TP_printk(WIPHY_PR_FMT ", " WDEV_PR_FMT,
>> + WIPHY_PR_ARG, WDEV_PR_ARG)
>> +);
>> +
>> /*************************************************************
>> * cfg80211 exported functions traces *
>> *************************************************************/
>
>
>
^ permalink raw reply
* Mobile Broadband Interface Model (MBIM) support?
From: Sarah Sharp @ 2013-05-24 17:09 UTC (permalink / raw)
To: linux-wireless, netdev, linux-usb; +Cc: Ismail, Rahman, Wallick, Stephanie S
Do we have support for the new extensions for USB communication devices
that use the Mobile Broadband Interface Model (MBIM) spec?
http://www.usb.org/developers/devclass_docs/MBIM10Errata1.zip
The spec was released pretty recently, which is why I'm asking on the
mailing lists, rather than digging around the kernel tree for a driver.
Sarah Sharp
^ permalink raw reply
* Re: [PATCH] ST-E CW1200 driver (v6)
From: John W. Linville @ 2013-05-24 17:50 UTC (permalink / raw)
To: Solomon Peachy; +Cc: linux-wireless
In-Reply-To: <1367090847-11937-1-git-send-email-pizza@shaftnet.org>
On Sat, Apr 27, 2013 at 03:27:13PM -0400, Solomon Peachy wrote:
> I'd love to see this finally committed upstream. There are no known
> bugs in the code, and it handles everything I (and other testers I've
> been working with) have thrown at it.
>
> Changes from the last patch series (v5):
> * Updated contact info for original author (Dmitry Tarnyagin)
> * Better documented the DPLL constants
> * Fixed more checkpatch warnings
> * Better logging in scan and bss loss state machines
> * BSS loss mitigation reimplemented (differently) due to FW bugginess
> * Reworked locking in the join code to handle rare corner cases
I'm sorry, but this just doesn't build on the current wireless-next
and I don't have enough time ATM to chase-down all the fix-ups.
Could you work that out and repost? Please also check the Kconfig
stuff, as that still seemed to be broken...
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: Mobile Broadband Interface Model (MBIM) support?
From: Sarah Sharp @ 2013-05-24 18:10 UTC (permalink / raw)
To: linux-wireless, netdev, linux-usb, dcbw
Cc: Ismail, Rahman, Wallick, Stephanie S
In-Reply-To: <20130524170915.GA15788@xanatos>
Ccing Dan Williams, since Johannes Berg mentioned on IRC that Dan might
know the status of MBIM support.
On Fri, May 24, 2013 at 10:09:15AM -0700, Sarah Sharp wrote:
> Do we have support for the new extensions for USB communication devices
> that use the Mobile Broadband Interface Model (MBIM) spec?
>
> http://www.usb.org/developers/devclass_docs/MBIM10Errata1.zip
>
> The spec was released pretty recently, which is why I'm asking on the
> mailing lists, rather than digging around the kernel tree for a driver.
>
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
From: Oleksij Rempel @ 2013-05-24 18:30 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Oleksij Rempel
In-Reply-To: <1368949136-6079-1-git-send-email-linux@rempel-privat.de>
This patch make use of STBC flag in DMA RX descriptor.
Only devices after ar9280 can provide this information.
If card support it we will set HAVE_STBC flag, to show
clint programm thet STBC is supported but not received.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
drivers/net/wireless/ath/ath9k/init.c | 10 ++++++++--
drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index aba4151..b9c97d4 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -21,6 +21,7 @@
#include <linux/ath9k_platform.h>
#include <linux/module.h>
#include <linux/relay.h>
+#include <net/ieee80211_radiotap.h>
#include "ath9k.h"
@@ -769,8 +770,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
IEEE80211_HW_SUPPORTS_RC_TABLE;
- if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
- hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+ if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
+ hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ hw->radiotap_mcs_details |=
+ IEEE80211_RADIOTAP_MCS_HAVE_STBC;
+ }
if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || ath9k_modparam_nohwcrypt)
hw->flags |= IEEE80211_HW_MFP_CAPABLE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index a52081d..d055e38 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -593,6 +593,11 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
(ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
rs->flag |=
(ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0;
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ rs->flag |=
+ (ads.ds_rxstatus3 & AR_STBC) ?
+ /* we can only Nss=1 STBC */
+ (1 << RX_FLAG_STBC_SHIFT) : 0;
if (ads.ds_rxstatus8 & AR_PreDelimCRCErr)
rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 3f1e775..b02dfce 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -534,7 +534,8 @@ struct ar5416_desc {
#define AR_2040 0x00000002
#define AR_Parallel40 0x00000004
#define AR_Parallel40_S 2
-#define AR_RxStatusRsvd30 0x000000f8
+#define AR_STBC 0x00000008 /* on ar9280 and later */
+#define AR_RxStatusRsvd30 0x000000f0
#define AR_RxAntenna 0xffffff00
#define AR_RxAntenna_S 8
--
1.8.1.2
^ permalink raw reply related
* Re: Mobile Broadband Interface Model (MBIM) support?
From: Bjørn Mork @ 2013-05-24 19:08 UTC (permalink / raw)
To: Sarah Sharp
Cc: linux-wireless, linux-usb, Ismail, Rahman, Wallick, Stephanie S
In-Reply-To: <20130524170915.GA15788@xanatos>
[resending due to an unreliable smtp smarthost - apologies if you
receive any duplicates]
Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> Do we have support for the new extensions for USB communication devices
> that use the Mobile Broadband Interface Model (MBIM) spec?
We do. See drivers/net/usb/cdc_mbim.c. It's a usbnet minidriver based on
reusing parts of cdc_ncm. It should be fairly complete, but the IP
session multiplexing and Device Service Streams features are not tested
on actual devices. I just haven't found any device with those features
yet. Any hints are appreciated...
The management protocol implementation is completely delegated to
userspace. The driver isn't involved at all. One implementation is
libmbim, which just had its 1.0.0 release:
http://www.freedesktop.org/software/libmbim/
The next ModemManager release will support MBIM devices using this
library.
> http://www.usb.org/developers/devclass_docs/MBIM10Errata1.zip
Thanks for that pointer. I haven't seen the errata before. Will study
it, but fortunately we are protected against anything involving
management protocol updates.
> The spec was released pretty recently, which is why I'm asking on the
> mailing lists, rather than digging around the kernel tree for a driver.
Well, a "git grep MBIM drivers/" would be enough. But I'm happy to
answer your questions :)
Bjørn
^ permalink raw reply
* Re: Mobile Broadband Interface Model (MBIM) support?
From: Bjørn Mork @ 2013-05-24 18:14 UTC (permalink / raw)
To: Sarah Sharp
Cc: linux-wireless, linux-usb, Ismail, Rahman, Wallick, Stephanie S
In-Reply-To: <20130524170915.GA15788@xanatos>
Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> Do we have support for the new extensions for USB communication devices
> that use the Mobile Broadband Interface Model (MBIM) spec?
We do. See drivers/net/usb/cdc_mbim.c. It's a usbnet minidriver based on
reusing parts of cdc_ncm. It should be fairly complete, but the IP
session multiplexing and Device Service Streams features are not tested
on actual devices. I just haven't found any device with those features
yet. Any hints are appreciated...
The management protocol implementation is completely delegated to
userspace. The driver isn't involved at all. One implementation is
libmbim, which just had its 1.0.0 release:
http://www.freedesktop.org/software/libmbim/
The next ModemManager release will support MBIM devices using this
library.
> http://www.usb.org/developers/devclass_docs/MBIM10Errata1.zip
Thanks for that pointer. I haven't seen the errata before. Will study
it, but fortunately we are protected against anything involving
management protocol updates.
> The spec was released pretty recently, which is why I'm asking on the
> mailing lists, rather than digging around the kernel tree for a driver.
Well, a "git grep MBIM drivers/" would be enough. But I'm happy to
answer your questions :)
Bjørn
^ permalink raw reply
* Re: Mobile Broadband Interface Model (MBIM) support?
From: Bjørn Mork @ 2013-05-24 19:31 UTC (permalink / raw)
To: Sarah Sharp
Cc: linux-wireless, linux-usb, Ismail, Rahman, Wallick, Stephanie S
In-Reply-To: <87zjvkdwlf.fsf@nemi.mork.no>
Bjørn Mork <bjorn@mork.no> writes:
>> http://www.usb.org/developers/devclass_docs/MBIM10Errata1.zip
>
> Thanks for that pointer. I haven't seen the errata before. Will study
> it, but fortunately we are protected against anything involving
> management protocol updates.
Yuck. When did the USB-IF start publishing the erratas merged with the
original with absolutely no indication about what they changed? This
sucks.
And the changes I notice also suck. WTF do they need another functional
descriptor for? For these two numbers? :
bMaxOutstandingCommand - Max number of outstanding Command Messages the
device can handle simultaneously. Shall be greater than 0.
wMTU - Operator preferred MTU for home network. wMTU applies to IP Data
Streams.
This is just plain stupid. Sorry. I don't know how else to describe
it. They already have an extensible management protocol. These numbers
could easily have been published through that. And "Operator preferred
MTU for home network" cannot possibly be a device specific attribute.
That's obviously a network attribute. How the heck can you put that
into a functional descriptor? It may change with the SIM card.
And then there are the things they didn't correct. I've been looking
for the "MBIMRegistry" they refer to ever since the initial version was
published. AFAICS there is none. I tried mailing admin@usb.org about
it in February, but haven't received any replies. As expected.
There are already several vendor specific UUIDs in use. The registry is
needed if we are expected to support any of these. Microsoft is the only
one documenting theirs AFAIK:
http://msdn.microsoft.com/en-us/library/windows/hardware/jj248720.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/jj248721.aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/jj149393.aspx
But I've also seen vendor specific services from Qualcomm, AT&T,
Ericsson, Huawei and MediaTek. All completely undocumented wrt open
source implementations, although I have successfully guessed how to use
the Qualcomm service (it embeds Qualcomms proprietary, but partly openly
documented, QMI protocol in MBIM).
Bjørn
^ permalink raw reply
* Re: [PATCH v2 1/2] cfg80211/nl80211: rename packet pattern related structures and enums
From: Johannes Berg @ 2013-05-24 20:10 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-wireless, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho, Amitkumar Karwar
In-Reply-To: <1369344908-11184-1-git-send-email-bzhao@marvell.com>
On Thu, 2013-05-23 at 14:35 -0700, Bing Zhao wrote:
> -enum nl80211_wowlan_packet_pattern_attr {
I think you missed a #define for this?
> +/* only for backward compatibility */
> +#define __NL80211_WOWLAN_PKTPAT_INVALID __NL80211_INVALID,
that , at the end looks like a copy/paste error, but in fact shouldn't
it be "__NL80211_PKTPAT_INVALID" anyway?
> * that is part of %NL80211_ATTR_WOWLAN_TRIGGERS_SUPPORTED in the
> * capability information given by the kernel to userspace.
Should this be updated?
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] cfg80211/nl80211: Add packet coalesce support
From: Johannes Berg @ 2013-05-24 20:22 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-wireless, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho, Amitkumar Karwar
In-Reply-To: <1369344908-11184-2-git-send-email-bzhao@marvell.com>
Some smallish things.
> In most cases, host that receives IPv4 and IPv6 multicast/broadcast
> packets does not do anything with these packets. Therefore the
> reception of these unwanted packets causes unnecessary processing
> and power consumption.
This is curious, you already discard those that you don't care about by
way of multicast filtering, no? What's the added advantage here? Would
you coalesce interrupts for those packets that pass the filter(s)? But
those packets are packets that the host cares about, no?
> /**
> + * struct cfg80211_coalesce_rules - Coalesce rule parameters
> + *
> + * This structure defines coalesce rule for the device.
> + * @delay: maximum coalescing delay in msecs.
> + * @condition: condition for packet coalescence.
> + * i.e. pattern 'match' or 'no match'
> + * @patterns: array of packet patterns
> + * @n_patterns: number of patterns
> + */
> +struct cfg80211_coalesce_rules {
> + int delay;
> + u8 condition;
seems like "condition" should be of some enum type? presumably an
nl80211 enum type that userspace can use?
> + struct cfg80211_pkt_pattern *patterns;
const?
> +struct cfg80211_coalesce {
> + struct cfg80211_coalesce_rules **rules;
> + int n_rules;
> +};
I think you can pass these as two function arguments rather than a
separate struct.
> @@ -3027,7 +3063,6 @@ enum nl80211_cqm_rssi_threshold_event {
> NL80211_CQM_RSSI_BEACON_LOSS_EVENT,
> };
>
> -
> /**
> * enum nl80211_tx_power_setting - TX power adjustment
> * @NL80211_TX_POWER_AUTOMATIC: automatically determine transmit power
seems spurious :)
> * This struct is carried in %NL80211_WOWLAN_TRIG_PKT_PATTERN when
> - * that is part of %NL80211_ATTR_WOWLAN_TRIGGERS_SUPPORTED in the
> - * capability information given by the kernel to userspace.
> + * that is part of %NL80211_ATTR_WOWLAN_TRIGGERS_SUPPORTED or in
> + * %NL80211_ATTR_COALESCE_RULE_PKT_PATTERN when that is part of
> + * %NL80211_ATTR_COALESCE_RULE in the capability information given
> + * by the kernel to userspace.
Ah, I think here you're updating what I asked about before.
> + * @NL80211_ATTR_COALESCE_RULE_CONDITION: condition for packet coalescence.
> + * i.e. pattern 'match' or 'no match'
I'm sure the condition attribute isn't a string, so this should say
which enum to take the value from?
> + * @NL80211_FEATURE_PACKET_COALESCE: This driver support packet coalescing
> + * feature. Packets are buffered in firmware based on configured rules
> + * to reduce unwanted packet or interrupt to host.
I don't think you need this, since you have this:
> + struct wiphy_coalesce_support coalesce;
Actually, you should probably make that a pointer, then it can be NULL
for drivers not supporting it, and static const for those that do. Means
you should make it a const pointer, of course.
Userspace can tell by checking if the support is advertised.
> +static inline void
> +cfg80211_rdev_free_coalesce(struct cfg80211_registered_device *rdev)
That's fairly big, would prefer not to inline it.
> +static int nl80211_set_coalesce(struct sk_buff *skb, struct genl_info *info)
> +{
> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
> + struct nlattr *tb[NUM_NL80211_ATTR_COALESCE_RULE];
> + struct wiphy_coalesce_support *coalesce = &rdev->wiphy.coalesce;
> + struct cfg80211_coalesce_rules new_rule = {};
> + struct cfg80211_coalesce_rules *nrule;
> + int err, i;
> +
> + if (!(rdev->wiphy.features & NL80211_FEATURE_PACKET_COALESCE))
> + return -EOPNOTSUPP;
Then this should check the coalesce pointer of course, which can then be
NULL.
> + if (!rdev->coalesce) {
> + rdev->coalesce = kzalloc(sizeof(*rdev->coalesce), GFP_KERNEL);
> + rdev->coalesce->rules = kcalloc(coalesce->n_rules,
> + sizeof(void *), GFP_KERNEL);
> + }
> +
> + if (rdev->coalesce->n_rules >= coalesce->n_rules)
> + return -EOPNOTSUPP;
This is bad. You leave rdev->coalesce assigned, but it's completely
invalid data. IMHO you should use a temporary variable and only assign
it when it's fully parsed, freeing it if not. That way, you also don't
kill old values when new invalid values are parsed.
> + new_rule.delay = nla_get_u32(tb[NL80211_ATTR_COALESCE_RULE_DELAY]);
> + new_rule.condition =
> + nla_get_u8(tb[NL80211_ATTR_COALESCE_RULE_CONDITION]);
Needs sanity checking, what if userspace passes the value 17? Does that
mean anything? :)
> + nla_for_each_nested(pat,
> + tb[NL80211_ATTR_COALESCE_RULE_PKT_PATTERN],
> + rem) {
> + nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
> + nla_len(pat), NULL);
> + err = -EINVAL;
> + if (!pat_tb[NL80211_PKTPAT_MASK] ||
> + !pat_tb[NL80211_PKTPAT_PATTERN])
> + goto error;
> + pat_len = nla_len(pat_tb[NL80211_PKTPAT_PATTERN]);
> + mask_len = DIV_ROUND_UP(pat_len, 8);
> + if (nla_len(pat_tb[NL80211_PKTPAT_MASK]) !=
> + mask_len)
> + goto error;
> + if (pat_len > coalesce->pattern_max_len ||
> + pat_len < coalesce->pattern_min_len)
> + goto error;
I wonder if any of this could be refactored with WoWLAN? Not really sure
though, maybe not.
> + err = rdev->ops->set_coalesce(&rdev->wiphy, nrule);
> + if (err)
> + goto error;
> +
> + rdev->coalesce->rules[rdev->coalesce->n_rules++] = nrule;
Wait ... you can't delete old rules, only add new ones? I think I'm
confused, I thought the SET command was going to overwrite all old
rules?
johannes
^ permalink raw reply
* Re: [RFT/RFC 0/4] iwlegacy: workaround for firmware frame tx rejection
From: Johannes Berg @ 2013-05-24 20:26 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Jake Edge
In-Reply-To: <1369311660-15378-1-git-send-email-sgruszka@redhat.com>
On Thu, 2013-05-23 at 14:20 +0200, Stanislaw Gruszka wrote:
> Jake, please test this set and check if it not cause association
> problems you reported earlier this month.
>
> Please apply it together with this mac80211 patch:
> http://marc.info/?l=linux-wireless&m=136879090123023&w=2
> which I already posted and is queued to upstream. Not having
> it may cause troubles and influence negatively this set test.
>
> Johannes, is need to check beacon bssid or even if rx frame
> is a beacon to unblock queues? I think if we receive any frame
> (not necessary beacon or our bssid beacon) on passive channel,
> that mean we can use that channel. But that depend how firmware
> is implemented, if firmware require our bssid beacon to unblock
> channel, driver of course need that too.
I _think_ any frame with good CRC will do, but I'm not entirely sure for
3945/4965.
johannes
^ permalink raw reply
* Re: Bisected 3.9 regression for iwl4965 connection problem to 1672c0e3
From: Johannes Berg @ 2013-05-24 20:28 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Jake Edge, linux-wireless, lkml
In-Reply-To: <20130522115908.GA22547@redhat.com>
On Wed, 2013-05-22 at 13:59 +0200, Stanislaw Gruszka wrote:
> > AFICT, we wake queues only if beacon arrives or mac80211 call drv_config
> > with BSS_CHANGED_IDLE. I'm not sure if the latter prevent stuck.
>
> It should prevent stuck. When we fail to auth, drv_config() with BSS_CHANGED_IDLE
> is called via:
>
> ieee80211_destroy_auth_data ->
> ieee80211_vif_release_channel ->
> __ieee80211_vif_release_channel ->
> ieee80211_unassign_vif_chanctx ->
> ieee80211_bss_info_change_notify
>
> But there is need to have ->vif.chanctx_conf valid in
> __ieee80211_vif_release_channel(), where is below condition:
>
> conf = rcu_dereference_protected(sdata->vif.chanctx_conf,
> lockdep_is_held(&local->chanctx_mtx));
> if (!conf)
> return;
>
> I'm not sure if that always happen. Perhaps would be better to change
> BSS_CHANGED_IDLE to BSS_CHANGED_BSSID, which is called directly from
> ieee80211_destroy_auth_data() ?
I don't think the "!conf" can hit in this case, since to even try to
associate you have to have a channel context assigned.
johannes
^ 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