Re: Intel Wireless 7260 Microcode SW error detected

2016-10-19 Thread Luca Coelho 
Hi Tibor,

On Sun, 2016-10-16 at 20:08 +0200, Billes Tibor wrote:
> I have Lenovo laptop with an Intel Wireless 7260 wifi module and the 
> latest stable kernel 4.8.1. I was playing a movie from an sshfs mounted 
> file system, when the movie just froze and my network stopped working. 
> Dmesg said 'Microcode SW error detected'. Below is my full `dmesg -r` 
> output. I probably will not be able to reproduce this behaviour, because 
> it did not happen in the past, and it seems to work fine after reboot.

Can you file a bug in bugzilla so we can track this? It seems to be a
firmware problem that we'll have to investigate.  We have instructions
on how to report here:

https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging


> Is there anything more that I can do to help you debug this?

It would be nice if you could enable firmware debugging so that, if
this happens again, we'll have the appropriate FW logs to investigate
it further.  There are instructions on how to enable it in the
"Firmware Debugging" section of that wiki page.

Please make sure you read and understand the privacy aspects of
submitting firmware debugging data, as explained here:

https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging#privacy_aspects


> <3>[37750.190201] iwlwifi :08:00.0: Microcode SW error detected.  
> Restarting 0x200.
> <3>[37750.190206] iwlwifi :08:00.0: CSR values:
> <3>[37750.190207] iwlwifi :08:00.0: (2nd byte of CSR_INT_COALESCING 
> is CSR_INT_PERIODIC_REG)
> <3>[37750.190212] iwlwifi :08:00.0: CSR_HW_IF_CONFIG_REG: 0X40489204
> <3>[37750.190226] iwlwifi :08:00.0: CSR_INT_COALESCING: 0X8040
> <3>[37750.190239] iwlwifi :08:00.0: CSR_INT: 0X
> <3>[37750.190253] iwlwifi :08:00.0: CSR_INT_MASK: 0X
> <3>[37750.190267] iwlwifi :08:00.0: CSR_FH_INT_STATUS: 0X
> <3>[37750.190281] iwlwifi :08:00.0: CSR_GPIO_IN: 0X
> <3>[37750.190294] iwlwifi :08:00.0: CSR_RESET: 0X
> <3>[37750.190308] iwlwifi :08:00.0: CSR_GP_CNTRL: 0X080403c5
> <3>[37750.190322] iwlwifi :08:00.0: CSR_HW_REV: 0X0144
> <3>[37750.190336] iwlwifi :08:00.0: CSR_EEPROM_REG: 0X
> <3>[37750.190350] iwlwifi :08:00.0: CSR_EEPROM_GP: 0X8000
> <3>[37750.190363] iwlwifi :08:00.0: CSR_OTP_GP_REG: 0X803a
> <3>[37750.190377] iwlwifi :08:00.0: CSR_GIO_REG: 0X001f0042
> <3>[37750.190391] iwlwifi :08:00.0: CSR_GP_UCODE_REG: 0X
> <3>[37750.190405] iwlwifi :08:00.0: CSR_GP_DRIVER_REG: 0X
> <3>[37750.190419] iwlwifi :08:00.0: CSR_UCODE_DRV_GP1: 0X
> <3>[37750.190432] iwlwifi :08:00.0: CSR_UCODE_DRV_GP2: 0X
> <3>[37750.190446] iwlwifi :08:00.0: CSR_LED_REG: 0X0060
> <3>[37750.190460] iwlwifi :08:00.0: CSR_DRAM_INT_TBL_REG: 0X881530a3
> <3>[37750.190474] iwlwifi :08:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
> <3>[37750.190488] iwlwifi :08:00.0: CSR_ANA_PLL_CFG: 0Xd5d5
> <3>[37750.190501] iwlwifi :08:00.0: CSR_MONITOR_STATUS_REG: 0X3d0801bd
> <3>[37750.190515] iwlwifi :08:00.0: CSR_HW_REV_WA_REG: 0X0001001a
> <3>[37750.190529] iwlwifi :08:00.0: CSR_DBG_HPET_MEM_REG: 0X0010
> <3>[37750.190530] iwlwifi :08:00.0: FH register values:
> <3>[37750.190552] iwlwifi :08:00.0: FH_RSCSR_CHNL0_STTS_WPTR_REG: 
> 0X15005f00
> <3>[37750.190566] iwlwifi :08:00.0: FH_RSCSR_CHNL0_RBDCB_BASE_REG: 
> 0X015005e0
> <3>[37750.190580] iwlwifi :08:00.0: FH_RSCSR_CHNL0_WPTR: 0X00e8
> <3>[37750.190593] iwlwifi :08:00.0: FH_MEM_RCSR_CHNL0_CONFIG_REG: 
> 0X80801114
> <3>[37750.190607] iwlwifi :08:00.0: FH_MEM_RSSR_SHARED_CTRL_REG: 
> 0X00fc
> <3>[37750.190621] iwlwifi :08:00.0: FH_MEM_RSSR_RX_STATUS_REG: 
> 0X0703
> <3>[37750.190635] iwlwifi :08:00.0: 
> FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X
> <3>[37750.190648] iwlwifi :08:00.0: FH_TSSR_TX_STATUS_REG: 0X07ff0001
> <3>[37750.190662] iwlwifi :08:00.0: FH_TSSR_TX_ERROR_REG: 0X
> <3>[37750.190790] iwlwifi :08:00.0: Start IWL Error Log Dump:
> <3>[37750.190791] iwlwifi :08:00.0: Status: 0x, count: 6
> <3>[37750.190793] iwlwifi :08:00.0: Loaded firmware version: 16.242414.0

I recommend that you update your firmware to the latest version
(iwlwifi-7260-17.ucode) published in linux-firmware.git:

http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git

While I'm not sure the issue you saw is solved by that, we do have lots
of other fixes in it that are worth the effort.


<3>[37750.190794] iwlwifi :08:00.0: 0x307C | ADVANCED_SYSASSERT

I hadn't seen this for a while.  This is something related to the TX
queues and could have many different causes...

Thanks for reporting!

--
Cheers,
Luca.

Re: crypto: aesni - add ccm(aes) algorithm implementation

2016-10-19 Thread Ben Greear 

On 10/19/2016 09:37 AM, gree...@candelatech.com wrote:

From: Yauhen Kharuzhy 

Add ccm(aes) implementation from linux-wireless mailing list (see
http://permalink.gmane.org/gmane.linux.kernel.wireless.general/126679).

This eliminates FPU context store/restore overhead existing in more
general ccm_base(ctr(aes-aesni),aes-aesni) case in MAC calculation.

Convert this patch to new AEAD API.

Signed-off-by: Yauhen Kharuzhy 
Signed-off-by: Ben Greear 


I've been using this patch or something similar for a while and it
significantly helps me with sw-crypt performance.  One version or another
has been around the internet for some time, and I am not the originator
of this code, but would still be happy to see it upstream if someone
can review and bless it.

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

2016-10-19 Thread Johannes Berg 
On Wed, 2016-10-19 at 08:59 -0700, Ben Greear wrote:
> 
> Do you actually expect performance regressions?  I'll be complaining
> if so, but will test first :)

I think we can expect this to use a bit more CPU time, but unless
you're very tight on that you probably shouldn't expect any throughput
difference.

johannes

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

2016-10-19 Thread Ben Greear 



On 10/19/2016 08:08 AM, Ard Biesheuvel wrote:

On 19 October 2016 at 08:43, Johannes Berg  wrote:

On Wed, 2016-10-19 at 11:31 +0800, Herbert Xu wrote:



We could probably make mac80211 do that too, but can we guarantee in-
order processing? Anyway, it's pretty low priority, maybe never
happening, since hardly anyone really uses "software" crypto, the wifi
devices mostly have it built in anyway.



Indeed. The code is now correct in terms of API requirements, so let's
just wait for someone to complain about any performance regressions.


Do you actually expect performance regressions?  I'll be complaining if
so, but will test first :)

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH net-next 2/6] net: use core MTU range checking in wireless drivers

2016-10-19 Thread Johannes Berg 
On Tue, 2016-10-18 at 22:33 -0400, Jarod Wilson wrote:
> - set max_mtu in wil6210 driver
> - set max_mtu in atmel driver
> - set min/max_mtu in cisco airo driver, remove airo_change_mtu
> - set min/max_mtu in ipw2100/ipw2200 drivers, remove
> libipw_change_mtu
> - set min/max_mtu in p80211netdev, remove wlan_change_mtu

I guess we should do the same in net/mac80211/iface.c?

johannes

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

2016-10-19 Thread Johannes Berg 
On Wed, 2016-10-19 at 11:31 +0800, Herbert Xu wrote:
> On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote:
> > 
> > 
> > Annoyingly, all this complication with scatterlists etc is for
> > doing
> > asynchronous crypto via DMA capable crypto accelerators, and the
> > networking code (ipsec as well as mac80211, afaik) only allow
> > synchronous in the first place, given that they execute in softirq
> > context.
> 
> I'm still thinking about the issue (in particular, whether we
> should continue to rely on the request context being SG-capable
> or allow it to be on the stack for AEAD).

