[PATCH] ath10k: fix use-after-free in ath10k_wmi_cmd_send_nowait

[Carl Huang]

The skb may be freed in tx completion context before
trace_ath10k_wmi_cmd is called. This can be easily captured
when KASAN(Kernel Address Sanitizer) is enabled. The fix is
to add a reference count to the skb and release it after
trace_ath10k_wmi_cmd is called.

Signed-off-by: Carl Huang 
---
 drivers/net/wireless/ath/ath10k/wmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 58dc218..e63aedb 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2005-2011 Atheros Communications Inc.
  * Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -1742,8 +1743,10 @@ int ath10k_wmi_cmd_send_nowait(struct ath10k *ar, struct 
sk_buff *skb,
cmd_hdr->cmd_id = __cpu_to_le32(cmd);
 
memset(skb_cb, 0, sizeof(*skb_cb));
+   skb_get(skb);
ret = ath10k_htc_send(>htc, ar->wmi.eid, skb);
trace_ath10k_wmi_cmd(ar, cmd_id, skb->data, skb->len, ret);
+   dev_kfree_skb(skb);
 
if (ret)
goto err_pull;
-- 
2.7.4

[PATCH] ath10k: fix use-after-free in ath10k_wmi_cmd_send_nowait

[Carl Huang]

The skb may be freed in tx completion context before
trace_ath10k_wmi_cmd is called. This can be easily captured
when KASAN(Kernel Address Sanitizer) is enabled. The fix is
to add a reference count to the skb and release it after
trace_ath10k_wmi_cmd is called.

Signed-off-by: Carl Huang 
---
 drivers/net/wireless/ath/ath10k/wmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 58dc218..e63aedb 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2005-2011 Atheros Communications Inc.
  * Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -1742,8 +1743,10 @@ int ath10k_wmi_cmd_send_nowait(struct ath10k *ar, struct 
sk_buff *skb,
cmd_hdr->cmd_id = __cpu_to_le32(cmd);
 
memset(skb_cb, 0, sizeof(*skb_cb));
+   skb_get(skb);
ret = ath10k_htc_send(>htc, ar->wmi.eid, skb);
trace_ath10k_wmi_cmd(ar, cmd_id, skb->data, skb->len, ret);
+   dev_kfree_skb(skb);
 
if (ret)
goto err_pull;
-- 
2.7.4

Re: Regulatory: reg.c : wiphy_apply_custom_regulatory()

[Johannes Berg]

> Can wiphy_apply_custom_regulatory() be called after wiphy registeration?
> The documentation(comment) says "/* Used by drivers prior to wiphy
> registration */"
> Whys is there a restriction to call this after registration? Is the
> comment outdated? After Tracing the regulatory code in the cfg80211,
> it seems that there should be no restriction.

Well, I think nothing gets reported to userspace when you call this
function, which I think is the reason for this.

If you want to update on the fly you should call
regulatory_set_wiphy_regd() instead?

johannes

Re: mac80211 scan results, signal value not reliable

[Johannes Berg]

On Thu, 2018-02-08 at 09:49 +, Jean Pierre TOSONI wrote:

> In net/mac80211/scan.c, function ieee80211_bss_info_update() passes
> incoming scan results to the generic wireless layer, with indication of
> the received signal level, but no indication of signal validity.

Well, there is an indication of validity, if the value is 0 then it's
invalid.

> Before ieee80211_bss_info_update() is called, rx_status->flag can be set
> to RX_FLAG_NO_SIGNAL_VAL by the ath9k driver and it won't be taken into
> account in the wireless layer.
> Even later in ieee80211_bss_info_update(), rx_status->flag can also be set
> to RX_FLAG_NO_SIGNAL_VAL, and the wireless layer won't be aware of this.

However, it looks like you're right and ieee80211_bss_info_update()
doesn't take the flag into account. Bit strange that we even have the
flag I guess, since we treat 0 as an invalid value in various places,
being too high power to realistically receive anyway.

> I stumbled on this because, when using ath9k (WLE350NX) to do a passive scan
> off-channel, the beacons received in a 30ms window after channel change show
> a signal level +10dB above the real value. So I was looking for a way to
> tell the above layers that the signal is invalid. RX_FLAG_NO_SIGNAL_VAL seems
> to fit, but is not conveyed up to iw or wpa_supplicant.
> 
> In fact I did not find any such thing in net/wireless/nl80211.c, function
> nl80211_send_bss().
> 
> Any suggestion? Did I miss something?

Want to send a patch? There seem to be a few more places as well, e.g.
in rx.c for cfg80211_report_obss_beacon() and cfg80211_rx_mgmt().

johannes

Re: [PATCH v2] ieee80211: Increase the PMK maximum length to 64 bytes

[Johannes Berg]

On Sat, 2018-02-10 at 12:32 +0200, Jouni Malinen wrote:
> 
> > Yeah I'm concerned about this too - and regardless of that issue, we
> > probably need those drivers that do support it to advertise support for
> > the new curves, and then allow the longer PMK length only for those that do?
> 
> Please note that some drivers may not support even the current
> PMK_MAX_LEN (48) value. In fact, most of the cfg80211 cases using
> NL80211_ATTR_PMK are separately enforcing shorter lengths (32 or that
> 48), so this change in PMK_MAX_LEN definition does not actually have any
> impact for many of the existing cases. 

Ok. If the drivers are checking/don't care then we can deal without
extra feature bits or something, IMHO, at least with respect to this
specific issue of length checks.

> The only place where it does make
> a difference is NL80211_CMD_SET_PMKSA and NL80211_ATTR_PMK was added for
> that command with FILS authentication in mind in the first place (and
> that would not get a 64 octet value from wpa_supplicant at least).

Ok.

> It turns out that there are no known use of PMK with DPP authentication
> at the moment in any driver, so for now, I think I'll just make
> wpa_supplicant skip addition of the NL80211_ATTR_PMK if the PMK is
> longer than 48 octets. This should take care of the most immediate need,

Fair enough.

> but it would be good to prepare for the possibility of there being a
> driver/firmware that would like to offload roaming and 4-way handshake
> with DPP APs and do that using this PMK value from DPP network
> introduction rather than offloading network introduction. For that to
> work, PMK_MAX_LEN needs to be increased.

So let's do the patch anyway? I mean ... it's one patch or the other,
so doesn't really make a huge difference?

> So DPP works just fine with most drivers even with the 64 octet PMK (as
> long as that wpa_supplicant change goes in) when there is no requirement
> of offloading 4-way handshake.

Right.

> As far as driver support for various PMK lengths is concerned, how
> should that be advertised? The limits can be different for each
> particular use of NL80211_ATTR_PMK (NL80211_CMD_CONNECT,
> NL80211_CMD_ASSOCIATE, NL80211_START_AP, NL80211_CMD_SET_PMKSA (for
> FILS), NL80211_CMD_SET_PMKSA (for DPP), NL80211_CMD_SET_PMKSA (for
> something else), NL80211_CMD_SET_PMK).

Yeah, that seems somewhat problematic? Though I'd hope they're kinda
all the same limits?

Perhaps we rather need something like "DPP supported" vs. "long PMK
supported" since just "long PMK" doesn't really say anything about the
supported curves?

johannes

Re: [PATCH] ath9k: turn on btcoex_enable as default

[Felix Fietkau]

On 2018-02-10 14:56, Kai Heng Feng wrote:
> 
>> On 9 Feb 2018, at 3:16 PM, Kalle Valo  wrote:
>> Sure, but we have to make sure that we don't create regressions on
>> existing systems. For example, did you test this with any system which
>> don't support btcoex? (just asking, haven't tested this myself)
> 
> No not really, but I will definitely test it.
> The only module I have that uses ath9k is Dell’s DW1707.
> How do I check if it support btcoex or not?
I just reviewed the code again, and I am sure that we cannot merge this
patch. Enabling the btcoex parameter makes the driver enable a whole
bunch of code starting timers, listening to some GPIOs, etc.

On non-btcoex systems, some of those GPIOs might be floating or even
connected to different things, which could cause a lot of undefined
behavior.

This is simply too big a risk, so there absolutely needs to be a
whitelist for systems that need this, otherwise it has to remain
disabled by default.

- Felix

[PATCH v2 3/4] qtnfmac: implement asynchronous firmware loading

[Sergey Matyukevich]

In pci probe() function start firmware loading, protocol handshake
and driver core initialization, and not wait for completion.

Signed-off-by: Sergei Maksimenko 
---
 drivers/net/wireless/quantenna/qtnfmac/bus.h   |   3 +-
 .../net/wireless/quantenna/qtnfmac/pearl/pcie.c| 375 ++---
 2 files changed, 180 insertions(+), 198 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/bus.h 
b/drivers/net/wireless/quantenna/qtnfmac/bus.h
index 56e5fed92a2a..0a1604683bab 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/bus.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/bus.h
@@ -59,8 +59,9 @@ struct qtnf_bus {
char fwname[32];
struct napi_struct mux_napi;
struct net_device mux_dev;
-   struct completion request_firmware_complete;
+   struct completion firmware_init_complete;
struct workqueue_struct *workqueue;
+   struct work_struct fw_work;
struct work_struct event_work;
struct mutex bus_lock; /* lock during command/event processing */
struct dentry *dbg_dir;
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index 7aa86d8e..f117904d9120 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -127,7 +127,7 @@ static inline void qtnf_dis_txdone_irq(struct 
qtnf_pcie_bus_priv *priv)
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
-static int qtnf_pcie_init_irq(struct qtnf_pcie_bus_priv *priv)
+static void qtnf_pcie_init_irq(struct qtnf_pcie_bus_priv *priv)
 {
struct pci_dev *pdev = priv->pdev;
 
@@ -148,8 +148,6 @@ static int qtnf_pcie_init_irq(struct qtnf_pcie_bus_priv 
*priv)
pr_warn("legacy PCIE interrupts enabled\n");
pci_intx(pdev, 1);
}
-
-   return 0;
 }
 
 static void qtnf_deassert_intx(struct qtnf_pcie_bus_priv *priv)
@@ -956,6 +954,98 @@ static const struct qtnf_bus_ops qtnf_pcie_bus_ops = {
.data_rx_stop   = qtnf_pcie_data_rx_stop,
 };
 
+static int qtnf_dbg_mps_show(struct seq_file *s, void *data)
+{
+   struct qtnf_bus *bus = dev_get_drvdata(s->private);
+   struct qtnf_pcie_bus_priv *priv = get_bus_priv(bus);
+
+   seq_printf(s, "%d\n", priv->mps);
+
+   return 0;
+}
+
+static int qtnf_dbg_msi_show(struct seq_file *s, void *data)
+{
+   struct qtnf_bus *bus = dev_get_drvdata(s->private);
+   struct qtnf_pcie_bus_priv *priv = get_bus_priv(bus);
+
+   seq_printf(s, "%u\n", priv->msi_enabled);
+
+   return 0;
+}
+
+static int qtnf_dbg_irq_stats(struct seq_file *s, void *data)
+{
+   struct qtnf_bus *bus = dev_get_drvdata(s->private);
+   struct qtnf_pcie_bus_priv *priv = get_bus_priv(bus);
+   u32 reg = readl(PCIE_HDP_INT_EN(priv->pcie_reg_base));
+   u32 status;
+
+   seq_printf(s, "pcie_irq_count(%u)\n", priv->pcie_irq_count);
+   seq_printf(s, "pcie_irq_tx_count(%u)\n", priv->pcie_irq_tx_count);
+   status = reg &  PCIE_HDP_INT_TX_BITS;
+   seq_printf(s, "pcie_irq_tx_status(%s)\n",
+  (status == PCIE_HDP_INT_TX_BITS) ? "EN" : "DIS");
+   seq_printf(s, "pcie_irq_rx_count(%u)\n", priv->pcie_irq_rx_count);
+   status = reg &  PCIE_HDP_INT_RX_BITS;
+   seq_printf(s, "pcie_irq_rx_status(%s)\n",
+  (status == PCIE_HDP_INT_RX_BITS) ? "EN" : "DIS");
+   seq_printf(s, "pcie_irq_uf_count(%u)\n", priv->pcie_irq_uf_count);
+   status = reg &  PCIE_HDP_INT_HHBM_UF;
+   seq_printf(s, "pcie_irq_hhbm_uf_status(%s)\n",
+  (status == PCIE_HDP_INT_HHBM_UF) ? "EN" : "DIS");
+
+   return 0;
+}
+
+static int qtnf_dbg_hdp_stats(struct seq_file *s, void *data)
+{
+   struct qtnf_bus *bus = dev_get_drvdata(s->private);
+   struct qtnf_pcie_bus_priv *priv = get_bus_priv(bus);
+
+   seq_printf(s, "tx_full_count(%u)\n", priv->tx_full_count);
+   seq_printf(s, "tx_done_count(%u)\n", priv->tx_done_count);
+   seq_printf(s, "tx_reclaim_done(%u)\n", priv->tx_reclaim_done);
+   seq_printf(s, "tx_reclaim_req(%u)\n", priv->tx_reclaim_req);
+
+   seq_printf(s, "tx_bd_r_index(%u)\n", priv->tx_bd_r_index);
+   seq_printf(s, "tx_bd_p_index(%u)\n",
+  readl(PCIE_HDP_RX0DMA_CNT(priv->pcie_reg_base))
+   & (priv->tx_bd_num - 1));
+   seq_printf(s, "tx_bd_w_index(%u)\n", priv->tx_bd_w_index);
+   seq_printf(s, "tx queue len(%u)\n",
+  CIRC_CNT(priv->tx_bd_w_index, priv->tx_bd_r_index,
+   priv->tx_bd_num));
+
+   seq_printf(s, "rx_bd_r_index(%u)\n", priv->rx_bd_r_index);
+   seq_printf(s, "rx_bd_p_index(%u)\n",
+  readl(PCIE_HDP_TX0DMA_CNT(priv->pcie_reg_base))
+   & (priv->rx_bd_num - 1));
+   seq_printf(s, "rx_bd_w_index(%u)\n", priv->rx_bd_w_index);
+   seq_printf(s, "rx alloc queue len(%u)\n",

[PATCH v2 1/4] qtnfmac: fix releasing Tx/Rx data buffers

[Sergey Matyukevich]

Add missing PCI unmap for Tx buffers and release all buffers explicitly.
Managed release using devm_add_action is not suitable for qtnfmac Tx/Rx
data buffers. The reason is in ordering and dependencies: buffers
should be released after transmission is stopped but before PCI
device resources and DMA allocations are released.

Signed-off-by: Sergey Matyukevich 
---
 .../net/wireless/quantenna/qtnfmac/pearl/pcie.c| 30 +-
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index 6f6190964320..be5813aa1486 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -478,10 +478,11 @@ static int alloc_rx_buffers(struct qtnf_pcie_bus_priv 
*priv)
 }
 
 /* all rx/tx activity should have ceased before calling this function */
-static void free_xfer_buffers(void *data)
+static void qtnf_free_xfer_buffers(struct qtnf_pcie_bus_priv *priv)
 {
-   struct qtnf_pcie_bus_priv *priv = (struct qtnf_pcie_bus_priv *)data;
+   struct qtnf_tx_bd *txbd;
struct qtnf_rx_bd *rxbd;
+   struct sk_buff *skb;
dma_addr_t paddr;
int i;
 
@@ -489,19 +490,26 @@ static void free_xfer_buffers(void *data)
for (i = 0; i < priv->rx_bd_num; i++) {
if (priv->rx_skb && priv->rx_skb[i]) {
rxbd = >rx_bd_vbase[i];
+   skb = priv->rx_skb[i];
paddr = QTN_HOST_ADDR(le32_to_cpu(rxbd->addr_h),
  le32_to_cpu(rxbd->addr));
pci_unmap_single(priv->pdev, paddr, SKB_BUF_SIZE,
 PCI_DMA_FROMDEVICE);
-
-   dev_kfree_skb_any(priv->rx_skb[i]);
+   dev_kfree_skb_any(skb);
+   priv->rx_skb[i] = NULL;
}
}
 
/* free tx buffers */
for (i = 0; i < priv->tx_bd_num; i++) {
if (priv->tx_skb && priv->tx_skb[i]) {
-   dev_kfree_skb_any(priv->tx_skb[i]);
+   txbd = >tx_bd_vbase[i];
+   skb = priv->tx_skb[i];
+   paddr = QTN_HOST_ADDR(le32_to_cpu(txbd->addr_h),
+ le32_to_cpu(txbd->addr));
+   pci_unmap_single(priv->pdev, paddr, skb->len,
+PCI_DMA_TODEVICE);
+   dev_kfree_skb_any(skb);
priv->tx_skb[i] = NULL;
}
}
@@ -1321,12 +1329,6 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
goto err_base;
}
 
-   ret = devm_add_action(>dev, free_xfer_buffers, (void *)pcie_priv);
-   if (ret) {
-   pr_err("custom release callback init failed\n");
-   goto err_base;
-   }
-
ret = qtnf_pcie_init_xfer(pcie_priv);
if (ret) {
pr_err("PCIE xfer init failed\n");
@@ -1343,7 +1345,7 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
   "qtnf_pcie_irq", (void *)bus);
if (ret) {
pr_err("failed to request pcie irq %d\n", pdev->irq);
-   goto err_base;
+   goto err_xfer;
}
 
tasklet_init(_priv->reclaim_tq, qtnf_reclaim_tasklet_fn,
@@ -1387,6 +1389,9 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
 err_bringup_fw:
netif_napi_del(>mux_napi);
 
+err_xfer:
+   qtnf_free_xfer_buffers(pcie_priv);
+
 err_base:
flush_workqueue(pcie_priv->workqueue);
destroy_workqueue(pcie_priv->workqueue);
@@ -1416,6 +1421,7 @@ static void qtnf_pcie_remove(struct pci_dev *pdev)
destroy_workqueue(priv->workqueue);
tasklet_kill(>reclaim_tq);
 
+   qtnf_free_xfer_buffers(priv);
qtnf_debugfs_remove(bus);
 
qtnf_pcie_free_shm_ipc(priv);
-- 
2.11.0

[PATCH v2 2/4] qtnfmac: enable reloading of qtnfmac kernel modules

[Sergey Matyukevich]

From: Sergei Maksimenko 

This patch enables rmmod/insmod for qtnfmac kernel modules:
- do not 'pin' pci device in order to disable it on module unload
- implement card reset procedure
- restore PCI bar addresses for restarted wireless card

Signed-off-by: Sergei Maksimenko 
Signed-off-by: Sergey Matyukevich 
---
 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c   | 15 ++-
 drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_ipc.h   |  1 +
 .../wireless/quantenna/qtnfmac/pearl/pcie_regs_pearl.h|  1 +
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index be5813aa1486..7aa86d8e 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -162,6 +162,17 @@ static void qtnf_deassert_intx(struct qtnf_pcie_bus_priv 
*priv)
qtnf_non_posted_write(cfg, reg);
 }
 
+static void qtnf_reset_card(struct qtnf_pcie_bus_priv *priv)
+{
+   const u32 data = QTN_PEARL_IPC_IRQ_WORD(QTN_PEARL_LHOST_EP_RESET);
+   void __iomem *reg = priv->sysctl_bar +
+   QTN_PEARL_SYSCTL_LHOST_IRQ_OFFSET;
+
+   qtnf_non_posted_write(data, reg);
+   msleep(QTN_EP_RESET_WAIT_MS);
+   pci_restore_state(priv->pdev);
+}
+
 static void qtnf_ipc_gen_ep_int(void *arg)
 {
const struct qtnf_pcie_bus_priv *priv = arg;
@@ -1308,7 +1319,6 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
goto err_base;
}
 
-   pcim_pin_device(pdev);
pci_set_master(pdev);
 
ret = qtnf_pcie_init_irq(pcie_priv);
@@ -1323,6 +1333,8 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
goto err_base;
}
 
+   pci_save_state(pdev);
+
ret = qtnf_pcie_init_shm_ipc(pcie_priv);
if (ret < 0) {
pr_err("PCIE SHM IPC init failed\n");
@@ -1425,6 +1437,7 @@ static void qtnf_pcie_remove(struct pci_dev *pdev)
qtnf_debugfs_remove(bus);
 
qtnf_pcie_free_shm_ipc(priv);
+   qtnf_reset_card(priv);
 }
 
 #ifdef CONFIG_PM_SLEEP
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_ipc.h 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_ipc.h
index c5a4e46d26ef..00bb21a1c47a 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_ipc.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_ipc.h
@@ -46,6 +46,7 @@
 /* state transition timeouts */
 #define QTN_FW_DL_TIMEOUT_MS   3000
 #define QTN_FW_QLINK_TIMEOUT_MS3
+#define QTN_EP_RESET_WAIT_MS   1000
 
 #define PCIE_HDP_INT_RX_BITS (0\
| PCIE_HDP_INT_EP_TXDMA \
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_regs_pearl.h 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_regs_pearl.h
index 5b48b425fa7f..0bfe285b6b48 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_regs_pearl.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie_regs_pearl.h
@@ -351,5 +351,6 @@
 
 #define QTN_PEARL_IPC_IRQ_WORD(irq)(BIT(irq) | BIT(irq + 16))
 #define QTN_PEARL_LHOST_IPC_IRQ(6)
+#define QTN_PEARL_LHOST_EP_RESET   (7)
 
 #endif /* __PEARL_PCIE_H */
-- 
2.11.0

[PATCH v2 4/4] qtnfmac: enable networked standby mode on device inactivity

[Sergey Matyukevich]

From: Sergei Maksimenko 

Enable support of networked standby mode (NSM) on qsr10g devices.
Networked standby is a power saving mode when the device keeps
all existing network connections and returns to full power mode
on a network activity. When enabled, device enters standby mode
after 15 min of inactivity (no associated stations or no trattic).
This period can be changed by setting sysfs attribute standby_timeout
(0 disables NSM support). A module parameter auto_standby
(defaults to 1) controls enabling NSM support on module loading.

Signed-off-by: Sergei Maksimenko 
---
 drivers/net/wireless/quantenna/qtnfmac/bus.h  |  1 +
 drivers/net/wireless/quantenna/qtnfmac/commands.c | 33 ++
 drivers/net/wireless/quantenna/qtnfmac/commands.h |  1 +
 drivers/net/wireless/quantenna/qtnfmac/core.c | 77 +++
 drivers/net/wireless/quantenna/qtnfmac/core.h |  2 +
 drivers/net/wireless/quantenna/qtnfmac/qlink.h| 30 +
 6 files changed, 144 insertions(+)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/bus.h 
b/drivers/net/wireless/quantenna/qtnfmac/bus.h
index 0a1604683bab..7a27ffc6c7a7 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/bus.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/bus.h
@@ -65,6 +65,7 @@ struct qtnf_bus {
struct work_struct event_work;
struct mutex bus_lock; /* lock during command/event processing */
struct dentry *dbg_dir;
+   u32 standby_timeout;
/* bus private data */
char bus_priv[0] __aligned(sizeof(void *));
 };
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.c 
b/drivers/net/wireless/quantenna/qtnfmac/commands.c
index deca0060eb27..1e730c9fa371 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.c
@@ -2753,3 +2753,36 @@ int qtnf_cmd_set_mac_acl(const struct qtnf_vif *vif,
 
return ret;
 }
+
+int qtnf_cmd_send_pm_set(struct qtnf_bus *bus, u8 pm_mode, u32 timeout)
+{
+   struct sk_buff *cmd_skb;
+   u16 res_code = QLINK_CMD_RESULT_OK;
+   struct qlink_cmd_pm_set *cmd;
+   int ret = 0;
+
+   cmd_skb = qtnf_cmd_alloc_new_cmdskb(QLINK_MACID_RSVD, QLINK_VIFID_RSVD,
+   QLINK_CMD_PM_SET, sizeof(*cmd));
+   if (!cmd_skb)
+   return -ENOMEM;
+
+   cmd = (struct qlink_cmd_pm_set *)cmd_skb->data;
+   cmd->pm_mode = pm_mode;
+   cmd->pm_standby_timer = cpu_to_le32(timeout);
+
+   qtnf_bus_lock(bus);
+
+   ret = qtnf_cmd_send(bus, cmd_skb, _code);
+
+   if (unlikely(ret))
+   goto out;
+
+   if (unlikely(res_code != QLINK_CMD_RESULT_OK)) {
+   pr_err("cmd exec failed: 0x%.4X\n", res_code);
+   ret = -EFAULT;
+   }
+
+out:
+   qtnf_bus_unlock(bus);
+   return ret;
+}
diff --git a/drivers/net/wireless/quantenna/qtnfmac/commands.h 
b/drivers/net/wireless/quantenna/qtnfmac/commands.h
index 69a7d56f7e58..a06e6a96c35d 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/commands.h
+++ b/drivers/net/wireless/quantenna/qtnfmac/commands.h
@@ -81,5 +81,6 @@ int qtnf_cmd_start_cac(const struct qtnf_vif *vif,
   u32 cac_time_ms);
 int qtnf_cmd_set_mac_acl(const struct qtnf_vif *vif,
 const struct cfg80211_acl_data *params);
+int qtnf_cmd_send_pm_set(struct qtnf_bus *bus, u8 pm_mode, u32 timeout);
 
 #endif /* QLINK_COMMANDS_H_ */
diff --git a/drivers/net/wireless/quantenna/qtnfmac/core.c 
b/drivers/net/wireless/quantenna/qtnfmac/core.c
index cf26c15a84f8..10c4e3ea2404 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/core.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/core.c
@@ -26,6 +26,10 @@
 #include "event.h"
 #include "util.h"
 
+static bool auto_standby = true;
+module_param(auto_standby, bool, 0644);
+MODULE_PARM_DESC(auto_standby, "set to 0 to disable auto standby mode");
+
 #define QTNF_DMP_MAX_LEN 48
 #define QTNF_PRIMARY_VIF_IDX   0
 
@@ -552,6 +556,53 @@ static int qtnf_core_mac_attach(struct qtnf_bus *bus, 
unsigned int macid)
return ret;
 }
 
