* [PATCH v3 2/6] {nl,cfg,mac}80211: enable the triggering of CSA frame in mesh
From: Chun-Yeow Yeoh @ 2013-10-03 0:33 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, linville, devel, distro11s, Chun-Yeow Yeoh
In-Reply-To: <1380760429-26100-1-git-send-email-yeohchunyeow@cozybit.com>
Allow the triggering of CSA frame using mesh interface. The
rules are more or less same with IBSS, such as not allowed to
change between the band and channel width has to be same from
the previous mode. Also, move the ieee80211_send_action_csa
to a common space so that it can be re-used by mesh interface.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
---
v2: fix return value and others (Johannes Berg)
net/mac80211/cfg.c | 19 ++++++++++
net/mac80211/ibss.c | 54 ---------------------------
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/util.c | 87 ++++++++++++++++++++++++++++++++++++++++++++
net/wireless/nl80211.c | 1 +
5 files changed, 109 insertions(+), 54 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index b455e72..438c689 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2907,6 +2907,7 @@ static int ieee80211_channel_switch(struct wiphy *wiphy, struct net_device *dev,
struct ieee80211_local *local = sdata->local;
struct ieee80211_chanctx_conf *chanctx_conf;
struct ieee80211_chanctx *chanctx;
+ struct ieee80211_if_mesh *ifmsh;
int err, num_chanctx;
if (!list_empty(&local->roc_list) || local->scanning)
@@ -2990,6 +2991,24 @@ static int ieee80211_channel_switch(struct wiphy *wiphy, struct net_device *dev,
if (err < 0)
return err;
break;
+ case NL80211_IFTYPE_MESH_POINT:
+ ifmsh = &sdata->u.mesh;
+
+ if (!ifmsh->mesh_id)
+ return -EINVAL;
+
+ if (params->chandef.width != sdata->vif.bss_conf.chandef.width)
+ return -EINVAL;
+
+ /* changes into another band are not supported */
+ if (sdata->vif.bss_conf.chandef.chan->band !=
+ params->chandef.chan->band)
+ return -EINVAL;
+
+ err = ieee80211_send_action_csa(sdata, params);
+ if (err < 0)
+ return err;
+ break;
default:
return -EOPNOTSUPP;
}
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 5ea9b3a..017e206 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -428,60 +428,6 @@ static void ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
tsf, false);
}
-static int ieee80211_send_action_csa(struct ieee80211_sub_if_data *sdata,
- struct cfg80211_csa_settings *csa_settings)
-{
- struct sk_buff *skb;
- struct ieee80211_mgmt *mgmt;
- struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
- struct ieee80211_local *local = sdata->local;
- int freq;
- int hdr_len = offsetof(struct ieee80211_mgmt, u.action.u.chan_switch) +
- sizeof(mgmt->u.action.u.chan_switch);
- u8 *pos;
-
- skb = dev_alloc_skb(local->tx_headroom + hdr_len +
- 5 + /* channel switch announcement element */
- 3); /* secondary channel offset element */
- if (!skb)
- return -1;
-
- skb_reserve(skb, local->tx_headroom);
- mgmt = (struct ieee80211_mgmt *)skb_put(skb, hdr_len);
- memset(mgmt, 0, hdr_len);
- mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
- IEEE80211_STYPE_ACTION);
-
- eth_broadcast_addr(mgmt->da);
- memcpy(mgmt->sa, sdata->vif.addr, ETH_ALEN);
- memcpy(mgmt->bssid, ifibss->bssid, ETH_ALEN);
- mgmt->u.action.category = WLAN_CATEGORY_SPECTRUM_MGMT;
- mgmt->u.action.u.chan_switch.action_code = WLAN_ACTION_SPCT_CHL_SWITCH;
- pos = skb_put(skb, 5);
- *pos++ = WLAN_EID_CHANNEL_SWITCH; /* EID */
- *pos++ = 3; /* IE length */
- *pos++ = csa_settings->block_tx ? 1 : 0; /* CSA mode */
- freq = csa_settings->chandef.chan->center_freq;
- *pos++ = ieee80211_frequency_to_channel(freq); /* channel */
- *pos++ = csa_settings->count; /* count */
-
- if (csa_settings->chandef.width == NL80211_CHAN_WIDTH_40) {
- enum nl80211_channel_type ch_type;
-
- skb_put(skb, 3);
- *pos++ = WLAN_EID_SECONDARY_CHANNEL_OFFSET; /* EID */
- *pos++ = 1; /* IE length */
- ch_type = cfg80211_get_chandef_type(&csa_settings->chandef);
- if (ch_type == NL80211_CHAN_HT40PLUS)
- *pos++ = IEEE80211_HT_PARAM_CHA_SEC_ABOVE;
- else
- *pos++ = IEEE80211_HT_PARAM_CHA_SEC_BELOW;
- }
-
- ieee80211_tx_skb(sdata, skb);
- return 0;
-}
-
int ieee80211_ibss_csa_beacon(struct ieee80211_sub_if_data *sdata,
struct cfg80211_csa_settings *csa_settings)
{
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 7f13b65..829ff7e 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1714,6 +1714,8 @@ void ieee80211_dfs_cac_timer(unsigned long data);
void ieee80211_dfs_cac_timer_work(struct work_struct *work);
void ieee80211_dfs_cac_cancel(struct ieee80211_local *local);
void ieee80211_dfs_radar_detected_work(struct work_struct *work);
+int ieee80211_send_action_csa(struct ieee80211_sub_if_data *sdata,
+ struct cfg80211_csa_settings *csa_settings);
#ifdef CONFIG_MAC80211_NOINLINE
#define debug_noinline noinline
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 133667c..5d12440 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2361,3 +2361,90 @@ u32 ieee80211_chandef_downgrade(struct cfg80211_chan_def *c)
return ret;
}
+
+int ieee80211_send_action_csa(struct ieee80211_sub_if_data *sdata,
+ struct cfg80211_csa_settings *csa_settings)
+{
+ struct sk_buff *skb;
+ struct ieee80211_mgmt *mgmt;
+ struct ieee80211_local *local = sdata->local;
+ int freq;
+ int hdr_len = offsetof(struct ieee80211_mgmt, u.action.u.chan_switch) +
+ sizeof(mgmt->u.action.u.chan_switch);
+ u8 *pos;
+
+ if (sdata->vif.type != NL80211_IFTYPE_ADHOC &&
+ sdata->vif.type != NL80211_IFTYPE_MESH_POINT)
+ return -EOPNOTSUPP;
+
+ skb = dev_alloc_skb(local->tx_headroom + hdr_len +
+ 5 + /* channel switch announcement element */
+ 3 + /* secondary channel offset element */
+ 8); /* mesh channel switch parameters element */
+ if (!skb)
+ return -ENOMEM;
+
+ skb_reserve(skb, local->tx_headroom);
+ mgmt = (struct ieee80211_mgmt *)skb_put(skb, hdr_len);
+ memset(mgmt, 0, hdr_len);
+ mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
+ IEEE80211_STYPE_ACTION);
+
+ eth_broadcast_addr(mgmt->da);
+ memcpy(mgmt->sa, sdata->vif.addr, ETH_ALEN);
+ if (ieee80211_vif_is_mesh(&sdata->vif)) {
+ memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
+ } else {
+ struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
+ memcpy(mgmt->bssid, ifibss->bssid, ETH_ALEN);
+ }
+ mgmt->u.action.category = WLAN_CATEGORY_SPECTRUM_MGMT;
+ mgmt->u.action.u.chan_switch.action_code = WLAN_ACTION_SPCT_CHL_SWITCH;
+ pos = skb_put(skb, 5);
+ *pos++ = WLAN_EID_CHANNEL_SWITCH; /* EID */
+ *pos++ = 3; /* IE length */
+ *pos++ = csa_settings->block_tx ? 1 : 0; /* CSA mode */
+ freq = csa_settings->chandef.chan->center_freq;
+ *pos++ = ieee80211_frequency_to_channel(freq); /* channel */
+ *pos++ = csa_settings->count; /* count */
+
+ if (csa_settings->chandef.width == NL80211_CHAN_WIDTH_40) {
+ enum nl80211_channel_type ch_type;
+
+ skb_put(skb, 3);
+ *pos++ = WLAN_EID_SECONDARY_CHANNEL_OFFSET; /* EID */
+ *pos++ = 1; /* IE length */
+ ch_type = cfg80211_get_chandef_type(&csa_settings->chandef);
+ if (ch_type == NL80211_CHAN_HT40PLUS)
+ *pos++ = IEEE80211_HT_PARAM_CHA_SEC_ABOVE;
+ else
+ *pos++ = IEEE80211_HT_PARAM_CHA_SEC_BELOW;
+ }
+
+ if (ieee80211_vif_is_mesh(&sdata->vif)) {
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ __le16 pre_value;
+
+ skb_put(skb, 8);
+ *pos++ = WLAN_EID_CHAN_SWITCH_PARAM; /* EID */
+ *pos++ = 6; /* IE length */
+ *pos++ = sdata->u.mesh.mshcfg.dot11MeshTTL; /* Mesh TTL */
+ *pos = 0x00; /* Mesh Flag: Tx Restrict, Initiator, Reason */
+ *pos |= WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
+ *pos++ |= csa_settings->block_tx ?
+ WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT : 0x00;
+ put_unaligned_le16(WLAN_REASON_MESH_CHAN, pos); /* Reason Cd */
+ pos += 2;
+ if (!ifmsh->pre_value)
+ ifmsh->pre_value = 1;
+ else
+ ifmsh->pre_value++;
+ pre_value = cpu_to_le16(ifmsh->pre_value);
+ memcpy(pos, &pre_value, 2); /* Precedence Value */
+ pos += 2;
+ ifmsh->chsw_init = true;
+ }
+
+ ieee80211_tx_skb(sdata, skb);
+ return 0;
+}
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index da8de5b..7bb5aca 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5650,6 +5650,7 @@ static int nl80211_channel_switch(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
break;
case NL80211_IFTYPE_ADHOC:
+ case NL80211_IFTYPE_MESH_POINT:
break;
default:
return -EOPNOTSUPP;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 0/6] Add Mesh Channel Switch Support
From: Chun-Yeow Yeoh @ 2013-10-03 0:33 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, linville, devel, distro11s, Chun-Yeow Yeoh
These are the patches required to support Mesh Basic Service Set (MBSS)
channel switch.
The design is more or less same with the IBSS. Additional procedures
or elements that are required for mesh operation are as follow:
* Add additional information element (IE) known as Mesh Channel Switch
Parameters (MCSP) required in CSA action, beacon and probe response
frames.
* Forwarding of CSA frame if the conditions defined in the standard
are met.
Limitations:
* Channel switch is only allow for the same band and also same channel
width from the previous setting.
These patches are reviewed and commented by Bob Copeland, Thomas Pedersen
and Johannes Berg. Any further comments are welcomed.
Add seperate patch for refactoring the ieee80211_parse_ch_switch_ie to
reduce the number of function paramaters.
Chun-Yeow Yeoh (6):
mac80211: process the CSA frame for mesh accordingly
{nl,cfg,mac}80211: enable the triggering of CSA frame in mesh
mac80211: add the CSA and MCSP elements in mesh beaconing
mac80211: refactor the parsing of chan switch ie
{nl,cfg,mac}80211: finalizing mesh channel switching
mac80211: process mesh channel switching using beacon
include/linux/ieee80211.h | 20 +++
net/mac80211/Kconfig | 11 ++
net/mac80211/cfg.c | 24 ++++
net/mac80211/debug.h | 10 ++
net/mac80211/ibss.c | 67 ++--------
net/mac80211/ieee80211_i.h | 29 ++++-
net/mac80211/mesh.c | 293 +++++++++++++++++++++++++++++++++++++++++++-
net/mac80211/mlme.c | 32 +++--
net/mac80211/rx.c | 5 +-
net/mac80211/spectmgmt.c | 33 +++--
net/mac80211/tx.c | 16 +++
net/mac80211/util.c | 96 +++++++++++++++
net/wireless/nl80211.c | 4 +-
13 files changed, 540 insertions(+), 100 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v3 1/6] mac80211: process the CSA frame for mesh accordingly
From: Chun-Yeow Yeoh @ 2013-10-03 0:33 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, linville, devel, distro11s, Chun-Yeow Yeoh
In-Reply-To: <1380760429-26100-1-git-send-email-yeohchunyeow@cozybit.com>
Process the CSA frame according to the procedures define in IEEE Std
802.11-2012 section 10.9.8.4.3 as follow:
* The mesh channel switch parameters element (MCSP) must be availabe.
* If the MCSP's TTL is 1, drop the frame but still process the CSA.
* If the MCSP's precedence value is less than or equal to the current
precedence value, drop the frame and do not process the CSA.
* The CSA frame is forwarded after TTL is decremented by 1 and the
initiator field is set to 0. Transmit restrict field and others
are maintained as is.
* No beacon or probe response frame are handled here.
Also, introduce the debug message used for mesh CSA purpose.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
---
v2: fix return value, typo and others (Johannes Berg)
include/linux/ieee80211.h | 20 +++++++++++
net/mac80211/Kconfig | 11 ++++++
net/mac80211/debug.h | 10 ++++++
net/mac80211/ieee80211_i.h | 4 +++
net/mac80211/mesh.c | 83 ++++++++++++++++++++++++++++++++++++++++++--
net/mac80211/util.c | 9 +++++
6 files changed, 134 insertions(+), 3 deletions(-)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 23a8877..f117427 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -696,6 +696,18 @@ struct ieee80211_sec_chan_offs_ie {
} __packed;
/**
+ * struct ieee80211_mesh_chansw_params_ie - mesh channel switch parameters IE
+ *
+ * This structure represents the "Mesh Channel Switch Paramters element"
+ */
+struct ieee80211_mesh_chansw_params_ie {
+ u8 mesh_ttl;
+ u8 mesh_flags;
+ __le16 mesh_reason;
+ __le16 mesh_pre_value;
+} __packed;
+
+/**
* struct ieee80211_wide_bw_chansw_ie - wide bandwidth channel switch IE
*/
struct ieee80211_wide_bw_chansw_ie {
@@ -750,6 +762,14 @@ enum mesh_config_capab_flags {
};
/**
+ * mesh channel switch parameters element's flag indicator
+ *
+ */
+#define WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT BIT(0)
+#define WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR BIT(1)
+#define WLAN_EID_CHAN_SWITCH_PARAM_REASON BIT(2)
+
+/**
* struct ieee80211_rann_ie
*
* This structure refers to "Root Announcement information element"
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 62535fe..bf1871e 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -258,6 +258,17 @@ config MAC80211_MESH_SYNC_DEBUG
Do not select this option.
+config MAC80211_MESH_CSA_DEBUG
+ bool "Verbose mesh channel switch debugging"
+ depends on MAC80211_DEBUG_MENU
+ depends on MAC80211_MESH
+ ---help---
+ Selecting this option causes mac80211 to print out very verbose mesh
+ channel switch debugging messages (when mac80211 is taking part in a
+ mesh network).
+
+ Do not select this option.
+
config MAC80211_MESH_PS_DEBUG
bool "Verbose mesh powersave debugging"
depends on MAC80211_DEBUG_MENU
diff --git a/net/mac80211/debug.h b/net/mac80211/debug.h
index 4ccc5ed..493d680 100644
--- a/net/mac80211/debug.h
+++ b/net/mac80211/debug.h
@@ -44,6 +44,12 @@
#define MAC80211_MESH_SYNC_DEBUG 0
#endif
+#ifdef CONFIG_MAC80211_MESH_CSA_DEBUG
+#define MAC80211_MESH_CSA_DEBUG 1
+#else
+#define MAC80211_MESH_CSA_DEBUG 0
+#endif
+
#ifdef CONFIG_MAC80211_MESH_PS_DEBUG
#define MAC80211_MESH_PS_DEBUG 1
#else
@@ -157,6 +163,10 @@ do { \
_sdata_dbg(MAC80211_MESH_SYNC_DEBUG, \
sdata, fmt, ##__VA_ARGS__)
+#define mcsa_dbg(sdata, fmt, ...) \
+ _sdata_dbg(MAC80211_MESH_CSA_DEBUG, \
+ sdata, fmt, ##__VA_ARGS__)
+
#define mps_dbg(sdata, fmt, ...) \
_sdata_dbg(MAC80211_MESH_PS_DEBUG, \
sdata, fmt, ##__VA_ARGS__)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 3a87c89..7f13b65 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -598,6 +598,9 @@ struct ieee80211_if_mesh {
int ps_peers_light_sleep;
int ps_peers_deep_sleep;
struct ps_data ps;
+ /* Channel Switching Support */
+ bool chsw_init;
+ u16 pre_value;
};
#ifdef CONFIG_MAC80211_MESH
@@ -1239,6 +1242,7 @@ struct ieee802_11_elems {
const struct ieee80211_timeout_interval_ie *timeout_int;
const u8 *opmode_notif;
const struct ieee80211_sec_chan_offs_ie *sec_chan_offs;
+ const struct ieee80211_mesh_chansw_params_ie *mesh_chansw_params_ie;
/* length of them, respectively */
u8 ssid_len;
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 707ac61..0a3ccaa 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -920,6 +920,82 @@ static void ieee80211_mesh_rx_bcn_presp(struct ieee80211_sub_if_data *sdata,
stype, mgmt, &elems, rx_status);
}
+static int mesh_fwd_csa_frame(struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_mgmt *mgmt, size_t len)
+{
+ struct ieee80211_mgmt *mgmt_fwd;
+ struct sk_buff *skb;
+ struct ieee80211_local *local = sdata->local;
+ u8 *pos = mgmt->u.action.u.chan_switch.variable;
+ size_t offset_ttl;
+
+ skb = dev_alloc_skb(local->tx_headroom + len);
+ if (!skb)
+ return -ENOMEM;
+ skb_reserve(skb, local->tx_headroom);
+ mgmt_fwd = (struct ieee80211_mgmt *) skb_put(skb, len);
+
+ /* offset_ttl is based on whether the secondary channel
+ * offset is available or not. Substract 1 from the mesh TTL
+ * and disable the initiator flag before forwarding.
+ */
+ offset_ttl = (len < 42) ? 7 : 10;
+ *(pos + offset_ttl) -= 1;
+ *(pos + offset_ttl + 1) &= ~WLAN_EID_CHAN_SWITCH_PARAM_INITIATOR;
+
+ memcpy(mgmt_fwd, mgmt, len);
+ eth_broadcast_addr(mgmt_fwd->da);
+ memcpy(mgmt_fwd->sa, sdata->vif.addr, ETH_ALEN);
+ memcpy(mgmt_fwd->bssid, sdata->vif.addr, ETH_ALEN);
+
+ ieee80211_tx_skb(sdata, skb);
+ return 0;
+}
+
+static void mesh_rx_csa_frame(struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_mgmt *mgmt, size_t len)
+{
+ struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
+ struct ieee802_11_elems elems;
+ u16 pre_value;
+ bool block_tx, fwd_csa = true;
+ size_t baselen;
+ u8 *pos, ttl;
+
+ if (mgmt->u.action.u.measurement.action_code !=
+ WLAN_ACTION_SPCT_CHL_SWITCH)
+ return;
+
+ pos = mgmt->u.action.u.chan_switch.variable;
+ baselen = offsetof(struct ieee80211_mgmt,
+ u.action.u.chan_switch.variable);
+ ieee802_11_parse_elems(pos, len - baselen, false, &elems);
+
+ ttl = elems.mesh_chansw_params_ie->mesh_ttl;
+ if (!--ttl)
+ fwd_csa = false;
+
+ pre_value = le16_to_cpu(elems.mesh_chansw_params_ie->mesh_pre_value);
+ if (ifmsh->pre_value >= pre_value)
+ return;
+
+ ifmsh->pre_value = pre_value;
+
+ /* forward or re-broadcast the CSA frame */
+ if (fwd_csa) {
+ if (mesh_fwd_csa_frame(sdata, mgmt, len) < 0)
+ mcsa_dbg(sdata, "Failed to forward the CSA frame");
+ }
+
+ /* block the Tx only after forwarding the CSA frame if required */
+ block_tx = elems.mesh_chansw_params_ie->mesh_flags &
+ WLAN_EID_CHAN_SWITCH_PARAM_TX_RESTRICT;
+ if (block_tx)
+ ieee80211_stop_queues_by_reason(&sdata->local->hw,
+ IEEE80211_MAX_QUEUE_MAP,
+ IEEE80211_QUEUE_STOP_REASON_CSA);
+}
+
static void ieee80211_mesh_rx_mgmt_action(struct ieee80211_sub_if_data *sdata,
struct ieee80211_mgmt *mgmt,
size_t len,
@@ -939,6 +1015,9 @@ static void ieee80211_mesh_rx_mgmt_action(struct ieee80211_sub_if_data *sdata,
if (mesh_action_is_path_sel(mgmt))
mesh_rx_path_sel_frame(sdata, mgmt, len);
break;
+ case WLAN_CATEGORY_SPECTRUM_MGMT:
+ mesh_rx_csa_frame(sdata, mgmt, len);
+ break;
}
}
@@ -1056,13 +1135,11 @@ void ieee80211_mesh_init_sdata(struct ieee80211_sub_if_data *sdata)
(unsigned long) sdata);
ifmsh->accepting_plinks = true;
- ifmsh->preq_id = 0;
- ifmsh->sn = 0;
- ifmsh->num_gates = 0;
atomic_set(&ifmsh->mpaths, 0);
mesh_rmc_init(sdata);
ifmsh->last_preq = jiffies;
ifmsh->next_perr = jiffies;
+ ifmsh->chsw_init = false;
/* Allocate all mesh structures when creating the first mesh interface. */
if (!mesh_allocated)
ieee80211s_init();
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 3c8283b..133667c 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -743,6 +743,7 @@ u32 ieee802_11_parse_elems_crc(const u8 *start, size_t len, bool action,
case WLAN_EID_TIMEOUT_INTERVAL:
case WLAN_EID_SECONDARY_CHANNEL_OFFSET:
case WLAN_EID_WIDE_BW_CHANNEL_SWITCH:
+ case WLAN_EID_CHAN_SWITCH_PARAM:
/*
* not listing WLAN_EID_CHANNEL_SWITCH_WRAPPER -- it seems possible
* that if the content gets bigger it might be needed more than once
@@ -908,6 +909,14 @@ u32 ieee802_11_parse_elems_crc(const u8 *start, size_t len, bool action,
}
elems->sec_chan_offs = (void *)pos;
break;
+ case WLAN_EID_CHAN_SWITCH_PARAM:
+ if (elen !=
+ sizeof(*elems->mesh_chansw_params_ie)) {
+ elem_parse_failed = true;
+ break;
+ }
+ elems->mesh_chansw_params_ie = (void *)pos;
+ break;
case WLAN_EID_WIDE_BW_CHANNEL_SWITCH:
if (!action ||
elen != sizeof(*elems->wide_bw_chansw_ie)) {
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH for-3.12 2/3] bcma: make bcma_core_pci_{up,down}() callable from atomic context
From: Tod Jackson @ 2013-10-02 23:02 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: Arend van Spriel, John W. Linville, linux-wireless, stable,
Joe Perches, Rafal Milecki
In-Reply-To: <524C092A.4090801@hauke-m.de>
The warnings are gone, indeed. brcmsmac is now working great for me.
(Late for me too... for some reason this e-mail was in my spam
folder... stupid gmail!)
On 10/2/13, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> On 09/25/2013 12:11 PM, Arend van Spriel wrote:
>> This patch removes the bcma_core_pci_power_save() call from
>> the bcma_core_pci_{up,down}() functions as it tries to schedule
>> thus requiring to call them from non-atomic context. The function
>> bcma_core_pci_power_save() is now exported so the calling module
>> can explicitly use it in non-atomic context. This fixes the
>> 'scheduling while atomic' issue reported by Tod Jackson and
>> Joe Perches.
>>
>> [ 13.210710] BUG: scheduling while atomic: dhcpcd/1800/0x00000202
>> [ 13.210718] Modules linked in: brcmsmac nouveau coretemp kvm_intel kvm
>> cordic brcmutil bcma dell_wmi atl1c ttm mxm_wmi wmi
>> [ 13.210756] CPU: 2 PID: 1800 Comm: dhcpcd Not tainted 3.11.0-wl #1
>> [ 13.210762] Hardware name: Alienware M11x R2/M11x R2, BIOS A04
>> 11/23/2010
>> [ 13.210767] ffff880177c92c40 ffff880170fd1948 ffffffff8169af5b
>> 0000000000000007
>> [ 13.210777] ffff880170fd1ab0 ffff880170fd1958 ffffffff81697ee2
>> ffff880170fd19d8
>> [ 13.210785] ffffffff816a19f5 00000000000f4240 000000000000d080
>> ffff880170fd1fd8
>> [ 13.210794] Call Trace:
>> [ 13.210813] [<ffffffff8169af5b>] dump_stack+0x4f/0x84
>> [ 13.210826] [<ffffffff81697ee2>] __schedule_bug+0x43/0x51
>> [ 13.210837] [<ffffffff816a19f5>] __schedule+0x6e5/0x810
>> [ 13.210845] [<ffffffff816a1c34>] schedule+0x24/0x70
>> [ 13.210855] [<ffffffff816a04fc>]
>> schedule_hrtimeout_range_clock+0x10c/0x150
>> [ 13.210867] [<ffffffff810684e0>] ? update_rmtp+0x60/0x60
>> [ 13.210877] [<ffffffff8106915f>] ? hrtimer_start_range_ns+0xf/0x20
>> [ 13.210887] [<ffffffff816a054e>] schedule_hrtimeout_range+0xe/0x10
>> [ 13.210897] [<ffffffff8104f6fb>] usleep_range+0x3b/0x40
>> [ 13.210910] [<ffffffffa00371af>]
>> bcma_pcie_mdio_set_phy.isra.3+0x4f/0x80 [bcma]
>> [ 13.210921] [<ffffffffa003729f>] bcma_pcie_mdio_write.isra.4+0xbf/0xd0
>> [bcma]
>> [ 13.210932] [<ffffffffa0037498>]
>> bcma_pcie_mdio_writeread.isra.6.constprop.13+0x18/0x30 [bcma]
>> [ 13.210942] [<ffffffffa00374ee>] bcma_core_pci_power_save+0x3e/0x80
>> [bcma]
>> [ 13.210953] [<ffffffffa003765d>] bcma_core_pci_up+0x2d/0x60 [bcma]
>> [ 13.210975] [<ffffffffa03dc17c>] brcms_c_up+0xfc/0x430 [brcmsmac]
>> [ 13.210989] [<ffffffffa03d1a7d>] brcms_up+0x1d/0x20 [brcmsmac]
>> [ 13.211003] [<ffffffffa03d2498>] brcms_ops_start+0x298/0x340
>> [brcmsmac]
>> [ 13.211020] [<ffffffff81600a12>] ?
>> cfg80211_netdev_notifier_call+0xd2/0x5f0
>> [ 13.211030] [<ffffffff815fa53d>] ? packet_notifier+0xad/0x1d0
>> [ 13.211064] [<ffffffff81656e75>] ieee80211_do_open+0x325/0xf80
>> [ 13.211076] [<ffffffff8106ac09>] ? __raw_notifier_call_chain+0x9/0x10
>> [ 13.211086] [<ffffffff81657b41>] ieee80211_open+0x71/0x80
>> [ 13.211101] [<ffffffff81526267>] __dev_open+0x87/0xe0
>> [ 13.211109] [<ffffffff8152650c>] __dev_change_flags+0x9c/0x180
>> [ 13.211117] [<ffffffff815266a3>] dev_change_flags+0x23/0x70
>> [ 13.211127] [<ffffffff8158cd68>] devinet_ioctl+0x5b8/0x6a0
>> [ 13.211136] [<ffffffff8158d5c5>] inet_ioctl+0x75/0x90
>> [ 13.211147] [<ffffffff8150b38b>] sock_do_ioctl+0x2b/0x70
>> [ 13.211155] [<ffffffff8150b681>] sock_ioctl+0x71/0x2a0
>> [ 13.211169] [<ffffffff8114ed47>] do_vfs_ioctl+0x87/0x520
>> [ 13.211180] [<ffffffff8113f159>] ? ____fput+0x9/0x10
>> [ 13.211198] [<ffffffff8106228c>] ? task_work_run+0x9c/0xd0
>> [ 13.211202] [<ffffffff8114f271>] SyS_ioctl+0x91/0xb0
>> [ 13.211208] [<ffffffff816aa252>] system_call_fastpath+0x16/0x1b
>> [ 13.211217] NOHZ: local_softirq_pending 202
>>
>> The issue was introduced in v3.11 kernel by following commit:
>>
>> commit aa51e598d04c6acf5477934cd6383f5a17ce9029
>> Author: Hauke Mehrtens <hauke@hauke-m.de>
>> Date: Sat Aug 24 00:32:31 2013 +0200
>>
>> brcmsmac: use bcma PCIe up and down functions
>>
>> replace the calls to bcma_core_pci_extend_L1timer() by calls to the
>> newly introduced bcma_core_pci_ip() and bcma_core_pci_down()
>>
>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>> Cc: Arend van Spriel <arend@broadcom.com>
>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>
>> This fix has been discussed with Hauke Mehrtens [1] selection
>> option 3) and is intended for v3.12.
>>
>> Ref:
>> [1] http://mid.gmane.org/5239B12D.3040206@hauke-m.de
>>
>> Cc: <stable@vger.kernel.org> # 3.11.x
>> Cc: Tod Jackson <tod.jackson@gmail.com>
>> Cc: Joe Perches <joe@perches.com>
>> Cc: Rafal Milecki <zajec5@gmail.com>
>> Cc: Hauke Mehrtens <hauke@hauke-m.de>
>> Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
>> Signed-off-by: Arend van Spriel <arend@broadcom.com>
>
> Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
>
>
> Hi,
>
> This is a little late but I am ok with the brcmsmac patch and the bcma
> patch, feel free to add my Acked-by. This should go into 3.12 and 3.13+.
>
> Hauke
>
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix merge damage
From: John W. Linville @ 2013-10-02 18:50 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1380706904.13329.15.camel@jlt4.sipsolutions.net>
On Wed, Oct 02, 2013 at 11:41:44AM +0200, Johannes Berg wrote:
> On Mon, 2013-09-30 at 11:02 +0200, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > The merge b35c8097 seems to have lost commit eabc4ac5d,
> > put the code back.
>
> I'm rebasing my tree on -rc1, which actually includes the merge commit,
> so it still makes sense for me to include this commit - I've done that
> now. Sorry for the confusion.
I'm not sure I follow -- please don't base on anything I don't already
have in my tree if you want me to pull from you.
I applied the patch to wireless-next today, FWIW.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix merge damage
From: John W. Linville @ 2013-10-02 18:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1380706904.13329.15.camel@jlt4.sipsolutions.net>
On Wed, Oct 02, 2013 at 11:41:44AM +0200, Johannes Berg wrote:
> On Mon, 2013-09-30 at 11:02 +0200, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > The merge b35c8097 seems to have lost commit eabc4ac5d,
> > put the code back.
>
> I'm rebasing my tree on -rc1, which actually includes the merge commit,
> so it still makes sense for me to include this commit - I've done that
> now. Sorry for the confusion.
I'm not sure I follow -- please don't base on anything I don't already
have in my tree if you want me to pull from you.
I applied the patch to wireless-next today, FWIW.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net-next] net:drivers/net: Miscellaneous conversions to ETH_ALEN
From: David Miller @ 2013-10-02 21:05 UTC (permalink / raw)
To: joe
Cc: netdev, linux-kernel, linuxppc-dev, e1000-devel, linux-usb,
ath10k, linux-wireless, wil6210, b43-dev, brcm80211-dev-list,
bridge, netfilter-devel
In-Reply-To: <1380679480.2081.24.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Tue, 01 Oct 2013 19:04:40 -0700
> Convert the memset/memcpy uses of 6 to ETH_ALEN
> where appropriate.
>
> Also convert some struct definitions and u8 array
> declarations of [6] to ETH_ALEN.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Looks fine, applied, thanks Joe.
^ permalink raw reply
* [PATCH 2/2] rt2x00: rt2800lib: remove TXPOWER_DELTA entry from extended EEPROM map
From: Gabor Juhos @ 2013-10-02 19:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
In-Reply-To: <1380742914-22486-1-git-send-email-juhosg@openwrt.org>
The TXPOWER_DELTA field of the regular EEPROM
stores the TX power compensation value for HT40.
The extended EEPROM has no such field, it stores
separate TX power values for HT20 and for HT40.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index c979bb7..315f4af 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -278,7 +278,6 @@ static const unsigned int rt2800_eeprom_map_ext[EEPROM_WORD_COUNT] = {
[EEPROM_LNA] = 0x0026,
[EEPROM_EXT_LNA2] = 0x0027,
[EEPROM_RSSI_BG] = 0x0028,
- [EEPROM_TXPOWER_DELTA] = 0x0028, /* Overlaps with RSSI_BG */
[EEPROM_RSSI_BG2] = 0x0029,
[EEPROM_RSSI_A] = 0x002a,
[EEPROM_RSSI_A2] = 0x002b,
--
1.7.10
^ permalink raw reply related
* [PATCH 1/2] rt2x00: rt2800lib: remove TXMIXER_GAIN entries from the extended EEPROM map
From: Gabor Juhos @ 2013-10-02 19:41 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, users, Gabor Juhos
The comments are indicating the TXMIXER_GAIN_BG and
the TXMIXED_GAIN_A entries are overlapping with the
RSSI_BG2 and RSSI_A2 entries in the extended EEPROM
map. This is not correct, becuase the upper byte of
the RSSI_BG2 and RSSI_A2 entries are reserved. There
are no TX mixer gain values are stored at all in the
extended EEPROM.
Remove the initialization of these entries from the
extended EEPROM map to reflect this.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/rt2x00/rt2800lib.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index c706ddc..c979bb7 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -280,10 +280,8 @@ static const unsigned int rt2800_eeprom_map_ext[EEPROM_WORD_COUNT] = {
[EEPROM_RSSI_BG] = 0x0028,
[EEPROM_TXPOWER_DELTA] = 0x0028, /* Overlaps with RSSI_BG */
[EEPROM_RSSI_BG2] = 0x0029,
- [EEPROM_TXMIXER_GAIN_BG] = 0x0029, /* Overlaps with RSSI_BG2 */
[EEPROM_RSSI_A] = 0x002a,
[EEPROM_RSSI_A2] = 0x002b,
- [EEPROM_TXMIXER_GAIN_A] = 0x002b, /* Overlaps with RSSI_A2 */
[EEPROM_TXPOWER_BG1] = 0x0030,
[EEPROM_TXPOWER_BG2] = 0x0037,
[EEPROM_EXT_TXPOWER_BG3] = 0x003e,
--
1.7.10
^ permalink raw reply related
* [ath3k] Support for Asus BT USB dongle (0cf3:3005)
From: Daniel Kamil Kozar @ 2013-10-02 17:59 UTC (permalink / raw)
To: linux-wireless
Hello,
The Bluetooth dongle installed inside my Asus K53SV laptop seems to be
unsupported. The USB VID:PID is 0cf3:3005, and it's identified by
lsusb as the following :
Bus 001 Device 006: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
However, I didn't see the VID:PID mentioned anywhere in the source of
ath3k. After adding the device's identifier to the source, thus
forcing it to be recognized as an "Atheros AR3011 with sflash
firmware", I got the following message from the driver :
ath3k: probe of 1-1.1:1.0 failed with error -32
How could I help with developing the support for this device?
Kind regards,
-dkk
^ permalink raw reply
* Re: [PATCH v2] mac80211: implement STA CSA for drivers using channel contexts
From: Johannes Berg @ 2013-10-02 16:20 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless
In-Reply-To: <1378044951-13682-1-git-send-email-arik@wizery.com>
On Sun, 2013-09-01 at 17:15 +0300, Arik Nemtsov wrote:
> Limit the current implementation to a single channel context used by
> a single vif, thereby avoiding multi-vif/channel complexities.
>
> Reuse the main function from AP CSA code, but move a portion out in
> order to fit the STA scenario.
>
> Add a new mac80211 HW flag so we don't break devices that don't support
> channel switch with channel-contexts. The new behavior will be opt-in.
Applied, sorry for the delay.
johannes
^ permalink raw reply
* Re: [PATCH 2/4] nl80211/cfg80211: enable DFS for IBSS mode
From: Johannes Berg @ 2013-10-02 16:07 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <20131002124006.GA23903@pandem0nium>
On Wed, 2013-10-02 at 14:40 +0200, Simon Wunderlich wrote:
> > > NL80211_ATTR_CONTROL_PORT_DFS attribute when joining the IBSS.
> >
> > I don't like that name, it makes no sense. This has nothing to do with
> > the port control (802.1X-style) at all.
>
> How about NL80211_ATTR_DFS_CAPABLE instead?
That seems also confusing, like a hardware capability or something...
Maybe rather "NL80211_ATTR_HANDLE_DFS" or something?
> Yeah, I should document this a little more: Userspace should react to
> radar events and apprioately switch the channel when this happens. As
> non-capable tools (like wpa_supplicant in it's current state) do not
> react on radar events but might select DFS channels when available, there
> might be non-conforming behaviour. Therefore I'm introducing this flag.
>
> Userspace programs are supposed to set this flag when they have channel
> management and radar avoidance/channel change functionality is implemented
> to unlock DFS channels.
I think we may we want some safeguard, e.g. only give the userspace a
second or so to react and tear down the IBSS otherwise? Even with
userspace that is capable of handling it, it could have crashed and the
IBSS will continue operating in that case since we don't tear down the
IBSS when it crashes. Or we could do that, require userspace to keep the
nl80211 socket open, but the timing seems easier?
> I can resend the patchset with some more documentation on this.
Thanks.
johannes
^ permalink raw reply
* pull-request: iwlwifi-fixes 2013-10-02
From: Johannes Berg @ 2013-10-02 16:04 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]
John,
Here are a few fixes for iwlwifi.
I have a fix for WoWLAN/D3, a PCIe device fix, we're removing a warning,
there's a fix for RF-kill while scanning (which goes together with a
mac80211 fix) and last but not least we have many new PCI IDs.
Let me know if there's any problem.
johannes
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git for-john
for you to fetch changes up to 5a3e9f7f8c8768b5f7df81100c684e4cd00a6eb5:
iwlwifi: mvm: call ieee80211_scan_completed when needed (2013-10-02 11:25:50 +0200)
----------------------------------------------------------------
Alexander Bondar (1):
iwlwifi: mvm: Disable uAPSD for D3 image
Emmanuel Grumbach (4):
iwlwifi: pcie: don't reset the TX queue counter
iwlwifi: don't WARN on host commands sent when firmware is dead
iwlwifi: pcie: add SKUs for 6000, 6005 and 6235 series
iwlwifi: mvm: call ieee80211_scan_completed when needed
Matti Gottlieb (1):
iwlwifi: pcie: add new SKUs for 7000 & 3160 NIC series
drivers/net/wireless/iwlwifi/iwl-6000.c | 6 +++++
drivers/net/wireless/iwlwifi/iwl-config.h | 1 +
drivers/net/wireless/iwlwifi/iwl-trans.h | 6 +++--
drivers/net/wireless/iwlwifi/mvm/power.c | 5 +++-
drivers/net/wireless/iwlwifi/mvm/scan.c | 12 ++++++++-
drivers/net/wireless/iwlwifi/pcie/drv.c | 42 +++++++++++++++++++++++++++++++
drivers/net/wireless/iwlwifi/pcie/tx.c | 2 ++
7 files changed, 70 insertions(+), 4 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Lorenzo Bianconi @ 2013-10-02 13:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <1380718874.13329.17.camel@jlt4.sipsolutions.net>
I am testing some personal hostapd changes in order to add CAC/NOP
management using methods added by Simon
2013/10/2 Johannes Berg <johannes@sipsolutions.net>:
> On Wed, 2013-10-02 at 14:52 +0200, Lorenzo Bianconi wrote:
>> I am not using latest mac80211/hostapd (in particular
>> compat-wireless-2013-04-16/hostapd-20130807) because I have to port
>> some personal stuff. In this scenario I was not able to establish an
>> AP/STA connection on DFS channel. Anyway I will update these packages.
>
> But that old hostapd doesn't support DFS to start with, does it? I'm
> confused.
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Johannes Berg @ 2013-10-02 13:01 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <CAA2SeNLFSN0tAyABk=MoFDxS6purc6Tgx6R-U5xhuRJZRCZ6ig@mail.gmail.com>
On Wed, 2013-10-02 at 14:52 +0200, Lorenzo Bianconi wrote:
> I am not using latest mac80211/hostapd (in particular
> compat-wireless-2013-04-16/hostapd-20130807) because I have to port
> some personal stuff. In this scenario I was not able to establish an
> AP/STA connection on DFS channel. Anyway I will update these packages.
But that old hostapd doesn't support DFS to start with, does it? I'm
confused.
johannes
^ permalink raw reply
* [PATCH] net: wireless: wl1251: update firmware path
From: Felipe Balbi @ 2013-10-02 13:00 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless, Linux Kernel Mailing List, Felipe Balbi
TI firmwares are located under ti-connectivity
directory. Update path to make sure driver can
find and load firmware blob.
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
drivers/net/wireless/ti/wl1251/wl1251.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wl1251/wl1251.h b/drivers/net/wireless/ti/wl1251/wl1251.h
index fd02060..2c3bd1b 100644
--- a/drivers/net/wireless/ti/wl1251/wl1251.h
+++ b/drivers/net/wireless/ti/wl1251/wl1251.h
@@ -424,8 +424,8 @@ void wl1251_disable_interrupts(struct wl1251 *wl);
#define CHIP_ID_1271_PG10 (0x4030101)
#define CHIP_ID_1271_PG20 (0x4030111)
-#define WL1251_FW_NAME "wl1251-fw.bin"
-#define WL1251_NVS_NAME "wl1251-nvs.bin"
+#define WL1251_FW_NAME "ti-connectivity/wl1251-fw.bin"
+#define WL1251_NVS_NAME "ti-connectivity/wl1251-nvs.bin"
#define WL1251_POWER_ON_SLEEP 10 /* in milliseconds */
--
1.8.3.4.840.g6a90778
^ permalink raw reply related
* Re: [PATCH] ath10k: fix scheduling while atomic bug on config
From: Kalle Valo @ 2013-10-02 13:00 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQnQVE_YUrrtfFCeQSj4tmccbA9cG_ZMdHisx4C-mJfqkg@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 2 October 2013 11:51, Michal Kazior <michal.kazior@tieto.com> wrote:
>> Recent WMI/HTC changes introduces this bug because
>> now WMI commands can sleep.
>>
>> Use appropriate interface iteration function.
>>
>> Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> Self NACK.
>
> I've posted this too soon. This patch can lead to deadlocks on
> iflist_mtx in some cases.
Ok, thanks for letting me know. I'll drop the patch from my queue.
--
Kalle Valo
^ permalink raw reply
* [GIT PULL] firmware: wl1251 firmware binary
From: Felipe Balbi @ 2013-10-02 12:55 UTC (permalink / raw)
To: Felipe Balbi, dwmw2, ben
Cc: Luca Coelho, ben, Linux Kernel Mailing List, linux-wireless,
Pavel Machek
In-Reply-To: <20130925135943.GI10746@radagast>
[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]
Hi,
here's a pull request for wl4 firmware. I'll send a patch for wl1251
driver updating firmware load path.
The following changes since commit b8ac7c7e27dcd13fa3c843aaf62457e9c57ea4db:
linux-firmware: Add Brocade FC/FCOE Adapter firmware files (2013-09-30 04:53:32 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/linux-firmware.git wilink4
for you to fetch changes up to d726804dbc8dad88587b6be17716714cd91ed86c:
ti-connectivity: add wl1251 firmware and license (2013-10-02 06:55:39 -0500)
----------------------------------------------------------------
Felipe Balbi (1):
ti-connectivity: add wl1251 firmware and license
LICENCE.wl1251 | 59 +++++++++++++++++++++++++++++++++++++++++
WHENCE | 18 +++++++++++++
ti-connectivity/wl1251-fw.bin | Bin 0 -> 194180 bytes
ti-connectivity/wl1251-nvs.bin | Bin 0 -> 752 bytes
4 files changed, 77 insertions(+)
create mode 100644 LICENCE.wl1251
create mode 100644 ti-connectivity/wl1251-fw.bin
create mode 100644 ti-connectivity/wl1251-nvs.bin
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Lorenzo Bianconi @ 2013-10-02 12:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <1380708715.13329.16.camel@jlt4.sipsolutions.net>
I am not using latest mac80211/hostapd (in particular
compat-wireless-2013-04-16/hostapd-20130807) because I have to port
some personal stuff. In this scenario I was not able to establish an
AP/STA connection on DFS channel. Anyway I will update these packages.
Lorenzo
2013/10/2 Johannes Berg <johannes@sipsolutions.net>:
> On Wed, 2013-10-02 at 12:07 +0200, Lorenzo Bianconi wrote:
>> Before start beaconing cfg80211_reg_can_beacon() verifies the channel
>> is CAC checked and available calling cfg80211_secondary_chans_ok().
>> Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
>> period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
>> frames on DFS channels causing association failures.
>
> I don't see how this can cause association failures? Please explain.
> DFS-capable hostapd doesn't use monitor interfaces with mac80211 any
> more.
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ permalink raw reply
* Re: [PATCH 2/4] nl80211/cfg80211: enable DFS for IBSS mode
From: Simon Wunderlich @ 2013-10-02 12:40 UTC (permalink / raw)
To: Johannes Berg
Cc: Simon Wunderlich, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1380625757.14430.22.camel@jlt4.sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Tue, Oct 01, 2013 at 01:09:17PM +0200, Johannes Berg wrote:
> On Tue, 2013-09-03 at 19:43 +0200, Simon Wunderlich wrote:
> > To use DFS in IBSS mode, userspace is required to react to radar events.
> > It can inform nl80211 that it is capable of doing so by adding a
> > NL80211_ATTR_CONTROL_PORT_DFS attribute when joining the IBSS.
>
> I don't like that name, it makes no sense. This has nothing to do with
> the port control (802.1X-style) at all.
>
How about NL80211_ATTR_DFS_CAPABLE instead?
> > If this attribute is supplied, DFS channels may be used if the driver
> > supports it. Support will be checked even if a channel without DFS will
> > be joined, as the channel might change later due to scan activity or
> > channel switch announcements.
>
> You also really should document *what* is required of userspace here.
> You're kinda saying this needs to be implemented, but not saying what
> needs to be done. I can't even tell - what does it really have to do?
Yeah, I should document this a little more: Userspace should react to
radar events and apprioately switch the channel when this happens. As
non-capable tools (like wpa_supplicant in it's current state) do not
react on radar events but might select DFS channels when available, there
might be non-conforming behaviour. Therefore I'm introducing this flag.
Userspace programs are supposed to set this flag when they have channel
management and radar avoidance/channel change functionality is implemented
to unlock DFS channels.
> Don't you implement most of it in patches 3 and 4 anyway in the kernel?
Nope, I don't.
I can resend the patchset with some more documentation on this.
Thanks,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH for-3.12 2/3] bcma: make bcma_core_pci_{up,down}() callable from atomic context
From: Hauke Mehrtens @ 2013-10-02 11:53 UTC (permalink / raw)
To: Arend van Spriel, John W. Linville
Cc: linux-wireless, stable, Tod Jackson, Joe Perches, Rafal Milecki
In-Reply-To: <1380103864-10447-3-git-send-email-arend@broadcom.com>
On 09/25/2013 12:11 PM, Arend van Spriel wrote:
> This patch removes the bcma_core_pci_power_save() call from
> the bcma_core_pci_{up,down}() functions as it tries to schedule
> thus requiring to call them from non-atomic context. The function
> bcma_core_pci_power_save() is now exported so the calling module
> can explicitly use it in non-atomic context. This fixes the
> 'scheduling while atomic' issue reported by Tod Jackson and
> Joe Perches.
>
> [ 13.210710] BUG: scheduling while atomic: dhcpcd/1800/0x00000202
> [ 13.210718] Modules linked in: brcmsmac nouveau coretemp kvm_intel kvm cordic brcmutil bcma dell_wmi atl1c ttm mxm_wmi wmi
> [ 13.210756] CPU: 2 PID: 1800 Comm: dhcpcd Not tainted 3.11.0-wl #1
> [ 13.210762] Hardware name: Alienware M11x R2/M11x R2, BIOS A04 11/23/2010
> [ 13.210767] ffff880177c92c40 ffff880170fd1948 ffffffff8169af5b 0000000000000007
> [ 13.210777] ffff880170fd1ab0 ffff880170fd1958 ffffffff81697ee2 ffff880170fd19d8
> [ 13.210785] ffffffff816a19f5 00000000000f4240 000000000000d080 ffff880170fd1fd8
> [ 13.210794] Call Trace:
> [ 13.210813] [<ffffffff8169af5b>] dump_stack+0x4f/0x84
> [ 13.210826] [<ffffffff81697ee2>] __schedule_bug+0x43/0x51
> [ 13.210837] [<ffffffff816a19f5>] __schedule+0x6e5/0x810
> [ 13.210845] [<ffffffff816a1c34>] schedule+0x24/0x70
> [ 13.210855] [<ffffffff816a04fc>] schedule_hrtimeout_range_clock+0x10c/0x150
> [ 13.210867] [<ffffffff810684e0>] ? update_rmtp+0x60/0x60
> [ 13.210877] [<ffffffff8106915f>] ? hrtimer_start_range_ns+0xf/0x20
> [ 13.210887] [<ffffffff816a054e>] schedule_hrtimeout_range+0xe/0x10
> [ 13.210897] [<ffffffff8104f6fb>] usleep_range+0x3b/0x40
> [ 13.210910] [<ffffffffa00371af>] bcma_pcie_mdio_set_phy.isra.3+0x4f/0x80 [bcma]
> [ 13.210921] [<ffffffffa003729f>] bcma_pcie_mdio_write.isra.4+0xbf/0xd0 [bcma]
> [ 13.210932] [<ffffffffa0037498>] bcma_pcie_mdio_writeread.isra.6.constprop.13+0x18/0x30 [bcma]
> [ 13.210942] [<ffffffffa00374ee>] bcma_core_pci_power_save+0x3e/0x80 [bcma]
> [ 13.210953] [<ffffffffa003765d>] bcma_core_pci_up+0x2d/0x60 [bcma]
> [ 13.210975] [<ffffffffa03dc17c>] brcms_c_up+0xfc/0x430 [brcmsmac]
> [ 13.210989] [<ffffffffa03d1a7d>] brcms_up+0x1d/0x20 [brcmsmac]
> [ 13.211003] [<ffffffffa03d2498>] brcms_ops_start+0x298/0x340 [brcmsmac]
> [ 13.211020] [<ffffffff81600a12>] ? cfg80211_netdev_notifier_call+0xd2/0x5f0
> [ 13.211030] [<ffffffff815fa53d>] ? packet_notifier+0xad/0x1d0
> [ 13.211064] [<ffffffff81656e75>] ieee80211_do_open+0x325/0xf80
> [ 13.211076] [<ffffffff8106ac09>] ? __raw_notifier_call_chain+0x9/0x10
> [ 13.211086] [<ffffffff81657b41>] ieee80211_open+0x71/0x80
> [ 13.211101] [<ffffffff81526267>] __dev_open+0x87/0xe0
> [ 13.211109] [<ffffffff8152650c>] __dev_change_flags+0x9c/0x180
> [ 13.211117] [<ffffffff815266a3>] dev_change_flags+0x23/0x70
> [ 13.211127] [<ffffffff8158cd68>] devinet_ioctl+0x5b8/0x6a0
> [ 13.211136] [<ffffffff8158d5c5>] inet_ioctl+0x75/0x90
> [ 13.211147] [<ffffffff8150b38b>] sock_do_ioctl+0x2b/0x70
> [ 13.211155] [<ffffffff8150b681>] sock_ioctl+0x71/0x2a0
> [ 13.211169] [<ffffffff8114ed47>] do_vfs_ioctl+0x87/0x520
> [ 13.211180] [<ffffffff8113f159>] ? ____fput+0x9/0x10
> [ 13.211198] [<ffffffff8106228c>] ? task_work_run+0x9c/0xd0
> [ 13.211202] [<ffffffff8114f271>] SyS_ioctl+0x91/0xb0
> [ 13.211208] [<ffffffff816aa252>] system_call_fastpath+0x16/0x1b
> [ 13.211217] NOHZ: local_softirq_pending 202
>
> The issue was introduced in v3.11 kernel by following commit:
>
> commit aa51e598d04c6acf5477934cd6383f5a17ce9029
> Author: Hauke Mehrtens <hauke@hauke-m.de>
> Date: Sat Aug 24 00:32:31 2013 +0200
>
> brcmsmac: use bcma PCIe up and down functions
>
> replace the calls to bcma_core_pci_extend_L1timer() by calls to the
> newly introduced bcma_core_pci_ip() and bcma_core_pci_down()
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> Cc: Arend van Spriel <arend@broadcom.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> This fix has been discussed with Hauke Mehrtens [1] selection
> option 3) and is intended for v3.12.
>
> Ref:
> [1] http://mid.gmane.org/5239B12D.3040206@hauke-m.de
>
> Cc: <stable@vger.kernel.org> # 3.11.x
> Cc: Tod Jackson <tod.jackson@gmail.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: Rafal Milecki <zajec5@gmail.com>
> Cc: Hauke Mehrtens <hauke@hauke-m.de>
> Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
> Signed-off-by: Arend van Spriel <arend@broadcom.com>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Hi,
This is a little late but I am ok with the brcmsmac patch and the bcma
patch, feel free to add my Acked-by. This should go into 3.12 and 3.13+.
Hauke
^ permalink raw reply
* Re: [PATCH v2] mac80211: implement STA CSA for drivers using channel contexts
From: Arik Nemtsov @ 2013-10-02 11:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CA+XVXfdy2VdnTa55YJMQHTc+bj-oBUuSb1rT0nKbLKK7BZrSjQ@mail.gmail.com>
On Sun, Sep 29, 2013 at 10:06 AM, Arik Nemtsov <arik@wizery.com> wrote:
> On Sun, Sep 1, 2013 at 5:15 PM, Arik Nemtsov <arik@wizery.com> wrote:
>> Limit the current implementation to a single channel context used by
>> a single vif, thereby avoiding multi-vif/channel complexities.
>>
>> Reuse the main function from AP CSA code, but move a portion out in
>> order to fit the STA scenario.
>>
>> Add a new mac80211 HW flag so we don't break devices that don't support
>> channel switch with channel-contexts. The new behavior will be opt-in.
>>
>> Signed-off-by: Arik Nemtsov <arik@wizery.com>
>
> Ping?
Ping 2 :)
(Just saw your email on the list urging pings)
Arik
^ permalink raw reply
* Re: [PATCH] ath10k: fix scheduling while atomic bug on config
From: Michal Kazior @ 2013-10-02 11:18 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1380707467-30387-1-git-send-email-michal.kazior@tieto.com>
On 2 October 2013 11:51, Michal Kazior <michal.kazior@tieto.com> wrote:
> Recent WMI/HTC changes introduces this bug because
> now WMI commands can sleep.
>
> Use appropriate interface iteration function.
>
> Reported-By: Kalle Valo <kvalo@qca.qualcomm.com>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Self NACK.
I've posted this too soon. This patch can lead to deadlocks on
iflist_mtx in some cases.
Michał
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Johannes Berg @ 2013-10-02 10:11 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <CAA2SeN+nhLU7vGDNLJCD=UrNRSFm5hT6HGEEhUqr1kAcMF3O-A@mail.gmail.com>
On Wed, 2013-10-02 at 12:07 +0200, Lorenzo Bianconi wrote:
> Before start beaconing cfg80211_reg_can_beacon() verifies the channel
> is CAC checked and available calling cfg80211_secondary_chans_ok().
> Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
> period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
> frames on DFS channels causing association failures.
I don't see how this can cause association failures? Please explain.
DFS-capable hostapd doesn't use monitor interfaces with mac80211 any
more.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: allow mgmt frame transmission on DFS channels
From: Lorenzo Bianconi @ 2013-10-02 10:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, Simon Wunderlich, linux-wireless
In-Reply-To: <1380704100.13329.6.camel@jlt4.sipsolutions.net>
Before start beaconing cfg80211_reg_can_beacon() verifies the channel
is CAC checked and available calling cfg80211_secondary_chans_ok().
Although the channel is marked NL80211_DFS_AVAILABLE after a CAC
period, ieee80211_monitor_start_xmit() does not allow to inject mgmt
frames on DFS channels causing association failures.
Lorenzo
2013/10/2 Johannes Berg <johannes@sipsolutions.net>:
> On Mon, 2013-09-30 at 14:52 +0200, Lorenzo Bianconi wrote:
>> Allow management frame injection on DFS channels if the channel has been CAC
>> checked and is available
>
>> +++ b/net/mac80211/tx.c
>> @@ -1694,8 +1694,10 @@ netdev_tx_t ieee80211_monitor_start_xmit(struct sk_buff *skb,
>> * radar detection by itself. We can do that later by adding a
>> * monitor flag interfaces used for AP support.
>> */
>> - if ((chan->flags & (IEEE80211_CHAN_NO_IBSS | IEEE80211_CHAN_RADAR |
>> - IEEE80211_CHAN_PASSIVE_SCAN)))
>> + if (((chan->flags & (IEEE80211_CHAN_PASSIVE_SCAN |
>> + IEEE80211_CHAN_NO_IBSS))) ||
>> + ((chan->flags & IEEE80211_CHAN_RADAR) &&
>> + chan->dfs_state != NL80211_DFS_AVAILABLE))
>
> This would be the only place where mac80211 is accessing
> chan->dfs_state, does that make sense? Why is it not needed elsewhere?
>
> johannes
>
--
UNIX is Sexy: who | grep -i blonde | talk; cd ~; wine; talk; touch;
unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp;
umount; make clean; sleep
^ 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