:)

> But IPsec definitely supports async crypto.  In fact it was the
> very first user of async crypto.

Yeah.

> mac80211 on the other hand is currently sync-only.

We could probably make mac80211 do that too, but can we guarantee in-
order processing? Anyway, it's pretty low priority, maybe never
happening, since hardly anyone really uses "software" crypto, the wifi
devices mostly have it built in anyway.

(One problem is that the skb->cb is already completely full, so we
can't stash away the AAD there)

johannes

Re: sequence diagrams in rst documentation

2016-10-19 Thread Johannes Berg 
On Tue, 2016-10-18 at 17:52 -0600, Jonathan Corbet wrote:

> In summary, I think we can consider taking on a module if it's what
> we need to do the docs right.  And if somebody agrees to maintain it!
> :)

:)

I think for the ones that we carry, they're probably specific?

> I've heard others say they would like better diagramming support.  Do
> you think that, maybe, something like aafigure would do the trick?
> 
>   https://pythonhosted.org/sphinxcontrib-aafig/
> 
> I've not actually played with it at all, but I like the idea that
> we'd have readable diagrams in the source docs as well...

Well, maybe. I agree having it readable in the source docs as well is
nice, but for sequence diagrams in particular, I don't think

    +---+ +---+
| Hello +>+ aafigure! |
+---+ +---+

really beats

   Hello -> aafigure!

by much. You could do some alignment even with the latter version, and
the above isn't even really a sequence diagram anyway :)

Some of the sequence diagrams may also be automatically generated from
runtime behaviour observation (e.g. tracing, we've actually done that),
and outputting the types of ascii boxes is much more difficult there.

For other types of diagrams this may be nice though.

Anyway, I guess we'll cross that bridge when we get to it. I'd like to
have these types of documentation, perhaps with a script to auto-
generate from tracing - such as script and visual display can even
serve as a debugging aid :)

johannes

[char-misc-next 4/5] nfc: mei_phy: get phy from the driver data

2016-10-19 Thread Tomas Winkler 
In order to remove rather redundant context from the callback
signature we the get nfc mei_phy from the driver's data.

Signed-off-by: Tomas Winkler 
---
 drivers/nfc/mei_phy.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c