+static ssize_t qtnf_pm_standby_timeout_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct qtnf_bus *bus = dev_get_drvdata(dev);
+
+   sprintf(buf, "%u\n", bus->standby_timeout);
+   return strlen(buf);
+}
+
+static ssize_t qtnf_pm_standby_timeout_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   struct qtnf_bus *bus = dev_get_drvdata(dev);
+   int timeout;
+
+   if (count < 1)
+   goto out;
+
+   if (kstrtoint(buf, 0, ))
+   goto out;
+
+   if (timeout < 0)
+   timeout = 0;
+   else if (timeout > S32_MAX)

[PATCH v2 0/4] qtnfmac: qsr10g pcie backend updates

[Sergey Matyukevich]

Hello Kalle and all,

Here is a patch set with various fixes and enhacements for qsr10g
PCIe backend driver. The major changes include the following two
items:
- make rmmod/insmod work properly for qtnfmac_pcie driver
- provide configuration knobs to control NSM (networked standby mode)

NSM (networked standby mode) is not related to WiFi standard. This is
a term that has been introduced by European Commission in regulation
No. 1275/2008. Simplifying things a bit, that regulation specifies
ecodesing requirements for various operating modes. In that document
‘networked standby’ is defined as a condition in which the equipment
is able to resume a function by way of a remotely initiated trigger
from a network connection.

