* Re: [PATCH v2 2/2] mac80211: store tx power value from user to station
From: Ben Greear @ 2017-01-31 19:00 UTC (permalink / raw)
To: Ashok Raj Nagarajan, linux-wireless; +Cc: johannes, arnagara, ath10k
In-Reply-To: <1485888101-23454-2-git-send-email-arnagara@qti.qualcomm.com>
On 01/31/2017 10:41 AM, Ashok Raj Nagarajan wrote:
> This patch introduce a new driver callback drv_sta_set_txpwr. This API will
> copy the transmit power value passed from user space and call the driver
> callback to set the tx power for the station.
>
> Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
> ---
> include/net/mac80211.h | 6 ++++++
> net/mac80211/cfg.c | 7 +++++++
> net/mac80211/driver-ops.c | 21 +++++++++++++++++++++
> net/mac80211/driver-ops.h | 5 +++++
> net/mac80211/trace.h | 27 +++++++++++++++++++++++++++
> 5 files changed, 66 insertions(+)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 5345d35..e059d5a 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -1777,6 +1777,8 @@ struct ieee80211_sta_rates {
> * This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE 2).
> * @support_p2p_ps: indicates whether the STA supports P2P PS mechanism or not.
> * @max_rc_amsdu_len: Maximum A-MSDU size in bytes recommended by rate control.
> + * @txpwr: indicates the tx power, in dBm, to be used when sending data frames
> + * to the STA. Value of 0 means, automatic (default) tx power.
Atheros NICs use 1/2 dBm increments internally, so maybe pass down mBm to the driver so you don't
loose the granularity? (Other NICs may potentially have even finer control.)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] ath10k: add support for controlling tx power to a station
From: Ben Greear @ 2017-01-31 18:57 UTC (permalink / raw)
To: Ashok Raj Nagarajan, ath10k; +Cc: arnagara, linux-wireless
In-Reply-To: <1485888165-23504-1-git-send-email-arnagara@qti.qualcomm.com>
On 01/31/2017 10:42 AM, Ashok Raj Nagarajan wrote:
> This patch will add the support to control the transmit power for traffic
> to a station associated with the AP. Userspace provide the transmit power
> value in mBm units and the allowed range is from 0 to 70. Underlying FW
How did you come up with 70 mBm as the limit. This is only 7dBm?
I would expect it to match the range of normal tx-power which is likely up to
30 dBm or so on some NICs (not counting regulatory limit).
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH v2 1/2] cfg80211: Add support to set tx power for a station associated
From: Ashok Raj Nagarajan @ 2017-01-31 18:41 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, johannes, arnagara, Ashok Raj Nagarajan
This patch adds support to set transmit power setting type and transmit
power level attributes to NL80211_CMD_SET_STATION in order to facilitate
adjusting the transmit power level of a station associated to the AP.
The added attributes allow selection of automatic and limited transmit
power level, with the level defined in mBm format.
Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
---
v2:
- refactor the shared code
- "keep what you had" using STATION_PARAM_APPLY_* BIT
- feature flag to let the user know if this feature is supported or not (Johannes)
include/net/cfg80211.h | 6 ++++++
include/uapi/linux/nl80211.h | 15 +++++++++++++
net/wireless/nl80211.c | 50 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 71 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 814be4b..c989fbd 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -808,6 +808,7 @@ enum station_parameters_apply_mask {
STATION_PARAM_APPLY_UAPSD = BIT(0),
STATION_PARAM_APPLY_CAPABILITY = BIT(1),
STATION_PARAM_APPLY_PLINK_STATE = BIT(2),
+ STATION_PARAM_APPLY_STA_TXPOWER = BIT(3),
};
/**
@@ -849,6 +850,10 @@ enum station_parameters_apply_mask {
* @opmode_notif: operating mode field from Operating Mode Notification
* @opmode_notif_used: information if operating mode field is used
* @support_p2p_ps: information if station supports P2P PS mechanism
+ * @txpwr: tx power (in mBm) to be used for sending data traffic. If tx power
+ * is not provided, the default per-interface tx power setting will be
+ * overriding. Driver should be picking up the lowest tx power, either tx
+ * power per-interface or per-station.
*/
struct station_parameters {
const u8 *supported_rates;
@@ -876,6 +881,7 @@ struct station_parameters {
u8 opmode_notif;
bool opmode_notif_used;
int support_p2p_ps;
+ unsigned int txpwr;
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6b76e3b..de2f72c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1980,6 +1980,15 @@ enum nl80211_commands {
* @NL80211_ATTR_BSSID: The BSSID of the AP. Note that %NL80211_ATTR_MAC is also
* used in various commands/events for specifying the BSSID.
*
+ * @NL80211_ATTR_STA_TX_POWER_SETTING: Transmit power setting type (u32) for
+ * station associated with the AP. See &enum nl80211_tx_power_setting for
+ * possible values.
+ * @NL80211_ATTR_STA_TX_POWER: Transmit power level (u32) in mBm units. This
+ * allows to set Tx power for a station. If this attribute is not included,
+ * the default per-interface tx power setting will be overriding. Driver
+ * should be picking up the lowest tx power, either tx power per-interface
+ * or per-station.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2386,6 +2395,9 @@ enum nl80211_attrs {
NL80211_ATTR_BSSID,
+ NL80211_ATTR_STA_TX_POWER_SETTING,
+ NL80211_ATTR_STA_TX_POWER,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -4697,6 +4709,8 @@ enum nl80211_feature_flags {
* configuration (AP/mesh) with VHT rates.
* @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial Link Setup
* with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
+ * @NL80211_EXT_FEATURE_STA_TX_PWR: This driver supports controlling tx power
+ * to a station.
*
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4712,6 +4726,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_BEACON_RATE_HT,
NL80211_EXT_FEATURE_BEACON_RATE_VHT,
NL80211_EXT_FEATURE_FILS_STA,
+ NL80211_EXT_FEATURE_STA_TX_PWR,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ef5eff93..ace87de 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -246,6 +246,8 @@ enum nl80211_multicast_groups {
[NL80211_ATTR_STA_SUPPORTED_RATES] = { .type = NLA_BINARY,
.len = NL80211_MAX_SUPP_RATES },
[NL80211_ATTR_STA_PLINK_ACTION] = { .type = NLA_U8 },
+ [NL80211_ATTR_STA_TX_POWER_SETTING] = { .type = NLA_U32 },
+ [NL80211_ATTR_STA_TX_POWER] = { .type = NLA_U32 },
[NL80211_ATTR_STA_VLAN] = { .type = NLA_U32 },
[NL80211_ATTR_MNTR_FLAGS] = { /* NLA_NESTED can't be empty */ },
[NL80211_ATTR_MESH_ID] = { .type = NLA_BINARY,
@@ -4548,6 +4550,8 @@ int cfg80211_check_station_change(struct wiphy *wiphy,
return -EINVAL;
if (params->sta_modify_mask & STATION_PARAM_APPLY_CAPABILITY)
return -EINVAL;
+ if (params->sta_modify_mask & STATION_PARAM_APPLY_STA_TXPOWER)
+ return -EINVAL;
if (params->supported_rates)
return -EINVAL;
if (params->ext_capab || params->ht_capa || params->vht_capa)
@@ -4755,6 +4759,40 @@ static int nl80211_set_station_tdls(struct genl_info *info,
return nl80211_parse_sta_wme(info, params);
}
+static int nl80211_parse_sta_txpower_setting(struct genl_info *info,
+ struct station_parameters *params)
+{
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ enum nl80211_tx_power_setting type;
+ int idx;
+
+ if (!rdev->ops->set_tx_power ||
+ !wiphy_ext_feature_isset(&rdev->wiphy,
+ NL80211_EXT_FEATURE_STA_TX_PWR))
+ return -EOPNOTSUPP;
+
+ idx = NL80211_ATTR_STA_TX_POWER_SETTING;
+ type = nla_get_u32(info->attrs[idx]);
+
+ if (!info->attrs[NL80211_ATTR_STA_TX_POWER] &&
+ (type != NL80211_TX_POWER_AUTOMATIC))
+ return -EINVAL;
+
+ if (type != NL80211_TX_POWER_AUTOMATIC) {
+ if (type == NL80211_TX_POWER_LIMITED) {
+ idx = NL80211_ATTR_STA_TX_POWER;
+ params->txpwr = nla_get_u32(info->attrs[idx]);
+ params->sta_modify_mask |=
+ STATION_PARAM_APPLY_STA_TXPOWER;
+ } else {
+ return -EINVAL;
+ }
+ } else {
+ params->txpwr = 0;
+ }
+ return 0;
+}
+
static int nl80211_set_station(struct sk_buff *skb, struct genl_info *info)
{
struct cfg80211_registered_device *rdev = info->user_ptr[0];
@@ -4854,6 +4892,12 @@ static int nl80211_set_station(struct sk_buff *skb, struct genl_info *info)
params.local_pm = pm;
}
+ if (info->attrs[NL80211_ATTR_STA_TX_POWER_SETTING]) {
+ err = nl80211_parse_sta_txpower_setting(info, ¶ms);
+ if (err)
+ return err;
+ }
+
/* Include parameters for TDLS peer (will check later) */
err = nl80211_set_station_tdls(info, ¶ms);
if (err)
@@ -4981,6 +5025,12 @@ static int nl80211_new_station(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
}
+ if (info->attrs[NL80211_ATTR_STA_TX_POWER_SETTING]) {
+ err = nl80211_parse_sta_txpower_setting(info, ¶ms);
+ if (err)
+ return err;
+ }
+
err = nl80211_parse_sta_channel_info(info, ¶ms);
if (err)
return err;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] mac80211: store tx power value from user to station
From: Ashok Raj Nagarajan @ 2017-01-31 18:41 UTC (permalink / raw)
To: linux-wireless; +Cc: ath10k, johannes, arnagara, Ashok Raj Nagarajan
In-Reply-To: <1485888101-23454-1-git-send-email-arnagara@qti.qualcomm.com>
This patch introduce a new driver callback drv_sta_set_txpwr. This API will
copy the transmit power value passed from user space and call the driver
callback to set the tx power for the station.
Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
---
include/net/mac80211.h | 6 ++++++
net/mac80211/cfg.c | 7 +++++++
net/mac80211/driver-ops.c | 21 +++++++++++++++++++++
net/mac80211/driver-ops.h | 5 +++++
net/mac80211/trace.h | 27 +++++++++++++++++++++++++++
5 files changed, 66 insertions(+)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 5345d35..e059d5a 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1777,6 +1777,8 @@ struct ieee80211_sta_rates {
* This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE 2).
* @support_p2p_ps: indicates whether the STA supports P2P PS mechanism or not.
* @max_rc_amsdu_len: Maximum A-MSDU size in bytes recommended by rate control.
+ * @txpwr: indicates the tx power, in dBm, to be used when sending data frames
+ * to the STA. Value of 0 means, automatic (default) tx power.
* @txq: per-TID data TX queues (if driver uses the TXQ abstraction)
*/
struct ieee80211_sta {
@@ -1800,6 +1802,7 @@ struct ieee80211_sta {
u16 max_amsdu_len;
bool support_p2p_ps;
u16 max_rc_amsdu_len;
+ u8 txpwr;
struct ieee80211_txq *txq[IEEE80211_NUM_TIDS];
@@ -3545,6 +3548,9 @@ struct ieee80211_ops {
#endif
void (*sta_notify)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
enum sta_notify_cmd, struct ieee80211_sta *sta);
+ int (*sta_set_txpwr)(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta);
int (*sta_state)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct ieee80211_sta *sta,
enum ieee80211_sta_state old_state,
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index e91e503..f84ada0 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1346,6 +1346,13 @@ static int sta_apply_parameters(struct ieee80211_local *local,
if (params->listen_interval >= 0)
sta->listen_interval = params->listen_interval;
+ if (params->txpwr >= 0) {
+ sta->sta.txpwr = MBM_TO_DBM(params->txpwr);
+ ret = drv_sta_set_txpwr(local, sdata, sta);
+ if (ret)
+ return ret;
+ }
+
if (params->supported_rates) {
ieee80211_parse_bitrates(&sdata->vif.bss_conf.chandef,
sband, params->supported_rates,
diff --git a/net/mac80211/driver-ops.c b/net/mac80211/driver-ops.c
index bb886e7..839c002 100644
--- a/net/mac80211/driver-ops.c
+++ b/net/mac80211/driver-ops.c
@@ -138,6 +138,27 @@ int drv_sta_state(struct ieee80211_local *local,
return ret;
}
+__must_check
+int drv_sta_set_txpwr(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct sta_info *sta)
+{
+ int ret = -EOPNOTSUPP;
+
+ might_sleep();
+
+ sdata = get_bss_sdata(sdata);
+ if (!check_sdata_in_driver(sdata))
+ return -EIO;
+
+ trace_drv_sta_set_txpwr(local, sdata, &sta->sta);
+ if (local->ops->sta_set_txpwr)
+ ret = local->ops->sta_set_txpwr(&local->hw, &sdata->vif,
+ &sta->sta);
+ trace_drv_return_int(local, ret);
+ return ret;
+}
+
void drv_sta_rc_update(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
struct ieee80211_sta *sta, u32 changed)
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 09f77e4..2b13c39 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -526,6 +526,11 @@ int drv_sta_state(struct ieee80211_local *local,
enum ieee80211_sta_state old_state,
enum ieee80211_sta_state new_state);
+__must_check
+int drv_sta_set_txpwr(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct sta_info *sta);
+
void drv_sta_rc_update(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
struct ieee80211_sta *sta, u32 changed);
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index 92a47af..a264261 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -823,6 +823,33 @@
)
);
+TRACE_EVENT(drv_sta_set_txpwr,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ struct ieee80211_sta *sta),
+
+ TP_ARGS(local, sdata, sta),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ STA_ENTRY
+ __field(u8, txpwr)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ STA_ASSIGN;
+ __entry->txpwr = sta->txpwr;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT VIF_PR_FMT STA_PR_FMT " txpwr: %d",
+ LOCAL_PR_ARG, VIF_PR_ARG, STA_PR_ARG, __entry->txpwr
+ )
+);
+
TRACE_EVENT(drv_sta_rc_update,
TP_PROTO(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
--
1.9.1
^ permalink raw reply related
* [PATCH v2] ath10k: add support for controlling tx power to a station
From: Ashok Raj Nagarajan @ 2017-01-31 18:42 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, arnagara, Ashok Raj Nagarajan
This patch will add the support to control the transmit power for traffic
to a station associated with the AP. Userspace provide the transmit power
value in mBm units and the allowed range is from 0 to 70. Underlying FW
will enforce that the maximum tx power will be based on the regulatory
requirements. If the user given transmit power is greater than the allowed
tx power in the given channel, then the FW will use the maximum tx power
in the same channel.
When 0 is sent to the FW as tx power, it will revert to the automatic tx
power for the station.
Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
---
v2:
- indicate that the driver supports this feature using
NL80211_EXT_FEATURE_STA_TX_PWR
drivers/net/wireless/ath/ath10k/debug.h | 3 +++
drivers/net/wireless/ath/ath10k/mac.c | 33 +++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 1 +
3 files changed, 37 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 2368f47..db51453 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -59,6 +59,9 @@ enum ath10k_dbg_aggr_mode {
/* FIXME: How to calculate the buffer size sanely? */
#define ATH10K_FW_STATS_BUF_SIZE (1024 * 1024)
+#define ATH10K_TX_POWER_MAX_VAL 70
+#define ATH10K_TX_POWER_MIN_VAL 0
+
extern unsigned int ath10k_debug_mask;
__printf(2, 3) void ath10k_info(struct ath10k *ar, const char *fmt, ...);
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 9977829..d1a5937 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5985,6 +5985,34 @@ static int ath10k_mac_tdls_vifs_count(struct ieee80211_hw *hw)
return num_tdls_vifs;
}
+static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct ath10k *ar = hw->priv;
+ struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ int ret = 0;
+ u8 txpwr;
+
+ txpwr = sta->txpwr;
+ if (txpwr > ATH10K_TX_POWER_MAX_VAL || txpwr < ATH10K_TX_POWER_MIN_VAL)
+ return -EINVAL;
+
+ mutex_lock(&ar->conf_mutex);
+
+ ret = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
+ WMI_PEER_USE_FIXED_PWR, txpwr);
+ if (ret) {
+ ath10k_warn(ar, "failed to set tx power for station ret: %d\n",
+ ret);
+ goto out;
+ }
+
+out:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
+}
+
static int ath10k_sta_state(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta,
@@ -7550,6 +7578,7 @@ static void ath10k_mac_op_sta_pre_rcu_remove(struct ieee80211_hw *hw,
.set_key = ath10k_set_key,
.set_default_unicast_key = ath10k_set_default_unicast_key,
.sta_state = ath10k_sta_state,
+ .sta_set_txpwr = ath10k_sta_set_txpwr,
.conf_tx = ath10k_conf_tx,
.remain_on_channel = ath10k_remain_on_channel,
.cancel_remain_on_channel = ath10k_cancel_remain_on_channel,
@@ -8193,11 +8222,15 @@ int ath10k_mac_register(struct ath10k *ar)
ar->hw->wiphy->iface_combinations = ath10k_10x_if_comb;
ar->hw->wiphy->n_iface_combinations =
ARRAY_SIZE(ath10k_10x_if_comb);
+ wiphy_ext_feature_set(ar->hw->wiphy,
+ NL80211_EXT_FEATURE_STA_TX_PWR);
break;
case ATH10K_FW_WMI_OP_VERSION_10_4:
ar->hw->wiphy->iface_combinations = ath10k_10_4_if_comb;
ar->hw->wiphy->n_iface_combinations =
ARRAY_SIZE(ath10k_10_4_if_comb);
+ wiphy_ext_feature_set(ar->hw->wiphy,
+ NL80211_EXT_FEATURE_STA_TX_PWR);
break;
case ATH10K_FW_WMI_OP_VERSION_UNSET:
case ATH10K_FW_WMI_OP_VERSION_MAX:
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 861c2d8..1ccb6bf 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -5811,6 +5811,7 @@ enum wmi_peer_param {
WMI_PEER_CHAN_WIDTH = 0x4,
WMI_PEER_NSS = 0x5,
WMI_PEER_USE_4ADDR = 0x6,
+ WMI_PEER_USE_FIXED_PWR = 0x8,
WMI_PEER_DUMMY_VAR = 0xff, /* dummy parameter for STA PS workaround */
};
--
1.9.1
^ permalink raw reply related
* [PATCH] ath10k: fix reading sram contents for QCA4019
From: Ashok Raj Nagarajan @ 2017-01-31 18:36 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, arnagara, Ashok Raj Nagarajan
With QCA4019 platform, SRAM address can be accessed directly from host but
currently, we are assuming sram addresses cannot be accessed directly and
hence we convert the addresses.
While there, clean up growing hw checks during conversion of target CPU
address to CE address. Now we have function pointer pertaining to different
chips.
Signed-off-by: Ashok Raj Nagarajan <arnagara@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/ahb.c | 23 ++++++++++++++++
drivers/net/wireless/ath/ath10k/pci.c | 51 ++++++++++++++++++++++-------------
drivers/net/wireless/ath/ath10k/pci.h | 5 ++++
3 files changed, 60 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ahb.c b/drivers/net/wireless/ath/ath10k/ahb.c
index 766c63b..45226db 100644
--- a/drivers/net/wireless/ath/ath10k/ahb.c
+++ b/drivers/net/wireless/ath/ath10k/ahb.c
@@ -33,6 +33,9 @@
MODULE_DEVICE_TABLE(of, ath10k_ahb_of_match);
+#define QCA4019_SRAM_ADDR 0x000C0000
+#define QCA4019_SRAM_LEN 0x00040000 /* 256 kb */
+
static inline struct ath10k_ahb *ath10k_ahb_priv(struct ath10k *ar)
{
return &((struct ath10k_pci *)ar->drv_priv)->ahb[0];
@@ -699,6 +702,25 @@ static int ath10k_ahb_hif_power_up(struct ath10k *ar)
return ret;
}
+static u32 ath10k_ahb_qca4019_targ_cpu_to_ce_addr(struct ath10k *ar, u32 addr)
+{
+ u32 val = 0, region = addr & 0xfffff;
+
+ val = ath10k_pci_read32(ar, PCIE_BAR_REG_ADDRESS);
+
+ if (region >= QCA4019_SRAM_ADDR && region <=
+ (QCA4019_SRAM_ADDR + QCA4019_SRAM_LEN)) {
+ /* SRAM contents for QCA4019 can be directly accessed and
+ * no conversions are required
+ */
+ val |= region;
+ } else {
+ val |= 0x100000 | region;
+ }
+
+ return val;
+}
+
static const struct ath10k_hif_ops ath10k_ahb_hif_ops = {
.tx_sg = ath10k_pci_hif_tx_sg,
.diag_read = ath10k_pci_hif_diag_read,
@@ -766,6 +788,7 @@ static int ath10k_ahb_probe(struct platform_device *pdev)
ar_pci->mem_len = ar_ahb->mem_len;
ar_pci->ar = ar;
ar_pci->bus_ops = &ath10k_ahb_bus_ops;
+ ar_pci->targ_cpu_to_ce_addr = ath10k_ahb_qca4019_targ_cpu_to_ce_addr;
ret = ath10k_pci_setup_resource(ar);
if (ret) {
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index d2aa9e5..6e0d062 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -840,31 +840,35 @@ void ath10k_pci_rx_replenish_retry(unsigned long ptr)
ath10k_pci_rx_post(ar);
}
-static u32 ath10k_pci_targ_cpu_to_ce_addr(struct ath10k *ar, u32 addr)
+static u32 ath10k_pci_qca988x_targ_cpu_to_ce_addr(struct ath10k *ar, u32 addr)
{
- u32 val = 0;
+ u32 val = 0, region = addr & 0xfffff;
- switch (ar->hw_rev) {
- case ATH10K_HW_QCA988X:
- case ATH10K_HW_QCA9887:
- case ATH10K_HW_QCA6174:
- case ATH10K_HW_QCA9377:
- val = (ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS +
- CORE_CTRL_ADDRESS) &
- 0x7ff) << 21;
- break;
- case ATH10K_HW_QCA9888:
- case ATH10K_HW_QCA99X0:
- case ATH10K_HW_QCA9984:
- case ATH10K_HW_QCA4019:
- val = ath10k_pci_read32(ar, PCIE_BAR_REG_ADDRESS);
- break;
- }
+ val = (ath10k_pci_read32(ar, SOC_CORE_BASE_ADDRESS + CORE_CTRL_ADDRESS)
+ & 0x7ff) << 21;
+ val |= 0x100000 | region;
+ return val;
+}
+
+static u32 ath10k_pci_qca99x0_targ_cpu_to_ce_addr(struct ath10k *ar, u32 addr)
+{
+ u32 val = 0, region = addr & 0xfffff;
- val |= 0x100000 | (addr & 0xfffff);
+ val = ath10k_pci_read32(ar, PCIE_BAR_REG_ADDRESS);
+ val |= 0x100000 | region;
return val;
}
+static u32 ath10k_pci_targ_cpu_to_ce_addr(struct ath10k *ar, u32 addr)
+{
+ struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+
+ if (WARN_ON_ONCE(!ar_pci->targ_cpu_to_ce_addr))
+ return -ENOTSUPP;
+
+ return ar_pci->targ_cpu_to_ce_addr(ar, addr);
+}
+
/*
* Diagnostic read/write access is provided for startup/config/debug usage.
* Caller must guarantee proper alignment, when applicable, and single user
@@ -3170,6 +3174,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
bool pci_ps;
int (*pci_soft_reset)(struct ath10k *ar);
int (*pci_hard_reset)(struct ath10k *ar);
+ u32 (*targ_cpu_to_ce_addr)(struct ath10k *ar, u32 addr);
switch (pci_dev->device) {
case QCA988X_2_0_DEVICE_ID:
@@ -3177,12 +3182,14 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
pci_ps = false;
pci_soft_reset = ath10k_pci_warm_reset;
pci_hard_reset = ath10k_pci_qca988x_chip_reset;
+ targ_cpu_to_ce_addr = ath10k_pci_qca988x_targ_cpu_to_ce_addr;
break;
case QCA9887_1_0_DEVICE_ID:
hw_rev = ATH10K_HW_QCA9887;
pci_ps = false;
pci_soft_reset = ath10k_pci_warm_reset;
pci_hard_reset = ath10k_pci_qca988x_chip_reset;
+ targ_cpu_to_ce_addr = ath10k_pci_qca988x_targ_cpu_to_ce_addr;
break;
case QCA6164_2_1_DEVICE_ID:
case QCA6174_2_1_DEVICE_ID:
@@ -3190,30 +3197,35 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
pci_ps = true;
pci_soft_reset = ath10k_pci_warm_reset;
pci_hard_reset = ath10k_pci_qca6174_chip_reset;
+ targ_cpu_to_ce_addr = ath10k_pci_qca988x_targ_cpu_to_ce_addr;
break;
case QCA99X0_2_0_DEVICE_ID:
hw_rev = ATH10K_HW_QCA99X0;
pci_ps = false;
pci_soft_reset = ath10k_pci_qca99x0_soft_chip_reset;
pci_hard_reset = ath10k_pci_qca99x0_chip_reset;
+ targ_cpu_to_ce_addr = ath10k_pci_qca99x0_targ_cpu_to_ce_addr;
break;
case QCA9984_1_0_DEVICE_ID:
hw_rev = ATH10K_HW_QCA9984;
pci_ps = false;
pci_soft_reset = ath10k_pci_qca99x0_soft_chip_reset;
pci_hard_reset = ath10k_pci_qca99x0_chip_reset;
+ targ_cpu_to_ce_addr = ath10k_pci_qca99x0_targ_cpu_to_ce_addr;
break;
case QCA9888_2_0_DEVICE_ID:
hw_rev = ATH10K_HW_QCA9888;
pci_ps = false;
pci_soft_reset = ath10k_pci_qca99x0_soft_chip_reset;
pci_hard_reset = ath10k_pci_qca99x0_chip_reset;
+ targ_cpu_to_ce_addr = ath10k_pci_qca99x0_targ_cpu_to_ce_addr;
break;
case QCA9377_1_0_DEVICE_ID:
hw_rev = ATH10K_HW_QCA9377;
pci_ps = true;
pci_soft_reset = NULL;
pci_hard_reset = ath10k_pci_qca6174_chip_reset;
+ targ_cpu_to_ce_addr = ath10k_pci_qca988x_targ_cpu_to_ce_addr;
break;
default:
WARN_ON(1);
@@ -3240,6 +3252,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
ar_pci->bus_ops = &ath10k_pci_bus_ops;
ar_pci->pci_soft_reset = pci_soft_reset;
ar_pci->pci_hard_reset = pci_hard_reset;
+ ar_pci->targ_cpu_to_ce_addr = targ_cpu_to_ce_addr;
ar->id.vendor = pdev->vendor;
ar->id.device = pdev->device;
diff --git a/drivers/net/wireless/ath/ath10k/pci.h b/drivers/net/wireless/ath/ath10k/pci.h
index c76789d..c1e08ad6 100644
--- a/drivers/net/wireless/ath/ath10k/pci.h
+++ b/drivers/net/wireless/ath/ath10k/pci.h
@@ -233,6 +233,11 @@ struct ath10k_pci {
/* Chip specific pci full reset function */
int (*pci_hard_reset)(struct ath10k *ar);
+ /* chip specific methods for converting target CPU virtual address
+ * space to CE address space
+ */
+ u32 (*targ_cpu_to_ce_addr)(struct ath10k *ar, u32 addr);
+
/* Keep this entry in the last, memory for struct ath10k_ahb is
* allocated (ahb support enabled case) in the continuation of
* this struct.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 3/3] mac80211: clear failure average upon mesh path deactivation
From: Thomas Pedersen @ 2017-01-31 17:51 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: Johannes Berg, linux-wireless, rmanohar
In-Reply-To: <1485561708-31559-3-git-send-email-rmanohar@qca.qualcomm.com>
Hi Rajkumar,
Thanks this looks good, but..
On Fri, Jan 27, 2017 at 4:01 PM, Rajkumar Manoharan
<rmanohar@qca.qualcomm.com> wrote:
> Mesh moving average should be cleared, whenever mesh paths
> to the given station are deactivated due to bad link. This will
> give enough room to analysis more tx status than retaining the
> current average.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
> ---
> net/mac80211/mesh_pathtbl.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
> index f0e6175a9821..208ad36c0a7f 100644
> --- a/net/mac80211/mesh_pathtbl.c
> +++ b/net/mac80211/mesh_pathtbl.c
> @@ -510,6 +510,7 @@ void mesh_plink_broken(struct sta_info *sta)
> struct mesh_path *mpath;
> struct rhashtable_iter iter;
> int ret;
> + bool paths_deactivated = false;
>
> ret = rhashtable_walk_init(&tbl->rhead, &iter, GFP_ATOMIC);
> if (ret)
> @@ -535,8 +536,11 @@ void mesh_plink_broken(struct sta_info *sta)
> sdata->u.mesh.mshcfg.element_ttl,
> mpath->dst, mpath->sn,
> WLAN_REASON_MESH_PATH_DEST_UNREACHABLE, bcast);
> + paths_deactivated = true;
> }
> }
> + if (paths_deactivated)
> + sta->mesh->fail_avg = 0;
.. why this indirection? Just reset mesh->fail_avg unconditionally in
this function?
--
thomas
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Tony Lindgren @ 2017-01-31 15:59 UTC (permalink / raw)
To: Kalle Valo
Cc: Pavel Machek, Pali Rohár, Arend Van Spriel, Ming Lei,
Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt, Michal Kazior,
Daniel Wagner, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <8737fzrb36.fsf@kamboji.qca.qualcomm.com>
* Kalle Valo <kvalo@codeaurora.org> [170130 22:36]:
> Tony Lindgren <tony@atomide.com> writes:
>
> > * Pavel Machek <pavel@ucw.cz> [170127 11:41]:
> >> On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
> >> > Pali Rohár <pali.rohar@gmail.com> writes:
> >> >
> >> > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> >> > >> Pali Rohár <pali.rohar@gmail.com> writes:
> >> > >>
> >> > >> > 2) It was already tested that example NVS data can be used for N900 e.g.
> >> > >> > for SSH connection. If real correct data are not available it is better
> >> > >> > to use at least those example (and probably log warning message) so user
> >> > >> > can connect via SSH and start investigating where is problem.
> >> > >>
> >> > >> I disagree. Allowing default calibration data to be used can be
> >> > >> unnoticed by user and left her wondering why wifi works so badly.
> >> > >
> >> > > So there are only two options:
> >> > >
> >> > > 1) Disallow it and so these users will have non-working wifi.
> >> > >
> >> > > 2) Allow those data to be used as fallback mechanism.
> >> > >
> >> > > And personally I'm against 1) because it will break wifi support for
> >> > > *all* Nokia N900 devices right now.
> >> >
> >> > All two of them? :)
> >>
> >> Umm. You clearly want a flock of angry penguins at your doorsteps :-).
> >
> > Well this silly issue of symlinking and renaming nvs files in a standard
> > Linux distro was also hitting me on various devices with wl12xx/wl18xx
> > trying to use the same rootfs.
> >
> > Why don't we just set a custom compatible property for n900 that then
> > picks up some other nvs file instead of the default?
>
> Please don't. An ugly kernel workaround in kernel because of user space
> problems is a bad idea. wl1251 should just ask for NVS file from user
> space, it shouldn't care if it's a "default" file or something else.
> That's a user space policy decision.
Grr I keep forgetting it needs to be for each device manufactured so
yeah that won't work.
The names of standard distro files are hardcoded into the kernel
driver so it's also a kernel problem though :p
How about a custom devices tree property saying "needs-custom-firmware"?
Something that would prevent anything being loaded until user space
loads the firmware. It could also be set in the driver automatically
based on the compatible flag if we always want it enabled. And we could
have some cmdline option to ignore it. Or the other way around whatever
makes sense.
> Why can't you do something like this:
>
> * rename the NVS file linux-firmware to wl1251-nvs.bin.example
As that name is hardcoded in the kernel and that file is provided by
all standard distros, let's assume we just have to deal with that ABI
forever.
> * before distro updates linux-firmware create yours own deb/rpm/whatever
> package "wl1251-firmware" which installs your flavor of nvs file (or
> the user fallback helper if more dynamic functionality is preferred)
And that won't work when using the same file system on other machines.
Think NFSroot for example. At least I'm using the same NFSroot across
about 15 different machines including one n900 macro board with smc91x
Ethernet.
Regards,
Tony
^ permalink raw reply
* Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Ben Greear @ 2017-01-31 15:26 UTC (permalink / raw)
To: Wojciech Dubowik, Klaus Kinski
Cc: Toke Høiland-Jørgensen, Dave Taht, linux-wireless
In-Reply-To: <afccf3d4-b095-1a64-fd08-d559b44bcb72@neratec.com>
One thing to consider: Older ath9k and maybe madwifi used a different congestion control,
and it got higher throughput in optimal situations in our testing. When it was removed
from the kernel, there was some effort to improve the minstrel_ht algorithm, but I don't
think it ever performed quite as well as far as bulk transfer is concerned.
Thanks,
Ben
On 01/31/2017 01:52 AM, Wojciech Dubowik wrote:
>
>
> On 31/01/17 10:46, Klaus Kinski wrote:
>> BTW, if I read the sources correctly, than IBSS mode uses the TXQ parameters from ieee80211_set_wmm_default with enable_qos = false which means that qparam.txop = 0, e.g. bursting is disabled. Am I right?
> I guess so. But you need to look also at contention window sizes because it make a big impact on throughout with retries and collisions.
>>
>> Jörg Pommnitz <jpo234@outlook.de <mailto:jpo234@outlook.de>> schrieb am Di., 31. Jan. 2017 um 10:37 Uhr:
>>
>> I'm mostly interested in Ad-Hoc mode, e.g. IBSS.
>>
>> Wojciech Dubowik <wojciech.dubowik@neratec.com
>> <mailto:wojciech.dubowik@neratec.com>> schrieb am Di., 31. Jan.
>> 2017 um 10:35 Uhr:
>>
>> That's tricky but look at
>> http://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf
>> <http://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf>
>>
>> tx_queue... are for AP and wmm_... for STA (over beacons).
>>
>> These should be default parameters. You can also enable CONFIG
>> debug flag
>>
>> for ath9k and it prints wme parameters when it starts.
>>
>> Wojtek
>>
>>
>> On 31/01/17 10:18, Klaus Kinski wrote:
>>> It seems that bursting can be controlled over nl80211 (see ,
>>> specifically with NL80211_ATTR_WIPHY_TXQ_PARAMS.
>>> Unfortunately this seems not to be exposed in iw. It's an
>>> attribute of NL80211_CMD_SET_WIPHY.
>>> Is there another tool that exposes txq params? If not, has
>>> anybody thought about exposing it in iw? I might take a stab
>>> at it...
>>>
>>> Regards
>>> Joerg
>>>
>>> Wojciech Dubowik <wojciech.dubowik@neratec.com
>>> <mailto:wojciech.dubowik@neratec.com>> schrieb am Di., 31.
>>> Jan. 2017 um 08:55 Uhr:
>>>
>>> Madwifi has default best effort queue "tuned" for throughout
>>>
>>> and its parameters are different from mac80211 defaults when
>>>
>>> qos (WME) is disabled.
>>>
>>> You would have to dump qos settings for both systems before
>>>
>>> comparing them. I guess the easiest way is to make sure QoS
>>>
>>> is enabled and send video type of packets with iperf ...
>>> -S 0xa0
>>>
>>> Wojtek
>>>
>>>
>>> On 30/01/17 20:43, Toke Høiland-Jørgensen wrote:
>>> > Klaus Kinski <jpo234@outlook.de
>>> <mailto:jpo234@outlook.de>> writes:
>>> >
>>> >> The captures I used to create the statistics are here:
>>> >>
>>> https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>>> >>
>>> >> An obvious difference is, that Madwifi sends 5 packets
>>> in a row
>>> >> without waiting for an ACK whereas ath9k/mac80211
>>> always seems to wait
>>> >> for an ACK. This seems to point to the "net80211
>>> aggressive mode
>>> >> theory" https://wiki.freebsd.org/WifiAggressiveMode
>>> <https://wiki.freebsd.org/WifiAggressiveMode>, IMHO.
>>> > I'm not too familiar with that part of the stack, but
>>> that seems
>>> > reasonable, yeah. AFAIK the "aggresive mode" is a
>>> pre-802.11n feature,
>>> > though, which is why you won't see that in ath9k. In
>>> 802.11n this kind
>>> > of bursting was replaced by aggregation, which you're
>>> not getting any of
>>> > since you're running in 802.11a mode, obviously.
>>> >
>>> > The lack of bursting will translate to slightly lower
>>> throughput, which
>>> > will be why you see fewer packets transmitted by ath9k.
>>> Of course, if
>>> > your receiver supported aggregation, the numbers would
>>> look dramatically
>>> > better in ath9k's favour... ;)
>>> >
>>> > -Toke
>>>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Kalle Valo @ 2017-01-31 15:02 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, Michal Kazior, ath10k
In-Reply-To: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> wrote:
> Firmware files are versioned to prevent older
> driver instances to load unsupported firmware
> blobs. This is reflected with a fallback logic
> which attempts to load several firmware files.
>
> This however produced a lot of unnecessary
> warnings sometimes confusing users and leading
> them to rename firmware files making things even
> more confusing.
>
> Hence use request_firmware_direct() which does not
> produce extra warnings. This shouldn't really
> break anything because most modern systems don't
> rely on udev/hotplug helpers to load firmware
> files anymore.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
While testing Erik's usb patches I noticed one problem if the firmware (or
board file) is not found:
[ 517.389399] usbcore: registered new interface driver ath10k_usb
[ 517.391756] usb 2-1.3: could not fetch firmware files (-2)
[ 517.391985] usb 2-1.3: could not probe fw (-2)
Now the user has no way to know what file is exactly missing. I'll try to
improve that in v2.
--
https://patchwork.kernel.org/patch/9237095/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* ANNOUNCE: Netdev 2.1 update
From: Jamal Hadi Salim @ 2017-01-31 14:15 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: netfilter-devel, netfilter, info, linux-wireless, tech-committee,
David Miller, Stephen Jaworski, Rob Echlin, lwn
A few announcements:
- We expect to open up registration and announce hotel and location
next week.
- We are pleased to announce the first netdev 2.1 talk has been accepted
by the tech committee! The Call for Proposals is still open, submit
early to avoid the hazards of last minute traffic. Refer to:
http://netdevconf.org/1.2/submit-proposal.html
On to the accepted talk:
-------
Title: Evaluating and improving kernel stack performance for datagram
sockets
from the perspective of RDBMS applications
Authors: Sowmini Varadhan, Tushar Dave
RDBMS applications heavily use stateless datagram sockets such as RDS
and UDP. These workloads are typically highly CPU-bound and sensitive
to network latency, so any perf improvements to these parameters is
extremely
desirable.
At the same time, since I/O for these RDBMS applications comes
from various sources (network, disk, local file-system and NFS),
APIs for perf enhancements is also a critical factor.
Motivated by these goals and constraints, we have investigated a few
kernel alternatives to UDP/IP, such as PF_PACKET. We have used
micro-benchmarks such as netperf, and are currently evaluating PF_PACKET
usage in IPC libraries for actual transaction-oriented RDBMS workloads.
We would like to share some of the findings from these experiments with
the netdev community. In addition to the actual numbers themselves,
interesting points that we'd like to discuss are the gaps between
micro-benchmarks and real-world usage, what works well (and what
doesn't matter so much) for real workloads, and practical factors
that impact deployment for any solution.
This is active work-in-progress, and some of our findings suggest areas
of perf-improvement in the kernel for various datagram sockets
that we'd like to bounce off netdev-ers for input.
---------------
cheers,
jamal
^ permalink raw reply
* [PATCH v3] wlcore: disable multicast filter in AP mode
From: Iain Hunter @ 2017-01-31 12:44 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Iain Hunter
In-Reply-To: <20170131104840.10366-1-i-hunter1@ti.com>
Enable AP support for allmulticast for MDNS. It can be enabled by bringing
up the interface with ip command with argument allmulticast on
Signed-off-by:Iain Hunter <i-hunter1@ti.com>
---
PATCH v3: fixes tabbing
drivers/net/wireless/ti/wlcore/main.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..7d3f15d5d5c 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -3281,6 +3281,21 @@ static void wl1271_op_configure_filter(struct ieee80211_hw *hw,
if (ret < 0)
goto out_sleep;
}
+
+ /*
+ * If interface in AP mode and created with allmulticast then disable
+ * the firmware filters so that all multicast packets are passed
+ * This is mandatory for MDNS based discovery protocols
+ */
+ if (wlvif->bss_type == BSS_TYPE_AP_BSS) {
+ if (*total & FIF_ALLMULTI) {
+ ret = wl1271_acx_group_address_tbl(wl, wlvif,
+ false,
+ NULL, 0);
+ if (ret < 0)
+ goto out_sleep;
+ }
+ }
}
/*
--
2.11.0
^ permalink raw reply related
* Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Rafał Miłecki @ 2017-01-31 12:42 UTC (permalink / raw)
To: Wojciech Dubowik
Cc: Klaus Kinski, Toke Høiland-Jørgensen, Dave Taht,
linux-wireless
In-Reply-To: <afccf3d4-b095-1a64-fd08-d559b44bcb72@neratec.com>
On 31 January 2017 at 10:52, Wojciech Dubowik
<wojciech.dubowik@neratec.com> wrote:
> On 31/01/17 10:46, Klaus Kinski wrote:
>>
>> BTW, if I read the sources correctly, than IBSS mode uses the TXQ
>> parameters from ieee80211_set_wmm_default with enable_qos = false which
>> means that qparam.txop = 0, e.g. bursting is disabled. Am I right?
>
> I guess so. But you need to look also at contention window sizes because it
> make a big impact on throughout with retries and collisions.
Klaus: I feel you keep dropping linux-wireless when sending your
replies. Please don't do that.
^ permalink raw reply
* Re: Intel Pro 4965 wireless
From: Stanislaw Gruszka @ 2017-01-31 12:11 UTC (permalink / raw)
To: Luca Coelho; +Cc: Mel Stimmel, linux-wireless
In-Reply-To: <1485848188.26003.54.camel@coelho.fi>
On Tue, Jan 31, 2017 at 09:36:28AM +0200, Luca Coelho wrote:
> On Mon, 2017-01-30 at 21:04 -0500, Mel Stimmel wrote:
> > I have a problem that recently arose with my Thinkpad model T61
> > running Ubuntu 16.04 with the Intel Pro 4965 installed.
> > This system was working just fine until sometime in Dec., when
> > after one of the routine updates, the software can't see/find/recognize
> > the wireless adapter. It's not the adapter, as if I boot the system from
> > an older CD (show and tell mode) the wifi works just fine.
It's hard to tell for me what could changed after ubuntu update. I would
check if device initialize using "dmesg", then if interface is created
by "iw dev". If interface is created problem will be realted with
wpa_supplicant or NetworkManager . If there are no messages about
4965 device in 'dmesg' I would check if driver module is sill there:
find /lib/modules/`uname -r`/ -name "*iwl*"
> > When I do the command LSHW, it shows the driver as iwl4965, and the
> > version as 3.13.0-93-generic.
> > I've been in the computer business since 1958 but are a newby to
> > Linux so don't any/many of the commands and/or it's inner workings.
> > Any help that y'all could provide would be greatly appreciated.
> Adding Stanislaw, who is the maintainer of iwlegacy (which is the driver
> that supports iwl4965).
It's actually system configuration problem not driver by itself, better
place to search help would be ubuntu forums or google.
Stanislaw
^ permalink raw reply
* Re: [PATCH 2/2] brcmfmac: be more verbose when PSM's watchdog fires
From: Arend Van Spriel @ 2017-01-31 11:58 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: <20170130150952.7133-2-zajec5@gmail.com>
On 30-1-2017 16:09, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> It's important to inform user so he knows things went wrong. He may also
> want to get memory dump for further debugging purposes.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
> index 6f8a4b074c31..f4644cf371c7 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
> @@ -58,10 +58,18 @@ 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);
>
> - return brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
> - evtmsg->datalen);
> + 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)
>
^ permalink raw reply
* Re: [PATCH 1/2] brcmfmac: check brcmf_bus_get_memdump result for error
From: Arend Van Spriel @ 2017-01-31 11:56 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: <20170130150952.7133-1-zajec5@gmail.com>
On 30-1-2017 16:09, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This method may be unsupported (see: USB bus) or may just fail (see:
> SDIO bus).
> While at it rework logic in brcmf_sdio_bus_get_memdump function to avoid
> too many conditional code nesting levels.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> .../wireless/broadcom/brcm80211/brcmfmac/debug.c | 23 +++++++++++++++-------
> 1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
> index e64557c35553..6f8a4b074c31 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
> @@ -32,16 +32,25 @@ static int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
> {
> void *dump;
> size_t ramsize;
> + int err;
>
> ramsize = brcmf_bus_get_ramsize(bus);
> - if (ramsize) {
> - dump = vzalloc(len + ramsize);
> - if (!dump)
> - return -ENOMEM;
> - memcpy(dump, data, len);
> - brcmf_bus_get_memdump(bus, dump + len, ramsize);
> - dev_coredumpv(bus->dev, dump, len + ramsize, GFP_KERNEL);
> + if (!ramsize)
> + return -ENOTSUPP;
> +
> + dump = vzalloc(len + ramsize);
> + if (!dump)
> + return -ENOMEM;
> +
> + memcpy(dump, data, len);
> + err = brcmf_bus_get_memdump(bus, dump + len, ramsize);
> + if (err) {
> + vfree(dump);
> + return err;
> }
> +
> + dev_coredumpv(bus->dev, dump, len + ramsize, GFP_KERNEL);
> +
> return 0;
> }
>
>
^ permalink raw reply
* [PATCH v3] rt2x00: avoid introducing a USB dependency in the
From: Stanislaw Gruszka @ 2017-01-31 11:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Helmut Schaa, Felix Fietkau, Vishal Thanki
As reported by Felix:
Though protected by an ifdef, introducing an usb symbol dependency in
the rt2x00lib module is a major inconvenience for distributions that
package kernel modules split into individual packages.
Get rid of this unnecessary dependency by calling the usb related
function from a more suitable place.
Cc: Vishal Thanki <vishalthanki@gmail.com>
Reported-by: Felix Fietkau <nbd@nbd.name>
Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
v1 -> v2 do not break shutdown sequence
v2 -> v3 update patch to current kernel version
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c | 23 ++++++++---------------
drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 5 +++++
2 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
index 8fcbc8d..4b08007 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00dev.c
@@ -1436,21 +1436,6 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
cancel_work_sync(&rt2x00dev->intf_work);
cancel_delayed_work_sync(&rt2x00dev->autowakeup_work);
cancel_work_sync(&rt2x00dev->sleep_work);
-#if IS_ENABLED(CONFIG_RT2X00_LIB_USB)
- if (rt2x00_is_usb(rt2x00dev)) {
- usb_kill_anchored_urbs(rt2x00dev->anchor);
- hrtimer_cancel(&rt2x00dev->txstatus_timer);
- cancel_work_sync(&rt2x00dev->rxdone_work);
- cancel_work_sync(&rt2x00dev->txdone_work);
- }
-#endif
- if (rt2x00dev->workqueue)
- destroy_workqueue(rt2x00dev->workqueue);
-
- /*
- * Free the tx status fifo.
- */
- kfifo_free(&rt2x00dev->txstatus_fifo);
/*
* Kill the tx status tasklet.
@@ -1466,6 +1451,14 @@ void rt2x00lib_remove_dev(struct rt2x00_dev *rt2x00dev)
*/
rt2x00lib_uninitialize(rt2x00dev);
+ if (rt2x00dev->workqueue)
+ destroy_workqueue(rt2x00dev->workqueue);
+
+ /*
+ * Free the tx status fifo.
+ */
+ kfifo_free(&rt2x00dev->txstatus_fifo);
+
/*
* Free extra components
*/
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index 838ca58..5a2bf9f 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -744,6 +744,11 @@ void rt2x00usb_uninitialize(struct rt2x00_dev *rt2x00dev)
{
struct data_queue *queue;
+ usb_kill_anchored_urbs(rt2x00dev->anchor);
+ hrtimer_cancel(&rt2x00dev->txstatus_timer);
+ cancel_work_sync(&rt2x00dev->rxdone_work);
+ cancel_work_sync(&rt2x00dev->txdone_work);
+
queue_for_each(rt2x00dev, queue)
rt2x00usb_free_entries(queue);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH] wlcore: disable multicast filter in AP mode
From: Iain Hunter @ 2017-01-31 11:31 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Iain Hunter
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..7d3f15d5d5c 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -3281,6 +3281,21 @@ static void wl1271_op_configure_filter(struct ieee80211_hw *hw,
if (ret < 0)
goto out_sleep;
}
+
+ /*
+ * If interface in AP mode and created with allmulticast then disable
+ * the firmware filters so that all multicast packets are passed
+ * This is mandatory for MDNS based discovery protocols
+ */
+ if (wlvif->bss_type == BSS_TYPE_AP_BSS) {
+ if (*total & FIF_ALLMULTI) {
+ ret = wl1271_acx_group_address_tbl(wl, wlvif,
+ false,
+ NULL, 0);
+ if (ret < 0)
+ goto out_sleep;
+ }
+ }
}
/*
--
2.11.0
^ permalink raw reply related
* [PATCH] wlcore: disable multicast filter in AP mode
From: Iain Hunter @ 2017-01-31 11:26 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Iain Hunter
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..7d3f15d5d5c 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -3281,6 +3281,21 @@ static void wl1271_op_configure_filter(struct ieee80211_hw *hw,
if (ret < 0)
goto out_sleep;
}
+
+ /*
+ * If interface in AP mode and created with allmulticast then disable
+ * the firmware filters so that all multicast packets are passed
+ * This is mandatory for MDNS based discovery protocols
+ */
+ if (wlvif->bss_type == BSS_TYPE_AP_BSS) {
+ if (*total & FIF_ALLMULTI) {
+ ret = wl1271_acx_group_address_tbl(wl, wlvif,
+ false,
+ NULL, 0);
+ if (ret < 0)
+ goto out_sleep;
+ }
+ }
}
/*
--
2.11.0
^ permalink raw reply related
* [PATCH] wlcore: disable multicast filter in AP mode
From: Iain Hunter @ 2017-01-31 10:48 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Iain Hunter
Enable AP support for allmulticast for MDNS It can be enabled by bringing
up the interface with ip command with argument allmulticast on
Signed-off-by: Iain Hunter <i-hunter1@ti.com>
---
PATCH v2: resumbitting to handle error return value
drivers/net/wireless/ti/wlcore/main.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..4fabbb486e7 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -3281,6 +3281,21 @@ static void wl1271_op_configure_filter(struct ieee80211_hw *hw,
if (ret < 0)
goto out_sleep;
}
+
+ /*
+ * If interface in AP mode and created with allmulticast then disable
+ * the firmware filters so that all multicast packets are passed
+ * This is mandatory for MDNS based discovery protocols
+ */
+ if (wlvif->bss_type == BSS_TYPE_AP_BSS) {
+ if (*total & FIF_ALLMULTI) {
+ ret = wl1271_acx_group_address_tbl(wl, wlvif,
+ false,
+ NULL, 0);
+ if (ret < 0)
+ goto out_sleep;
+ }
+ }
}
/*
--
2.11.0
^ permalink raw reply related
* Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Wojciech Dubowik @ 2017-01-31 9:52 UTC (permalink / raw)
To: Klaus Kinski; +Cc: Toke Høiland-Jørgensen, Dave Taht, linux-wireless
In-Reply-To: <HE1PR0701MB1803B7D5D0182EF7DD662B18FC4A0@HE1PR0701MB1803.eurprd07.prod.outlook.com>
On 31/01/17 10:46, Klaus Kinski wrote:
> BTW, if I read the sources correctly, than IBSS mode uses the TXQ
> parameters from ieee80211_set_wmm_default with enable_qos = false
> which means that qparam.txop = 0, e.g. bursting is disabled. Am I right?
I guess so. But you need to look also at contention window sizes because
it make a big impact on throughout with retries and collisions.
>
> Jörg Pommnitz <jpo234@outlook.de <mailto:jpo234@outlook.de>> schrieb
> am Di., 31. Jan. 2017 um 10:37 Uhr:
>
> I'm mostly interested in Ad-Hoc mode, e.g. IBSS.
>
> Wojciech Dubowik <wojciech.dubowik@neratec.com
> <mailto:wojciech.dubowik@neratec.com>> schrieb am Di., 31. Jan.
> 2017 um 10:35 Uhr:
>
> That's tricky but look at
> http://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf
> <http://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf>
>
> tx_queue... are for AP and wmm_... for STA (over beacons).
>
> These should be default parameters. You can also enable CONFIG
> debug flag
>
> for ath9k and it prints wme parameters when it starts.
>
> Wojtek
>
>
> On 31/01/17 10:18, Klaus Kinski wrote:
>> It seems that bursting can be controlled over nl80211 (see ,
>> specifically with NL80211_ATTR_WIPHY_TXQ_PARAMS.
>> Unfortunately this seems not to be exposed in iw. It's an
>> attribute of NL80211_CMD_SET_WIPHY.
>> Is there another tool that exposes txq params? If not, has
>> anybody thought about exposing it in iw? I might take a stab
>> at it...
>>
>> Regards
>> Joerg
>>
>> Wojciech Dubowik <wojciech.dubowik@neratec.com
>> <mailto:wojciech.dubowik@neratec.com>> schrieb am Di., 31.
>> Jan. 2017 um 08:55 Uhr:
>>
>> Madwifi has default best effort queue "tuned" for throughout
>>
>> and its parameters are different from mac80211 defaults when
>>
>> qos (WME) is disabled.
>>
>> You would have to dump qos settings for both systems before
>>
>> comparing them. I guess the easiest way is to make sure QoS
>>
>> is enabled and send video type of packets with iperf ...
>> -S 0xa0
>>
>> Wojtek
>>
>>
>> On 30/01/17 20:43, Toke Høiland-Jørgensen wrote:
>> > Klaus Kinski <jpo234@outlook.de
>> <mailto:jpo234@outlook.de>> writes:
>> >
>> >> The captures I used to create the statistics are here:
>> >>
>> https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>> >>
>> >> An obvious difference is, that Madwifi sends 5 packets
>> in a row
>> >> without waiting for an ACK whereas ath9k/mac80211
>> always seems to wait
>> >> for an ACK. This seems to point to the "net80211
>> aggressive mode
>> >> theory" https://wiki.freebsd.org/WifiAggressiveMode
>> <https://wiki.freebsd.org/WifiAggressiveMode>, IMHO.
>> > I'm not too familiar with that part of the stack, but
>> that seems
>> > reasonable, yeah. AFAIK the "aggresive mode" is a
>> pre-802.11n feature,
>> > though, which is why you won't see that in ath9k. In
>> 802.11n this kind
>> > of bursting was replaced by aggregation, which you're
>> not getting any of
>> > since you're running in 802.11a mode, obviously.
>> >
>> > The lack of bursting will translate to slightly lower
>> throughput, which
>> > will be why you see fewer packets transmitted by ath9k.
>> Of course, if
>> > your receiver supported aggregation, the numbers would
>> look dramatically
>> > better in ath9k's favour... ;)
>> >
>> > -Toke
>>
^ permalink raw reply
* Re: Unsupported NVRAM on D-Link DIR-885L (affects brcmfmac)
From: Rafał Miłecki @ 2017-01-31 10:09 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, brcm80211 development,
Arend Van Spriel, Hante Meuleman
Cc: Hauke Mehrtens
In-Reply-To: <CACna6rx_gU-k790j=SnSvOtq5C2vxXWEQ75k=Y2CiUsHnrHEsA@mail.gmail.com>
On 31 January 2017 at 07:24, Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> wro=
te:
> I just noticed my DIR-885L has some weird NVRAM format. Linux doesn't
> support it, it reads only part of it, which may affect brcmfmac.
>
> There goes the most interesting part:
> 00000000 46 4c 53 48 50 3e 00 00 3f 01 00 00 4b 01 00 00 |FLSHP>..?...=
K...|
> 00000010 00 00 00 00 31 3a 70 61 35 67 38 30 61 33 3d 30 |....1:pa5g80=
a3=3D0|
> 00000020 78 31 64 36 36 2c 30 78 65 34 35 66 2c 30 78 32 |x1d66,0xe45f=
,0x2|
> 00000030 32 37 61 2c 30 78 32 33 36 65 2c 30 78 31 64 30 |27a,0x236e,0=
x1d0|
> 00000040 30 2c 30 78 65 62 38 38 2c 30 78 33 32 39 36 2c |0,0xeb88,0x3=
296,|
> (...)
> 00003e00 3d 36 35 35 33 35 00 31 3a 72 78 67 61 69 6e 65 |=3D65535.1:r=
xgaine|
> 00003e10 72 72 32 67 61 30 3d 36 33 00 30 3a 75 6c 62 70 |rr2ga0=3D63.=
0:ulbp|
> 00003e20 64 6f 66 66 73 35 67 62 34 61 31 3d 36 35 35 33 |doffs5gb4a1=
=3D6553|
> 00003e30 35 00 30 3a 6d 63 73 62 77 32 30 35 67 68 70 6f |5.0:mcsbw205=
ghpo|
> 00003e40 3d 32 38 35 38 38 33 35 39 36 38 00 00 00 00 00 |=3D285883596=
8.....|
> 00003e50 6f 66 66 73 65 74 32 30 69 6e 34 30 6d 32 67 3d |offset20in40=
m2g=3D|
> 00003e60 36 35 35 33 35 00 65 74 30 6d 61 63 61 64 64 72 |65535.et0mac=
addr|
> 00003e70 3d 30 30 3a 30 30 3a 30 30 3a 30 30 3a 30 30 3a |=3D00:00:00:=
00:00:|
> 00003e80 30 30 00 31 3a 72 78 67 61 69 6e 73 32 67 74 72 |00.1:rxgains=
2gtr|
>
> Header has length field 50 3e 00 00 which means 0x3e50 bytes. I was
> surprised to see more entries after then "end" of the NVRAM.
>
> What's interesting CFE (bootloader) also can't read these entries.
>
> Any idea what format is that?
I used original D-Link firmware and did:
nvram set foo=3D"loremipsum"
nvram commit
After that NVRAM looks normal. Length is 04 66 00 00 which is 0x6604
00000000 46 4c 53 48 04 66 00 00 2e 01 00 00 4b 01 00 00 |FLSH.f......K.=
..|
00000010 00 00 00 00 77 6c 31 5f 33 67 70 70 6c 69 73 74 |....wl1_3gppli=
st|
00000020 3d 00 77 6c 30 5f 72 65 61 6c 6d 6c 69 73 74 3d |=3D.wl0_realml=
ist=3D|
00000030 6d 61 69 6c 2e 65 78 61 6d 70 6c 65 2e 63 6f 6d |mail.example.c=
om|
00000040 2b 30 2b 32 31 3d 32 2c 34 23 35 2c 37 3f 63 69 |+0+21=3D2,4#5,=
7?ci|
(...)
00003e00 33 3d 31 30 38 00 77 6c 31 5f 61 63 73 5f 63 69 |3=3D108.wl1_ac=
s_ci|
00003e10 5f 73 63 61 6e 5f 74 69 6d 65 6f 75 74 3d 33 30 |_scan_timeout=
=3D30|
00003e20 30 00 77 6c 31 5f 6d 6f 64 65 3d 61 70 00 77 6c |0.wl1_mode=3Da=
p.wl|
00003e30 30 5f 64 66 73 5f 70 72 65 66 3d 00 30 3a 72 78 |0_dfs_pref=3D.=
0:rx|
00003e40 67 61 69 6e 65 72 72 32 67 61 31 3d 33 31 00 30 |gainerr2ga1=3D=
31.0|
00003e50 3a 70 64 6f 66 66 73 65 74 34 30 69 6e 38 30 6d |:pdoffset40in8=
0m|
00003e60 35 67 62 31 3d 36 35 35 33 35 00 77 6c 31 5f 72 |5gb1=3D65535.w=
l1_r|
00003e70 78 63 68 61 69 6e 5f 70 77 72 73 61 76 65 5f 65 |xchain_pwrsave=
_e|
00003e80 6e 61 62 6c 65 3d 31 00 77 6c 30 5f 61 6d 70 64 |nable=3D1.wl0_=
ampd|
(...)
000065d0 78 65 31 61 65 2c 30 78 32 39 36 31 2c 30 78 32 |xe1ae,0x2961,0=
x2|
000065e0 34 36 31 2c 30 78 31 65 61 39 2c 30 78 64 61 37 |461,0x1ea9,0xd=
a7|
000065f0 63 2c 30 78 32 30 62 31 2c 30 78 32 33 37 38 00 |c,0x20b1,0x237=
8.|
00006600 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |..............=
..|
00006610 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |..............=
..|
Should we care about this previous weird NVRAM format?
--=20
Rafa=C5=82
^ permalink raw reply
* Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Wojciech Dubowik @ 2017-01-31 9:42 UTC (permalink / raw)
To: Klaus Kinski; +Cc: Toke Høiland-Jørgensen, Dave Taht, linux-wireless
In-Reply-To: <HE1PR0701MB1803911A9D8B8CF7813C6EACFC4A0@HE1PR0701MB1803.eurprd07.prod.outlook.com>
Then you need to use CONFIG debug flag. WMM parameters are not set when
MESH compile flag is enabled. At least I have had once such problem.
Wojtek
PS It would be actually nice to have sth like madwifi's wlanconfig ...
list wme to
print QoS settings in current systems.
On 31/01/17 10:38, Klaus Kinski wrote:
> I'm mostly interested in Ad-Hoc mode, e.g. IBSS.
>
> Wojciech Dubowik <wojciech.dubowik@neratec.com
> <mailto:wojciech.dubowik@neratec.com>> schrieb am Di., 31. Jan. 2017
> um 10:35 Uhr:
>
> That's tricky but look at
> http://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf
> <http://w1.fi/cgit/hostap/tree/hostapd/hostapd.conf>
>
> tx_queue... are for AP and wmm_... for STA (over beacons).
>
> These should be default parameters. You can also enable CONFIG
> debug flag
>
> for ath9k and it prints wme parameters when it starts.
>
> Wojtek
>
>
> On 31/01/17 10:18, Klaus Kinski wrote:
>> It seems that bursting can be controlled over nl80211 (see ,
>> specifically with NL80211_ATTR_WIPHY_TXQ_PARAMS. Unfortunately
>> this seems not to be exposed in iw. It's an attribute of
>> NL80211_CMD_SET_WIPHY.
>> Is there another tool that exposes txq params? If not, has
>> anybody thought about exposing it in iw? I might take a stab at it...
>>
>> Regards
>> Joerg
>>
>> Wojciech Dubowik <wojciech.dubowik@neratec.com
>> <mailto:wojciech.dubowik@neratec.com>> schrieb am Di., 31. Jan.
>> 2017 um 08:55 Uhr:
>>
>> Madwifi has default best effort queue "tuned" for throughout
>>
>> and its parameters are different from mac80211 defaults when
>>
>> qos (WME) is disabled.
>>
>> You would have to dump qos settings for both systems before
>>
>> comparing them. I guess the easiest way is to make sure QoS
>>
>> is enabled and send video type of packets with iperf ... -S 0xa0
>>
>> Wojtek
>>
>>
>> On 30/01/17 20:43, Toke Høiland-Jørgensen wrote:
>> > Klaus Kinski <jpo234@outlook.de <mailto:jpo234@outlook.de>>
>> writes:
>> >
>> >> The captures I used to create the statistics are here:
>> >> https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>> >>
>> >> An obvious difference is, that Madwifi sends 5 packets in
>> a row
>> >> without waiting for an ACK whereas ath9k/mac80211 always
>> seems to wait
>> >> for an ACK. This seems to point to the "net80211
>> aggressive mode
>> >> theory" https://wiki.freebsd.org/WifiAggressiveMode
>> <https://wiki.freebsd.org/WifiAggressiveMode>, IMHO.
>> > I'm not too familiar with that part of the stack, but that
>> seems
>> > reasonable, yeah. AFAIK the "aggresive mode" is a
>> pre-802.11n feature,
>> > though, which is why you won't see that in ath9k. In
>> 802.11n this kind
>> > of bursting was replaced by aggregation, which you're not
>> getting any of
>> > since you're running in 802.11a mode, obviously.
>> >
>> > The lack of bursting will translate to slightly lower
>> throughput, which
>> > will be why you see fewer packets transmitted by ath9k. Of
>> course, if
>> > your receiver supported aggregation, the numbers would look
>> dramatically
>> > better in ath9k's favour... ;)
>> >
>> > -Toke
>>
^ permalink raw reply
* Re: [RFC 3/3] cfg80211: Share Channel DFS state across wiphys of same DFS domain
From: Thiagarajan, Vasanthakumar @ 2017-01-31 9:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1485423682.11038.8.camel@sipsolutions.net>
T24gVGh1cnNkYXkgMjYgSmFudWFyeSAyMDE3IDAzOjExIFBNLCBKb2hhbm5lcyBCZXJnIHdyb3Rl
Og0KPiBPbiBXZWQsIDIwMTctMDEtMjUgYXQgMTc6MDEgKzA1MzAsIFZhc2FudGhha3VtYXIgVGhp
YWdhcmFqYW4gd3JvdGU6DQo+PiBTaGFyaW5nIERGUyBjaGFubmVsIHN0YXRlIGFjcm9zcyBtdWx0
aXBsZSB3aXBoeXMgKHJhZGlvcykgY291bGQNCj4+IGJlIHVzZWZ1bCB3aXRoIG11bHRpcGxlIHJh
ZGlvcyBvbiB0aGUgc3lzdGVtLiBXaGVuIG9uZSByYWRpbw0KPj4gY29tcGxldGVzIENBQyBhbmQg
bWFya3MgdGhlIGNoYW5uZWwgYXZhaWxhYmxlIGFub3RoZXIgcmFkaW8NCj4+IGNhbiB1c2UgdGhp
cyBpbmZvcm1hdGlvbiBhbmQgc3RhcnQgYmVhY29uaW5nIHdpdGhvdXQgcmVhbGx5IGRvaW5nDQo+
PiBDQUMuDQo+Pg0KPj4gV2hlbmV2ZXIgdGhlcmUgaXMgYSBzdGF0ZSBjaGFuZ2UgaW4gREZTIGNo
YW5uZWwgYXNzb2NpYXRlZCB0bw0KPj4gYSBwYXJ0aWN1bGFyIHdpcGh5IHRoZSB0aGUgc2FtZSBz
dGF0ZSBjaGFuZ2UgaXMgcHJvcGFnYXRlZCB0bw0KPj4gb3RoZXIgd2lwaHlzIGhhdmluZyB0aGUg
c2FtZSBERlMgcmVnIGRvbWFpbiBjb25maWd1cmF0aW9uLg0KPj4gQWxzbyB3aGVuIGEgbmV3IHdp
cGh5IGlzIGNyZWF0ZWQgdGhlIERGUyBjaGFubmVsIHN0YXRlIG9mDQo+PiBvdGhlciBleGlzdGlu
ZyB3aXBoeXMgb2Ygc2FtZSBERlMgZG9tYWluIGlzIGNvcGllZC4NCj4+DQo+PiBTaWduZWQtb2Zm
LWJ5OiBWYXNhbnRoYWt1bWFyIFRoaWFnYXJhamFuIDx2dGhpYWdhckBxdGkucXVhbGNvbW0uY29t
Pg0KPj4gLS0tDQo+PiAgIG5ldC93aXJlbGVzcy9jaGFuLmMgfCAgMjQgKysrKysrKysrLS0NCj4+
ICAgbmV0L3dpcmVsZXNzL2NvcmUuYyB8ICAzNyArKysrKysrKysrKysrKysrKw0KPj4gICBuZXQv
d2lyZWxlc3MvY29yZS5oIHwgICA2ICsrKw0KPj4gICBuZXQvd2lyZWxlc3MvbWxtZS5jIHwgIDEx
ICsrKysrLQ0KPj4gICBuZXQvd2lyZWxlc3MvcmVnLmMgIHwgMTEyDQo+PiArKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+PiAgIG5ldC93aXJlbGVz
cy9yZWcuaCAgfCAgMjIgKysrKysrKysrKysNCj4+ICAgNiBmaWxlcyBjaGFuZ2VkLCAyMDcgaW5z
ZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkNCj4+DQo+PiBkaWZmIC0tZ2l0IGEvbmV0L3dpcmVs
ZXNzL2NoYW4uYyBiL25ldC93aXJlbGVzcy9jaGFuLmMNCj4+IGluZGV4IDA5MDMwOWEuLjQwZjEw
OTcgMTAwNjQ0DQo+PiAtLS0gYS9uZXQvd2lyZWxlc3MvY2hhbi5jDQo+PiArKysgYi9uZXQvd2ly
ZWxlc3MvY2hhbi5jDQo+PiBAQCAtNTMyLDIxICs1MzIsMzcgQEAgYm9vbCBjZmc4MDIxMV9iZWFj
b25pbmdfaWZhY2VfYWN0aXZlKHN0cnVjdA0KPj4gd2lyZWxlc3NfZGV2ICp3ZGV2KQ0KPj4gICAJ
cmV0dXJuIGFjdGl2ZTsNCj4+ICAgfQ0KPj4NCj4+ICtzdGF0aWMgYm9vbCBjZmc4MDIxMV81Z2h6
X2lzX3dpcGh5X29wZXJfY2hhbihzdHJ1Y3Qgd2lwaHkgKndpcGh5LA0KPj4gKwkJCQkJICAgICBz
dHJ1Y3QNCj4+IGllZWU4MDIxMV9jaGFubmVsICpjaGFuKQ0KPg0KPiBhZ2Fpbiwgbm90aGluZyBy
ZWFsbHkgNSBHSHogc3BlY2lmaWMgaGVyZSwgYWZhaWN0Pw0KDQpTdXJlLg0KDQo+DQo+PiArCXN0
cnVjdCB3aXJlbGVzc19kZXYgKndkZXY7DQo+PiArDQo+PiArCWxpc3RfZm9yX2VhY2hfZW50cnko
d2RldiwgJndpcGh5LT53ZGV2X2xpc3QsIGxpc3QpIHsNCj4+ICsJCWlmICghY2ZnODAyMTFfYmVh
Y29uaW5nX2lmYWNlX2FjdGl2ZSh3ZGV2KSkNCj4+ICsJCQljb250aW51ZTsNCj4+ICsNCj4+ICsJ
CWlmIChjZmc4MDIxMV81Z2h6X3N1Yl9jaGFuKCZ3ZGV2LT5jaGFuZGVmLCBjaGFuKSkNCj4+ICsJ
CQlyZXR1cm4gdHJ1ZTsNCj4+ICsJfQ0KPj4gKw0KPj4gKwlyZXR1cm4gZmFsc2U7DQo+PiArfQ0K
Pj4gKw0KPj4gICBib29sIGNmZzgwMjExXzVnaHpfYW55X3dpcGh5X29wZXJfY2hhbihzdHJ1Y3Qg
d2lwaHkgKndpcGh5LA0KPj4gICAJCQkJICAgICAgIHN0cnVjdCBpZWVlODAyMTFfY2hhbm5lbA0K
Pj4gKmNoYW4pDQo+PiAgIHsNCj4+IC0Jc3RydWN0IHdpcmVsZXNzX2RldiAqd2RldjsNCj4+ICsJ
c3RydWN0IGNmZzgwMjExX3JlZ2lzdGVyZWRfZGV2aWNlICpyZGV2Ow0KPj4NCj4+ICAgCUFTU0VS
VF9SVE5MKCk7DQo+Pg0KPj4gICAJaWYgKCEoY2hhbi0+ZmxhZ3MgJiBJRUVFODAyMTFfQ0hBTl9S
QURBUikpDQo+PiAgIAkJcmV0dXJuIGZhbHNlOw0KPj4NCj4+IC0JbGlzdF9mb3JfZWFjaF9lbnRy
eSh3ZGV2LCAmd2lwaHktPndkZXZfbGlzdCwgbGlzdCkgew0KPj4gLQkJaWYgKCFjZmc4MDIxMV9i
ZWFjb25pbmdfaWZhY2VfYWN0aXZlKHdkZXYpKQ0KPj4gKwlsaXN0X2Zvcl9lYWNoX2VudHJ5KHJk
ZXYsICZjZmc4MDIxMV9yZGV2X2xpc3QsIGxpc3QpIHsNCj4+ICsJCWlmICghcmVnX2Rmc19kb21h
aW5fc2FtZSh3aXBoeSwgJnJkZXYtPndpcGh5KSkNCj4+ICAgCQkJY29udGludWU7DQo+Pg0KPj4g
LQkJaWYgKGNmZzgwMjExXzVnaHpfc3ViX2NoYW4oJndkZXYtPmNoYW5kZWYsIGNoYW4pKQ0KPj4g
KwkJaWYgKGNmZzgwMjExXzVnaHpfaXNfd2lwaHlfb3Blcl9jaGFuKCZyZGV2LT53aXBoeSwNCj4+
IGNoYW4pKQ0KPj4gICAJCQlyZXR1cm4gdHJ1ZTsNCj4+ICAgCX0NCj4+DQo+PiBkaWZmIC0tZ2l0
IGEvbmV0L3dpcmVsZXNzL2NvcmUuYyBiL25ldC93aXJlbGVzcy9jb3JlLmMNCj4+IGluZGV4IDkw
M2ZjNDE5Li5jM2ZlNDRiIDEwMDY0NA0KPj4gLS0tIGEvbmV0L3dpcmVsZXNzL2NvcmUuYw0KPj4g
KysrIGIvbmV0L3dpcmVsZXNzL2NvcmUuYw0KPj4gQEAgLTM1Nyw2ICszNTcsMzggQEAgc3RhdGlj
IHZvaWQgY2ZnODAyMTFfc2NoZWRfc2Nhbl9zdG9wX3drKHN0cnVjdA0KPj4gd29ya19zdHJ1Y3Qg
KndvcmspDQo+PiAgIAlydG5sX3VubG9jaygpOw0KPj4gICB9DQo+Pg0KPj4gK3N0YXRpYyB2b2lk
IGNmZzgwMjExX3Byb3BhZ2F0ZV9yYWRhcl9kZXRlY3Rfd2soc3RydWN0IHdvcmtfc3RydWN0DQo+
PiAqd29yaykNCj4+ICt7DQo+PiArCXN0cnVjdCBjZmc4MDIxMV9yZWdpc3RlcmVkX2RldmljZSAq
cmRldjsNCj4+ICsNCj4+ICsJcmRldiA9IGNvbnRhaW5lcl9vZih3b3JrLCBzdHJ1Y3QgY2ZnODAy
MTFfcmVnaXN0ZXJlZF9kZXZpY2UsDQo+PiArCQkJICAgIHBvcnBhZ2F0ZV9yYWRhcl9kZXRlY3Rf
d2spOw0KPj4gKw0KPj4gKwlydG5sX2xvY2soKTsNCj4+ICsNCj4+ICsJcmVndWxhdG9yeV9wcm9w
YWdhdGVfZGZzX3N0YXRlKCZyZGV2LT53aXBoeSwgJnJkZXYtDQo+Pj4gcmFkYXJfY2hhbmRlZiwN
Cj4+ICsJCQkJICAgICAgIE5MODAyMTFfREZTX1VOQVZBSUxBQkxFLA0KPj4gKwkJCQkgICAgICAg
Tkw4MDIxMV9SQURBUl9ERVRFQ1RFRCk7DQo+PiArDQo+PiArCXJ0bmxfdW5sb2NrKCk7DQo+PiAr
fQ0KPj4gKw0KPj4gK3N0YXRpYyB2b2lkIGNmZzgwMjExX3Byb3BhZ2F0ZV9jYWNfZG9uZV93ayhz
dHJ1Y3Qgd29ya19zdHJ1Y3QgKndvcmspDQo+PiArew0KPj4gKwlzdHJ1Y3QgY2ZnODAyMTFfcmVn
aXN0ZXJlZF9kZXZpY2UgKnJkZXY7DQo+PiArDQo+PiArCXJkZXYgPSBjb250YWluZXJfb2Yod29y
aywgc3RydWN0IGNmZzgwMjExX3JlZ2lzdGVyZWRfZGV2aWNlLA0KPj4gKwkJCSAgICBwcm9wYWdh
dGVfY2FjX2RvbmVfd2spOw0KPj4gKw0KPj4gKwlydG5sX2xvY2soKTsNCj4+ICsNCj4+ICsJcmVn
dWxhdG9yeV9wcm9wYWdhdGVfZGZzX3N0YXRlKCZyZGV2LT53aXBoeSwgJnJkZXYtDQo+Pj4gY2Fj
X2RvbmVfY2hhbmRlZiwNCj4+ICsJCQkJICAgICAgIE5MODAyMTFfREZTX0FWQUlMQUJMRSwNCj4+
ICsJCQkJICAgICAgIE5MODAyMTFfUkFEQVJfQ0FDX0ZJTklTSEVEKTsNCj4+ICsNCj4+ICsJcnRu
bF91bmxvY2soKTsNCj4+ICt9DQo+PiArDQo+PiAgIC8qIGV4cG9ydGVkIGZ1bmN0aW9ucyAqLw0K
Pj4NCj4+ICAgc3RydWN0IHdpcGh5ICp3aXBoeV9uZXdfbm0oY29uc3Qgc3RydWN0IGNmZzgwMjEx
X29wcyAqb3BzLCBpbnQNCj4+IHNpemVvZl9wcml2LA0KPj4gQEAgLTQ1Niw2ICs0ODgsOSBAQCBz
dHJ1Y3Qgd2lwaHkgKndpcGh5X25ld19ubShjb25zdCBzdHJ1Y3QNCj4+IGNmZzgwMjExX29wcyAq
b3BzLCBpbnQgc2l6ZW9mX3ByaXYsDQo+PiAgIAlzcGluX2xvY2tfaW5pdCgmcmRldi0+ZGVzdHJv
eV9saXN0X2xvY2spOw0KPj4gICAJSU5JVF9XT1JLKCZyZGV2LT5kZXN0cm95X3dvcmssIGNmZzgw
MjExX2Rlc3Ryb3lfaWZhY2Vfd2spOw0KPj4gICAJSU5JVF9XT1JLKCZyZGV2LT5zY2hlZF9zY2Fu
X3N0b3Bfd2ssDQo+PiBjZmc4MDIxMV9zY2hlZF9zY2FuX3N0b3Bfd2spOw0KPj4gKwlJTklUX1dP
UksoJnJkZXYtPnBvcnBhZ2F0ZV9yYWRhcl9kZXRlY3Rfd2ssDQo+PiArCQkgIGNmZzgwMjExX3By
b3BhZ2F0ZV9yYWRhcl9kZXRlY3Rfd2spOw0KPj4gKwlJTklUX1dPUksoJnJkZXYtPnByb3BhZ2F0
ZV9jYWNfZG9uZV93aywNCj4+IGNmZzgwMjExX3Byb3BhZ2F0ZV9jYWNfZG9uZV93ayk7DQo+Pg0K
Pj4gICAjaWZkZWYgQ09ORklHX0NGRzgwMjExX0RFRkFVTFRfUFMNCj4+ICAgCXJkZXYtPndpcGh5
LmZsYWdzIHw9IFdJUEhZX0ZMQUdfUFNfT05fQllfREVGQVVMVDsNCj4+IEBAIC05MTQsNiArOTQ5
LDggQEAgdm9pZCB3aXBoeV91bnJlZ2lzdGVyKHN0cnVjdCB3aXBoeSAqd2lwaHkpDQo+PiAgIAlm
bHVzaF93b3JrKCZyZGV2LT5kZXN0cm95X3dvcmspOw0KPj4gICAJZmx1c2hfd29yaygmcmRldi0+
c2NoZWRfc2Nhbl9zdG9wX3drKTsNCj4+ICAgCWZsdXNoX3dvcmsoJnJkZXYtPm1sbWVfdW5yZWdf
d2spOw0KPj4gKwlmbHVzaF93b3JrKCZyZGV2LT5wb3JwYWdhdGVfcmFkYXJfZGV0ZWN0X3drKTsN
Cj4NCj4gdHlwbzogcHJvcGFnYXRlLg0KPg0KPj4gKwlmbHVzaF93b3JrKCZyZGV2LT5wcm9wYWdh
dGVfY2FjX2RvbmVfd2spOw0KPg0KPiBZb3UgZ290IGl0IHJpZ2h0IGhlcmUgOikNCg0KVGhhbmtz
LCBzb21lIHNlYXJjaCByZXBsYWNlIGlzc3VlLg0KDQo+DQo+PiAgICNpZmRlZiBDT05GSUdfUE0N
Cj4+ICAgCWlmIChyZGV2LT53aXBoeS53b3dsYW5fY29uZmlnICYmIHJkZXYtPm9wcy0+c2V0X3dh
a2V1cCkNCj4+IGRpZmYgLS1naXQgYS9uZXQvd2lyZWxlc3MvY29yZS5oIGIvbmV0L3dpcmVsZXNz
L2NvcmUuaA0KPj4gaW5kZXggMzI3ZmU5NS4uNjA3YzhiZSAxMDA2NDQNCj4+IC0tLSBhL25ldC93
aXJlbGVzcy9jb3JlLmgNCj4+ICsrKyBiL25ldC93aXJlbGVzcy9jb3JlLmgNCj4+IEBAIC05Nyw2
ICs5NywxMiBAQCBzdHJ1Y3QgY2ZnODAyMTFfcmVnaXN0ZXJlZF9kZXZpY2Ugew0KPj4NCj4+ICAg
CXN0cnVjdCB3b3JrX3N0cnVjdCBzY2hlZF9zY2FuX3N0b3Bfd2s7DQo+Pg0KPj4gKwlzdHJ1Y3Qg
Y2ZnODAyMTFfY2hhbl9kZWYgcmFkYXJfY2hhbmRlZjsNCj4+ICsJc3RydWN0IHdvcmtfc3RydWN0
IHBvcnBhZ2F0ZV9yYWRhcl9kZXRlY3Rfd2s7DQo+DQo+IFNpbmNlIGl0IGNvbXBpbGVkLCB0aGUg
dHlwbyBleGlzdHMgZXZlcnl3aGVyZSB0aGlzIGlzIHJlZmVyZW5jZWQuDQo+DQo+PiArKysgYi9u
ZXQvd2lyZWxlc3MvbWxtZS5jDQo+PiBAQCAtMTgsNyArMTgsNiBAQA0KPj4gICAjaW5jbHVkZSAi
bmw4MDIxMS5oIg0KPj4gICAjaW5jbHVkZSAicmRldi1vcHMuaCINCj4+DQo+PiAtDQo+PiAgIHZv
aWQgY2ZnODAyMTFfcnhfYXNzb2NfcmVzcChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QN
Cj4+IGNmZzgwMjExX2JzcyAqYnNzLA0KPg0KPiBwbGVhc2UgZG9uJ3QgbWFrZSB1bnJlbGF0ZWQg
ImNsZWFudXBzIi4NCg0KT29wcywgc29ycnkuDQoNCj4NCj4+ICtib29sIHJlZ19kZnNfZG9tYWlu
X3NhbWUoc3RydWN0IHdpcGh5ICp3aXBoeTEsIHN0cnVjdCB3aXBoeSAqd2lwaHkyKQ0KPj4gK3sN
Cj4+ICsJY29uc3Qgc3RydWN0IGllZWU4MDIxMV9yZWdkb21haW4gKndpcGh5MV9yZWdkID0gTlVM
TDsNCj4+ICsJY29uc3Qgc3RydWN0IGllZWU4MDIxMV9yZWdkb21haW4gKndpcGh5Ml9yZWdkID0g
TlVMTDsNCj4+ICsJY29uc3Qgc3RydWN0IGllZWU4MDIxMV9yZWdkb21haW4gKmNmZzgwMjExX3Jl
Z2QgPSBOVUxMOw0KPj4gKwlib29sIGRmc19kb21haW5fc2FtZSA9IGZhbHNlOw0KPg0KPiBZb3Ug
Y2FuIHJlbW92ZSB0aGF0IGluaXRpYWxpemVyLA0KPg0KPj4gKwlyY3VfcmVhZF9sb2NrKCk7DQo+
PiArDQo+PiArCWNmZzgwMjExX3JlZ2QgPSByY3VfZGVyZWZlcmVuY2UoY2ZnODAyMTFfcmVnZG9t
YWluKTsNCj4+ICsJd2lwaHkxX3JlZ2QgPSByY3VfZGVyZWZlcmVuY2Uod2lwaHkxLT5yZWdkKTsN
Cj4+ICsJaWYgKCF3aXBoeTFfcmVnZCkNCj4+ICsJCXdpcGh5MV9yZWdkID0gY2ZnODAyMTFfcmVn
ZDsNCj4+ICsNCj4+ICsJd2lwaHkyX3JlZ2QgPSByY3VfZGVyZWZlcmVuY2Uod2lwaHkyLT5yZWdk
KTsNCj4+ICsJaWYgKCF3aXBoeTJfcmVnZCkNCj4+ICsJCXdpcGh5Ml9yZWdkID0gY2ZnODAyMTFf
cmVnZDsNCj4+ICsNCj4+ICsJaWYgKHdpcGh5MV9yZWdkLT5kZnNfcmVnaW9uID09IHdpcGh5Ml9y
ZWdkLT5kZnNfcmVnaW9uKQ0KPj4gKwkJZGZzX2RvbWFpbl9zYW1lID0gdHJ1ZTsNCj4NCj4gYW5k
IGp1c3QgYXNzaWduDQo+IAlkZnNfZG9tYWluX3NhbWUgPSB3aXBoeTEuLi4gPT0gd2lwaHkyLi4u
Ow0KDQpPay4NCg0KPg0KPj4gK3N0YXRpYyB2b2lkIHdpcGh5X3NoYXJlX2Rmc19jaGFuX3N0YXRl
KHN0cnVjdCB3aXBoeSAqZHN0X3dpcGh5LA0KPj4gKwkJCQkgICAgICAgc3RydWN0IHdpcGh5ICpz
cmNfd2lwaHkpDQo+PiArew0KPj4gKwlzdHJ1Y3QgaWVlZTgwMjExX3N1cHBvcnRlZF9iYW5kICpz
cmNfc2JhbmQsICpkc3Rfc2JhbmQ7DQo+PiArCWludCBpLCBqOw0KPj4gKw0KPj4gKwlkc3Rfc2Jh
bmQgPSBkc3Rfd2lwaHktPmJhbmRzW05MODAyMTFfQkFORF81R0haXTsNCj4+ICsJc3JjX3NiYW5k
ID0gc3JjX3dpcGh5LT5iYW5kc1tOTDgwMjExX0JBTkRfNUdIWl07DQo+PiArCWlmICghZHN0X3Ni
YW5kIHx8ICFzcmNfc2JhbmQpDQo+PiArCQlyZXR1cm47DQo+DQo+IFdoeSBtYWtlIHRoaXMgNSBH
SHogc3BlY2lmaWM/IFBlcmhhcHMgc29tZSBraW5kIG9mIHJhZGFyIHN0dWZmIHdpbGwNCj4gZXhp
c3QgaW4gZnV0dXJlIGJhbmRzIHRvby4gSXQgc2hvdWxkbid0IHJlYWxseSBjb3N0IG11Y2ggdG8g
aXRlcmF0ZSBhbGwNCj4gdGhlIGJhbmRzLCBJIHRoaW5rPw0KDQpHb2luZyBvdmVyIGFsbCB0aGUg
YmFuZHMgc2hvdWxkIG5vdCBiZSBhbiBpc3N1ZSwgaSdsbCBtYWtlIHRoZSBjaGFuZ2UuDQoNClRo
YW5rcywNCg0KVmFzYW50aA0K
^ permalink raw reply
* Re: [RFC 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI
From: Thiagarajan, Vasanthakumar @ 2017-01-31 9:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1485423406.11038.6.camel@sipsolutions.net>
T24gVGh1cnNkYXkgMjYgSmFudWFyeSAyMDE3IDAzOjA2IFBNLCBKb2hhbm5lcyBCZXJnIHdyb3Rl
Og0KPg0KPj4gK3N0YXRpYyBib29sIGNmZzgwMjExX29mZl9jaGFubmVsX29wZXJfYWxsb3dlZChz
dHJ1Y3Qgd2lyZWxlc3NfZGV2DQo+PiAqd2RldikNCj4+ICt7DQo+PiArCWlmICghY2ZnODAyMTFf
YmVhY29uaW5nX2lmYWNlX2FjdGl2ZSh3ZGV2KSkNCj4+ICsJCXJldHVybiB0cnVlOw0KPj4gKw0K
Pj4gKwlpZiAoISh3ZGV2LT5jaGFuZGVmLmNoYW4tPmZsYWdzICYgSUVFRTgwMjExX0NIQU5fUkFE
QVIpKQ0KPj4gKwkJcmV0dXJuIHRydWU7DQo+DQo+IFRoYXQgY291bGQgdXNlIHNvbWUgbG9ja2lu
ZyBhc3NlcnRpb25zLiBNYXliZSBhbHNvIGluIHRoZQ0KPiBjZmc4MDIxMV9iZWFjb25pbmdfaWZh
Y2VfYWN0aXZlKCkgZnVuY3Rpb24geW91IGludHJvZHVjZWQgaW4gdGhlDQo+IHByZXZpb3VzIHBh
dGNoLg0KDQpPay4NCg0KPg0KPj4gKwlpZiAoIWNmZzgwMjExX29mZl9jaGFubmVsX29wZXJfYWxs
b3dlZCh3ZGV2KSkgew0KPj4gKwkJc3RydWN0IGllZWU4MDIxMV9jaGFubmVsICpjaGFuOw0KPj4g
Kw0KPj4gKwkJaWYgKHJlcXVlc3QtPm5fY2hhbm5lbHMgIT0gMSkgew0KPj4gKwkJCWVyciA9IC1F
QlVTWTsNCj4+ICsJCQlnb3RvIG91dF9mcmVlOw0KPj4gKwkJfQ0KPj4gKw0KPj4gKwkJY2hhbiA9
IHJlcXVlc3QtPmNoYW5uZWxzWzBdOw0KPj4gKwkJaWYgKGNoYW4tPmNlbnRlcl9mcmVxICE9IHdk
ZXYtPmNoYW5kZWYuY2hhbi0NCj4+PiBjZW50ZXJfZnJlcSkgew0KPj4gKwkJCWVyciA9IC1FQlVT
WTsNCj4+ICsJCQlnb3RvIG91dF9mcmVlOw0KPj4gKwkJfQ0KPj4gKwl9DQo+DQo+IEknbSBub3Qg
Y29udmluY2VkIHlvdSBldmVuIGhvbGQgdGhlIHJlbGV2YW50IGxvY2tzIGhlcmUsIHRob3VnaCBv
ZmYgdGhlDQo+IHRvcCBvZiBteSBoZWFkIEknbSBub3QgZXZlbiBzdXJlIHdoaWNoIGFyZSBuZWVk
ZWQuDQoNClRoYW5rcyBmb3IgcG9pbnRpbmcgaXQsIGl0IHNob3VsZCBiZSB3aXRoaW4gd2Rldl9s
b2NrKCkuDQoNCj4NCj4+ICAgCWkgPSAwOw0KPj4gICAJaWYgKG5fc3NpZHMpIHsNCj4+ICAgCQlu
bGFfZm9yX2VhY2hfbmVzdGVkKGF0dHIsIGluZm8tDQo+Pj4gYXR0cnNbTkw4MDIxMV9BVFRSX1ND
QU5fU1NJRFNdLCB0bXApIHsNCj4+IEBAIC05MDUzLDYgKzkwNzksNyBAQCBzdGF0aWMgaW50IG5s
ODAyMTFfcmVtYWluX29uX2NoYW5uZWwoc3RydWN0DQo+PiBza19idWZmICpza2IsDQo+PiAgIAlz
dHJ1Y3QgY2ZnODAyMTFfcmVnaXN0ZXJlZF9kZXZpY2UgKnJkZXYgPSBpbmZvLT51c2VyX3B0clsw
XTsNCj4+ICAgCXN0cnVjdCB3aXJlbGVzc19kZXYgKndkZXYgPSBpbmZvLT51c2VyX3B0clsxXTsN
Cj4+ICAgCXN0cnVjdCBjZmc4MDIxMV9jaGFuX2RlZiBjaGFuZGVmOw0KPj4gKwljb25zdCBzdHJ1
Y3QgY2ZnODAyMTFfY2hhbl9kZWYgKmNvbXBhdF9jaGFuZGVmOw0KPj4gICAJc3RydWN0IHNrX2J1
ZmYgKm1zZzsNCj4+ICAgCXZvaWQgKmhkcjsNCj4+ICAgCXU2NCBjb29raWU7DQo+PiBAQCAtOTA4
MSw2ICs5MTA4LDE0IEBAIHN0YXRpYyBpbnQgbmw4MDIxMV9yZW1haW5fb25fY2hhbm5lbChzdHJ1
Y3QNCj4+IHNrX2J1ZmYgKnNrYiwNCj4+ICAgCWlmIChlcnIpDQo+PiAgIAkJcmV0dXJuIGVycjsN
Cj4+DQo+PiArCWlmICghKGNmZzgwMjExX29mZl9jaGFubmVsX29wZXJfYWxsb3dlZCh3ZGV2KSB8
fA0KPj4gKwkgICAgICBjZmc4MDIxMV9jaGFuZGVmX2lkZW50aWNhbCgmd2Rldi0+Y2hhbmRlZiwg
JmNoYW5kZWYpKSkNCj4NCj4gSSdkIHByZWZlciB0byB3cml0ZSB0aGF0IGFzICFvZmZfY2hhbm5l
bCAmJiAhY2hhbmRlZl9pZGVudGljYWwsIHNlZW1zDQo+IGVhc2llciB0byB1bmRlcnN0YW5kIGhl
cmUuDQoNCk9rLg0KDQoNClRoYW5rcywNCg0KVmFzYW50aA0K
^ 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