index 83deda4bb4d6..66dfd81ffb18 100644
--- a/drivers/nfc/mei_phy.c
+++ b/drivers/nfc/mei_phy.c
@@ -300,7 +300,10 @@ static int mei_nfc_recv(struct nfc_mei_phy *phy, u8 *buf, 
size_t length)
 static void nfc_mei_event_cb(struct mei_cl_device *cldev, u32 events,
 void *context)
 {
-   struct nfc_mei_phy *phy = context;
+   struct nfc_mei_phy *phy = mei_cldev_get_drvdata(cldev);
+
+   if (!phy)
+   return;
 
if (phy->hard_fault != 0)
return;
-- 
2.7.4

[PATCH 00/10] iwlwifi: updates intended for v4.10 2016-10-19

2016-10-19 Thread Luca Coelho 
From: Luca Coelho 

Hi,

Here's my first series for v4.10.  These are the changes:

* Finalize and enable dynamic queue allocation;
* Use dev_coredumpmsg() to prevent locking the driver;
* Small fix to pass the AID to the FW;
* Use FW PS decisions with multi-queue;

As usual, I'm pushing this to a pending branch, for kbuild bot, and
will send a pull-request later.

Please review.

Cheers,
Luca.


Aviya Erenfeld (1):
  iwlwifi: mvm: use dev_coredumpsg()

Emmanuel Grumbach (1):
  iwlwifi: mvm: tell the firmware about the AID of the peer

Johannes Berg (1):
  iwlwifi: mvm: use firmware station PM notification for AP_LINK_PS

Liad Kaufman (5):
  iwlwifi: mvm: update txq metadata to current owner
  iwlwifi: mvm: fix reserved txq freeing
  iwlwifi: mvm: support MONITOR vif in DQA mode
  iwlwifi: mvm: fix dqa deferred frames marking
  iwlwifi: mvm: operate in dqa mode

Sara Sharon (1):
  iwlwifi: mvm: assign cab queue to the correct station

Sharon Dvir (1):
  iwlwifi: pcie: give a meaningful name to interrupt request

 drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h   |   2 +
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api-rx.h |  26 ++
 .../net/wireless/intel/iwlwifi/mvm/fw-api-sta.h|   9 +-
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h|   1 +
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c| 100 +++--
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c  |  24 ++---
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |  86 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   |   6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c   |   3 +
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   |  37 ++--
 drivers/net/wireless/intel/iwlwifi/mvm/sta.h   |   1 +
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c|  29 +-
 12 files changed, 249 insertions(+), 75 deletions(-)

-- 
2.9.3

[PATCH 08/10] iwlwifi: mvm: assign cab queue to the correct station

2016-10-19 Thread Luca Coelho 
From: Sara Sharon 

Currently when configuring the cab queue the scheduler is configured
without station id - which results in station id 0.
In DQA mode this causes firmware to assert later on when the actual
station 0 is added with an empty tfd_queue_mask.
Fix that by configuring the queue to the broadcast station.
This is a bit trickier since the queue should not be included in the
tfd_queue_mask of the ADD_STA since it is a multicast queue, and the
tfd_queue_mask is only unicast queue. As a result the queue should be
enabled only after the broadcast station is added.

Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 16 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 16 
 2 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index 9a91203..4a0874e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -499,23 +499,21 @@ int iwl_mvm_mac_ctxt_init(struct iwl_mvm *mvm, struct 
ieee80211_vif *vif)
if (ret)
return ret;
 
+   /* If DQA is supported - queues will be enabled when needed */
+   if (iwl_mvm_is_dqa_supported(mvm))
+   return 0;
+
switch (vif->type) {
case NL80211_IFTYPE_P2P_DEVICE:
-   if (!iwl_mvm_is_dqa_supported(mvm))
-   iwl_mvm_enable_ac_txq(mvm, IWL_MVM_OFFCHANNEL_QUEUE,
- IWL_MVM_OFFCHANNEL_QUEUE,
- IWL_MVM_TX_FIFO_VO, 0,
- wdg_timeout);
+   iwl_mvm_enable_ac_txq(mvm, IWL_MVM_OFFCHANNEL_QUEUE,
+ IWL_MVM_OFFCHANNEL_QUEUE,
+ IWL_MVM_TX_FIFO_VO, 0, wdg_timeout);
break;
case NL80211_IFTYPE_AP:
iwl_mvm_enable_ac_txq(mvm, vif->cab_queue, vif->cab_queue,
  IWL_MVM_TX_FIFO_MCAST, 0, wdg_timeout);
/* fall through */
default:
-   /* If DQA is supported - queues will be enabled when needed */
-   if (iwl_mvm_is_dqa_supported(mvm))
-   break;
-
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
iwl_mvm_enable_ac_txq(mvm, vif->hw_queue[ac],
  vif->hw_queue[ac],
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 9eeb2c3..4f8c134 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -2099,6 +2099,22 @@ static int iwl_mvm_start_ap_ibss(struct ieee80211_hw *hw,
if (ret)
goto out_unbind;
 
+   /* enable the multicast queue, now that we have a station for it */
+   if (iwl_mvm_is_dqa_supported(mvm)) {
+   unsigned int wdg_timeout =
+   iwl_mvm_get_wd_timeout(mvm, vif, false, false);
+   struct iwl_trans_txq_scd_cfg cfg = {
+   .fifo = IWL_MVM_TX_FIFO_MCAST,
+   .sta_id = mvmvif->bcast_sta.sta_id,
+   .tid = IWL_MAX_TID_COUNT,
+   .aggregate = false,
+   .frame_limit = IWL_FRAME_LIMIT,
+   };
+
+   iwl_mvm_enable_txq(mvm, vif->cab_queue, vif->cab_queue, 0,
+  , wdg_timeout);
+   }
+
/* must be set before quota calculations */
mvmvif->ap_ibss_active = true;
 
-- 
2.9.3

[PATCH 01/10] iwlwifi: mvm: update txq metadata to current owner

2016-10-19 Thread Luca Coelho 
From: Liad Kaufman 

When a TXQ's owner is changed, the FW is indeed notified, but
the driver doesn't update the current metadata to reflect the
owner change. Fix that.

Signed-off-by: Liad Kaufman 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index fc77188..a65030f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -875,12 +875,17 @@ static void iwl_mvm_change_queue_owner(struct iwl_mvm 
*mvm, int queue)
cmd.tx_fifo = iwl_mvm_ac_to_tx_fifo[tid_to_mac80211_ac[tid]];
 
ret = iwl_mvm_send_cmd_pdu(mvm, SCD_QUEUE_CFG, 0, sizeof(cmd), );
-   if (ret)
+   if (ret) {
IWL_ERR(mvm, "Failed to update owner of TXQ %d (ret=%d)\n",
queue, ret);
-   else
-   IWL_DEBUG_TX_QUEUES(mvm, "Changed TXQ %d ownership to tid %d\n",
-   queue, tid);
+   return;
+   }
+
+   spin_lock_bh(>queue_info_lock);
+   mvm->queue_info[queue].txq_tid = tid;
+   spin_unlock_bh(>queue_info_lock);
+   IWL_DEBUG_TX_QUEUES(mvm, "Changed TXQ %d ownership to tid %d\n",
+   queue, tid);
 }
 
 static void iwl_mvm_unshare_queue(struct iwl_mvm *mvm, int queue)
-- 
2.9.3

[PATCH 06/10] iwlwifi: pcie: give a meaningful name to interrupt request

2016-10-19 Thread Luca Coelho 
From: Sharon Dvir 

Instead of passing DRV_NAME pass a string that
represents the reason for the interrupt.

Signed-off-by: Sharon Dvir 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index ae95533..b10e363 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -1598,6 +1598,29 @@ static void iwl_pcie_irq_set_affinity(struct iwl_trans 
*trans)
}
 }
 
+static const char *queue_name(struct device *dev,
+ struct iwl_trans_pcie *trans_p, int i)
+{
+   if (trans_p->shared_vec_mask) {
+   int vec = trans_p->shared_vec_mask &
+ IWL_SHARED_IRQ_FIRST_RSS ? 1 : 0;
+
+   if (i == 0)
+   return DRV_NAME ": shared IRQ";
+
+   return devm_kasprintf(dev, GFP_KERNEL,
+ DRV_NAME ": queue %d", i + vec);
+   }
+   if (i == 0)
+   return DRV_NAME ": default queue";
+
+   if (i == trans_p->alloc_vecs - 1)
+   return DRV_NAME ": exception";
+
+   return devm_kasprintf(dev, GFP_KERNEL,
+ DRV_NAME  ": queue %d", i);
+}
+
 static int iwl_pcie_init_msix_handler(struct pci_dev *pdev,
  struct iwl_trans_pcie *trans_pcie)
 {
@@ -1606,6 +1629,10 @@ static int iwl_pcie_init_msix_handler(struct pci_dev 
*pdev,
for (i = 0; i < trans_pcie->alloc_vecs; i++) {
int ret;
struct msix_entry *msix_entry;
+   const char *qname = queue_name(>dev, trans_pcie, i);
+
+   if (!qname)
+   return -ENOMEM;
 
msix_entry = _pcie->msix_entries[i];
ret = devm_request_threaded_irq(>dev,
@@ -1615,7 +1642,7 @@ static int iwl_pcie_init_msix_handler(struct pci_dev 
*pdev,
iwl_pcie_irq_msix_handler :
iwl_pcie_irq_rx_msix_handler,
IRQF_SHARED,
-   DRV_NAME,
+   qname,
msix_entry);
if (ret) {
IWL_ERR(trans_pcie->trans,
-- 
2.9.3

[PATCH 02/10] iwlwifi: mvm: fix reserved txq freeing

2016-10-19 Thread Luca Coelho 
From: Liad Kaufman 

If a TXQ's marking as a reserved queue is removed,
when removing the STA the driver might try to access
out of bounds memory. Make sure the reserved queue
is freed only if it is still reserved.

Signed-off-by: Liad Kaufman 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index a65030f..c9dcb70 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -1494,12 +1494,15 @@ int iwl_mvm_rm_sta(struct iwl_mvm *mvm,
ret = iwl_mvm_drain_sta(mvm, mvm_sta, false);
 
/* If DQA is supported - the queues can be disabled now */
-   if (iwl_mvm_is_dqa_supported(mvm)) {
+   if (iwl_mvm_is_dqa_supported(mvm))
+   iwl_mvm_disable_sta_queues(mvm, vif, mvm_sta);
+
+   /* If there is a TXQ still marked as reserved - free it */
+   if (iwl_mvm_is_dqa_supported(mvm) &&
+   mvm_sta->reserved_queue != IEEE80211_INVAL_HW_QUEUE) {
u8 reserved_txq = mvm_sta->reserved_queue;
enum iwl_mvm_queue_status *status;
 
-   iwl_mvm_disable_sta_queues(mvm, vif, mvm_sta);
-
/*
 * If no traffic has gone through the reserved TXQ - it
 * is still marked as IWL_MVM_QUEUE_RESERVED, and
-- 
2.9.3

[PATCH 09/10] iwlwifi: mvm: operate in dqa mode

2016-10-19 Thread Luca Coelho 
From: Liad Kaufman 

Run DQA flows by default, as long as the FW supports it.

Signed-off-by: Liad Kaufman 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h 
b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index 726ba48..cde8c6c 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -,9 +,8 @@ static inline bool iwl_mvm_is_d0i3_supported(struct 
iwl_mvm *mvm)
 
 static inline bool iwl_mvm_is_dqa_supported(struct iwl_mvm *mvm)
 {
-   /* Make sure DQA isn't allowed in driver until feature is complete */
-   return false && fw_has_capa(>fw->ucode_capa,
-   IWL_UCODE_TLV_CAPA_DQA_SUPPORT);
+   return fw_has_capa(>fw->ucode_capa,
+  IWL_UCODE_TLV_CAPA_DQA_SUPPORT);
 }
 
 static inline bool iwl_mvm_enter_d0i3_on_suspend(struct iwl_mvm *mvm)
-- 
2.9.3

[PATCH 03/10] iwlwifi: mvm: support MONITOR vif in DQA mode

2016-10-19 Thread Luca Coelho 
From: Liad Kaufman 

In DQA mode the TXQs are allocated on demand, so make
sure the sniffer STA tfd_queue_msk isn't set.

Signed-off-by: Liad Kaufman 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
index 6b962d6..9a91203 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c
@@ -899,9 +899,11 @@ static int iwl_mvm_mac_ctxt_cmd_listener(struct iwl_mvm 
*mvm,
 
iwl_mvm_mac_ctxt_cmd_common(mvm, vif, , NULL, action);
 
-   for (i = 0; i < IEEE80211_NUM_ACS; i++)
-   if (vif->hw_queue[i] != IEEE80211_INVAL_HW_QUEUE)
-   tfd_queue_msk |= BIT(vif->hw_queue[i]);
+   if (!iwl_mvm_is_dqa_supported(mvm)) {
+   for (i = 0; i < IEEE80211_NUM_ACS; i++)
+   if (vif->hw_queue[i] != IEEE80211_INVAL_HW_QUEUE)
+   tfd_queue_msk |= BIT(vif->hw_queue[i]);
+   }
 
cmd.filter_flags = cpu_to_le32(MAC_FILTER_IN_PROMISC |
   MAC_FILTER_IN_CONTROL_AND_MGMT |
-- 
2.9.3

[PATCH 04/10] iwlwifi: mvm: fix dqa deferred frames marking

2016-10-19 Thread Luca Coelho 
From: Liad Kaufman 

When a STA has deferred traffic to TX, an appropriate bit
is turned on in %deferred_tx_frames to indicate deferred
traffic. This marking is never turned off, resulting in
iterating over TIDs with no deferred traffic.

Although this didn't cause any failures/errors/bugs, there
is still no point of iterating over these TIDs when not
needed.

Signed-off-by: Liad Kaufman 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
index c9dcb70..5ec1b96 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/sta.c
@@ -1015,6 +1015,7 @@ static void iwl_mvm_tx_deferred_stream(struct iwl_mvm 
*mvm,
local_bh_disable();
spin_lock(>lock);
skb_queue_splice_init(_data->deferred_tx_frames, _tx);
+   mvmsta->deferred_traffic_tid_map &= ~BIT(tid);
spin_unlock(>lock);
 
while ((skb = __skb_dequeue(_tx)))
-- 
2.9.3

[PATCH 10/10] iwlwifi: mvm: use dev_coredumpsg()

2016-10-19 Thread Luca Coelho 
From: Aviya Erenfeld 

iwlmvm currently uses dev_coredumpm() to collect multiple
buffers, but this has the downside of pinning the module
until the coredump expires, if the data isn't read by any
userspace.

Avoid this by using the new dev_coredumpsg() method. We
still copy the data from the old way of generating it, but
neither hold on to vmalloc'ed data for a long time, nor do
we pin the module now.

Signed-off-by: Aviya Erenfeld 
[rewrite commit message]
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 100 +---
 1 file changed, 55 insertions(+), 45 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
index d89d0a1..2e8e3e8 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c
@@ -70,49 +70,6 @@
 #include "iwl-prph.h"
 #include "iwl-csr.h"
 
-static ssize_t iwl_mvm_read_coredump(char *buffer, loff_t offset, size_t count,
-void *data, size_t datalen)
-{
-   const struct iwl_mvm_dump_ptrs *dump_ptrs = data;
-   ssize_t bytes_read;
-   ssize_t bytes_read_trans;
-
-   if (offset < dump_ptrs->op_mode_len) {
-   bytes_read = min_t(ssize_t, count,
-  dump_ptrs->op_mode_len - offset);
-   memcpy(buffer, (u8 *)dump_ptrs->op_mode_ptr + offset,
-  bytes_read);
-   offset += bytes_read;
-   count -= bytes_read;
-
-   if (count == 0)
-   return bytes_read;
-   } else {
-   bytes_read = 0;
-   }
-
-   if (!dump_ptrs->trans_ptr)
-   return bytes_read;
-
-   offset -= dump_ptrs->op_mode_len;
-   bytes_read_trans = min_t(ssize_t, count,
-dump_ptrs->trans_ptr->len - offset);
-   memcpy(buffer + bytes_read,
-  (u8 *)dump_ptrs->trans_ptr->data + offset,
-  bytes_read_trans);
-
-   return bytes_read + bytes_read_trans;
-}
-
-static void iwl_mvm_free_coredump(void *data)
-{
-   const struct iwl_mvm_dump_ptrs *fw_error_dump = data;
-
-   vfree(fw_error_dump->op_mode_ptr);
-   vfree(fw_error_dump->trans_ptr);
-   kfree(fw_error_dump);
-}
-
 #define RADIO_REG_MAX_READ 0x2ad
 static void iwl_mvm_read_radio_reg(struct iwl_mvm *mvm,
   struct iwl_fw_error_dump_data **dump_data)
@@ -491,6 +448,43 @@ static u32 iwl_dump_prph(struct iwl_trans *trans,
return prph_len;
 }
 
+/*
+ * alloc_sgtable - allocates scallerlist table in the given size,
+ * fills it with pages and returns it
+ * @size: the size (in bytes) of the table
+*/
+static struct scatterlist *alloc_sgtable(int size)
+{
+   int alloc_size, nents, i;
+   struct page *new_page;
+   struct scatterlist *iter;
+   struct scatterlist *table;
+
+   nents = DIV_ROUND_UP(size, PAGE_SIZE);
+   table = kcalloc(nents, sizeof(*table), GFP_KERNEL);
+   if (!table)
+   return NULL;
+   sg_init_table(table, nents);
+   iter = table;
+   for_each_sg(table, iter, sg_nents(table), i) {
+   new_page = alloc_page(GFP_KERNEL);
+   if (!new_page) {
+   /* release all previous allocated pages in the table */
+   iter = table;
+   for_each_sg(table, iter, sg_nents(table), i) {
+   new_page = sg_page(iter);
+   if (new_page)
+   __free_page(new_page);
+   }
+   return NULL;
+   }
+   alloc_size = min_t(int, size, PAGE_SIZE);
+   size -= PAGE_SIZE;
+   sg_set_page(iter, new_page, alloc_size, 0);
+   }
+   return table;
+}
+
 void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
 {
struct iwl_fw_error_dump_file *dump_file;
@@ -499,6 +493,7 @@ void iwl_mvm_fw_error_dump(struct iwl_mvm *mvm)
struct iwl_fw_error_dump_mem *dump_mem;
struct iwl_fw_error_dump_trigger_desc *dump_trig;
struct iwl_mvm_dump_ptrs *fw_error_dump;
+   struct scatterlist *sg_dump_data;
u32 sram_len, sram_ofs;
struct iwl_fw_dbg_mem_seg_tlv * const *fw_dbg_mem =
mvm->fw->dbg_mem_tlv;
@@ -815,8 +810,23 @@ dump_trans_data:
file_len += fw_error_dump->trans_ptr->len;
dump_file->file_len = cpu_to_le32(file_len);
 
-   dev_coredumpm(mvm->trans->dev, THIS_MODULE, fw_error_dump, 0,
- GFP_KERNEL, iwl_mvm_read_coredump, iwl_mvm_free_coredump);
+   sg_dump_data = alloc_sgtable(file_len);
+   if (sg_dump_data) {
+

[char-misc-next 3/5] nfc: mei: use module_mei_cl_driver macro

2016-10-19 Thread Tomas Winkler 
Replace boilerplate driver registration with module_mei_cl_driver
macro in pn544 and microread devices.

Signed-off-by: Tomas Winkler 
---
 drivers/nfc/microread/mei.c | 23 +--
 drivers/nfc/pn544/mei.c | 23 +--
 2 files changed, 2 insertions(+), 44 deletions(-)

diff --git a/drivers/nfc/microread/mei.c b/drivers/nfc/microread/mei.c
index 3092501f26c4..eb5eddf1794e 100644
--- a/drivers/nfc/microread/mei.c
+++ b/drivers/nfc/microread/mei.c
@@ -82,28 +82,7 @@ static struct mei_cl_driver microread_driver = {
.remove = microread_mei_remove,
 };
 
-static int microread_mei_init(void)
-{
-   int r;
-
-   pr_debug(DRIVER_DESC ": %s\n", __func__);
-
-   r = mei_cldev_driver_register(_driver);
-   if (r) {
-   pr_err(MICROREAD_DRIVER_NAME ": driver registration failed\n");
-   return r;
-   }
-
-   return 0;
-}
-
-static void microread_mei_exit(void)
-{
-   mei_cldev_driver_unregister(_driver);
-}
-
-module_init(microread_mei_init);
-module_exit(microread_mei_exit);
+module_mei_cl_driver(microread_driver);
 
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION(DRIVER_DESC);
diff --git a/drivers/nfc/pn544/mei.c b/drivers/nfc/pn544/mei.c
index 46d0eb24eef9..ad57a8ec00d6 100644
--- a/drivers/nfc/pn544/mei.c
+++ b/drivers/nfc/pn544/mei.c
@@ -82,28 +82,7 @@ static struct mei_cl_driver pn544_driver = {
.remove = pn544_mei_remove,
 };
 
-static int pn544_mei_init(void)
-{
-   int r;
-
-   pr_debug(DRIVER_DESC ": %s\n", __func__);
-
-   r = mei_cldev_driver_register(_driver);
-   if (r) {
-   pr_err(PN544_DRIVER_NAME ": driver registration failed\n");
-   return r;
-   }
-
-   return 0;
-}
-
-static void pn544_mei_exit(void)
-{
-   mei_cldev_driver_unregister(_driver);
-}
-
-module_init(pn544_mei_init);
-module_exit(pn544_mei_exit);
+module_mei_cl_driver(pn544_driver);
 
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION(DRIVER_DESC);
-- 
2.7.4

[char-misc-next 1/5] mei: bus: add module_mei_cl_driver helper macro

2016-10-19 Thread Tomas Winkler 
Add module_mei_cl_driver helper macro for eliminating the boilerplate
code from mei_cl drivers registration. The macro is intended for
drivers which in their init/exit sections does only register/unregister
of a mei_cl driver.

Signed-off-by: Tomas Winkler 
---
 include/linux/mei_cl_bus.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h
index e746919530f5..e6fbd98ea90e 100644
--- a/include/linux/mei_cl_bus.h
+++ b/include/linux/mei_cl_bus.h
@@ -74,6 +74,19 @@ int __mei_cldev_driver_register(struct mei_cl_driver *cldrv,
 
 void mei_cldev_driver_unregister(struct mei_cl_driver *cldrv);
 
+/**
+ * module_mei_cl_driver - Helper macro for registering mei cl driver
+ *
+ * @__mei_cldrv mei_cl_driver structure
+ *
+ *  Helper macro for mei cl drivers which do not do anything special in module
+ *  init/exit, for eliminating a boilerplate code.
+ */
+#define module_mei_cl_driver(__mei_cldrv) \
+   module_driver(__mei_cldrv, \
+ mei_cldev_driver_register,\
+ mei_cldev_driver_unregister)
+
 ssize_t mei_cldev_send(struct mei_cl_device *cldev, u8 *buf, size_t length);
 ssize_t  mei_cldev_recv(struct mei_cl_device *cldev, u8 *buf, size_t length);
 
-- 
2.7.4

[char-misc-next 2/5] watchdog: mei_wdt: use module_mei_cl_driver macro

2016-10-19 Thread Tomas Winkler 
Replace boilerplate driver registration with module_mei_cl_driver macro.

Signed-off-by: Tomas Winkler 
---
 drivers/watchdog/mei_wdt.c | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
index 630bd189f167..116be477c8fd 100644
--- a/drivers/watchdog/mei_wdt.c
+++ b/drivers/watchdog/mei_wdt.c
@@ -699,25 +699,7 @@ static struct mei_cl_driver mei_wdt_driver = {
.remove = mei_wdt_remove,
 };
 
-static int __init mei_wdt_init(void)
-{
-   int ret;
-
-   ret = mei_cldev_driver_register(_wdt_driver);
-   if (ret) {
-   pr_err(KBUILD_MODNAME ": module registration failed\n");
-   return ret;
-   }
-   return 0;
-}
-
-static void __exit mei_wdt_exit(void)
-{
-   mei_cldev_driver_unregister(_wdt_driver);
-}
-
-module_init(mei_wdt_init);
-module_exit(mei_wdt_exit);
+module_mei_cl_driver(mei_wdt_driver);
 
 MODULE_AUTHOR("Intel Corporation");
 MODULE_LICENSE("GPL");
-- 
2.7.4

Re: [PATCH net-next 2/6] net: use core MTU range checking in wireless drivers

2016-10-19 Thread Johannes Berg 

> > I guess we should do the same in net/mac80211/iface.c?
> 
> Yeah. I thought I'd located all places this needed to happen, but
> obviously not. I'll get this added and do another sweep for others I
> might have missed.

No worries. I can also do it if you prefer, just wanted to ask :)

johannes

[PATCH 4/7] iwlwifi: mvm: comply with fw_restart mod param on suspend

2016-10-19 Thread Luca Coelho 
From: Haim Dreyfuss 

If the suspend flow fails, we restart the hardware to go back to
the D0 image (with non-unified images), but we don't comply with
the fw_restart module parameter.  If something goes wrong when
starting the D3 image, we may want to debug it, so we should
comply with the fw_restart flag to avoid clearing everything up
and losing the firmware state when the error occurred.

Signed-off-by: Haim Dreyfuss 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index 0e17cb2..03a8fc5 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -1254,7 +1254,10 @@ static int __iwl_mvm_suspend(struct ieee80211_hw *hw,
  out:
if (ret < 0) {
iwl_mvm_ref(mvm, IWL_MVM_REF_UCODE_DOWN);
-   ieee80211_restart_hw(mvm->hw);
+   if (mvm->restart_fw > 0) {
+   mvm->restart_fw--;
+   ieee80211_restart_hw(mvm->hw);
+   }
iwl_mvm_free_nd(mvm);
}
  out_noreset:
-- 
2.9.3

[PATCH 5/7] iwlwifi: mvm: wake the wait queue when the RX sync counter is zero

2016-10-19 Thread Luca Coelho 
From: Sara Sharon 

When we sync the RX queues the driver waits to receive echo
notification on all the RX queues.
The wait queue is set with timeout until all queues have received
the notification.
However, iwl_mvm_rx_queue_notif() never woke up the wait queue,
with the result of the counter value being checked only when the
timeout expired.
This may cause a latency of up to 1 second.

Fixes: 0636b938214c ("iwlwifi: mvm: implement driver RX queues sync command")
Signed-off-by: Sara Sharon 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 3 +--
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h  | 1 +
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c  | 1 +
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 3 ++-
 4 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 318efd8..1db1dc1 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -4121,7 +4121,6 @@ void iwl_mvm_sync_rx_queues_internal(struct iwl_mvm *mvm,
 struct iwl_mvm_internal_rxq_notif *notif,
 u32 size)
 {
-   DECLARE_WAIT_QUEUE_HEAD_ONSTACK(notif_waitq);
u32 qmask = BIT(mvm->trans->num_rx_queues) - 1;
int ret;
 
@@ -4143,7 +4142,7 @@ void iwl_mvm_sync_rx_queues_internal(struct iwl_mvm *mvm,
}
 
if (notif->sync)
-   ret = wait_event_timeout(notif_waitq,
+   ret = wait_event_timeout(mvm->rx_sync_waitq,
 atomic_read(>queue_sync_counter) 
== 0,
 HZ);
WARN_ON_ONCE(!ret);
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h 
b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
index d17cbf6..c60703e 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h
@@ -937,6 +937,7 @@ struct iwl_mvm {
/* sync d0i3_tx queue and IWL_MVM_STATUS_IN_D0I3 status flag */
spinlock_t d0i3_tx_lock;
wait_queue_head_t d0i3_exit_waitq;
+   wait_queue_head_t rx_sync_waitq;
 
/* BT-Coex */
struct iwl_bt_coex_profile_notif last_bt_notif;
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
index 05fe6dd..4d35deb 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/ops.c
@@ -619,6 +619,7 @@ iwl_op_mode_mvm_start(struct iwl_trans *trans, const struct 
iwl_cfg *cfg,
spin_lock_init(>refs_lock);
skb_queue_head_init(>d0i3_tx);
init_waitqueue_head(>d0i3_exit_waitq);
+   init_waitqueue_head(>rx_sync_waitq);
 
atomic_set(>queue_sync_counter, 0);
 
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
index a57c6ef..6c802ce 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c
@@ -547,7 +547,8 @@ void iwl_mvm_rx_queue_notif(struct iwl_mvm *mvm, struct 
iwl_rx_cmd_buffer *rxb,
  "Received expired RX queue sync message\n");
return;
}
-   atomic_dec(>queue_sync_counter);
+   if (!atomic_dec_return(>queue_sync_counter))
+   wake_up(>rx_sync_waitq);
}
 
switch (internal_notif->type) {
-- 
2.9.3

[PATCH 6/7] iwlwifi: pcie: fix SPLC structure parsing

2016-10-19 Thread Luca Coelho 
From: Luca Coelho 

The SPLC data parsing is too restrictive and was not trying find the
correct element for WiFi.  This causes problems with some BIOSes where
the SPLC method exists, but doesn't have a WiFi entry on the first
element of the list.  The domain type values are also incorrect
according to the specification.

Fix this by complying with the actual specification.

Additionally, replace all occurrences of SPLX to SPLC, since SPLX is
only a structure internal to the ACPI tables, and may not even exist.

Fixes: bcb079a14d75 ("iwlwifi: pcie: retrieve and parse ACPI power limitations")
Reported-by: Chris Rorvick 
Tested-by: Paul Bolle 
Tested-by: Chris Rorvick 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 79 ---
 1 file changed, 48 insertions(+), 31 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 001be40..2f8134b 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -541,48 +541,64 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
 MODULE_DEVICE_TABLE(pci, iwl_hw_card_ids);
 
 #ifdef CONFIG_ACPI
-#define SPL_METHOD "SPLC"
-#define SPL_DOMAINTYPE_MODULE  BIT(0)
-#define SPL_DOMAINTYPE_WIFIBIT(1)
-#define SPL_DOMAINTYPE_WIGIG   BIT(2)
-#define SPL_DOMAINTYPE_RFEMBIT(3)
+#define ACPI_SPLC_METHOD   "SPLC"
+#define ACPI_SPLC_DOMAIN_WIFI  (0x07)
 
-static u64 splx_get_pwr_limit(struct iwl_trans *trans, union acpi_object *splx)
+static u64 splc_get_pwr_limit(struct iwl_trans *trans, union acpi_object *splc)
 {
-   union acpi_object *limits, *domain_type, *power_limit;
-
-   if (splx->type != ACPI_TYPE_PACKAGE ||
-   splx->package.count != 2 ||
-   splx->package.elements[0].type != ACPI_TYPE_INTEGER ||
-   splx->package.elements[0].integer.value != 0) {
-   IWL_ERR(trans, "Unsupported splx structure\n");
+   union acpi_object *data_pkg, *dflt_pwr_limit;
+   int i;
+
+   /* We need at least two elements, one for the revision and one
+* for the data itself.  Also check that the revision is
+* supported (currently only revision 0).
+   */
+   if (splc->type != ACPI_TYPE_PACKAGE ||
+   splc->package.count < 2 ||
+   splc->package.elements[0].type != ACPI_TYPE_INTEGER ||
+   splc->package.elements[0].integer.value != 0) {
+   IWL_DEBUG_INFO(trans,
+  "Unsupported structure returned by the SPLC 
method.  Ignoring.\n");
return 0;
}
 
-   limits = >package.elements[1];
-   if (limits->type != ACPI_TYPE_PACKAGE ||
-   limits->package.count < 2 ||
-   limits->package.elements[0].type != ACPI_TYPE_INTEGER ||
-   limits->package.elements[1].type != ACPI_TYPE_INTEGER) {
-   IWL_ERR(trans, "Invalid limits element\n");
-   return 0;
+   /* loop through all the packages to find the one for WiFi */
+   for (i = 1; i < splc->package.count; i++) {
+   union acpi_object *domain;
+
+   data_pkg = >package.elements[i];
+
+   /* Skip anything that is not a package with the right
+* amount of elements (i.e. at least 2 integers).
+*/
+   if (data_pkg->type != ACPI_TYPE_PACKAGE ||
+   data_pkg->package.count < 2 ||
+   data_pkg->package.elements[0].type != ACPI_TYPE_INTEGER ||
+   data_pkg->package.elements[1].type != ACPI_TYPE_INTEGER)
+   continue;
+
+   domain = _pkg->package.elements[0];
+   if (domain->integer.value == ACPI_SPLC_DOMAIN_WIFI)
+   break;
+
+   data_pkg = NULL;
}
 
-   domain_type = >package.elements[0];
-   power_limit = >package.elements[1];
-   if (!(domain_type->integer.value & SPL_DOMAINTYPE_WIFI)) {
-   IWL_DEBUG_INFO(trans, "WiFi power is not limited\n");
+   if (!data_pkg) {
+   IWL_DEBUG_INFO(trans,
+  "No element for the WiFi domain returned by the 
SPLC method.\n");
return 0;
}
 
-   return power_limit->integer.value;
+   dflt_pwr_limit = _pkg->package.elements[1];
+   return dflt_pwr_limit->integer.value;
 }
 
 static void set_dflt_pwr_limit(struct iwl_trans *trans, struct pci_dev *pdev)
 {
acpi_handle pxsx_handle;
acpi_handle handle;
-   struct acpi_buffer splx = {ACPI_ALLOCATE_BUFFER, NULL};
+   struct acpi_buffer splc = {ACPI_ALLOCATE_BUFFER, NULL};
acpi_status status;
 
pxsx_handle = ACPI_HANDLE(>dev);
@@ -593,23 +609,24 @@ static void set_dflt_pwr_limit(struct iwl_trans *trans,

[PATCH 2/7] iwlwifi: mvm: use ssize_t for len in iwl_debugfs_mem_read()

2016-10-19 Thread Luca Coelho 
From: Luca Coelho 

In iwl_dbgfs_mem_read(), the len variable may become negative and is
compared to < 0 (an error case).  Comparing size_t (which is unsigned)
to < 0 causes a warning on certain platforms (like i386):

drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:1561:5-8: WARNING: Unsigned 
expression compared with zero: len < 0

To prevent that, use ssize_t for len instead.

Fixes: commit 2b55f43f8e47 ("iwlwifi: mvm: Add mem debugfs entry")
Reported-by: kbuild test robot 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
index 539d718..06805a6 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c
@@ -1529,8 +1529,8 @@ static ssize_t iwl_dbgfs_mem_read(struct file *file, char 
__user *user_buf,
.data = { , },
.len = { sizeof(cmd) },
};
-   size_t delta, len;
-   ssize_t ret;
+   size_t delta;
+   ssize_t ret, len;
 
hcmd.id = iwl_cmd_id(*ppos >> 24 ? UMAC_RD_WR : LMAC_RD_WR,
 DEBUG_GROUP, 0);
-- 
2.9.3

[PATCH 3/7] iwlwifi: mvm: fix d3_test with unified D0/D3 images

2016-10-19 Thread Luca Coelho 
From: Luca Coelho 

When a unified D0/D3 image is used, we don't restart the FW in the
D0->D3->D0 transitions.  Therefore, the d3_test functionality should
not call ieee8021_restart_hw() when the resuming either.

Fixes: commit 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on 
suspend")
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 25 +++--
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index 4fdc3da..0e17cb2 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -2271,7 +2271,8 @@ static void iwl_mvm_d3_test_disconn_work_iter(void 
*_data, u8 *mac,
 static int iwl_mvm_d3_test_release(struct inode *inode, struct file *file)
 {
struct iwl_mvm *mvm = inode->i_private;
-   int remaining_time = 10;
+   bool unified_image = fw_has_capa(>fw->ucode_capa,
+IWL_UCODE_TLV_CAPA_CNSLDTD_D3_D0_IMG);
 
mvm->d3_test_active = false;
 
@@ -2282,17 +2283,21 @@ static int iwl_mvm_d3_test_release(struct inode *inode, 
struct file *file)
mvm->trans->system_pm_mode = IWL_PLAT_PM_MODE_DISABLED;
 
iwl_abort_notification_waits(>notif_wait);
-   ieee80211_restart_hw(mvm->hw);
+   if (!unified_image) {
+   int remaining_time = 10;
 
-   /* wait for restart and disconnect all interfaces */
-   while (test_bit(IWL_MVM_STATUS_IN_HW_RESTART, >status) &&
-  remaining_time > 0) {
-   remaining_time--;
-   msleep(1000);
-   }
+   ieee80211_restart_hw(mvm->hw);
+
+   /* wait for restart and disconnect all interfaces */
+   while (test_bit(IWL_MVM_STATUS_IN_HW_RESTART, >status) &&
+  remaining_time > 0) {
+   remaining_time--;
+   msleep(1000);
+   }
 
-   if (remaining_time == 0)
-   IWL_ERR(mvm, "Timed out waiting for HW restart to finish!\n");
+   if (remaining_time == 0)
+   IWL_ERR(mvm, "Timed out waiting for HW restart!\n");
+   }
 
ieee80211_iterate_active_interfaces_atomic(
mvm->hw, IEEE80211_IFACE_ITER_NORMAL,
-- 
2.9.3

[PATCH 1/7] iwlwifi: pcie: mark command queue lock with separate lockdep class

2016-10-19 Thread Luca Coelho 
From: Johannes Berg 

Emmanuel reports that when CMD_WANT_ASYNC_CALLBACK is used by mvm,
the callback will be called with the command queue lock held, and
mvm will try to stop all (other) TX queues, which acquires their
locks - this caused a false lockdep recursive locking report.

Suppress this report by marking the command queue lock with a new,
separate, lock class so lockdep can tell the difference between
the two types of queues.

Fixes: 156f92f2b471 ("iwlwifi: block the queues when we send ADD_STA for uAPSD")
Reported-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
index e9a278b..5f840f1 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
@@ -592,6 +592,7 @@ error:
 static int iwl_pcie_txq_init(struct iwl_trans *trans, struct iwl_txq *txq,
  int slots_num, u32 txq_id)
 {
+   struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
int ret;
 
txq->need_update = false;
@@ -606,6 +607,13 @@ static int iwl_pcie_txq_init(struct iwl_trans *trans, 
struct iwl_txq *txq,
return ret;
 
spin_lock_init(>lock);
+
+   if (txq_id == trans_pcie->cmd_queue) {
+   static struct lock_class_key iwl_pcie_cmd_queue_lock_class;
+
+   lockdep_set_class(>lock, _pcie_cmd_queue_lock_class);
+   }
+
__skb_queue_head_init(>overflow_q);
 
/*
-- 
2.9.3

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

2016-10-19 Thread Ard Biesheuvel 
On 19 October 2016 at 08:43, Johannes Berg  wrote:
> On Wed, 2016-10-19 at 11:31 +0800, Herbert Xu wrote:
>> On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote:
>> >
>> >
>> > Annoyingly, all this complication with scatterlists etc is for
>> > doing
>> > asynchronous crypto via DMA capable crypto accelerators, and the
>> > networking code (ipsec as well as mac80211, afaik) only allow
>> > synchronous in the first place, given that they execute in softirq
>> > context.
>>
>> I'm still thinking about the issue (in particular, whether we
>> should continue to rely on the request context being SG-capable
>> or allow it to be on the stack for AEAD).
>
> :)
>
>> But IPsec definitely supports async crypto.  In fact it was the
>> very first user of async crypto.
>
> Yeah.
>

Ah yes, my bad.

>> mac80211 on the other hand is currently sync-only.
>
> We could probably make mac80211 do that too, but can we guarantee in-
> order processing? Anyway, it's pretty low priority, maybe never
> happening, since hardly anyone really uses "software" crypto, the wifi
> devices mostly have it built in anyway.
>

Indeed. The code is now correct in terms of API requirements, so let's
just wait for someone to complain about any performance regressions.

Re: sequence diagrams in rst documentation

2016-10-19 Thread Markus Heiser 

Am 18.10.2016 um 16:52 schrieb Jani Nikula :

>> *Only* adding the PNG would be awful, I'd have to keep track of the
>> corresponding source elsewhere, and perhaps couldn't even GPL it
>> because then I couldn't distribute the PNG without corresponding
>> source...
>> 
>> Adding the source text would really be the only practical choice, but
>> doing so makes it easy to mismatch things, and also very easy to use
>> proprietary services for it that may go away at any time, etc.
> 
> Agreed. And there are other problems with attaching binaries (although
> I'd say we should fix them too) [1].
> 
> [1] http://lkml.kernel.org/r/02a78907-933d-3f61-572e-28154b16b...@redhat.com

Hmm, I was not briefed that binaries are problematic. I have seen
GIFs e.g. [2] and PDFs with a long history (when I worked with the media
documentation), so I thought binaries are OK.

Can you give me some more hints to understand in what ways they are
problematic?  / sorry if my question seems dump /

[2] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/Documentation/DocBook/v4l/fieldseq_tb.gif?h=v3.0

-- Markus --

[char-misc-next 5/5] mei: bus: remove rx callback context

2016-10-19 Thread Tomas Winkler 
The callback context is redunant as all the information can be
retrived from the device struture of its private data.

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus.c | 6 ++
 drivers/nfc/mei_phy.c  | 5 ++---
 drivers/watchdog/mei_wdt.c | 6 ++
 include/linux/mei_cl_bus.h | 6 ++
 4 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 8cac7ef9ad0d..89a694ca624c 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -228,7 +228,7 @@ static void mei_cl_bus_event_work(struct work_struct *work)
bus = cldev->bus;
 
if (cldev->event_cb)
-   cldev->event_cb(cldev, cldev->events, cldev->event_context);
+   cldev->event_cb(cldev, cldev->events);
 
cldev->events = 0;
 
@@ -301,7 +301,6 @@ bool mei_cl_bus_rx_event(struct mei_cl *cl)
  * @cldev: me client devices
  * @event_cb: callback function
  * @events_mask: requested events bitmask
- * @context: driver context data
  *
  * Return: 0 on success
  * -EALREADY if an callback is already registered
@@ -309,7 +308,7 @@ bool mei_cl_bus_rx_event(struct mei_cl *cl)
  */
 int mei_cldev_register_event_cb(struct mei_cl_device *cldev,
unsigned long events_mask,
-   mei_cldev_event_cb_t event_cb, void *context)
+   mei_cldev_event_cb_t event_cb)
 {
struct mei_device *bus = cldev->bus;
int ret;
@@ -320,7 +319,6 @@ int mei_cldev_register_event_cb(struct mei_cl_device *cldev,
cldev->events = 0;
cldev->events_mask = events_mask;
cldev->event_cb = event_cb;
-   cldev->event_context = context;
INIT_WORK(>event_work, mei_cl_bus_event_work);
 
if (cldev->events_mask & BIT(MEI_CL_EVENT_RX)) {
diff --git a/drivers/nfc/mei_phy.c b/drivers/nfc/mei_phy.c
index 66dfd81ffb18..07b4239585fa 100644
--- a/drivers/nfc/mei_phy.c
+++ b/drivers/nfc/mei_phy.c
@@ -297,8 +297,7 @@ static int mei_nfc_recv(struct nfc_mei_phy *phy, u8 *buf, 
size_t length)
 }
 
 
-static void nfc_mei_event_cb(struct mei_cl_device *cldev, u32 events,
-void *context)
+static void nfc_mei_event_cb(struct mei_cl_device *cldev, u32 events)
 {
struct nfc_mei_phy *phy = mei_cldev_get_drvdata(cldev);
 
@@ -360,7 +359,7 @@ static int nfc_mei_phy_enable(void *phy_id)
}
 
r = mei_cldev_register_event_cb(phy->cldev, BIT(MEI_CL_EVENT_RX),
-nfc_mei_event_cb, phy);
+   nfc_mei_event_cb);
if (r) {
pr_err("Event cb registration failed %d\n", r);
goto err;
diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
index 116be477c8fd..e0af52265511 100644
--- a/drivers/watchdog/mei_wdt.c
+++ b/drivers/watchdog/mei_wdt.c
@@ -501,10 +501,8 @@ static void mei_wdt_notify_event(struct mei_cl_device 
*cldev)
  *
  * @cldev: bus device
  * @events: event mask
- * @context: callback context
  */
-static void mei_wdt_event(struct mei_cl_device *cldev,
- u32 events, void *context)
+static void mei_wdt_event(struct mei_cl_device *cldev, u32 events)
 {
if (events & BIT(MEI_CL_EVENT_RX))
mei_wdt_event_rx(cldev);
@@ -626,7 +624,7 @@ static int mei_wdt_probe(struct mei_cl_device *cldev,
ret = mei_cldev_register_event_cb(wdt->cldev,
  BIT(MEI_CL_EVENT_RX) |
  BIT(MEI_CL_EVENT_NOTIF),
- mei_wdt_event, NULL);
+ mei_wdt_event);
 
/* on legacy devices notification is not supported
 * this doesn't fail the registration for RX event
diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h
index e6fbd98ea90e..4adb2e7c9f84 100644
--- a/include/linux/mei_cl_bus.h
+++ b/include/linux/mei_cl_bus.h
@@ -9,7 +9,7 @@ struct mei_cl_device;
 struct mei_device;
 
 typedef void (*mei_cldev_event_cb_t)(struct mei_cl_device *cldev,
-u32 events, void *context);
+u32 events);
 
 /**
  * struct mei_cl_device - MEI device handle
@@ -27,7 +27,6 @@ typedef void (*mei_cldev_event_cb_t)(struct mei_cl_device 
*cldev,
  * @event_work: async work to execute event callback
  * @event_cb: Drivers register this callback to get asynchronous ME
  * events (e.g. Rx buffer pending) notifications.
- * @event_context: event callback run context
  * @events_mask: Events bit mask requested by driver.
  * @events: Events bitmask sent to the driver.
  *
@@ -46,7 +45,6 @@ struct mei_cl_device {
 
struct work_struct event_work;
mei_cldev_event_cb_t event_cb;
-   void *event_context;
unsigned long events_mask;
unsigned long events;
 
@@ -92,7 +90,7 @@

[char-misc-next 0/5] mei: mei client bus api changes

2016-10-19 Thread Tomas Winkler 
We are adding a helper module macro for removing boilerplate  
code in driver registration, and removing redundant context
argument from the event callback.

The changes go over misc, nfc, and watchdog subtrees. 
I believe it should be conflict free to merge it to the misc
tree.

Tomas Winkler (5):
  mei: bus: add  module_mei_cl_driver helper macro
  watchdog: mei_wdt: use module_mei_cl_driver macro
  nfc: mei: use module_mei_cl_driver macro
  nfc: mei_phy: get phy from the driver data
  mei: bus: remove rx callback context

 drivers/misc/mei/bus.c  |  6 ++
 drivers/nfc/mei_phy.c   | 10 ++
 drivers/nfc/microread/mei.c | 23 +--
 drivers/nfc/pn544/mei.c | 23 +--
 drivers/watchdog/mei_wdt.c  | 26 +++---
 include/linux/mei_cl_bus.h  | 19 +++
 6 files changed, 28 insertions(+), 79 deletions(-)

-- 
2.7.4

[PATCH 0/7] iwlwifi: updates intended for v4.9 2016-10-19

2016-10-19 Thread Luca Coelho 
From: Luca Coelho 

Hi,

Here are a few fixes that I'm planning to send for v4.9.  Nothing
major, here's what they are about:

* some fixes for suspend/resume with unified FW images;
* a fix for a false-positive lockdep report;
* a fix for multi-queue that caused an unnecessary 1 second latency;
* a fix for an ACPI parsing bug that caused a misleading error
  message;

I'll leave this in my pending branch for a while to get kbuild bot
reports and then I'll send a pull-request.

Please review.

Cheers,
Luca.


Haim Dreyfuss (1):
  iwlwifi: mvm: comply with fw_restart mod param on suspend

Johannes Berg (1):
  iwlwifi: pcie: mark command queue lock with separate lockdep class

Luca Coelho (4):
  iwlwifi: mvm: use ssize_t for len in iwl_debugfs_mem_read()
  iwlwifi: mvm: fix d3_test with unified D0/D3 images
  iwlwifi: pcie: fix SPLC structure parsing
  iwlwifi: mvm: fix netdetect starting/stopping for unified images

Sara Sharon (1):
  iwlwifi: mvm: wake the wait queue when the RX sync counter is zero

 drivers/net/wireless/intel/iwlwifi/mvm/d3.c   | 49 ++
 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c  |  4 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c |  3 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h  |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c  |  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c |  3 +-
 drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 33 --
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 79 ++-
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c  |  8 +++
 9 files changed, 128 insertions(+), 53 deletions(-)

-- 
2.9.3

[PATCH 7/7] iwlwifi: mvm: fix netdetect starting/stopping for unified images

2016-10-19 Thread Luca Coelho 
From: Luca Coelho 

With unified images, we need to make sure the net-detect scan is
stopped after resuming, since we don't restart the FW.  Also, we need
to make sure we check if there are enough scan slots available to run
it, as we do with other scans.

Fixes: commit 23ae61282b88 ("iwlwifi: mvm: Do not switch to D3 image on 
suspend")
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c   | 19 +++
 drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 33 ++-
 2 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index 03a8fc5..b88e204 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -1087,6 +1087,15 @@ iwl_mvm_netdetect_config(struct iwl_mvm *mvm,
ret = iwl_mvm_switch_to_d3(mvm);
if (ret)
return ret;
+   } else {
+   /* In theory, we wouldn't have to stop a running sched
+* scan in order to start another one (for
+* net-detect).  But in practice this doesn't seem to
+* work properly, so stop any running sched_scan now.
+*/
+   ret = iwl_mvm_scan_stop(mvm, IWL_MVM_SCAN_SCHED, true);
+   if (ret)
+   return ret;
}
 
/* rfkill release can be either for wowlan or netdetect */
@@ -2091,6 +2100,16 @@ static int __iwl_mvm_resume(struct iwl_mvm *mvm, bool 
test)
iwl_mvm_update_changed_regdom(mvm);
 
if (mvm->net_detect) {
+   /* If this is a non-unified image, we restart the FW,
+* so no need to stop the netdetect scan.  If that
+* fails, continue and try to get the wake-up reasons,
+* but trigger a HW restart by keeping a failure code
+* in ret.
+*/
+   if (unified_image)
+   ret = iwl_mvm_scan_stop(mvm, IWL_MVM_SCAN_NETDETECT,
+   false);
+
iwl_mvm_query_netdetect_reasons(mvm, vif);
/* has unlocked the mutex, so skip that */
goto out;
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
index f279fdd..fa97432 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/scan.c
@@ -1199,6 +1199,9 @@ static int iwl_mvm_num_scans(struct iwl_mvm *mvm)
 
 static int iwl_mvm_check_running_scans(struct iwl_mvm *mvm, int type)
 {
+   bool unified_image = fw_has_capa(>fw->ucode_capa,
+IWL_UCODE_TLV_CAPA_CNSLDTD_D3_D0_IMG);
+
/* This looks a bit arbitrary, but the idea is that if we run
 * out of possible simultaneous scans and the userspace is
 * trying to run a scan type that is already running, we
@@ -1225,12 +1228,30 @@ static int iwl_mvm_check_running_scans(struct iwl_mvm 
*mvm, int type)
return -EBUSY;
return iwl_mvm_scan_stop(mvm, IWL_MVM_SCAN_REGULAR, true);
case IWL_MVM_SCAN_NETDETECT:
-   /* No need to stop anything for net-detect since the
-* firmware is restarted anyway.  This way, any sched
-* scans that were running will be restarted when we
-* resume.
-   */
-   return 0;
+   /* For non-unified images, there's no need to stop
+* anything for net-detect since the firmware is
+* restarted anyway.  This way, any sched scans that
+* were running will be restarted when we resume.
+*/
+   if (!unified_image)
+   return 0;
+
+   /* If this is a unified image and we ran out of scans,
+* we need to stop something.  Prefer stopping regular
+* scans, because the results are useless at this
+* point, and we should be able to keep running
+* another scheduled scan while suspended.
+*/
+   if (mvm->scan_status & IWL_MVM_SCAN_REGULAR_MASK)
+   return iwl_mvm_scan_stop(mvm, IWL_MVM_SCAN_REGULAR,
+true);
+   if (mvm->scan_status & IWL_MVM_SCAN_SCHED_MASK)
+   return iwl_mvm_scan_stop(mvm, IWL_MVM_SCAN_SCHED,
+true);
+
+   /* fall through, something is wrong if no scan was
+* running but we ran out of scans.
+*/
default:
WARN_ON(1);
break;
-- 
2.9.3

Re: [PATCH net-next 2/6] net: use core MTU range checking in wireless drivers

2016-10-19 Thread Jarod Wilson 
On Wed, Oct 19, 2016 at 09:38:33AM +0200, Johannes Berg wrote:
> On Tue, 2016-10-18 at 22:33 -0400, Jarod Wilson wrote:
> > - set max_mtu in wil6210 driver
> > - set max_mtu in atmel driver
> > - set min/max_mtu in cisco airo driver, remove airo_change_mtu
> > - set min/max_mtu in ipw2100/ipw2200 drivers, remove
> > libipw_change_mtu
> > - set min/max_mtu in p80211netdev, remove wlan_change_mtu
> 
> I guess we should do the same in net/mac80211/iface.c?

Yeah. I thought I'd located all places this needed to happen, but
obviously not. I'll get this added and do another sweep for others I might
have missed.

-- 
Jarod Wilson
ja...@redhat.com

Re: BCM43602 firmware reports multiple BRCMF_E_DEAUTH

2016-10-19 Thread Rafał Miłecki 

On 10/04/2016 08:15 PM, Rafał Miłecki wrote:

# My smartphone remains in the same place (1 m from the AP) but there is some
# connection/A-MPDU problem.
Tue Oct  4 17:22:22 2016 kern.debug kernel: [  247.509120] brcmfmac: CONSOLE: 
026970.308 ampdu_dbg: wl0.0 scb:0035ee78 tid:0
Tue Oct  4 17:22:22 2016 kern.debug kernel: [  247.509250] brcmfmac: CONSOLE: 
026970.308 ampdu_dbg: wl0.0 dead_cnt 2 tx_in_transit 1 psm_mux 0xfff0 aqmqmap 
0x0x101 aqmfifo_status 0x0x4000 fifordy 0x0 cpbusy 0x0
Tue Oct  4 17:22:22 2016 kern.debug kernel: [  247.509304] brcmfmac: CONSOLE: 
026970.308 ampdu_dbg: ifsstat 0xaf nav_stat 0x0 txop 110486
Tue Oct  4 17:22:22 2016 kern.debug kernel: [  247.509346] brcmfmac: CONSOLE: 
026970.308 ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
Tue Oct  4 17:22:22 2016 kern.debug kernel: [  247.509411] brcmfmac: CONSOLE: 
026970.308 ampdu_dbg: txall 4 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Tue Oct  4 17:22:22 2016 kern.debug kernel: [  247.509477] brcmfmac: CONSOLE: 
026970.308 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 4 0 0 0 0 ifs_boff 0
Tue Oct  4 17:22:22 2016 kern.debug kernel: [  247.509527] brcmfmac: CONSOLE: 
026970.308 ampdu_dbg: again1 ifsstat 0xaf nav_stat 0x0
Tue Oct  4 17:22:22 2016 kern.debug kernel: [  247.509576] brcmfmac: CONSOLE: 
026970.308 ampdu_dbg: again2 ifsstat 0xaf nav_stat 0x0
Tue Oct  4 17:22:22 2016 kern.debug kernel: [  247.509665] brcmfmac: CONSOLE: 
026970.308 wl0: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress 
for 2 secs tx_in_transit 1
Tue Oct  4 17:22:22 2016 kern.debug kernel: [  247.509726] brcmfmac: CONSOLE: 
026970.308 wl0: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Tue Oct  4 17:22:41 2016 kern.debug kernel: [  266.456860] brcmfmac: CONSOLE: 
026990.068 wl0.0: wlc_send_bar: seq 0x7c tid 0
Tue Oct  4 17:22:43 2016 kern.debug kernel: [  268.178234] brcmfmac: CONSOLE: 
026991.783 pktid is NULL

# After recovering from A-MPDU thing firmware sends BRCMF_E_DEAUTH and
# BRCMF_E_DISASSOC_IND events.
# My smartphone never receives deauth/disassoc and it believes it's still
# connected to the AP.
Tue Oct  4 17:23:24 2016 kern.debug kernel: [  309.275305] brcmfmac: 
brcmf_notify_connect_status_ap event 5, reason 4
Tue Oct  4 17:23:24 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 
802.11: disassociated
Tue Oct  4 17:23:24 2016 kern.debug kernel: [  309.275354] brcmfmac: 
brcmf_notify_connect_status_ap event 12, reason 8
Tue Oct  4 17:23:24 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 
802.11: disassociated
Tue Oct  4 17:23:24 2016 kern.debug kernel: [  309.275865] brcmfmac: 
brcmf_cfg80211_del_key key index (0)
Tue Oct  4 17:23:24 2016 kern.debug kernel: [  309.276177] brcmfmac: 
brcmf_cfg80211_del_key key index (0)
Tue Oct  4 17:23:24 2016 kern.debug kernel: [  309.276188] brcmfmac: 
brcmf_cfg80211_del_key Ignore clearing of (never configured) key

# My smartphone starts sending packets. It seems brcmfmac refuses them due to
# STA not being connected and for each packet it reports BRCMF_E_DEAUTH to the
# driver.
Tue Oct  4 17:23:58 2016 kern.debug kernel: [  343.000406] brcmfmac: 
brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct  4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 
802.11: disassociated
Tue Oct  4 17:23:58 2016 kern.debug kernel: [  343.001227] brcmfmac: 
brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct  4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 
802.11: disassociated
Tue Oct  4 17:23:58 2016 kern.debug kernel: [  343.001894] brcmfmac: 
brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct  4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 
802.11: disassociated
Tue Oct  4 17:23:58 2016 kern.debug kernel: [  343.002594] brcmfmac: 
brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct  4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 
802.11: disassociated
Tue Oct  4 17:23:58 2016 kern.debug kernel: [  343.003741] brcmfmac: 
brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct  4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 
802.11: disassociated
Tue Oct  4 17:23:58 2016 kern.debug kernel: [  343.004096] brcmfmac: 
brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct  4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 
802.11: disassociated
Tue Oct  4 17:23:58 2016 kern.debug kernel: [  343.004490] brcmfmac: 
brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct  4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 
802.11: disassociated
Tue Oct  4 17:23:58 2016 kern.debug kernel: [  343.004936] brcmfmac: 
brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct  4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 
802.11: disassociated


I just got 400+ messages like this:
wlan1: STA 84:38:38:e4:b5:ea IEEE 802.11: disassociated
this time I was lucky enough to have monitor mode running on some

Re: [PATCH 0/7] patches for mac80211/cfg80211 2016-10-18

2016-10-19 Thread Johannes Berg 
On Tue, 2016-10-18 at 23:12 +0300, Luca Coelho wrote:
> From: Luca Coelho 
> 
> Hi Johannes,
> 
> Here are a few patches for mac80211/cfg80211 from our internal tree.
> You're probably familiar with most of them, I'm just adding a cover
> letter to make it easier for you to reply "Applied all"
> (hopefully).:)

Heh, ok, done; all are in mac80211-next, I didn't think they were
important for mac80211. My NULL deref fix is debatable, but the
hardware that supports this isn't shipping yet, and will never work
with this kernel due to firmware release/compatibility anyway.

Also the NAN patch you sent separately.

johannes