* [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.
From: Alexis Green @ 2017-02-24 19:58 UTC (permalink / raw)
To: linux-wireless; +Cc: Jesse Jones
From: Jesse Jones <jjones@uniumwifi.com>
Changes since v1: Only flush tx queue if interface is mesh mode.
This prevents kernel panics due to uninitialized spin_lock.
When more than one station hears a broadcast request, it is possible that
multiple devices will reply at the same time, potentially causing
collision. This patch helps reduce this issue.
Signed-off-by: Alexis Green <agreen@uniumwifi.com>
Signed-off-by: Benjamin Morgan <bmorgan@uniumwifi.com>
---
net/mac80211/ieee80211_i.h | 11 ++++
net/mac80211/iface.c | 61 ++++++++++++++++++++++
net/mac80211/mesh.c | 2 +
net/mac80211/mesh_hwmp.c | 124 +++++++++++++++++++++++++++++++++++----------
4 files changed, 171 insertions(+), 27 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 159a1a7..f422897 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -330,6 +330,11 @@ struct mesh_preq_queue {
u8 flags;
};
+struct mesh_tx_queue {
+ struct list_head list;
+ struct sk_buff *skb;
+};
+
struct ieee80211_roc_work {
struct list_head list;
@@ -670,6 +675,11 @@ struct ieee80211_if_mesh {
spinlock_t mesh_preq_queue_lock;
struct mesh_preq_queue preq_queue;
int preq_queue_len;
+ /* Spinlock for trasmitted MPATH frames */
+ spinlock_t mesh_tx_queue_lock;
+ struct mesh_tx_queue tx_queue;
+ int tx_queue_len;
+
struct mesh_stats mshstats;
struct mesh_config mshcfg;
atomic_t estab_plinks;
@@ -919,6 +929,7 @@ struct ieee80211_sub_if_data {
struct work_struct work;
struct sk_buff_head skb_queue;
+ struct delayed_work tx_work;
u8 needed_rx_chains;
enum ieee80211_smps_mode smps_mode;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 40813dd..d5b4bf4 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -778,6 +778,59 @@ static int ieee80211_open(struct net_device *dev)
return ieee80211_do_open(&sdata->wdev, true);
}
+static void flush_tx_skbs(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct mesh_tx_queue *tx_node;
+
+ spin_lock_bh(&ifmsh->mesh_tx_queue_lock);
+
+ /* Note that this check is important because of the two-stage
+ * way that ieee80211_if_mesh is initialized.
+ */
+ if (ifmsh->tx_queue_len > 0) {
+ mhwmp_dbg(sdata, "flushing %d skbs", ifmsh->tx_queue_len);
+
+ while (!list_empty(&ifmsh->tx_queue.list)) {
+ tx_node = list_last_entry(&ifmsh->tx_queue.list,
+ struct mesh_tx_queue, list);
+ kfree_skb(tx_node->skb);
+ list_del(&tx_node->list);
+ kfree(tx_node);
+ }
+ ifmsh->tx_queue_len = 0;
+ }
+
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+}
+
+static void mesh_jittered_tx(struct work_struct *wk)
+{
+ struct ieee80211_sub_if_data *sdata =
+ container_of(
+ wk, struct ieee80211_sub_if_data,
+ tx_work.work);
+
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct mesh_tx_queue *tx_node;
+
+ spin_lock_bh(&ifmsh->mesh_tx_queue_lock);
+
+ list_for_each_entry(tx_node, &ifmsh->tx_queue.list, list) {
+ ieee80211_tx_skb(sdata, tx_node->skb);
+ }
+
+ while (!list_empty(&ifmsh->tx_queue.list)) {
+ tx_node = list_last_entry(&ifmsh->tx_queue.list,
+ struct mesh_tx_queue, list);
+ list_del(&tx_node->list);
+ kfree(tx_node);
+ }
+ ifmsh->tx_queue_len = 0;
+
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+}
+
static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
bool going_down)
{
@@ -881,6 +934,12 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
cancel_delayed_work_sync(&sdata->dfs_cac_timer_work);
+ /* Nothing to flush if the interface is not in mesh mode */
+ if (sdata->vif.type == NL80211_IFTYPE_MESH_POINT)
+ flush_tx_skbs(sdata);
+
+ cancel_delayed_work_sync(&sdata->tx_work);
+
if (sdata->wdev.cac_started) {
chandef = sdata->vif.bss_conf.chandef;
WARN_ON(local->suspended);
@@ -1846,6 +1905,8 @@ int ieee80211_if_add(struct ieee80211_local *local, const char *name,
ieee80211_dfs_cac_timer_work);
INIT_DELAYED_WORK(&sdata->dec_tailroom_needed_wk,
ieee80211_delayed_tailroom_dec);
+ INIT_DELAYED_WORK(&sdata->tx_work,
+ mesh_jittered_tx);
for (i = 0; i < NUM_NL80211_BANDS; i++) {
struct ieee80211_supported_band *sband;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index c28b0af..f0d3cd9 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -1381,6 +1381,8 @@ void ieee80211_mesh_init_sdata(struct ieee80211_sub_if_data *sdata)
ieee80211_mesh_path_root_timer,
(unsigned long) sdata);
INIT_LIST_HEAD(&ifmsh->preq_queue.list);
+ INIT_LIST_HEAD(&ifmsh->tx_queue.list);
+ spin_lock_init(&ifmsh->mesh_tx_queue_lock);
skb_queue_head_init(&ifmsh->ps.bc_buf);
spin_lock_init(&ifmsh->mesh_preq_queue_lock);
spin_lock_init(&ifmsh->sync_offset_lock);
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index d07ee3c..5c22daf 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -18,6 +18,7 @@
#define ARITH_SHIFT 8
#define MAX_PREQ_QUEUE_LEN 64
+#define MAX_TX_QUEUE_LEN 8
static void mesh_queue_preq(struct mesh_path *, u8);
@@ -98,13 +99,15 @@ enum mpath_frame_type {
static const u8 broadcast_addr[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
-static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
- const u8 *orig_addr, u32 orig_sn,
- u8 target_flags, const u8 *target,
- u32 target_sn, const u8 *da,
- u8 hop_count, u8 ttl,
- u32 lifetime, u32 metric, u32 preq_id,
- struct ieee80211_sub_if_data *sdata)
+static struct sk_buff *alloc_mesh_path_sel_frame(enum mpath_frame_type action,
+ u8 flags, const u8 *orig_addr,
+ u32 orig_sn, u8 target_flags,
+ const u8 *target,
+ u32 target_sn, const u8 *da,
+ u8 hop_count, u8 ttl,
+ u32 lifetime, u32 metric,
+ u32 preq_id,
+ struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_local *local = sdata->local;
struct sk_buff *skb;
@@ -117,7 +120,7 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
hdr_len +
2 + 37); /* max HWMP IE */
if (!skb)
- return -1;
+ return NULL;
skb_reserve(skb, local->tx_headroom);
mgmt = (struct ieee80211_mgmt *) skb_put(skb, hdr_len);
memset(mgmt, 0, hdr_len);
@@ -153,7 +156,7 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
break;
default:
kfree_skb(skb);
- return -ENOTSUPP;
+ return NULL;
}
*pos++ = ie_len;
*pos++ = flags;
@@ -192,10 +195,72 @@ static int mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
pos += 4;
}
- ieee80211_tx_skb(sdata, skb);
- return 0;
+ return skb;
+}
+
+static void mesh_path_sel_frame_tx(enum mpath_frame_type action, u8 flags,
+ const u8 *orig_addr, u32 orig_sn,
+ u8 target_flags, const u8 *target,
+ u32 target_sn, const u8 *da,
+ u8 hop_count, u8 ttl,
+ u32 lifetime, u32 metric, u32 preq_id,
+ struct ieee80211_sub_if_data *sdata)
+{
+ struct sk_buff *skb = alloc_mesh_path_sel_frame(action, flags,
+ orig_addr, orig_sn, target_flags, target, target_sn,
+ da, hop_count, ttl, lifetime, metric, preq_id, sdata);
+ if (skb)
+ ieee80211_tx_skb(sdata, skb);
}
+static void mesh_path_sel_frame_tx_jittered(enum mpath_frame_type action,
+ u8 flags, const u8 *orig_addr,
+ u32 orig_sn, u8 target_flags,
+ const u8 *target, u32 target_sn,
+ const u8 *da, u8 hop_count, u8 ttl,
+ u32 lifetime, u32 metric,
+ u32 preq_id,
+ struct ieee80211_sub_if_data *sdata)
+{
+ u32 jitter;
+ struct sk_buff *skb = alloc_mesh_path_sel_frame(action, flags,
+ orig_addr, orig_sn,
+ target_flags, target,
+ target_sn, da,
+ hop_count, ttl,
+ lifetime, metric,
+ preq_id, sdata);
+ if (skb) {
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct mesh_tx_queue *tx_node = kmalloc(
+ sizeof(struct mesh_tx_queue), GFP_ATOMIC);
+ if (!tx_node) {
+ mhwmp_dbg(sdata, "could not allocate mesh_hwmp tx node");
+ return;
+ }
+
+ spin_lock_bh(&ifmsh->mesh_tx_queue_lock);
+ if (ifmsh->tx_queue_len == MAX_TX_QUEUE_LEN) {
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+ kfree(tx_node);
+ kfree_skb(skb);
+ if (printk_ratelimit())
+ mhwmp_dbg(sdata, "mesh_hwmp tx node queue full");
+ return;
+ }
+
+ tx_node->skb = skb;
+ list_add_tail(&tx_node->list, &ifmsh->tx_queue.list);
+ ++ifmsh->tx_queue_len;
+ spin_unlock_bh(&ifmsh->mesh_tx_queue_lock);
+
+ jitter = prandom_u32() % 25;
+
+ ieee80211_queue_delayed_work(
+ &sdata->local->hw,
+ &sdata->tx_work, msecs_to_jiffies(jitter));
+ }
+}
/* Headroom is not adjusted. Caller should ensure that skb has sufficient
* headroom in case the frame is encrypted. */
@@ -620,11 +685,13 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
ttl = ifmsh->mshcfg.element_ttl;
if (ttl != 0) {
mhwmp_dbg(sdata, "replying to the PREQ\n");
- mesh_path_sel_frame_tx(MPATH_PREP, 0, orig_addr,
- orig_sn, 0, target_addr,
- target_sn, mgmt->sa, 0, ttl,
- lifetime, target_metric, 0,
- sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_PREP, 0,
+ orig_addr, orig_sn,
+ 0, target_addr,
+ target_sn, mgmt->sa,
+ 0, ttl, lifetime,
+ target_metric, 0,
+ sdata);
} else {
ifmsh->mshstats.dropped_frames_ttl++;
}
@@ -652,10 +719,11 @@ static void hwmp_preq_frame_process(struct ieee80211_sub_if_data *sdata,
target_sn = PREQ_IE_TARGET_SN(preq_elem);
}
- mesh_path_sel_frame_tx(MPATH_PREQ, flags, orig_addr,
- orig_sn, target_flags, target_addr,
- target_sn, da, hopcount, ttl, lifetime,
- orig_metric, preq_id, sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_PREQ, flags, orig_addr,
+ orig_sn, target_flags,
+ target_addr, target_sn, da,
+ hopcount, ttl, lifetime,
+ orig_metric, preq_id, sdata);
if (!is_multicast_ether_addr(da))
ifmsh->mshstats.fwded_unicast++;
else
@@ -721,9 +789,10 @@ static void hwmp_prep_frame_process(struct ieee80211_sub_if_data *sdata,
target_sn = PREP_IE_TARGET_SN(prep_elem);
orig_sn = PREP_IE_ORIG_SN(prep_elem);
- mesh_path_sel_frame_tx(MPATH_PREP, flags, orig_addr, orig_sn, 0,
- target_addr, target_sn, next_hop, hopcount,
- ttl, lifetime, metric, 0, sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_PREP, flags, orig_addr, orig_sn,
+ 0, target_addr, target_sn, next_hop,
+ hopcount, ttl, lifetime, metric, 0,
+ sdata);
rcu_read_unlock();
sdata->u.mesh.mshstats.fwded_unicast++;
@@ -873,10 +942,11 @@ static void hwmp_rann_frame_process(struct ieee80211_sub_if_data *sdata,
ttl--;
if (ifmsh->mshcfg.dot11MeshForwarding) {
- mesh_path_sel_frame_tx(MPATH_RANN, flags, orig_addr,
- orig_sn, 0, NULL, 0, broadcast_addr,
- hopcount, ttl, interval,
- metric + metric_txsta, 0, sdata);
+ mesh_path_sel_frame_tx_jittered(MPATH_RANN, flags, orig_addr,
+ orig_sn, 0, NULL, 0,
+ broadcast_addr, hopcount, ttl,
+ interval, metric + metric_txsta,
+ 0, sdata);
}
rcu_read_unlock();
^ permalink raw reply related
* Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
From: Johannes Berg @ 2017-02-24 19:37 UTC (permalink / raw)
To: Oliver Freyermuth, linux-wireless
In-Reply-To: <5d69cf9b-1113-835a-8423-3796586eae20@googlemail.com>
On Fri, 2017-02-24 at 19:51 +0100, Oliver Freyermuth wrote:
>
> Thanks for your reply and the suggestion! I have put the two lines
> directly after the last #include
> in both files, i.e. both drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
> and net/mac80211/ieee80211_i.h .
> Sadly, none of them triggers when trying to enter suspend.
>
> I still get:
> [ 85.308756] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
> returns -16
> [ 85.308757] PM: Device phy0 failed to suspend async: error -16
> [ 85.310518] sd 5:0:0:0: [sdb] Stopping disk
> [ 85.857976] PM: Some devices failed to suspend, or early wake
> event detected
> with nothing in between.
I'd have expected the message to show up *before* the first one
(dpm_run_callback) you quoted, because this one already has the -16
return value printed, and it must've been generated before that.
I just tried on one of my systems, but it's not exactly the same kernel
version (would be difficult to install right now), and it works just
fine for me. Perhaps there's something going on with your system.
> Just to make sure, I can confirm the change is effective, since I get
> many of:
> [ 57.819114] WARNING: CPU: 4 PID: 4092 at
> drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1503
> iwl_mvm_rx_tx_cmd+0x51e/0x579 [iwlmvm]
> (with the tracebacks) for example when connecting to a different
> network. But none of these when trying to suspend...
Oops. I didn't see this instance of EBUSY in the success path - it's
used for a comparison that probably never triggered. Anyway, no harm
done apart from logging lots of useless stack traces :)
> Any other ideas on where I could look, or how I could trace the
> origin of this -16?
(see below)
> You are right about the bug report - I provided the wrong link,
> sorry.
> The report I meant is here:
> https://bugzilla.redhat.com/show_bug.cgi?id=1362311
> for a 7260 similar to mine.
Yes, that one looks like the same as yours.
> I believe that
> https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
> i.e. comment 25 was made by the same person who just hijacked that
> kernel
> bug report even though it was indeed for a very different hardware.
Ok, that's possible.
So let's see. The error *isn't* generated by mac80211 or iwlwifi, but
it's still returned through wiphy_suspend(). That function just calls
mac80211 though, and never generates any error conditions by itself. As
a consequence, this must be generated in some callee of wiphy_suspend()
that *isn't* in mac80211/iwlwifi...
__ieee80211_suspend() also doesn't generate any error codes by itself,
let's take a look at iwlmvm's suspend (called through drv_suspend()),
that's iwl_mvm_suspend().
Oh. Can you see if you have CONFIG_IWLWIFI_PCIE_RTPM enabled in your
configuration? If you do, please turn it off and see if that fixes it.
This still looks fishy in the code though, but let's see if that's the
problem first.
johannes
^ permalink raw reply
* Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
From: Oliver Freyermuth @ 2017-02-24 18:51 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1487938277.2540.13.camel@sipsolutions.net>
Am 24.02.2017 um 13:11 schrieb Johannes Berg:
>> However, when trying to suspend to RAM ( echo mem > /sys/power/state
>> ), I get:
>> [46656.403767] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
>> returns -16
>> [46656.403769] PM: Device phy0 failed to suspend async: error -16
>>
>
> However, I don't see EBUSY anywhere there in the driver.
>
> Can you recompile the kernel and run a quick experiment?
>
> Open drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and put something
> like this after the includes:
>
> #undef EBUSY
> #define EBUSY ({ WARN_ON(1); 16; })
>
> that should trigger a warning at the place where the EBUSY came from,
> assuming it did in fact come from the driver. You could repeat it for
> net/mac80211/ieee80211_i.h if that doesn't trigger.
Thanks for your reply and the suggestion! I have put the two lines directly after the last #include
in both files, i.e. both drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and net/mac80211/ieee80211_i.h .
Sadly, none of them triggers when trying to enter suspend.
I still get:
[ 85.308756] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211] returns -16
[ 85.308757] PM: Device phy0 failed to suspend async: error -16
[ 85.310518] sd 5:0:0:0: [sdb] Stopping disk
[ 85.857976] PM: Some devices failed to suspend, or early wake event detected
with nothing in between.
Just to make sure, I can confirm the change is effective, since I get many of:
[ 57.819114] WARNING: CPU: 4 PID: 4092 at drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1503 iwl_mvm_rx_tx_cmd+0x51e/0x579 [iwlmvm]
(with the tracebacks) for example when connecting to a different network. But none of these when trying to suspend...
Any other ideas on where I could look, or how I could trace the origin of this -16?
>
>> https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
>
> That device is like mine, afaict, so this seems to be a different bug.
You are right about the bug report - I provided the wrong link, sorry.
The report I meant is here:
https://bugzilla.redhat.com/show_bug.cgi?id=1362311
for a 7260 similar to mine.
I believe that
https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
i.e. comment 25 was made by the same person who just hijacked that kernel
bug report even though it was indeed for a very different hardware.
I'm open for any other suggestions, let me know if anything comes to mind.
Cheers and thanks for your reply,
Oliver
^ permalink raw reply
* [PATCH RFC] brcmfmac: shutdown interfaces on PSM's watchdog fire
From: Rafał Miłecki @ 2017-02-24 17:24 UTC (permalink / raw)
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
When PSM's watchdog fires hardware / firmware is not operational. It
seems there isn't a way to restart firmware & reapply all settings so
instead shut all interfaces down. This is at least some signal for the
user things went wrong and allows reacting to it.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
This patch is RFC as I'm wondering if there is any other way to handle
such errors. I couldn't find anything except for that
cfg80211_shutdown_all_interfaces.
Unfortunately hostapd doesn't seem to react to this except for sth like:
Fri Feb 24 13:41:07 2017 daemon.notice hostapd: wlan0: INTERFACE-DISABLED
Shall we introduce some nl80211 even for such cases maybe?
Or maybe I'm totally wrong and there is some simple way for a driver to
request reconfiguration of all interfaces?
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 5 +++++
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h | 1 +
drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 4 ++++
3 files changed, 10 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 10098b7586f3..520d397bb963 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6981,3 +6981,8 @@ void brcmf_cfg80211_detach(struct brcmf_cfg80211_info *cfg)
wl_deinit_priv(cfg);
brcmf_free_wiphy(cfg->wiphy);
}
+
+void brcmf_cfg80211_shutdown(struct brcmf_cfg80211_info *cfg)
+{
+ cfg80211_shutdown_all_interfaces(cfg->wiphy);
+}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
index 8f19d95d4175..77dafe03bb31 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
@@ -385,6 +385,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
struct device *busdev,
bool p2pdev_forced);
void brcmf_cfg80211_detach(struct brcmf_cfg80211_info *cfg);
+void brcmf_cfg80211_shutdown(struct brcmf_cfg80211_info *cfg);
s32 brcmf_cfg80211_up(struct net_device *ndev);
s32 brcmf_cfg80211_down(struct net_device *ndev);
enum nl80211_iftype brcmf_cfg80211_get_iftype(struct brcmf_if *ifp);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 2f2f3a5ad86a..c6c0f3e8ef00 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -753,6 +753,10 @@ static int brcmf_psm_watchdog_notify(struct brcmf_if *ifp,
if (err)
brcmf_err("Failed to get memory dump, %d\n", err);
+ brcmf_cfg80211_shutdown(ifp->drvr->config);
+
+ /* TODO: Stop the firmware */
+
return err;
}
--
2.11.0
^ permalink raw reply related
* [PATCH] brcmfmac: always print error when PSM's watchdog fires
From: Rafał Miłecki @ 2017-02-24 16:32 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
So far we were attaching BRCMF_E_PSM_WATCHDOG event listener in
brcmf_debug_attach which gets compiled only with CONFIG_BRCMDBG. This
event means something went wrong and firmware / hardware usually can't
be expected to work (reliably).
Such a problem is significant for user experience so I believe we should
print an error unconditionally (even with debugging disabled). What can
be indeed optional is dumping bus memory as this is clearly part of
debugging process.
In the future we may also try to extend this listener by trying to
recover from the error or at least signal it to the cfg80211.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 22 ++++++++++++++++++
.../wireless/broadcom/brcm80211/brcmfmac/debug.c | 26 +++-------------------
.../wireless/broadcom/brcm80211/brcmfmac/debug.h | 9 ++++++++
3 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 60da86a8d95b..2f2f3a5ad86a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -738,6 +738,24 @@ void brcmf_remove_interface(struct brcmf_if *ifp, bool rtnl_locked)
brcmf_del_if(ifp->drvr, ifp->bsscfgidx, rtnl_locked);
}
+static int brcmf_psm_watchdog_notify(struct brcmf_if *ifp,
+ const struct brcmf_event_msg *evtmsg,
+ void *data)
+{
+ int err;
+
+ brcmf_dbg(TRACE, "enter: bsscfgidx=%d\n", ifp->bsscfgidx);
+
+ brcmf_err("PSM's watchdog has fired!\n");
+
+ err = brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
+ evtmsg->datalen);
+ if (err)
+ brcmf_err("Failed to get memory dump, %d\n", err);
+
+ return err;
+}
+
#ifdef CONFIG_INET
#define ARPOL_MAX_ENTRIES 8
static int brcmf_inetaddr_changed(struct notifier_block *nb,
@@ -917,6 +935,10 @@ int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings)
goto fail;
}
+ /* Attach to events important for core code */
+ brcmf_fweh_register(drvr, BRCMF_E_PSM_WATCHDOG,
+ brcmf_psm_watchdog_notify);
+
/* attach firmware event handler */
brcmf_fweh_attach(drvr);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
index f4644cf371c7..1447a8352383 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
@@ -27,8 +27,8 @@
static struct dentry *root_folder;
-static int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
- size_t len)
+int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
+ size_t len)
{
void *dump;
size_t ramsize;
@@ -54,24 +54,6 @@ static int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
return 0;
}
-static int brcmf_debug_psm_watchdog_notify(struct brcmf_if *ifp,
- const struct brcmf_event_msg *evtmsg,
- void *data)
-{
- int err;
-
- brcmf_dbg(TRACE, "enter: bsscfgidx=%d\n", ifp->bsscfgidx);
-
- brcmf_err("PSM's watchdog has fired!\n");
-
- err = brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
- evtmsg->datalen);
- if (err)
- brcmf_err("Failed to get memory dump, %d\n", err);
-
- return err;
-}
-
void brcmf_debugfs_init(void)
{
root_folder = debugfs_create_dir(KBUILD_MODNAME, NULL);
@@ -99,9 +81,7 @@ int brcmf_debug_attach(struct brcmf_pub *drvr)
if (IS_ERR(drvr->dbgfs_dir))
return PTR_ERR(drvr->dbgfs_dir);
-
- return brcmf_fweh_register(drvr, BRCMF_E_PSM_WATCHDOG,
- brcmf_debug_psm_watchdog_notify);
+ return 0;
}
void brcmf_debug_detach(struct brcmf_pub *drvr)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
index 066126123e96..389166abb520 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
@@ -99,6 +99,7 @@ do { \
extern int brcmf_msg_level;
+struct brcmf_bus;
struct brcmf_pub;
#ifdef DEBUG
void brcmf_debugfs_init(void);
@@ -108,6 +109,8 @@ void brcmf_debug_detach(struct brcmf_pub *drvr);
struct dentry *brcmf_debugfs_get_devdir(struct brcmf_pub *drvr);
int brcmf_debugfs_add_entry(struct brcmf_pub *drvr, const char *fn,
int (*read_fn)(struct seq_file *seq, void *data));
+int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
+ size_t len);
#else
static inline void brcmf_debugfs_init(void)
{
@@ -128,6 +131,12 @@ int brcmf_debugfs_add_entry(struct brcmf_pub *drvr, const char *fn,
{
return 0;
}
+static inline
+int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
+ size_t len)
+{
+ return 0;
+}
#endif
#endif /* BRCMFMAC_DEBUG_H */
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 099/306] mac80211-hwsim: notify user-space about channel change.
From: Ben Greear @ 2017-02-24 15:39 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1487918197.2540.1.camel@sipsolutions.net>
On 02/23/2017 10:36 PM, Johannes Berg wrote:
>
>
>> + msg_head = genlmsg_put(skb, 0, 0, &hwsim_genl_family, 0,
>> + HWSIM_CMD_NOTIFY);
>
> I think you should use a more specific command name.
My idea was that other attributes could be added over time without
having to add a new cmd-id, so that is why I left it general. If you
still want a different command, do you want it to be something like
'HWSIM_CMD_CHANNEL_CHANGE' ?
Thanks,
Ben
>
>> + if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER,
>> + ETH_ALEN, data->addresses[1].addr))
>> + goto nla_put_failure;
>
> and at least also add a more specific identifier like the radio ID.
>
>> + if (data->channel)
>> + center_freq = data->channel->center_freq;
>> +
>> + if (nla_put_u32(skb, HWSIM_ATTR_FREQ, center_freq))
>> + goto nla_put_failure;
>
> and have the full channel definition
>
>
> Also the indentation in the documentation didn't match the convention
> used there.
>
> johannes
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 160/306] mac80211-hwsim: add rate-limited debugging for rx-netlink
From: Ben Greear @ 2017-02-24 15:27 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1487918388.2540.6.camel@sipsolutions.net>
On 02/23/2017 10:39 PM, Johannes Berg wrote:
>
>> + !info->attrs[HWSIM_ATTR_SIGNAL]) {
>> + if (net_ratelimit())
>> + printk(KERN_DEBUG " hwsim rx-nl: Missing
>> required attribute\n");
>
> I'm not convinced net_ratelimit() is a good idea, that's a global rate
> limiter.
Is there a better rate-limiter w/out hand-crafting something?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 161/306] mac80211-hwsim: Improve logging.
From: Ben Greear @ 2017-02-24 15:26 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <1487918553.2540.9.camel@sipsolutions.net>
On 02/23/2017 10:42 PM, Johannes Berg wrote:
>
>> + static unsigned int cnt = 0;
>> + /* This is fairly common, and usually not a
>> bug. So, print errors
>> + rarely. */
>> + if (((cnt++ & 0x3FF) == 0x3FF) && net_ratelimit())
>> + printk(KERN_DEBUG " hwsim rx-nl: radio %pM
>> idle: %d or not started: %d cnt: %d\n",
>> + dst, data2->idle, !data2->started,
>> cnt);
>> goto out;
>> }
>
> You just added that in the previous patch...
>
> Please take a bit more care, or I'll eventually stop looking at your
> patches since things like that seem to happen over and over again. I
> don't get a feeling that you actually care about getting things
> upstream much anyway.
I wrote these patches over a long period of time. Some, like the binary
API things I already knew you did not want, but I posted them since
it seems several people are looking at this sort of thing and maybe
they will have a good idea how to add similar behaviour in an efficient
manner. I think your previous suggestion was that I should map each
flag in some translate code and/or bloat up netlink API, and neither
of those options seemed like an efficient use of CPU time.
I'll work to fix the cosmetic problems and squash these logging patches
and re-submit those.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] wireless-regdb: Update rules for Australia (AU) and add 60GHz rules
From: Seth Forshee @ 2017-02-24 14:55 UTC (permalink / raw)
To: Ryan Mounce; +Cc: wireless-regdb, linux-wireless, Johannes Berg
In-Reply-To: <CAN+fvRYhW4hhHfyzvE8uJZ+qu8hneUni_je=3kdNe+bPa+WQxA@mail.gmail.com>
On Fri, Feb 24, 2017 at 01:20:24PM +1030, Ryan Mounce wrote:
> On 24 February 2017 at 02:05, Seth Forshee <seth.forshee@canonical.com> wrote:
> > On Fri, Feb 24, 2017 at 12:22:53AM +1030, Ryan Mounce wrote:
> >> Sourced from the current legislation at
> >> https://www.legislation.gov.au/Details/F2016C00432
> >>
> >> The current rules exceed legal limits between 5250-5330MHz, and permit
> >> illegal operation in 5600-5650MHz (disallowed regardless of DFS).
> >>
> >> Frequency ranges and EIRP limits for all ranges have been updated to
> >> match items 59-63, 65 in the linked document. As the rules for AU have
> >> never previously mirrored local regulations, changes include a
> >> significant increase in the allowable 2.4GHz EIRP and smaller increases
> >> in most other bands.
> >>
> >> In order to allow 80MHz operation between 5650-5730MHz (bordering two
> >> bands) the lower, more restrictive band has been rounded up by 5MHz.
> >>
> >> Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
> >> ---
> >> db.txt | 15 ++++++++++-----
> >> 1 file changed, 10 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/db.txt b/db.txt
> >> index 05108e0..00e81b6 100644
> >> --- a/db.txt
> >> +++ b/db.txt
> >> @@ -85,12 +85,17 @@ country AT: DFS-ETSI
> >> # 60 GHz band channels 1-4, ref: Etsi En 302 567
> >> (57000 - 66000 @ 2160), (40)
> >>
> >> +# Source:
> >> +# https://www.legislation.gov.au/Details/F2016C00432
> >> +# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B
> >> country AU: DFS-ETSI
> >> - (2402 - 2482 @ 40), (20)
> >> - (5170 - 5250 @ 80), (17), AUTO-BW
> >> - (5250 - 5330 @ 80), (24), DFS, AUTO-BW
> >> - (5490 - 5710 @ 160), (24), DFS
> >> - (5735 - 5835 @ 80), (30)
> >> + (2400 - 2483.5 @ 40), (36)
> >
> > The mention of ETSI EN 300 328 in item 55 (a) leads me to believe that
> > this is the limit we should be using, i.e. 500 mW. It is a bit confusing
> > though since it seems like such devices would also fall under "digital
> > modulation transmitters."
>
> Item 55 applies only to frequency hopping transmitters e.g. Bluetooth.
> As a local, I can say with some degree of certainty that 4W/36dBm is
> the correct 2.4GHz ISM EIRP for Australia. It is advertised as the
> EIRP in the 802.11d IE of commercial devices e.g. Cisco Aironet APs
> and widely deployed ISP gateways in Australia, among other devices
> that have received relevant approvals.
Okay, looking at that section again that makes sense.
> >> + (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
> >
> > This looks correct.
> >
> >> + (5250 - 5350 @ 80), (23), NO-OUTDOOR, AUTO-BW, DFS
> >
> > Since this range requires TPC we need to set the power limit at 100 mW.
> >
> >> + (5470 - 5600 @ 80), (30), DFS
> >> + (5650 - 5730 @ 80), (30), DFS
> >
> > These ranges also require TPC so we need to set the limit at 500 mW.
>
> I was unsure about this one. Setting this to 27dBm also affects the
> 802.11d country information IE, however when the DFS flag is set a 3dB
> 802.11h power constraint IE is also advertised so stations will limit
> themselves to (27-3)=24dBm/250mW.
>
> Given the choice between unnecessarily halving transmit power on
> stations and potentially transmitting at twice the permissible power
> on APs without TPC I agree that the conservative approach should be
> taken for now. Ideally I think that the actual EIRP limits should be
> in the regdb and a 3dB constraint should be applied automatically on
> APs that cannot support TPC when the DFS flag is set.
>
> >> + (5730 - 5850 @ 80), (36)
> >
> > In the document the ranges are 5650-5725 MHz and 5725-5850 MHz. I
> > suspect that the existing rules fudge that to line up with the wifi
> > channels, which technically is okay because the rules in the former
> > range are more restrictive. I wonder if we shouldn't be recording them
> > here as per the document and adding AUTO-BW. Johannes, any thoughts?
>
> I've tested with AUTO-BW and it doesn't work in this case as channel
> 144 will be disabled if it doesn't exist entirely within one band.
> Fudging the more restrictive rules by a mere 5MHz to fit 802.11
> channels seems to be the status quo.
I wonder why AUTO-BW doesn't work. In that case it's certainly fine to
keep those ranges as they are.
Thanks,
Seth
^ permalink raw reply
* Re: [PATCH 162/306] mac80211-hwsim: add length checks before allocating skb.
From: Ben Greear @ 2017-02-24 15:19 UTC (permalink / raw)
To: Andrew Zaborowski; +Cc: linux-wireless
In-Reply-To: <CAOq732+L3KDLP-5E4XnKE0-+TKV6KG_V5AVqeBjQRdyQ5Nr74g@mail.gmail.com>
On 02/24/2017 12:45 AM, Andrew Zaborowski wrote:
> On 24 February 2017 at 01:28, <greearb@candelatech.com> wrote:
>> Modify the receive-from-user-space logic to do length
>> and 'is-down' checks before trying to allocate an skb.
>>
>> And, if we are going to ignore the pkt due to radio idle,
>> then do not return an error code to user-space. User-space
>> cannot reliably know exactly when a radio is idle or not.
>
> You probably want to return some error code anyway because 0, if you
> compare to the kernel medium, currently maps to the ack returned bit
> and is possibly the only way for userspace to set the
> HWSIM_TX_STAT_ACK flag in a meaningful way.
Maybe there is a way to return a specific error code so that
the user-space doesn't get concerned when radio is idle. I
didn't want to spam logs in user-space app...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset
From: Rafał Miłecki @ 2017-02-24 13:43 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Rafał Miłecki, Kalle Valo, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl
In-Reply-To: <c7c82c1f-df42-c4a2-4f1f-1ff4928590d1@broadcom.com>
On 2017-02-24 14:21, Arend Van Spriel wrote:
> On 24-2-2017 13:27, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
>> brcmfmac there is support for 43602a1 and from what I know supporting
>> 43602a0 would require loading a different firmware.
>
> This is not necessarily true. It depends on whether the rom image is
> different or not and there is no way to tell up front. So if a0 has
> same
> rom image as a1 the firmware is compatible and no distinction is
> needed.
> This tends to be the case for chips that only change the digit and not
> the letter in the chip revision. Anyway, I do not know if a0 has
> different rom image, but the a0 was never sold so there is no harm in
> keeping it as is.
Just to be sure (I don't have such a good hardware knowledge):
1) Does ROM image mean some code that is permanently on the device?
2) Does firmware mean code we upload from the host driver?
I'm not sure if I understand the rest of your description.
AFAIU first you said ROM image tends to be the same on chipset
variations using
the same letter. If this is so, why we need different firmware for
43602a0 and
43602a1? Or different firmware for 43570a0 and 43570a2?
Also if what you said about sharing one ROM image between chip
variations using
the same letter was correct, shouldn't you expect the same ROM image on
43602a0
and 43602a1?
Forgive me if something of this is obvious for you, I just don't have
access to
any Broadcom internal documentation :)
^ permalink raw reply
* Re: [PATCH 4.12] brcmfmac: put chip into passive mode (when attaching) just once
From: Rafał Miłecki @ 2017-02-24 13:47 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Rafał Miłecki, Kalle Valo, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl
In-Reply-To: <cbcb8722-15bb-bf6e-f329-972797b02028@broadcom.com>
On 2017-02-24 14:31, Arend Van Spriel wrote:
> On 24-2-2017 14:10, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> It avoids some unnecessary work. Most likely there wasn't much sense
>> in
>> doing this before bus reset anyway, as reset is supposed to put chip
>> into default state. In PCIe code (only bus implementing reset) we e.g.
>> use watchdog to perform a chip "reboot".
>
> Sorry, but removing the fisrt passive call will cause chip lockups for
> sure on certain systems. We learned the hard way :-p
OK, acknowledged! ;) I just tested it on my BCM43602 doing warm reboots
(they
were causing problems earlier) and it worked fine.
It also seems I don't use SDK recent enough as my reference :)
Kalle please drop this patch.
^ permalink raw reply
* Re: [PATCH 4.12] brcmfmac: put chip into passive mode (when attaching) just once
From: Arend Van Spriel @ 2017-02-24 13:31 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170224131027.29880-1-zajec5@gmail.com>
On 24-2-2017 14:10, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> It avoids some unnecessary work. Most likely there wasn't much sense in
> doing this before bus reset anyway, as reset is supposed to put chip
> into default state. In PCIe code (only bus implementing reset) we e.g.
> use watchdog to perform a chip "reboot".
Sorry, but removing the fisrt passive call will cause chip lockups for
sure on certain systems. We learned the hard way :-p
Regards,
Arend
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> index 05f22ff81d60..670f2f50f9e5 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> @@ -967,16 +967,14 @@ static int brcmf_chip_recognition(struct brcmf_chip_priv *ci)
> if (ret)
> return ret;
>
> - /* assure chip is passive for core access */
> - brcmf_chip_set_passive(&ci->pub);
> -
> /* Call bus specific reset function now. Cores have been determined
> * but further access may require a chip specific reset at this point.
> */
> - if (ci->ops->reset) {
> + if (ci->ops->reset)
> ci->ops->reset(ci->ctx, &ci->pub);
> - brcmf_chip_set_passive(&ci->pub);
> - }
> +
> + /* assure chip is passive for core access */
> + brcmf_chip_set_passive(&ci->pub);
>
> return brcmf_chip_get_raminfo(ci);
> }
>
^ permalink raw reply
* [PATCH] mwifiex: fix kernel crash after shutdown command timeout
From: Amitkumar Karwar @ 2017-02-24 13:29 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
We observed a SHUTDOWN command timeout during reboot stress test due
to a corner case firmware bug. It leads to use-after-free on adapter
structure pointer and crash.
We already have a cancel_work_sync() call in teardown thread. This
issue is fixed by having this call just before mwifiex_remove_card().
At this point no further work will be scheduled.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 3 +--
drivers/net/wireless/marvell/mwifiex/sdio.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index a0d9180..f31c5ea 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -294,8 +294,6 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
if (!adapter || !adapter->priv_num)
return;
- cancel_work_sync(&card->work);
-
reg = card->pcie.reg;
if (reg)
ret = mwifiex_read_reg(adapter, reg->fw_status, &fw_status);
@@ -312,6 +310,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
mwifiex_init_shutdown_fw(priv, MWIFIEX_FUNC_SHUTDOWN);
}
+ cancel_work_sync(&card->work);
mwifiex_remove_card(adapter);
}
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index a4b356d..9534b47 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -387,8 +387,6 @@ static int mwifiex_check_winner_status(struct mwifiex_adapter *adapter)
if (!adapter || !adapter->priv_num)
return;
- cancel_work_sync(&card->work);
-
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
ret = mwifiex_sdio_read_fw_status(adapter, &firmware_stat);
@@ -400,6 +398,7 @@ static int mwifiex_check_winner_status(struct mwifiex_adapter *adapter)
mwifiex_init_shutdown_fw(priv, MWIFIEX_FUNC_SHUTDOWN);
}
+ cancel_work_sync(&card->work);
mwifiex_remove_card(adapter);
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table
From: Arend Van Spriel @ 2017-02-24 13:28 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170224122739.1778-2-zajec5@gmail.com>
On 24-2-2017 13:27, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or
> 4366c0. Cutting name at the letter isn't a good idea as sometimes we may
> have e.g. a0 and a1.
As explained in 1/2, the revision may change but if rom image is
unchanged the firmware stays compatible. As predicting chip development
is impossible initially we choose a common name as entry ID. So if there
would come a 4366c1 with incompatible rom image it would be time to
change the entry ID.
Regards,
Arend
> This is just a cosmetic change, a trivial cleanup. It obviously doesn't
> change fw filenames as we don't want to break user space.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 2a171479b42b..7039f7f09653 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -46,7 +46,7 @@ enum brcmf_pcie_state {
> BRCMFMAC_PCIE_STATE_UP
> };
>
> -BRCMF_FW_NVRAM_DEF(43602, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt");
> +BRCMF_FW_NVRAM_DEF(43602a1, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4350, "brcmfmac4350-pcie.bin", "brcmfmac4350-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4350C, "brcmfmac4350c2-pcie.bin", "brcmfmac4350c2-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-pcie.bin", "brcmfmac4356-pcie.txt");
> @@ -55,13 +55,13 @@ BRCMF_FW_NVRAM_DEF(4358, "brcmfmac4358-pcie.bin", "brcmfmac4358-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4359, "brcmfmac4359-pcie.bin", "brcmfmac4359-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4365B, "brcmfmac4365b-pcie.bin", "brcmfmac4365b-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4365C, "brcmfmac4365c-pcie.bin", "brcmfmac4365c-pcie.txt");
> -BRCMF_FW_NVRAM_DEF(4366B, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt");
> -BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
> +BRCMF_FW_NVRAM_DEF(4366b1, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt");
> +BRCMF_FW_NVRAM_DEF(4366c0, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
>
> static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602a1),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366c0),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43525_CHIP_ID, 0xFFFFFFF0, 4365C),
> @@ -73,8 +73,8 @@ static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0x0000000F, 4365B),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFFFFFF0, 4365C),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366B),
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366C),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366b1),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366c0),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371),
> };
>
>
^ permalink raw reply
* Re: [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset
From: Arend Van Spriel @ 2017-02-24 13:21 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170224122739.1778-1-zajec5@gmail.com>
On 24-2-2017 13:27, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> 43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
> brcmfmac there is support for 43602a1 and from what I know supporting
> 43602a0 would require loading a different firmware.
This is not necessarily true. It depends on whether the rom image is
different or not and there is no way to tell up front. So if a0 has same
rom image as a1 the firmware is compatible and no distinction is needed.
This tends to be the case for chips that only change the digit and not
the letter in the chip revision. Anyway, I do not know if a0 has
different rom image, but the a0 was never sold so there is no harm in
keeping it as is.
Regards,
Arend
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 6fae4cf3f6ab..2a171479b42b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -60,7 +60,7 @@ BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
> BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
>
> static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
> - BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFF, 43602),
> + BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C),
> BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350),
>
^ permalink raw reply
* [PATCH 4.12] brcmfmac: put chip into passive mode (when attaching) just once
From: Rafał Miłecki @ 2017-02-24 13:10 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
It avoids some unnecessary work. Most likely there wasn't much sense in
doing this before bus reset anyway, as reset is supposed to put chip
into default state. In PCIe code (only bus implementing reset) we e.g.
use watchdog to perform a chip "reboot".
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 05f22ff81d60..670f2f50f9e5 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -967,16 +967,14 @@ static int brcmf_chip_recognition(struct brcmf_chip_priv *ci)
if (ret)
return ret;
- /* assure chip is passive for core access */
- brcmf_chip_set_passive(&ci->pub);
-
/* Call bus specific reset function now. Cores have been determined
* but further access may require a chip specific reset at this point.
*/
- if (ci->ops->reset) {
+ if (ci->ops->reset)
ci->ops->reset(ci->ctx, &ci->pub);
- brcmf_chip_set_passive(&ci->pub);
- }
+
+ /* assure chip is passive for core access */
+ brcmf_chip_set_passive(&ci->pub);
return brcmf_chip_get_raminfo(ci);
}
--
2.11.0
^ permalink raw reply related
* Re: Regression with Intel 3160 AP: client not reconnecting
From: Jarek Kamiński @ 2017-02-24 12:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: Emmanuel Grumbach, Intel Linux Wireless, linux-wireless
In-Reply-To: <1487938414.2540.15.camel@sipsolutions.net>
W dniu 24.02.2017 o 13:13, Johannes Berg pisze:
> Hi Jarek,
Hello Johannes,
>> What might be the cause? Is there anything I can do to help debug or
>> fix this?
>
> Thanks for the detailed bug report and analysis! I can't analyse this
> in depth right now, can you please file a bug on bugzilla.kernel.org?
Sure, I'll do that during the weekend. Thanks for response!
--
pozdr(); // Jarek
^ permalink raw reply
* Re: Usage of WoWLAN with iwlwifi driver (Device phy0 failed to suspend async: error -16)
From: Johannes Berg @ 2017-02-24 12:11 UTC (permalink / raw)
To: Oliver Freyermuth, linux-wireless
In-Reply-To: <cc035655-0869-f7d7-bdb4-61e7a38b7fc8@googlemail.com>
> I have been trying to get basic WoWLAN to work with the following
> configuration:
> - Intel Corporation Wireless 7260 (rev 73) with in-tree iwlwifi
> driver
So I just tried on 4.9 with a 6205 NIC and it works there. The
difference must be somewhere in mvm/d3.c then, I guess. I got a lot of
warnings at resume time though, not sure why.
> However, when trying to suspend to RAM ( echo mem > /sys/power/state
> ), I get:
> [46656.403767] dpm_run_callback(): wiphy_suspend+0x0/0x97 [cfg80211]
> returns -16
> [46656.403769] PM: Device phy0 failed to suspend async: error -16
>
However, I don't see EBUSY anywhere there in the driver.
Can you recompile the kernel and run a quick experiment?
Open drivers/net/wireless/intel/iwlwifi/mvm/mvm.h and put something
like this after the includes:
#undef EBUSY
#define EBUSY ({ WARN_ON(1); 16; })
that should trigger a warning at the place where the EBUSY came from,
assuming it did in fact come from the driver. You could repeat it for
net/mac80211/ieee80211_i.h if that doesn't trigger.
> https://bugzilla.kernel.org/show_bug.cgi?id=109591#c25
That device is like mine, afaict, so this seems to be a different bug.
johannes
^ permalink raw reply
* [PATCH 4.12 2/2] brcmfmac: use more accurate PCIe chip names in fw table
From: Rafał Miłecki @ 2017-02-24 12:27 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170224122739.1778-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
Many chips have few variants/versions, e.g. BCM4366 can be 4366b1 or
4366c0. Cutting name at the letter isn't a good idea as sometimes we may
have e.g. a0 and a1.
This is just a cosmetic change, a trivial cleanup. It obviously doesn't
change fw filenames as we don't want to break user space.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 2a171479b42b..7039f7f09653 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -46,7 +46,7 @@ enum brcmf_pcie_state {
BRCMFMAC_PCIE_STATE_UP
};
-BRCMF_FW_NVRAM_DEF(43602, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt");
+BRCMF_FW_NVRAM_DEF(43602a1, "brcmfmac43602-pcie.bin", "brcmfmac43602-pcie.txt");
BRCMF_FW_NVRAM_DEF(4350, "brcmfmac4350-pcie.bin", "brcmfmac4350-pcie.txt");
BRCMF_FW_NVRAM_DEF(4350C, "brcmfmac4350c2-pcie.bin", "brcmfmac4350c2-pcie.txt");
BRCMF_FW_NVRAM_DEF(4356, "brcmfmac4356-pcie.bin", "brcmfmac4356-pcie.txt");
@@ -55,13 +55,13 @@ BRCMF_FW_NVRAM_DEF(4358, "brcmfmac4358-pcie.bin", "brcmfmac4358-pcie.txt");
BRCMF_FW_NVRAM_DEF(4359, "brcmfmac4359-pcie.bin", "brcmfmac4359-pcie.txt");
BRCMF_FW_NVRAM_DEF(4365B, "brcmfmac4365b-pcie.bin", "brcmfmac4365b-pcie.txt");
BRCMF_FW_NVRAM_DEF(4365C, "brcmfmac4365c-pcie.bin", "brcmfmac4365c-pcie.txt");
-BRCMF_FW_NVRAM_DEF(4366B, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt");
-BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
+BRCMF_FW_NVRAM_DEF(4366b1, "brcmfmac4366b-pcie.bin", "brcmfmac4366b-pcie.txt");
+BRCMF_FW_NVRAM_DEF(4366c0, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
- BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602),
- BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C),
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602a1),
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366c0),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43525_CHIP_ID, 0xFFFFFFF0, 4365C),
@@ -73,8 +73,8 @@ static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4359_CHIP_ID, 0xFFFFFFFF, 4359),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0x0000000F, 4365B),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4365_CHIP_ID, 0xFFFFFFF0, 4365C),
- BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366B),
- BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366C),
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0x0000000F, 4366b1),
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4366_CHIP_ID, 0xFFFFFFF0, 4366c0),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4371_CHIP_ID, 0xFFFFFFFF, 4371),
};
--
2.11.0
^ permalink raw reply related
* [PATCH 4.12 1/2] brcmfmac: don't use 43602a1 firmware for 43602a0 chipset
From: Rafał Miłecki @ 2017-02-24 12:27 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
43602a0 uses chip revision 0 compared to 43602a1 with revision 1. In
brcmfmac there is support for 43602a1 and from what I know supporting
43602a0 would require loading a different firmware.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 6fae4cf3f6ab..2a171479b42b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -60,7 +60,7 @@ BRCMF_FW_NVRAM_DEF(4366C, "brcmfmac4366c-pcie.bin", "brcmfmac4366c-pcie.txt");
BRCMF_FW_NVRAM_DEF(4371, "brcmfmac4371-pcie.bin", "brcmfmac4371-pcie.txt");
static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
- BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFF, 43602),
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFE, 43602),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0x000000FF, 4350C),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4350_CHIP_ID, 0xFFFFFF00, 4350),
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq
From: jeffy @ 2017-02-24 12:20 UTC (permalink / raw)
To: Kalle Valo
Cc: Amitkumar Karwar, Brian Norris, Rajat Jain, netdev,
linux-wireless, linux-kernel, Nishant Sarmukadam
In-Reply-To: <87d1e726p5.fsf@codeaurora.org>
Hi Kalle,
On 02/24/2017 07:01 PM, Kalle Valo wrote:
> Jeffy Chen <jeffy.chen@rock-chips.com> writes:
>
>> Currrently we are disabling this wake irq after receiving it. If this
>> happens before we finish suspend and the pm event check is disabled,
>> the system will continue suspending, and this irq would not work again.
>>
>> We may need to abort system suspend to avoid that.
>>
>> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> I only see patch 3 in patchwork. Where are patches 1 and 2?
>
the other two are much like this one, but for bluetooth :)
please check:
https://patchwork.kernel.org/patch/9589455 New [1/3] btusb:
wake system up when receives a wake irq
https://patchwork.kernel.org/patch/9589453 New [2/3] btmrvl:
wake system up when receives a wake irq
https://patchwork.kernel.org/patch/9589457 New [3/3] mwifiex:
wake system up when receives a wake irq
(sorry, this is a resent mail, because the last one was rejected due to
wrong format)
^ permalink raw reply
* Re: brcmfmac: problem using WPS with wpa_supplicant on BCM43362
From: Arend Van Spriel @ 2017-02-24 12:15 UTC (permalink / raw)
To: Jörg Krause, linux-wireless@vger.kernel.org
Cc: brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <1487932016.3812.10.camel@embedded.rocks>
On 24-2-2017 11:26, Jörg Krause wrote:
> Hi Arend,
>
> On Fri, 2017-02-24 at 10:58 +0100, Arend Van Spriel wrote:
>> On 24-2-2017 10:43, Jörg Krause wrote:
>>> Hi Arend,
>>>
>>> On Fri, 2017-02-24 at 09:16 +0100, Arend Van Spriel wrote:
>>>>
>>>> On 23-2-2017 21:21, Jörg Krause wrote:
>>>>> Hi,
>>>>>
>>>>> I am using Linux Kernel v4.9.9 and wpa_supplicant 2.6. When
>>>>> running
>>>>> 'wpa_cli wps_pin any', the following messages are printed:
>>>>>
>>>>> """
>>>>>> wps_pin any
>>>>>
>>>>> [ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
>>>>> error :
>>>>> -30
>>>>> [ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
>>>>> Failed
>>>>> """
>>>>>
>>>>> .. and nothing happens. The data sheet for the BCM43362 states
>>>>> that
>>>>> the
>>>>> module supports WPS.
>>>>
>>>> Hi Jörg,
>>>>
>>>> We have never tested WPS with brcmfmac. Most of it is in firmware
>>>> so
>>>> it
>>>> might work. We had some fixes related to setting management IE,
>>>> but
>>>> it
>>>> should be in 4.9. I did not check it (yet).
>>>
>>> As it turns out, WPS does not work if a network configuration in
>>> wpa_supplicant has the flag `mode=2` (access point mode) set:
>>>
>>> """
>>> ctrl_interface=/var/run/wpa_supplicant
>>> update_config=1
>>>
>>> network={
>>> ssid="AP"
>>> key_mgmt=NONE
>>> mode=2
>>> id_str="ap"
>>> }
>>> """
>>>
>>> Setting mode=2 for a network and having ap_scan=1 (default) means
>>> if no
>>> APs matching to the currently enabled networks are found, a new
>>> network
>>> (IBSS or AP mode operation) may be initialized (if configured).
>>>
>>> So, WPS does not work if the interface is operating in AP mode. I
>>> wonder, if this is a desired behavior? At least, wpa_supplicant
>>> does
>>> not complain, but prints "WPS-PBC-ACTIVE", but no messages are
>>> following, until "WPS-TIMEOUT".
>>
>> So what do you expect exactly? Are you trying to connect with some
>> other
>> device to this AP interface?
>
> Sorry, I got confused. The device operating in AP mode shall be
> connected to some other AP as a station. Of course, WPS cannot be used
> to do so as long as the interface is operation in AP mode, as the
> device should be the WPS enrollee and not the registrar. My bad! Thanks
> for pointing that out.
>
> So, to use WPS for connecting the device to another AP I have to bring
> the interface into an non-AP mode first.
>
> So, I can confirm that using WPS works when the interface is
> unconfigured. However, if the in the interface is in AP mode and WPS is
> started the error messages pop up.
You mean the message you emailed earlier as below?
[ 4011.779108] brcmfmac: brcmf_vif_set_mgmt_ie: vndr ie set
error :
-30
[ 4011.786190] brcmfmac: brcmf_config_ap_mgmt_ie: Set Beacon IE
Failed
You get firmware error -30 which is BCME_NOTFOUND. This can happen in
firmware upon deleting an IE. However, it is hard to say what is exactly
happening without knowing the message content that goes to firmware. You
can enable firmware console logging to see if you get any message
regarding this, eg. "wlc_del_ie: IE not in list". Do insmod with
debug=0x00100000.
if (total_ie_buf_len) {
err = brcmf_fil_bsscfg_data_set(ifp, "vndr_ie", iovar_ie_buf,
total_ie_buf_len);
if (err)
brcmf_err("vndr ie set error : %d\n", err);
}
If this happens in the .start_ap() callback the error is ignored so it
should not affect AP operation although beacon may not be setup properly.
Regards,
Arend
^ permalink raw reply
* Re: Regression with Intel 3160 AP: client not reconnecting
From: Johannes Berg @ 2017-02-24 12:13 UTC (permalink / raw)
To: Jarek Kamiński, Emmanuel Grumbach, Intel Linux Wireless
Cc: linux-wireless
In-Reply-To: <20170221213340.GA14974@Straylight.freeside.be>
Hi Jarek,
[snip]
> What might be the cause? Is there anything I can do to help debug or
> fix this?
Thanks for the detailed bug report and analysis! I can't analyse this
in depth right now, can you please file a bug on bugzilla.kernel.org?
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH 3/3] mwifiex: wake system up when receives a wake irq
From: Kalle Valo @ 2017-02-24 11:01 UTC (permalink / raw)
To: Jeffy Chen
Cc: Amitkumar Karwar, Brian Norris, Rajat Jain, netdev,
linux-wireless, linux-kernel, Nishant Sarmukadam
In-Reply-To: <1487917471-5501-3-git-send-email-jeffy.chen@rock-chips.com>
Jeffy Chen <jeffy.chen@rock-chips.com> writes:
> Currrently we are disabling this wake irq after receiving it. If this
> happens before we finish suspend and the pm event check is disabled,
> the system will continue suspending, and this irq would not work again.
>
> We may need to abort system suspend to avoid that.
>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
I only see patch 3 in patchwork. Where are patches 1 and 2?
--
Kalle Valo
^ 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