Re: [PATCH] iw: print human readable radar events
On Fri, Jan 30, 2015 at 11:36 AM, Joe Perches wrote: > Might be better with a const char * use Yeah, could do that. However, this is consistent with the rest of the code in iw, so should be fine as is. Thanks, Helmut -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On 30 January 2015 at 15:40, Eric Dumazet wrote: > On Fri, 2015-01-30 at 14:39 +0100, Michal Kazior wrote: > >> I've briefly tried playing with this knob to no avail unfortunately. I >> tried 256K, 1M - it didn't improve TCP performance. When I tried to >> make it smaller (e.g. 16K) the traffic dropped even more so it does >> have an effect. It seems there's some other limiting factor in this >> case. > > Interesting. > > Could you take some tcpdump/pcap with various tcp_limit_output_bytes > values ? > > echo 131072 >/proc/sys/net/ipv4/tcp_limit_output_bytes > tcpdump -p -i wlanX -s 128 -c 2 -w 128k.pcap > > echo 262144 >/proc/sys/net/ipv4/tcp_limit_output_bytes > tcpdump -p -i wlanX -s 128 -c 2 -w 256k.pcap I've run a couple of tests across different kernels. This got pretty big so I decided to use an external file hosting: http://www.filedropper.com/testtar Let me know if you can't access it (and perhaps you could suggest how you prefer the logs to be delivered in that case). The layout of logs is: $kernel/$limit-P$threads.pcap. I've also included the test script and output of each test run. While testing I've had my internal GRO patch for ath10k and no stretch ack patches. When I was trying to come up with a testing methodology I've noticed something interesting: 1. set 16k limit 2. start iperf -P1 3. observe 200mbps 4. set 2048k limit (while iperf is running) 5. observe 600mbps 6. set 16limit back (while iperf is running) 7. observe 500-600mbps (i.e. no drop to 200mbps) Due to that I've decided to re-start iperf for each limit test. If you want me to gather some other logs/dumps/configuration permutations let me know, please. Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] ath9k patches
From: Sujith Manoharan ath9k patches for -next. Sujith Manoharan (6): ath9k: Add support for more WOW patterns ath9k: Register correct WOW details with mac80211 ath9k: Fix issues with WoW enable ath9k: Program AR_WA correctly ath9k: Clear TSF2 properly ath9k: Choose correct rate for 2GHz channel drivers/net/wireless/ath/ath9k/ar9003_wow.c | 281 ++-- drivers/net/wireless/ath/ath9k/hw.h | 3 +- drivers/net/wireless/ath/ath9k/reg.h| 2 + drivers/net/wireless/ath/ath9k/reg_wow.h| 39 +++- drivers/net/wireless/ath/ath9k/wow.c| 16 +- 5 files changed, 200 insertions(+), 141 deletions(-) -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ath9k: Add support for more WOW patterns
From: Sujith Manoharan
Newer chips like WB222, WB335 support more than
8 user-configurable patterns. This patch adds
support for it by setting up the correct HW
registers.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ar9003_wow.c | 48 +
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/reg_wow.h| 34
3 files changed, 56 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_wow.c
b/drivers/net/wireless/ath/ath9k/ar9003_wow.c
index d2a4f6f..4b53d0b 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_wow.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_wow.c
@@ -100,9 +100,11 @@ int ath9k_hw_wow_apply_pattern(struct ath_hw *ah, u8
*user_pattern,
if (pattern_count >= ah->wow.max_patterns)
return -ENOSPC;
- REG_SET_BIT(ah, AR_WOW_PATTERN, BIT(pattern_count));
+ if (pattern_count < MAX_NUM_PATTERN_LEGACY)
+ REG_SET_BIT(ah, AR_WOW_PATTERN, BIT(pattern_count));
+ else
+ REG_SET_BIT(ah, AR_MAC_PCU_WOW4, BIT(pattern_count - 8));
- /* set the registers for pattern */
for (i = 0; i < MAX_PATTERN_SIZE; i += 4) {
memcpy(&pattern_val, user_pattern, 4);
REG_WRITE(ah, (AR_WOW_TB_PATTERN(pattern_count) + i),
@@ -110,47 +112,39 @@ int ath9k_hw_wow_apply_pattern(struct ath_hw *ah, u8
*user_pattern,
user_pattern += 4;
}
- /* set the registers for mask */
for (i = 0; i < MAX_PATTERN_MASK_SIZE; i += 4) {
memcpy(&mask_val, user_mask, 4);
REG_WRITE(ah, (AR_WOW_TB_MASK(pattern_count) + i), mask_val);
user_mask += 4;
}
- /* set the pattern length to be matched
-*
-* AR_WOW_LENGTH1_REG1
-* bit 31:24 pattern 0 length
-* bit 23:16 pattern 1 length
-* bit 15:8 pattern 2 length
-* bit 7:0 pattern 3 length
-*
-* AR_WOW_LENGTH1_REG2
-* bit 31:24 pattern 4 length
-* bit 23:16 pattern 5 length
-* bit 15:8 pattern 6 length
-* bit 7:0 pattern 7 length
-*
-* the below logic writes out the new
-* pattern length for the corresponding
-* pattern_count, while masking out the
-* other fields
-*/
-
- ah->wow.wow_event_mask |= BIT(pattern_count + AR_WOW_PAT_FOUND_SHIFT);
+ if (pattern_count < MAX_NUM_PATTERN_LEGACY)
+ ah->wow.wow_event_mask |=
+ BIT(pattern_count + AR_WOW_PAT_FOUND_SHIFT);
+ else
+ ah->wow.wow_event_mask2 |=
+ BIT((pattern_count - 8) + AR_WOW_PAT_FOUND_SHIFT);
if (pattern_count < 4) {
- /* Pattern 0-3 uses AR_WOW_LENGTH1 register */
set = (pattern_len & AR_WOW_LENGTH_MAX) <<
AR_WOW_LEN1_SHIFT(pattern_count);
clr = AR_WOW_LENGTH1_MASK(pattern_count);
REG_RMW(ah, AR_WOW_LENGTH1, set, clr);
- } else {
- /* Pattern 4-7 uses AR_WOW_LENGTH2 register */
+ } else if (pattern_count < 8) {
set = (pattern_len & AR_WOW_LENGTH_MAX) <<
AR_WOW_LEN2_SHIFT(pattern_count);
clr = AR_WOW_LENGTH2_MASK(pattern_count);
REG_RMW(ah, AR_WOW_LENGTH2, set, clr);
+ } else if (pattern_count < 12) {
+ set = (pattern_len & AR_WOW_LENGTH_MAX) <<
+ AR_WOW_LEN3_SHIFT(pattern_count);
+ clr = AR_WOW_LENGTH3_MASK(pattern_count);
+ REG_RMW(ah, AR_WOW_LENGTH3, set, clr);
+ } else if (pattern_count < MAX_NUM_PATTERN) {
+ set = (pattern_len & AR_WOW_LENGTH_MAX) <<
+ AR_WOW_LEN4_SHIFT(pattern_count);
+ clr = AR_WOW_LENGTH4_MASK(pattern_count);
+ REG_RMW(ah, AR_WOW_LENGTH4, set, clr);
}
return 0;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h
b/drivers/net/wireless/ath/ath9k/hw.h
index f51a28f..c8b3d8f 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -273,6 +273,7 @@ enum ath9k_hw_caps {
struct ath9k_hw_wow {
u32 wow_event_mask;
+ u32 wow_event_mask2;
u8 max_patterns;
};
diff --git a/drivers/net/wireless/ath/ath9k/reg_wow.h
b/drivers/net/wireless/ath/ath9k/reg_wow.h
index e6de4a3..83f27f9 100644
--- a/drivers/net/wireless/ath/ath9k/reg_wow.h
+++ b/drivers/net/wireless/ath/ath9k/reg_wow.h
@@ -25,9 +25,39 @@
#define AR_WOW_KEEP_ALIVE 0x827c
#define AR_WOW_KEEP_ALIVE_DELAY 0x8288
#define AR_WOW_PATTERN_MATCH0x828c
+
+/*
+ * AR_WOW_LENGTH1
+ * bit 31:24 pattern 0 length
+ * bit 23:16 pattern 1 length
+ * bit 15:8 pattern 2 length
+ * bit 7:0 pattern 3 length
+ *
+ * AR_WOW_LENGTH2
+ * bit 31:24 pattern 4 length
+ * bit 23:16 pattern 5 lengt
[PATCH 2/6] ath9k: Register correct WOW details with mac80211
From: Sujith Manoharan
Since the number of user patterns is higher for
newer chips, make sure that this is registered
during initialization.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/wow.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/wow.c
b/drivers/net/wireless/ath/ath9k/wow.c
index 5092939..8d0b173 100644
--- a/drivers/net/wireless/ath/ath9k/wow.c
+++ b/drivers/net/wireless/ath/ath9k/wow.c
@@ -16,13 +16,20 @@
#include "ath9k.h"
-static const struct wiphy_wowlan_support ath9k_wowlan_support = {
+static const struct wiphy_wowlan_support ath9k_wowlan_support_legacy = {
.flags = WIPHY_WOWLAN_MAGIC_PKT | WIPHY_WOWLAN_DISCONNECT,
.n_patterns = MAX_NUM_USER_PATTERN,
.pattern_min_len = 1,
.pattern_max_len = MAX_PATTERN_SIZE,
};
+static const struct wiphy_wowlan_support ath9k_wowlan_support = {
+ .flags = WIPHY_WOWLAN_MAGIC_PKT | WIPHY_WOWLAN_DISCONNECT,
+ .n_patterns = MAX_NUM_PATTERN - 2,
+ .pattern_min_len = 1,
+ .pattern_max_len = MAX_PATTERN_SIZE,
+};
+
static u8 ath9k_wow_map_triggers(struct ath_softc *sc,
struct cfg80211_wowlan *wowlan)
{
@@ -320,9 +327,14 @@ void ath9k_set_wakeup(struct ieee80211_hw *hw, bool
enabled)
void ath9k_init_wow(struct ieee80211_hw *hw)
{
struct ath_softc *sc = hw->priv;
+ struct ath_hw *ah = sc->sc_ah;
if ((sc->driver_data & ATH9K_PCI_WOW) || sc->force_wow) {
- hw->wiphy->wowlan = &ath9k_wowlan_support;
+ if (AR_SREV_9462_20_OR_LATER(ah) ||
AR_SREV_9565_11_OR_LATER(ah))
+ hw->wiphy->wowlan = &ath9k_wowlan_support;
+ else
+ hw->wiphy->wowlan = &ath9k_wowlan_support_legacy;
+
device_init_wakeup(sc->dev, 1);
}
}
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ath9k: Program AR_WA correctly
From: Sujith Manoharan
Setting the required configuration in the PCIE
WorkAround register needs to be done after all the
WoW parameters have been set.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ar9003_wow.c | 39 -
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_wow.c
b/drivers/net/wireless/ath/ath9k/ar9003_wow.c
index 6ffa0e0..cf45b91 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_wow.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_wow.c
@@ -219,31 +219,34 @@ u32 ath9k_hw_wow_wakeup(struct ath_hw *ah)
}
EXPORT_SYMBOL(ath9k_hw_wow_wakeup);
+static void ath9k_hw_wow_set_arwr_reg(struct ath_hw *ah)
+{
+ u32 wa_reg;
+
+ if (!ah->is_pciexpress)
+ return;
+
+ /*
+* We need to untie the internal POR (power-on-reset)
+* to the external PCI-E reset. We also need to tie
+* the PCI-E Phy reset to the PCI-E reset.
+*/
+ wa_reg = REG_READ(ah, AR_WA);
+ wa_reg &= ~AR_WA_UNTIE_RESET_EN;
+ wa_reg |= AR_WA_RESET_EN;
+ wa_reg |= AR_WA_POR_SHORT;
+
+ REG_WRITE(ah, AR_WA, wa_reg);
+}
+
void ath9k_hw_wow_enable(struct ath_hw *ah, u32 pattern_enable)
{
u32 wow_event_mask;
u32 keep_alive, magic_pattern, host_pm_ctrl;
- u32 set, clr;
wow_event_mask = ah->wow.wow_event_mask;
/*
-* Untie Power-on-Reset from the PCI-E-Reset. When we are in
-* WOW sleep, we do want the Reset from the PCI-E to disturb
-* our hw state
-*/
- if (ah->is_pciexpress) {
- /*
-* we need to untie the internal POR (power-on-reset)
-* to the external PCI-E reset. We also need to tie
-* the PCI-E Phy reset to the PCI-E reset.
-*/
- set = AR_WA_RESET_EN | AR_WA_POR_SHORT;
- clr = AR_WA_UNTIE_RESET_EN | AR_WA_D3_L1_DISABLE;
- REG_RMW(ah, AR_WA, set, clr);
- }
-
- /*
* AR_PMCTRL_HOST_PME_EN - Override PME enable in configuration
* space and allow MAC to generate WoW anyway.
*
@@ -390,6 +393,8 @@ void ath9k_hw_wow_enable(struct ath_hw *ah, u32
pattern_enable)
/* To bring down WOW power low margin */
REG_SET_BIT(ah, AR_PCIE_PHY_REG3, BIT(13));
+ ath9k_hw_wow_set_arwr_reg(ah);
+
/* HW WoW */
REG_CLR_BIT(ah, AR_PCU_MISC_MODE3, BIT(5));
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] ath9k: Fix issues with WoW enable
From: Sujith Manoharan
This patch addresses several issues with the
ath9k_hw_wow_enable() routine:
* The usage of set/clr variables is removed. Writing
the required values to registers is cleaner.
* The shift value of 28 for the contention window field
in AR_WOW_PATTERN is incorrect, change it to 27.
* Disabling Keep Alive needs to be done based on the
LINK_CHANGE option. This is done unconditionally now,
fix this.
* The workaround for the D1/D3 issue is required only
for AR9462.
* The bitfield for enabling pattern matching for packets
less than 256 bytes has expanded for new chips, handle
this accordingly.
* General cleanup.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ar9003_wow.c | 181 ++--
drivers/net/wireless/ath/ath9k/hw.h | 2 +-
drivers/net/wireless/ath/ath9k/reg_wow.h| 5 +-
3 files changed, 93 insertions(+), 95 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_wow.c
b/drivers/net/wireless/ath/ath9k/ar9003_wow.c
index 4b53d0b..6ffa0e0 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_wow.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_wow.c
@@ -222,14 +222,9 @@ EXPORT_SYMBOL(ath9k_hw_wow_wakeup);
void ath9k_hw_wow_enable(struct ath_hw *ah, u32 pattern_enable)
{
u32 wow_event_mask;
+ u32 keep_alive, magic_pattern, host_pm_ctrl;
u32 set, clr;
- /*
-* wow_event_mask is a mask to the AR_WOW_PATTERN register to
-* indicate which WoW events we have enabled. The WoW events
-* are from the 'pattern_enable' in this function and
-* 'pattern_count' of ath9k_hw_wow_apply_pattern()
-*/
wow_event_mask = ah->wow.wow_event_mask;
/*
@@ -249,152 +244,154 @@ void ath9k_hw_wow_enable(struct ath_hw *ah, u32
pattern_enable)
}
/*
-* set the power states appropriately and enable PME
+* AR_PMCTRL_HOST_PME_EN - Override PME enable in configuration
+* space and allow MAC to generate WoW anyway.
+*
+* AR_PMCTRL_PWR_PM_CTRL_ENA - ???
+*
+* AR_PMCTRL_AUX_PWR_DET - PCI core SYS_AUX_PWR_DET signal,
+* needs to be set for WoW in PCI mode.
+*
+* AR_PMCTRL_WOW_PME_CLR - WoW Clear Signal going to the MAC.
+*
+* Set the power states appropriately and enable PME.
+*
+* Set and clear WOW_PME_CLEAR for the chip
+* to generate next wow signal.
*/
- set = AR_PMCTRL_HOST_PME_EN | AR_PMCTRL_PWR_PM_CTRL_ENA |
- AR_PMCTRL_AUX_PWR_DET | AR_PMCTRL_WOW_PME_CLR;
+ REG_SET_BIT(ah, AR_PCIE_PM_CTRL, AR_PMCTRL_HOST_PME_EN |
+AR_PMCTRL_PWR_PM_CTRL_ENA |
+AR_PMCTRL_AUX_PWR_DET |
+AR_PMCTRL_WOW_PME_CLR);
+ REG_CLR_BIT(ah, AR_PCIE_PM_CTRL, AR_PMCTRL_WOW_PME_CLR);
/*
-* set and clear WOW_PME_CLEAR registers for the chip
-* to generate next wow signal.
+* Random Backoff.
+*
+* 31:28 in AR_WOW_PATTERN : Indicates the number of bits used in the
+* contention window. For value N,
+* the random backoff will be selected between
+* 0 and (2 ^ N) - 1.
*/
- REG_SET_BIT(ah, AR_PCIE_PM_CTRL, set);
- clr = AR_PMCTRL_WOW_PME_CLR;
- REG_CLR_BIT(ah, AR_PCIE_PM_CTRL, clr);
+ REG_SET_BIT(ah, AR_WOW_PATTERN,
+ AR_WOW_BACK_OFF_SHIFT(AR_WOW_PAT_BACKOFF));
/*
-* Setup for:
-* - beacon misses
-* - magic pattern
-* - keep alive timeout
-* - pattern matching
+* AIFS time, Slot time, Keep Alive count.
*/
-
+ REG_SET_BIT(ah, AR_WOW_COUNT, AR_WOW_AIFS_CNT(AR_WOW_CNT_AIFS_CNT) |
+ AR_WOW_SLOT_CNT(AR_WOW_CNT_SLOT_CNT) |
+ AR_WOW_KEEP_ALIVE_CNT(AR_WOW_CNT_KA_CNT));
/*
-* Program default values for pattern backoff, aifs/slot/KAL count,
-* beacon miss timeout, KAL timeout, etc.
+* Beacon timeout.
*/
- set = AR_WOW_BACK_OFF_SHIFT(AR_WOW_PAT_BACKOFF);
- REG_SET_BIT(ah, AR_WOW_PATTERN, set);
-
- set = AR_WOW_AIFS_CNT(AR_WOW_CNT_AIFS_CNT) |
- AR_WOW_SLOT_CNT(AR_WOW_CNT_SLOT_CNT) |
- AR_WOW_KEEP_ALIVE_CNT(AR_WOW_CNT_KA_CNT);
- REG_SET_BIT(ah, AR_WOW_COUNT, set);
-
if (pattern_enable & AH_WOW_BEACON_MISS)
- set = AR_WOW_BEACON_TIMO;
- /* We are not using beacon miss, program a large value */
+ REG_WRITE(ah, AR_WOW_BCN_TIMO, AR_WOW_BEACON_TIMO);
else
- set = AR_WOW_BEACON_TIMO_MAX;
-
- REG_WRITE(ah, AR_WOW_BCN_TIMO, set);
+ REG_WRITE(
[PATCH 5/6] ath9k: Clear TSF2 properly
From: Sujith Manoharan
Chips in the AR9003 family have a second TSF, which
needs to be cleared when putting the card to
sleep.
Signed-off-by: Sujith Manoharan
---
drivers/net/wireless/ath/ath9k/ar9003_wow.c | 9 +
drivers/net/wireless/ath/ath9k/reg.h| 2 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_wow.c
b/drivers/net/wireless/ath/ath9k/ar9003_wow.c
index cf45b91..2dc50a0 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_wow.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_wow.c
@@ -35,6 +35,15 @@ static void ath9k_hw_set_powermode_wow_sleep(struct ath_hw
*ah)
return;
}
+ if (AR_SREV_9462(ah) || AR_SREV_9565(ah)) {
+ if (!REG_READ(ah, AR_MAC_PCU_GEN_TIMER_TSF_SEL))
+ REG_CLR_BIT(ah, AR_DIRECT_CONNECT, AR_DC_TSF2_ENABLE);
+ } else if (AR_SREV_9485(ah)){
+ if (!(REG_READ(ah, AR_NDP2_TIMER_MODE) &
+ AR_GEN_TIMERS2_MODE_ENABLE_MASK))
+ REG_CLR_BIT(ah, AR_DIRECT_CONNECT, AR_DC_TSF2_ENABLE);
+ }
+
REG_WRITE(ah, AR_RTC_FORCE_WAKE, AR_RTC_FORCE_WAKE_ON_INT);
}
diff --git a/drivers/net/wireless/ath/ath9k/reg.h
b/drivers/net/wireless/ath/ath9k/reg.h
index b1b803d..9587ec6 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -1883,6 +1883,7 @@ enum {
#define AR_FIRST_NDP_TIMER 7
#define AR_NDP2_PERIOD 0x81a0
#define AR_NDP2_TIMER_MODE 0x81c0
+#define AR_GEN_TIMERS2_MODE_ENABLE_MASK 0x00FF
#define AR_GEN_TIMERS(_i) (0x8200 + ((_i) << 2))
#define AR_NEXT_TBTT_TIMER AR_GEN_TIMERS(0)
@@ -1978,6 +1979,7 @@ enum {
#define AR_DIRECT_CONNECT 0x83a0
#define AR_DC_AP_STA_EN0x0001
+#define AR_DC_TSF2_ENABLE 0x0001
#define AR_AES_MUTE_MASK0 0x805c
#define AR_AES_MUTE_MASK0_FC0x
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] ath9k: Choose correct rate for 2GHz channel
From: Sujith Manoharan Set the transmit rate for the keep-alive frames as 1M/CCK when the current channel is in the 2GHz band. Signed-off-by: Sujith Manoharan --- drivers/net/wireless/ath/ath9k/ar9003_wow.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath9k/ar9003_wow.c b/drivers/net/wireless/ath/ath9k/ar9003_wow.c index 2dc50a0..86bfc96 100644 --- a/drivers/net/wireless/ath/ath9k/ar9003_wow.c +++ b/drivers/net/wireless/ath/ath9k/ar9003_wow.c @@ -62,11 +62,15 @@ static void ath9k_wow_create_keep_alive_pattern(struct ath_hw *ah) /* set the transmit buffer */ ctl[0] = (KAL_FRAME_LEN | (MAX_RATE_POWER << 16)); ctl[1] = 0; - ctl[3] = 0xb; /* OFDM_6M hardware value for this rate */ ctl[4] = 0; ctl[7] = (ah->txchainmask) << 2; ctl[2] = 0xf << 16; /* tx_tries 0 */ + if (IS_CHAN_2GHZ(ah->curchan)) + ctl[3] = 0x1b; /* CCK_1M */ + else + ctl[3] = 0xb; /* OFDM_6M */ + for (i = 0; i < KAL_NUM_DESC_WORDS; i++) REG_WRITE(ah, (AR_WOW_KA_DESC_WORD2 + i * 4), ctl[i]); -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On Fri, 2015-01-30 at 14:53 -0800, Peter Oh wrote: > I admit that I/O ordering and posted write are looked different in > theory and at glance since posted write could be related cache invalidate. > But wmb are still related to both. > As I addressed wmb uses dsb (in arm arch) and here is the description of > arm architecture. > > * DSB drains write buffer. > * DSB is architecturally defined to include all cache, TLB and branch > prediction maintenance operations as well as explicit memory operations > > These are the reasons why I mentioned wmb does both. > > * captured from ARMv7 Architecture Manual > --- Notes --- > Historically, this operation was referred to as Drain Write Buffer or > Data Write Barrier (DWB). From ARMv6, these > names and the use of DWB were deprecated in favor of the new Data > Synchronization Barrier name and DSB > abbreviation. DSB better reflects the functionality provided from ARMv6, > because DSB is architecturally defined > to include all cache, TLB and branch prediction maintenance operations > as well as explicit memory operations > > --- A DSB completes when: --- > ? all explicit memory accesses that are observed by Pe before the DSB is > executed, are of the required access > types, and are from observers in the same required shareability domain > as Pe, are complete for the set of > observers in the required shareability domain. > ? if the required accesses types of the DSB is reads and writes, all > cache and branch predictor maintenance > operations issued by Pe before the DSB are complete for the required > shareability domain. > ? if the required accesses types of the DSB is reads and writes, all TLB > maintenance operations issued by Pe > before the DSB are complete for the required shareability domain. > -- I cannot read from this in any way that it can post writes to the PCIe bus. In fact, architecturally, I cannot think of any reason how it even could do that from the CPU. > Furthermore this is the comparison of the compiled assembly code between > ath10k_pci_read32 and wmb. > > ath10k_pci_read32() > bac:e5932008 ldrr2, [r3, #8] > bb0:f57ff04f dsbsy > bb4:e2883d52 addr3, r8, #5248; 0x1480 > bb8:e283303c addr3, r3, #60; 0x3c > bbc:e593300c ldrr3, [r3, #12] > bc0:e2833a09 addr3, r3, #36864; 0x9000 > > wmb(); > b9c:f57ff04e dsbst > > ath10k_pci_read32 does register operation except dsb and there is no > cache invalidate related commands. I don't think this is relevant. The question is "what are you trying to achieve". > So that if wmb is not enough for the purpose then ath10k_pci_read32 is > also not enough for that. > > Also refer the section "ACQUIRES VS I/O ACCESSES" in memory-barriers.txt. > > It gives an example with PCI bridge and introduces readl as an > alternative method to mmiowb which weaker form of wmb. > > Please give your opinion. Again - the question is - what are you trying to achieve? The code (as it is before your patch) implies that it's trying to make sure that before it continues, any previous writes to the PCIe device's registers are posted. The only way to ensure that is to do a read to the registers, as the code does now. What you're describing is something else entirely - you're describing a way to make sure that some data was flushed out to DRAM from the CPU caches. These two things are not related in any way. In an interrupt routine, it would make sense to ensure that the write was posted (e.g. to mask interrupts, or to acknowledge them, or similar, before the routine can be re-invoked.) To me, flushing memory writes to DRAM makes less sense in an interrupt handlers unless the device was somehow using DMA to coordinate interrupts [1], which seems unlikely but I haven't checked. Anyway - I have no particular interest in this discussion, I was merely trying to help you out with this :) You can make whatever change you want, of course :P johannes [1] incidentally, our device [iwlwifi] does in fact do something like that, but it's read-only for the driver so no need for such a thing either -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Subject: NetDev 0.1 weekly update, registration working again
Fellow netheads: Schedule: == The schedule is out. It is currently a graphic image, but we are working on a proper non-graphic rendered clickable version. https://www.netdev01.org/schedule Registration: == There was a glitch in the registration web site yesterday. We apologize for the inconvenience and it is now working again. Please try again if you had difficulty. https://onlineregistrations.ca/netdev01/ $100/day, or $350 for 4 days (Cdn dollars). (online reg closes Feb 12th) Please register as early as practical. Registering helps us plan properly for numbers of attendees, ensuring venue sizes and supplies are appropriate without wasting resources. Hotel discount rates deadline extended == The Westin Hotel is still holding a block of rooms for Netdev01 at a guaranteed rate of $159.00 or $179.00 (depending on the type of room required) and there are still a few rooms available. We've been able to negotiate an extention to the block of rooms at the hotel earlybird special rates beyond the discount rate deadline, but when they are gone, they are gone. There were still several people able to register over the weekend. There are lots of big and small hotels in Ottawa, but they will fill up fast as Winterlude approaches, so book something soon. There may be some possibilities to billet locally, but don't leave it last minute. Make your reservations at: https://www.starwoodmeeting.com/StarGroupsWeb/res?id=1412035802&key=1AC9C1F8 Sponsors: = NetDev 0.1 would like to gratefully acknowledge all our sponsors: https://netdev01.org/sponsors CENGN http://www.cengn.ca/ Google https://www.google.ca Qualcommhttps://www.qualcomm.com/ Verizon http://www.verizon.com/ Cumulus Networkshttp://cumulusnetworks.com/ Mojatatu Networks http://mojatatu.com/ --- THE Technical Conference on Linux Networking, February 14-17, 2015, Ottawa, Canada https://netdev01.org/ Contact:i...@netdev01.info Main site: https://www.netdev01.org/ Travel/hotel/weather/clothing: https://www.netdev01.org/travel RSS feed: https://netdev01.org/atom Follow us on Twitter: @netdev01 https://twitter.com/netdev01 slainte mhath, RGB -- Richard Guy Briggs -- ~\-- ~\ -- \___ o \@ @Ride yer bike! Ottawa, ON, CANADA -- Lo_>__M__\\/\%__\\/\% Vote! -- _GTVS6#790__(*)__(*)(*)(*)_ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine TSO autosizing`
On Sun, Feb 1, 2015 at 11:04 PM, Avery Pennarun wrote: > On Sun, Feb 1, 2015 at 6:34 PM, Andrew McGregor wrote: >> I missed one item in my list of potential improvements: the most braindead >> thing 802.11 has to say about rates is that broadcast and multicast packets >> should be sent at 'the lowest basic rate in the current supported rate set', >> which is really wasteful. There are a couple of ways of dealing with this: >> one, ignore the standard and pick the rate that is most likely to get the >> frame to as many neighbours as possible (by a scan of the Minstrel tables). >> Or two, fan it out as unicast, which might well take less airtime (due to >> aggregation) as well as being much more likely to be delivered, since you >> get ACKs and retries by doing that. > > As far as I can see, the only sensible thing to do with > multicast/broadcast is some variation of the unicast fanout, unless > you've got a truly huge number of nodes. I don't know of any > protocols (certainly not video streams) that actually work well with > the kind of packet loss you see at medium/long range with wifi if > retransmits aren't used. I've heard that openwrt already has a patch > included that does this kind of fanout at the bridge layer. I gather some Windows drivers from some vendors do this unicast fanout (claim made by one of their engineers in an early homenet meeting). > > I've also heard of a new "reliable multicast" in some newer 802.11 > variant, which essentially sends out a single multicast packet and > expects an ACK from each intended recipient. Other than adding > complexity, it seems like the best of both worlds. So long as it times out in some very small, finite time. We don't want a repeat of the infinite retry bugs Dave found in drivers a few years back... "Reliable multicast" ultimately is an oxymoron, particularly on a medium with hundreds/one bandwidth variation. One remote low bandwidth station cannot be allowed to drag the entire network to the basement. - Jim -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Open Source RRM & Hand-Over Optimization (WAS: Throughput regression with `tcp: refine TSO autosizing`)
On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun wrote: > On Sun, Feb 1, 2015 at 9:43 AM, wrote: >> Just to clarify, managing queueing in a single access point WiFi network is >> only a small part of the problem of fixing the rapidly degrading performance >> of WiFi based systems. > > Can you explain what you mean by "rapidly degrading?" The performance > in odd situations is certainly not inspirational, but I haven't > noticed it getting worse over time. > >> Similarly, mesh routing is only a small part of the >> problem with the scalability of cooperative meshes based on the WiFi MAC. > > That's certainly true. Not to say the mesh routing algorithms are > much good either. > >> Also, as we noted >> earlier, "handoff" from one next hop to another is a huge problem with >> performance in practical deployments (a factor of 10x at least, just in >> that). > > While there is definitely some work to be done in handoff, it seems > like there are some find implementations of this already in existence. > Several brands of "enterprise access point" setups seem to do well at > this. It would be nice if they interoperated, I guess. > > The fact that there's no open source version of this kind of handoff > feature bugs me, but we are working on it here and the work is all > planned to be open source, for example: (very early version) > https://gfiber.googlesource.com/vendor/google/platform/+/master/waveguide/ We've got an SDN-inspired architecture with 802.11 frame tunneling (a la CAPWAP), airtime fairness, infrastructure initiated hand-over, Opportunistic Key Caching (OKC), IEEE 802.11r Fast BSS Transition and a few more goodies. It's currently free as in beer (http://anyfi.net/software, https://github.com/carrierwrt/carrierwrt/pull/7 and http://www.anyfinetworks.com/download) up to 100 APs, but we're definitely going to open source in one form or another. We've also tried to raise some interest in fixing up CAPWAP (https://www.ietf.org/mail-archive/web/opsawg/current/msg03196.html), which is (unfortunately) the best open standard at the moment. Interest seems marginal though... If anybody's interested in joining forces on either front we'd be be happy to talk. Cheers, Björn -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On 01/30/2015 06:06 PM, Sujith Manoharan wrote: Peter Oh wrote: Please refer the email thread that I mentioned about other architectures. (dsb is for ARM and other platforms have the equivalent instruction such as sfence, sync, mf, and dcs). Ok. Also the patch is updated with 2nd patch set replacing wmb to mb. Would be good to test this on a MIPS platform... Agree. I'll do the investigation and test. Sujith ___ ath10k mailing list ath...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On 02/02/2015 05:02 AM, Johannes Berg wrote: On Fri, 2015-01-30 at 14:53 -0800, Peter Oh wrote: I admit that I/O ordering and posted write are looked different in theory and at glance since posted write could be related cache invalidate. But wmb are still related to both. As I addressed wmb uses dsb (in arm arch) and here is the description of arm architecture. * DSB drains write buffer. * DSB is architecturally defined to include all cache, TLB and branch prediction maintenance operations as well as explicit memory operations These are the reasons why I mentioned wmb does both. * captured from ARMv7 Architecture Manual --- Notes --- Historically, this operation was referred to as Drain Write Buffer or Data Write Barrier (DWB). From ARMv6, these names and the use of DWB were deprecated in favor of the new Data Synchronization Barrier name and DSB abbreviation. DSB better reflects the functionality provided from ARMv6, because DSB is architecturally defined to include all cache, TLB and branch prediction maintenance operations as well as explicit memory operations --- A DSB completes when: --- ? all explicit memory accesses that are observed by Pe before the DSB is executed, are of the required access types, and are from observers in the same required shareability domain as Pe, are complete for the set of observers in the required shareability domain. ? if the required accesses types of the DSB is reads and writes, all cache and branch predictor maintenance operations issued by Pe before the DSB are complete for the required shareability domain. ? if the required accesses types of the DSB is reads and writes, all TLB maintenance operations issued by Pe before the DSB are complete for the required shareability domain. -- I cannot read from this in any way that it can post writes to the PCIe bus. In fact, architecturally, I cannot think of any reason how it even could do that from the CPU. Furthermore this is the comparison of the compiled assembly code between ath10k_pci_read32 and wmb. ath10k_pci_read32() bac:e5932008 ldrr2, [r3, #8] bb0:f57ff04f dsbsy bb4:e2883d52 addr3, r8, #5248; 0x1480 bb8:e283303c addr3, r3, #60; 0x3c bbc:e593300c ldrr3, [r3, #12] bc0:e2833a09 addr3, r3, #36864; 0x9000 wmb(); b9c:f57ff04e dsbst ath10k_pci_read32 does register operation except dsb and there is no cache invalidate related commands. I don't think this is relevant. The question is "what are you trying to achieve". So that if wmb is not enough for the purpose then ath10k_pci_read32 is also not enough for that. Also refer the section "ACQUIRES VS I/O ACCESSES" in memory-barriers.txt. It gives an example with PCI bridge and introduces readl as an alternative method to mmiowb which weaker form of wmb. Please give your opinion. Again - the question is - what are you trying to achieve? The code (as it is before your patch) implies that it's trying to make sure that before it continues, any previous writes to the PCIe device's registers are posted. The only way to ensure that is to do a read to the registers, as the code does now. Do you know how the read ensure that although the read code does not check the return value? Can you explain how a read ensures that posted write reaches PCIe device? What you're describing is something else entirely - you're describing a way to make sure that some data was flushed out to DRAM from the CPU caches. These two things are not related in any way. In an interrupt routine, it would make sense to ensure that the write was posted (e.g. to mask interrupts, or to acknowledge them, or similar, before the routine can be re-invoked.) To me, flushing memory writes to DRAM makes less sense in an interrupt handlers unless the device was somehow using DMA to coordinate interrupts [1], which seems unlikely but I haven't checked. Anyway - I have no particular interest in this discussion, I was merely trying to help you out with this :) You can make whatever change you want, of course :P johannes [1] incidentally, our device [iwlwifi] does in fact do something like that, but it's read-only for the driver so no need for such a thing either ___ ath10k mailing list ath...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k Thanks, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On Mon, 2015-02-02 at 11:27 +0100, Michal Kazior wrote: > While testing I've had my internal GRO patch for ath10k and no stretch > ack patches. Thanks for the data, I took a look at it. I am afraid this GRO patch might be the problem. It seems to break ACK clocking badly (linux stack has a somewhat buggy tcp_tso_should_defer(), which relies on ACK being received smoothly, as no timer is setup to split the TSO packet.) I am seeing huge delays on ACK packets and bursts like that : 05:01:53.413038 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 76745, win 4435, options [nop,nop,TS val 4294758508 ecr 4294757300], length 0 05:01:53.413407 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 79641, win 4435, options [nop,nop,TS val 4294758508 ecr 4294757301], length 0 05:01:53.413969 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 92673, win 4435, options [nop,nop,TS val 4294758510 ecr 4294757302], length 0 05:01:53.413990 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 97017, win 4435, options [nop,nop,TS val 4294758510 ecr 4294757302], length 0 05:01:53.414011 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 110049, win 4435, options [nop,nop,TS val 4294758510 ecr 4294757302], length 0 ... 05:01:53.422663 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 189689, win 4435, options [nop,nop,TS val 4294758519 ecr 4294757310], length 0 05:01:53.424354 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 198377, win 4435, options [nop,nop,TS val 4294758520 ecr 4294757311], length 0 05:01:53.424400 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 202721, win 4435, options [nop,nop,TS val 4294758520 ecr 4294757313], length 0 05:01:53.424409 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 205617, win 4435, options [nop,nop,TS val 4294758520 ecr 4294757313], length 0 ... 05:01:53.450248 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 419921, win 4435, options [nop,nop,TS val 4294758547 ecr 4294757337], length 0 05:01:53.450266 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 427161, win 4435, options [nop,nop,TS val 4294758547 ecr 4294757340], length 0 05:01:53.450289 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 431505, win 4435, options [nop,nop,TS val 4294758547 ecr 4294757340], length 0 Could you make again your experiments using upstream kernel (David Miller net tree) ? You also could post the GRO patch so that we can comment on it. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On Mon, 2015-02-02 at 09:33 -0800, Peter Oh wrote: > > The code (as it is before your patch) implies that it's trying to make > > sure that before it continues, any previous writes to the PCIe device's > > registers are posted. The only way to ensure that is to do a read to the > > registers, as the code does now. > Do you know how the read ensure that although the read code does not > check the return value? > Can you explain how a read ensures that posted write reaches PCIe device? You basically have the following sequence: iowrite() ioread() If you look, you'll see that iowrite() is actually done (or should be, or perhaps with appropriate syncs) on an uncached mapping. As a result, the only thing you care about here is the PCIe bus, not the CPU cache flush. And from there on that's just a question of PCIe bus semantics. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On 02/02/2015 10:54 AM, Johannes Berg wrote: On Mon, 2015-02-02 at 09:33 -0800, Peter Oh wrote: The code (as it is before your patch) implies that it's trying to make sure that before it continues, any previous writes to the PCIe device's registers are posted. The only way to ensure that is to do a read to the registers, as the code does now. Do you know how the read ensure that although the read code does not check the return value? Can you explain how a read ensures that posted write reaches PCIe device? You basically have the following sequence: iowrite() ioread() If you look, you'll see that iowrite() is actually done (or should be, or perhaps with appropriate syncs) on an uncached mapping. since it's mmio, iowrite will be map to write, not out which is cached mapping. That's why we address "posted write" here. If it's un-cached mapping which is volatile, we don't even need ioread. As a result, the only thing you care about here is the PCIe bus, not the CPU cache flush. And from there on that's just a question of PCIe bus semantics. So how does ioread guarantee PCIe bus transaction done? johannes ___ ath10k mailing list ath...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k Regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
> > You basically have the following sequence: > > > > iowrite() > > ioread() > > > > If you look, you'll see that iowrite() is actually done (or should be, > > or perhaps with appropriate syncs) on an uncached mapping. > since it's mmio, iowrite will be map to write, not out which is cached > mapping. > That's why we address "posted write" here. > If it's un-cached mapping which is volatile, we don't even need ioread. No, this isn't true - "posted write" in the context of this discussion is about the PCIe bus. Memory writes that go through cache aren't referred to as "posted writes", those are just (cached) memory writes. > > As a result, > > the only thing you care about here is the PCIe bus, not the CPU cache > > flush. And from there on that's just a question of PCIe bus semantics. > So how does ioread guarantee PCIe bus transaction done? That's how PCIe works, operations are serialized, and read() has to wait for a response from the device (but write doesn't - which is "posted write") johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On 02/02/2015 11:22 AM, Johannes Berg wrote: You basically have the following sequence: iowrite() ioread() If you look, you'll see that iowrite() is actually done (or should be, or perhaps with appropriate syncs) on an uncached mapping. since it's mmio, iowrite will be map to write, not out which is cached mapping. That's why we address "posted write" here. If it's un-cached mapping which is volatile, we don't even need ioread. No, this isn't true - "posted write" in the context of this discussion is about the PCIe bus. Memory writes that go through cache aren't referred to as "posted writes", those are just (cached) memory writes. As a result, the only thing you care about here is the PCIe bus, not the CPU cache flush. And from there on that's just a question of PCIe bus semantics. So how does ioread guarantee PCIe bus transaction done? That's how PCIe works, operations are serialized, and read() has to wait for a response from the device do you know which mechanism or which instruction set makes read() wait for a response from the device? (but write doesn't - which is "posted write") johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On Mon, 2015-02-02 at 11:36 -0800, Peter Oh wrote: > On 02/02/2015 11:22 AM, Johannes Berg wrote: > >>> You basically have the following sequence: > >>> > >>> iowrite() > >>> ioread() > >>> > >>> If you look, you'll see that iowrite() is actually done (or should be, > >>> or perhaps with appropriate syncs) on an uncached mapping. > >> since it's mmio, iowrite will be map to write, not out which is cached > >> mapping. > >> That's why we address "posted write" here. > >> If it's un-cached mapping which is volatile, we don't even need ioread. > > No, this isn't true - "posted write" in the context of this discussion > > is about the PCIe bus. Memory writes that go through cache aren't > > referred to as "posted writes", those are just (cached) memory writes. > > > >>>As a result, > >>> the only thing you care about here is the PCIe bus, not the CPU cache > >>> flush. And from there on that's just a question of PCIe bus semantics. > >> So how does ioread guarantee PCIe bus transaction done? > > That's how PCIe works, operations are serialized, and read() has to wait > > for a response from the device > do you know which mechanism or which instruction set makes read() wait > for a response from the device? I have no idea. I assume it's just like a DRAM read, the CPU stalls while there's no response. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] cfg80211: Add API to change the indoor regulatory setting
As the operating environment of a device can change, add
API for user space to indicate a change of indoor settings.
In addition modify the handling of the indoor processing as
follows:
1. Directly update the indoor setting without wrapping it as a
regulatory request.
2. Track the socket on which the indoor hint is issued, and reset
indoor setting if the socket was released. The motivation here is to
force a user space process that sets the indoor setting to constantly
monitor this setting, and be responsible to correctly toggling it,
so indoor operation will not be enabled uncontrolled.
3. Do not reset the indoor setting when restoring the regulatory
settings as it has nothing to do with CRDA or interface
disconnection.
Signed-off-by: Ilan Peer
Signed-off-by: ArikX Nemtsov
---
include/uapi/linux/nl80211.h | 5 +++
net/wireless/nl80211.c | 10 +-
net/wireless/reg.c | 80 +---
net/wireless/reg.h | 15 -
4 files changed, 73 insertions(+), 37 deletions(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 68b294e..d80edcc 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1739,6 +1739,9 @@ enum nl80211_commands {
*
* @NL80211_ATTR_SCHED_SCAN_DELAY: delay before a scheduled scan (or a
* WoWLAN net-detect scan) is started, u32 in seconds.
+
+ * @NL80211_ATTR_REG_INDOOR: flag attribute, if set indicates that the device
+ * is operating in an indoor environment.
*
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
@@ -2107,6 +2110,8 @@ enum nl80211_attrs {
NL80211_ATTR_SCHED_SCAN_DELAY,
+ NL80211_ATTR_REG_INDOOR,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 454d7a0..e78b096 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -399,6 +399,7 @@ static const struct nla_policy
nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_WIPHY_SELF_MANAGED_REG] = { .type = NLA_FLAG },
[NL80211_ATTR_NETNS_FD] = { .type = NLA_U32 },
[NL80211_ATTR_SCHED_SCAN_DELAY] = { .type = NLA_U32 },
+ [NL80211_ATTR_REG_INDOOR] = { .type = NLA_FLAG },
};
/* policy for the key attributes */
@@ -4955,6 +4956,7 @@ static int parse_reg_rule(struct nlattr *tb[],
static int nl80211_req_set_reg(struct sk_buff *skb, struct genl_info *info)
{
char *data = NULL;
+ bool is_indoor;
enum nl80211_user_reg_hint_type user_reg_hint_type;
/*
@@ -4981,7 +4983,8 @@ static int nl80211_req_set_reg(struct sk_buff *skb,
struct genl_info *info)
data = nla_data(info->attrs[NL80211_ATTR_REG_ALPHA2]);
return regulatory_hint_user(data, user_reg_hint_type);
case NL80211_USER_REG_HINT_INDOOR:
- return regulatory_hint_indoor_user();
+ is_indoor = !!info->attrs[NL80211_ATTR_REG_INDOOR];
+ return regulatory_hint_indoor(is_indoor, info->snd_portid);
default:
return -EINVAL;
}
@@ -12759,6 +12762,11 @@ static int nl80211_netlink_notify(struct
notifier_block * nb,
rcu_read_unlock();
+ /*
+* It is possible that the user space process that is controlling the
+* indoor setting disappeared, so notify the regulatory core.
+*/
+ regulatory_netlink_notify(notify->portid);
return NOTIFY_OK;
}
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 886cc7c..e96251f 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -82,17 +82,12 @@
* be intersected with the current one.
* @REG_REQ_ALREADY_SET: the regulatory request will not change the current
* regulatory settings, and no further processing is required.
- * @REG_REQ_USER_HINT_HANDLED: a non alpha2 user hint was handled and no
- * further processing is required, i.e., not need to update last_request
- * etc. This should be used for user hints that do not provide an alpha2
- * but some other type of regulatory hint, i.e., indoor operation.
*/
enum reg_request_treatment {
REG_REQ_OK,
REG_REQ_IGNORE,
REG_REQ_INTERSECT,
REG_REQ_ALREADY_SET,
- REG_REQ_USER_HINT_HANDLED,
};
static struct regulatory_request core_request_world = {
@@ -133,9 +128,12 @@ static int reg_num_devs_support_basehint;
* State variable indicating if the platform on which the devices
* are attached is operating in an indoor environment. The state variable
* is relevant for all registered devices.
- * (protected by RTNL)
*/
static bool reg_is_indoor;
+static spinlock_t reg_indoor_lock;
+
+/* Used to track the userspace process controlling the indoor setting */
+static u32 reg_is_indoor_portid;
static const struct ieee80211_regdomai
[PATCH v4 2/2] cfg80211: Schedule timeout for all CRDA calls
Timeout was scheduled only in case CRDA was called due to user hints,
but was not scheduled for other cases. This can result in regulatory
hint processing getting stuck in case that there is no CRDA configured.
Change this by scheduling a timeout every time CRDA is called. In
addition, in restore_regulatory_settings() all pending requests are
restored (and not only the user ones).
Signed-off-by: Ilan Peer
---
net/wireless/reg.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index e96251f..a34a534 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -552,6 +552,9 @@ reg_call_crda(struct regulatory_request *request)
{
if (call_crda(request->alpha2))
return REG_REQ_IGNORE;
+
+ queue_delayed_work(system_power_efficient_wq,
+ ®_timeout, msecs_to_jiffies(3142));
return REG_REQ_OK;
}
@@ -1779,8 +1782,7 @@ static void reg_set_request_processed(void)
need_more_processing = true;
spin_unlock(®_requests_lock);
- if (lr->initiator == NL80211_REGDOM_SET_BY_USER)
- cancel_delayed_work(®_timeout);
+ cancel_delayed_work(®_timeout);
if (need_more_processing)
schedule_work(®_work);
@@ -2059,8 +2061,6 @@ static void reg_process_hint(struct regulatory_request
*reg_request)
if (treatment == REG_REQ_IGNORE ||
treatment == REG_REQ_ALREADY_SET)
return;
- queue_delayed_work(system_power_efficient_wq,
- ®_timeout, msecs_to_jiffies(3142));
return;
case NL80211_REGDOM_SET_BY_DRIVER:
if (!wiphy)
@@ -2485,7 +2485,6 @@ static void restore_regulatory_settings(bool reset_user)
char alpha2[2];
char world_alpha2[2];
struct reg_beacon *reg_beacon, *btmp;
- struct regulatory_request *reg_request, *tmp;
LIST_HEAD(tmp_reg_req_list);
struct cfg80211_registered_device *rdev;
@@ -2501,11 +2500,7 @@ static void restore_regulatory_settings(bool reset_user)
* settings.
*/
spin_lock(®_requests_lock);
- list_for_each_entry_safe(reg_request, tmp, ®_requests_list, list) {
- if (reg_request->initiator != NL80211_REGDOM_SET_BY_USER)
- continue;
- list_move_tail(®_request->list, &tmp_reg_req_list);
- }
+ list_splice_tail_init(®_requests_list, &tmp_reg_req_list);
spin_unlock(®_requests_lock);
/* Clear beacon hints */
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [iwlwifi] fail to flush all tx queues on kernel 3.17.6
On Mon, Feb 2, 2015 at 9:56 PM, Gerlof Fokkema wrote: > > Dear Emmanuel, > > I have compiled and experimented with the kernel from this specific commit. > While I don't get any crash logs from iwlmvm anymore, network performance is > still truly horrible. > > After connecting the WiFi connection seems to work fine for a few minutes, > and after that the network card does not seem to flush any data anymore. > When running a ping job together with a download, fully utilizing WiFi, after > a few minutes (or less) I get: > > 64 bytes from 172.16.2.1: icmp_seq=63 ttl=64 time=1476 ms > 64 bytes from 172.16.2.1: icmp_seq=64 ttl=64 time=476 ms > 64 bytes from 172.16.2.1: icmp_seq=65 ttl=64 time=10.6 ms > 64 bytes from 172.16.2.1: icmp_seq=66 ttl=64 time=1558 ms > 64 bytes from 172.16.2.1: icmp_seq=67 ttl=64 time=569 ms > 64 bytes from 172.16.2.1: icmp_seq=68 ttl=64 time=9.97 ms > ping: sendmsg: No buffer space available > ping: sendmsg: No buffer space available > > It seems to me there is something fundamentally wrong with flushing network > traffic, > and with the newest commits it doesn't log these problems anymore either. > > This problem persists on linux 3.18.0 - 3.18.5 and on the aforementioned 3.19 > branch. Can you try with this firmware: https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-7260-10.ucode?id=d5cd7a6cb5f85f6234cca596354e440061a28aa4 Please copy the file to /lib/firmware/ you may want to back up the previous version first. > > Kind regards, > > Gerlof Fokkema > > On Thu, Jan 22, 2015 at 7:33 PM, Emmanuel Grumbach > wrote: >> >> Hi, >> >> On Thu, Jan 22, 2015 at 4:14 PM, Gerlof Fokkema >> wrote: >> > Hello Emmanuel, >> > >> > First of all, thanks for your previous reply. >> > I'm glad the issue is known and being looked at. >> > >> > Recently I tried linux kernel 3.18.2 on Arch linux and had the same >> > issues I previously mentioned. >> > Is there any bug report on this I can follow or any other way to be >> > updated? >> > >> >> This should help: >> https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers.git/commit/?id=4e6c48e0984e28d064ee8fbc292aee7b7920c507 >> >> > >> > On Tue, Dec 30, 2014 at 3:30 PM, Emmanuel Grumbach >> > wrote: >> >> Hi, >> >> >> >> Sorry for the delay. This one got lost in my inbox. >> >> >> >> On Sat, Dec 27, 2014 at 4:03 PM, Gerlof Fokkema >> >> wrote: >> >>> Hi all, >> >>> >> >>> Since a few weeks I own a laptop with an Intel Wireless 7260 wireless >> >>> adapter. >> >>> I first noticed that my connection started dropping when I transferred >> >>> large files over WiFi. >> >>> Later on I noticed this problem when the signal strength was low as well. >> >>> >> >>> I seem to be experiencing the bug described here: >> >>> https://bugzilla.kernel.org/show_bug.cgi?id=56581 >> >> >> >> This bug relates to dvm - which is de-facto another driver. We made >> >> this work around because >> >> of firmware issues. These issues aren't supposed to happen on devices >> >> supported by iwlmvm. >> >> Obviously, they do. You are not the only one to report this issue. >> >> I will discuss it with our firmware team. >> >> >> >>> >> >>> However, if I read the changelogs correctly, this should've been fixed >> >>> in 3.17.3. >> >>> >> >>> Atttached you'll find dmesg.log with the error. >> >>> Excerpt: >> >>> [ 152.941067] iwlwifi :03:00.0: fail to flush all tx fifo queues Q 2 >> >>> [ 152.941072] iwlwifi :03:00.0: Current SW read_ptr 209 write_ptr >> >>> 234 >> >>> [ 152.941097] iwl data: : 00 00 00 00 00 00 00 00 00 00 00 00 >> >>> 00 00 00 00 >> >>> [ 152.94] iwlwifi :03:00.0: FH TRBs(0) = 0x80003000 >> >>> [ 152.941125] iwlwifi :03:00.0: FH TRBs(1) = 0xc01100f2 >> >>> [ 152.941139] iwlwifi :03:00.0: FH TRBs(2) = 0x >> >>> When I try reconnecting to WiFi I get dozens more of those errors. >> >>> >> >>> Can someone point me in the right direction for this? >> >>> Is there already a bugreport for this on kernel 3.17.6? >> >>> Should you need more information, I'm happy to supply. >> >>> >> >>> For now I've reverted to 3.16.4, since it seems to work better... >> >> >> >> Probably because 3.16 uses an older firmware (-9.ucode). >> >> This is also an interesting input - although I heard complaints about >> >> this very same issue on -9.ucode as well. >> >> >> >>> >> >>> Kind regards, >> >>> Gerlof Fokkema > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On 02/02/2015 10:52 AM, Eric Dumazet wrote: > On Mon, 2015-02-02 at 11:27 +0100, Michal Kazior wrote: > >> While testing I've had my internal GRO patch for ath10k and no stretch >> ack patches. > > Thanks for the data, I took a look at it. > > I am afraid this GRO patch might be the problem. > > It seems to break ACK clocking badly (linux stack has a somewhat buggy > tcp_tso_should_defer(), which relies on ACK being received smoothly, as > no timer is setup to split the TSO packet.) It is a big throughput win to have fewer TCP ack packets on wireless since it is a half-duplex environment. Is there anything we could improve so that we can have fewer acks and still get good tcp stack behaviour? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
broken URLs of iwlwifi firmware tarballs
Hello, the URLs to iwlwifi firmware tarballs are broken. https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi Is that a temporary problem? I could find no mirrors for some of the files. (Besides, I found that nixos.org isn't the only user of those URLs.) Please, CC me with replies. Thanks, Vladimir smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On 02/02/2015 11:47 AM, Johannes Berg wrote: On Mon, 2015-02-02 at 11:36 -0800, Peter Oh wrote: On 02/02/2015 11:22 AM, Johannes Berg wrote: You basically have the following sequence: iowrite() ioread() If you look, you'll see that iowrite() is actually done (or should be, or perhaps with appropriate syncs) on an uncached mapping. since it's mmio, iowrite will be map to write, not out which is cached mapping. That's why we address "posted write" here. If it's un-cached mapping which is volatile, we don't even need ioread. No, this isn't true - "posted write" in the context of this discussion is about the PCIe bus. Memory writes that go through cache aren't referred to as "posted writes", those are just (cached) memory writes. As a result, the only thing you care about here is the PCIe bus, not the CPU cache flush. And from there on that's just a question of PCIe bus semantics. So how does ioread guarantee PCIe bus transaction done? That's how PCIe works, operations are serialized, and read() has to wait for a response from the device do you know which mechanism or which instruction set makes read() wait for a response from the device? I have no idea. I assume it's just like a DRAM read, the CPU stalls while there's no response. My explanation in this thread is all about how read() guarantees the wait for a response from the device, therefore why mb() - replace from wmb at patch set 2 - is compatible to read(). Briefly speaking, read() -> dsb 'st' -> cpu (actually axi master in cpu) holding axi bus -> cpu post write buffer on axi bus -> axi bus (axi slave which is PCIe device) signals write completion when write transactions completed in write response channel -> cpu release axi bus -> cpu program counter (pc) proceeds the next to read. the exact same routines happen with mb(). mb() -> dsb 'st' -> cpu (actually axi master in cpu) holding axi bus -> cpu post write buffer on axi bus -> axi bus (axi slave which is PCIe device) signals write completion when write transactions completed in write response channel -> cpu release axi bus -> cpu program counter (pc) proceeds the next to read. Since axi bus master is waiting (blocking) for write completion signal from axi slave (PCIe device), this is how read() and mb() guarantee write command reaches to the device. johannes ___ ath10k mailing list ath...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k Regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On 30 January 2015 at 18:06, Sujith Manoharan wrote: > Peter Oh wrote: >> Please refer the email thread that I mentioned about other architectures. >> (dsb is for ARM and other platforms have the equivalent instruction such >> as sfence, sync, mf, and dcs). > > Ok. > >> Also the patch is updated with 2nd patch set replacing wmb to mb. > > Would be good to test this on a MIPS platform... > The Atheros mips74k stuff I have here does /not/ flush all the writes out to the device and guarantee the device has seen everything with a memory barrier. Just saying. Various drivers ended up needing ioread()s in my experiments; mips sync operations weren't enough. So I'd suggest abstracting it out like the linux dri i915 code has - they define a "posting read" macro which they use whenever they need to ensure it's definitely made it all the way out to the hardware and through internal FIFOs so internal hardware has seen the state change. Then you can redefine that to your hearts content based on platform. -adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Open Source RRM & Hand-Over Optimization (WAS: Throughput regression with `tcp: refine TSO autosizing`)
On Mon, Feb 2, 2015 at 11:44 AM, Björn Smedman wrote: > On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun wrote: >> While there is definitely some work to be done in handoff, it seems >> like there are some find implementations of this already in existence. >> Several brands of "enterprise access point" setups seem to do well at >> this. It would be nice if they interoperated, I guess. >> >> The fact that there's no open source version of this kind of handoff >> feature bugs me, but we are working on it here and the work is all >> planned to be open source, for example: (very early version) >> https://gfiber.googlesource.com/vendor/google/platform/+/master/waveguide/ > > We've got an SDN-inspired architecture with 802.11 frame tunneling (a > la CAPWAP), airtime fairness, infrastructure initiated hand-over, > Opportunistic Key Caching (OKC), IEEE 802.11r Fast BSS Transition and > a few more goodies. It's currently free as in beer > (http://anyfi.net/software, > https://github.com/carrierwrt/carrierwrt/pull/7 and > http://www.anyfinetworks.com/download) up to 100 APs, but we're > definitely going to open source in one form or another. > > We've also tried to raise some interest in fixing up CAPWAP > (https://www.ietf.org/mail-archive/web/opsawg/current/msg03196.html), > which is (unfortunately) the best open standard at the moment. > Interest seems marginal though... This sounds cool. Is the CAPWAP/encapsulation stuff separable from the rest? At 802.11ac speeds, a super fast WAN link, and a low-cost SoC, too many layers can be a killer. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: broken URLs of iwlwifi firmware tarballs
On Mon, 2 Feb 2015, Vladimír Čunát wrote: > the URLs to iwlwifi firmware tarballs are broken. > https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi > > Is that a temporary problem? I could find no mirrors for some of the files. > (Besides, I found that nixos.org isn't the only user of those URLs.) Aren't they now all available as part of https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ ? c'ya sven-haegar -- Three may keep a secret, if two of them are dead. - Ben F.
Re: broken URLs of iwlwifi firmware tarballs
On 02/02/2015 11:45 PM, Sven-Haegar Koch wrote: Aren't they now all available as part of https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/ Yes, all should be there as well, I guess. I didn't switch to that repo yet because: - they're not the same *.tgz files (with the same hashes); - serving uncompressed files through (c)git surely isn't a preferred method to distribute binaries; - the URLs were used by many (according to my searching), so it seemed preferable to just fix them instead of everyone switching to different ones. Vladimir smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On 02/02/2015 02:26 PM, Adrian Chadd wrote: On 30 January 2015 at 18:06, Sujith Manoharan wrote: Peter Oh wrote: Please refer the email thread that I mentioned about other architectures. (dsb is for ARM and other platforms have the equivalent instruction such as sfence, sync, mf, and dcs). Ok. Also the patch is updated with 2nd patch set replacing wmb to mb. Would be good to test this on a MIPS platform... The Atheros mips74k stuff I have here does /not/ flush all the writes out to the device and guarantee the device has seen everything with a memory barrier. Just saying. Various drivers ended up needing ioread()s in my experiments; mips sync operations weren't enough. So I'd suggest abstracting it out like the linux dri i915 code has - they define a "posting read" macro which they use whenever they need to ensure it's definitely made it all the way out to the hardware and through internal FIFOs so internal hardware has seen the state change. Then you can redefine that to your hearts content based on platform. Thank you Adrian to head up the concern and suggestion. The other people also concerned about other architectures like mips, so I was going to analysis it. But since you've already experienced the defects, let me hold the change back until I find better for all. -adrian Regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On Mon, 2015-02-02 at 13:25 -0800, Ben Greear wrote: > It is a big throughput win to have fewer TCP ack packets on > wireless since it is a half-duplex environment. Is there anything > we could improve so that we can have fewer acks and still get > good tcp stack behaviour? First apply TCP stretch ack fixes to the sender. There is no way to get good performance if the sender does not handle stretch ack. d6b1a8a92a14 tcp: fix timing issue in CUBIC slope calculation 9cd981dcf174 tcp: fix stretch ACK bugs in CUBIC c22bdca94782 tcp: fix stretch ACK bugs in Reno 814d488c6126 tcp: fix the timid additive increase on stretch ACKs e73ebb0881ea tcp: stretch ACK fixes prep Then, make sure you do not throttle ACK too long, especially if you hope to get Gbit line rate on a 4 ms RTT flow. GRO does not mean : send one ACK every ms, or after 3ms delay... It is literally : aggregate X packets at receive, and send the ACK asap. If the receiver expects to have 64 ACK packets in the TX ring buffer to actually send them (wifi aggregation), then you certainly do not want to compress ACK too much. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
On 02/02/15 14:06, Peter Oh wrote: > > On 02/02/2015 11:47 AM, Johannes Berg wrote: >> On Mon, 2015-02-02 at 11:36 -0800, Peter Oh wrote: >>> On 02/02/2015 11:22 AM, Johannes Berg wrote: >> You basically have the following sequence: >> >> iowrite() >> ioread() >> >> If you look, you'll see that iowrite() is actually done (or should >> be, >> or perhaps with appropriate syncs) on an uncached mapping. > since it's mmio, iowrite will be map to write, not out which is >> cached > mapping. > That's why we address "posted write" here. > If it's un-cached mapping which is volatile, we don't even need >> ioread. No, this isn't true - "posted write" in the context of this discussion is about the PCIe bus. Memory writes that go through cache aren't referred to as "posted writes", those are just (cached) memory writes. >> As a result, >> the only thing you care about here is the PCIe bus, not the CPU >> cache >> flush. And from there on that's just a question of PCIe bus >> semantics. > So how does ioread guarantee PCIe bus transaction done? That's how PCIe works, operations are serialized, and read() has to >> wait for a response from the device >>> do you know which mechanism or which instruction set makes read() wait >>> for a response from the device? >> I have no idea. I assume it's just like a DRAM read, the CPU stalls >> while there's no response. > My explanation in this thread is all about how read() guarantees the > wait for a response from the device, therefore why mb() - replace from > wmb at patch set 2 - is compatible to read(). > Briefly speaking, > read() -> dsb 'st' -> cpu (actually axi master in cpu) holding axi bus > -> cpu post write buffer on axi bus -> axi bus (axi slave which is PCIe > device) signals write completion when write transactions completed in > write response channel -> cpu release axi bus -> cpu program counter > (pc) proceeds the next to read. > > the exact same routines happen with mb(). > mb() -> dsb 'st' -> cpu (actually axi master in cpu) holding axi bus -> > cpu post write buffer on axi bus -> axi bus (axi slave which is PCIe > device) signals write completion when write transactions completed in > write response channel -> cpu release axi bus -> cpu program counter > (pc) proceeds the next to read. > > Since axi bus master is waiting (blocking) for write completion signal > from axi slave (PCIe device), this is how read() and mb() guarantee > write command reaches to the device. PCIe writes are posted, so the only guarantee you can have by inserting such barriers is that writes from CPU to the PCIe RC (targeting PCIe device) is non-posted (as far as the busing between CPU and the PCIe RC is concerned), but past the PCIe RC, there is no such guarantee, because the PCIe specification allows for that and there is flow control, PCIe switches or other things that can alter the way your PCIe device ends-up being written to. The only way to make a "portable" synchronization barrier is to do a PCIe read from the same register you just wrote to, because then, the PCIe RC needs to guarantee the transaction ordering on the PCIe bus itself. You might just be lucky and/or have very good HW which ensures that the ARM synchronization barriers are propagated to the memory region where your PCIe device BARs are mapped from the CPU perspective, but you definitively cannot rely on such assumptions, as there will be bogus HW there, for which only a subsequent ioread32() will work. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Cerowrt-devel] Open Source RRM & Hand-Over Optimization (WAS: Throughput regression with `tcp: refine TSO autosizing`)
On Mon, 2 Feb 2015, Avery Pennarun wrote: On Mon, Feb 2, 2015 at 11:44 AM, Björn Smedman wrote: On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun wrote: While there is definitely some work to be done in handoff, it seems like there are some find implementations of this already in existence. Several brands of "enterprise access point" setups seem to do well at this. It would be nice if they interoperated, I guess. The fact that there's no open source version of this kind of handoff feature bugs me, but we are working on it here and the work is all planned to be open source, for example: (very early version) https://gfiber.googlesource.com/vendor/google/platform/+/master/waveguide/ We've got an SDN-inspired architecture with 802.11 frame tunneling (a la CAPWAP), airtime fairness, infrastructure initiated hand-over, Opportunistic Key Caching (OKC), IEEE 802.11r Fast BSS Transition and a few more goodies. It's currently free as in beer (http://anyfi.net/software, https://github.com/carrierwrt/carrierwrt/pull/7 and http://www.anyfinetworks.com/download) up to 100 APs, but we're definitely going to open source in one form or another. Please keep in touch, when it is released open source I'd be very interested in trying it for SCaLE. I'll probably exceed your 100 radio free limit this year, and it's hard to justify using non-free code at a linux conference (not impossible, but not something I'm going to try to do 3 weeks before the show :-) I'm doing social engineering to push people to the 5GHz network (SSID for 5G is scale, for 2.4 is scale-slow), it would be great to be able to do this directly. And better handoffs as people move around would be good. It would also be good if something like this could help identify gaps in coverage. If it can identify cases where users go from having coverage to poor connectivity to having coverage, we can manually investigate to see where in the building that is and see what we can do to fix it. David Lang We've also tried to raise some interest in fixing up CAPWAP (https://www.ietf.org/mail-archive/web/opsawg/current/msg03196.html), which is (unfortunately) the best open standard at the moment. Interest seems marginal though... This sounds cool. Is the CAPWAP/encapsulation stuff separable from the rest? At 802.11ac speeds, a super fast WAN link, and a low-cost SoC, too many layers can be a killer. ___ Cerowrt-devel mailing list cerowrt-de...@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
rtl8192ee (Thinkpad T440s)
Hi, all. Just got a new Thinkpad, and needless to say, tried to fire it up on the network. Ubuntu 14.04 didn't have the driver, so I tried 14.10, which did. I thought I was good until I tried to connect; the laptop would see all the advertised WAPs, but wouldn't connect to any of them (including my security-free ones). I then downloaded the 3.19 RC and tried that -- same deal. I see a few extra git commits in -next; any idea if that will be of any assistance? Is there anything I can dig through in my logs to help flesh out what the problem is? Thanks! -Ken -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Replace ioread with wmb for data sync
Hi Florian, Very appreciate your explanation in detail. Regards, Peter On 02/02/2015 03:25 PM, Florian Fainelli wrote: On 02/02/15 14:06, Peter Oh wrote: On 02/02/2015 11:47 AM, Johannes Berg wrote: On Mon, 2015-02-02 at 11:36 -0800, Peter Oh wrote: On 02/02/2015 11:22 AM, Johannes Berg wrote: You basically have the following sequence: iowrite() ioread() If you look, you'll see that iowrite() is actually done (or should be, or perhaps with appropriate syncs) on an uncached mapping. since it's mmio, iowrite will be map to write, not out which is cached mapping. That's why we address "posted write" here. If it's un-cached mapping which is volatile, we don't even need ioread. No, this isn't true - "posted write" in the context of this discussion is about the PCIe bus. Memory writes that go through cache aren't referred to as "posted writes", those are just (cached) memory writes. As a result, the only thing you care about here is the PCIe bus, not the CPU cache flush. And from there on that's just a question of PCIe bus semantics. So how does ioread guarantee PCIe bus transaction done? That's how PCIe works, operations are serialized, and read() has to wait for a response from the device do you know which mechanism or which instruction set makes read() wait for a response from the device? I have no idea. I assume it's just like a DRAM read, the CPU stalls while there's no response. My explanation in this thread is all about how read() guarantees the wait for a response from the device, therefore why mb() - replace from wmb at patch set 2 - is compatible to read(). Briefly speaking, read() -> dsb 'st' -> cpu (actually axi master in cpu) holding axi bus -> cpu post write buffer on axi bus -> axi bus (axi slave which is PCIe device) signals write completion when write transactions completed in write response channel -> cpu release axi bus -> cpu program counter (pc) proceeds the next to read. the exact same routines happen with mb(). mb() -> dsb 'st' -> cpu (actually axi master in cpu) holding axi bus -> cpu post write buffer on axi bus -> axi bus (axi slave which is PCIe device) signals write completion when write transactions completed in write response channel -> cpu release axi bus -> cpu program counter (pc) proceeds the next to read. Since axi bus master is waiting (blocking) for write completion signal from axi slave (PCIe device), this is how read() and mb() guarantee write command reaches to the device. PCIe writes are posted, so the only guarantee you can have by inserting such barriers is that writes from CPU to the PCIe RC (targeting PCIe device) is non-posted (as far as the busing between CPU and the PCIe RC is concerned), but past the PCIe RC, there is no such guarantee, because the PCIe specification allows for that and there is flow control, PCIe switches or other things that can alter the way your PCIe device ends-up being written to. The only way to make a "portable" synchronization barrier is to do a PCIe read from the same register you just wrote to, because then, the PCIe RC needs to guarantee the transaction ordering on the PCIe bus itself. You might just be lucky and/or have very good HW which ensures that the ARM synchronization barriers are propagated to the memory region where your PCIe device BARs are mapped from the CPU perspective, but you definitively cannot rely on such assumptions, as there will be bogus HW there, for which only a subsequent ioread32() will work. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: rtl8192ee (Thinkpad T440s)
On 02/02/2015 05:24 PM, Ken D'Ambrosio wrote: Hi, all. Just got a new Thinkpad, and needless to say, tried to fire it up on the network. Ubuntu 14.04 didn't have the driver, so I tried 14.10, which did. I thought I was good until I tried to connect; the laptop would see all the advertised WAPs, but wouldn't connect to any of them (including my security-free ones). I then downloaded the 3.19 RC and tried that -- same deal. I see a few extra git commits in -next; any idea if that will be of any assistance? Is there anything I can dig through in my logs to help flesh out what the problem is? Logs are always helpful. As some of us do not use Ubuntu, a kernel version as shown by 'uname -r' is a lot more helpful that what version of Ubuntu you are using. Kernel 3.19-rc4 from the wireless-drivers repo contains all those commits in -next, and it works fine here. At this point, I have been connected for 27 hours with a WPA2 connection. You can also try the repo at http://github.com/lwfinger/rtlwifi-new.git. The master branch should be OK. If not, try the troy branch. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On Mon, 2015-02-02 at 10:52 -0800, Eric Dumazet wrote: > It seems to break ACK clocking badly (linux stack has a somewhat buggy > tcp_tso_should_defer(), which relies on ACK being received smoothly, as > no timer is setup to split the TSO packet.) Following patch might help the TSO split defer logic. It would avoid setting the TSO defer 'pseudo timer' twice, if/when TCP Small Queue logic prevented the xmit at the expiration of first 'timer'. This patch clears the tso_deferred variable only if we could really send something. Please try it, thanks ! diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index 65caf8b95e17..e735f38557db 100644 --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -1821,7 +1821,6 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb, return true; send_now: - tp->tso_deferred = 0; return false; } @@ -2070,6 +2069,7 @@ static bool tcp_write_xmit(struct sock *sk, unsigned int mss_now, int nonagle, if (unlikely(tcp_transmit_skb(sk, skb, 1, gfp))) break; + tp->tso_deferred = 0; repair: /* Advance the send_head. This one is sent out. * This call will increment packets_out. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pull request: iwlwifi-next 2015-02-03
Hi Kalle, Here is probably the last pull request for 3.20. Details below. Since it is probably too late to send patches for 3.19, There are a few patches here that are tagged for stable. Please let me know if you have issues! The following changes since commit 0b83795a110248db8f8e7c289a27b3b71b0bb35a: iwlwifi: mvm: fix rx chains configuration in phy ctxt cmd (2015-01-22 22:17:22 +0200) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2015-02-03 for you to fetch changes up to b9a641d9cb768177a7c867e382a2fdb6023b06ad: iwlwifi: mvm: reduce quota threshold (2015-02-03 09:01:44 +0200) * Add support for beamforming * Enable stuck queue detection for iwlmvm * A few fixes for EBS scan * Fixes for various failure paths * Improvements for TDLS Offchannel Arik Nemtsov (2): iwlwifi: mvm: improve TDLS ch-sw state machine iwlwifi: mvm: ignore stale TDLS ch-switch responses Emmanuel Grumbach (7): iwlwifi: mvm: check IWL_UCODE_TLV_API_SCD_CFG in API and not in capa iwlwifi: pcie: don't dump useless data when a TFD queue hangs iwlwifi: pcie: prepare the enablement of 31 TFD queues iwlwifi: pcie: disable the SCD_BASE_ADDR when we resume from WoWLAN iwlwifi: mvm: enable watchdog on Tx queues for mvm iwlwifi: allow to define the stuck queue timer per queue iwlwifi: mvm: don't send a command the firmware doesn't know Eyal Shapira (2): iwlwifi: mvm: add beamformer support iwlwifi: mvm: rs: enable forcing single stream Tx decision Haim Dreyfuss (2): iwlwifi: mvm: Fix a few EBS error handling bugs iwlwifi: mvm: Enable EBS also in single scan on umac interface Ilan Peer (1): iwlwifi: mvm: Fix building channels in scan_config_cmd Johannes Berg (2): iwlwifi: mvm: remove space padding after sysassert description iwlwifi: mvm: reduce quota threshold Luciano Coelho (3): iwlwifi: mvm: don't reprobe if we fail during reconfig and fw_restart is false iwlwifi: mvm: always use mac color zero iwlwifi: mvm: fix failure path when power_update fails in add_interface drivers/net/wireless/iwlwifi/dvm/main.c | 7 +- drivers/net/wireless/iwlwifi/dvm/tx.c| 2 +- drivers/net/wireless/iwlwifi/dvm/ucode.c | 2 +- drivers/net/wireless/iwlwifi/iwl-config.h| 2 +- drivers/net/wireless/iwlwifi/iwl-drv.c | 5 - drivers/net/wireless/iwlwifi/iwl-fw-file.h | 2 + drivers/net/wireless/iwlwifi/iwl-modparams.h | 2 - drivers/net/wireless/iwlwifi/iwl-prph.h | 26 +- drivers/net/wireless/iwlwifi/iwl-scd.h | 41 +++-- drivers/net/wireless/iwlwifi/iwl-trans.h | 29 +++--- drivers/net/wireless/iwlwifi/mvm/constants.h | 2 +- drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h | 43 +++-- drivers/net/wireless/iwlwifi/mvm/fw.c| 3 +- drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c | 10 +- drivers/net/wireless/iwlwifi/mvm/mac80211.c | 12 ++- drivers/net/wireless/iwlwifi/mvm/mvm.h | 23 +++-- drivers/net/wireless/iwlwifi/mvm/ops.c | 28 -- drivers/net/wireless/iwlwifi/mvm/rs.c| 241 + drivers/net/wireless/iwlwifi/mvm/rs.h| 14 ++- drivers/net/wireless/iwlwifi/mvm/scan.c | 24 - drivers/net/wireless/iwlwifi/mvm/sta.c | 15 ++- drivers/net/wireless/iwlwifi/mvm/tdls.c | 63 + drivers/net/wireless/iwlwifi/mvm/utils.c | 10 +- drivers/net/wireless/iwlwifi/pcie/internal.h | 10 +- drivers/net/wireless/iwlwifi/pcie/trans.c| 5 +- drivers/net/wireless/iwlwifi/pcie/tx.c | 58 ++-- 26 files changed, 503 insertions(+), 176 deletions(-)
[PATCH 01/19] iwlwifi: mvm: check IWL_UCODE_TLV_API_SCD_CFG in API and not in capa
IWL_UCODE_TLV_API_SCD_CFG is a new API and hence, check if
enabled in the correct field.
Fixes: 0294d9eece86 ("iwlwifi: mvm: let the firmware configure the scheduler")
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/mvm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h
b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index 979ac23..7773ffc 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -874,7 +874,7 @@ static inline bool iwl_mvm_is_d0i3_supported(struct iwl_mvm
*mvm)
static inline bool iwl_mvm_is_scd_cfg_supported(struct iwl_mvm *mvm)
{
- return mvm->fw->ucode_capa.capa[0] & IWL_UCODE_TLV_API_SCD_CFG;
+ return mvm->fw->ucode_capa.api[0] & IWL_UCODE_TLV_API_SCD_CFG;
}
extern const u8 iwl_mvm_ac_to_tx_fifo[];
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/19] iwlwifi: mvm: don't reprobe if we fail during reconfig and fw_restart is false
From: Luciano Coelho
If we don't want to restart the firmware, don't reprobe either in case
of a failure during reconfiguration. This allows us to debug failures
in the reconfig flow as well.
Signed-off-by: Luciano Coelho
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/ops.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c
b/drivers/net/wireless/iwlwifi/mvm/ops.c
index 8bf8c2a..b1dea68 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -870,7 +870,10 @@ void iwl_mvm_nic_restart(struct iwl_mvm *mvm, bool
fw_error)
* If WoWLAN fw asserted, don't restart either, mac80211
* can't recover this since we're already half suspended.
*/
- if (test_and_set_bit(IWL_MVM_STATUS_IN_HW_RESTART, &mvm->status)) {
+ if (!mvm->restart_fw && fw_error) {
+ schedule_work(&mvm->fw_error_dump_wk);
+ } else if (test_and_set_bit(IWL_MVM_STATUS_IN_HW_RESTART,
+ &mvm->status)) {
struct iwl_mvm_reprobe *reprobe;
IWL_ERR(mvm,
@@ -894,16 +897,13 @@ void iwl_mvm_nic_restart(struct iwl_mvm *mvm, bool
fw_error)
reprobe->dev = mvm->trans->dev;
INIT_WORK(&reprobe->work, iwl_mvm_reprobe_wk);
schedule_work(&reprobe->work);
- } else if (mvm->cur_ucode == IWL_UCODE_REGULAR &&
- (!fw_error || mvm->restart_fw)) {
+ } else if (mvm->cur_ucode == IWL_UCODE_REGULAR) {
/* don't let the transport/FW power down */
iwl_mvm_ref(mvm, IWL_MVM_REF_UCODE_DOWN);
if (fw_error && mvm->restart_fw > 0)
mvm->restart_fw--;
ieee80211_restart_hw(mvm->hw);
- } else if (fw_error) {
- schedule_work(&mvm->fw_error_dump_wk);
}
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/19] iwlwifi: mvm: always use mac color zero
From: Luciano Coelho We don't really need to use different mac colors when adding mac contexts, because they're not used anywhere. In fact, the firmware doesn't accept 255 as a valid color, so we get into a SYSASSERT 0x3401 when we reach that. Remove the color increment to use always zero and avoid reaching 255. CC: [3.10+] Signed-off-by: Luciano Coelho Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/iwlwifi/mvm/mac80211.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/iwlwifi/mvm/mac80211.c index cef6f33..cfd7bfc 100644 --- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c +++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c @@ -707,9 +707,6 @@ static void iwl_mvm_cleanup_iterator(void *data, u8 *mac, mvmvif->uploaded = false; mvmvif->ap_sta_id = IWL_MVM_STATION_COUNT; - /* does this make sense at all? */ - mvmvif->color++; - spin_lock_bh(&mvm->time_event_lock); iwl_mvm_te_clear_data(mvm, &mvmvif->time_event_data); spin_unlock_bh(&mvm->time_event_lock); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/19] iwlwifi: mvm: rs: enable forcing single stream Tx decision
From: Eyal Shapira
In certain testing scenarios we'd like to force a decision
between STBC/BFER/SISO. In the normal scenario this decision
is done by the FW. Enable this option vis debugfs.
Signed-off-by: Eyal Shapira
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h | 8 +++
drivers/net/wireless/iwlwifi/mvm/rs.c| 84
drivers/net/wireless/iwlwifi/mvm/rs.h| 10
3 files changed, 102 insertions(+)
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h
b/drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h
index 4c33f27..0f1ea80 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h
+++ b/drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h
@@ -330,6 +330,14 @@ enum {
#define LQ_SS_BFER_ALLOWED_POS 2
#define LQ_SS_BFER_ALLOWED (1 << LQ_SS_BFER_ALLOWED_POS)
+/* Bit 3: Force BFER or STBC for testing
+ * If this is set:
+ * If BFER is allowed then force the ucode to choose BFER else
+ * If STBC is allowed then force the ucode to choose STBC over SISO
+ */
+#define LQ_SS_FORCE_POS3
+#define LQ_SS_FORCE(1 << LQ_SS_FORCE_POS)
+
/* Bit 31: ss_params field is valid. Used for FW backward compatibility
* with other drivers which don't support the ss_params API yet
*/
diff --git a/drivers/net/wireless/iwlwifi/mvm/rs.c
b/drivers/net/wireless/iwlwifi/mvm/rs.c
index 95b718b..194bd1f 100644
--- a/drivers/net/wireless/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/iwlwifi/mvm/rs.c
@@ -39,6 +39,7 @@
#include "sta.h"
#include "iwl-op-mode.h"
#include "mvm.h"
+#include "debugfs.h"
#define RS_NAME "iwl-mvm-rs"
@@ -3057,6 +3058,20 @@ static void rs_set_lq_ss_params(struct iwl_mvm *mvm,
if (!iwl_mvm_bt_coex_is_mimo_allowed(mvm, sta))
goto out;
+ /* Check if forcing the decision is configured.
+* Note that SISO is forced by not allowing STBC or BFER
+*/
+ if (lq_sta->ss_force == RS_SS_FORCE_STBC)
+ ss_params |= (LQ_SS_STBC_1SS_ALLOWED | LQ_SS_FORCE);
+ else if (lq_sta->ss_force == RS_SS_FORCE_BFER)
+ ss_params |= (LQ_SS_BFER_ALLOWED | LQ_SS_FORCE);
+
+ if (lq_sta->ss_force != RS_SS_FORCE_NONE) {
+ IWL_DEBUG_RATE(mvm, "Forcing single stream Tx decision %d\n",
+ lq_sta->ss_force);
+ goto out;
+ }
+
if (lq_sta->stbc_capable)
ss_params |= LQ_SS_STBC_1SS_ALLOWED;
@@ -3502,9 +3517,73 @@ static const struct file_operations
rs_sta_dbgfs_drv_tx_stats_ops = {
.llseek = default_llseek,
};
+static ssize_t iwl_dbgfs_ss_force_read(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct iwl_lq_sta *lq_sta = file->private_data;
+ char buf[12];
+ int bufsz = sizeof(buf);
+ int pos = 0;
+ static const char * const ss_force_name[] = {
+ [RS_SS_FORCE_NONE] = "none",
+ [RS_SS_FORCE_STBC] = "stbc",
+ [RS_SS_FORCE_BFER] = "bfer",
+ [RS_SS_FORCE_SISO] = "siso",
+ };
+
+ pos += scnprintf(buf+pos, bufsz-pos, "%s\n",
+ss_force_name[lq_sta->ss_force]);
+ return simple_read_from_buffer(user_buf, count, ppos, buf, pos);
+}
+
+static ssize_t iwl_dbgfs_ss_force_write(struct iwl_lq_sta *lq_sta, char *buf,
+ size_t count, loff_t *ppos)
+{
+ struct iwl_mvm *mvm = lq_sta->pers.drv;
+ int ret = 0;
+
+ if (!strncmp("none", buf, 4)) {
+ lq_sta->ss_force = RS_SS_FORCE_NONE;
+ } else if (!strncmp("siso", buf, 4)) {
+ lq_sta->ss_force = RS_SS_FORCE_SISO;
+ } else if (!strncmp("stbc", buf, 4)) {
+ if (lq_sta->stbc_capable) {
+ lq_sta->ss_force = RS_SS_FORCE_STBC;
+ } else {
+ IWL_ERR(mvm,
+ "can't force STBC. peer doesn't support\n");
+ ret = -EINVAL;
+ }
+ } else if (!strncmp("bfer", buf, 4)) {
+ if (lq_sta->bfer_capable) {
+ lq_sta->ss_force = RS_SS_FORCE_BFER;
+ } else {
+ IWL_ERR(mvm,
+ "can't force BFER. peer doesn't support\n");
+ ret = -EINVAL;
+ }
+ } else {
+ IWL_ERR(mvm, "valid values none|siso|stbc|bfer\n");
+ ret = -EINVAL;
+ }
+ return ret ?: count;
+}
+
+#define MVM_DEBUGFS_READ_WRITE_FILE_OPS(name, bufsz) \
+ _MVM_DEBUGFS_READ_WRITE_FILE_OPS(name, bufsz, struct iwl_lq_sta)
+#define MVM_DEBUGFS_ADD_FILE_RS(name, parent, mode) do { \
+ if (!debugfs_create_file(#name, mode, parent, lq_sta, \
+
[PATCH 05/19] iwlwifi: pcie: don't dump useless data when a TFD queue hangs
Printing all the scratch data of the TFDs of that queue is
useless and stuffed the kernel log with data. Remove that.
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/pcie/tx.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c
b/drivers/net/wireless/iwlwifi/pcie/tx.c
index d40cd4a..6c7bfe8 100644
--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
@@ -147,7 +147,6 @@ static void iwl_pcie_free_dma_ptr(struct iwl_trans *trans,
static void iwl_pcie_txq_stuck_timer(unsigned long data)
{
struct iwl_txq *txq = (void *)data;
- struct iwl_queue *q = &txq->q;
struct iwl_trans_pcie *trans_pcie = txq->trans_pcie;
struct iwl_trans *trans = iwl_trans_pcie_get_trans(trans_pcie);
u32 scd_sram_addr = trans_pcie->scd_base_addr +
@@ -198,11 +197,6 @@ static void iwl_pcie_txq_stuck_timer(unsigned long data)
iwl_read_prph(trans, SCD_QUEUE_WRPTR(i)));
}
- for (i = q->read_ptr; i != q->write_ptr;
-i = iwl_queue_inc_wrap(i))
- IWL_ERR(trans, "scratch %d = 0x%08x\n", i,
- le32_to_cpu(txq->scratchbufs[i].scratch));
-
iwl_force_nmi(trans);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/19] iwlwifi: mvm: remove space padding after sysassert description
From: Johannes Berg There's really no reason to pad out the field with spaces at the end of the line - they're practically invisible there anyway. Signed-off-by: Johannes Berg Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/iwlwifi/mvm/utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/iwlwifi/mvm/utils.c b/drivers/net/wireless/iwlwifi/mvm/utils.c index 4eb3cad..02f434d 100644 --- a/drivers/net/wireless/iwlwifi/mvm/utils.c +++ b/drivers/net/wireless/iwlwifi/mvm/utils.c @@ -432,7 +432,7 @@ static void iwl_mvm_dump_umac_error_log(struct iwl_mvm *mvm) mvm->status, table.valid); } - IWL_ERR(mvm, "0x%08X | %-28s\n", table.error_id, + IWL_ERR(mvm, "0x%08X | %s\n", table.error_id, desc_lookup(table.error_id)); IWL_ERR(mvm, "0x%08X | umac branchlink1\n", table.blink1); IWL_ERR(mvm, "0x%08X | umac branchlink2\n", table.blink2); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/19] iwlwifi: pcie: disable the SCD_BASE_ADDR when we resume from WoWLAN
The base address of the scheduler in the device's memory (SRAM) comes from two different sources. The periphery register and the alive notification from the firmware. We have a check in iwl_pcie_tx_start that ensures that they are the same. When we resume from WoWLAN, the firmware may have crashed for whatever reason. In that case, the whole device may be reset which means that the periphery register will hold a meaningless value. When we come to compare trans_pcie->scd_base_addr (which really holds the value we had when we loaded the WoWLAN firmware upon suspend) and the current value of the register, we don't see a match unsurprisingly. Trick the check to avoid a loud yet harmless WARN. Note that when the WoWLAN has crashed, we will see that in iwl_trans_pcie_d3_resume which will let the op_mode know. Once the op_mode is informed that the WowLAN firmware has crashed, it can't do much besides resetting the whole device. CC: Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/iwlwifi/pcie/tx.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c b/drivers/net/wireless/iwlwifi/pcie/tx.c index 0a94083..59aefa4 100644 --- a/drivers/net/wireless/iwlwifi/pcie/tx.c +++ b/drivers/net/wireless/iwlwifi/pcie/tx.c @@ -716,7 +716,12 @@ void iwl_trans_pcie_tx_reset(struct iwl_trans *trans) iwl_write_direct32(trans, FH_KW_MEM_ADDR_REG, trans_pcie->kw.dma >> 4); - iwl_pcie_tx_start(trans, trans_pcie->scd_base_addr); + /* +* Send 0 as the scd_base_addr since the device may have be reset +* while we were in WoWLAN in which case SCD_SRAM_BASE_ADDR will +* contain garbage. +*/ + iwl_pcie_tx_start(trans, 0); } /* -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/19] iwlwifi: pcie: prepare the enablement of 31 TFD queues
Some devices have 31 TFD queues. Don't enable it yet since
there are still issues with it, but at least prepare the
code for it. There was a bug in the read pointer assignment,
fix that. Also, move the inline functions to iwl-scd.h which
is the right place.
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/iwl-prph.h | 26 ++--
drivers/net/wireless/iwlwifi/iwl-scd.h| 41 +--
drivers/net/wireless/iwlwifi/pcie/trans.c | 1 +
drivers/net/wireless/iwlwifi/pcie/tx.c| 4 +++
4 files changed, 40 insertions(+), 32 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-prph.h
b/drivers/net/wireless/iwlwifi/iwl-prph.h
index b21fcf0..6221e4d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-prph.h
+++ b/drivers/net/wireless/iwlwifi/iwl-prph.h
@@ -252,6 +252,7 @@
#define SCD_QUEUE_CTX_REG2_WIN_SIZE_MSK(0x007F)
#define SCD_QUEUE_CTX_REG2_FRAME_LIMIT_POS (16)
#define SCD_QUEUE_CTX_REG2_FRAME_LIMIT_MSK (0x007F)
+#define SCD_GP_CTRL_ENABLE_31_QUEUES BIT(0)
/* Context Data */
#define SCD_CONTEXT_MEM_LOWER_BOUND(SCD_MEM_LOWER_BOUND + 0x600)
@@ -285,32 +286,9 @@
#define SCD_CHAINEXT_EN(SCD_BASE + 0x244)
#define SCD_AGGR_SEL (SCD_BASE + 0x248)
#define SCD_INTERRUPT_MASK (SCD_BASE + 0x108)
+#define SCD_GP_CTRL(SCD_BASE + 0x1a8)
#define SCD_EN_CTRL(SCD_BASE + 0x254)
-static inline unsigned int SCD_QUEUE_WRPTR(unsigned int chnl)
-{
- if (chnl < 20)
- return SCD_BASE + 0x18 + chnl * 4;
- WARN_ON_ONCE(chnl >= 32);
- return SCD_BASE + 0x284 + (chnl - 20) * 4;
-}
-
-static inline unsigned int SCD_QUEUE_RDPTR(unsigned int chnl)
-{
- if (chnl < 20)
- return SCD_BASE + 0x68 + chnl * 4;
- WARN_ON_ONCE(chnl >= 32);
- return SCD_BASE + 0x2B4 + (chnl - 20) * 4;
-}
-
-static inline unsigned int SCD_QUEUE_STATUS_BITS(unsigned int chnl)
-{
- if (chnl < 20)
- return SCD_BASE + 0x10c + chnl * 4;
- WARN_ON_ONCE(chnl >= 32);
- return SCD_BASE + 0x384 + (chnl - 20) * 4;
-}
-
/*** END TX SCHEDULER
*/
/* Oscillator clock */
diff --git a/drivers/net/wireless/iwlwifi/iwl-scd.h
b/drivers/net/wireless/iwlwifi/iwl-scd.h
index 6c622b2..f2353eb 100644
--- a/drivers/net/wireless/iwlwifi/iwl-scd.h
+++ b/drivers/net/wireless/iwlwifi/iwl-scd.h
@@ -69,14 +69,6 @@
#include "iwl-prph.h"
-static inline void iwl_scd_txq_set_inactive(struct iwl_trans *trans,
- u16 txq_id)
-{
- iwl_write_prph(trans, SCD_QUEUE_STATUS_BITS(txq_id),
- (0 << SCD_QUEUE_STTS_REG_POS_ACTIVE)|
- (1 << SCD_QUEUE_STTS_REG_POS_SCD_ACT_EN));
-}
-
static inline void iwl_scd_txq_set_chain(struct iwl_trans *trans,
u16 txq_id)
{
@@ -115,4 +107,37 @@ static inline void iwl_scd_enable_set_active(struct
iwl_trans *trans,
{
iwl_write_prph(trans, SCD_EN_CTRL, value);
}
+
+static inline unsigned int SCD_QUEUE_WRPTR(unsigned int chnl)
+{
+ if (chnl < 20)
+ return SCD_BASE + 0x18 + chnl * 4;
+ WARN_ON_ONCE(chnl >= 32);
+ return SCD_BASE + 0x284 + (chnl - 20) * 4;
+}
+
+static inline unsigned int SCD_QUEUE_RDPTR(unsigned int chnl)
+{
+ if (chnl < 20)
+ return SCD_BASE + 0x68 + chnl * 4;
+ WARN_ON_ONCE(chnl >= 32);
+ return SCD_BASE + 0x2B4 + chnl * 4;
+}
+
+static inline unsigned int SCD_QUEUE_STATUS_BITS(unsigned int chnl)
+{
+ if (chnl < 20)
+ return SCD_BASE + 0x10c + chnl * 4;
+ WARN_ON_ONCE(chnl >= 32);
+ return SCD_BASE + 0x334 + chnl * 4;
+}
+
+static inline void iwl_scd_txq_set_inactive(struct iwl_trans *trans,
+ u16 txq_id)
+{
+ iwl_write_prph(trans, SCD_QUEUE_STATUS_BITS(txq_id),
+ (0 << SCD_QUEUE_STTS_REG_POS_ACTIVE)|
+ (1 << SCD_QUEUE_STTS_REG_POS_SCD_ACT_EN));
+}
+
#endif
diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c
b/drivers/net/wireless/iwlwifi/pcie/trans.c
index 1ff8767..eb0ffc1 100644
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@ -75,6 +75,7 @@
#include "iwl-trans.h"
#include "iwl-csr.h"
#include "iwl-prph.h"
+#include "iwl-scd.h"
#include "iwl-agn-hw.h"
#include "iwl-fw-error-dump.h"
#include "internal.h"
diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c
b/drivers/net/wireless/iwlwifi/pcie/tx.c
index 6c7bfe8..0a94083 100644
--- a/drivers/net/wireless/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
@@ -892,6 +892,10 @@ int iwl_pcie_tx_init(struct iwl_trans *trans)
}
}
+ if (trans->cfg->base_params->num_of_queues > 20)
+ iwl_set_bits_prph(trans, SCD_GP_CTRL,
+
[PATCH 06/19] iwlwifi: mvm: add beamformer support
From: Eyal Shapira
VHT Beamformer (BFER) will be used if the peer supports it
and there's a benefit to use it vs. STBC or SISO.
The driver now tells the FW whether BFER and/or STBC are
allowed but the FW will make the decision to use either
or stick to SISO on its own.
BFER is limited to a single remote peer. The driver takes
care of ensuring this to the FW and prioritizes with which
peer BFER will be used.
Signed-off-by: Eyal Shapira
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/iwl-fw-file.h | 2 +
drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h | 35 --
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 7 +-
drivers/net/wireless/iwlwifi/mvm/rs.c| 157 ---
drivers/net/wireless/iwlwifi/mvm/rs.h| 4 +-
5 files changed, 177 insertions(+), 28 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-fw-file.h
b/drivers/net/wireless/iwlwifi/iwl-fw-file.h
index e4f5898..016d913 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw-file.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw-file.h
@@ -270,6 +270,7 @@ enum iwl_ucode_tlv_api {
* @IWL_UCODE_TLV_CAPA_D0I3_SUPPORT: supports D0i3
* @IWL_UCODE_TLV_CAPA_LAR_SUPPORT: supports Location Aware Regulatory
* @IWL_UCODE_TLV_CAPA_UMAC_SCAN: supports UMAC scan.
+ * @IWL_UCODE_TLV_CAPA_BEAMFORMER: supports Beamformer
* @IWL_UCODE_TLV_CAPA_TDLS_SUPPORT: support basic TDLS functionality
* @IWL_UCODE_TLV_CAPA_TXPOWER_INSERTION_SUPPORT: supports insertion of current
* tx power value into TPC Report action frame and Link Measurement Report
@@ -288,6 +289,7 @@ enum iwl_ucode_tlv_capa {
IWL_UCODE_TLV_CAPA_D0I3_SUPPORT = BIT(0),
IWL_UCODE_TLV_CAPA_LAR_SUPPORT = BIT(1),
IWL_UCODE_TLV_CAPA_UMAC_SCAN= BIT(2),
+ IWL_UCODE_TLV_CAPA_BEAMFORMER = BIT(3),
IWL_UCODE_TLV_CAPA_TDLS_SUPPORT = BIT(6),
IWL_UCODE_TLV_CAPA_TXPOWER_INSERTION_SUPPORT= BIT(8),
IWL_UCODE_TLV_CAPA_DS_PARAM_SET_IE_SUPPORT = BIT(9),
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h
b/drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h
index 6a2a6b0..4c33f27 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h
+++ b/drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h
@@ -308,16 +308,33 @@ enum {
#define LQ_FLAG_DYNAMIC_BW_POS 6
#define LQ_FLAG_DYNAMIC_BW_MSK (1 << LQ_FLAG_DYNAMIC_BW_POS)
-/* Single Stream Parameters
- * SS_STBC/BFER_ALLOWED - Controls whether STBC or Beamformer (BFER) is allowed
- * ucode will make a smart decision between SISO/STBC/BFER
- * SS_PARAMS_VALID - if not set ignore the ss_params field.
+/* Single Stream Tx Parameters (lq_cmd->ss_params)
+ * Flags to control a smart FW decision about whether BFER/STBC/SISO will be
+ * used for single stream Tx.
*/
-enum {
- RS_SS_STBC_ALLOWED = BIT(0),
- RS_SS_BFER_ALLOWED = BIT(1),
- RS_SS_PARAMS_VALID = BIT(31),
-};
+
+/* Bit 0-1: Max STBC streams allowed. Can be 0-3.
+ * (0) - No STBC allowed
+ * (1) - 2x1 STBC allowed (HT/VHT)
+ * (2) - 4x2 STBC allowed (HT/VHT)
+ * (3) - 3x2 STBC allowed (HT only)
+ * All our chips are at most 2 antennas so only (1) is valid for now.
+ */
+#define LQ_SS_STBC_ALLOWED_POS 0
+#define LQ_SS_STBC_ALLOWED_MSK (3 << LQ_SS_STBC_ALLOWED_MSK)
+
+/* 2x1 STBC is allowed */
+#define LQ_SS_STBC_1SS_ALLOWED (1 << LQ_SS_STBC_ALLOWED_POS)
+
+/* Bit 2: Beamformer (VHT only) is allowed */
+#define LQ_SS_BFER_ALLOWED_POS 2
+#define LQ_SS_BFER_ALLOWED (1 << LQ_SS_BFER_ALLOWED_POS)
+
+/* Bit 31: ss_params field is valid. Used for FW backward compatibility
+ * with other drivers which don't support the ss_params API yet
+ */
+#define LQ_SS_PARAMS_VALID_POS 31
+#define LQ_SS_PARAMS_VALID (1 << LQ_SS_PARAMS_VALID_POS)
/**
* struct iwl_lq_cmd - link quality command
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index cfd7bfc..51e02e6 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -401,10 +401,15 @@ int iwl_mvm_mac_setup_register(struct iwl_mvm *mvm)
if (mvm->nvm_data->bands[IEEE80211_BAND_2GHZ].n_channels)
hw->wiphy->bands[IEEE80211_BAND_2GHZ] =
&mvm->nvm_data->bands[IEEE80211_BAND_2GHZ];
- if (mvm->nvm_data->bands[IEEE80211_BAND_5GHZ].n_channels)
+ if (mvm->nvm_data->bands[IEEE80211_BAND_5GHZ].n_channels) {
hw->wiphy->bands[IEEE80211_BAND_5GHZ] =
&mvm->nvm_data->bands[IEEE80211_BAND_5GHZ];
+ if (mvm->fw->ucode_capa.capa[0] & IWL_UCODE_TLV_CAPA_BEAMFORMER)
+ hw->wiphy->bands[IEEE80211_BAND_5GHZ]->vht_cap.cap |=
+ IEEE80211_VHT_CAP_SU_BEAMFORMER_CAPABLE;
+ }
+
hw->wiphy->hw_version
[PATCH 18/19] iwlwifi: mvm: don't send a command the firmware doesn't know
-9.ucode doesn't know the command SHARED_MEM_CFG yet.
Fixes: 04fd2c28226f ("iwlwifi: mvm: add rxf and txf to dump data")
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/fw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw.c
b/drivers/net/wireless/iwlwifi/mvm/fw.c
index a322a5e..ca38e98 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/iwlwifi/mvm/fw.c
@@ -575,7 +575,8 @@ int iwl_mvm_up(struct iwl_mvm *mvm)
goto error;
}
- iwl_mvm_get_shared_mem_conf(mvm);
+ if (IWL_UCODE_API(mvm->fw->ucode_ver) >= 10)
+ iwl_mvm_get_shared_mem_conf(mvm);
ret = iwl_mvm_sf_update(mvm, NULL, false);
if (ret)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/19] iwlwifi: mvm: Enable EBS also in single scan on umac interface
From: Haim Dreyfuss Enable EBS on one shot scans if supported by FW. Signed-off-by: Haim Dreyfuss Reviewed-by: Alexander Bondar Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/iwlwifi/mvm/scan.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/wireless/iwlwifi/mvm/scan.c b/drivers/net/wireless/iwlwifi/mvm/scan.c index 4169e3d..8b74ce7 100644 --- a/drivers/net/wireless/iwlwifi/mvm/scan.c +++ b/drivers/net/wireless/iwlwifi/mvm/scan.c @@ -1863,6 +1863,13 @@ int iwl_mvm_scan_umac(struct iwl_mvm *mvm, struct ieee80211_vif *vif, flags |= IWL_UMAC_SCAN_GEN_FLAGS_PASS_ALL; cmd->general_flags = cpu_to_le32(flags); + + if (mvm->fw->ucode_capa.api[0] & IWL_UCODE_TLV_API_SINGLE_SCAN_EBS && + mvm->last_ebs_successful) + cmd->channel_flags = IWL_SCAN_CHANNEL_FLAG_EBS | +IWL_SCAN_CHANNEL_FLAG_EBS_ACCURATE | +IWL_SCAN_CHANNEL_FLAG_CACHE_ADD; + cmd->n_channels = req->req.n_channels; for (i = 0; i < req->req.n_ssids; i++) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/19] iwlwifi: mvm: enable watchdog on Tx queues for mvm
This watchdog allows to monitor the transmit queues. When a
queue doesn't progress for a too long time, a timer fires
and then, debug data can be collected.
This watchdog has never been enabled on dvm controlled
devices, so don't enable it there.
In order to have it running on mvm controlled devices, we
need to fix a small issue in the transport layer: mvm
controlled devices use the shadow registers optimization.
In this case, the watchdog wasn't running at all, even if
enabled by the module parameter. Fix that on the way.
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/dvm/main.c | 6 +-
drivers/net/wireless/iwlwifi/iwl-drv.c | 5 -
drivers/net/wireless/iwlwifi/iwl-modparams.h | 2 --
drivers/net/wireless/iwlwifi/mvm/mvm.h | 2 ++
drivers/net/wireless/iwlwifi/mvm/ops.c | 9 ++---
drivers/net/wireless/iwlwifi/pcie/tx.c | 2 +-
6 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/dvm/main.c
b/drivers/net/wireless/iwlwifi/dvm/main.c
index de43dd7..a21400c 100644
--- a/drivers/net/wireless/iwlwifi/dvm/main.c
+++ b/drivers/net/wireless/iwlwifi/dvm/main.c
@@ -1228,11 +1228,7 @@ static struct iwl_op_mode *iwl_op_mode_dvm_start(struct
iwl_trans *trans,
trans_cfg.no_reclaim_cmds = no_reclaim_cmds;
trans_cfg.n_no_reclaim_cmds = ARRAY_SIZE(no_reclaim_cmds);
trans_cfg.rx_buf_size_8k = iwlwifi_mod_params.amsdu_size_8K;
- if (!iwlwifi_mod_params.wd_disable)
- trans_cfg.queue_watchdog_timeout =
- priv->cfg->base_params->wd_timeout;
- else
- trans_cfg.queue_watchdog_timeout = IWL_WATCHDOG_DISABLED;
+ trans_cfg.queue_watchdog_timeout = IWL_WATCHDOG_DISABLED;
trans_cfg.command_names = iwl_dvm_cmd_strings;
trans_cfg.cmd_fifo = IWLAGN_CMD_FIFO_NUM;
diff --git a/drivers/net/wireless/iwlwifi/iwl-drv.c
b/drivers/net/wireless/iwlwifi/iwl-drv.c
index e7c0df6..996e7f1 100644
--- a/drivers/net/wireless/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/iwlwifi/iwl-drv.c
@@ -1367,7 +1367,6 @@ struct iwl_mod_params iwlwifi_mod_params = {
.restart_fw = true,
.bt_coex_active = true,
.power_level = IWL_POWER_INDEX_1,
- .wd_disable = true,
.d0i3_disable = true,
#ifndef CONFIG_IWLWIFI_UAPSD
.uapsd_disable = true,
@@ -1478,10 +1477,6 @@ module_param_named(antenna_coupling,
iwlwifi_mod_params.ant_coupling,
MODULE_PARM_DESC(antenna_coupling,
"specify antenna coupling in dB (default: 0 dB)");
-module_param_named(wd_disable, iwlwifi_mod_params.wd_disable, int, S_IRUGO);
-MODULE_PARM_DESC(wd_disable,
- "Disable stuck queue watchdog timer 0=system default, 1=disable
(default: 1)");
-
module_param_named(nvm_file, iwlwifi_mod_params.nvm_file, charp, S_IRUGO);
MODULE_PARM_DESC(nvm_file, "NVM file name");
diff --git a/drivers/net/wireless/iwlwifi/iwl-modparams.h
b/drivers/net/wireless/iwlwifi/iwl-modparams.h
index 2a8cf4b..e8eabd2 100644
--- a/drivers/net/wireless/iwlwifi/iwl-modparams.h
+++ b/drivers/net/wireless/iwlwifi/iwl-modparams.h
@@ -96,7 +96,6 @@ enum iwl_disable_11n {
* use IWL_[DIS,EN]ABLE_HT_* constants
* @amsdu_size_8K: enable 8K amsdu size, default = 0
* @restart_fw: restart firmware, default = 1
- * @wd_disable: disable stuck queue check, default = 1
* @bt_coex_active: enable bt coex, default = true
* @led_mode: system default, default = 0
* @power_save: enable power save, default = false
@@ -111,7 +110,6 @@ struct iwl_mod_params {
unsigned int disable_11n;
int amsdu_size_8K;
bool restart_fw;
- int wd_disable;
bool bt_coex_active;
int led_mode;
bool power_save;
diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h
b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index ed09726..4a7620c 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -119,11 +119,13 @@ extern const struct ieee80211_ops iwl_mvm_hw_ops;
* We will register to mac80211 to have testmode working. The NIC must not
* be up'ed after the INIT fw asserted. This is useful to be able to use
* proprietary tools over testmode to debug the INIT fw.
+ * @tfd_q_hang_detect: enabled the detection of hung transmit queues
* @power_scheme: CAM(Continuous Active Mode)-1, BPS(Balanced Power
* Save)-2(default), LP(Low Power)-3
*/
struct iwl_mvm_mod_params {
bool init_dbg;
+ bool tfd_q_hang_detect;
int power_scheme;
};
extern struct iwl_mvm_mod_params iwlmvm_mod_params;
diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c
b/drivers/net/wireless/iwlwifi/mvm/ops.c
index b1dea68..f801824 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -93,6 +93,7 @@ static const struct iwl_op_mode_ops iwl_mvm_ops;
struct iwl_mvm_mod_params iwlmvm_mod_params = {
.power_s
[PATCH 13/19] iwlwifi: allow to define the stuck queue timer per queue
Different queue can have different behavior. While it can be
unacceptable for a certain queue to be stuck for 2 seconds
(e.g. the command queue), it can happen that another queue
will stay stuck for even longer (a queue servicing a power
saving client in GO).
The op_mode can even make the timeout be a function of the
listen interval.
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/dvm/main.c | 3 +-
drivers/net/wireless/iwlwifi/dvm/tx.c| 2 +-
drivers/net/wireless/iwlwifi/dvm/ucode.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-config.h| 2 +-
drivers/net/wireless/iwlwifi/iwl-trans.h | 29 +++-
drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c | 10 +--
drivers/net/wireless/iwlwifi/mvm/mvm.h | 15 ++
drivers/net/wireless/iwlwifi/mvm/ops.c | 8 --
drivers/net/wireless/iwlwifi/mvm/sta.c | 15 --
drivers/net/wireless/iwlwifi/mvm/utils.c | 8 --
drivers/net/wireless/iwlwifi/pcie/internal.h | 10 +++
drivers/net/wireless/iwlwifi/pcie/trans.c| 4 +--
drivers/net/wireless/iwlwifi/pcie/tx.c | 41 +++-
13 files changed, 87 insertions(+), 62 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/dvm/main.c
b/drivers/net/wireless/iwlwifi/dvm/main.c
index a21400c..c4d6dd7 100644
--- a/drivers/net/wireless/iwlwifi/dvm/main.c
+++ b/drivers/net/wireless/iwlwifi/dvm/main.c
@@ -1228,7 +1228,8 @@ static struct iwl_op_mode *iwl_op_mode_dvm_start(struct
iwl_trans *trans,
trans_cfg.no_reclaim_cmds = no_reclaim_cmds;
trans_cfg.n_no_reclaim_cmds = ARRAY_SIZE(no_reclaim_cmds);
trans_cfg.rx_buf_size_8k = iwlwifi_mod_params.amsdu_size_8K;
- trans_cfg.queue_watchdog_timeout = IWL_WATCHDOG_DISABLED;
+ trans_cfg.cmd_q_wdg_timeout = IWL_WATCHDOG_DISABLED;
+
trans_cfg.command_names = iwl_dvm_cmd_strings;
trans_cfg.cmd_fifo = IWLAGN_CMD_FIFO_NUM;
diff --git a/drivers/net/wireless/iwlwifi/dvm/tx.c
b/drivers/net/wireless/iwlwifi/dvm/tx.c
index d1ce3ce..1e40a12 100644
--- a/drivers/net/wireless/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/dvm/tx.c
@@ -715,7 +715,7 @@ int iwlagn_tx_agg_oper(struct iwl_priv *priv, struct
ieee80211_vif *vif,
fifo = ctx->ac_to_fifo[tid_to_ac[tid]];
iwl_trans_txq_enable(priv->trans, q, fifo, sta_priv->sta_id, tid,
-buf_size, ssn);
+buf_size, ssn, 0);
/*
* If the limit is 0, then it wasn't initialised yet,
diff --git a/drivers/net/wireless/iwlwifi/dvm/ucode.c
b/drivers/net/wireless/iwlwifi/dvm/ucode.c
index d5cee15..4dbef7e 100644
--- a/drivers/net/wireless/iwlwifi/dvm/ucode.c
+++ b/drivers/net/wireless/iwlwifi/dvm/ucode.c
@@ -267,7 +267,7 @@ static int iwl_alive_notify(struct iwl_priv *priv)
for (i = 0; i < n_queues; i++)
if (queue_to_txf[i] != IWL_TX_FIFO_UNUSED)
iwl_trans_ac_txq_enable(priv->trans, i,
- queue_to_txf[i]);
+ queue_to_txf[i], 0);
priv->passive_no_rx = false;
priv->transport_queue_stop = 0;
diff --git a/drivers/net/wireless/iwlwifi/iwl-config.h
b/drivers/net/wireless/iwlwifi/iwl-config.h
index 445bff6..4b190d9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-config.h
+++ b/drivers/net/wireless/iwlwifi/iwl-config.h
@@ -126,7 +126,7 @@ enum iwl_led_mode {
/* TX queue watchdog timeouts in mSecs */
#define IWL_WATCHDOG_DISABLED 0
-#define IWL_DEF_WD_TIMEOUT 2000
+#define IWL_DEF_WD_TIMEOUT 2500
#define IWL_LONG_WD_TIMEOUT1
#define IWL_MAX_WD_TIMEOUT 12
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans.h
b/drivers/net/wireless/iwlwifi/iwl-trans.h
index 84d8477..a96bd8d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans.h
@@ -368,6 +368,7 @@ enum iwl_trans_status {
* @cmd_queue: the index of the command queue.
* Must be set before start_fw.
* @cmd_fifo: the fifo for host commands
+ * @cmd_q_wdg_timeout: the timeout of the watchdog timer for the command queue.
* @no_reclaim_cmds: Some devices erroneously don't set the
* SEQ_RX_FRAME bit on some notifications, this is the
* list of such notifications to filter. Max length is
@@ -378,8 +379,6 @@ enum iwl_trans_status {
* @bc_table_dword: set to true if the BC table expects the byte count to be
* in DWORD (as opposed to bytes)
* @scd_set_active: should the transport configure the SCD for HCMD queue
- * @queue_watchdog_timeout: time (in ms) after which queues
- * are considered stuck and will trigger device restart
* @command_names: array of command names, must be 256 entries
* (one for each command); for debugging only
* @sdio_adma_addr: the default address to set for the ADMA in SDIO mode until
@@ -390,13 +389,13 @@ struct iwl_trans_config {
[PATCH 15/19] iwlwifi: mvm: fix failure path when power_update fails in add_interface
From: Luciano Coelho
When iwl_mvm_power_update_mac() is called, we have already added the
mac context, so if this call fails we should remove the mac.
CC: [3.15+]
Fixes: commit e5e7aa8e2561 ('iwlwifi: mvm: refactor power code')
Signed-off-by: Luciano Coelho
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
index 51e02e6..1ff7ec0 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c
@@ -1355,7 +1355,7 @@ static int iwl_mvm_mac_add_interface(struct ieee80211_hw
*hw,
ret = iwl_mvm_power_update_mac(mvm);
if (ret)
- goto out_release;
+ goto out_remove_mac;
/* beacon filtering */
ret = iwl_mvm_disable_beacon_filter(mvm, vif, 0);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/19] iwlwifi: mvm: ignore stale TDLS ch-switch responses
From: Arik Nemtsov
During out-of-channel activities (e.g. scan) TDLS ch-switch responses from
a peer are kept in FW. These packets arrive only after the out-of-channel
activity is complete, which can be in the order of several seconds.
Since TDLS ch-sw has no dialog-token-like mechanism for distinguishing
sessions, use the GP2 time of the incoming ch-switch response to discern
validity. For this purpose record the GP2 time of an outgoing TDLS ch-sw
request and compare to the Rx time of the ch-sw response.
The methods works in practice since the GP2 time of FW-deferred Rx is
accurate and contains the real Rx timestamp.
Signed-off-by: Arik Nemtsov
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/mvm.h | 3 +++
drivers/net/wireless/iwlwifi/mvm/tdls.c | 15 +--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h
b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index fc80b7b..ed09726 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -798,6 +798,9 @@ struct iwl_mvm {
struct cfg80211_chan_def chandef;
struct sk_buff *skb; /* ch sw template */
u32 ch_sw_tm_ie;
+
+ /* timestamp of last ch-sw request sent (GP2 time) */
+ u32 sent_timestamp;
} peer;
} tdls_cs;
diff --git a/drivers/net/wireless/iwlwifi/mvm/tdls.c
b/drivers/net/wireless/iwlwifi/mvm/tdls.c
index ea1831c..a87b506 100644
--- a/drivers/net/wireless/iwlwifi/mvm/tdls.c
+++ b/drivers/net/wireless/iwlwifi/mvm/tdls.c
@@ -64,6 +64,8 @@
#include
#include "mvm.h"
#include "time-event.h"
+#include "iwl-io.h"
+#include "iwl-prph.h"
#define TU_TO_US(x) (x * 1024)
#define TU_TO_MS(x) (TU_TO_US(x) / 1000)
@@ -250,6 +252,11 @@ static void iwl_mvm_tdls_update_cs_state(struct iwl_mvm
*mvm,
iwl_mvm_tdls_cs_state_str(state));
mvm->tdls_cs.state = state;
+ /* we only send requests to our switching peer - update sent time */
+ if (state == IWL_MVM_TDLS_SW_REQ_SENT)
+ mvm->tdls_cs.peer.sent_timestamp =
+ iwl_read_prph(mvm->trans, DEVICE_SYSTEM_TIME_REG);
+
if (state == IWL_MVM_TDLS_SW_IDLE)
mvm->tdls_cs.cur_sta_id = IWL_MVM_STATION_COUNT;
}
@@ -302,7 +309,7 @@ out:
static int
iwl_mvm_tdls_check_action(struct iwl_mvm *mvm,
enum iwl_tdls_channel_switch_type type,
- const u8 *peer, bool peer_initiator)
+ const u8 *peer, bool peer_initiator, u32 timestamp)
{
bool same_peer = false;
int ret = 0;
@@ -341,6 +348,9 @@ iwl_mvm_tdls_check_action(struct iwl_mvm *mvm,
else if (type == TDLS_SEND_CHAN_SW_REQ)
/* wait for idle before sending another request */
ret = -EBUSY;
+ else if (timestamp <= mvm->tdls_cs.peer.sent_timestamp)
+ /* we got a stale response - ignore it */
+ ret = -EINVAL;
break;
case IWL_MVM_TDLS_SW_RESP_RCVD:
/*
@@ -399,7 +409,8 @@ iwl_mvm_tdls_config_channel_switch(struct iwl_mvm *mvm,
lockdep_assert_held(&mvm->mutex);
- ret = iwl_mvm_tdls_check_action(mvm, type, peer, peer_initiator);
+ ret = iwl_mvm_tdls_check_action(mvm, type, peer, peer_initiator,
+ timestamp);
if (ret)
return ret;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/19] iwlwifi: mvm: reduce quota threshold
From: Johannes Berg The quota threshold should be reduced to 4 to update the firmware more frequently. Signed-off-by: Johannes Berg Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/iwlwifi/mvm/constants.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/iwlwifi/mvm/constants.h b/drivers/net/wireless/iwlwifi/mvm/constants.h index d91c46b..beba375 100644 --- a/drivers/net/wireless/iwlwifi/mvm/constants.h +++ b/drivers/net/wireless/iwlwifi/mvm/constants.h @@ -99,7 +99,7 @@ #define IWL_MVM_BT_COEX_ANTENNA_COUPLING_THRS 30 #define IWL_MVM_FW_MCAST_FILTER_PASS_ALL 0 #define IWL_MVM_FW_BCAST_FILTER_PASS_ALL 0 -#define IWL_MVM_QUOTA_THRESHOLD8 +#define IWL_MVM_QUOTA_THRESHOLD4 #define IWL_MVM_RS_RSSI_BASED_INIT_RATE 0 #define IWL_MVM_RS_DISABLE_P2P_MIMO0 #define IWL_MVM_RS_NUM_TRY_BEFORE_ANT_TOGGLE1 -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/19] iwlwifi: mvm: Fix building channels in scan_config_cmd
From: Ilan Peer Use the chanel hw_value and not the center frequency when building channel array for scan_config_cmd. Signed-off-by: Ilan Peer Reviewed-by: Johannes Berg Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/iwlwifi/mvm/scan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/iwlwifi/mvm/scan.c b/drivers/net/wireless/iwlwifi/mvm/scan.c index 8b74ce7..7e9aa3c 100644 --- a/drivers/net/wireless/iwlwifi/mvm/scan.c +++ b/drivers/net/wireless/iwlwifi/mvm/scan.c @@ -1683,10 +1683,10 @@ int iwl_mvm_config_scan(struct iwl_mvm *mvm) band = &mvm->nvm_data->bands[IEEE80211_BAND_2GHZ]; for (i = 0; i < band->n_channels; i++, j++) - scan_config->channel_array[j] = band->channels[i].center_freq; + scan_config->channel_array[j] = band->channels[i].hw_value; band = &mvm->nvm_data->bands[IEEE80211_BAND_5GHZ]; for (i = 0; i < band->n_channels; i++, j++) - scan_config->channel_array[j] = band->channels[i].center_freq; + scan_config->channel_array[j] = band->channels[i].hw_value; cmd.data[0] = scan_config; cmd.len[0] = cmd_size; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/19] iwlwifi: mvm: improve TDLS ch-sw state machine
From: Arik Nemtsov
Add a response-received state and add more limits on allowed requests
in each state of the connection. Previously ch-switch requests from
other peers could interrupt an outgoing active ch-switch. Also stale
packets from the current peer could disrupt the channel switch state.
Signed-off-by: Arik Nemtsov
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/mvm.h | 1 +
drivers/net/wireless/iwlwifi/mvm/tdls.c | 48 +++--
2 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h
b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index 7773ffc..fc80b7b 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -532,6 +532,7 @@ enum {
enum iwl_mvm_tdls_cs_state {
IWL_MVM_TDLS_SW_IDLE = 0,
IWL_MVM_TDLS_SW_REQ_SENT,
+ IWL_MVM_TDLS_SW_RESP_RCVD,
IWL_MVM_TDLS_SW_REQ_RCVD,
IWL_MVM_TDLS_SW_ACTIVE,
};
diff --git a/drivers/net/wireless/iwlwifi/mvm/tdls.c
b/drivers/net/wireless/iwlwifi/mvm/tdls.c
index c0e00ba..ea1831c 100644
--- a/drivers/net/wireless/iwlwifi/mvm/tdls.c
+++ b/drivers/net/wireless/iwlwifi/mvm/tdls.c
@@ -228,6 +228,8 @@ iwl_mvm_tdls_cs_state_str(enum iwl_mvm_tdls_cs_state state)
return "IDLE";
case IWL_MVM_TDLS_SW_REQ_SENT:
return "REQ SENT";
+ case IWL_MVM_TDLS_SW_RESP_RCVD:
+ return "RESP RECEIVED";
case IWL_MVM_TDLS_SW_REQ_RCVD:
return "REQ RECEIVED";
case IWL_MVM_TDLS_SW_ACTIVE:
@@ -325,17 +327,27 @@ iwl_mvm_tdls_check_action(struct iwl_mvm *mvm,
ret = -EINVAL;
break;
case IWL_MVM_TDLS_SW_REQ_SENT:
+ /* only allow requests from the same peer */
+ if (!same_peer)
+ ret = -EBUSY;
+ else if (type == TDLS_SEND_CHAN_SW_RESP_AND_MOVE_CH &&
+!peer_initiator)
+ /*
+* We received a ch-switch request while an outgoing
+* one is pending. Allow it if the peer is the link
+* initiator.
+*/
+ ret = -EBUSY;
+ else if (type == TDLS_SEND_CHAN_SW_REQ)
+ /* wait for idle before sending another request */
+ ret = -EBUSY;
+ break;
+ case IWL_MVM_TDLS_SW_RESP_RCVD:
/*
-* We received a ch-switch request while an outgoing one is
-* pending. Allow it to proceed if the other peer is the same
-* one we sent to, and we are not the link initiator.
+* we are waiting for the FW to give an "active" notification,
+* so ignore requests in the meantime
*/
- if (type == TDLS_SEND_CHAN_SW_RESP_AND_MOVE_CH) {
- if (!same_peer)
- ret = -EBUSY;
- else if (!peer_initiator) /* we are the initiator */
- ret = -EBUSY;
- }
+ ret = -EBUSY;
break;
case IWL_MVM_TDLS_SW_REQ_RCVD:
/* as above, allow the link initiator to proceed */
@@ -349,9 +361,12 @@ iwl_mvm_tdls_check_action(struct iwl_mvm *mvm,
}
break;
case IWL_MVM_TDLS_SW_ACTIVE:
- /* we don't allow initiations during active channel switch */
- if (type == TDLS_SEND_CHAN_SW_REQ)
- ret = -EINVAL;
+ /*
+* the only valid request when active is a request to return
+* to the base channel by the current off-channel peer
+*/
+ if (type != TDLS_MOVE_CH || !same_peer)
+ ret = -EBUSY;
break;
}
@@ -473,6 +488,8 @@ iwl_mvm_tdls_config_channel_switch(struct iwl_mvm *mvm,
type == TDLS_SEND_CHAN_SW_REQ ?
IWL_MVM_TDLS_SW_REQ_SENT :
IWL_MVM_TDLS_SW_REQ_RCVD);
+ } else {
+ iwl_mvm_tdls_update_cs_state(mvm, IWL_MVM_TDLS_SW_RESP_RCVD);
}
out:
@@ -657,12 +674,15 @@ iwl_mvm_tdls_recv_channel_switch(struct ieee80211_hw *hw,
struct iwl_mvm *mvm = IWL_MAC80211_GET_MVM(hw);
enum iwl_tdls_channel_switch_type type;
unsigned int delay;
+ const char *action_str =
+ params->action_code == WLAN_TDLS_CHANNEL_SWITCH_REQUEST ?
+ "REQ" : "RESP";
mutex_lock(&mvm->mutex);
IWL_DEBUG_TDLS(mvm,
- "Received TDLS ch switch action %d from %pM status %d\n",
- params->action_code, params->sta->addr, par
[PATCH 14/19] iwlwifi: mvm: Fix a few EBS error handling bugs
From: Haim Dreyfuss
Last EBS status wasn't set to success in the initialization, which
caused the first scan to be without EBS. Fix that.
When EBS is not enabled by the driver, the FW still sends ebs_status success,
which can override EBS failure state. Consider only EBS failures, to avoid
such override. Last_ebs_success is set back to true upon disconnection.
Last_ebs_success wasn't set in umac scan abort flow, fix that too.
Signed-off-by: Haim Dreyfuss
Signed-off-by: David Spinadel
Reviewed-by: Alexander Bondar
Reviewed-by: Johannes Berg
Signed-off-by: Emmanuel Grumbach
---
drivers/net/wireless/iwlwifi/mvm/ops.c | 3 +++
drivers/net/wireless/iwlwifi/mvm/scan.c | 13 ++---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c
b/drivers/net/wireless/iwlwifi/mvm/ops.c
index b6181ef..2dffc36 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -568,6 +568,9 @@ iwl_op_mode_mvm_start(struct iwl_trans *trans, const struct
iwl_cfg *cfg,
if (!mvm->scan_cmd)
goto out_free;
+ /* Set EBS as successful as long as not stated otherwise by the FW. */
+ mvm->last_ebs_successful = true;
+
err = iwl_mvm_mac_setup_register(mvm);
if (err)
goto out_free;
diff --git a/drivers/net/wireless/iwlwifi/mvm/scan.c
b/drivers/net/wireless/iwlwifi/mvm/scan.c
index 3bd5f34..4169e3d 100644
--- a/drivers/net/wireless/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/iwlwifi/mvm/scan.c
@@ -704,7 +704,8 @@ int iwl_mvm_rx_scan_offload_complete_notif(struct iwl_mvm
*mvm,
iwl_mvm_unref(mvm, IWL_MVM_REF_SCAN);
}
- mvm->last_ebs_successful = !ebs_status;
+ if (ebs_status)
+ mvm->last_ebs_successful = false;
return 0;
}
@@ -2025,7 +2026,9 @@ int iwl_mvm_rx_umac_scan_complete_notif(struct iwl_mvm
*mvm,
notif->ebs_status == IWL_SCAN_EBS_SUCCESS ?
"success" : "failed");
- mvm->last_ebs_successful = !notif->ebs_status;
+ if (notif->ebs_status)
+ mvm->last_ebs_successful = false;
+
mvm->scan_uid[uid_idx] = 0;
if (!sched) {
@@ -2058,10 +2061,14 @@ static bool iwl_scan_umac_done_check(struct
iwl_notif_wait_data *notif_wait,
/*
* Clear scan uid of scans that was aborted from above and completed
-* in FW so the RX handler does nothing.
+* in FW so the RX handler does nothing. Set last_ebs_successful here if
+* needed.
*/
scan_done->mvm->scan_uid[uid_idx] = 0;
+ if (notif->ebs_status)
+ scan_done->mvm->last_ebs_successful = false;
+
return !iwl_mvm_find_scan_type(scan_done->mvm, scan_done->type);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