Regards,
Sergey


Changes v1 -> v2
- do not perform fw check using request_firmware (Arend)
- meld rmmod/insmod fixes into async fw async load patch
  -- those fixes are reworked by that patch anyway


Sergei Maksimenko (3)
  qtnfmac: implement asynchronous firmware loading
  qtnfmac: enable reloading of qtnfmac kernel modules
  qtnfmac: enable networked standby mode on device

Sergey Matyukevich (1)
  qtnfmac: fix releasing Tx/Rx data buffers


 bus.h   |4 
 commands.c  |   33 +++
 commands.h  |1 
 core.c  |   77 
 core.h  |2 
 pearl/pcie.c|  418 
 pearl/pcie_ipc.h|1 
 pearl/pcie_regs_pearl.h |1 
 qlink.h |   30 +++
 9 files changed, 357 insertions(+), 210 deletions(-)

Re: [PATCH] ath9k: turn on btcoex_enable as default

[Kai Heng Feng]

> On 9 Feb 2018, at 3:16 PM, Kalle Valo  wrote:
> Sure, but we have to make sure that we don't create regressions on
> existing systems. For example, did you test this with any system which
> don't support btcoex? (just asking, haven't tested this myself)

No not really, but I will definitely test it.
The only module I have that uses ath9k is Dell’s DW1707.
How do I check if it support btcoex or not?

