* 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
* [PATCH 6/8] mwifiex: update tx_pkts_queued for requeued packets
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>
wmm.tx_pkts_queued and ralist's total_pkt_count should be updated in
synchronization. They were not correctly updated in
mwifiex_send_processed_packet().
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/wmm.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index dea2fe6..1ff3a87 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -1334,9 +1334,11 @@ mwifiex_send_processed_packet(struct mwifiex_private *priv,
skb = skb_dequeue(&ptr->skb_head);
if (adapter->data_sent || adapter->tx_lock_flag) {
+ ptr->total_pkt_count--;
spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock,
ra_list_flags);
skb_queue_tail(&adapter->tx_data_q, skb);
+ atomic_dec(&priv->wmm.tx_pkts_queued);
atomic_inc(&adapter->tx_queued);
return;
}
@@ -1394,6 +1396,10 @@ mwifiex_send_processed_packet(struct mwifiex_private *priv,
if (ret != -EBUSY) {
mwifiex_rotate_priolists(priv, ptr, ptr_index);
atomic_dec(&priv->wmm.tx_pkts_queued);
+ spin_lock_irqsave(&priv->wmm.ra_list_spinlock, ra_list_flags);
+ ptr->total_pkt_count--;
+ spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock,
+ ra_list_flags);
}
}
--
1.9.1
^ permalink raw reply related
* [PATCH 5/8] mwifiex: add memrw command information in README
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
Support for this debugfs command is available in driver. This patch
adds usage information in README file.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/README | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/README b/drivers/net/wireless/marvell/mwifiex/README
index 24e649b..588fcbe 100644
--- a/drivers/net/wireless/marvell/mwifiex/README
+++ b/drivers/net/wireless/marvell/mwifiex/README
@@ -180,6 +180,29 @@ regrdwr
echo "1 0xa060 0x12" > regrdwr : Write the MAC register
echo "1 0xa794 0x80000000" > regrdwr
: Write 0x80000000 to MAC register
+
+memrw
+ This command is used to read/write the firmware memory.
+
+ Usage:
+ 1) For reading firmware memory location.
+ echo r <address> 0 > /sys/kernel/debug/mwifiex/mlan0/memrw
+ cat /sys/kernel/debug/mwifiex/mlan0/memrw
+ 2) For writing value to firmware memory location.
+ echo w <address> [value] > /sys/kernel/debug/mwifiex/mlan0/memrw
+
+ where the parameters are,
+ <address>: memory address
+ [value]: value to be written
+
+ Examples:
+ echo r 0x4cf70 0 > /sys/kernel/debug/mwifiex/mlan0/memrw
+ cat /sys/kernel/debug/mwifiex/mlan0/memrw
+ : Read memory address 0x4cf70
+ iwpriv mlan0 memrdwr -0x7fff6000 -0x40000000
+ echo w 0x8000a000 0xc0000000 > /sys/kernel/debug/mwifiex/mlan0/memrw
+ : Write 0xc0000000 to memory address 0x8000a000
+
rdeeprom
This command is used to read the EEPROM contents of the card.
--
1.9.1
^ permalink raw reply related
* [PATCH 4/8] mwifiex: vendor_ie length check for parse WMM IEs
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>
While copying the vendor_ie obtained from the cfg80211_find_vendor_ie()
to the struct mwifiex_types_wmm_info, length/size was inappropriate.
This patch corrects the required length needed to the
mwifiex_types_wmm_info
Signed-off-by: Karthik D A <karthida@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
index a7e9f54..35d8636 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
@@ -404,7 +404,7 @@ mwifiex_set_wmm_params(struct mwifiex_private *priv,
struct cfg80211_ap_settings *params)
{
const u8 *vendor_ie;
- struct ieee_types_header *wmm_ie;
+ const u8 *wmm_ie;
u8 wmm_oui[] = {0x00, 0x50, 0xf2, 0x02};
vendor_ie = cfg80211_find_vendor_ie(WLAN_OUI_MICROSOFT,
@@ -412,9 +412,9 @@ mwifiex_set_wmm_params(struct mwifiex_private *priv,
params->beacon.tail,
params->beacon.tail_len);
if (vendor_ie) {
- wmm_ie = (struct ieee_types_header *)vendor_ie;
- memcpy(&bss_cfg->wmm_info, wmm_ie + 1,
- sizeof(bss_cfg->wmm_info));
+ wmm_ie = vendor_ie;
+ memcpy(&bss_cfg->wmm_info, wmm_ie +
+ sizeof(struct ieee_types_header), *(wmm_ie + 1));
priv->wmm_enabled = 1;
} else {
memset(&bss_cfg->wmm_info, 0, sizeof(bss_cfg->wmm_info));
--
1.9.1
^ permalink raw reply related
* [PATCH 3/8] mwifiex: Fix NULL pointer dereference in skb_dequeue()
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
At couple of places in cleanup path, we are just going through the
skb queue and freeing them without unlinking. This leads to a crash
when other thread tries to do skb_dequeue() and use already freed node.
The problem is freed by unlinking skb before freeing it.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 +++-
drivers/net/wireless/marvell/mwifiex/wmm.c | 12 +++++++++---
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 39ce76a..e83861f 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3070,8 +3070,10 @@ int mwifiex_del_virtual_intf(struct wiphy *wiphy, struct wireless_dev *wdev)
mwifiex_stop_net_dev_queue(priv->netdev, adapter);
- skb_queue_walk_safe(&priv->bypass_txq, skb, tmp)
+ skb_queue_walk_safe(&priv->bypass_txq, skb, tmp) {
+ skb_unlink(skb, &priv->bypass_txq);
mwifiex_write_data_complete(priv->adapter, skb, 0, -1);
+ }
if (netif_carrier_ok(priv->netdev))
netif_carrier_off(priv->netdev);
diff --git a/drivers/net/wireless/marvell/mwifiex/wmm.c b/drivers/net/wireless/marvell/mwifiex/wmm.c
index 0eb2465..dea2fe6 100644
--- a/drivers/net/wireless/marvell/mwifiex/wmm.c
+++ b/drivers/net/wireless/marvell/mwifiex/wmm.c
@@ -503,8 +503,10 @@ mwifiex_wmm_del_pkts_in_ralist_node(struct mwifiex_private *priv,
struct mwifiex_adapter *adapter = priv->adapter;
struct sk_buff *skb, *tmp;
- skb_queue_walk_safe(&ra_list->skb_head, skb, tmp)
+ skb_queue_walk_safe(&ra_list->skb_head, skb, tmp) {
+ skb_unlink(skb, &ra_list->skb_head);
mwifiex_write_data_complete(adapter, skb, 0, -1);
+ }
}
/*
@@ -600,11 +602,15 @@ mwifiex_clean_txrx(struct mwifiex_private *priv)
priv->adapter->if_ops.clean_pcie_ring(priv->adapter);
spin_unlock_irqrestore(&priv->wmm.ra_list_spinlock, flags);
- skb_queue_walk_safe(&priv->tdls_txq, skb, tmp)
+ skb_queue_walk_safe(&priv->tdls_txq, skb, tmp) {
+ skb_unlink(skb, &priv->tdls_txq);
mwifiex_write_data_complete(priv->adapter, skb, 0, -1);
+ }
- skb_queue_walk_safe(&priv->bypass_txq, skb, tmp)
+ skb_queue_walk_safe(&priv->bypass_txq, skb, tmp) {
+ skb_unlink(skb, &priv->bypass_txq);
mwifiex_write_data_complete(priv->adapter, skb, 0, -1);
+ }
atomic_set(&priv->adapter->bypass_tx_pending, 0);
idr_for_each(&priv->ack_status_frames, mwifiex_free_ack_frame, NULL);
--
1.9.1
^ permalink raw reply related
* [PATCH 2/8] mwifiex: report error to PCIe for suspend failure
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1475066908-11771-1-git-send-email-akarwar@marvell.com>
When host_sleep_config command fails, we should return an error to
PCIe, instead of continuing (and possibly panicking, when we try to keep
processing a timed-out ioctl after we return "successfully" from
suspend).
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 2833d47..063c707 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -101,7 +101,6 @@ static int mwifiex_pcie_suspend(struct device *dev)
{
struct mwifiex_adapter *adapter;
struct pcie_service_card *card;
- int hs_actived;
struct pci_dev *pdev = to_pci_dev(dev);
if (pdev) {
@@ -117,7 +116,14 @@ static int mwifiex_pcie_suspend(struct device *dev)
adapter = card->adapter;
- hs_actived = mwifiex_enable_hs(adapter);
+ /* Enable the Host Sleep */
+ if (!mwifiex_enable_hs(adapter)) {
+ mwifiex_dbg(adapter, ERROR,
+ "cmd: failed to suspend\n");
+ adapter->hs_enabling = false;
+ return -EFAULT;
+ }
+
flush_workqueue(adapter->workqueue);
/* Indicate device suspended */
--
1.9.1
^ permalink raw reply related
* [PATCH 1/8] mwifiex: prevent register accesses after host is sleeping
From: Amitkumar Karwar @ 2016-09-28 12:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
Following is mwifiex driver-firmware host sleep handshake.
It involves three threads. suspend handler, interrupt handler, interrupt
processing in main work queue.
1) Enter suspend handler
2) Download HS_CFG command
3) Response from firmware for HS_CFG
4) Suspend thread waits until handshake completes(i.e hs_activate becomes
true)
5) SLEEP from firmware
6) SLEEP confirm downloaded to firmware.
7) SLEEP confirm response from firmware
8) Driver processes SLEEP confirm response and set hs_activate to wake up
suspend thread
9) Exit suspend handler
10) Read sleep cookie in loop and wait until it indicates firmware is
sleep.
11) After processing SLEEP confirm response, we are at the end of interrupt
processing routine. Recheck if there are interrupts received while we were
processing them.
During suspend-resume stress test, it's been observed that we may end up
acessing PCIe hardware(in 10 and 11) when PCIe bus is closed which leads
to a kernel crash.
This patch solves the problem with below changes.
a) action 10 above can be done before 8
b) Skip 11 if hs_activated is true. SLEEP confirm response
is the last interrupt from firmware. No need to recheck for
pending interrupts.
c) Add flush_workqueue() in suspend handler.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 3c3c4f1..2833d47 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -118,6 +118,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
adapter = card->adapter;
hs_actived = mwifiex_enable_hs(adapter);
+ flush_workqueue(adapter->workqueue);
/* Indicate device suspended */
adapter->is_suspended = true;
@@ -1669,9 +1670,6 @@ static int mwifiex_pcie_process_cmd_complete(struct mwifiex_adapter *adapter)
if (!adapter->curr_cmd) {
if (adapter->ps_state == PS_STATE_SLEEP_CFM) {
- mwifiex_process_sleep_confirm_resp(adapter, skb->data,
- skb->len);
- mwifiex_pcie_enable_host_int(adapter);
if (mwifiex_write_reg(adapter,
PCIE_CPU_INT_EVENT,
CPU_INTR_SLEEP_CFM_DONE)) {
@@ -1684,6 +1682,9 @@ static int mwifiex_pcie_process_cmd_complete(struct mwifiex_adapter *adapter)
while (reg->sleep_cookie && (count++ < 10) &&
mwifiex_pcie_ok_to_access_hw(adapter))
usleep_range(50, 60);
+ mwifiex_pcie_enable_host_int(adapter);
+ mwifiex_process_sleep_confirm_resp(adapter, skb->data,
+ skb->len);
} else {
mwifiex_dbg(adapter, ERROR,
"There is no command but got cmdrsp\n");
@@ -2322,6 +2323,8 @@ static int mwifiex_process_pcie_int(struct mwifiex_adapter *adapter)
ret = mwifiex_pcie_process_cmd_complete(adapter);
if (ret)
return ret;
+ if (adapter->hs_activated)
+ return ret;
}
if (card->msi_enable) {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v8] cfg80211: Provision to allow the support for different beacon intervals
From: Johannes Berg @ 2016-09-28 11:21 UTC (permalink / raw)
To: Undekari, Sunil Dutt, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Hullur Subramanyam, Amarnath
In-Reply-To: <0b626d7836be4cce8ea4868538fe66d3@aphydexm01f.ap.qualcomm.com>
Hi,
> In PATCH v8 , cfg80211_validate_beacon_int ->
> cfg80211_iter_combinations carries the argument iftype_num , which
> also considers the "new interface" that is getting added.
Ah, right, I remember now, sorry.
> Thus , in the example you have quoted above , the iftype_num shall
> represent 2 ( AP + AP ) , and thus the min_gcd obtained out of
> cfg80211_iter_combinations (cfg80211_get_beacon_int_min_gcd) shall be
> 50 for the example 1 and 200 for the example 2 .
> Thus , considering the two examples mentioned above , the second AP
> should succeed for "example 1" vs failure for "example 2" with patch
> V8 , isn't ?
Yeah, I tried to simplify and did so too much. I believe you are, for
this purpose, ignoring for example radar detection.
Since you're passing 0 for num_different_channels and radar_detect, you
might find a combination isn't actually currently usable, but that
allows the new beacon interval configuration.
So I think overall this will only work right if it's done with all
necessary information, no?
Trying to construct another example ... let's say permitted
combinations are
* go = 3, channels = 1, min_bcn_gcd = 50
* go = 3, channels = 2, min_bcn_gcd = 100
(which isn't actually all that far-fetched, since channel hopping takes
time)
For simplification, say you already have two GOs active on different
channels (with BI 100), and want to add another one - with beacon
interval 50 - this isn't possible, but I don't think your code would
detect it?
Or, perhaps I'm reading this wrong, if your code *does* detect it then
changing the scenario a bit to have just a single channel, your code
would prevent it even though it's allowed?
> The current behavior of the kernel is to not allow the configuration
> of different beacon intervals and our expectation is that this new
> patch should be backward compatible with the existing behavior.
Correct, and I agree, we shouldn't break that.
> Now , if we go with this approach of "introducing a new argument to
> cfg80211_iter_combinations which shall be the GCD of all the existing
> combinations to check against the respective
> "diff_beacon_int_gcd_min"" , consider the case ( same one which is
> mentioned above ) that we have a single AP interface ( beacon
> interval = 300 ) , and a new AP is getting added ( beacon interval =
> 150 ), with the following allowed combinations:
>
> 1) * ap = 2
> diff_beacon_int_gcd_min = 0 ( rather not specified )
> 2) * ap = 2
> diff_beacon_int_gcd_min = 100
>
> The GCD calculated is 150 . cfg80211_iter_combinations shall return
> success for both the scenarios ( 1 and 2 ) (The intention here is to
> compare with only the nonzero " diff_beacon_int_gcd_min" )
>
> This success from "cfg80211_iter_combinations" does not represent if
> the GCD passed is compared against a 0 / non zero
> "diff_beacon_int_gcd_min" , isn't ?
>
> Thus , we are trying to solve this problem , by getting the
> "diff_beacon_int_gcd_min" for the respective interface combination ,
> before comparing it with the calculated GCD.
Oh. I think I finally understand your concern - good point!
Let me see if I understand correctly - you're saying that if I first
calculate
g = GCD(all BIs, including the new one)
and then do
cfg80211_iter_combinations(... existing variables ..., g)
then I cannot accurately determine whether or not I can use a
combination that doesn't specify a min_beacon_interval_gcd, you can't
know if the "all BIs" were the same, or not.
That's actually a very good point.
However, it seems pretty easy to solve by passing another bool that
indicates "all the same"?
johannes
^ permalink raw reply
* Re: [v2] rt2x00: add support for mac addr from device tree
From: Kalle Valo @ 2016-09-28 10:55 UTC (permalink / raw)
To: Mathias Kresin; +Cc: linux-wireless, devicetree
In-Reply-To: <CABwW5nn9gGpzBQq3ag1MhsA-bxGop93=C7mjZG9nmi26G4ar5A@mail.gmail.com>
Mathias Kresin <dev@kresin.me> writes:
> 2016-09-27 17:50 GMT+02:00 Kalle Valo <kvalo@codeaurora.org>:
>> Mathias Kresin <dev@kresin.me> wrote:
>>> On some devices the EEPROMs of Ralink Wi-Fi chips have a default Ralink
>>> MAC address set (RT3062F: 00:0C:43:30:62:00, RT3060F:
>>> 00:0C:43:30:60:00). Using multiple of these devices in the same network
>>> can cause nasty issues.
>>>
>>> Allow to override the MAC in the EEPROM with (a known good) one set in
>>> the device tree to bypass the issue.
>>>
>>> Signed-off-by: Mathias Kresin <dev@kresin.me>
>>> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
>>
>> I think this needs to update the devicetree binding document. Also
>> remember to CC the devicetree mailing list.
>>
>> Patch set to Changes Requested.
>>
>> --
>> https://patchwork.kernel.org/patch/9300893/
>
> Hey Kalle,
>
> was it intentional not to CC the linux-wireless list?
No, that was a bug in my script. Thanks for noticing it! Please always
report back if my script does something strange.
I'm adding now linux-wireless back.
> I thought about _adding_ a devicetree binding document before sending
> the patch. But in the end it would be an empty file, since I neither
> add any bindings nor introduce a compatible string. I'm just add
> support for the generic of_get_mac_address() devicetree property,
> which is meant to be used via a devicetree pci childnode.
>
> I grepped though the 4.7 code and found a few driver using
> of_get_mac_address() without having a devicetree binding document:
>
> - drivers/net/usb/smsc95xx.c
> - drivers/net/usb/smsc75xx.c
> - drivers/net/ethernet/marvell/sky2.c
> - drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> - drivers/net/ethernet/wiznet/w5100-spi.c
> - drivers/net/ethernet/arc/emac_main.c
>
> Just let me know if you are still the opinion that a devicetree
> binding document is required to get this patch accepted.
I'm not familiar enough device tree to really comment. Can someone from
the device tree list (CCed) help?
Full patch here:
https://patchwork.kernel.org/patch/9300893/
--
Kalle Valo
^ permalink raw reply
* Re: MAINTAINERS: hostap: Mark the Host AP driver obsolete
From: Kalle Valo @ 2016-09-28 10:27 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless
In-Reply-To: <20160927154258.GA6443@w1.fi>
Jouni Malinen <j@w1.fi> wrote:
> This is old code for old hardware and it is not really accurate to claim
> this to be maintained anymore. Change the status to "Obsolete" to make
> it clearer that minor cleanup and other unnecessary changes from
> automated tools is not necessarily beneficial and has larger risk of
> breaking something without being quickly noticed due to lack of testing.
>
> In addition, remove the old mailing list that does not work anymore and
> point the web-page to a more accurate URL.
>
> Signed-off-by: Jouni Malinen <j@w1.fi>
Patch applied to wireless-drivers-next.git, thanks.
ffd74aca44b7 MAINTAINERS: hostap: Mark the Host AP driver obsolete
--
https://patchwork.kernel.org/patch/9352117/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: add support for controlling tx power to a station
From: Kalle Valo @ 2016-09-28 10:14 UTC (permalink / raw)
To: Ashok Raj Nagarajan; +Cc: ath10k, Ashok Raj Nagarajan, arnagara, linux-wireless
In-Reply-To: <1465925914-6404-1-git-send-email-arnagara@qti.qualcomm.com>
Ashok Raj Nagarajan <arnagara@qti.qualcomm.com> 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
> 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>
No development on the dependency patches. I'm dropping this for now,
please resend once mac80211 patches are accepted.
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9176353/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: advertize hardware packet loss mechanism
From: Kalle Valo @ 2016-09-28 10:11 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: ath10k, linux-wireless, Rajkumar Manoharan, rmanohar
In-Reply-To: <20160906070841.4266-1-rmanohar@qti.qualcomm.com>
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
> Indicate hardware (or firmware) supports that CQM packet-loss report
> will be generated based on station kickout algorithm. As of now mac80211
> tracks connection loss by missing msdu counts (50) whereas ath10k
> firmware tracks them by missing ppdus (+ BAR tries). While firmware is
> trying to adapt its rate table, mac80211 might send out low_ack event to
> hostapd. This is causing frequent connect and disconnect iteration under
> noisy environment or when station is roaming around.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
(Note to myself in patchwork)
Depends on:
e8a24cd4b872 mac80211: allow driver to handle packet-loss mechanism
Is in net-next currently.
--
https://patchwork.kernel.org/patch/9315811/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath6kl: fix return value in ath6kl_wmi_set_pvb_cmd
From: Kalle Valo @ 2016-09-28 10:01 UTC (permalink / raw)
To: Chaehyun Lim; +Cc: linux-wireless, netdev, Chaehyun Lim
In-Reply-To: <20160918063024.2535-1-chaehyun.lim@gmail.com>
Chaehyun Lim <chaehyun.lim@gmail.com> wrote:
> When building with W=1, we got one warning as belows:
> drivers/net/wireless/ath/ath6kl/wmi.c:3509:6: warning: variable ‘ret’
> set but not used [-Wunused-but-set-variable]
>
> At the end of ath6kl_wmi_set_pvb_cmd, it is returned by 0 regardless of
> return value of ath6kl_wmi_cmd_send.
> This patch fixes return value from 0 to ret that has result of
> ath6kl_wmi_cmd_send execution.
>
> Signed-off-by: Chaehyun Lim <chaehyun.lim@gmail.com>
Patch applied to ath-next branch of ath.git, thanks.
b93015057e31 ath6kl: fix return value in ath6kl_wmi_set_pvb_cmd
--
https://patchwork.kernel.org/patch/9337611/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [2/2] ath9k: disable RNG by default
From: Kalle Valo @ 2016-09-28 10:00 UTC (permalink / raw)
To: miaoqing pan
Cc: linux-wireless, ath9k-devel, linux-crypto, smueller, jason,
pouyans, Miaoqing Pan
In-Reply-To: <1470726147-30095-2-git-send-email-miaoqing@codeaurora.org>
miaoqing pan <miaoqing@codeaurora.org> wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
> Acked-by: Stephan Mueller <smueller@chronox.de>
> Acked-by: Stephan Mueller <smueller@chronox.de>
> Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Patch applied to ath-next branch of ath.git, thanks.
739ccd76b40e ath9k: disable RNG by default
--
https://patchwork.kernel.org/patch/9270467/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: fix copy engine 5 destination ring stuck
From: Kalle Valo @ 2016-09-28 9:48 UTC (permalink / raw)
To: Rajkumar Manoharan
Cc: ath10k, stable, linux-wireless, Rajkumar Manoharan, rmanohar
In-Reply-To: <20160921105806.23980-1-rmanohar@qti.qualcomm.com>
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
> Firmware is running watchdog timer for tracking copy engine ring index
> and write index. Whenever both indices are stuck at same location for
> given duration, watchdog will be trigger to assert target. While
> updating copy engine destination ring write index, driver ensures that
> write index will not be same as read index by finding delta between these
> two indices (CE_RING_DELTA).
>
> HTT target to host copy engine (CE5) is special case where ring buffers
> will be reused and delta check is not applied while updating write index.
> In rare scenario, whenever CE5 ring is full, both indices will be referring
> same location and this is causing CE ring stuck issue as explained
> above. This issue is originally reported on IPQ4019 during long hour stress
> testing and during veriwave max clients testsuites. The same issue is
> also observed in other chips as well. Fix this by ensuring that write
> index is one less than read index which means that full ring is
> available for receiving data.
>
> Cc: stable@vger.kernel.org
> Tested-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
0628467f97b5 ath10k: fix copy engine 5 destination ring stuck
--
https://patchwork.kernel.org/patch/9343317/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Ignore SWBA event for a vif if its marked for no beacon
From: Kalle Valo @ 2016-09-28 9:48 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1474359727-6854-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> Ignore processing further in SWBA event scheduled for a vif, if mac80211
> has marked the particular vif for stop beaconing and brought the vdev
> down in 'ath10k_control_beaconing'. This should potentially avoid ath10k
> warning/error messages while running continuous wifi down/up with max
> number of vaps configured. Found this change during code walk through
> and going through other beacon configuration related functions in ath10k
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
b63b33ecafa5 ath10k: Ignore SWBA event for a vif if its marked for no beacon
--
https://patchwork.kernel.org/patch/9341147/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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