* [PATCH 05/13] wlcore: fwlog dynamic mem_block control
From: Eliad Peller @ 2013-09-09 9:24 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1378718684-14430-1-git-send-email-eliad@wizery.com>
From: Ido Reis <idor@ti.com>
number of fwlog mem_blocks can be configured using module param.
this is a fw debug feature: in case a large fw log data is busrted during
a short period of time, the memory get filled and data is lost.
this allows us to dynamicly set the fw log mem_block usage, although
configuring more mem_block for logger comes at the expense of TP.
Signed-off-by: Yair Shapira <yair.shapira@ti.com>
Signed-off-by: Ido Reis <idor@ti.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/ti/wlcore/conf.h | 5 ++++-
drivers/net/wireless/ti/wlcore/main.c | 16 ++++++++++++++++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/conf.h b/drivers/net/wireless/ti/wlcore/conf.h
index 2b96ff8..40995c4 100644
--- a/drivers/net/wireless/ti/wlcore/conf.h
+++ b/drivers/net/wireless/ti/wlcore/conf.h
@@ -1274,6 +1274,9 @@ struct conf_rx_streaming_settings {
u8 always;
} __packed;
+#define CONF_FWLOG_MIN_MEM_BLOCKS 2
+#define CONF_FWLOG_MAX_MEM_BLOCKS 16
+
struct conf_fwlog {
/* Continuous or on-demand */
u8 mode;
@@ -1281,7 +1284,7 @@ struct conf_fwlog {
/*
* Number of memory blocks dedicated for the FW logger
*
- * Range: 1-3, or 0 to disable the FW logger
+ * Range: 2-16, or 0 to disable the FW logger
*/
u8 mem_blocks;
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index dbf3315..ebb1076 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -44,6 +44,7 @@
#define WL1271_BOOT_RETRIES 3
static char *fwlog_param;
+static int fwlog_mem_blocks = -1;
static int bug_on_recovery = -1;
static int no_recovery = -1;
@@ -291,6 +292,18 @@ static void wlcore_adjust_conf(struct wl1271 *wl)
{
/* Adjust settings according to optional module parameters */
+ /* Firmware Logger params */
+ if (fwlog_mem_blocks != -1) {
+ if (fwlog_mem_blocks >= CONF_FWLOG_MIN_MEM_BLOCKS &&
+ fwlog_mem_blocks <= CONF_FWLOG_MAX_MEM_BLOCKS) {
+ wl->conf.fwlog.mem_blocks = fwlog_mem_blocks;
+ } else {
+ wl1271_error(
+ "Illegal fwlog_mem_blocks=%d using default %d",
+ fwlog_mem_blocks, wl->conf.fwlog.mem_blocks);
+ }
+ }
+
if (fwlog_param) {
if (!strcmp(fwlog_param, "continuous")) {
wl->conf.fwlog.mode = WL12XX_FWLOG_CONTINUOUS;
@@ -6161,6 +6174,9 @@ module_param_named(fwlog, fwlog_param, charp, 0);
MODULE_PARM_DESC(fwlog,
"FW logger options: continuous, ondemand, dbgpins or disable");
+module_param(fwlog_mem_blocks, int, S_IRUSR | S_IWUSR);
+MODULE_PARM_DESC(fwlog_mem_blocks, "fwlog mem_blocks");
+
module_param(bug_on_recovery, int, S_IRUSR | S_IWUSR);
MODULE_PARM_DESC(bug_on_recovery, "BUG() on fw recovery");
--
1.8.3.rc1.35.g9b79519
^ permalink raw reply related
* [PATCH 06/13] wl12xx/wl18xx: update default fw logger's settings
From: Eliad Peller @ 2013-09-09 9:24 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1378718684-14430-1-git-send-email-eliad@wizery.com>
From: Ido Reis <idor@ti.com>
update the fw logger mode to continuous, and output to dbgpins (uart).
Signed-off-by: Ido Reis <idor@ti.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/ti/wl12xx/main.c | 4 ++--
drivers/net/wireless/ti/wl18xx/main.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
index f147e32..d94173c 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -333,11 +333,11 @@ static struct wlcore_conf wl12xx_conf = {
.always = 0,
},
.fwlog = {
- .mode = WL12XX_FWLOG_ON_DEMAND,
+ .mode = WL12XX_FWLOG_CONTINUOUS,
.mem_blocks = 2,
.severity = 0,
.timestamp = WL12XX_FWLOG_TIMESTAMP_DISABLED,
- .output = WL12XX_FWLOG_OUTPUT_HOST,
+ .output = WL12XX_FWLOG_OUTPUT_DBG_PINS,
.threshold = 0,
},
.rate = {
diff --git a/drivers/net/wireless/ti/wl18xx/main.c b/drivers/net/wireless/ti/wl18xx/main.c
index a02e0bf..aaea0cc 100644
--- a/drivers/net/wireless/ti/wl18xx/main.c
+++ b/drivers/net/wireless/ti/wl18xx/main.c
@@ -456,11 +456,11 @@ static struct wlcore_conf wl18xx_conf = {
.always = 0,
},
.fwlog = {
- .mode = WL12XX_FWLOG_ON_DEMAND,
+ .mode = WL12XX_FWLOG_CONTINUOUS,
.mem_blocks = 2,
.severity = 0,
.timestamp = WL12XX_FWLOG_TIMESTAMP_DISABLED,
- .output = WL12XX_FWLOG_OUTPUT_HOST,
+ .output = WL12XX_FWLOG_OUTPUT_DBG_PINS,
.threshold = 0,
},
.rate = {
--
1.8.3.rc1.35.g9b79519
^ permalink raw reply related
* [PATCH 07/13] wlcore/wl18xx/wl12xx: FW log params per chip arch
From: Eliad Peller @ 2013-09-09 9:24 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1378718684-14430-1-git-send-email-eliad@wizery.com>
From: Igal Chernobelsky <igalc@ti.com>
FW memory block size and FW log end marker parameters
are added to wl structure and are initialized per
chip architecture.
convert_hwaddr hw operation is added to convert chip
dependent FW internal address.
Copy from FW log is also simplified to copy the entire
memory block as FW logger utility is repsponsible
for parsing of FW log content.
Signed-off-by: Igal Chernobelsky <igalc@ti.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/ti/wl12xx/main.c | 9 +++++++
drivers/net/wireless/ti/wl18xx/main.c | 9 +++++++
drivers/net/wireless/ti/wlcore/hw_ops.h | 9 +++++++
drivers/net/wireless/ti/wlcore/io.h | 4 +--
drivers/net/wireless/ti/wlcore/main.c | 44 ++++++++++++++++++-------------
drivers/net/wireless/ti/wlcore/wlcore.h | 7 +++++
drivers/net/wireless/ti/wlcore/wlcore_i.h | 2 --
7 files changed, 61 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/ti/wl12xx/main.c b/drivers/net/wireless/ti/wl12xx/main.c
index d94173c..06b5847 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -717,6 +717,9 @@ static int wl12xx_identify_chip(struct wl1271 *wl)
goto out;
}
+ wl->fw_mem_block_size = 256;
+ wl->fwlog_end = 0x2000000;
+
/* common settings */
wl->scan_templ_id_2_4 = CMD_TEMPL_APP_PROBE_REQ_2_4_LEGACY;
wl->scan_templ_id_5 = CMD_TEMPL_APP_PROBE_REQ_5_LEGACY;
@@ -1649,6 +1652,11 @@ static bool wl12xx_lnk_low_prio(struct wl1271 *wl, u8 hlid,
return true;
}
+static u32 wl12xx_convert_hwaddr(struct wl1271 *wl, u32 hwaddr)
+{
+ return hwaddr << 5;
+}
+
static int wl12xx_setup(struct wl1271 *wl);
static struct wlcore_ops wl12xx_ops = {
@@ -1685,6 +1693,7 @@ static struct wlcore_ops wl12xx_ops = {
.channel_switch = wl12xx_cmd_channel_switch,
.pre_pkt_send = NULL,
.set_peer_cap = wl12xx_set_peer_cap,
+ .convert_hwaddr = wl12xx_convert_hwaddr,
.lnk_high_prio = wl12xx_lnk_high_prio,
.lnk_low_prio = wl12xx_lnk_low_prio,
};
diff --git a/drivers/net/wireless/ti/wl18xx/main.c b/drivers/net/wireless/ti/wl18xx/main.c
index aaea0cc..75912df 100644
--- a/drivers/net/wireless/ti/wl18xx/main.c
+++ b/drivers/net/wireless/ti/wl18xx/main.c
@@ -686,6 +686,9 @@ static int wl18xx_identify_chip(struct wl1271 *wl)
goto out;
}
+ wl->fw_mem_block_size = 272;
+ wl->fwlog_end = 0x40000000;
+
wl->scan_templ_id_2_4 = CMD_TEMPL_CFG_PROBE_REQ_2_4;
wl->scan_templ_id_5 = CMD_TEMPL_CFG_PROBE_REQ_5;
wl->sched_scan_templ_id_2_4 = CMD_TEMPL_PROBE_REQ_2_4_PERIODIC;
@@ -1603,6 +1606,11 @@ static bool wl18xx_lnk_low_prio(struct wl1271 *wl, u8 hlid,
return lnk->allocated_pkts < thold;
}
+static u32 wl18xx_convert_hwaddr(struct wl1271 *wl, u32 hwaddr)
+{
+ return hwaddr & ~0x80000000;
+}
+
static int wl18xx_setup(struct wl1271 *wl);
static struct wlcore_ops wl18xx_ops = {
@@ -1640,6 +1648,7 @@ static struct wlcore_ops wl18xx_ops = {
.pre_pkt_send = wl18xx_pre_pkt_send,
.sta_rc_update = wl18xx_sta_rc_update,
.set_peer_cap = wl18xx_set_peer_cap,
+ .convert_hwaddr = wl18xx_convert_hwaddr,
.lnk_high_prio = wl18xx_lnk_high_prio,
.lnk_low_prio = wl18xx_lnk_low_prio,
};
diff --git a/drivers/net/wireless/ti/wlcore/hw_ops.h b/drivers/net/wireless/ti/wlcore/hw_ops.h
index 7fd260c..51f8d63 100644
--- a/drivers/net/wireless/ti/wlcore/hw_ops.h
+++ b/drivers/net/wireless/ti/wlcore/hw_ops.h
@@ -222,6 +222,15 @@ wlcore_hw_set_peer_cap(struct wl1271 *wl,
return 0;
}
+static inline u32
+wlcore_hw_convert_hwaddr(struct wl1271 *wl, u32 hwaddr)
+{
+ if (!wl->ops->convert_hwaddr)
+ BUG_ON(1);
+
+ return wl->ops->convert_hwaddr(wl, hwaddr);
+}
+
static inline bool
wlcore_hw_lnk_high_prio(struct wl1271 *wl, u8 hlid,
struct wl1271_link *lnk)
diff --git a/drivers/net/wireless/ti/wlcore/io.h b/drivers/net/wireless/ti/wlcore/io.h
index af7d9f9..07e3d6a 100644
--- a/drivers/net/wireless/ti/wlcore/io.h
+++ b/drivers/net/wireless/ti/wlcore/io.h
@@ -165,8 +165,8 @@ static inline int __must_check wlcore_read_hwaddr(struct wl1271 *wl, int hwaddr,
int physical;
int addr;
- /* Addresses are stored internally as addresses to 32 bytes blocks */
- addr = hwaddr << 5;
+ /* Convert from FW internal address which is chip arch dependent */
+ addr = wl->ops->convert_hwaddr(wl, hwaddr);
physical = wlcore_translate_addr(wl, addr);
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index ebb1076..58800ab 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -800,19 +800,10 @@ void wl12xx_queue_recovery_work(struct wl1271 *wl)
size_t wl12xx_copy_fwlog(struct wl1271 *wl, u8 *memblock, size_t maxlen)
{
- size_t len = 0;
-
- /* The FW log is a length-value list, find where the log end */
- while (len < maxlen) {
- if (memblock[len] == 0)
- break;
- if (len + memblock[len] + 1 > maxlen)
- break;
- len += memblock[len] + 1;
- }
+ size_t len;
/* Make sure we have enough room */
- len = min(len, (size_t)(PAGE_SIZE - wl->fwlog_size));
+ len = min(maxlen, (size_t)(PAGE_SIZE - wl->fwlog_size));
/* Fill the FW log file, consumed by the sysfs fwlog entry */
memcpy(wl->fwlog + wl->fwlog_size, memblock, len);
@@ -821,10 +812,9 @@ size_t wl12xx_copy_fwlog(struct wl1271 *wl, u8 *memblock, size_t maxlen)
return len;
}
-#define WLCORE_FW_LOG_END 0x2000000
-
static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
{
+ struct wlcore_partition_set part, old_part;
u32 addr;
u32 offset;
u32 end_of_log;
@@ -837,7 +827,7 @@ static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
wl1271_info("Reading FW panic log");
- block = kmalloc(WL12XX_HW_BLOCK_SIZE, GFP_KERNEL);
+ block = kmalloc(wl->fw_mem_block_size, GFP_KERNEL);
if (!block)
return;
@@ -863,17 +853,31 @@ static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
if (wl->conf.fwlog.mode == WL12XX_FWLOG_CONTINUOUS) {
offset = sizeof(addr) + sizeof(struct wl1271_rx_descriptor);
- end_of_log = WLCORE_FW_LOG_END;
+ end_of_log = wl->fwlog_end;
} else {
offset = sizeof(addr);
end_of_log = addr;
}
+ old_part = wl->curr_part;
+ memset(&part, 0, sizeof(part));
+
/* Traverse the memory blocks linked list */
do {
- memset(block, 0, WL12XX_HW_BLOCK_SIZE);
- ret = wlcore_read_hwaddr(wl, addr, block, WL12XX_HW_BLOCK_SIZE,
- false);
+ part.mem.start = wlcore_hw_convert_hwaddr(wl, addr);
+ part.mem.size = PAGE_SIZE;
+
+ ret = wlcore_set_partition(wl, &part);
+ if (ret < 0) {
+ wl1271_error("%s: set_partition start=0x%X size=%d",
+ __func__, part.mem.start, part.mem.size);
+ goto out;
+ }
+
+ memset(block, 0, wl->fw_mem_block_size);
+ ret = wlcore_read_hwaddr(wl, addr, block,
+ wl->fw_mem_block_size, false);
+
if (ret < 0)
goto out;
@@ -884,8 +888,9 @@ static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
* on demand mode and is equal to 0x2000000 in continuous mode.
*/
addr = le32_to_cpup((__le32 *)block);
+
if (!wl12xx_copy_fwlog(wl, block + offset,
- WL12XX_HW_BLOCK_SIZE - offset))
+ wl->fw_mem_block_size - offset))
break;
} while (addr && (addr != end_of_log));
@@ -893,6 +898,7 @@ static void wl12xx_read_fwlog_panic(struct wl1271 *wl)
out:
kfree(block);
+ wlcore_set_partition(wl, &old_part);
}
static void wlcore_print_recovery(struct wl1271 *wl)
diff --git a/drivers/net/wireless/ti/wlcore/wlcore.h b/drivers/net/wireless/ti/wlcore/wlcore.h
index f927222..06efc12 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore.h
@@ -110,6 +110,7 @@ struct wlcore_ops {
struct ieee80211_sta_ht_cap *ht_cap,
bool allow_ht_operation,
u32 rate_set, u8 hlid);
+ u32 (*convert_hwaddr)(struct wl1271 *wl, u32 hwaddr);
bool (*lnk_high_prio)(struct wl1271 *wl, u8 hlid,
struct wl1271_link *lnk);
bool (*lnk_low_prio)(struct wl1271 *wl, u8 hlid,
@@ -290,6 +291,12 @@ struct wl1271 {
/* Number of valid bytes in the FW log buffer */
ssize_t fwlog_size;
+ /* FW log end marker */
+ u32 fwlog_end;
+
+ /* FW memory block size */
+ u32 fw_mem_block_size;
+
/* Sysfs FW log entry readers wait queue */
wait_queue_head_t fwlog_waitq;
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index 2a50e08..ce7261c 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -550,6 +550,4 @@ void wl1271_rx_filter_flatten_fields(struct wl12xx_rx_filter *filter,
#define HW_HT_RATES_OFFSET 16
#define HW_MIMO_RATES_OFFSET 24
-#define WL12XX_HW_BLOCK_SIZE 256
-
#endif /* __WLCORE_I_H__ */
--
1.8.3.rc1.35.g9b79519
^ permalink raw reply related
* [PATCH 08/13] wlcore: read fw panic log only in host mode
From: Eliad Peller @ 2013-09-09 9:24 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1378718684-14430-1-git-send-email-eliad@wizery.com>
From: Barak Bercovitz <barak@wizery.com>
Reading FW panic log is only supported in host mode (SDIO)
Signed-off-by: Barak Bercovitz <barak@wizery.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/ti/wlcore/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 58800ab..8639ea9 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -943,7 +943,8 @@ static void wl1271_recovery_work(struct work_struct *work)
goto out_unlock;
if (!test_bit(WL1271_FLAG_INTENDED_FW_RECOVERY, &wl->flags)) {
- wl12xx_read_fwlog_panic(wl);
+ if (wl->conf.fwlog.output == WL12XX_FWLOG_OUTPUT_HOST)
+ wl12xx_read_fwlog_panic(wl);
wlcore_print_recovery(wl);
}
--
1.8.3.rc1.35.g9b79519
^ permalink raw reply related
* [PATCH 09/13] wlcore: Allow stopping fw log in recovery
From: Eliad Peller @ 2013-09-09 9:24 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1378718684-14430-1-git-send-email-eliad@wizery.com>
From: Barak Bercovitz <barak@wizery.com>
The FW panic log is read during recovery work.
It has to be stopped properly before reading. otherwise,
inconsistent data might be read which cause the driver
to freeze.
__wlcore_cmd_send has to work for the special case of
CMD_STOP_FWLOGGER, while in recovery, in order to stop
the fw log before it is read.
Signed-off-by: Barak Bercovitz <barak@wizery.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/ti/wlcore/cmd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/cmd.c b/drivers/net/wireless/ti/wlcore/cmd.c
index f6a3d7d..8c8dfa3 100644
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -60,7 +60,8 @@ static int __wlcore_cmd_send(struct wl1271 *wl, u16 id, void *buf,
u16 status;
u16 poll_count = 0;
- if (WARN_ON(unlikely(wl->state == WLCORE_STATE_RESTARTING)))
+ if (WARN_ON(wl->state == WLCORE_STATE_RESTARTING &&
+ id != CMD_STOP_FWLOGGER))
return -EIO;
cmd = buf;
--
1.8.3.rc1.35.g9b79519
^ permalink raw reply related
* [PATCH 10/13] wlcore: wakeup from ELP before starting recovery
From: Eliad Peller @ 2013-09-09 9:24 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1378718684-14430-1-git-send-email-eliad@wizery.com>
From: Barak Bercovitz <barak@wizery.com>
Make sure the FW is awake when entering recovery. This is useful for
reading the FW panic log and also some FW registers giving us crash
report stats.
We must do this before interrupts are disabled since we rely on an
interrupt to complete the wakeup.
If the wakeup fails, continue recovery normally. All read/writes will be
blocked and won't do any harm.
Signed-off-by: Barak Bercovitz <barak@wizery.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/ti/wlcore/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 8639ea9..60b2113 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -793,6 +793,7 @@ void wl12xx_queue_recovery_work(struct wl1271 *wl)
if (wl->state == WLCORE_STATE_ON) {
wl->state = WLCORE_STATE_RESTARTING;
set_bit(WL1271_FLAG_RECOVERY_IN_PROGRESS, &wl->flags);
+ wl1271_ps_elp_wakeup(wl);
wlcore_disable_interrupts_nosync(wl);
ieee80211_queue_work(wl->hw, &wl->recovery_work);
}
--
1.8.3.rc1.35.g9b79519
^ permalink raw reply related
* [PATCH 11/13] wlcore: memset wl->rx_filter_enabled to zero after recovery
From: Eliad Peller @ 2013-09-09 9:24 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1378718684-14430-1-git-send-email-eliad@wizery.com>
From: Nadim Zubidat <nadimz@ti.com>
zero rx_filter_enabled array after recovery to avoid
cases were the driver will keep trying to clear a
filter which is not configured in FW.
Such case will cause consecutive recoveries due to
command execution failures.
Signed-off-by: Nadim Zubidat <nadimz@ti.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/ti/wlcore/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 60b2113..acb3502 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -1915,6 +1915,7 @@ static void wlcore_op_stop_locked(struct wl1271 *wl)
memset(wl->links_map, 0, sizeof(wl->links_map));
memset(wl->roc_map, 0, sizeof(wl->roc_map));
memset(wl->session_ids, 0, sizeof(wl->session_ids));
+ memset(wl->rx_filter_enabled, 0, sizeof(wl->rx_filter_enabled));
wl->active_sta_count = 0;
wl->active_link_count = 0;
--
1.8.3.rc1.35.g9b79519
^ permalink raw reply related
* [PATCH 12/13] wlcore: fix started_vifs calculation
From: Eliad Peller @ 2013-09-09 9:24 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1378718684-14430-1-git-send-email-eliad@wizery.com>
wlcore configures different dwell times according to number
of active interfaces (in order to prevent hurting VO during
scan).
However, determining active vif only according to
bss_conf->idle is not explicit enough, and might result
in non-started vifs being counted as started as well
(e.g. unassociated sta during sta).
Fix it by checking for explicit conditions according
to the vif type.
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/ti/wlcore/scan.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/scan.c b/drivers/net/wireless/ti/wlcore/scan.c
index bbe0bc4..867e64b 100644
--- a/drivers/net/wireless/ti/wlcore/scan.c
+++ b/drivers/net/wireless/ti/wlcore/scan.c
@@ -92,9 +92,31 @@ out:
static void wlcore_started_vifs_iter(void *data, u8 *mac,
struct ieee80211_vif *vif)
{
+ struct wl12xx_vif *wlvif = wl12xx_vif_to_data(vif);
+ bool active = false;
int *count = (int *)data;
- if (!vif->bss_conf.idle)
+ /*
+ * count active interfaces according to interface type.
+ * checking only bss_conf.idle is bad for some cases, e.g.
+ * we don't want to count sta in p2p_find as active interface.
+ */
+ switch (wlvif->bss_type) {
+ case BSS_TYPE_STA_BSS:
+ if (test_bit(WLVIF_FLAG_STA_ASSOCIATED, &wlvif->flags))
+ active = true;
+ break;
+
+ case BSS_TYPE_AP_BSS:
+ if (wlvif->wl->active_sta_count > 0)
+ active = true;
+ break;
+
+ default:
+ break;
+ }
+
+ if (active)
(*count)++;
}
--
1.8.3.rc1.35.g9b79519
^ permalink raw reply related
* [PATCH 13/13] wlcore: save last regdom configuration on stop
From: Eliad Peller @ 2013-09-09 9:24 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1378718684-14430-1-git-send-email-eliad@wizery.com>
In order to reconfigure the correct reg domain on
recovery, we have to save the current configuration
before clearing it (wl->reg_ch_conf_pending is
considered before configuring a new regdomain).
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
drivers/net/wireless/ti/wlcore/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index acb3502..657b9eb 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -1950,8 +1950,10 @@ static void wlcore_op_stop_locked(struct wl1271 *wl)
/*
* FW channels must be re-calibrated after recovery,
- * clear the last Reg-Domain channel configuration.
+ * save current Reg-Domain channel configuration and clear it.
*/
+ memcpy(wl->reg_ch_conf_pending, wl->reg_ch_conf_last,
+ sizeof(wl->reg_ch_conf_pending));
memset(wl->reg_ch_conf_last, 0, sizeof(wl->reg_ch_conf_last));
}
--
1.8.3.rc1.35.g9b79519
^ permalink raw reply related
* [PATCH 2/2] rt2800: comment enable radio initialization sequence
From: Stanislaw Gruszka @ 2013-09-09 10:37 UTC (permalink / raw)
To: linux-wireless; +Cc: users
In-Reply-To: <1378723058-7858-1-git-send-email-sgruszka@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 8f6820a..959f94f 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6625,17 +6625,20 @@ int rt2800_enable_radio(struct rt2x00_dev *rt2x00dev)
u16 word;
/*
- * Initialize all registers.
+ * Initialize MAC registers.
*/
if (unlikely(rt2800_wait_wpdma_ready(rt2x00dev) ||
rt2800_init_registers(rt2x00dev)))
return -EIO;
+ /*
+ * Wait BBP/RF to wake up.
+ */
if (unlikely(rt2800_wait_bbp_rf_ready(rt2x00dev)))
return -EIO;
/*
- * Send signal to firmware during boot time.
+ * Send signal during boot time to initialize firmware.
*/
rt2800_register_write(rt2x00dev, H2M_BBP_AGENT, 0);
rt2800_register_write(rt2x00dev, H2M_MAILBOX_CSR, 0);
@@ -6644,9 +6647,15 @@ int rt2800_enable_radio(struct rt2x00_dev *rt2x00dev)
rt2800_mcu_request(rt2x00dev, MCU_BOOT_SIGNAL, 0, 0, 0);
msleep(1);
+ /*
+ * Make sure BBP is up and running.
+ */
if (unlikely(rt2800_wait_bbp_ready(rt2x00dev)))
return -EIO;
+ /*
+ * Initialize BBP/RF registers.
+ */
rt2800_init_bbp(rt2x00dev);
rt2800_init_rfcsr(rt2x00dev);
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/2] rt2800: change initialization sequence to fix system freeze
From: Stanislaw Gruszka @ 2013-09-09 10:37 UTC (permalink / raw)
To: linux-wireless; +Cc: users
My commit
commit c630ccf1a127578421a928489d51e99c05037054
Author: Stanislaw Gruszka <stf_xl@wp.pl>
Date: Sat Mar 16 19:19:46 2013 +0100
rt2800: rearrange bbp/rfcsr initialization
make Maxim machine freeze when try to start wireless device.
Initialization order and sending MCU_BOOT_SIGNAL request, changed in
above commit, is important. Doing things incorrectly make PCIe bus
problems, which can froze the machine.
This patch change initialization sequence like vendor driver do:
function NICInitializeAsic() from
2011_1007_RT5390_RT5392_Linux_STA_V2.5.0.3_DPO (PCI devices) and
DPO_RT5572_LinuxSTA_2.6.1.3_20121022 (according Mediatek, latest driver
for RT8070/RT3070/RT3370/RT3572/RT5370/RT5372/RT5572 USB devices).
It fixes freezes on Maxim system.
Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=1000679
Reported-and-tested-by: Maxim Polyakov <polyakov@dexmalabs.com>
Bisected-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Cc: stable@vger.kernel.org # 3.10+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index d217c9e..8f6820a 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6631,19 +6631,20 @@ int rt2800_enable_radio(struct rt2x00_dev *rt2x00dev)
rt2800_init_registers(rt2x00dev)))
return -EIO;
+ if (unlikely(rt2800_wait_bbp_rf_ready(rt2x00dev)))
+ return -EIO;
+
/*
* Send signal to firmware during boot time.
*/
rt2800_register_write(rt2x00dev, H2M_BBP_AGENT, 0);
rt2800_register_write(rt2x00dev, H2M_MAILBOX_CSR, 0);
- if (rt2x00_is_usb(rt2x00dev)) {
+ if (rt2x00_is_usb(rt2x00dev))
rt2800_register_write(rt2x00dev, H2M_INT_SRC, 0);
- rt2800_mcu_request(rt2x00dev, MCU_BOOT_SIGNAL, 0, 0, 0);
- }
+ rt2800_mcu_request(rt2x00dev, MCU_BOOT_SIGNAL, 0, 0, 0);
msleep(1);
- if (unlikely(rt2800_wait_bbp_rf_ready(rt2x00dev) ||
- rt2800_wait_bbp_ready(rt2x00dev)))
+ if (unlikely(rt2800_wait_bbp_ready(rt2x00dev)))
return -EIO;
rt2800_init_bbp(rt2x00dev);
--
1.7.11.7
^ permalink raw reply related
* Re: RTL8192CU continually reconnecting
From: Mark Cave-Ayland @ 2013-09-09 14:16 UTC (permalink / raw)
To: Larry Finger; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522D054B.5060205@lwfinger.net>
On 09/09/13 00:16, Larry Finger wrote:
> On 09/08/2013 06:53 AM, Timothy Rundle wrote:
>> My TL-WN821N with a RTL8192CU chipsets fails to stay connected. It
>> appears to be disconnecting every 5-10 seconds. Since the issue
>> happens with the mainline kernel, the downstream maintainer ask me to
>> post here. Here is a section of my kernel log:
>
> This problem has been reported before; however, I cannot duplicate it on
> my openSUSE KDE system that controls the wireless using NetworkManager.
Yes, this sounds like exactly the same problem that I reported a couple
of weeks ago. Note that I see the issue invoking wpa_supplicant manually
rather than using NetworkManager, so I don't think that this is part of
the problem.
I can also clarify that if I remove *all* entries from
wpa_supplicant.conf except for the one AP I'm trying to associate with,
then I can generally get an initial association within about 30-60s.
However I still repeatedly see drop-outs every 30s or so.
> When taking another look at the code, I realized that rtl8192cu has
> duplicated a routine that is found in rtlwifi. The attached patch
> implements that change. Please try it and report back. I don't expect it
> to do much good as your problem appears to be a bad interaction with the
> Ubuntu front-end to wireless.
I've just tried the attached patch, and while it applies cleanly, I see
no change in behaviour in that I keep associating/deassociating from the
AP :(
Larry, did those traces I sent you off-list help at all? I'm also happy
to test patches that include more verbose debugging information in order
to help further with this.
Also I notice that Debian Wheezy includes a slightly older version of
wpa_supplicant:
# wpa_supplicant -v
wpa_supplicant v1.0
Copyright (c) 2003-2012, Jouni Malinen <j@w1.fi> and contributors
I could try building directly from source 1.1 and/or 2.0 if you think
that would help too? Perhaps some internal Debian patches are having an
effect here?
ATB,
Mark.
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Larry Finger @ 2013-09-09 14:57 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522DD856.7050309@ilande.co.uk>
On 09/09/2013 09:16 AM, Mark Cave-Ayland wrote:
> On 09/09/13 00:16, Larry Finger wrote:
>
>> On 09/08/2013 06:53 AM, Timothy Rundle wrote:
>>> My TL-WN821N with a RTL8192CU chipsets fails to stay connected. It
>>> appears to be disconnecting every 5-10 seconds. Since the issue
>>> happens with the mainline kernel, the downstream maintainer ask me to
>>> post here. Here is a section of my kernel log:
>>
>> This problem has been reported before; however, I cannot duplicate it on
>> my openSUSE KDE system that controls the wireless using NetworkManager.
>
> Yes, this sounds like exactly the same problem that I reported a couple of weeks
> ago. Note that I see the issue invoking wpa_supplicant manually rather than
> using NetworkManager, so I don't think that this is part of the problem.
>
> I can also clarify that if I remove *all* entries from wpa_supplicant.conf
> except for the one AP I'm trying to associate with, then I can generally get an
> initial association within about 30-60s. However I still repeatedly see
> drop-outs every 30s or so.
I think your user space is exactly the problem. As I am writing this, my device,
which lsusb reports as "ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
802.11n Wireless Adapter [Realtek RTL8188CUS]" has been up for a little over 20
hours. During that time, there have been 23 deauthentications for reason 7, but
0 of the "connection to AP lost" variety.
My system is running version 1.1 of wpa_supplicant, 0.9.6.4 of NetworkManager,
and 0.9.0.7 of the KDE applet.
None of my wireless connections are made automatically. When I select a
particular AP from the KDE applet, it is roughly 2 seconds until the interface
has gotten an IP and reports its state as connected.
I will switch my system from NM to manual control to see what happens.
Larry
^ permalink raw reply
* [PATCH] mac80211: improve default WMM parameter setting
From: Fred Zhou @ 2013-09-09 15:03 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Fred Zhou
Move the default setting for WMM parameters outside the for loop
to avoid redundant assignment multiple times.
Signed-off-by: Fred Zhou <fred.zy@gmail.com>
---
net/mac80211/util.c | 29 +++++++++++++++--------------
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index e1b34a1..16bdd15 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1007,14 +1007,21 @@ void ieee80211_set_wmm_default(struct ieee80211_sub_if_data *sdata,
*/
enable_qos = (sdata->vif.type != NL80211_IFTYPE_STATION);
+ /* Set defaults according to 802.11-2007 Table 7-37 */
+ aCWmax = 1023;
+ if (use_11b)
+ aCWmin = 31;
+ else
+ aCWmin = 15;
+
+ /* Confiure old 802.11b/g medium access rules. */
+ qparam.cw_max = aCWmax;
+ qparam.cw_min = aCWmin;
+ qparam.txop = 0;
+ qparam.aifs = 2;
+
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
- /* Set defaults according to 802.11-2007 Table 7-37 */
- aCWmax = 1023;
- if (use_11b)
- aCWmin = 31;
- else
- aCWmin = 15;
-
+ /* Update if QoS is enabled. */
if (enable_qos) {
switch (ac) {
case IEEE80211_AC_BK:
@@ -1050,13 +1057,7 @@ void ieee80211_set_wmm_default(struct ieee80211_sub_if_data *sdata,
qparam.aifs = 2;
break;
}
- } else {
- /* Confiure old 802.11b/g medium access rules. */
- qparam.cw_max = aCWmax;
- qparam.cw_min = aCWmin;
- qparam.txop = 0;
- qparam.aifs = 2;
- }
+ }
qparam.uapsd = false;
--
1.7.9.5
^ permalink raw reply related
* Re: RTL8192CU continually reconnecting
From: Oleksij Rempel @ 2013-09-09 15:08 UTC (permalink / raw)
To: Larry Finger; +Cc: Mark Cave-Ayland, Timothy Rundle, linux-wireless
In-Reply-To: <522DE1BE.6070904@lwfinger.net>
Am 09.09.2013 16:57, schrieb Larry Finger:
> On 09/09/2013 09:16 AM, Mark Cave-Ayland wrote:
>> On 09/09/13 00:16, Larry Finger wrote:
>>
>>> On 09/08/2013 06:53 AM, Timothy Rundle wrote:
>>>> My TL-WN821N with a RTL8192CU chipsets fails to stay connected. It
>>>> appears to be disconnecting every 5-10 seconds. Since the issue
>>>> happens with the mainline kernel, the downstream maintainer ask me to
>>>> post here. Here is a section of my kernel log:
>>>
>>> This problem has been reported before; however, I cannot duplicate it on
>>> my openSUSE KDE system that controls the wireless using NetworkManager.
>>
>> Yes, this sounds like exactly the same problem that I reported a
>> couple of weeks
>> ago. Note that I see the issue invoking wpa_supplicant manually rather
>> than
>> using NetworkManager, so I don't think that this is part of the problem.
>>
>> I can also clarify that if I remove *all* entries from
>> wpa_supplicant.conf
>> except for the one AP I'm trying to associate with, then I can
>> generally get an
>> initial association within about 30-60s. However I still repeatedly see
>> drop-outs every 30s or so.
>
> I think your user space is exactly the problem. As I am writing this, my
> device, which lsusb reports as "ID 7392:7811 Edimax Technology Co., Ltd
> EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]" has been up for
> a little over 20 hours. During that time, there have been 23
> deauthentications for reason 7, but 0 of the "connection to AP lost"
> variety.
>
> My system is running version 1.1 of wpa_supplicant, 0.9.6.4 of
> NetworkManager, and 0.9.0.7 of the KDE applet.
>
> None of my wireless connections are made automatically. When I select a
> particular AP from the KDE applet, it is roughly 2 seconds until the
> interface has gotten an IP and reports its state as connected.
>
> I will switch my system from NM to manual control to see what happens.
>
> Larry
Just in case:
There can be some usb issue. At least i need to fight right now with
some of them on ath9k_htc.
--
Regards,
Oleksij
^ permalink raw reply
* Re: [PATCH] mac80211: do not check duplicate IEs when parsing elements.
From: Johannes Berg @ 2013-09-09 15:11 UTC (permalink / raw)
To: Fred Zhou; +Cc: linux-wireless
In-Reply-To: <1378698114-18930-1-git-send-email-fred.zy@gmail.com>
On Mon, 2013-09-09 at 11:41 +0800, Fred Zhou wrote:
> The 802.11 standard does not prevent the same IE to be
> included in one frame (e.g. beacon) multiple times.
Actually, it does say that the IEs must be in a given order, with
exactly the IEs (except for the ones that are allowed multiple times
etc.)
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: Pass station supported channel and oper class info to kernel
From: Johannes Berg @ 2013-09-09 15:12 UTC (permalink / raw)
To: Sunil Dutt; +Cc: Sunil Dutt, linux-wireless, j, Deepak (QCA), Ashwani
In-Reply-To: <CACA4iOrhMhksNV78VUafCyw=Jeu++LV4BO5StQD4oVgARPCbfQ@mail.gmail.com>
On Sun, 2013-09-08 at 12:02 +0530, Sunil Dutt wrote:
> Hi Johannes,
> Can you please help in reviewing the patch and upstream the same.
Don't get impatient. The merge window is open, so there's no reason for
me to be applying patches.
johannes
^ permalink raw reply
* Re: RTL8192CU continually reconnecting
From: Mark Cave-Ayland @ 2013-09-09 15:27 UTC (permalink / raw)
To: Larry Finger; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522DE1BE.6070904@lwfinger.net>
On 09/09/13 15:57, Larry Finger wrote:
> I think your user space is exactly the problem. As I am writing this, my
> device, which lsusb reports as "ID 7392:7811 Edimax Technology Co., Ltd
> EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]" has been up for
> a little over 20 hours. During that time, there have been 23
> deauthentications for reason 7, but 0 of the "connection to AP lost"
> variety.
I've just tried building wpa_supplicant 2.0 from source and it sadly
doesn't make any difference here.
I do still however see the following in dmesg output:
rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now
Briefly looking through the code in rtlwifi/base.c I see that the
watchdog message above is triggered by the condition
(rtlpriv->link_info.bcn_rx_inperiod +
rtlpriv->link_info.num_rx_inperiod) == 0).
The bcn_rx_inperiod value is only incremented by rtl_beacon_statistic()
in base.c, which is in turn called from _rtl_usb_rx_process_noagg() (but
not _rtl_usb_rx_process_agg() for some reason?). Shall I try adding some
debugging printk() statements in there to get a feel for what is going
on? Or would it be better to attempt a trace with debug=0x5?
> My system is running version 1.1 of wpa_supplicant, 0.9.6.4 of
> NetworkManager, and 0.9.0.7 of the KDE applet.
>
> None of my wireless connections are made automatically. When I select a
> particular AP from the KDE applet, it is roughly 2 seconds until the
> interface has gotten an IP and reports its state as connected.
>
> I will switch my system from NM to manual control to see what happens.
Interesting. Did it make any difference in the end?
ATB,
Mark.
^ permalink raw reply
* [PATCH] ath10k: define ath10k_debug_start/_stop as static inline
From: Bartosz Markowski @ 2013-09-09 15:50 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Bartosz Markowski
Otherwise if CONFIG_ATH10K_DEBUGFS won't be set we will
end up with multiple definitions and compilation failure
in each place the header is included.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
---
drivers/net/wireless/ath/ath10k/debug.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 9c442a8..376a56b 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -52,12 +52,12 @@ void ath10k_debug_read_target_stats(struct ath10k *ar,
struct wmi_stats_event *ev);
#else
-int ath10k_debug_start(struct ath10k *ar)
+static inline int ath10k_debug_start(struct ath10k *ar)
{
return 0;
}
-void ath10k_debug_stop(struct ath10k *ar)
+static inline void ath10k_debug_stop(struct ath10k *ar)
{
}
--
1.7.10
^ permalink raw reply related
* Re: RTL8192CU continually reconnecting
From: Larry Finger @ 2013-09-09 17:04 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522DE8CA.9010008@ilande.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]
On 09/09/2013 10:27 AM, Mark Cave-Ayland wrote:
> On 09/09/13 15:57, Larry Finger wrote:
>
>> I think your user space is exactly the problem. As I am writing this, my
>> device, which lsusb reports as "ID 7392:7811 Edimax Technology Co., Ltd
>> EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]" has been up for
>> a little over 20 hours. During that time, there have been 23
>> deauthentications for reason 7, but 0 of the "connection to AP lost"
>> variety.
>
> I've just tried building wpa_supplicant 2.0 from source and it sadly doesn't
> make any difference here.
>
> I do still however see the following in dmesg output:
>
> rtlwifi:rtl_watchdog_wq_callback():<0-0> AP off, try to reconnect now
>
> Briefly looking through the code in rtlwifi/base.c I see that the watchdog
> message above is triggered by the condition (rtlpriv->link_info.bcn_rx_inperiod
> + rtlpriv->link_info.num_rx_inperiod) == 0).
>
> The bcn_rx_inperiod value is only incremented by rtl_beacon_statistic() in
> base.c, which is in turn called from _rtl_usb_rx_process_noagg() (but not
> _rtl_usb_rx_process_agg() for some reason?). Shall I try adding some debugging
> printk() statements in there to get a feel for what is going on? Or would it be
> better to attempt a trace with debug=0x5?
Debug level 5 will inundate you with so much info that you will not get much
feeling for the results. Even the Realtek engineers never ask for level 5. Try
the attached patch. That will let us know if rtl_beacon_statistic() is being
called, and what parameters it is getting.
I have added the call to rtl_beacon_statistic() to _rtl_usb_rx_process_agg(),
which should be the routine used in my connection to an AP using WPA2, which
allows aggregation. As I write this, the revised driver has been running for
only 1800 seconds, but I have not seen any of the "AP off" messages.
>> I will switch my system from NM to manual control to see what happens.
>
> Interesting. Did it make any difference in the end?
In 3 hours, it made no difference.
Larry
[-- Attachment #2: rtl8192cu_dump_AP_off --]
[-- Type: text/plain, Size: 1235 bytes --]
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/base.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/base.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/base.c
@@ -1287,7 +1287,13 @@ void rtl_beacon_statistic(struct ieee802
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+ static int count;
+ if (count++ < 100) {
+ pr_info("mode %d, state %d, is_beacon %d, is_probe_resp %d, length %d, MAC %pM\n",
+ rtlpriv->mac80211.opmode, rtlpriv->mac80211.link_state, ieee80211_is_beacon(hdr->frame_control),
+ ieee80211_is_probe_resp(hdr->frame_control), skb->len, hdr->addr3);
+ }
if (rtlpriv->mac80211.opmode != NL80211_IFTYPE_STATION)
return;
diff --git a/drivers/net/wireless/rtlwifi/usb.c b/drivers/net/wireless/rtlwifi/usb.c
index e56778c..ba9844a 100644
--- a/drivers/net/wireless/rtlwifi/usb.c
+++ b/drivers/net/wireless/rtlwifi/usb.c
@@ -484,6 +484,8 @@ static void _rtl_usb_rx_process_agg(struct ieee80211_hw *hw,
if (unicast)
rtlpriv->link_info.num_rx_inperiod++;
}
+ /* static bcn for roaming */
+ rtl_beacon_statistic(hw, skb);
}
}
^ permalink raw reply related
* Re: [PATCH 1/2] cw1200: Don't perform SPI transfers in interrupt context
From: John W. Linville @ 2013-09-09 18:33 UTC (permalink / raw)
To: Solomon Peachy; +Cc: linux-wireless
In-Reply-To: <20130903115856.GA16844@shaftnet.org>
On Tue, Sep 03, 2013 at 07:58:57AM -0400, Solomon Peachy wrote:
> On Tue, Aug 27, 2013 at 08:29:46PM -0400, Solomon Peachy wrote:
> > When we get an interrupt from the hardware, the first thing the driver does
> > is tell the device to mask off the interrupt line. Unfortunately this
> > involves a SPI transaction in interrupt context. Some (most?) SPI
> > controllers perform the transfer asynchronously and try to sleep.
> > This is bad, and triggers a BUG().
>
> Did this patch series get dropped? I saw that the followup series
> of minor cleanups were merged into wireless-next, but not these.
>
> Since they didn't make it into 3.11, I intend to submit them to -stable,
> but I need to make sure they at least make it into -next.
I'll be sending them for 3.12 soon...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Specifying priority for management frames?
From: Ben Greear @ 2013-09-09 18:52 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <5228CAB6.5060308@candelatech.com>
On 09/05/2013 11:17 AM, Ben Greear wrote:
> While debugging a problem with group-rekeys, we noticed that the sniffer (on external machine)
> reported management packets are sent in the best-effort QoS queue.
>
> It seems to me that these should be in the VO queue instead, or at least
> we should be able to specify the queue in supplicant when sending the frames?
This is a problem in supplicant/hostapd. They were not setting the socket
priority to (256 + 7) as they should have been doing. With that fix, packets
on the air show the proper 'VO' QoS queue.
I posted patches to fix supplicant/hostapd to the hostapd mailing list.
Hopefully they are proper patches...at least they seem to work for me.
At least the hostapd side of this seemed to slip in with the addition
of the new non-monitor eapol tx status feature.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] ar5523: Add USB ID of D-Link WUA-2340 rev A1
From: Albert Pool @ 2013-09-09 18:36 UTC (permalink / raw)
To: Pontus Fuchs, linux-wireless, linux-kernel; +Cc: Albert Pool
Signed-off-by: Albert Pool <albertpool@solcon.nl>
Reported-by: Michael Landrum <landrummd@gmail.com>
---
drivers/net/wireless/ath/ar5523/ar5523.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ar5523/ar5523.c b/drivers/net/wireless/ath/ar5523/ar5523.c
index 17d7fec..280fc3d 100644
--- a/drivers/net/wireless/ath/ar5523/ar5523.c
+++ b/drivers/net/wireless/ath/ar5523/ar5523.c
@@ -1762,6 +1762,7 @@ static struct usb_device_id ar5523_id_table[] = {
AR5523_DEVICE_UX(0x2001, 0x3a00), /* Dlink / DWLAG132 */
AR5523_DEVICE_UG(0x2001, 0x3a02), /* Dlink / DWLG132 */
AR5523_DEVICE_UX(0x2001, 0x3a04), /* Dlink / DWLAG122 */
+ AR5523_DEVICE_UG(0x07d1, 0x3a07), /* D-Link / WUA-2340 rev A1 */
AR5523_DEVICE_UG(0x1690, 0x0712), /* Gigaset / AR5523 */
AR5523_DEVICE_UG(0x1690, 0x0710), /* Gigaset / SMCWUSBTG */
AR5523_DEVICE_UG(0x129b, 0x160c), /* Gigaset / USB stick 108
--
1.7.10.4
^ permalink raw reply related
* Re: RTL8192CU continually reconnecting
From: Larry Finger @ 2013-09-09 19:03 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Timothy Rundle, linux-wireless
In-Reply-To: <522E0573.4000804@ilande.co.uk>
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
On 09/09/2013 12:29 PM, Mark Cave-Ayland wrote:
> Please find the attached dmesg output from my current environment which is
> Linus' git commit 6a7492a4b2e05051a44458d7187023e22d580666 along with your
> beacon patch.
>
> Does that help provide any further insight? To my untrained eye, it really looks
> as if I'm not getting beacons every 6s as suggested by the comments in base.c.
>
> (Feel free to CC any replies back to the list if you're happy no secrets are
> being revealed)
There were no secrets in that dump, but it did reveal a major clue.
A response from your system for your AP was:
mode 2, state 0, is_beacon 0, is_probe_resp 1, length 147
For the number of beacons to be updated, the state has to be 2 or 3. My system
has scan_ssid=1 in the wpa_supplicant configuration file. When the scan
finishes, then a value of 2 is set into the mode variable.
The attached updated patch should set the correct mode even if scanning is not
enabled.
Larry
[-- Attachment #2: rtl8192cu_dump_AP_off --]
[-- Type: text/plain, Size: 1781 bytes --]
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/base.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/base.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/base.c
@@ -1287,7 +1287,13 @@ void rtl_beacon_statistic(struct ieee802
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+ static int count;
+ if (count++ < 100) {
+ pr_info("mode %d, state %d, is_beacon %d, is_probe_resp %d, length %d, MAC %pM\n",
+ rtlpriv->mac80211.opmode, rtlpriv->mac80211.link_state, ieee80211_is_beacon(hdr->frame_control),
+ ieee80211_is_probe_resp(hdr->frame_control), skb->len, hdr->addr3);
+ }
if (rtlpriv->mac80211.opmode != NL80211_IFTYPE_STATION)
return;
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/usb.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
@@ -484,6 +484,8 @@ static void _rtl_usb_rx_process_agg(stru
if (unicast)
rtlpriv->link_info.num_rx_inperiod++;
}
+ /* static bcn for roaming */
+ rtl_beacon_statistic(hw, skb);
}
}
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/core.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/core.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/core.c
@@ -184,6 +184,7 @@ static int rtl_op_add_interface(struct i
rtlpriv->cfg->maps
[RTL_IBSS_INT_MASKS]);
}
+ mac->link_state = MAC80211_LINKED;
break;
case NL80211_IFTYPE_ADHOC:
RT_TRACE(rtlpriv, COMP_MAC80211, DBG_LOUD,
^ permalink raw reply
* Always send management frames at MCS-0??
From: Ben Greear @ 2013-09-09 19:10 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, hostap@lists.shmoo.com
I had a user request that we support always sending management frames
(such as EAPOL) at the lowest rate. Evidently, other equipment does this,
where as normal-ish supplicant/linux tends to send them at much higher
rates.
Any suggestions on how to go about doing this properly?
Any opinions on whether it's a good idea or not?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox