* Re: rfkill guidance
From: Johannes Berg @ 2016-09-29 11:22 UTC (permalink / raw)
To: Jonathan Richardson
Cc: linux-wireless, devicetree, Marek Belisko, Mark Rutland
In-Reply-To: <fc993a0d-25cc-fb1c-3d96-86b12d1140d2@broadcom.com>
> This clarifies the issue, thanks. Basically the reason is history -
> this user space code has been around for a while. It turns out the
> HCI BT driver doesn't exist as it should. If it did, then the
> regulator could be tied to the driver. Now I see what's missing.
So like what Marcel wrote over in his email, but with regulator vs.
GPIO. Seems completely reasonable for the BT HCI driver to support
that, if you ask me.
> We will push on the team responsible for the BT drivers but all I
> need to know right now is that an rfkill driver isn't necessary.
And indeed, that would get rid of the need for anything rfkill.
> There might be some need for this but for our purpose I think the
> right path is to have a BT driver doing what this user space app is
> doing and then integrate whatever is missing with this HCI User
> Channel.
>
Sounds good to me, even if I have no idea (and don't really need to
know) what all that is :)
I'll look at killing the rfkill-regulator driver entirely though,
since, afaict, nothing uses it.
johannes
^ permalink raw reply
* [PATCH 0/4] ath10k: fix mesh sync operation
From: Thomas Pedersen @ 2016-09-28 23:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
This patchset introduces a new ieee80211_op offset_tsf(), which gives
the driver a s64 TSF offset for TSF adjustment. This is more accurate
than programming absolute TSF since programming delay is avoided.
ath10k can't get the current TSF or program an absolute TSF, so we
remove those ops to not mislead the stack and hopefully avoid future
bugs.
Tested on QCA4019 with firmware 10.4-3.2.1-0033. After this change
Toffset remains stable to within 5us.
Thomas Pedersen (4):
mac80211: add offset_tsf driver op
ath10k: implement offset_tsf ieee80211_op
ath10k: remove set/get_tsf ieee80211_ops
mac80211: mesh: decrease max drift
drivers/net/wireless/ath/ath10k/mac.c | 45 +++++++++++--------------------
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 -
drivers/net/wireless/ath/ath10k/wmi.c | 6 ++---
drivers/net/wireless/ath/ath10k/wmi.h | 8 +++++-
include/net/mac80211.h | 8 ++++++
net/mac80211/debugfs_netdev.c | 12 ++++++---
net/mac80211/driver-ops.c | 15 +++++++++++
net/mac80211/driver-ops.h | 3 +++
net/mac80211/mesh_sync.c | 12 ++++++---
net/mac80211/trace.h | 26 ++++++++++++++++++
10 files changed, 94 insertions(+), 42 deletions(-)
--
2.10.0.297.gf6727b0
^ permalink raw reply
* [PATCH 4/4] mac80211: mesh: decrease max drift
From: Thomas Pedersen @ 2016-09-28 23:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
In-Reply-To: <20160928235631.9197-1-twp@qca.qualcomm.com>
The old value was 30ms, which means mesh sync will treat
any value below as merely TSF drift. This isn't really
reasonable (typical drift is < 10us/s) since people
probably want to adjust TSF in smaller increments (for ie.
beacon collision avoidance) without mesh sync fighting
back.
Change max drift adjustment to 0.8ms, so manual TSF
adjustments can be made in 1ms increments, with some
margin.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
net/mac80211/mesh_sync.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/mac80211/mesh_sync.c b/net/mac80211/mesh_sync.c
index 22ca43c..faca22c 100644
--- a/net/mac80211/mesh_sync.c
+++ b/net/mac80211/mesh_sync.c
@@ -28,7 +28,7 @@
* could be, for instance, in case a neighbor is restarted and its TSF counter
* reset.
*/
-#define TOFFSET_MAXIMUM_ADJUSTMENT 30000 /* 30 ms */
+#define TOFFSET_MAXIMUM_ADJUSTMENT 800 /* 0.8 ms */
struct sync_method {
u8 method;
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH 2/4] ath10k: implement offset_tsf ieee80211_op
From: Thomas Pedersen @ 2016-09-28 23:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
In-Reply-To: <20160928235631.9197-1-twp@qca.qualcomm.com>
Current set_tsf is implemented in terms of TSF_INCREMENT
only. Instead support new WMI command TSF_DECREMENT and
export these through offset_tsf. Advantage is we get
more accurate TSF adjustments, and don't calculate wrong
offset in case absolute TSF was calculated from rx_mactime
(actual TSF).
The new WMI command is available in firmware
10.4-3.2.1-00033 for QCA4019 chips. Old drivers on new
firmware or vice versa shouldn't be a problem since
get/set tsf logic was already broken.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 25 +++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 2 ++
drivers/net/wireless/ath/ath10k/wmi.h | 7 +++++++
3 files changed, 34 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 76297d6..06bd027 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6992,6 +6992,30 @@ static void ath10k_set_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
ath10k_warn(ar, "failed to set tsf offset: %d\n", ret);
}
+static void ath10k_offset_tsf(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif, s64 tsf_offset)
+{
+ struct ath10k *ar = hw->priv;
+ struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ u32 offset, vdev_param;
+ int ret;
+
+ if (tsf_offset < 0) {
+ vdev_param = ar->wmi.vdev_param->dec_tsf;
+ offset = -tsf_offset;
+ } else {
+ vdev_param = ar->wmi.vdev_param->inc_tsf;
+ offset = tsf_offset;
+ }
+
+ ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
+ vdev_param, offset);
+
+ if (ret && ret != -EOPNOTSUPP)
+ ath10k_warn(ar, "failed to set tsf offset %d cmd %d: %d\n",
+ offset, vdev_param, ret);
+}
+
static int ath10k_ampdu_action(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_ampdu_params *params)
@@ -7455,6 +7479,7 @@ static const struct ieee80211_ops ath10k_ops = {
.sta_rc_update = ath10k_sta_rc_update,
.get_tsf = ath10k_get_tsf,
.set_tsf = ath10k_set_tsf,
+ .offset_tsf = ath10k_offset_tsf,
.ampdu_action = ath10k_ampdu_action,
.get_et_sset_count = ath10k_debug_get_et_sset_count,
.get_et_stats = ath10k_debug_get_et_stats,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 38993d7..430074b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1013,6 +1013,8 @@ static struct wmi_vdev_param_map wmi_10_4_vdev_param_map = {
.rx_decap_type = WMI_10_4_VDEV_PARAM_RX_DECAP_TYPE,
.bw_nss_ratemask = WMI_10_4_VDEV_PARAM_BW_NSS_RATEMASK,
.set_tsf = WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
+ .inc_tsf = WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
+ .dec_tsf = WMI_10_4_VDEV_PARAM_TSF_DECREMENT,
};
static struct wmi_pdev_param_map wmi_pdev_param_map = {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 1b243c8..9d13c6f 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4677,6 +4677,8 @@ struct wmi_vdev_param_map {
u32 rx_decap_type;
u32 bw_nss_ratemask;
u32 set_tsf;
+ u32 inc_tsf;
+ u32 dec_tsf;
};
#define WMI_VDEV_PARAM_UNSUPPORTED 0
@@ -5009,6 +5011,11 @@ enum wmi_10_4_vdev_param {
WMI_10_4_VDEV_PARAM_STA_KICKOUT,
WMI_10_4_VDEV_PARAM_CAPABILITIES,
WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
+ WMI_10_4_VDEV_PARAM_RX_FILTER,
+ WMI_10_4_VDEV_PARAM_MGMT_TX_POWER,
+ WMI_10_4_VDEV_PARAM_ATF_SSID_SCHED_POLICY,
+ WMI_10_4_VDEV_PARAM_DISABLE_DYN_BW_RTS,
+ WMI_10_4_VDEV_PARAM_TSF_DECREMENT,
};
#define WMI_VDEV_PARAM_TXBF_SU_TX_BFEE BIT(0)
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH 1/4] mac80211: add offset_tsf driver op
From: Thomas Pedersen @ 2016-09-28 23:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
In-Reply-To: <20160928235631.9197-1-twp@qca.qualcomm.com>
Allows ie. mesh sync code to make incremental TSF
adjustments, avoiding any uncertainty introduced by delay
in programming absolute TSF.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
include/net/mac80211.h | 8 ++++++++
net/mac80211/debugfs_netdev.c | 12 +++++++++---
net/mac80211/driver-ops.c | 15 +++++++++++++++
net/mac80211/driver-ops.h | 3 +++
net/mac80211/mesh_sync.c | 10 +++++++---
net/mac80211/trace.h | 26 ++++++++++++++++++++++++++
6 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 5296100..6312cbda9f 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -3166,6 +3166,12 @@ enum ieee80211_reconfig_type {
* required function.
* The callback can sleep.
*
+ * @offset_tsf: Offset the TSF timer by the specified value in the
+ * firmware/hardware. Preferred to set_tsf as it avoids delay between
+ * calling set_tsf() and hardware getting programmed, which will show up
+ * as TSF delay. Is not a required function.
+ * The callback can sleep.
+ *
* @reset_tsf: Reset the TSF timer and allow firmware/hardware to synchronize
* with other STAs in the IBSS. This is only used in IBSS mode. This
* function is optional if the firmware/hardware takes full care of
@@ -3531,6 +3537,8 @@ struct ieee80211_ops {
u64 (*get_tsf)(struct ieee80211_hw *hw, struct ieee80211_vif *vif);
void (*set_tsf)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
u64 tsf);
+ void (*offset_tsf)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+ s64 offset);
void (*reset_tsf)(struct ieee80211_hw *hw, struct ieee80211_vif *vif);
int (*tx_last_beacon)(struct ieee80211_hw *hw);
int (*ampdu_action)(struct ieee80211_hw *hw,
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index 5d35c0f..bcec124 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -556,9 +556,15 @@ static ssize_t ieee80211_if_parse_tsf(
ret = kstrtoull(buf, 10, &tsf);
if (ret < 0)
return ret;
- if (tsf_is_delta)
- tsf = drv_get_tsf(local, sdata) + tsf_is_delta * tsf;
- if (local->ops->set_tsf) {
+ if (tsf_is_delta && local->ops->offset_tsf) {
+ drv_offset_tsf(local, sdata, tsf_is_delta * tsf);
+ wiphy_info(local->hw.wiphy,
+ "debugfs offset TSF by %018lld\n",
+ tsf_is_delta * tsf);
+ } else if (local->ops->set_tsf) {
+ if (tsf_is_delta)
+ tsf = drv_get_tsf(local, sdata) +
+ tsf_is_delta * tsf;
drv_set_tsf(local, sdata, tsf);
wiphy_info(local->hw.wiphy,
"debugfs set TSF to %#018llx\n", tsf);
diff --git a/net/mac80211/driver-ops.c b/net/mac80211/driver-ops.c
index c701b64..bb886e7 100644
--- a/net/mac80211/driver-ops.c
+++ b/net/mac80211/driver-ops.c
@@ -215,6 +215,21 @@ void drv_set_tsf(struct ieee80211_local *local,
trace_drv_return_void(local);
}
+void drv_offset_tsf(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ s64 offset)
+{
+ might_sleep();
+
+ if (!check_sdata_in_driver(sdata))
+ return;
+
+ trace_drv_offset_tsf(local, sdata, offset);
+ if (local->ops->offset_tsf)
+ local->ops->offset_tsf(&local->hw, &sdata->vif, offset);
+ trace_drv_return_void(local);
+}
+
void drv_reset_tsf(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata)
{
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index fe35a1c..f47781ab1 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -568,6 +568,9 @@ u64 drv_get_tsf(struct ieee80211_local *local,
void drv_set_tsf(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
u64 tsf);
+void drv_offset_tsf(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ s64 offset);
void drv_reset_tsf(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata);
diff --git a/net/mac80211/mesh_sync.c b/net/mac80211/mesh_sync.c
index 64bc22a..22ca43c 100644
--- a/net/mac80211/mesh_sync.c
+++ b/net/mac80211/mesh_sync.c
@@ -70,9 +70,13 @@ void mesh_sync_adjust_tbtt(struct ieee80211_sub_if_data *sdata)
}
spin_unlock_bh(&ifmsh->sync_offset_lock);
- tsf = drv_get_tsf(local, sdata);
- if (tsf != -1ULL)
- drv_set_tsf(local, sdata, tsf + tsfdelta);
+ if (local->ops->offset_tsf) {
+ drv_offset_tsf(local, sdata, tsfdelta);
+ } else {
+ tsf = drv_get_tsf(local, sdata);
+ if (tsf != -1ULL)
+ drv_set_tsf(local, sdata, tsf + tsfdelta);
+ }
}
static void mesh_sync_offset_rx_bcn_presp(struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index 77e4c53..10e9d4b 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -984,6 +984,32 @@ TRACE_EVENT(drv_set_tsf,
)
);
+TRACE_EVENT(drv_offset_tsf,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ s64 offset),
+
+ TP_ARGS(local, sdata, offset),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ VIF_ENTRY
+ __field(s64, tsf_offset)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ VIF_ASSIGN;
+ __entry->tsf_offset = offset;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT VIF_PR_FMT " tsf offset:%lld",
+ LOCAL_PR_ARG, VIF_PR_ARG,
+ (unsigned long long)__entry->tsf_offset
+ )
+);
+
DEFINE_EVENT(local_sdata_evt, drv_reset_tsf,
TP_PROTO(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata),
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* [PATCH 3/4] ath10k: remove set/get_tsf ieee80211_ops
From: Thomas Pedersen @ 2016-09-28 23:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Thomas Pedersen
In-Reply-To: <20160928235631.9197-1-twp@qca.qualcomm.com>
Neither of these did the right thing:
- get_tsf just returned 0
- set_tsf assumed a simple offset was applied against
get_tsf(), which works, except in the case of
calculating TSF from rx_mactime (actual TSF).
Just remove them for now. We can reimplement set_tsf in
terms of TSF increment/decrement in the future if get_tsf
is ever supported by FW.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 38 -------------------------------
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 -
drivers/net/wireless/ath/ath10k/wmi.c | 4 ----
drivers/net/wireless/ath/ath10k/wmi.h | 1 -
4 files changed, 44 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 06bd027..9806546 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6956,42 +6956,6 @@ static void ath10k_sta_rc_update(struct ieee80211_hw *hw,
ieee80211_queue_work(hw, &arsta->update_wk);
}
-static u64 ath10k_get_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
-{
- /*
- * FIXME: Return 0 for time being. Need to figure out whether FW
- * has the API to fetch 64-bit local TSF
- */
-
- return 0;
-}
-
-static void ath10k_set_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
- u64 tsf)
-{
- struct ath10k *ar = hw->priv;
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
- u32 tsf_offset, vdev_param = ar->wmi.vdev_param->set_tsf;
- int ret;
-
- /* Workaround:
- *
- * Given tsf argument is entire TSF value, but firmware accepts
- * only TSF offset to current TSF.
- *
- * get_tsf function is used to get offset value, however since
- * ath10k_get_tsf is not implemented properly, it will return 0 always.
- * Luckily all the caller functions to set_tsf, as of now, also rely on
- * get_tsf function to get entire tsf value such get_tsf() + tsf_delta,
- * final tsf offset value to firmware will be arithmetically correct.
- */
- tsf_offset = tsf - ath10k_get_tsf(hw, vif);
- ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id,
- vdev_param, tsf_offset);
- if (ret && ret != -EOPNOTSUPP)
- ath10k_warn(ar, "failed to set tsf offset: %d\n", ret);
-}
-
static void ath10k_offset_tsf(struct ieee80211_hw *hw,
struct ieee80211_vif *vif, s64 tsf_offset)
{
@@ -7477,8 +7441,6 @@ static const struct ieee80211_ops ath10k_ops = {
.get_survey = ath10k_get_survey,
.set_bitrate_mask = ath10k_mac_op_set_bitrate_mask,
.sta_rc_update = ath10k_sta_rc_update,
- .get_tsf = ath10k_get_tsf,
- .set_tsf = ath10k_set_tsf,
.offset_tsf = ath10k_offset_tsf,
.ampdu_action = ath10k_ampdu_action,
.get_et_sset_count = ath10k_debug_get_et_sset_count,
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index e64f593..5e399c6 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -3464,7 +3464,6 @@ static struct wmi_vdev_param_map wmi_tlv_vdev_param_map = {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
- .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
};
static const struct wmi_ops wmi_tlv_ops = {
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 430074b..8661400 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -785,7 +785,6 @@ static struct wmi_vdev_param_map wmi_vdev_param_map = {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
- .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
};
/* 10.X WMI VDEV param map */
@@ -861,7 +860,6 @@ static struct wmi_vdev_param_map wmi_10x_vdev_param_map = {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
- .set_tsf = WMI_VDEV_PARAM_UNSUPPORTED,
};
static struct wmi_vdev_param_map wmi_10_2_4_vdev_param_map = {
@@ -936,7 +934,6 @@ static struct wmi_vdev_param_map wmi_10_2_4_vdev_param_map = {
.meru_vc = WMI_VDEV_PARAM_UNSUPPORTED,
.rx_decap_type = WMI_VDEV_PARAM_UNSUPPORTED,
.bw_nss_ratemask = WMI_VDEV_PARAM_UNSUPPORTED,
- .set_tsf = WMI_10X_VDEV_PARAM_TSF_INCREMENT,
};
static struct wmi_vdev_param_map wmi_10_4_vdev_param_map = {
@@ -1012,7 +1009,6 @@ static struct wmi_vdev_param_map wmi_10_4_vdev_param_map = {
.meru_vc = WMI_10_4_VDEV_PARAM_MERU_VC,
.rx_decap_type = WMI_10_4_VDEV_PARAM_RX_DECAP_TYPE,
.bw_nss_ratemask = WMI_10_4_VDEV_PARAM_BW_NSS_RATEMASK,
- .set_tsf = WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
.inc_tsf = WMI_10_4_VDEV_PARAM_TSF_INCREMENT,
.dec_tsf = WMI_10_4_VDEV_PARAM_TSF_DECREMENT,
};
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 9d13c6f..3a73b5c 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -4676,7 +4676,6 @@ struct wmi_vdev_param_map {
u32 meru_vc;
u32 rx_decap_type;
u32 bw_nss_ratemask;
- u32 set_tsf;
u32 inc_tsf;
u32 dec_tsf;
};
--
2.10.0.297.gf6727b0
^ permalink raw reply related
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-09-28 22:10 UTC (permalink / raw)
To: Jes Sorensen
Cc: Michael Braun, kvalo, akarwar, nishants, Larry.Finger,
linux-wireless, projekt-wlan
In-Reply-To: <wrfjoa38aqi3.fsf@redhat.com>
On Wed, 2016-09-28 at 13:22 -0400, Jes Sorensen wrote:
> I'll still argue this could be handled better through gradual
> migration rather than one large patch that touches too many places,
I'd agree if it was actually a large patch, but if at all, I have to
coordinate only with Kalle, which won't be difficult.
Comparing that to the alternative - introducing new API, changing all
the users in separate patches, and finally removing the old API - and
the nightmare of coordinating that going in through various different
trees, I'll take this any day. :)
johannes
^ permalink raw reply
* Re: [PATCH 6/6] cfg80211: reduce connect key caching struct size
From: Johannes Berg @ 2016-09-28 21:57 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <20160928205855.GA27770@w1.fi>
> > struct cfg80211_cached_keys {
> > - struct key_params params[6];
> > - u8 data[6][WLAN_MAX_KEY_LEN];
> > - int def, defmgmt;
> > + struct key_params params[4];
> > + u8 data[4][WLAN_KEY_LEN_WEP104];
> > + int def;
> > };
>
> As noted in our irc discussion, this is not really a good thing to
> do.
> WEXT compat code uses this structure for all ciphers, not just static
> WEP keys. BIP configuration can use key index 4-5 and the key lengths
> can go up to 32 bytes instead of WLAN_KEY_LEN_WEP104. In other words,
> this patch should be dropped or reverted since it causes kernel
> panics due to memory corruption when writing beyond this reduced size
> structure.
Yeah, this was obviously a mistake - and smatch even pointed it out to
me, but I *still* couldn't find it.
I've just sent a fix to *really* only store the WEP keys, which fixes
the issue (after I could reproduce it) for me.
johannes
^ permalink raw reply
* [PATCH] cfg80211: wext: really don't store non-WEP keys
From: Johannes Berg @ 2016-09-28 21:56 UTC (permalink / raw)
To: linux-wireless; +Cc: Jouni Malinen, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Jouni reported that during (repeated) wext_pmf test runs (from the
wpa_supplicant hwsim test suite) the kernel crashes. The reason is
that after the key is set, the wext code still unnecessarily stores
it into the key cache. Despite smatch pointing out an overflow, I
failed to identify the possibility for this in the code and missed
it during development of the earlier patch series.
In order to fix this, simply check that we never store anything but
WEP keys into the cache, adding a comment as to why that's enough.
Also, since the cache is still allocated early even if it won't be
used in many cases, add a comment explaining why - otherwise we'd
have to roll back key settings to the driver in case of allocation
failures, which is far more difficult.
Fixes: 89b706fb28e4 ("cfg80211: reduce connect key caching struct size")
Reported-by: Jouni Malinen <j@w1.fi>
Bisected-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/wext-compat.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 7b97d43b27e1..2b096c02eb85 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -406,6 +406,10 @@ static int __cfg80211_set_encryption(struct cfg80211_registered_device *rdev,
if (pairwise && !addr)
return -EINVAL;
+ /*
+ * In many cases we won't actually need this, but it's better
+ * to do it first in case the allocation fails. Don't use wext.
+ */
if (!wdev->wext.keys) {
wdev->wext.keys = kzalloc(sizeof(*wdev->wext.keys),
GFP_KERNEL);
@@ -493,7 +497,13 @@ static int __cfg80211_set_encryption(struct cfg80211_registered_device *rdev,
if (err)
return err;
- if (!addr) {
+ /*
+ * We only need to store WEP keys, since they're the only keys that
+ * can be be set before a connection is established and persist after
+ * disconnecting.
+ */
+ if (!addr && (params->cipher == WLAN_CIPHER_SUITE_WEP40 ||
+ params->cipher == WLAN_CIPHER_SUITE_WEP104)) {
wdev->wext.keys->params[idx] = *params;
memcpy(wdev->wext.keys->data[idx],
params->key, params->key_len);
--
2.8.1
^ permalink raw reply related
* Re: [PATCH 6/6] cfg80211: reduce connect key caching struct size
From: Jouni Malinen @ 2016-09-28 20:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <1473777868-32429-6-git-send-email-johannes@sipsolutions.net>
On Tue, Sep 13, 2016 at 04:44:28PM +0200, Johannes Berg wrote:
> After the previous patches, connect keys can only (correctly)
> be used for storing static WEP keys. Therefore, remove all the
> data for dealing with key index 4/5 and reduce the size of the
> key material to the maximum for WEP keys.
> diff --git a/net/wireless/core.h b/net/wireless/core.h
> struct cfg80211_cached_keys {
> - struct key_params params[6];
> - u8 data[6][WLAN_MAX_KEY_LEN];
> - int def, defmgmt;
> + struct key_params params[4];
> + u8 data[4][WLAN_KEY_LEN_WEP104];
> + int def;
> };
As noted in our irc discussion, this is not really a good thing to do.
WEXT compat code uses this structure for all ciphers, not just static
WEP keys. BIP configuration can use key index 4-5 and the key lengths
can go up to 32 bytes instead of WLAN_KEY_LEN_WEP104. In other words,
this patch should be dropped or reverted since it causes kernel panics
due to memory corruption when writing beyond this reduced size
structure.
This was found with hwsim tests and after full day of running full test
runs, a compressed form for easy triggering of the issue was found:
hostap/tests/hwsim/vm$ ./vm-run.sh wext_pmf wext_pmf wext_pmf wext_pmf wext_pmf wext_pmf
Starting test run in a virtual machine
./run-all.sh: passing the following args to run-tests.py: wext_pmf wext_pmf wext_pmf wext_pmf wext_pmf wext_pmf
START wext_pmf 1/6
PASS wext_pmf 7.384815 2016-09-28 20:36:15.644646
START wext_pmf 2/6
qemu-system-x86_64: 9pfs:virtfs_reset: One or more uncluncked fids found during reset
qemu-system-x86_64: 9pfs:virtfs_reset: One or more uncluncked fids found during reset
KERNEL CRASHED!
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: rfkill guidance
From: Jonathan Richardson @ 2016-09-28 20:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, devicetree, Marek Belisko, Mark Rutland
In-Reply-To: <1475044682.4139.18.camel@sipsolutions.net>
Thanks for your help. Your comment below clarifies what's missing.
On 16-09-27 11:38 PM, Johannes Berg wrote:
> Hi,
>
> Mark, Marek, DT folks - the root of the discussion here is the old
> rfkill-regulator device-tree support. I'm discussing some details of
> the system here first, but below we get to the DT discussion.
>
> The old thread is here:
> http://thread.gmane.org/gmane.linux.kernel/1643236
>
>> Sure, I'll tell you what I can. A user space app handles interaction
>> between the kernel and BT radio. When the app is started, it enables
>> the regulator (via the rfkill driver and userspace sysfs interface)
>
> You should probably consider /dev/rfkill over the sysfs interface :)
>
>> to power up the BT chip. The app sends the firmware via a uart to the
>> chip. The chip loads the firmware then goes into a lower power mode.
>> When the app needs to talk to the chip it toggles a gpio (device
>> wake) before sending messages. If the kernel is in a low power mode
>> and the BT chip receives a message that requires handling by the app,
>> then a host wake gpio is driven to wake up the host (kernel).
>
> So the reason then for having it all done in userspace is that there's
> a UART to communicate with it? Or is the reason that you just don't
> want the kernel abstraction? There *are* UART BT drivers in the kernel,
> as far as I can tell, what's the difference? Or is it that there's just
> a completely different protocol, vs. the HCI protocol used normally?
>
> At this point I'm just curious though, doesn't seem all that important
> to the discussion :)
This clarifies the issue, thanks. Basically the reason is history - this
user space code has been around for a while. It turns out the HCI BT
driver doesn't exist as it should. If it did, then the regulator could
be tied to the driver. Now I see what's missing.
We will push on the team responsible for the BT drivers but all I need
to know right now is that an rfkill driver isn't necessary.
>
> Although having a DT binding for a kernel driver for the device that
> includes the regulator might change the discussion somewhat?
>
>> In addition to the regulator(s) controlled by the rfkill driver I
>> didn't mention the two gpio's previously. The existing rfkill driver
>> does nothing with them. It just exports the global gpio # to sysfs
>> which the app can read to control via the gpio sysfs interface. These
>> could be hard coded in a startup script or something, they aren't
>> that important but it does handle the conversion to the global gpio#
>> from 1 of 3 gpio controllers on a Cygnus SOC. I'm not sure how to
>> handle that, since the gpio's vary across board variants.
>
> Could also just be exposed in the DT, I guess? Userspace can read the
> DT, no? Not sure that actually gives you all the dynamic information
> though that might be needed if there's any kind of mapping going on.
I'm not sure there's any way to have the mapping done by just specifying
the gpio somewhere outside a driver. This gpio functionality I mentioned
should probably be handled by the BT HCI driver.
>
>>> Indeed, looks like Documentation/ABI/testing/sysfs-class-regulator
>>> is all read-only.
>>
>> There's a regulator driver named userspace-consumer.c that allows
>> enable/disable from userspace, but it doesn't support DT either.
>
> Adding DT support there might make some sense, perhaps? Although that's
> not really a useful DT binding at all since it won't provide any hints
> as to how you'd use that, so ... maybe not so much.
>
> As I read it, the main concern about or objection to the rfkill-
> regulator DT binding was that it's not tied to a device, when it seems
> that rfkill instances really should be living off a device that they
> control. That's true for many, but not all devices.
>
> Today we already have all the platform rfkill instances (like the
> various ACPI ones) that don't live off a device that they control, but
> instead control the platform's radio functionality. And in some cases,
> that actually has very similar behaviour to what was proposed in the
> previous patch, and what you're looking for, in that it sometimes kills
> power to BT or WiFi chips when soft-disabled (or kicks them off the bus
> in some other way). Particularly for the ones that call some random
> ACPI function to deal with things, that can happen.
>
> rfkill-regulator, with its platform driver today, more or less mirrors
> that. You could even use that with a very simple (few lines of code)
> platform module that just binds the regulators to rfkill-regulator, I
> think.
>
> Making this more flexible and configurable with DT would make sense to
> me, less for the usage of rfkill-for-a-device (which could *also* be
> done, but isn't what you need or what was discussed before), but more
> for the usage of rfkill-for-the-platform.
>
> Mark and DT folks - can you clarify your objections to the old patch?
> Am I reading things correctly, and if so, what do you think about the
> platform rfkill?
There might be some need for this but for our purpose I think the right
path is to have a BT driver doing what this user space app is doing and
then integrate whatever is missing with this HCI User Channel.
>
> johannes
>
Thanks,
Jon
^ permalink raw reply
* Re: rfkill guidance
From: Marcel Holtmann @ 2016-09-28 17:33 UTC (permalink / raw)
To: Johannes Berg
Cc: Jonathan Richardson, linux-wireless, devicetree, Marek Belisko,
Mark Rutland
In-Reply-To: <1475045391.4139.26.camel@sipsolutions.net>
Hi Johannes,
>> Today we already have all the platform rfkill instances (like the
>> various ACPI ones) that don't live off a device that they control,
>> but instead control the platform's radio functionality. And in some
>> cases, that actually has very similar behaviour to what was proposed
>> in the previous patch, and what you're looking for, in that it
>> sometimes kills power to BT or WiFi chips when soft-disabled (or
>> kicks them off the bus in some other way).
>
> Actually, let me retract that a bit. Obviously they *do* control a
> device or radio, but we don't actually know which one. And that can
> actually become a problem, since we don't even know how they work etc.
>
> So IOW, even with the ACPI stuff, there's no real "platform rfkill"
> concept - it's always killing a specific radio.
>
> There used to be some rfkill that was just reflecting the button state,
> but I think we got rid of that in favour of reflecting button state
> through hid/input, if it doesn't also control a radio.
>
> So, actually, the more I think about it the more I agree with Mark's
> objection. It doesn't really make sense to have a concept of an rfkill
> and not know what radio it controls.
>
> In your particular case, Jon, it's complicated by the fact that you
> don't want to bind a kernel driver with the rfkill, not sure where
> you'd get a device to tie the rfkill to then.
we are actually taking away the RFKILL switches that are represented by specific GPIOs. We are mapping these into the Bluetooth driver itself. This has been done for Intel and Broadcom UART based Bluetooth chips. The power control is done via the Bluetooth subsystem and that is how it should be. Enumeration of these GPIOs is done from ACPI or eventually DT (which has not made it upstream yet).
In addition, we do not want this crazy Android side of things with custom vendor specific power control via userspace or whatever crazy is done there. It can be all done through the Bluetooth subsystem and still use Android on top of it. There is a concept called HCI User Channel that allows user space application to gain exclusive access to the HCI transport. It has the advantage that the kernel does all the driver integration and handles power control.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Jes Sorensen @ 2016-09-28 17:22 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Braun, kvalo, akarwar, nishants, Larry.Finger,
linux-wireless, projekt-wlan
In-Reply-To: <1475077359.4139.44.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2016-09-28 at 11:39 -0400, Jes Sorensen wrote:
>
>> > No Jes, you're wrong this time - this is changing internal API so
>> > it does have to touch all users thereof.
>>
>> Even in this case, change the individual components in individual
>> patches and post them as a set.
>
> No, still wrong - it has to be committed as a single patch so it
> doesn't break bisect.
>
>> Changes to staging needs to go in via staging, and rtl8723au is gone
>> from the staging tree.
>>
>
> I've previously taken API change patches that touch staging, if people
> feel so inclined, and I don't think Greg will mind. I'm going to keep
> doing that unless Dave tells me he won't pull from me when I do it :)
I'll still argue this could be handled better through gradual migration
rather than one large patch that touches too many places, but if you are
willing to take it, I am not going to fight you over it :)
Jes
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-09-28 15:42 UTC (permalink / raw)
To: Jes Sorensen
Cc: Michael Braun, kvalo, akarwar, nishants, Larry.Finger,
linux-wireless, projekt-wlan
In-Reply-To: <wrfj1t04c9ug.fsf@redhat.com>
On Wed, 2016-09-28 at 11:39 -0400, Jes Sorensen wrote:
> > No Jes, you're wrong this time - this is changing internal API so
> > it does have to touch all users thereof.
>
> Even in this case, change the individual components in individual
> patches and post them as a set.
No, still wrong - it has to be committed as a single patch so it
doesn't break bisect.
> Changes to staging needs to go in via staging, and rtl8723au is gone
> from the staging tree.
>
I've previously taken API change patches that touch staging, if people
feel so inclined, and I don't think Greg will mind. I'm going to keep
doing that unless Dave tells me he won't pull from me when I do it :)
johannes
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Jes Sorensen @ 2016-09-28 15:39 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Braun, kvalo, akarwar, nishants, Larry.Finger,
linux-wireless, projekt-wlan
In-Reply-To: <1475076763.4139.42.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2016-09-28 at 11:19 -0400, Jes Sorensen wrote:
>>
>> I understand the intentions of this patch are all good, but you need
>> to not post patches that include both staging and mainline drivers at
>> the same time. In general make it a patchset and do one patch per
>> driver.
>>
>> Ideally split up changes to generic code into their own patches too.
>
> No Jes, you're wrong this time - this is changing internal API so it
> does have to touch all users thereof.
Even in this case, change the individual components in individual
patches and post them as a set.
>> Last drivers/staging/rtl8723au is gone - so your patch is going to
>> fail to apply anyway.
>
> It's there in my tree, for now, so I guess I'll see if it's still there
> when I take this in :)
Changes to staging needs to go in via staging, and rtl8723au is gone
from the staging tree.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Johannes Berg @ 2016-09-28 15:32 UTC (permalink / raw)
To: Jes Sorensen, Michael Braun
Cc: kvalo, akarwar, nishants, Larry.Finger, linux-wireless,
projekt-wlan
In-Reply-To: <wrfja8esdpcb.fsf@redhat.com>
On Wed, 2016-09-28 at 11:19 -0400, Jes Sorensen wrote:
>
> I understand the intentions of this patch are all good, but you need
> to not post patches that include both staging and mainline drivers at
> the same time. In general make it a patchset and do one patch per
> driver.
>
> Ideally split up changes to generic code into their own patches too.
No Jes, you're wrong this time - this is changing internal API so it
does have to touch all users thereof.
> Last drivers/staging/rtl8723au is gone - so your patch is going to
> fail to apply anyway.
It's there in my tree, for now, so I guess I'll see if it's still there
when I take this in :)
johannes
^ permalink raw reply
* Re: [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Jes Sorensen @ 2016-09-28 15:19 UTC (permalink / raw)
To: Michael Braun
Cc: johannes, kvalo, akarwar, nishants, Larry.Finger, linux-wireless,
projekt-wlan
In-Reply-To: <1475075672-30549-1-git-send-email-michael-dev@fami-braun.de>
Michael Braun <michael-dev@fami-braun.de> writes:
> When using WPA security, the station and thus the required key is
> identified by its mac address when packets are received. So a
> station usually cannot spoof its source mac address.
>
> But when a station sends an A-MSDU frame, port control and crypto
> is done using the outer mac address, while the packets delivered
> and forwarded use the inner mac address.
>
> IEEE 802.11-2012 mandates that the outer source mac address should
> match the inner source address (section 8.3.2.2). For the
> destination mac address, matching is not required (section 10.23.15).
>
> Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
> ---
> drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 3 ++-
> .../net/wireless/marvell/mwifiex/11n_rxreorder.c | 18 +++++++-------
> drivers/staging/rtl8723au/core/rtw_recv.c | 2 +-
> include/net/cfg80211.h | 9 +++----
> net/mac80211/rx.c | 11 +++++++--
> net/wireless/util.c | 28 +++++++++-------------
> 6 files changed, 38 insertions(+), 33 deletions(-)
I understand the intentions of this patch are all good, but you need to
not post patches that include both staging and mainline drivers at the
same time. In general make it a patchset and do one patch per driver.
Ideally split up changes to generic code into their own patches too.
Last drivers/staging/rtl8723au is gone - so your patch is going to fail
to apply anyway.
Jes
^ permalink raw reply
* [PATCHv3] wireless: check A-MSDU inner frame source address on AP interfaces
From: Michael Braun @ 2016-09-28 15:14 UTC (permalink / raw)
To: johannes
Cc: kvalo, akarwar, nishants, Larry.Finger, Jes.Sorensen,
Michael Braun, linux-wireless, projekt-wlan
When using WPA security, the station and thus the required key is
identified by its mac address when packets are received. So a
station usually cannot spoof its source mac address.
But when a station sends an A-MSDU frame, port control and crypto
is done using the outer mac address, while the packets delivered
and forwarded use the inner mac address.
IEEE 802.11-2012 mandates that the outer source mac address should
match the inner source address (section 8.3.2.2). For the
destination mac address, matching is not required (section 10.23.15).
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
---
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 3 ++-
.../net/wireless/marvell/mwifiex/11n_rxreorder.c | 18 +++++++-------
drivers/staging/rtl8723au/core/rtw_recv.c | 2 +-
include/net/cfg80211.h | 9 +++----
net/mac80211/rx.c | 11 +++++++--
net/wireless/util.c | 28 +++++++++-------------
6 files changed, 38 insertions(+), 33 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index 4fdc3da..416d060 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -1436,7 +1436,8 @@ static void iwl_mvm_report_wakeup_reasons(struct iwl_mvm *mvm,
memcpy(skb_put(pkt, pktsize), pktdata, pktsize);
- if (ieee80211_data_to_8023(pkt, vif->addr, vif->type))
+ if (ieee80211_data_to_8023(pkt, NULL, vif->addr,
+ vif->type))
goto report;
wakeup.packet = pkt->data;
wakeup.packet_present_len = pkt->len;
diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index a74cc43..f4469d7 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -30,7 +30,8 @@
* layer.
*/
static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
- struct sk_buff *skb)
+ struct sk_buff *skb,
+ const u8 *ta)
{
struct rxpd *local_rx_pd = (struct rxpd *)(skb->data);
int ret;
@@ -45,7 +46,7 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
skb_trim(skb, le16_to_cpu(local_rx_pd->rx_pkt_length));
ieee80211_amsdu_to_8023s(skb, &list, priv->curr_addr,
- priv->wdev.iftype, 0, false);
+ priv->wdev.iftype, 0, ta);
while (!skb_queue_empty(&list)) {
struct rx_packet_hdr *rx_hdr;
@@ -76,9 +77,10 @@ static int mwifiex_11n_dispatch_amsdu_pkt(struct mwifiex_private *priv,
/* This function will process the rx packet and forward it to kernel/upper
* layer.
*/
-static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void *payload)
+static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void *payload,
+ const u8 *ta)
{
- int ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload);
+ int ret = mwifiex_11n_dispatch_amsdu_pkt(priv, payload, ta);
if (!ret)
return 0;
@@ -119,7 +121,7 @@ mwifiex_11n_dispatch_pkt_until_start_win(struct mwifiex_private *priv,
}
spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
if (rx_tmp_ptr)
- mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
+ mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr, tbl->ta);
}
spin_lock_irqsave(&priv->rx_pkt_lock, flags);
@@ -161,7 +163,7 @@ mwifiex_11n_scan_and_dispatch(struct mwifiex_private *priv,
rx_tmp_ptr = tbl->rx_reorder_ptr[i];
tbl->rx_reorder_ptr[i] = NULL;
spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
- mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
+ mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr, tbl->ta);
}
spin_lock_irqsave(&priv->rx_pkt_lock, flags);
@@ -568,12 +570,12 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private *priv,
tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid, ta);
if (!tbl) {
if (pkt_type != PKT_TYPE_BAR)
- mwifiex_11n_dispatch_pkt(priv, payload);
+ mwifiex_11n_dispatch_pkt(priv, payload, ta);
return ret;
}
if ((pkt_type == PKT_TYPE_AMSDU) && !tbl->amsdu) {
- mwifiex_11n_dispatch_pkt(priv, payload);
+ mwifiex_11n_dispatch_pkt(priv, payload, ta);
return ret;
}
diff --git a/drivers/staging/rtl8723au/core/rtw_recv.c b/drivers/staging/rtl8723au/core/rtw_recv.c
index 150dabc..38ba7dd 100644
--- a/drivers/staging/rtl8723au/core/rtw_recv.c
+++ b/drivers/staging/rtl8723au/core/rtw_recv.c
@@ -1687,7 +1687,7 @@ int amsdu_to_msdu(struct rtw_adapter *padapter, struct recv_frame *prframe)
skb_pull(skb, prframe->attrib.hdrlen);
__skb_queue_head_init(&skb_list);
- ieee80211_amsdu_to_8023s(skb, &skb_list, NULL, 0, 0, false);
+ ieee80211_amsdu_to_8023s(skb, &skb_list, NULL, 0, 0, pattrib->ta);
while (!skb_queue_empty(&skb_list)) {
sub_skb = __skb_dequeue(&skb_list);
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index beb7610..d768fcd 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3905,12 +3905,13 @@ unsigned int ieee80211_get_mesh_hdrlen(struct ieee80211s_hdr *meshhdr);
/**
* ieee80211_data_to_8023 - convert an 802.11 data frame to 802.3
* @skb: the 802.11 data frame
+ * @ehdr: (out) buffer for source/destination address (optional)
* @addr: the device MAC address
* @iftype: the virtual interface type
* Return: 0 on success. Non-zero on error.
*/
-int ieee80211_data_to_8023(struct sk_buff *skb, const u8 *addr,
- enum nl80211_iftype iftype);
+int ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
+ const u8 *addr, enum nl80211_iftype iftype);
/**
* ieee80211_data_from_8023 - convert an 802.3 frame to 802.11
@@ -3938,12 +3939,12 @@ int ieee80211_data_from_8023(struct sk_buff *skb, const u8 *addr,
* @addr: The device MAC address.
* @iftype: The device interface type.
* @extra_headroom: The hardware extra headroom for SKBs in the @list.
- * @has_80211_header: Set it true if SKB is with IEEE 802.11 header.
+ * @ta: transmitter address (or NULL)
*/
void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
const u8 *addr, enum nl80211_iftype iftype,
const unsigned int extra_headroom,
- bool has_80211_header);
+ const u8 *ta);
/**
* cfg80211_classify8021d - determine the 802.1p/1d tag for a data frame
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 9dce3b1..fbf99b8 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2090,7 +2090,8 @@ __ieee80211_data_to_8023(struct ieee80211_rx_data *rx, bool *port_control)
sdata->vif.type == NL80211_IFTYPE_AP_VLAN && sdata->u.vlan.sta)
return -1;
- ret = ieee80211_data_to_8023(rx->skb, sdata->vif.addr, sdata->vif.type);
+ ret = ieee80211_data_to_8023(rx->skb, NULL, sdata->vif.addr,
+ sdata->vif.type);
if (ret < 0)
return ret;
@@ -2243,6 +2244,7 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
__le16 fc = hdr->frame_control;
struct sk_buff_head frame_list;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx->skb);
+ struct ethhdr eth_80211;
if (unlikely(!ieee80211_is_data(fc)))
return RX_CONTINUE;
@@ -2268,9 +2270,14 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx_data *rx)
skb->dev = dev;
__skb_queue_head_init(&frame_list);
+ if (ieee80211_data_to_8023(skb, ð_80211, dev->dev_addr,
+ rx->sdata->vif.type) < 0)
+ return RX_DROP_UNUSABLE;
+
ieee80211_amsdu_to_8023s(skb, &frame_list, dev->dev_addr,
rx->sdata->vif.type,
- rx->local->hw.extra_tx_headroom, true);
+ rx->local->hw.extra_tx_headroom,
+ eth_80211.h_source);
while (!skb_queue_empty(&frame_list)) {
rx->skb = __skb_dequeue(&frame_list);
diff --git a/net/wireless/util.c b/net/wireless/util.c
index b7d1592..5622740 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -414,8 +414,8 @@ unsigned int ieee80211_get_mesh_hdrlen(struct ieee80211s_hdr *meshhdr)
}
EXPORT_SYMBOL(ieee80211_get_mesh_hdrlen);
-static int __ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
- const u8 *addr, enum nl80211_iftype iftype)
+int ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
+ const u8 *addr, enum nl80211_iftype iftype)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct {
@@ -519,12 +519,6 @@ static int __ieee80211_data_to_8023(struct sk_buff *skb, struct ethhdr *ehdr,
return 0;
}
-
-int ieee80211_data_to_8023(struct sk_buff *skb, const u8 *addr,
- enum nl80211_iftype iftype)
-{
- return __ieee80211_data_to_8023(skb, NULL, addr, iftype);
-}
EXPORT_SYMBOL(ieee80211_data_to_8023);
int ieee80211_data_from_8023(struct sk_buff *skb, const u8 *addr,
@@ -740,24 +734,18 @@ __ieee80211_amsdu_copy(struct sk_buff *skb, unsigned int hlen,
void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
const u8 *addr, enum nl80211_iftype iftype,
const unsigned int extra_headroom,
- bool has_80211_header)
+ const u8 *ta)
{
unsigned int hlen = ALIGN(extra_headroom, 4);
struct sk_buff *frame = NULL;
u16 ethertype;
u8 *payload;
- int offset = 0, remaining, err;
+ int offset = 0, remaining;
struct ethhdr eth;
bool reuse_frag = skb->head_frag && !skb_has_frag_list(skb);
bool reuse_skb = false;
bool last = false;
- if (has_80211_header) {
- err = __ieee80211_data_to_8023(skb, ð, addr, iftype);
- if (err)
- goto out;
- }
-
while (!last) {
unsigned int subframe_len;
int len;
@@ -768,6 +756,13 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
subframe_len = sizeof(struct ethhdr) + len;
padding = (4 - subframe_len) & 0x3;
+ if (unlikely(ta &&
+ (iftype == NL80211_IFTYPE_AP ||
+ iftype == NL80211_IFTYPE_AP_VLAN) &&
+ !ether_addr_equal(ta, eth.h_source)
+ ))
+ goto purge;
+
/* the last MSDU has no padding */
remaining = skb->len - offset;
if (subframe_len > remaining)
@@ -813,7 +808,6 @@ void ieee80211_amsdu_to_8023s(struct sk_buff *skb, struct sk_buff_head *list,
purge:
__skb_queue_purge(list);
- out:
dev_kfree_skb(skb);
}
EXPORT_SYMBOL(ieee80211_amsdu_to_8023s);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH -next] wlcore: sdio: drop kfree for memory allocated with devm_kzalloc
From: Tony Lindgren @ 2016-09-28 15:11 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Kalle Valo, Bruno Herrera, Wei Yongjun, linux-wireless
In-Reply-To: <1475073516-7328-1-git-send-email-weiyj.lk@gmail.com>
* Wei Yongjun <weiyj.lk@gmail.com> [160928 07:39]:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> It's not necessary to free memory allocated with devm_kzalloc
> and using kfree leads to a double free.
>
> Fixes: d776fc86b82f ("wlcore: sdio: Populate config firmware data")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Oops thanks for catching this:
Acked-by: Tony Lindgren <tony@atomide.com>
> ---
> drivers/net/wireless/ti/wlcore/sdio.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
> index a6e94b1..47fe7f9 100644
> --- a/drivers/net/wireless/ti/wlcore/sdio.c
> +++ b/drivers/net/wireless/ti/wlcore/sdio.c
> @@ -391,7 +391,6 @@ static void wl1271_remove(struct sdio_func *func)
> pm_runtime_get_noresume(&func->dev);
>
> platform_device_unregister(glue->core);
> - kfree(glue);
> }
>
> #ifdef CONFIG_PM
>
^ permalink raw reply
* [PATCH -next] wlcore: sdio: drop kfree for memory allocated with devm_kzalloc
From: Wei Yongjun @ 2016-09-28 14:38 UTC (permalink / raw)
To: Kalle Valo, Bruno Herrera, Tony Lindgren; +Cc: Wei Yongjun, linux-wireless
From: Wei Yongjun <weiyongjun1@huawei.com>
It's not necessary to free memory allocated with devm_kzalloc
and using kfree leads to a double free.
Fixes: d776fc86b82f ("wlcore: sdio: Populate config firmware data")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/wireless/ti/wlcore/sdio.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index a6e94b1..47fe7f9 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -391,7 +391,6 @@ static void wl1271_remove(struct sdio_func *func)
pm_runtime_get_noresume(&func->dev);
platform_device_unregister(glue->core);
- kfree(glue);
}
#ifdef CONFIG_PM
^ permalink raw reply related
* RE: [PATCH v2] mwifiex: report wakeup for wowlan
From: Amitkumar Karwar @ 2016-09-28 13:59 UTC (permalink / raw)
To: Rajat Jain, Nishant Sarmukadam, Kalle Valo,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Cc: Wei-Ning Huang, Brian Norris, Eric Caruso, rajatxjain@gmail.com
In-Reply-To: <1475027104-17423-1-git-send-email-rajatja@google.com>
> From: Rajat Jain [mailto:rajatja@google.com]
> Sent: Wednesday, September 28, 2016 7:15 AM
> To: Amitkumar Karwar; Nishant Sarmukadam; Kalle Valo; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org
> Cc: Rajat Jain; Wei-Ning Huang; Brian Norris; Eric Caruso;
> rajatxjain@gmail.com
> Subject: [PATCH v2] mwifiex: report wakeup for wowlan
>
> Enable notifying wakeup source to the PM core in case of a wake on
> wireless LAN event.
>
> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
> Signed-off-by: Rajat Jain <rajatja@google.com>
> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
> ---
> v2: Fix the commit log
>
> drivers/net/wireless/marvell/mwifiex/sdio.c | 8 ++++++++
> drivers/net/wireless/marvell/mwifiex/sdio.h | 1 +
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c
> b/drivers/net/wireless/marvell/mwifiex/sdio.c
> index d3e1561..a5f63e4 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
> @@ -89,6 +89,9 @@ static irqreturn_t mwifiex_wake_irq_wifi(int irq, void
> *priv)
> disable_irq_nosync(irq);
> }
>
> + /* Notify PM core we are wakeup source */
> + pm_wakeup_event(cfg->dev, 0);
> +
> return IRQ_HANDLED;
> }
>
> @@ -112,6 +115,7 @@ static int mwifiex_sdio_probe_of(struct device *dev,
> struct sdio_mmc_card *card)
> GFP_KERNEL);
> cfg = card->plt_wake_cfg;
> if (cfg && card->plt_of_node) {
> + cfg->dev = dev;
> cfg->irq_wifi = irq_of_parse_and_map(card->plt_of_node, 0);
> if (!cfg->irq_wifi) {
> dev_dbg(dev,
> @@ -130,6 +134,10 @@ static int mwifiex_sdio_probe_of(struct device
> *dev, struct sdio_mmc_card *card)
> }
> }
>
> + ret = device_init_wakeup(dev, true);
> + if (ret)
> + dev_err(dev, "fail to init wakeup for mwifiex");
> +
> return 0;
> }
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h
> b/drivers/net/wireless/marvell/mwifiex/sdio.h
> index db837f1..07cdd23 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sdio.h
> +++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
> @@ -155,6 +155,7 @@
> } while (0)
>
> struct mwifiex_plt_wake_cfg {
> + struct device *dev;
> int irq_wifi;
> bool wake_by_wifi;
> };
> --
> 2.8.0.rc3.226.g39d4020
Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Regards,
Amitkumar
^ permalink raw reply
* wireless-drivers-next closed for 4.9
From: Kalle Valo @ 2016-09-28 13:48 UTC (permalink / raw)
To: linux-wireless
Hi,
I just pushed the last patches to wireless-drivers-next and I'm planning
to send the final pull request to Dave tomorrow. This means that
wireless-drivers-next is closed and will open again for patches going to
4.10 sometime after 4.9-rc1 is released. Feel free to submit patches at
this time, they will be just queued in patchwork until the tree is open
again.
For Linux release schedules estimations PHB crystal ball is a nice
service. The deadline for wireless-drivers patches is usually a week
before the merge window opens.
http://phb-crystal-ball.org/
wireless-drivers remains open for important bug and regressions fixes to
4.9.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: fix debug cal data file
From: Valo, Kalle @ 2016-09-28 13:26 UTC (permalink / raw)
To: Nikolay Martynov
Cc: linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <1474341984-19220-1-git-send-email-mar.kolya@gmail.com>
Nikolay Martynov <mar.kolya@gmail.com> writes:
> It got broken by 0b8e3c4ca29fe2c0efd3d41a76e34a657b9f17a4
>
> Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Good catch, I'll queue this to 4.9.
There was one checkpatch warning I fixed:
drivers/net/wireless/ath/ath10k/debug.c:1477: Prefer vmalloc(sizeof(*data).=
..) over vmalloc(sizeof(struct ath10k_debug_cal_data)...)
The commit log is quite short so added more information about the bug.
The full patch is in the pending branch.
Author: Nikolay Martynov <mar.kolya@gmail.com>
Date: Wed Sep 28 15:11:52 2016 +0300
ath10k: fix debug cal data file
=20
Commit 0b8e3c4ca29f ("ath10k: move cal data len to hw_params") broke re=
trieving
the calibration data from cal_data debugfs file. The length of file was=
always
zero. The reason is:
=20
static ssize_t ath10k_debug_cal_data_read(struct file *file,
char __user *user_buf,
size_t count, loff_t *ppos)
{
struct ath10k *ar =3D file->private_data;
void *buf =3D file->private_data;
=20
=20
This is obviously bogus, private_data cannot contain both struct ath10k=
and the
buffer. Fix it by introducing a new temporary structure for storing bot=
h the
length of the buffer and the actual buffer, then struct ath10k is not n=
eeded
anymore.
=20
Fixes: 0b8e3c4ca29f ("ath10k: move cal data len to hw_params")
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
[kvalo@qca.qualcomm.com: improve commit log, fix a checkpatch warning]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
--=20
Kalle Valo=
^ permalink raw reply
* [PATCH 8/8] mwifiex: fix p2p device doesn't find in scan problem
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Karthik D A, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
From: Karthik D A <karthida@marvell.com>
Marvell p2p device disappears from the list of p2p peers on the other
p2p device after disconnection.
It happens due to a bug in driver. When interface is changed from p2p
to station, certain variables(bss_type, bss_role etc.) aren't correctly
updated. This patch corrects them to fix the issue.
Signed-off-by: Karthik D A <karthida@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index e83861f..d9f5445 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -1203,6 +1203,12 @@ mwifiex_cfg80211_change_virtual_intf(struct wiphy *wiphy,
priv->adapter->curr_iface_comb.p2p_intf--;
priv->adapter->curr_iface_comb.sta_intf++;
dev->ieee80211_ptr->iftype = type;
+ if (mwifiex_deinit_priv_params(priv))
+ return -1;
+ if (mwifiex_init_new_priv_params(priv, dev, type))
+ return -1;
+ if (mwifiex_sta_init_cmd(priv, false, false))
+ return -1;
break;
case NL80211_IFTYPE_ADHOC:
if (mwifiex_cfg80211_deinit_p2p(priv))
--
1.9.1
^ permalink raw reply related
* [PATCH 7/8] mwifiex: fix command timeout problem seen in stress tests
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
It is observed that if single tid 6 packet comes among with massive tid 0
packets, tid 6 packet may stay in it's queue and will never be
transmited. This is because wmm.highest_queued_prio will be set to 2
during transmission of tid 0 packets As a result, main work thread
keeps on looping without serving that packet. In this case, if command
has downloaded to firmware, driver doesn't process it's response causing
command timeout.
This patch will reset highest_queued_prio if packets exist in data
queue, and try to find a ra_list for current private.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/main.h | 1 +
drivers/net/wireless/marvell/mwifiex/wmm.c | 13 ++++++++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index 26df28f..d61fe3a 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -315,6 +315,7 @@ struct mwifiex_tid_tbl {
#define WMM_HIGHEST_PRIORITY 7
#define HIGH_PRIO_TID 7
#define LOW_PRIO_TID 0
+#define NO_PKT_PRIO_TID -1
#define MWIFIEX_WMM_DRV_DELAY_MAX 510
struct mwifiex_wmm_desc {
diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 1ff3a87..28c2f6f 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -1105,6 +1105,7 @@ mwifiex_wmm_get_highest_priolist_ptr(struct mwifiex_adapter *adapter,
&adapter->bss_prio_tbl[j].bss_prio_head,
list) {
+try_again:
priv_tmp = adapter->bss_prio_tbl[j].bss_prio_cur->priv;
if (((priv_tmp->bss_mode != NL80211_IFTYPE_ADHOC) &&
@@ -1140,8 +1141,18 @@ mwifiex_wmm_get_highest_priolist_ptr(struct mwifiex_adapter *adapter,
ra_list_spinlock,
flags_ra);
}
- }
+ if (atomic_read(&priv_tmp->wmm.tx_pkts_queued) != 0) {
+ atomic_set(&priv_tmp->wmm.highest_queued_prio,
+ HIGH_PRIO_TID);
+ /* Iterate current private once more, since
+ * there still exist packets in data queue
+ */
+ goto try_again;
+ } else
+ atomic_set(&priv_tmp->wmm.highest_queued_prio,
+ NO_PKT_PRIO_TID);
+ }
}
return NULL;
--
1.9.1
^ permalink raw reply related
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