Re: [PATCH] NFC: pn533: don't send USB data off of the stack

[kbuild test robot]

Hi Greg,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Greg-KH/NFC-pn533-don-t-send-USB-data-off-of-the-stack/20180518-100416
config: i386-randconfig-x013-201819 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/nfc/pn533/usb.c: In function 'pn533_usb_send_ack':
>> drivers/nfc/pn533/usb.c:163:15: error: invalid operands to binary | (have 
>> 'struct urb *' and 'int')
 phy->out_urb |= URB_FREE_BUFFER;
  ^~
   drivers/nfc/pn533/usb.c: In function 'pn533_usb_send_frame':
   drivers/nfc/pn533/usb.c:180:15: error: invalid operands to binary & (have 
'struct urb *' and 'int')
 phy->out_urb &= ~URB_FREE_BUFFER;
  ^~
   drivers/nfc/pn533/usb.c: In function 'pn533_acr122_poweron_rdr':
   drivers/nfc/pn533/usb.c:406:15: error: invalid operands to binary | (have 
'struct urb *' and 'int')
 phy->out_urb |= URB_FREE_BUFFER;
  ^~

vim +163 drivers/nfc/pn533/usb.c

   147  
   148  static int pn533_usb_send_ack(struct pn533 *dev, gfp_t flags)
   149  {
   150  struct pn533_usb_phy *phy = dev->phy;
   151  static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
   152  /* spec 7.1.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
   153  char *buffer;
   154  int rc;
   155  
   156  buffer = kmalloc(sizeof(ack), GFP_KERNEL);
   157  if (!buffer)
   158  return -ENOMEM;
   159  memcpy(buffer, ack, sizeof(ack));
   160  
   161  phy->out_urb->transfer_buffer = (u8 *)ack;
   162  phy->out_urb->transfer_buffer_length = sizeof(ack);
 > 163  phy->out_urb |= URB_FREE_BUFFER;
   164  rc = usb_submit_urb(phy->out_urb, flags);
   165  
   166  return rc;
   167  }
   168  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: ath10k wake_tx_queue issues

[Niklas Cassel]

On Wed, May 16, 2018 at 07:28:21PM +0200, Erik Stromdahl wrote:
> Hello Niklas
> 
> Quick question:
> Are you using my patch: "ath10k: add htt_tx num_pending window"?

Nope, but I definitely think that your patch should be merged,
since the current code can lock/unlock/lock a lot of times for
no good reason.

(I actually tried it, but I could still reproduce the bug with it.)

> 
> I assume (from your logs below) that you are not...
> 

Thanks a lot for you suggestions Erik!

Increasing max_num_pending might be a good idea (perhaps we will
get better thoughput in the SDIO case).

However, increasing either max_num_pending or
HTC_HOST_MAX_MSG_PER_TX_BUNDLE would probably just move the problem,
since it would still be possible for us to get hit by the same problem
again in the future.

I actually took Toke's suggestion and cooked up a patch:
https://marc.info/?l=linux-kernel=152659902128543=2


Kind regards,
Niklas

Re: [PATCH] ath10k: transmit queued frames after waking queues

[Adrian Chadd]

On Thu, 17 May 2018 at 16:16, Niklas Cassel 
wrote:

> diff --git a/drivers/net/wireless/ath/ath10k/txrx.c
b/drivers/net/wireless/ath/ath10k/txrx.c
> index cda164f6e9f6..1d3b2d2c3fee 100644
> --- a/drivers/net/wireless/ath/ath10k/txrx.c
> +++ b/drivers/net/wireless/ath/ath10k/txrx.c
> @@ -95,6 +95,9 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
>  wake_up(>empty_tx_wq);
>  spin_unlock_bh(>tx_lock);

> +   if (htt->num_pending_tx <= 3 && !list_empty(>txqs))
> +   ath10k_mac_tx_push_pending(ar);
> +

Just sanity checking - what's protecting htt->num_pending_tx? or is it
serialised some other way?

>  dma_unmap_single(dev, skb_cb->paddr, msdu->len, DMA_TO_DEVICE);

>  ath10k_report_offchan_tx(htt->ar, msdu);
> --
> 2.17.0

[PATCH] ath10k: transmit queued frames after waking queues

[Niklas Cassel]

The following problem was observed when running iperf:

[  3]  0.0- 1.0 sec  2.00 MBytes  16.8 Mbits/sec
[  3]  1.0- 2.0 sec  3.12 MBytes  26.2 Mbits/sec
[  3]  2.0- 3.0 sec  3.25 MBytes  27.3 Mbits/sec
[  3]  3.0- 4.0 sec   655 KBytes  5.36 Mbits/sec
[  3]  4.0- 5.0 sec  0.00 Bytes  0.00 bits/sec
[  3]  5.0- 6.0 sec  0.00 Bytes  0.00 bits/sec
[  3]  6.0- 7.0 sec  0.00 Bytes  0.00 bits/sec
[  3]  7.0- 8.0 sec  0.00 Bytes  0.00 bits/sec
[  3]  8.0- 9.0 sec  0.00 Bytes  0.00 bits/sec
[  3]  9.0-10.0 sec  0.00 Bytes  0.00 bits/sec
[  3]  0.0-10.3 sec  9.01 MBytes  7.32 Mbits/sec

There are frames in the ieee80211_txq and there are frames that have
been removed from from this queue, but haven't yet been sent on the wire
(num_pending_tx).

When num_pending_tx reaches max_num_pending_tx, we will stop the queues
by calling ieee80211_stop_queues().

As frames that have previously been sent for transmission
(num_pending_tx) are completed, we will decrease num_pending_tx and wake
the queues by calling ieee80211_wake_queue(). ieee80211_wake_queue()
does not call wake_tx_queue, so we might still have frames in the
queue at this point.

While the queues were stopped, the socket buffer might have filled up,
and in order for user space to write more, we need to free the frames
in the queue, since they are accounted to the socket. In order to free
them, we first need to transmit them.

In order to avoid trying to flush the queue every time we free a frame,
only do this when there are 3 or less frames pending, and while we
actually have frames in the queue. This logic was copied from
mt76_txq_schedule (mt76), one of few other drivers that are actually
using wake_tx_queue.

Suggested-by: Toke Høiland-Jørgensen 
Signed-off-by: Niklas Cassel 
---
 drivers/net/wireless/ath/ath10k/txrx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/txrx.c 
b/drivers/net/wireless/ath/ath10k/txrx.c
index cda164f6e9f6..1d3b2d2c3fee 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -95,6 +95,9 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
wake_up(>empty_tx_wq);
spin_unlock_bh(>tx_lock);
 
+   if (htt->num_pending_tx <= 3 && !list_empty(>txqs))
+   ath10k_mac_tx_push_pending(ar);
+
dma_unmap_single(dev, skb_cb->paddr, msdu->len, DMA_TO_DEVICE);
 
ath10k_report_offchan_tx(htt->ar, msdu);
-- 
2.17.0

Re: pull-request: wireless-drivers-next 2018-05-17

[David Miller]

From: Kalle Valo 
Date: Thu, 17 May 2018 11:44:34 +0300

> here's a pull request to net-next for 4.18. I forgot to mention in the
> signed tag was that one id is added to include/linux/mmc/sdio_ids.h but
> that was acked by Ulf.
> 
> I suspect hat because of my merge of wireless-drivers into
> wireless-drivers-next the diffstat from request-pull was wrong again. I
> manually replaced that with the diffstat from my test pull to net-next.
> 
> Please let me know if you have any problems.

Pulled, thank you.

Re: [PATCH] nl80211: fix nlmsg allocation in cfg80211_ft_event

[Johannes Berg]

On Thu, 2018-05-17 at 11:43 -0700, Jeff Johnson wrote:
> 
> > -   msg = nlmsg_new(100 + ft_event->ric_ies_len, GFP_KERNEL);
> > +   msg = nlmsg_new(100 + ft_event->ies_len + ft_event->ric_ies_len,
> > +   GFP_KERNEL);
> > if (!msg)
> > return;
> 
> should these really be nla_total_size(ft_event->ies_len) + 
> nla_total_size(ft_event->ric_ies_len) to properly account for the NLA 
> header + padding? or do we consider that to be noise captured by the 
> "100"?

We do, technically we should have something like nla_total_size() of
various things including all those wiphy, ifindex, MAC attributes etc.
so we just get lazy...

johannes

Re: [PATCHv2 0/5] Runtime PM support for wlcore

[Tony Lindgren]

* Tony Lindgren  [180517 18:52]:
> Hi all,
> 
> Here's a series of patches to add runtime PM support for wlcore. It does not
> yet implement autosuspend support, but let's get this tested first as the
> autosuspend can mask enable/disable issues easily.

Sorry forgot to mention that you will want to have patch
"[PATCHv2] wlcore: sdio: Fix flakey SDIO runtime PM handling"
applied when testing to avoid bogus errors.

Regards,

Tony

[PATCHv2 0/5] Runtime PM support for wlcore

[Tony Lindgren]

Hi all,

Here's a series of patches to add runtime PM support for wlcore. It does not
yet implement autosuspend support, but let's get this tested first as the
autosuspend can mask enable/disable issues easily.

Regards,

Tony

Changes since v1:

- Fix issues reported by Eyal for recovery

- Add few patches for enable/disable issues found when using runtime PM

- Remove unused ps.h includes

Tony Lindgren (5):
  wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()
  wlcore: Make sure PM calls are paired
  wlcore: Add support for runtime PM
  wlcore: Fix misplaced PM call for scan_complete_work()
  wlcore: sdio: Warn about runtime PM suspend errors

 drivers/net/wireless/ti/wl18xx/debugfs.c|  26 +-
 drivers/net/wireless/ti/wlcore/acx.c|   1 -
 drivers/net/wireless/ti/wlcore/cmd.c|   9 +
 drivers/net/wireless/ti/wlcore/debugfs.c|  79 ++--
 drivers/net/wireless/ti/wlcore/main.c   | 404 ++--
 drivers/net/wireless/ti/wlcore/ps.c | 146 ---
 drivers/net/wireless/ti/wlcore/ps.h |   3 -
 drivers/net/wireless/ti/wlcore/scan.c   |  12 +-
 drivers/net/wireless/ti/wlcore/sdio.c   |   7 +
 drivers/net/wireless/ti/wlcore/sysfs.c  |  12 +-
 drivers/net/wireless/ti/wlcore/testmode.c   |  18 +-
 drivers/net/wireless/ti/wlcore/tx.c |   9 +-
 drivers/net/wireless/ti/wlcore/vendor_cmd.c |  27 +-
 drivers/net/wireless/ti/wlcore/wlcore.h |   1 -
 drivers/net/wireless/ti/wlcore/wlcore_i.h   |   1 -
 15 files changed, 421 insertions(+), 334 deletions(-)

-- 
2.17.0

[PATCH 5/5] wlcore: sdio: Warn about runtime PM suspend errors

[Tony Lindgren]

We may get -EBUSY from runtime PM and that most likely means some
earlier wlcore command did not complete yet and further calls may
fail. Let's add a warning to make it easier to track down and fix
such issues in wlcore code.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/sdio.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -188,6 +188,13 @@ static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue 
*glue)
return error;
}
 
+   if (error == -EBUSY) {
+   dev_warn(>dev,
+"%s: wlcore write did not yet complete?\n",
+   __func__);
+   dump_stack();
+   }
+
return 0;
 }
 
-- 
2.17.0

[PATCH 3/5] wlcore: Add support for runtime PM

[Tony Lindgren]

We can update wlcore to use PM runtime by adding functions for
wlcore_runtime_suspend() and wlcore_runtime_resume() and replacing
calls to wl1271_ps_elp_wakeup() and wl1271_ps_elp_sleep() with calls
to pm_runtime_get_sync() and pm_runtime_put().

Note that the new wlcore_runtime_suspend() and wlcore_runtime_resume()
functions are based on simplified versions of wl1271_ps_elp_sleep() and
wl1271_ps_elp_wakeup().

We don't want to use the old functions as we can now take advantage of
the runtime PM usage count. And we don't need the old elp_work at all.
And we can also remove WL1271_FLAG_ELP_REQUESTED that is no longer needed.

Pretty much the only place where we are not just converting the existing
functions is wl1271_op_suspend() where we add pm_runtime_put_noidle()
to keep the calls paired.

As the next step is to implement runtime PM autosuspend, let's not add
wrapper functions for the generic runtime PM calls. We would be getting
rid of any wrapper functions anyways.

After autoidle we should be able to start using Linux generic wakeirqs
for the padconf interrupt.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wl18xx/debugfs.c|  26 +-
 drivers/net/wireless/ti/wlcore/acx.c|   1 -
 drivers/net/wireless/ti/wlcore/cmd.c|  11 +-
 drivers/net/wireless/ti/wlcore/debugfs.c|  79 ++--
 drivers/net/wireless/ti/wlcore/main.c   | 400 ++--
 drivers/net/wireless/ti/wlcore/ps.c | 146 ---
 drivers/net/wireless/ti/wlcore/ps.h |   3 -
 drivers/net/wireless/ti/wlcore/scan.c   |  10 +-
 drivers/net/wireless/ti/wlcore/sysfs.c  |  12 +-
 drivers/net/wireless/ti/wlcore/testmode.c   |  18 +-
 drivers/net/wireless/ti/wlcore/tx.c |   9 +-
 drivers/net/wireless/ti/wlcore/vendor_cmd.c |  27 +-
 drivers/net/wireless/ti/wlcore/wlcore.h |   1 -
 drivers/net/wireless/ti/wlcore/wlcore_i.h   |   1 -
 14 files changed, 406 insertions(+), 338 deletions(-)

diff --git a/drivers/net/wireless/ti/wl18xx/debugfs.c 
b/drivers/net/wireless/ti/wl18xx/debugfs.c
--- a/drivers/net/wireless/ti/wl18xx/debugfs.c
+++ b/drivers/net/wireless/ti/wl18xx/debugfs.c
@@ -20,6 +20,8 @@
  *
  */
 
+#include 
+
 #include "../wlcore/debugfs.h"
 #include "../wlcore/wlcore.h"
 #include "../wlcore/debug.h"
@@ -276,15 +278,17 @@ static ssize_t radar_detection_write(struct file *file,
if (unlikely(wl->state != WLCORE_STATE_ON))
goto out;
 
-   ret = wl1271_ps_elp_wakeup(wl);
-   if (ret < 0)
+   ret = pm_runtime_get_sync(wl->dev);
+   if (ret < 0) {
+   pm_runtime_put_noidle(wl->dev);
goto out;
+   }
 
ret = wl18xx_cmd_radar_detection_debug(wl, channel);
if (ret < 0)
count = ret;
 
-   wl1271_ps_elp_sleep(wl);
+   pm_runtime_put(wl->dev);
 out:
mutex_unlock(>mutex);
return count;
@@ -315,15 +319,17 @@ static ssize_t dynamic_fw_traces_write(struct file *file,
if (unlikely(wl->state != WLCORE_STATE_ON))
goto out;
 
-   ret = wl1271_ps_elp_wakeup(wl);
-   if (ret < 0)
+   ret = pm_runtime_get_sync(wl->dev);
+   if (ret < 0) {
+   pm_runtime_put_noidle(wl->dev);
goto out;
+   }
 
ret = wl18xx_acx_dynamic_fw_traces(wl);
if (ret < 0)
count = ret;
 
-   wl1271_ps_elp_sleep(wl);
+   pm_runtime_put(wl->dev);
 out:
mutex_unlock(>mutex);
return count;
@@ -374,9 +380,11 @@ static ssize_t radar_debug_mode_write(struct file *file,
if (unlikely(wl->state != WLCORE_STATE_ON))
goto out;
 
-   ret = wl1271_ps_elp_wakeup(wl);
-   if (ret < 0)
+   ret = pm_runtime_get_sync(wl->dev);
+   if (ret < 0) {
+   pm_runtime_put_noidle(wl->dev);
goto out;
+   }
 
wl12xx_for_each_wlvif_ap(wl, wlvif) {
wlcore_cmd_generic_cfg(wl, wlvif,
@@ -384,7 +392,7 @@ static ssize_t radar_debug_mode_write(struct file *file,
   wl->radar_debug_mode, 0);
}
 
-   wl1271_ps_elp_sleep(wl);
+   pm_runtime_put(wl->dev);
 out:
mutex_unlock(>mutex);
return count;
diff --git a/drivers/net/wireless/ti/wlcore/acx.c 
b/drivers/net/wireless/ti/wlcore/acx.c
--- a/drivers/net/wireless/ti/wlcore/acx.c
+++ b/drivers/net/wireless/ti/wlcore/acx.c
@@ -31,7 +31,6 @@
 #include "wlcore.h"
 #include "debug.h"
 #include "wl12xx_80211.h"
-#include "ps.h"
 #include "hw_ops.h"
 
 int wl1271_acx_wake_up_conditions(struct wl1271 *wl, struct wl12xx_vif *wlvif,
diff --git a/drivers/net/wireless/ti/wlcore/cmd.c 
b/drivers/net/wireless/ti/wlcore/cmd.c
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -35,7 +36,6 @@
 #include "wl12xx_80211.h"
 #include "cmd.h"
 #include "event.h"
-#include "ps.h"
 

[PATCH 2/5] wlcore: Make sure PM calls are paired

[Tony Lindgren]

The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is
unpaired. Let's remove it and add paired calls to wl1271_recovery_work()
instead in preparation for changing things to use runtime PM.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/main.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -796,8 +796,6 @@ void wl12xx_queue_recovery_work(struct wl1271 *wl)
 
wl->state = WLCORE_STATE_RESTARTING;
set_bit(WL1271_FLAG_RECOVERY_IN_PROGRESS, >flags);
-   wl1271_ps_elp_wakeup(wl);
-   wlcore_disable_interrupts_nosync(wl);
ieee80211_queue_work(wl->hw, >recovery_work);
}
 }
@@ -919,12 +917,18 @@ static void wl1271_recovery_work(struct work_struct *work)
container_of(work, struct wl1271, recovery_work);
struct wl12xx_vif *wlvif;
struct ieee80211_vif *vif;
+   int error;
 
mutex_lock(>mutex);
 
if (wl->state == WLCORE_STATE_OFF || wl->plt)
goto out_unlock;
 
+   error = wl1271_ps_elp_wakeup(wl);
+   if (error < 0)
+   wl1271_warning("Enable for recovery failed");
+   wlcore_disable_interrupts_nosync(wl);
+
if (!test_bit(WL1271_FLAG_INTENDED_FW_RECOVERY, >flags)) {
if (wl->conf.fwlog.output == WL12XX_FWLOG_OUTPUT_HOST)
wl12xx_read_fwlog_panic(wl);
@@ -967,6 +971,8 @@ static void wl1271_recovery_work(struct work_struct *work)
 */
wlcore_wake_queues(wl, WLCORE_QUEUE_STOP_REASON_FW_RESTART);
 
+   wl1271_ps_elp_sleep(wl);
+
 out_unlock:
wl->watchdog_recovery = false;
clear_bit(WL1271_FLAG_RECOVERY_IN_PROGRESS, >flags);
-- 
2.17.0

[PATCH 4/5] wlcore: Fix misplaced PM call for scan_complete_work()

[Tony Lindgren]

With runtime PM enabled, we now need to have wlcore enabled longer
until after we're done calling wlcore_cmd_regdomain_config_locked():

scan_complete_work()
 wlcore_cmd_regdomain_config_locked()
   wlcore_cmd_send_failsafe()
 wl12xx_sdio_raw_read()

Note that this is not needed before runtime PM support as the
custom PM code had it's own timer. We have not yet enabled runtime
PM autosuspend for wlcore and this is why this issue now shows up.

Let's fix the issues first before we enable runtime PM autosuspend.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/scan.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/scan.c 
b/drivers/net/wireless/ti/wlcore/scan.c
--- a/drivers/net/wireless/ti/wlcore/scan.c
+++ b/drivers/net/wireless/ti/wlcore/scan.c
@@ -78,8 +78,6 @@ void wl1271_scan_complete_work(struct work_struct *work)
wl1271_cmd_build_ap_probe_req(wl, wlvif, wlvif->probereq);
}
 
-   pm_runtime_put(wl->dev);
-
if (wl->scan.failed) {
wl1271_info("Scan completed due to error.");
wl12xx_queue_recovery_work(wl);
@@ -87,6 +85,8 @@ void wl1271_scan_complete_work(struct work_struct *work)
 
wlcore_cmd_regdomain_config_locked(wl);
 
+   pm_runtime_put(wl->dev);
+
ieee80211_scan_completed(wl->hw, );
 
 out:
-- 
2.17.0

[PATCH 1/5] wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()

[Tony Lindgren]

Otherwise we can get:

WARNING: CPU: 0 PID: 55 at drivers/net/wireless/ti/wlcore/io.h:84

I've only seen this few times with the runtime PM patches enabled
so this one is probably not needed before that. This seems to
work currently based on the current PM implementation timer. Let's
apply this separately though in case others are hitting this issue.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/cmd.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/ti/wlcore/cmd.c 
b/drivers/net/wireless/ti/wlcore/cmd.c
--- a/drivers/net/wireless/ti/wlcore/cmd.c
+++ b/drivers/net/wireless/ti/wlcore/cmd.c
@@ -35,6 +35,7 @@
 #include "wl12xx_80211.h"
 #include "cmd.h"
 #include "event.h"
+#include "ps.h"
 #include "tx.h"
 #include "hw_ops.h"
 
@@ -191,6 +192,10 @@ int wlcore_cmd_wait_for_event_or_timeout(struct wl1271 *wl,
 
timeout_time = jiffies + msecs_to_jiffies(WL1271_EVENT_TIMEOUT);
 
+   ret = wl1271_ps_elp_wakeup(wl);
+   if (ret < 0)
+   return ret;
+
do {
if (time_after(jiffies, timeout_time)) {
wl1271_debug(DEBUG_CMD, "timeout waiting for event %d",
@@ -222,6 +227,7 @@ int wlcore_cmd_wait_for_event_or_timeout(struct wl1271 *wl,
} while (!event);
 
 out:
+   wl1271_ps_elp_sleep(wl);
kfree(events_vector);
return ret;
 }
-- 
2.17.0

Re: [PATCH] nl80211: fix nlmsg allocation in cfg80211_ft_event

[Jeff Johnson]

On 2018-05-17 06:25, Dedy Lansky wrote:

From: Dedy Lansky 

Allocation size of nlmsg in cfg80211_ft_event is based on ric_ies_len
and doesn't take into account ies_len. This leads to
NL80211_CMD_FT_EVENT message construction failure in case ft_event
contains large enough ies buffer.
Add ies_len to the nlmsg allocation size.

Signed-off-by: Dedy Lansky 
---
 net/wireless/nl80211.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index afbe510..64afd04 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -15755,7 +15755,8 @@ void cfg80211_ft_event(struct net_device 
*netdev,

if (!ft_event->target_ap)
return;

-   msg = nlmsg_new(100 + ft_event->ric_ies_len, GFP_KERNEL);
+   msg = nlmsg_new(100 + ft_event->ies_len + ft_event->ric_ies_len,
+   GFP_KERNEL);
if (!msg)
return;


should these really be nla_total_size(ft_event->ies_len) + 
nla_total_size(ft_event->ric_ies_len) to properly account for the NLA 
header + padding? or do we consider that to be noise captured by the 
"100"?

Re: [PATCH] wcn36xx: Add support for Factory Test Mode (FTM)

[Jeff Johnson]

On 2018-05-17 04:32, Ramon Fried wrote:

From: Eyal Ilsar 

...

+static int wcn36xx_smd_process_ptt_msg_rsp(void *buf, size_t len,
+  void **p_ptt_rsp_msg)
+{
+   struct wcn36xx_hal_process_ptt_msg_rsp_msg *rsp;
+   int ret = 0;


why initialize 'ret' when you immediately overwrite?


+   ret = wcn36xx_smd_rsp_status_check(buf, len);

...

+   if (rsp->header.len > 0) {
+   *p_ptt_rsp_msg = kmalloc(rsp->header.len, GFP_ATOMIC);


NULL check required?


+   memcpy(*p_ptt_rsp_msg, rsp->ptt_msg, rsp->header.len);
+   }
+   return ret;
+}
+
+int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
+   struct ieee80211_vif *vif, void *ptt_msg, 
size_t len,
+   void **ptt_rsp_msg)
+{
+   struct wcn36xx_hal_process_ptt_msg_req_msg *p_msg_body;
+   int ret = 0;


why initialize 'ret' when it is always overwritten before use?


+   ret = wcn36xx_smd_send_and_wait(wcn, p_msg_body->header.len);

[PATCHv2] wlcore: sdio: Fix flakey SDIO runtime PM handling

[Tony Lindgren]

We can have pm_runtime_get_sync() return 1, and we can have
pm_runtime_put_sync() return -EBUSY. See rpm_suspend() and
rpm_resume() for more information.

Fix the issue by returning 0 from wl12xx_sdio_power_on() on success.
And use pm_runtime_put() instead of pm_runtime_put_sync() for
wl12xx_sdio_power_off(), then the MMC subsystem will idle the bus
when suitable.

Otherwise wlcore can sometimes get confused and may report bogus
errors and WLAN connection can fail.

Note that while wlcore checks the return value for wl1271_power_on(),
the return value is ignored for wl1271_power_off(). Let's fix them
both though to avoid further confusion in the future.

Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Signed-off-by: Tony Lindgren 
---

Changes since v1:

- Just ignore -EBUSY error for pm_runtime_put(), we're not checking
  the return value for wl12xx_sdio_power_off() anyways currently

---
 drivers/net/wireless/ti/wlcore/sdio.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -159,28 +159,36 @@ static int wl12xx_sdio_power_on(struct wl12xx_sdio_glue 
*glue)
pm_runtime_put_noidle(>dev);
dev_err(glue->dev, "%s: failed to get_sync(%d)\n",
__func__, ret);
-   goto out;
+
+   return ret;
}
 
sdio_claim_host(func);
sdio_enable_func(func);
sdio_release_host(func);
 
-out:
-   return ret;
+   return 0;
 }
 
 static int wl12xx_sdio_power_off(struct wl12xx_sdio_glue *glue)
 {
struct sdio_func *func = dev_to_sdio_func(glue->dev);
struct mmc_card *card = func->card;
+   int error;
 
sdio_claim_host(func);
sdio_disable_func(func);
sdio_release_host(func);
 
/* Let runtime PM know the card is powered off */
-   return pm_runtime_put_sync(>dev);
+   error = pm_runtime_put(>dev);
+   if (error < 0 && error != -EBUSY) {
+   dev_err(>dev, "%s failed: %i\n", __func__, error);
+
+   return error;
+   }
+
+   return 0;
 }
 
 static int wl12xx_sdio_set_power(struct device *child, bool enable)
-- 
2.17.0

Re: ACS ACR122U not working: pn533_usb 1-1:1.0: NFC: Couldn't poweron...

[Greg KH]

On Thu, May 17, 2018 at 06:40:04PM +0200, Greg KH wrote:
> Adding the network and NFC developers as this really is a NFC driver
> bug, not a USB core issue...
> 
> On Thu, May 17, 2018 at 04:12:17PM +0200, Greg KH wrote:
> > On Thu, May 17, 2018 at 02:10:57PM +0100, Carlos Manuel Santos wrote:
> > > Hello.
> > > I'm having troubles with this NFC card reader. It seems kernel driver
> > > pn533 is not working properly.
> > > At this moment I have my work stalled. I need to add NFC support to a
> > > software product and I can't get the device to work. NFC tools won't
> > > work, the device is not detected.
> > > 
> > > This is what I get from "dmesg":
> > > 
> > > [4.182300] nfc: nfc_init: NFC Core ver 0.1
> > > [4.182318] NET: Registered protocol family 39
> > > [4.184676] hidraw: raw HID events driver (C) Jiri Kosina
> > > [4.193366] [ cut here ]
> > > [4.193366] transfer buffer not dma capable
> > > [4.193398] WARNING: CPU: 2 PID: 259 at drivers/usb/core/hcd.c:1584
> > > usb_hcd_map_urb_for_dma+0x413/0x570 [usbcore]
> > > [4.193399] Modules linked in: usbhid(+) pn533_usb(+) pn533 hid nfc
> > > snd_soc_skl(+) rtsx_usb_ms snd_soc_skl_ipc memstick snd_hda_ext_core
> > > snd_soc_sst_dsp snd_soc_sst_ipc ecdh_generic snd_soc_acpi snd_soc_core
> > > snd_hda_codec_realtek(+) snd_hda_codec_generic snd_compress ac97_bus
> > > snd_pcm_dmaengine arc4 intel_rapl x86_pkg_temp_thermal
> > > intel_powerclamp coretemp kvm_intel snd_hda_intel kvm iTCO_wdt
> > > snd_hda_codec iTCO_vendor_support iwlmvm i915 nls_iso8859_1 nls_cp437
> > > mac80211 vfat fat ppdev irqbypass crct10dif_pclmul crc32_pclmul
> > > ghash_clmulni_intel uvcvideo pcbc snd_hda_core iwlwifi
> > > videobuf2_vmalloc videobuf2_memops aesni_intel videobuf2_v4l2
> > > snd_hwdep aes_x86_64 crypto_simd glue_helper cryptd snd_pcm
> > > intel_cstate videobuf2_common e1000e intel_uncore snd_timer cfg80211
> > > intel_rapl_perf tpm_crb psmouse
> > > [4.193427]  videodev pcspkr input_leds intel_wmi_thunderbolt
> > > wmi_bmof ptp snd pps_core i2c_i801 soundcore toshiba_acpi mei_me media
> > > sparse_keymap toshiba_bluetooth mei intel_gtt industrialio
> > > intel_pch_thermal shpchp parport_pc tpm_tis tpm_tis_core battery
> > > rfkill parport evdev rtc_cmos mac_hid tpm rng_core ac sg crypto_user
> > > ip_tables x_tables rtsx_usb_sdmmc mmc_core rtsx_usb ext4
> > > crc32c_generic crc16 mbcache jbd2 fscrypto sr_mod cdrom sd_mod
> > > serio_raw atkbd libps2 ahci libahci xhci_pci xhci_hcd crc32c_intel
> > > libata usbcore scsi_mod usb_common i8042 serio nouveau led_class
> > > mxm_wmi wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect
> > > sysimgblt fb_sys_fops ttm drm agpgart
> > > [4.193458] CPU: 2 PID: 259 Comm: systemd-udevd Not tainted 
> > > 4.16.8-1-ARCH #1
> > > [4.193459] Hardware name: TOSHIBA SATELLITE PRO A50-C/SATELLITE
> > > PRO A50-C, BIOS Version 7.50   09/26/2016
> > > [4.193467] RIP: 0010:usb_hcd_map_urb_for_dma+0x413/0x570 [usbcore]
> > > [4.193468] RSP: 0018:a3b44282f9f8 EFLAGS: 00010282
> > > [4.193469] RAX:  RBX: 981fc9e320c0 RCX: 
> > > 0001
> > > [4.193470] RDX: 8001 RSI: 0002 RDI: 
> > > 
> > > [4.193471] RBP: 981fd42f R08: 000713ed01d2 R09: 
> > > 001f
> > > [4.193472] R10: 0344 R11: f300 R12: 
> > > 014000c0
> > > [4.193473] R13: fff5 R14: 981fd2592b98 R15: 
> > > c0410280
> > > [4.193475] FS:  7f4fb98d0d40() GS:981fe6d0()
> > > knlGS:
> > > [4.193476] CS:  0010 DS:  ES:  CR0: 80050033
> > > [4.193477] CR2: 562b4a68f6e8 CR3: 0004532d6004 CR4: 
> > > 003606e0
> > > [4.193478] Call Trace:
> > > [4.193488]  usb_hcd_submit_urb+0x38d/0xb20 [usbcore]
> > > [4.193492]  ? pn533_usb_probe+0x61/0x4d0 [pn533_usb]
> > > [4.193495]  ? __kmalloc+0x19e/0x220
> > > [4.193498]  pn533_usb_probe+0x397/0x4d0 [pn533_usb]
> > > [4.193507]  usb_probe_interface+0xe4/0x2f0 [usbcore]
> > > [4.193511]  driver_probe_device+0x2b9/0x460
> > > [4.193514]  ? __driver_attach+0xb6/0xe0
> > > [4.193516]  ? driver_probe_device+0x460/0x460
> > > [4.193518]  ? bus_for_each_dev+0x76/0xc0
> > > [4.193520]  ? bus_add_driver+0x152/0x230
> > > [4.193522]  ? driver_register+0x6b/0xb0
> > > [4.193530]  ? usb_register_driver+0x7a/0x130 [usbcore]
> > > [4.193531]  ? 0xc13b6000
> > > [4.193534]  ? do_one_initcall+0x48/0x13b
> > > [4.193537]  ? free_unref_page_commit+0x6a/0x100
> > > [4.193539]  ? kmem_cache_alloc_trace+0xdc/0x1c0
> > > [4.193542]  ? do_init_module+0x5a/0x210
> > > [4.193544]  ? load_module+0x247a/0x29f0
> > > [4.193549]  ? SyS_init_module+0x139/0x180
> > > [4.193550]  ? SyS_init_module+0x139/0x180
> > > [4.193554]  ? do_syscall_64+0x74/0x190
> > > [

Re: ACS ACR122U not working: pn533_usb 1-1:1.0: NFC: Couldn't poweron...

[Greg KH]

Adding the network and NFC developers as this really is a NFC driver
bug, not a USB core issue...

On Thu, May 17, 2018 at 04:12:17PM +0200, Greg KH wrote:
> On Thu, May 17, 2018 at 02:10:57PM +0100, Carlos Manuel Santos wrote:
> > Hello.
> > I'm having troubles with this NFC card reader. It seems kernel driver
> > pn533 is not working properly.
> > At this moment I have my work stalled. I need to add NFC support to a
> > software product and I can't get the device to work. NFC tools won't
> > work, the device is not detected.
> > 
> > This is what I get from "dmesg":
> > 
> > [4.182300] nfc: nfc_init: NFC Core ver 0.1
> > [4.182318] NET: Registered protocol family 39
> > [4.184676] hidraw: raw HID events driver (C) Jiri Kosina
> > [4.193366] [ cut here ]
> > [4.193366] transfer buffer not dma capable
> > [4.193398] WARNING: CPU: 2 PID: 259 at drivers/usb/core/hcd.c:1584
> > usb_hcd_map_urb_for_dma+0x413/0x570 [usbcore]
> > [4.193399] Modules linked in: usbhid(+) pn533_usb(+) pn533 hid nfc
> > snd_soc_skl(+) rtsx_usb_ms snd_soc_skl_ipc memstick snd_hda_ext_core
> > snd_soc_sst_dsp snd_soc_sst_ipc ecdh_generic snd_soc_acpi snd_soc_core
> > snd_hda_codec_realtek(+) snd_hda_codec_generic snd_compress ac97_bus
> > snd_pcm_dmaengine arc4 intel_rapl x86_pkg_temp_thermal
> > intel_powerclamp coretemp kvm_intel snd_hda_intel kvm iTCO_wdt
> > snd_hda_codec iTCO_vendor_support iwlmvm i915 nls_iso8859_1 nls_cp437
> > mac80211 vfat fat ppdev irqbypass crct10dif_pclmul crc32_pclmul
> > ghash_clmulni_intel uvcvideo pcbc snd_hda_core iwlwifi
> > videobuf2_vmalloc videobuf2_memops aesni_intel videobuf2_v4l2
> > snd_hwdep aes_x86_64 crypto_simd glue_helper cryptd snd_pcm
> > intel_cstate videobuf2_common e1000e intel_uncore snd_timer cfg80211
> > intel_rapl_perf tpm_crb psmouse
> > [4.193427]  videodev pcspkr input_leds intel_wmi_thunderbolt
> > wmi_bmof ptp snd pps_core i2c_i801 soundcore toshiba_acpi mei_me media
> > sparse_keymap toshiba_bluetooth mei intel_gtt industrialio
> > intel_pch_thermal shpchp parport_pc tpm_tis tpm_tis_core battery
> > rfkill parport evdev rtc_cmos mac_hid tpm rng_core ac sg crypto_user
> > ip_tables x_tables rtsx_usb_sdmmc mmc_core rtsx_usb ext4
> > crc32c_generic crc16 mbcache jbd2 fscrypto sr_mod cdrom sd_mod
> > serio_raw atkbd libps2 ahci libahci xhci_pci xhci_hcd crc32c_intel
> > libata usbcore scsi_mod usb_common i8042 serio nouveau led_class
> > mxm_wmi wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect
> > sysimgblt fb_sys_fops ttm drm agpgart
> > [4.193458] CPU: 2 PID: 259 Comm: systemd-udevd Not tainted 
> > 4.16.8-1-ARCH #1
> > [4.193459] Hardware name: TOSHIBA SATELLITE PRO A50-C/SATELLITE
> > PRO A50-C, BIOS Version 7.50   09/26/2016
> > [4.193467] RIP: 0010:usb_hcd_map_urb_for_dma+0x413/0x570 [usbcore]
> > [4.193468] RSP: 0018:a3b44282f9f8 EFLAGS: 00010282
> > [4.193469] RAX:  RBX: 981fc9e320c0 RCX: 
> > 0001
> > [4.193470] RDX: 8001 RSI: 0002 RDI: 
> > 
> > [4.193471] RBP: 981fd42f R08: 000713ed01d2 R09: 
> > 001f
> > [4.193472] R10: 0344 R11: f300 R12: 
> > 014000c0
> > [4.193473] R13: fff5 R14: 981fd2592b98 R15: 
> > c0410280
> > [4.193475] FS:  7f4fb98d0d40() GS:981fe6d0()
> > knlGS:
> > [4.193476] CS:  0010 DS:  ES:  CR0: 80050033
> > [4.193477] CR2: 562b4a68f6e8 CR3: 0004532d6004 CR4: 
> > 003606e0
> > [4.193478] Call Trace:
> > [4.193488]  usb_hcd_submit_urb+0x38d/0xb20 [usbcore]
> > [4.193492]  ? pn533_usb_probe+0x61/0x4d0 [pn533_usb]
> > [4.193495]  ? __kmalloc+0x19e/0x220
> > [4.193498]  pn533_usb_probe+0x397/0x4d0 [pn533_usb]
> > [4.193507]  usb_probe_interface+0xe4/0x2f0 [usbcore]
> > [4.193511]  driver_probe_device+0x2b9/0x460
> > [4.193514]  ? __driver_attach+0xb6/0xe0
> > [4.193516]  ? driver_probe_device+0x460/0x460
> > [4.193518]  ? bus_for_each_dev+0x76/0xc0
> > [4.193520]  ? bus_add_driver+0x152/0x230
> > [4.193522]  ? driver_register+0x6b/0xb0
> > [4.193530]  ? usb_register_driver+0x7a/0x130 [usbcore]
> > [4.193531]  ? 0xc13b6000
> > [4.193534]  ? do_one_initcall+0x48/0x13b
> > [4.193537]  ? free_unref_page_commit+0x6a/0x100
> > [4.193539]  ? kmem_cache_alloc_trace+0xdc/0x1c0
> > [4.193542]  ? do_init_module+0x5a/0x210
> > [4.193544]  ? load_module+0x247a/0x29f0
> > [4.193549]  ? SyS_init_module+0x139/0x180
> > [4.193550]  ? SyS_init_module+0x139/0x180
> > [4.193554]  ? do_syscall_64+0x74/0x190
> > [4.193556]  ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> > [4.193559] Code: 49 39 c9 73 30 80 3d 7d b5 02 00 00 41 bd f5 ff
> > ff ff 0f 85 57 ff ff ff 48 c7 c7 88 9d 6e c0 c6 05 63 b5 02 00 01 e8
> > 97 85 9a ec <0f> 0b 8b 53 64 e9 3a 

[PATCH] WHENCE: Fix typo Version v3

[Sedat Dilek]

I have seen that in the WHENCE file there is "Version" with and
without ":", mostly iwlwifi ucodes.

As an example:

 File: iwlwifi-8265-36.ucode
-Version 36.e91976c0.0
+Version: 36.e91976c0.0

The usual case is "Version:".

This patch is against iwlwifi.git#linux-firmware.

Signed-off-by: Sedat Dilek 
---
 WHENCE | 56 
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/WHENCE b/WHENCE
index fe63439b8cad..3678bc41a0f0 100644
--- a/WHENCE
+++ b/WHENCE
@@ -866,10 +866,10 @@ File: iwlwifi-7260-13.ucode
 Version: 25.30.13.0
 
 File: iwlwifi-7260-16.ucode
-Version 16.242414.0
+Version: 16.242414.0
 
 File: iwlwifi-7260-17.ucode
-Version 17.bfb58538.0
+Version: 17.bfb58538.0
 
 File: iwlwifi-3160-7.ucode
 Version: 22.1.7.0
@@ -890,10 +890,10 @@ File: iwlwifi-3160-13.ucode
 Version: 25.30.13.0
 
 File: iwlwifi-3160-16.ucode
-Version 16.242414.0
+Version: 16.242414.0
 
 File: iwlwifi-3160-17.ucode
-Version 17.bfb58538.0
+Version: 17.bfb58538.0
 
 File: iwlwifi-7265-8.ucode
 Version: 22.24.8.0
@@ -911,10 +911,10 @@ File: iwlwifi-7265-13.ucode
 Version: 25.30.13.0
 
 File: iwlwifi-7265-16.ucode
-Version 16.242414.0
+Version: 16.242414.0
 
 File: iwlwifi-7265-17.ucode
-Version 17.bfb58538.0
+Version: 17.bfb58538.0
 
 File: iwlwifi-7265D-10.ucode
 Version: 23.15.10.0
@@ -926,73 +926,73 @@ File: iwlwifi-7265D-13.ucode
 Version: 25.30.13.0
 
 File: iwlwifi-7265D-16.ucode
-Version 16.242414.0
+Version: 16.242414.0
 
 File: iwlwifi-7265D-17.ucode
-Version 17.352738.0
+Version: 17.352738.0
 
 File: iwlwifi-7265D-21.ucode
-Version 21.302800.0
+Version: 21.302800.0
 
 File: iwlwifi-7265D-22.ucode
-Version 22.391740.0
+Version: 22.391740.0
 
 File: iwlwifi-7265D-27.ucode
-Version 27.541033.0
+Version: 27.541033.0
 
 File: iwlwifi-7265D-29.ucode
-Version 29.3e3b4de5.0
+Version: 29.3e3b4de5.0
 
 File: iwlwifi-3168-21.ucode
-Version 21.302800.0
+Version: 21.302800.0
 
 File: iwlwifi-3168-22.ucode
-Version 22.391740.0
+Version: 22.391740.0
 
 File: iwlwifi-3168-27.ucode
-Version 27.541033.0
+Version: 27.541033.0
 
 File: iwlwifi-3168-29.ucode
-Version 29.3e3b4de5.0
+Version: 29.3e3b4de5.0
 
 File: iwlwifi-8000C-13.ucode
 Version: 25.30.13.0
 
 File: iwlwifi-8000C-16.ucode
-Version 16.242414.0
+Version: 16.242414.0
 
 File: iwlwifi-8000C-21.ucode
-Version 21.302800.0
+Version: 21.302800.0
 
 File: iwlwifi-8000C-22.ucode
-Version 22.391740.0
+Version: 22.391740.0
 
 File: iwlwifi-8000C-27.ucode
-Version 27.541033.0
+Version: 27.541033.0
 
 File: iwlwifi-8000C-31.ucode
-Version 31.560484.0
+Version: 31.560484.0
 
 File: iwlwifi-8000C-34.ucode
-Version 34.610288.0
+Version: 34.610288.0
 
 File: iwlwifi-8000C-36.ucode
-Version 36.7596afd4.0
+Version: 36.7596afd4.0
 
 File: iwlwifi-8265-21.ucode
-Version 21.302800.0
+Version: 21.302800.0
 
 File: iwlwifi-8265-22.ucode
-Version 22.391740.0
+Version: 22.391740.0
 
 File: iwlwifi-8265-27.ucode
-Version 27.541033.0
+Version: 27.541033.0
 
 File: iwlwifi-8265-31.ucode
-Version 31.560484.0
+Version: 31.560484.0
 
 File: iwlwifi-8265-34.ucode
-Version 34.610288.0
+Version: 34.610288.0
 
 File: iwlwifi-8265-36.ucode
 Version: 36.7596afd4.0
-- 
2.17.0

[bug report] ath9k: Fix issue with MCS15

[Dan Carpenter]

Hello Sujith Manoharan,

The patch 6fcbe538be43: "ath9k: Fix issue with MCS15" from Nov 14,
2013, leads to the following static checker warning:

drivers/net/wireless/ath/ath9k/ar9003_phy.c:836 ar9003_doubler_fix()
warn: 'ah->hw_version.macVersion == 448' 'false' implies 
'ah->hw_version.macVersion == 448' is 'false'

drivers/net/wireless/ath/ath9k/ar9003_phy.c
   834  static void ar9003_doubler_fix(struct ath_hw *ah)
   835  {
   836  if (AR_SREV_9300(ah) || AR_SREV_9580(ah) || AR_SREV_9550(ah)) {

The problem is that both AR_SREV_VERSION_9300 and AR_SREV_VERSION_9580
are 0x1c0 so the test for AR_SREV_9580() is duplicative.

   837  REG_RMW(ah, AR_PHY_65NM_CH0_RXTX2,
   838  1 << AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK_S |
   839  1 << AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK_S, 0);
   840  REG_RMW(ah, AR_PHY_65NM_CH1_RXTX2,
   841  1 << AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK_S |
   842  1 << AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK_S, 0);
   843  REG_RMW(ah, AR_PHY_65NM_CH2_RXTX2,
   844  1 << AR_PHY_65NM_CH0_RXTX2_SYNTHON_MASK_S |
   845  1 << AR_PHY_65NM_CH0_RXTX2_SYNTHOVR_MASK_S, 0);
   846  
   847  udelay(200);
   848  

regards,
dan carpenter

[no subject]

[George Thompson]

Dobrý den,

Stále čekám na odpověď na e-mail, obdrželi jste můj první e-mail?

S úctou,

Pan George Thompson (Esq)

[PATCH] nl80211: fix nlmsg allocation in cfg80211_ft_event

[Dedy Lansky]

From: Dedy Lansky 

Allocation size of nlmsg in cfg80211_ft_event is based on ric_ies_len
and doesn't take into account ies_len. This leads to
NL80211_CMD_FT_EVENT message construction failure in case ft_event
contains large enough ies buffer.
Add ies_len to the nlmsg allocation size.

Signed-off-by: Dedy Lansky 
---
 net/wireless/nl80211.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index afbe510..64afd04 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -15755,7 +15755,8 @@ void cfg80211_ft_event(struct net_device *netdev,
if (!ft_event->target_ap)
return;
 
-   msg = nlmsg_new(100 + ft_event->ric_ies_len, GFP_KERNEL);
+   msg = nlmsg_new(100 + ft_event->ies_len + ft_event->ric_ies_len,
+   GFP_KERNEL);
if (!msg)
return;
 
-- 
1.9.1

[PATCH] mac80211: mesh: fix premature update of rc stats

[Bob Copeland]

The mesh_neighbour_update() function, queued via beacon rx, can race with
userspace creating the same station.  If the station already exists by the
time mesh_neighbour_update() is called, the function wrongly assumes rate
control has been initialized and calls rate_control_rate_update(), which
in turn calls into the driver.

Updating the rate control before it has been initialized can cause a
crash in some drivers, for example this firmware crash in ath10k due
to sta->rx_nss being 0:

[ 3078.088247] mesh0: Inserted STA 5c:e2:8c:f1:ab:ba
[ 3078.258407] ath10k_pci :0d:00.0: firmware crashed! (uuid 
d6ed5961-93cc-4d61-803f-5eda55bb8643)
[ 3078.258421] ath10k_pci :0d:00.0: qca988x hw2.0 target 0x4100016c chip_id 
0x043202ff sub :
[ 3078.258426] ath10k_pci :0d:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 
0 testmode 0
[ 3078.258608] ath10k_pci :0d:00.0: firmware ver 10.2.4.70.59-2 api 5 
features no-p2p,raw-mode,mfp crc32 4159f498
[ 3078.258613] ath10k_pci :0d:00.0: board_file api 1 bmi_id N/A crc32 
bebc7c08
[ 3078.258617] ath10k_pci :0d:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp 
max-sta 128 raw 0 hwcrypto 1
[ 3078.260627] ath10k_pci :0d:00.0: firmware register dump:
[ 3078.260640] ath10k_pci :0d:00.0: [00]: 0x4100016C 0x15B3 0x009A31BB 
0x00955B31
[ 3078.260647] ath10k_pci :0d:00.0: [04]: 0x009A31BB 0x00060130 0x0008 
0x0007
[ 3078.260652] ath10k_pci :0d:00.0: [08]: 0x 0x00955B31 0x 
0x0040F89E
[ 3078.260656] ath10k_pci :0d:00.0: [12]: 0x0009 0x 0x009580F5 
0x00958117
[ 3078.260660] ath10k_pci :0d:00.0: [16]: 0x00958080 0x0094085D 0x 
0x
[ 3078.260664] ath10k_pci :0d:00.0: [20]: 0x409A31BB 0x0040AA84 0x0002 
0x0001
[ 3078.260669] ath10k_pci :0d:00.0: [24]: 0x809A2B8D 0x0040AAE4 0x0088 
0xC09A31BB
[ 3078.260673] ath10k_pci :0d:00.0: [28]: 0x809898C8 0x0040AB04 0x0043F91C 
0x009C6458
[ 3078.260677] ath10k_pci :0d:00.0: [32]: 0x809B66AC 0x0040AB34 0x009C6458 
0x0043F91C
[ 3078.260686] ath10k_pci :0d:00.0: [36]: 0x809B2824 0x0040ADA4 0x0040 
0x00416EB4
[ 3078.260692] ath10k_pci :0d:00.0: [40]: 0x809C07D9 0x0040ADE4 0x0040AE08 
0x00412028
[ 3078.260696] ath10k_pci :0d:00.0: [44]: 0x809486FA 0x0040AE04 0x0001 
0x
[ 3078.260700] ath10k_pci :0d:00.0: [48]: 0x80948E2C 0x0040AEA4 0x0041F4F0 
0x00412634
[ 3078.260704] ath10k_pci :0d:00.0: [52]: 0x809BFC39 0x0040AEC4 0x0041F4F0 
0x0001
[ 3078.260709] ath10k_pci :0d:00.0: [56]: 0x80940F18 0x0040AF14 0x0010 
0x00403AC0
[ 3078.284130] ath10k_pci :0d:00.0: failed to to request monitor vdev 1 
stop: -108

Fix this by checking whether the sta has already initialized rate control
using the flag for that purpose.  We can also drop the unnecessary insert
parameter here.

Signed-off-by: Bob Copeland 
---
 net/mac80211/mesh_plink.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 0f6c9ca..5b5b0f9 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -401,7 +401,7 @@ u32 mesh_plink_deactivate(struct sta_info *sta)
 
 static void mesh_sta_info_init(struct ieee80211_sub_if_data *sdata,
   struct sta_info *sta,
-  struct ieee802_11_elems *elems, bool insert)
+  struct ieee802_11_elems *elems)
 {
struct ieee80211_local *local = sdata->local;
struct ieee80211_supported_band *sband;
@@ -447,7 +447,7 @@ static void mesh_sta_info_init(struct ieee80211_sub_if_data 
*sdata,
sta->sta.bandwidth = IEEE80211_STA_RX_BW_20;
}
 
-   if (insert)
+   if (!test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
rate_control_rate_init(sta);
else
rate_control_rate_update(local, sband, sta, changed);
@@ -551,7 +551,7 @@ mesh_sta_info_get(struct ieee80211_sub_if_data *sdata,
rcu_read_lock();
sta = sta_info_get(sdata, addr);
if (sta) {
-   mesh_sta_info_init(sdata, sta, elems, false);
+   mesh_sta_info_init(sdata, sta, elems);
} else {
rcu_read_unlock();
/* can't run atomic */
@@ -561,7 +561,7 @@ mesh_sta_info_get(struct ieee80211_sub_if_data *sdata,
return NULL;
}
 
-   mesh_sta_info_init(sdata, sta, elems, true);
+   mesh_sta_info_init(sdata, sta, elems);
 
if (sta_info_insert_rcu(sta))
return NULL;
-- 
2.9.0

[PATCH] wcn36xx: Add support for Factory Test Mode (FTM)

[Ramon Fried]

From: Eyal Ilsar 

Introduce infrastructure for supporting Factory Test Mode (FTM) of the
wireless LAN subsystem. In order for the user space to access the
firmware in test mode the relevant netlink channel needs to be exposed
from the kernel driver.

The above is achieved as follows:
1) Register wcn36xx driver to testmode callback from netlink
2) Add testmode callback implementation to handle incoming FTM commands
3) Add FTM command packet structure
4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
5) Add generic handling for all PTT_MSG packets

Signed-off-by: Eyal Ilsar 
Signed-off-by: Ramon Fried 
---
 drivers/net/wireless/ath/wcn36xx/Makefile |   2 +
 drivers/net/wireless/ath/wcn36xx/hal.h|  16 ++
 drivers/net/wireless/ath/wcn36xx/main.c   |   3 +
 drivers/net/wireless/ath/wcn36xx/smd.c|  74 +
 drivers/net/wireless/ath/wcn36xx/smd.h|   4 +
 drivers/net/wireless/ath/wcn36xx/testmode.c   | 151 ++
 drivers/net/wireless/ath/wcn36xx/testmode.h   |  46 ++
 drivers/net/wireless/ath/wcn36xx/testmode_i.h |  29 
 drivers/net/wireless/ath/wcn36xx/wcn36xx.h|   2 +
 9 files changed, 327 insertions(+)
 create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.c
 create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.h
 create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode_i.h

diff --git a/drivers/net/wireless/ath/wcn36xx/Makefile 
b/drivers/net/wireless/ath/wcn36xx/Makefile
index 3b09435104eb..582049f65735 100644
--- a/drivers/net/wireless/ath/wcn36xx/Makefile
+++ b/drivers/net/wireless/ath/wcn36xx/Makefile
@@ -6,3 +6,5 @@ wcn36xx-y +=   main.o \
smd.o \
pmc.o \
debug.o
+
+wcn36xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h 
b/drivers/net/wireless/ath/wcn36xx/hal.h
index 182963522941..8491b3cb3206 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -2230,6 +2230,22 @@ struct wcn36xx_hal_switch_channel_rsp_msg {
 
 } __packed;
 
+struct wcn36xx_hal_process_ptt_msg_req_msg {
+   struct wcn36xx_hal_msg_header header;
+
+   /* Actual FTM Command body */
+   u8 ptt_msg[0];
+} __packed;
+
+struct wcn36xx_hal_process_ptt_msg_rsp_msg {
+   struct wcn36xx_hal_msg_header header;
+
+   /* FTM Command response status */
+   u32 ptt_msg_resp_status;
+   /* Actual FTM Command body */
+   u8 ptt_msg[0];
+} __packed;
+
 struct update_edca_params_req_msg {
struct wcn36xx_hal_msg_header header;
 
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..ea14f87d11ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include "wcn36xx.h"
+#include "testmode.h"
 
 unsigned int wcn36xx_dbg_mask;
 module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
@@ -1116,6 +1117,8 @@ static const struct ieee80211_ops wcn36xx_ops = {
.sta_add= wcn36xx_sta_add,
.sta_remove = wcn36xx_sta_remove,
.ampdu_action   = wcn36xx_ampdu_action,
+
+   CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
 };
 
 static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..8eaf192f8bdb 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -292,12 +292,26 @@ static void init_hal_msg(struct wcn36xx_hal_msg_header 
*hdr,
msg_body.header.len = sizeof(msg_body); \
} while (0) \
 
+#define INIT_HAL_PTT_MSG(p_msg_body, ppt_msg_len) \
+   do { \
+   memset(p_msg_body, 0, sizeof(*p_msg_body) + ppt_msg_len); \
+   p_msg_body->header.msg_type = WCN36XX_HAL_PROCESS_PTT_REQ; \
+   p_msg_body->header.msg_version = WCN36XX_HAL_MSG_VERSION0; \
+   p_msg_body->header.len = sizeof(*p_msg_body) + ppt_msg_len; \
+   } while (0)
+
 #define PREPARE_HAL_BUF(send_buf, msg_body) \
do {\
memset(send_buf, 0, msg_body.header.len);   \
memcpy(send_buf, _body, sizeof(msg_body));  \
} while (0) \
 
+#define PREPARE_HAL_PTT_MSG_BUF(send_buf, p_msg_body) \
+   do {\
+   memset(send_buf, 0, p_msg_body->header.len); \
+   memcpy(send_buf, p_msg_body, p_msg_body->header.len); \
+   } while (0)
+
 static int wcn36xx_smd_rsp_status_check(void *buf, size_t len)
 {
struct wcn36xx_fw_msg_status_rsp *rsp;
@@ -741,6 +755,64 @@ int 

[bug report] mwifiex: add rx histogram statistics support

[Dan Carpenter]

Hello Xinming Hu,

The patch cbf6e05527a7: "mwifiex: add rx histogram statistics
support" from Dec 23, 2014, leads to the following static checker
warning:

drivers/net/wireless/marvell/mwifiex/util.c:714 mwifiex_hist_data_set()
error: buffer underflow 'phist_data->snr' '(-128)-127'

drivers/net/wireless/marvell/mwifiex/util.c
   706  /* function to add histogram record */
   707  void mwifiex_hist_data_set(struct mwifiex_private *priv, u8 rx_rate, s8 
snr,
 
^^
   708 s8 nflr)
   709  {
   710  struct mwifiex_histogram_data *phist_data = priv->hist_data;
   711  
   712  atomic_inc(_data->num_samples);
   713  atomic_inc(_data->rx_rate[rx_rate]);
   714  atomic_inc(_data->snr[snr]);
   715  atomic_inc(_data->noise_flr[128 + nflr]);
   716  atomic_inc(_data->sig_str[nflr - snr]);

Smatch complains that "snr" comes from skb->data so it's untrusted and
it can be less than zero and underflow the ->snr array.

->snr, ->noise_flr and ->sig_str all have 256 elements.  Obviously it
seems like "snr" should be declared as a u8 instead of an s8.  But I'm
not totally sure what to do about the ->noise_flr and ->sig_str[]
arrays.

   717  }

regards,
dan carpenter

Re: [PATCH 02/10] wcn36xx: set DMA mask explicitly

[Ramon Fried]

On Wed, May 16, 2018 at 5:08 PM, Daniel Mack  wrote:
> The device takes 32-bit addresses only, so inform the DMA API about it.
> This is the default on msm8016, so that doesn't change anything, but
> it's best practice to be explicit.
>
> Signed-off-by: Daniel Mack 
> ---
>  drivers/net/wireless/ath/wcn36xx/main.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
> b/drivers/net/wireless/ath/wcn36xx/main.c
> index e3b91b3b38ef..e6330ad372b3 100644
> --- a/drivers/net/wireless/ath/wcn36xx/main.c
> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
> @@ -1309,6 +1309,12 @@ static int wcn36xx_probe(struct platform_device *pdev)
> mutex_init(>hal_mutex);
> mutex_init(>scan_lock);
>
> +   ret = dma_set_mask_and_coherent(wcn->dev, DMA_BIT_MASK(32));
> +   if (ret < 0) {
> +   wcn36xx_err("failed to set DMA mask: %d\n", ret);
> +   goto out_wq;
> +   }
> +
> INIT_WORK(>scan_work, wcn36xx_hw_scan_worker);
>
> wcn->smd_channel = qcom_wcnss_open_channel(wcnss, "WLAN_CTRL", 
> wcn36xx_smd_rsp_process, hw);
> --
> 2.14.3
>
>
> ___
> wcn36xx mailing list
> wcn3...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/wcn36xx
Acked-by: Ramon Fried 

Re: [PATCH 01/10] wcn36xx: fix buffer commit logic on TX path

[Ramon Fried]

On Wed, May 16, 2018 at 5:08 PM, Daniel Mack  wrote:
> When wcn36xx_dxe_tx_frame() is entered while the device is still processing
> the queue asyncronously, we are racing against the firmware code with
> updates to the buffer descriptors. Presumably, the firmware scans the ring
> buffer that holds the descriptors and scans for a valid control descriptor,
> and then assumes that the next descriptor contains the payload. If, however,
> the control descriptor is marked valid, but the payload descriptor isn't,
> the packet is not sent out.
>
> Another issue with the current code is that is lacks memory barriers before
> descriptors are marked valid. This is important because the CPU may reorder
> writes to memory, even if it is allocated as coherent DMA area, and hence
> the device may see incompletely written data.
>
> To fix this, the code in wcn36xx_dxe_tx_frame() was restructured a bit so
> that the payload descriptor is made valid before the control descriptor.
> Memory barriers are added to ensure coherency of shared memory areas.
>
> Signed-off-by: Daniel Mack 
> ---
>  drivers/net/wireless/ath/wcn36xx/dxe.c | 75 
> +-
>  1 file changed, 38 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
> b/drivers/net/wireless/ath/wcn36xx/dxe.c
> index bd2b946a65c9..3d1cf7dd1f8e 100644
> --- a/drivers/net/wireless/ath/wcn36xx/dxe.c
> +++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
> @@ -642,8 +642,8 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
>  struct sk_buff *skb,
>  bool is_low)
>  {
> -   struct wcn36xx_dxe_ctl *ctl = NULL;
> -   struct wcn36xx_dxe_desc *desc = NULL;
> +   struct wcn36xx_dxe_desc *desc_bd, *desc_skb;
> +   struct wcn36xx_dxe_ctl *ctl_bd, *ctl_skb;
> struct wcn36xx_dxe_ch *ch = NULL;
> unsigned long flags;
> int ret;
> @@ -651,74 +651,75 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
> ch = is_low ? >dxe_tx_l_ch : >dxe_tx_h_ch;
>
> spin_lock_irqsave(>lock, flags);
> -   ctl = ch->head_blk_ctl;
> +   ctl_bd = ch->head_blk_ctl;
> +   ctl_skb = ctl_bd->next;
>
> /*
>  * If skb is not null that means that we reached the tail of the ring
>  * hence ring is full. Stop queues to let mac80211 back off until ring
>  * has an empty slot again.
>  */
> -   if (NULL != ctl->next->skb) {
> +   if (NULL != ctl_skb->skb) {
> ieee80211_stop_queues(wcn->hw);
> wcn->queues_stopped = true;
> spin_unlock_irqrestore(>lock, flags);
> return -EBUSY;
> }
>
> -   ctl->skb = NULL;
> -   desc = ctl->desc;
> +   if (unlikely(ctl_skb->bd_cpu_addr)) {
> +   wcn36xx_err("bd_cpu_addr cannot be NULL for skb DXE\n");
> +   ret = -EINVAL;
> +   goto unlock;
> +   }
> +
> +   desc_bd = ctl_bd->desc;
> +   desc_skb = ctl_skb->desc;
> +
> +   ctl_bd->skb = NULL;
>
> /* write buffer descriptor */
> -   memcpy(ctl->bd_cpu_addr, bd, sizeof(*bd));
> +   memcpy(ctl_bd->bd_cpu_addr, bd, sizeof(*bd));
>
> /* Set source address of the BD we send */
> -   desc->src_addr_l = ctl->bd_phy_addr;
> -
> -   desc->dst_addr_l = ch->dxe_wq;
> -   desc->fr_len = sizeof(struct wcn36xx_tx_bd);
> -   desc->ctrl = ch->ctrl_bd;
> +   desc_bd->src_addr_l = ctl_bd->bd_phy_addr;
> +   desc_bd->dst_addr_l = ch->dxe_wq;
> +   desc_bd->fr_len = sizeof(struct wcn36xx_tx_bd);
>
> wcn36xx_dbg(WCN36XX_DBG_DXE, "DXE TX\n");
>
> wcn36xx_dbg_dump(WCN36XX_DBG_DXE_DUMP, "DESC1 >>> ",
> -(char *)desc, sizeof(*desc));
> +(char *)desc_bd, sizeof(*desc_bd));
> wcn36xx_dbg_dump(WCN36XX_DBG_DXE_DUMP,
> -"BD   >>> ", (char *)ctl->bd_cpu_addr,
> +"BD   >>> ", (char *)ctl_bd->bd_cpu_addr,
>  sizeof(struct wcn36xx_tx_bd));
>
> -   /* Set source address of the SKB we send */
> -   ctl = ctl->next;
> -   desc = ctl->desc;
> -   if (ctl->bd_cpu_addr) {
> -   wcn36xx_err("bd_cpu_addr cannot be NULL for skb DXE\n");
> -   ret = -EINVAL;
> -   goto unlock;
> -   }
> -
> -   desc->src_addr_l = dma_map_single(wcn->dev,
> - skb->data,
> - skb->len,
> - DMA_TO_DEVICE);
> -   if (dma_mapping_error(wcn->dev, desc->src_addr_l)) {
> +   desc_skb->src_addr_l = dma_map_single(wcn->dev,
> + skb->data,
> + skb->len,
> + DMA_TO_DEVICE);
> +   if (dma_mapping_error(wcn->dev, 

pull-request: wireless-drivers-next 2018-05-17

[Kalle Valo]

Hi Dave,

here's a pull request to net-next for 4.18. I forgot to mention in the
signed tag was that one id is added to include/linux/mmc/sdio_ids.h but
that was acked by Ulf.

I suspect hat because of my merge of wireless-drivers into
wireless-drivers-next the diffstat from request-pull was wrong again. I
manually replaced that with the diffstat from my test pull to net-next.

Please let me know if you have any problems.

Kalle

The following changes since commit af8a41cccf8f469165c6debc8fe07c5fd2ca501a:

  rtlwifi: cleanup 8723be ant_sel definition (2018-04-24 13:15:08 +0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
tags/wireless-drivers-next-for-davem-2018-05-17

for you to fetch changes up to 763ece85f45a6b93268e25a0abf02922f911dab4:

  brcmfmac: fix initialization of struct cfg80211_inform_bss variable 
(2018-05-15 18:03:35 +0300)


wireless-drivers-next patches for 4.18

The first pull request for 4.18. As usual new features and bug fixes
but nothing really special.

I also merged wireless-drivers due to an iwlwifi patch dependency.

Major changes:

iwlwifi

* implement Traffic Condition Monitor and use it for scan, BT coex and
  to detect when the AP doesn't support UAPSD properly

* some more work for the 22000 family of devices;

* introduce AMSDU rate control offload

qtnfmac

* DFS offload support

rsi

* roaming enhancements

* increase max supported aggregation subframes

* don't advertise 5 GHz support if the device doesn't support it

brcmfmac

* add support for BCM4366E chipset

* add support for bcm43364 wireless chipset

ath10k

* enable temperature reads for QCA6174 and QCA9377

* add firmware memory dump support for QCA9984

* continue adding WCN3990 support via SNOC bus


Amitkumar Karwar (7):
  rsi: disable fw watchdog timer during reset
  rsi: device bootup parameter configuration
  rsi: use appropriate interface for power save configuration
  rsi: increase max supported aggregation subframes
  rsi: parse TID from data frame correctly
  rsi: enable power save by default for coex
  rsi: advertise 5GHz support based on device capability

Arend Van Spriel (2):
  brcmfmac: check p2pdev mac address uniqueness
  brcmfmac: constify firmware mapping tables

Arnd Bergmann (1):
  ath10k: avoid possible string overflow

Carl Huang (2):
  ath10k: add WMI_SERVICE_AVAILABLE_EVENT support
  ath10k: support MAC address randomization in scan

Colin Ian King (9):
  wil6210: fix potential null dereference of ndev before null check
  ath10k: fix spelling mistake: "tiggers" -> "triggers"
  ath6kl: fix spelling mistake: "chache" -> "cache"
  cw1200: fix spelling mistake: "Mailformed" -> "Malformed"
  rt2x00: fix spelling mistake in various macros, UKNOWN -> UNKNOWN
  ipw2100: fix spelling mistake: "decsribed" -> "described"
  rtlwifi: fix spelling mistake: "dismatch" -> "mismatch"
  ipw2200: fix spelling mistake: "functionalitis" -> "functionalities"
  rsi: fix spelling mistake: "thead" -> "thread"

Dan Carpenter (2):
  rsi: remove unecessary PTR_ALIGN()s
  mwifiex: pcie: tighten a check in mwifiex_pcie_process_event_ready()

Dan Haab (1):
  brcmfmac: add support for BCM4366E chipset

Daniel Mack (11):
  wcn36xx: check for DMA mapping errors in wcn36xx_dxe_tx_frame()
  wcn36xx: don't keep reference to skb if transmission failed
  wcn36xx: don't delete invalid bss indices
  wcn36xx: allocate skbs with GFP_KERNEL during init
  wcn36xx: use READ_ONCE() to access desc->ctrl
  wcn36xx: pass correct BSS index when deleting BSS keys
  wcn36xx: abort scan request when 'dequeued' indicator is sent
  wcn36xx: cancel pending scan request when interface goes down
  wcn36xx: handle scan cancellation when firmware support is missing
  wcn36xx: send bss_type in scan requests
  wcn36xx: pass information elements in scan requests

Dmitry Lebed (1):
  qtnfmac: add DFS offload support

Eliad Peller (2):
  iwlwifi: pcie: allow sending pre-built A-MSDUs
  iwlwifi: mvm: set wakeup filters for wowlan "any" configuration

Emmanuel Grumbach (3):
  iwlwifi: mvm: BT Coex - make the primary / secondary pick traffic aware
  iwlwifi: pcie: implement the overlow queue for Gen2 devices
  iwlwifi: mvm: set the MFP flag for keys that are used by MFP stations

Erik Stromdahl (2):
  ath10k: add inlined wrappers for htt tx ops
  ath10k: add inlined wrappers for htt rx ops

Eyal Reizer (1):
  wlcore: sdio: allow pm to handle sdio power

Felix Fietkau (11):
  mt76: stop tx queues from the driver callback instead of common code
  mt76: add missing VHT maximum A-MPDU length capability
  mt76: toggle driver station powersave bit before notifying mac80211