(I resend the mail because my last mail get changed to HTML by my mail client)

Kai-Heng

> 
> -- 
> Kalle Valo

[PATCH v2] mac80211: round IEEE80211_TX_STATUS_HEADROOM up to multiple of 4

[Felix Fietkau]

This ensures that mac80211 allocated management frames are properly
aligned, which makes copying them more efficient.
For instance, mt76 uses iowrite32_copy to copy beacon frames to beacon
template memory on the chip.
Misaligned 32-bit accesses cause CPU exceptions on MIPS and should be
avoided.

Signed-off-by: Felix Fietkau 
---
 include/net/mac80211.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 906e90223066..c96511fa9198 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -4149,7 +4149,7 @@ void ieee80211_sta_uapsd_trigger(struct ieee80211_sta 
*sta, u8 tid);
  * The TX headroom reserved by mac80211 for its own tx_status functions.
  * This is enough for the radiotap header.
  */
-#define IEEE80211_TX_STATUS_HEADROOM   14
+#define IEEE80211_TX_STATUS_HEADROOM   ALIGN(14, 4)
 
 /**
  * ieee80211_sta_set_buffered - inform mac80211 about driver-buffered frames
-- 
2.14.2

Re: [PATCH v2] ieee80211: Increase the PMK maximum length to 64 bytes

[Jouni Malinen]

On Wed, Feb 07, 2018 at 09:21:34PM +0100, Johannes Berg wrote:
> On Wed, 2018-02-07 at 20:35 +0100, Arend van Spriel wrote:
> > On 2/7/2018 5:20 PM, Srinivas Dasari wrote:
> > > This is needed to cover the case of DPP with the NIST P-521 and
> > > brainpoolP512r1 curves which derive a PMK that is longer than the
> > > previously used limit.
> > 
> > So how are driver supposed to deal with this longer PMK. Maybe if you 
> > could elaborate on what DPP stands for in this context it would become 
> > more clear. 
> 
> device provisioning protocol, I guess? But longer curves and longer PMK
> is kinda obvious, whichever way that ends up getting used.

Yes, that's what DPP stands for here. With those two curves, the PMK
will be 64 octets.

> > Can we stick with PMK_MAX_LEN or does it need to be more 
> > fine-grained per use-case? If existing drivers only support 48 bytes PMK 
> > and trust nl80211 code to check that limit it may screw them up. Not?
> 
> Yeah I'm concerned about this too - and regardless of that issue, we
> probably need those drivers that do support it to advertise support for
> the new curves, and then allow the longer PMK length only for those that do?

Please note that some drivers may not support even the current
PMK_MAX_LEN (48) value. In fact, most of the cfg80211 cases using
NL80211_ATTR_PMK are separately enforcing shorter lengths (32 or that
48), so this change in PMK_MAX_LEN definition does not actually have any
impact for many of the existing cases. The only place where it does make
a difference is NL80211_CMD_SET_PMKSA and NL80211_ATTR_PMK was added for
that command with FILS authentication in mind in the first place (and
that would not get a 64 octet value from wpa_supplicant at least).

It turns out that there are no known use of PMK with DPP authentication
at the moment in any driver, so for now, I think I'll just make
wpa_supplicant skip addition of the NL80211_ATTR_PMK if the PMK is
longer than 48 octets. This should take care of the most immediate need,
but it would be good to prepare for the possibility of there being a
driver/firmware that would like to offload roaming and 4-way handshake
with DPP APs and do that using this PMK value from DPP network
introduction rather than offloading network introduction. For that to
work, PMK_MAX_LEN needs to be increased.

So DPP works just fine with most drivers even with the 64 octet PMK (as
long as that wpa_supplicant change goes in) when there is no requirement
of offloading 4-way handshake.

As far as driver support for various PMK lengths is concerned, how
should that be advertised? The limits can be different for each
particular use of NL80211_ATTR_PMK (NL80211_CMD_CONNECT,
NL80211_CMD_ASSOCIATE, NL80211_START_AP, NL80211_CMD_SET_PMKSA (for
FILS), NL80211_CMD_SET_PMKSA (for DPP), NL80211_CMD_SET_PMKSA (for
something else), NL80211_CMD_SET_PMK).

-- 
Jouni MalinenPGP id EFC895FA