Re: wireless drives for intel 3165

[Luca Coelho]

 Hi,

With kernel v4.9, you must use the iwlwifi-7265D-22.ucode.  The driver
supports up to -26, but we didn't release firmwares 23 to 26 publicly.

The error messages you're seeing are harmless, because they seem to stop
 -23, which probably means -22 was found, loaded and everything should
work fine. :)

HTH.

--
Cheers,
Luca.


On Tue, 2017-07-25 at 12:18 +0800, 龚恒 wrote:
> hello,my computer'system is deepin15.4.1,the kernels is 4.9.0,my 
> computer turn on failed to load iwlwifi-7265D-26.ucode , failed to load 
> iwlwifi-7265D-25.ucode ,failed to load iwlwifi-7265D-24.ucode and failed 
> to load iwlwifi-7265D-23.ucode .
> I don't find firmware for inter 3165 with the most leastest,I need your 
> help,can you help me find the  firmware for iwlwifi-7265D-26.ucode , 
> failed to load iwlwifi-7265D-25.ucode ,failed to load 
> iwlwifi-7265D-24.ucode and failed to load iwlwifi-7265D-23.ucode and 
> send my email,thank you
> 
> 

Re: pull-request: iwlwifi firmwares update 2017-06-27

[Luca Coelho]

Ping?

On Tue, 2017-06-27 at 18:42 +0300, Luca Coelho wrote:
> Hi Kyle,
> 
> We have some updates for our -27 firmware version (on supported devices)
> and versions -29 and -31 that will be supported by the iwlwifi driver on
> v4.13.
> 
> Please pull or let me know if there are any issues.
> 
> Cheers,
> Luca.
> 
> 
> The following changes since commit 7d2c913dcd1be083350d97a8cb1eba24cfacbc8a:
> 
>   ath10k: update year in license (2017-06-22 12:06:02 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git 
> tags/iwlwifi-fw-2017-06-27
> 
> for you to fetch changes up to d392df8feda805e37022686d76be96de407a9e18:
> 
>   iwlwifi: add new firmware for 3168, 7265D, 8000C and 8265 (2017-06-27 
> 14:45:20 +0300)
> 
> 
> Update and add new firmwares for 3168, 7265D, 8000C and 8265
> 
> * new -29 for 3168 and 7265D;
> * new -31 for 8000C and 8265;
> * updated -27 for 3168, 7265D, 8000C and 8265.
> 
> 
> Emmanuel Grumbach (1):
>   iwlwifi: update -27 firmware for 3168, 7265D, 8000C and 8265
> 
> Johannes Berg (1):
>   iwlwifi: add new firmware for 3168, 7265D, 8000C and 8265
> 
>  WHENCE |  20 
>  iwlwifi-3168-27.ucode  | Bin 1032168 -> 1032436 bytes
>  iwlwifi-3168-29.ucode  | Bin 0 -> 1036372 bytes
>  iwlwifi-7265D-27.ucode | Bin 1032452 -> 1032740 bytes
>  iwlwifi-7265D-29.ucode | Bin 0 -> 1036528 bytes
>  iwlwifi-8000C-27.ucode | Bin 2227284 -> 2227284 bytes
>  iwlwifi-8000C-31.ucode | Bin 0 -> 2309768 bytes
>  iwlwifi-8265-27.ucode  | Bin 2234528 -> 2234528 bytes
>  iwlwifi-8265-31.ucode  | Bin 0 -> 2303024 bytes
>  9 files changed, 16 insertions(+), 4 deletions(-)
>  create mode 100644 iwlwifi-3168-29.ucode
>  create mode 100644 iwlwifi-7265D-29.ucode
>  create mode 100644 iwlwifi-8000C-31.ucode
>  create mode 100644 iwlwifi-8265-31.ucode

wireless drives for intel 3165

[龚恒]

hello,my computer'system is deepin15.4.1,the kernels is 4.9.0,my 
computer turn on failed to load iwlwifi-7265D-26.ucode , failed to load 
iwlwifi-7265D-25.ucode ,failed to load iwlwifi-7265D-24.ucode and failed 
to load iwlwifi-7265D-23.ucode .
I don't find firmware for inter 3165 with the most leastest,I need your 
help,can you help me find the  firmware for iwlwifi-7265D-26.ucode , 
failed to load iwlwifi-7265D-25.ucode ,failed to load 
iwlwifi-7265D-24.ucode and failed to load iwlwifi-7265D-23.ucode and 
send my email,thank you

[PATCH v2 15/20] mwifiex: pcie: unify MSI-X / non-MSI-X interrupt process

[Brian Norris]

After removing the interrupt loop in commit 5d5ddb5e0d9b ("mwifiex:
pcie: don't loop/retry interrupt status checks"), there is practically
zero difference between mwifiex_process_pcie_int() (which handled legacy
PCI interrupts and MSI interrupts) and mwifiex_process_msix_int() (which
handled MSI-X interrupts). Let's add the one relevant line to
mwifiex_process_pcie_int() and kill the copy-and-paste.

Signed-off-by: Brian Norris 
---
new in v2
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 68 ++---
 1 file changed, 3 insertions(+), 65 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 2f4da08f127c..c08ebb55a7e8 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2417,7 +2417,7 @@ static irqreturn_t mwifiex_pcie_interrupt(int irq, void 
*context)
  * In case of Rx packets received, the packets are uploaded from card to
  * host and processed accordingly.
  */
-static int mwifiex_process_pcie_int(struct mwifiex_adapter *adapter)
+static int mwifiex_process_int_status(struct mwifiex_adapter *adapter)
 {
int ret;
u32 pcie_ireg = 0;
@@ -2492,75 +2492,13 @@ static int mwifiex_process_pcie_int(struct 
mwifiex_adapter *adapter)
mwifiex_dbg(adapter, INTR,
"info: cmd_sent=%d data_sent=%d\n",
adapter->cmd_sent, adapter->data_sent);
-   if (!card->msi_enable && adapter->ps_state != PS_STATE_SLEEP)
+   if (!card->msi_enable && !card->msix_enable &&
+adapter->ps_state != PS_STATE_SLEEP)
mwifiex_pcie_enable_host_int(adapter);
 
return 0;
 }
 
-static int mwifiex_process_msix_int(struct mwifiex_adapter *adapter)
-{
-   int ret;
-   u32 pcie_ireg;
-   unsigned long flags;
-
-   spin_lock_irqsave(>int_lock, flags);
-   /* Clear out unused interrupts */
-   pcie_ireg = adapter->int_status;
-   adapter->int_status = 0;
-   spin_unlock_irqrestore(>int_lock, flags);
-
-   if (pcie_ireg & HOST_INTR_DNLD_DONE) {
-   mwifiex_dbg(adapter, INTR,
-   "info: TX DNLD Done\n");
-   ret = mwifiex_pcie_send_data_complete(adapter);
-   if (ret)
-   return ret;
-   }
-   if (pcie_ireg & HOST_INTR_UPLD_RDY) {
-   mwifiex_dbg(adapter, INTR,
-   "info: Rx DATA\n");
-   ret = mwifiex_pcie_process_recv_data(adapter);
-   if (ret)
-   return ret;
-   }
-   if (pcie_ireg & HOST_INTR_EVENT_RDY) {
-   mwifiex_dbg(adapter, INTR,
-   "info: Rx EVENT\n");
-   ret = mwifiex_pcie_process_event_ready(adapter);
-   if (ret)
-   return ret;
-   }
-
-   if (pcie_ireg & HOST_INTR_CMD_DONE) {
-   if (adapter->cmd_sent) {
-   mwifiex_dbg(adapter, INTR,
-   "info: CMD sent Interrupt\n");
-   adapter->cmd_sent = false;
-   }
-   /* Handle command response */
-   ret = mwifiex_pcie_process_cmd_complete(adapter);
-   if (ret)
-   return ret;
-   }
-
-   mwifiex_dbg(adapter, INTR,
-   "info: cmd_sent=%d data_sent=%d\n",
-   adapter->cmd_sent, adapter->data_sent);
-
-   return 0;
-}
-
-static int mwifiex_process_int_status(struct mwifiex_adapter *adapter)
-{
-   struct pcie_service_card *card = adapter->card;
-
-   if (card->msix_enable)
-   return mwifiex_process_msix_int(adapter);
-   else
-   return mwifiex_process_pcie_int(adapter);
-}
-
 /*
  * This function downloads data from driver to card.
  *
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 13/20] mwifiex: drop 'add_tail' param from mwifiex_insert_cmd_to_pending_q()

[Brian Norris]

It's always called with 'true' -- we only determine it 'false' locally
within this function. So drop the parameter.

Also, this should be 'bool' (since we use true/false), not 'u32'.

Signed-off-by: Brian Norris 
---
v2: no change
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c | 5 +++--
 drivers/net/wireless/marvell/mwifiex/main.h   | 3 +--
 drivers/net/wireless/marvell/mwifiex/scan.c   | 5 ++---
 3 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 6ff8e84b01e0..3f5e822673bf 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -664,7 +664,7 @@ int mwifiex_send_cmd(struct mwifiex_private *priv, u16 
cmd_no,
cmd_no == HostCmd_CMD_802_11_SCAN_EXT) {
mwifiex_queue_scan_cmd(priv, cmd_node);
} else {
-   mwifiex_insert_cmd_to_pending_q(adapter, cmd_node, true);
+   mwifiex_insert_cmd_to_pending_q(adapter, cmd_node);
queue_work(adapter->workqueue, >main_work);
if (cmd_node->wait_q_enabled)
ret = mwifiex_wait_queue_complete(adapter, cmd_node);
@@ -682,11 +682,12 @@ int mwifiex_send_cmd(struct mwifiex_private *priv, u16 
cmd_no,
  */
 void
 mwifiex_insert_cmd_to_pending_q(struct mwifiex_adapter *adapter,
-   struct cmd_ctrl_node *cmd_node, u32 add_tail)
+   struct cmd_ctrl_node *cmd_node)
 {
struct host_cmd_ds_command *host_cmd = NULL;
u16 command;
unsigned long flags;
+   bool add_tail = true;
 
host_cmd = (struct host_cmd_ds_command *) (cmd_node->cmd_skb->data);
if (!host_cmd) {
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 2bee5cdf1fc8..909bd1ad3838 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1088,8 +1088,7 @@ void mwifiex_recycle_cmd_node(struct mwifiex_adapter 
*adapter,
  struct cmd_ctrl_node *cmd_node);
 
 void mwifiex_insert_cmd_to_pending_q(struct mwifiex_adapter *adapter,
-struct cmd_ctrl_node *cmd_node,
-u32 addtail);
+struct cmd_ctrl_node *cmd_node);
 
 int mwifiex_exec_next_cmd(struct mwifiex_adapter *adapter);
 int mwifiex_process_cmdresp(struct mwifiex_adapter *adapter);
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c 
b/drivers/net/wireless/marvell/mwifiex/scan.c
index ae9630b49342..16eaeae74979 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -1534,8 +1534,7 @@ int mwifiex_scan_networks(struct mwifiex_private *priv,
list_del(_node->list);
spin_unlock_irqrestore(>scan_pending_q_lock,
   flags);
-   mwifiex_insert_cmd_to_pending_q(adapter, cmd_node,
-   true);
+   mwifiex_insert_cmd_to_pending_q(adapter, cmd_node);
queue_work(adapter->workqueue, >main_work);
 
/* Perform internal scan synchronously */
@@ -2033,7 +2032,7 @@ static void mwifiex_check_next_scan_command(struct 
mwifiex_private *priv)
struct cmd_ctrl_node, list);
list_del(_node->list);
spin_unlock_irqrestore(>scan_pending_q_lock, flags);
-   mwifiex_insert_cmd_to_pending_q(adapter, cmd_node, true);
+   mwifiex_insert_cmd_to_pending_q(adapter, cmd_node);
}
 
return;
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 08/20] mwifiex: ensure "disable auto DS" struct is initialized

[Brian Norris]

The .idle_time field *should* be unused, but technically, we're allowing
unitialized stack garbage to pass all the way through to the firmware
host command. Let's zero it out instead.

Signed-off-by: Brian Norris 
---
v2: no change
---
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c 
b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
index 42997e05d90f..43ecd621d1ef 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_ioctl.c
@@ -654,9 +654,9 @@ int mwifiex_get_bss_info(struct mwifiex_private *priv,
  */
 int mwifiex_disable_auto_ds(struct mwifiex_private *priv)
 {
-   struct mwifiex_ds_auto_ds auto_ds;
-
-   auto_ds.auto_ds = DEEP_SLEEP_OFF;
+   struct mwifiex_ds_auto_ds auto_ds = {
+   .auto_ds = DEEP_SLEEP_OFF,
+   };
 
return mwifiex_send_cmd(priv, HostCmd_CMD_802_11_PS_MODE_ENH,
DIS_AUTO_PS, BITMAP_AUTO_DS, _ds, true);
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 14/20] mwifiex: pcie: remove unnecessary masks

[Brian Norris]

After removing the interrupt loop in commit 5d5ddb5e0d9b ("mwifiex:
pcie: don't loop/retry interrupt status checks"), we don't need to keep
track of the cleared interrupts (actually, we didn't need to do that
before, but we *really* don't need to now).

Signed-off-by: Brian Norris 
---
new in v2
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 5c07edd4e094..2f4da08f127c 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2460,28 +2460,24 @@ static int mwifiex_process_pcie_int(struct 
mwifiex_adapter *adapter)
}
 
if (pcie_ireg & HOST_INTR_DNLD_DONE) {
-   pcie_ireg &= ~HOST_INTR_DNLD_DONE;
mwifiex_dbg(adapter, INTR, "info: TX DNLD Done\n");
ret = mwifiex_pcie_send_data_complete(adapter);
if (ret)
return ret;
}
if (pcie_ireg & HOST_INTR_UPLD_RDY) {
-   pcie_ireg &= ~HOST_INTR_UPLD_RDY;
mwifiex_dbg(adapter, INTR, "info: Rx DATA\n");
ret = mwifiex_pcie_process_recv_data(adapter);
if (ret)
return ret;
}
if (pcie_ireg & HOST_INTR_EVENT_RDY) {
-   pcie_ireg &= ~HOST_INTR_EVENT_RDY;
mwifiex_dbg(adapter, INTR, "info: Rx EVENT\n");
ret = mwifiex_pcie_process_event_ready(adapter);
if (ret)
return ret;
}
if (pcie_ireg & HOST_INTR_CMD_DONE) {
-   pcie_ireg &= ~HOST_INTR_CMD_DONE;
if (adapter->cmd_sent) {
mwifiex_dbg(adapter, INTR,
"info: CMD sent Interrupt\n");
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 07/20] mwifiex: fixup init_channel_scan_gap error case

[Brian Norris]

In reading through _mwifiex_fw_dpc(), I noticed that after we've
registered our wiphy, we still have error paths that don't free it back
up. Let's do that.

Signed-off-by: Brian Norris 
---
v2: no change
---
 drivers/net/wireless/marvell/mwifiex/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 77e491720664..0448dcc07139 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -588,7 +588,7 @@ static int _mwifiex_fw_dpc(const struct firmware *firmware, 
void *context)
if (mwifiex_init_channel_scan_gap(adapter)) {
mwifiex_dbg(adapter, ERROR,
"could not init channel stats table\n");
-   goto err_init_fw;
+   goto err_init_chan_scan;
}
 
if (driver_mode) {
@@ -636,6 +636,7 @@ static int _mwifiex_fw_dpc(const struct firmware *firmware, 
void *context)
 
 err_add_intf:
vfree(adapter->chan_stats);
+err_init_chan_scan:
wiphy_unregister(adapter->wiphy);
wiphy_free(adapter->wiphy);
 err_init_fw:
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 06/20] mwifiex: don't short-circuit netdev notifiers on interface deletion

[Brian Norris]

When we leave the delete interface function, there are still netdev
hooks that might try to process the device. We're short-circuiting some
of that by changing the interface type and clearing ieee80211_ptr. This
means we skip NETDEV_UNREGISTER_FINAL in cfg80211. Fortunately, that is
currently a no-op.

We don't need most of the cleanup here anyway:

 * the connection state will get (un)set as part of the disconnect
   process (which cfg80211 already initiates for us)
 * the interface type doesn't actually need to be cleared at all (it'll
   trigger a WARN_ON() in cfg80211 if we do)
 * the iee80211_ptr isn't really "ours" to clear anyway

So stop resetting those 3 things.

Signed-off-by: Brian Norris 
---
v2: no change
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 06ad2d50f9b0..f86a8a69d060 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3123,11 +3123,7 @@ int mwifiex_del_virtual_intf(struct wiphy *wiphy, struct 
wireless_dev *wdev)
priv->dfs_chan_sw_workqueue = NULL;
}
/* Clear the priv in adapter */
-   priv->netdev->ieee80211_ptr = NULL;
priv->netdev = NULL;
-   priv->wdev.iftype = NL80211_IFTYPE_UNSPECIFIED;
-
-   priv->media_connected = false;
 
switch (priv->bss_mode) {
case NL80211_IFTYPE_UNSPECIFIED:
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 10/20] mwifiex: make mwifiex_free_cmd_buffer() return void

[Brian Norris]

It doesn't fail.

Signed-off-by: Brian Norris 
---
new in v2; noticed when reworking driver
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c | 6 ++
 drivers/net/wireless/marvell/mwifiex/main.h   | 2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 8dad52886034..6ff8e84b01e0 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -427,7 +427,7 @@ int mwifiex_alloc_cmd_buffer(struct mwifiex_adapter 
*adapter)
  * The function calls the completion callback for all the command
  * buffers that still have response buffers associated with them.
  */
-int mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter)
+void mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter)
 {
struct cmd_ctrl_node *cmd_array;
u32 i;
@@ -436,7 +436,7 @@ int mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter)
if (!adapter->cmd_pool) {
mwifiex_dbg(adapter, FATAL,
"info: FREE_CMD_BUF: cmd_pool is null\n");
-   return 0;
+   return;
}
 
cmd_array = adapter->cmd_pool;
@@ -464,8 +464,6 @@ int mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter)
kfree(adapter->cmd_pool);
adapter->cmd_pool = NULL;
}
-
-   return 0;
 }
 
 /*
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 62ce4e81f695..2bee5cdf1fc8 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1077,7 +1077,7 @@ int mwifiex_get_debug_info(struct mwifiex_private *,
   struct mwifiex_debug_info *);
 
 int mwifiex_alloc_cmd_buffer(struct mwifiex_adapter *adapter);
-int mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter);
+void mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter);
 void mwifiex_free_cmd_buffers(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_all_pending_cmd(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter);
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 12/20] mwifiex: don't open-code ARRAY_SIZE()

[Brian Norris]

Signed-off-by: Brian Norris 
---
v2: no change
---
 drivers/net/wireless/marvell/mwifiex/cfp.c | 4 +---
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 8 ++--
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 5 ++---
 3 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfp.c 
b/drivers/net/wireless/marvell/mwifiex/cfp.c
index 6e2994308526..bfe84e55df77 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfp.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfp.c
@@ -180,11 +180,9 @@ static struct region_code_mapping region_code_mapping_t[] 
= {
 u8 *mwifiex_11d_code_2_region(u8 code)
 {
u8 i;
-   u8 size = sizeof(region_code_mapping_t)/
-   sizeof(struct region_code_mapping);
 
/* Look for code in mapping table */
-   for (i = 0; i < size; i++)
+   for (i = 0; i < ARRAY_SIZE(region_code_mapping_t); i++)
if (region_code_mapping_t[i].code == code)
return region_code_mapping_t[i].region;
 
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index 534d94a206a5..b71ad4de5e54 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -189,9 +189,7 @@ static int mwifiex_cmd_tx_rate_cfg(struct mwifiex_private 
*priv,
if (pbitmap_rates != NULL) {
rate_scope->hr_dsss_rate_bitmap = cpu_to_le16(pbitmap_rates[0]);
rate_scope->ofdm_rate_bitmap = cpu_to_le16(pbitmap_rates[1]);
-   for (i = 0;
-i < sizeof(rate_scope->ht_mcs_rate_bitmap) / sizeof(u16);
-i++)
+   for (i = 0; i < ARRAY_SIZE(rate_scope->ht_mcs_rate_bitmap); i++)
rate_scope->ht_mcs_rate_bitmap[i] =
cpu_to_le16(pbitmap_rates[2 + i]);
if (priv->adapter->fw_api_ver == MWIFIEX_FW_V15) {
@@ -206,9 +204,7 @@ static int mwifiex_cmd_tx_rate_cfg(struct mwifiex_private 
*priv,
cpu_to_le16(priv->bitmap_rates[0]);
rate_scope->ofdm_rate_bitmap =
cpu_to_le16(priv->bitmap_rates[1]);
-   for (i = 0;
-i < sizeof(rate_scope->ht_mcs_rate_bitmap) / sizeof(u16);
-i++)
+   for (i = 0; i < ARRAY_SIZE(rate_scope->ht_mcs_rate_bitmap); i++)
rate_scope->ht_mcs_rate_bitmap[i] =
cpu_to_le16(priv->bitmap_rates[2 + i]);
if (priv->adapter->fw_api_ver == MWIFIEX_FW_V15) {
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
index 2945775e83c5..0fba5b10ef2d 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c
@@ -298,9 +298,8 @@ static int mwifiex_ret_tx_rate_cfg(struct mwifiex_private 
*priv,
priv->bitmap_rates[1] =
le16_to_cpu(rate_scope->ofdm_rate_bitmap);
for (i = 0;
-i <
-sizeof(rate_scope->ht_mcs_rate_bitmap) /
-sizeof(u16); i++)
+i < ARRAY_SIZE(rate_scope->ht_mcs_rate_bitmap);
+i++)
priv->bitmap_rates[2 + i] =
le16_to_cpu(rate_scope->
ht_mcs_rate_bitmap[i]);
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 09/20] mwifiex: fix misnomers in mwifiex_free_lock_list()

[Brian Norris]

Despite the name (and meticulous comments), this function frees no
memory and does not touch any locks. All it does is "delete" the list
heads -- which just means they'll be dangling, and we'll need to re-init
them if we use them again.

It seems like this code would work OK as a sort of canary for using the
list after we've torn everything down, so it's fine to keep the code;
let's just get the name and comments to match what's actually happening.

Signed-off-by: Brian Norris 
---
new in v2; noticed when bugfixing/reworking other parts of this series
---
 drivers/net/wireless/marvell/mwifiex/init.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/init.c 
b/drivers/net/wireless/marvell/mwifiex/init.c
index de96675e43d5..de974e8bb9c6 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -373,15 +373,13 @@ void mwifiex_stop_net_dev_queue(struct net_device *netdev,
 }
 
 /*
- *  This function releases the lock variables and frees the locks and
- *  associated locks.
+ * This function invalidates the list heads.
  */
-static void mwifiex_free_lock_list(struct mwifiex_adapter *adapter)
+static void mwifiex_invalidate_lists(struct mwifiex_adapter *adapter)
 {
struct mwifiex_private *priv;
s32 i, j;
 
-   /* Free lists */
list_del(>cmd_free_q);
list_del(>cmd_pending_q);
list_del(>scan_pending_q);
@@ -422,8 +420,7 @@ mwifiex_adapter_cleanup(struct mwifiex_adapter *adapter)
 
 void mwifiex_free_cmd_buffers(struct mwifiex_adapter *adapter)
 {
-   /* Free lock variables */
-   mwifiex_free_lock_list(adapter);
+   mwifiex_invalidate_lists(adapter);
 
/* Free command buffer */
mwifiex_dbg(adapter, INFO, "info: free cmd buffer\n");
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 11/20] mwifiex: utilize netif_tx_{wake,stop}_all_queues()

[Brian Norris]

We're open-coding these. Just use the helpers.

Signed-off-by: Brian Norris 
---
v2: no change
---
 drivers/net/wireless/marvell/mwifiex/init.c | 20 ++--
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/init.c 
b/drivers/net/wireless/marvell/mwifiex/init.c
index de974e8bb9c6..e11919db7818 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -337,17 +337,9 @@ void mwifiex_wake_up_net_dev_queue(struct net_device 
*netdev,
struct mwifiex_adapter *adapter)
 {
unsigned long dev_queue_flags;
-   unsigned int i;
 
spin_lock_irqsave(>queue_lock, dev_queue_flags);
-
-   for (i = 0; i < netdev->num_tx_queues; i++) {
-   struct netdev_queue *txq = netdev_get_tx_queue(netdev, i);
-
-   if (netif_tx_queue_stopped(txq))
-   netif_tx_wake_queue(txq);
-   }
-
+   netif_tx_wake_all_queues(netdev);
spin_unlock_irqrestore(>queue_lock, dev_queue_flags);
 }
 
@@ -358,17 +350,9 @@ void mwifiex_stop_net_dev_queue(struct net_device *netdev,
struct mwifiex_adapter *adapter)
 {
unsigned long dev_queue_flags;
-   unsigned int i;
 
spin_lock_irqsave(>queue_lock, dev_queue_flags);
-
-   for (i = 0; i < netdev->num_tx_queues; i++) {
-   struct netdev_queue *txq = netdev_get_tx_queue(netdev, i);
-
-   if (!netif_tx_queue_stopped(txq))
-   netif_tx_stop_queue(txq);
-   }
-
+   netif_tx_stop_all_queues(netdev);
spin_unlock_irqrestore(>queue_lock, dev_queue_flags);
 }
 
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 16/20] mwifiex: debugfs: allow card_reset() to cancel things

[Brian Norris]

The card_reset() implementation should be setting our state flags and
cancelling commands for us (i.e., in mwifiex_shutdown_drv()), so let's
not do it here.

Also, this debugfs file is useful for testing and debugging the reset
feature, so we shouldn't do extra preparatory steps here, as that might
cause different reset behavior, which could either cause new bugs or
paper over existing ones that this debug feature should otherwise help
us catch.

Signed-off-by: Brian Norris 
---
new in v2
---
 drivers/net/wireless/marvell/mwifiex/debugfs.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/debugfs.c 
b/drivers/net/wireless/marvell/mwifiex/debugfs.c
index f6f105a7d3ff..6f4239be609d 100644
--- a/drivers/net/wireless/marvell/mwifiex/debugfs.c
+++ b/drivers/net/wireless/marvell/mwifiex/debugfs.c
@@ -940,8 +940,6 @@ mwifiex_reset_write(struct file *file,
 
if (adapter->if_ops.card_reset) {
dev_info(adapter->dev, "Resetting per request\n");
-   adapter->hw_status = MWIFIEX_HW_STATUS_RESET;
-   mwifiex_cancel_all_pending_cmd(adapter);
adapter->if_ops.card_reset(adapter);
}
 
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 20/20] mwifiex: drop num CPU notice

[Brian Norris]

This print isn't very useful. It's also different between
mwifiex_add_card() and mwifiex_reinit_sw(), and I'd like to consolidate
them eventually.

Signed-off-by: Brian Norris 
---
new in v2
---
 drivers/net/wireless/marvell/mwifiex/main.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 0448dcc07139..13fc7b6ed11d 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1619,10 +1619,8 @@ mwifiex_add_card(void *card, struct completion *fw_done,
adapter->cmd_wait_q.status = 0;
adapter->scan_wait_q_woken = false;
 
-   if ((num_possible_cpus() > 1) || adapter->iface_type == MWIFIEX_USB) {
+   if ((num_possible_cpus() > 1) || adapter->iface_type == MWIFIEX_USB)
adapter->rx_work_enabled = true;
-   pr_notice("rx work enabled, cpus %d\n", num_possible_cpus());
-   }
 
adapter->workqueue =
alloc_workqueue("MWIFIEX_WORK_QUEUE",
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 17/20] mwifiex: pcie: disable device DMA before unmapping/freeing buffers

[Brian Norris]

In testing the mwifiex reset code path, I've noticed KASAN complaining
about some "overwritten poison values" in our RX buffer descriptors.
Because KASAN didn't notice this at the time of a CPU write, this seems
to suggest that the device is writing to this memory.

This makes a little sense, because when resetting, we don't necessarily
expect the device to be responsive, so we don't have a chance to disable
everything cleanly.

We can at least take the precaution of disabling DMA for the device
though, and in my testing that seems to clear up this particular issue.

This patch reorders the removal path so that we disable the device
*before* releasing our last PCIe buffers, and it clears/sets the bus
master feature from the PCI device when resetting.

Along the way, remove the insufficient (and confusing) error path in
mwifiex_pcie_up_dev() (it doesn't unwind things well enough, and it
doesn't propagate its errors upward anyway).

Signed-off-by: Brian Norris 
---
new in v2
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index c08ebb55a7e8..a1907e8e620f 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2958,15 +2958,17 @@ static void mwifiex_cleanup_pcie(struct mwifiex_adapter 
*adapter)
"Failed to write driver not-ready 
signature\n");
}
 
-   mwifiex_pcie_free_buffers(adapter);
-
if (pdev) {
+   pci_disable_device(pdev);
+
pci_iounmap(pdev, card->pci_mmap);
pci_iounmap(pdev, card->pci_mmap1);
pci_disable_device(pdev);
pci_release_region(pdev, 2);
pci_release_region(pdev, 0);
}
+
+   mwifiex_pcie_free_buffers(adapter);
 }
 
 static int mwifiex_pcie_request_irq(struct mwifiex_adapter *adapter)
@@ -3142,7 +3144,6 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter 
*adapter)
 static void mwifiex_pcie_up_dev(struct mwifiex_adapter *adapter)
 {
struct pcie_service_card *card = adapter->card;
-   int ret;
struct pci_dev *pdev = card->dev;
 
/* tx_buf_size might be changed to 3584 by firmware during
@@ -3150,11 +3151,9 @@ static void mwifiex_pcie_up_dev(struct mwifiex_adapter 
*adapter)
 */
adapter->tx_buf_size = card->pcie.tx_buf_size;
 
-   ret = mwifiex_pcie_alloc_buffers(adapter);
-   if (!ret)
-   return;
+   mwifiex_pcie_alloc_buffers(adapter);
 
-   pci_iounmap(pdev, card->pci_mmap1);
+   pci_set_master(pdev);
 }
 
 /* This function cleans up the PCI-E host memory space. */
@@ -3162,10 +3161,13 @@ static void mwifiex_pcie_down_dev(struct 
mwifiex_adapter *adapter)
 {
struct pcie_service_card *card = adapter->card;
const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
+   struct pci_dev *pdev = card->dev;
 
if (mwifiex_write_reg(adapter, reg->drv_rdy, 0x))
mwifiex_dbg(adapter, ERROR, "Failed to write driver not-ready 
signature\n");
 
+   pci_clear_master(pdev);
+
adapter->seq_num = 0;
 
mwifiex_pcie_free_buffers(adapter);
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 18/20] mwifiex: pcie: remove unnecessary 'pdev' check

[Brian Norris]

'card->dev' is initialized once and is never cleared. Drop the
unnecessary "safety" check, as it simply obscures things, and we don't
do this check everywhere (and therefore it's not really "safe").

Signed-off-by: Brian Norris 
---
new in v2
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index a1907e8e620f..1993b9b339df 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2958,15 +2958,12 @@ static void mwifiex_cleanup_pcie(struct mwifiex_adapter 
*adapter)
"Failed to write driver not-ready 
signature\n");
}
 
-   if (pdev) {
-   pci_disable_device(pdev);
+   pci_disable_device(pdev);
 
-   pci_iounmap(pdev, card->pci_mmap);
-   pci_iounmap(pdev, card->pci_mmap1);
-   pci_disable_device(pdev);
-   pci_release_region(pdev, 2);
-   pci_release_region(pdev, 0);
-   }
+   pci_iounmap(pdev, card->pci_mmap);
+   pci_iounmap(pdev, card->pci_mmap1);
+   pci_release_region(pdev, 2);
+   pci_release_region(pdev, 0);
 
mwifiex_pcie_free_buffers(adapter);
 }
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 19/20] mwifiex: keep mwifiex_cancel_pending_ioctl() static

[Brian Norris]

It has some scary comments about "only being called" from the timeout
handler, so let's help keep it that way.

Signed-off-by: Brian Norris 
---
new in v2
---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c | 4 +++-
 drivers/net/wireless/marvell/mwifiex/main.h   | 1 -
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c 
b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 3f5e822673bf..0edc5d621304 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -26,6 +26,8 @@
 #include "11n.h"
 #include "11ac.h"
 
+static void mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter);
+
 /*
  * This function initializes a command node.
  *
@@ -1074,7 +1076,7 @@ mwifiex_cancel_all_pending_cmd(struct mwifiex_adapter 
*adapter)
  * In case of scan commands, all pending commands in scan pending queue
  * are cancelled.
  */
-void
+static void
 mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter)
 {
struct cmd_ctrl_node *cmd_node = NULL;
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 909bd1ad3838..537a0ad795ff 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1080,7 +1080,6 @@ int mwifiex_alloc_cmd_buffer(struct mwifiex_adapter 
*adapter);
 void mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter);
 void mwifiex_free_cmd_buffers(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_all_pending_cmd(struct mwifiex_adapter *adapter);
-void mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_pending_scan_cmd(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_scan(struct mwifiex_adapter *adapter);
 
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 05/20] mwifiex: unregister wiphy before freeing resources

[Brian Norris]

It's possible for some control interfaces (e.g., scans, set freq) to be
active after we've stopped our main work queue and the netif TX queues.
These don't get completely shut out until we've unregistered the wdevs
and wiphy.

So let's only free command buffers and poison our lists after
wiphy_unregister().

This resolves various use-after-free issues seen when resetting the
device.

Cc: Johannes Berg 
Signed-off-by: Brian Norris 
---
new in v2
---
 drivers/net/wireless/marvell/mwifiex/init.c | 3 +++
 drivers/net/wireless/marvell/mwifiex/main.c | 7 ++-
 drivers/net/wireless/marvell/mwifiex/main.h | 1 +
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/init.c 
b/drivers/net/wireless/marvell/mwifiex/init.c
index 3ecb59f7405b..de96675e43d5 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -418,7 +418,10 @@ mwifiex_adapter_cleanup(struct mwifiex_adapter *adapter)
mwifiex_cancel_all_pending_cmd(adapter);
wake_up_interruptible(>cmd_wait_q.wait);
wake_up_interruptible(>hs_activate_wait_q);
+}
 
+void mwifiex_free_cmd_buffers(struct mwifiex_adapter *adapter)
+{
/* Free lock variables */
mwifiex_free_lock_list(adapter);
 
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 9c8f7bcfef8b..77e491720664 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -653,6 +653,7 @@ static int _mwifiex_fw_dpc(const struct firmware *firmware, 
void *context)
if (adapter->hw_status == MWIFIEX_HW_STATUS_READY) {
pr_debug("info: %s: shutdown mwifiex\n", __func__);
mwifiex_shutdown_drv(adapter);
+   mwifiex_free_cmd_buffers(adapter);
}
 
init_failed = true;
@@ -1404,11 +1405,13 @@ static void mwifiex_uninit_sw(struct mwifiex_adapter 
*adapter)
mwifiex_del_virtual_intf(adapter->wiphy, >wdev);
rtnl_unlock();
}
-   vfree(adapter->chan_stats);
 
wiphy_unregister(adapter->wiphy);
wiphy_free(adapter->wiphy);
adapter->wiphy = NULL;
+
+   vfree(adapter->chan_stats);
+   mwifiex_free_cmd_buffers(adapter);
 }
 
 /*
@@ -1515,6 +1518,7 @@ mwifiex_reinit_sw(struct mwifiex_adapter *adapter)
mwifiex_dbg(adapter, ERROR,
"info: %s: shutdown mwifiex\n", __func__);
mwifiex_shutdown_drv(adapter);
+   mwifiex_free_cmd_buffers(adapter);
}
 
complete_all(adapter->fw_done);
@@ -1662,6 +1666,7 @@ mwifiex_add_card(void *card, struct completion *fw_done,
if (adapter->hw_status == MWIFIEX_HW_STATUS_READY) {
pr_debug("info: %s: shutdown mwifiex\n", __func__);
mwifiex_shutdown_drv(adapter);
+   mwifiex_free_cmd_buffers(adapter);
}
 err_kmalloc:
mwifiex_free_adapter(adapter);
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index f8cf3079ac7d..62ce4e81f695 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1078,6 +1078,7 @@ int mwifiex_get_debug_info(struct mwifiex_private *,
 
 int mwifiex_alloc_cmd_buffer(struct mwifiex_adapter *adapter);
 int mwifiex_free_cmd_buffer(struct mwifiex_adapter *adapter);
+void mwifiex_free_cmd_buffers(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_all_pending_cmd(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter);
 void mwifiex_cancel_pending_scan_cmd(struct mwifiex_adapter *adapter);
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 04/20] mwifiex: re-register wiphy across reset

[Brian Norris]

In general, it's helpful to use the same code for device removal as for
device reset, as this tends to have fewer bugs. Let's move the wiphy
unregistration code into the common reset and removal code.

In particular, it's very hard to properly handle the reset sequence when
something fails. Currently, if mwifiex_reinit_sw() fails, we've failed
to unregister the associated wiphy, and so running something as simple
as "iw phy" can trigger an OOPS, as the wiphy still has hooks back into
freed mwifiex data structures. For example, KASAN complained:

[... see reset fail for other reasons ...]
[ 1184.821158] mwifiex_pcie :01:00.0: info: dnld wifi firmware from 174948 
bytes
[ 1186.870914] mwifiex_pcie :01:00.0: info: FW download over, size 608396 
bytes
[ 1187.685990] mwifiex_pcie :01:00.0: WLAN FW is active
[ 1187.692673] mwifiex_pcie :01:00.0: cmd_wait_q terminated: -512
[ 1187.699075] mwifiex_pcie :01:00.0: info: _mwifiex_fw_dpc: unregister 
device
[ 1187.713476] mwifiex: Failed to bring up adapter: -5
[ 1187.718644] mwifiex_pcie :01:00.0: reinit failed: -5

[... run `iw phy` ...]
[ 1212.902419] 
==
[ 1212.909806] BUG: KASAN: use-after-free in 
mwifiex_cfg80211_get_antenna+0x54/0xfc [mwifiex] at addr ffc0ad1a8028
[ 1212.920246] Read of size 1 by task iw/3127
[...]
[ 1212.934946] page dumped because: kasan: bad access detected
[...]
[ 1212.950665] Call trace:
[ 1212.953148] [] dump_backtrace+0x0/0x190
[ 1212.958572] [] show_stack+0x20/0x28
[ 1212.963648] [] dump_stack+0xa4/0xcc
[ 1212.968723] [] kasan_report+0x378/0x500
[ 1212.974140] [] __asan_load1+0x44/0x4c
[ 1212.979462] [] mwifiex_cfg80211_get_antenna+0x54/0xfc 
[mwifiex]
[ 1212.987131] [] nl80211_send_wiphy+0x75c/0x2de0 [cfg80211]
[ 1212.994246] [] nl80211_dump_wiphy+0x32c/0x438 [cfg80211]
[ 1213.001149] [] genl_lock_dumpit+0x48/0x64
[ 1213.006746] [] netlink_dump+0x178/0x398
[ 1213.012171] [] __netlink_dump_start+0x1bc/0x260
[...]

This all goes away if we just tear down the wiphy on the way down, and
set it back up if/when we bring the device back up.

Signed-off-by: Brian Norris 
---
v2: no change
---
 drivers/net/wireless/marvell/mwifiex/main.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 275cf8dc4f2a..9c8f7bcfef8b 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1405,6 +1405,10 @@ static void mwifiex_uninit_sw(struct mwifiex_adapter 
*adapter)
rtnl_unlock();
}
vfree(adapter->chan_stats);
+
+   wiphy_unregister(adapter->wiphy);
+   wiphy_free(adapter->wiphy);
+   adapter->wiphy = NULL;
 }
 
 /*
@@ -1686,9 +1690,6 @@ int mwifiex_remove_card(struct mwifiex_adapter *adapter)
 
mwifiex_uninit_sw(adapter);
 
-   wiphy_unregister(adapter->wiphy);
-   wiphy_free(adapter->wiphy);
-
if (adapter->irq_wakeup >= 0)
device_init_wakeup(adapter->dev, false);
 
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 03/20] mwifiex: pcie: don't allow cmd buffer reuse after reset

[Brian Norris]

In rogue cases (due to other bugs) it's possible we try to process an
old command response *after* resetting the device. This could trigger a
double-free (or the SKB can get reallocated elsewhere...causing other
memory corruptions) in mwifiex_pcie_process_cmd_complete().

For safety (and symmetry) let's always NULL out the command buffer as we
free it up. We're already doing this for the command response buffer.

Signed-off-by: Brian Norris 
---
v2: no change
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index b53ecf1eddda..5c07edd4e094 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -1030,12 +1030,14 @@ static int mwifiex_pcie_delete_cmdrsp_buf(struct 
mwifiex_adapter *adapter)
mwifiex_unmap_pci_memory(adapter, card->cmdrsp_buf,
 PCI_DMA_FROMDEVICE);
dev_kfree_skb_any(card->cmdrsp_buf);
+   card->cmdrsp_buf = NULL;
}
 
if (card && card->cmd_buf) {
mwifiex_unmap_pci_memory(adapter, card->cmd_buf,
 PCI_DMA_TODEVICE);
dev_kfree_skb_any(card->cmd_buf);
+   card->cmd_buf = NULL;
}
return 0;
 }
@@ -2921,7 +2923,6 @@ static void mwifiex_pcie_free_buffers(struct 
mwifiex_adapter *adapter)
mwifiex_pcie_delete_evtbd_ring(adapter);
mwifiex_pcie_delete_rxbd_ring(adapter);
mwifiex_pcie_delete_txbd_ring(adapter);
-   card->cmdrsp_buf = NULL;
 }
 
 /*
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 01/20] mwifiex: reunite copy-and-pasted remove/reset code

[Brian Norris]

When PCIe FLR code was added, it explicitly copy-and-pasted much of
mwifiex_remove_card() into mwifiex_shutdown_sw(). This is unnecessary,
as almost all of the code should be reused.

Let's reunite what we can for now.

The only functional changes for now:

 * call netif_device_detach() in the remove() code path -- this wasn't
   done before, but it really should be a no-op, when the device is
   getting totally unregistered soon anyway

 * call the ->down_dev() driver callback only after we've finished all
   SW teardown -- this should have no significant effect, since the only
   user (pcie.c) does very minimal work there, and it doesn't matter
   that we reorder this

Signed-off-by: Brian Norris 
---
v2: no change
---
 drivers/net/wireless/marvell/mwifiex/main.c | 104 
 1 file changed, 28 insertions(+), 76 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index f2600b827e81..8615099468da 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1352,26 +1352,12 @@ static void mwifiex_main_work_queue(struct work_struct 
*work)
mwifiex_main_process(adapter);
 }
 
-/*
- * This function gets called during PCIe function level reset. Required
- * code is extracted from mwifiex_remove_card()
- */
-int
-mwifiex_shutdown_sw(struct mwifiex_adapter *adapter)
+/* Common teardown code used for both device removal and reset */
+static void mwifiex_uninit_sw(struct mwifiex_adapter *adapter)
 {
struct mwifiex_private *priv;
int i;
 
-   if (!adapter)
-   goto exit_return;
-
-   wait_for_completion(adapter->fw_done);
-   /* Caller should ensure we aren't suspending while this happens */
-   reinit_completion(adapter->fw_done);
-
-   priv = mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_ANY);
-   mwifiex_deauthenticate(priv, NULL);
-
/* We can no longer handle interrupts once we start doing the teardown
 * below.
 */
@@ -1393,12 +1379,9 @@ mwifiex_shutdown_sw(struct mwifiex_adapter *adapter)
}
 
mwifiex_dbg(adapter, CMD, "cmd: calling mwifiex_shutdown_drv...\n");
-
mwifiex_shutdown_drv(adapter);
-   if (adapter->if_ops.down_dev)
-   adapter->if_ops.down_dev(adapter);
-
mwifiex_dbg(adapter, CMD, "cmd: mwifiex_shutdown_drv done\n");
+
if (atomic_read(>rx_pending) ||
atomic_read(>tx_pending) ||
atomic_read(>cmd_pending)) {
@@ -1421,9 +1404,30 @@ mwifiex_shutdown_sw(struct mwifiex_adapter *adapter)
rtnl_unlock();
}
vfree(adapter->chan_stats);
+}
+
+/*
+ * This function gets called during PCIe function level reset.
+ */
+int mwifiex_shutdown_sw(struct mwifiex_adapter *adapter)
+{
+   struct mwifiex_private *priv;
+
+   if (!adapter)
+   return 0;
+
+   wait_for_completion(adapter->fw_done);
+   /* Caller should ensure we aren't suspending while this happens */
+   reinit_completion(adapter->fw_done);
+
+   priv = mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_ANY);
+   mwifiex_deauthenticate(priv, NULL);
+
+   mwifiex_uninit_sw(adapter);
+
+   if (adapter->if_ops.down_dev)
+   adapter->if_ops.down_dev(adapter);
 
-   mwifiex_dbg(adapter, INFO, "%s, successful\n", __func__);
-exit_return:
return 0;
 }
 EXPORT_SYMBOL_GPL(mwifiex_shutdown_sw);
@@ -1676,61 +1680,10 @@ EXPORT_SYMBOL_GPL(mwifiex_add_card);
  */
 int mwifiex_remove_card(struct mwifiex_adapter *adapter)
 {
-   struct mwifiex_private *priv = NULL;
-   int i;
-
if (!adapter)
-   goto exit_remove;
-
-   /* We can no longer handle interrupts once we start doing the teardown
-* below. */
-   if (adapter->if_ops.disable_int)
-   adapter->if_ops.disable_int(adapter);
-
-   adapter->surprise_removed = true;
-
-   mwifiex_terminate_workqueue(adapter);
-
-   /* Stop data */
-   for (i = 0; i < adapter->priv_num; i++) {
-   priv = adapter->priv[i];
-   if (priv && priv->netdev) {
-   mwifiex_stop_net_dev_queue(priv->netdev, adapter);
-   if (netif_carrier_ok(priv->netdev))
-   netif_carrier_off(priv->netdev);
-   }
-   }
-
-   mwifiex_dbg(adapter, CMD,
-   "cmd: calling mwifiex_shutdown_drv...\n");
-
-   mwifiex_shutdown_drv(adapter);
-   mwifiex_dbg(adapter, CMD,
-   "cmd: mwifiex_shutdown_drv done\n");
-   if (atomic_read(>rx_pending) ||
-   atomic_read(>tx_pending) ||
-   atomic_read(>cmd_pending)) {
-   mwifiex_dbg(adapter, ERROR,
-   "rx_pending=%d, tx_pending=%d,\t"
-   "cmd_pending=%d\n",
-   atomic_read(>rx_pending),
-   

[PATCH v2 02/20] mwifiex: reset interrupt status across device reset

[Brian Norris]

When resetting the device, we might have queued up interrupts that
didn't get a chance to finish processing. We really don't need to handle
them at this point; we just want to make sure they don't cause us to try
to process old commands from before the device was reset.

Signed-off-by: Brian Norris 
---
v2: no change
---
 drivers/net/wireless/marvell/mwifiex/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 8615099468da..275cf8dc4f2a 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1366,6 +1366,7 @@ static void mwifiex_uninit_sw(struct mwifiex_adapter 
*adapter)
 
adapter->surprise_removed = true;
mwifiex_terminate_workqueue(adapter);
+   adapter->int_status = 0;
 
/* Stop data */
for (i = 0; i < adapter->priv_num; i++) {
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 00/20] mwifiex: "reset" bugfixes and other refactorings

[Brian Norris]

Hello,

I've previously sent a stack of similar patches (with no cover letter),
starting at this patch:

[PATCH 01/14] mwifiex: pcie: properly synchronize, disable interrupts in driver 
callbacks
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1405062.html
https://patchwork.kernel.org/patch/9747263/

They fixed several bugs related to the "reset" codepath in this driver,
in which the driver tries to recover from a dead firmware, as well as making
various code improvements (e.g., refactorings, removing redunancy, improving
safety).

There were some valid criticisms of the first patch in that series (and some
real issues I hit with it later on in testing), and in the end, I believe
the concern there was not actually appearing in practice, so in order to
make some forward progress, I've dropped that patch (and related changes)
from this series. I've kept most of the rest and added a few bugfixes along
the way.

Thanks to Johannes for some brainstorming/ideas that yielded the patch
"mwifiex: unregister wiphy before freeing resources".

Regards,
Brian

Brian Norris (20):
  mwifiex: reunite copy-and-pasted remove/reset code
  mwifiex: reset interrupt status across device reset
  mwifiex: pcie: don't allow cmd buffer reuse after reset
  mwifiex: re-register wiphy across reset
  mwifiex: unregister wiphy before freeing resources
  mwifiex: don't short-circuit netdev notifiers on interface deletion
  mwifiex: fixup init_channel_scan_gap error case
  mwifiex: ensure "disable auto DS" struct is initialized
  mwifiex: fix misnomers in mwifiex_free_lock_list()
  mwifiex: make mwifiex_free_cmd_buffer() return void
  mwifiex: utilize netif_tx_{wake,stop}_all_queues()
  mwifiex: don't open-code ARRAY_SIZE()
  mwifiex: drop 'add_tail' param from mwifiex_insert_cmd_to_pending_q()
  mwifiex: pcie: remove unnecessary masks
  mwifiex: pcie: unify MSI-X / non-MSI-X interrupt process
  mwifiex: debugfs: allow card_reset() to cancel things
  mwifiex: pcie: disable device DMA before unmapping/freeing buffers
  mwifiex: pcie: remove unnecessary 'pdev' check
  mwifiex: keep mwifiex_cancel_pending_ioctl() static
  mwifiex: drop num CPU notice

 drivers/net/wireless/marvell/mwifiex/cfg80211.c|   4 -
 drivers/net/wireless/marvell/mwifiex/cfp.c |   4 +-
 drivers/net/wireless/marvell/mwifiex/cmdevt.c  |  15 +--
 drivers/net/wireless/marvell/mwifiex/debugfs.c |   2 -
 drivers/net/wireless/marvell/mwifiex/init.c|  32 ++
 drivers/net/wireless/marvell/mwifiex/main.c| 124 +++--
 drivers/net/wireless/marvell/mwifiex/main.h|   7 +-
 drivers/net/wireless/marvell/mwifiex/pcie.c| 100 +++--
 drivers/net/wireless/marvell/mwifiex/scan.c|   5 +-
 drivers/net/wireless/marvell/mwifiex/sta_cmd.c |   8 +-
 drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c |   5 +-
 drivers/net/wireless/marvell/mwifiex/sta_ioctl.c   |   6 +-
 12 files changed, 87 insertions(+), 225 deletions(-)

-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH] mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in aggr_ctrl module parameter
message text.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/marvell/mwifiex/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index f2600b827e81..ebe2c9319948 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -46,7 +46,7 @@ MODULE_PARM_DESC(mfg_mode, "manufacturing mode enable:1, 
disable:0");
 
 bool aggr_ctrl;
 module_param(aggr_ctrl, bool, );
-MODULE_PARM_DESC(aggr_ctrl, "usb tx aggreataon enable:1, disable:0");
+MODULE_PARM_DESC(aggr_ctrl, "usb tx aggregation enable:1, disable:0");
 
 /*
  * This function registers the device and performs all the necessary
-- 
2.11.0

Re: pull-request: wireless-drivers 2017-07-21

[David Miller]

From: Kalle Valo 
Date: Fri, 21 Jul 2017 19:12:54 +0300

> important fixes for net which had accumulated while I was away. I only
> applied the brcmfmac and rtlwifi patches only eight hours ago and I
> haven't seen the kbuild report yet so they might have some build
> breakage in theory. But the patches are so small so the chances that
> they would break something are really small and so I send this to you
> already now to not delay them any longer.
> 
> Please let me know if there are any problems.

Welcome back, pulled, thanks.

Re: PATCH v3 brcmfmac driver cleanup

[Arend van Spriel]

On 19-07-17 21:07, Ian Molton wrote:
> Hi all,
> 
> Please find the 3rd revision of my cleanup patchset for brcmfmac.
> 
> I've done some further cleanup and it now handles SDIO the ay the MMC 
> subsystem
> was designed to.
> 
> I've also taken the liberty of greatly reducing the amount of indirection
> used thoughout the SDIO code, which I think has improved readability quite a
> lot.
> 
> Hope this finds you all well.

After only one week of vacation there was quite some catching up to do.
So I decided to get an easy start and run 'checkpatch.pl --strict' over
the series. Attached the output of that. Might be stuff that was already
wrong before. I did only a quick check on patch 1/34 and it is really
introduced by that patch. So can you please check the output.

FWIW, I tend to ignore the warning about block comments, ie.:

/*
 * bla
 */

is fine by me. At least I prefer it over:

/* bla
 */

Regards,
Arend
branch: fmac-molton-patches
checking patch: a6d80ee brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
WARNING: line over 80 characters
#24: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:233:
+static inline int brcmf_sdiod_f0_writeb(struct sdio_func *func, u8 byte, uint 
regaddr)

WARNING: line over 80 characters
#34: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:271:
+   ret = brcmf_sdiod_f0_writeb(func, *(u8 *)data, 
addr);

total: 0 errors, 2 warnings, 0 checks, 18 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

Your patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.
checking patch: f86e392 brcmfmac: Register sizes on hardware are not dependent 
on compiler types
total: 0 errors, 0 warnings, 0 checks, 79 lines checked

Your patch has no obvious style problems and is ready for submission.
checking patch: 700bd76 brcmfmac: Split brcmf_sdiod_regrw_helper() up.
CHECK: Alignment should match open parenthesis
#28: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:304:
+static int brcmf_sdiod_reg_write(struct brcmf_sdio_dev *sdiodev, u32 addr,
+  u8 regsz, void *data)

CHECK: braces {} should be used on all arms of this statement
#48: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:335:
+   if (ret == -ENOMEDIUM)
[...]
+   else if (ret != 0) {
[...]

WARNING: networking block comments don't use an empty /* line, use /* Comment...
#52: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:339:
+   /*
+* SleepCSR register access can fail when

CHECK: Alignment should match open parenthesis
#68: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:355:
+static int brcmf_sdiod_reg_read(struct brcmf_sdio_dev *sdiodev, u32 addr,
+  u8 regsz, void *data)

WARNING: networking block comments don't use an empty /* line, use /* Comment...
#78: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:365:
+   /*
+* figure out how to read the register based on address range

CHECK: Alignment should match open parenthesis
#128: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:422:
+   brcmf_sdiod_regwb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i, addr[i],
+   );

total: 0 errors, 2 warnings, 4 checks, 151 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

Your patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.
checking patch: cc14ab9 brcmfmac: Clean up brcmf_sdiod_set_sbaddr_window()
ERROR: space prohibited after that open parenthesis '('
#39: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:418:
+   for ( i = 0 ; i < 3 && !err ; i++, addr >>= 8 )

ERROR: space prohibited before that close parenthesis ')'
#39: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:418:
+   for ( i = 0 ; i < 3 && !err ; i++, addr >>= 8 )

WARNING: line over 80 characters
#40: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:419:
+   brcmf_sdiod_regwb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i, addr & 
0xff,

CHECK: Alignment should match open parenthesis
#41: FILE: drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c:420:
+   brcmf_sdiod_regwb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i, addr & 
0xff,
);

total: 2 errors, 1 warnings, 1 checks, 36 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

Re: [PATCH] dt-bindings: add device tree binding for Allwinner XR819 SDIO Wi-Fi

[Rob Herring]

On Tue, Jul 18, 2017 at 03:29:40PM +0800, Icenowy Zheng wrote:
> Allwinner XR819 is a SDIO Wi-Fi chip, which has the functionality to use
> an out-of-band interrupt pin instead of SDIO in-band interrupt.
> 
> Add the device tree binding of this chip, in order to make it possible
> to add this interrupt pin to device trees.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  .../bindings/net/wireless/allwinner,xr819.txt  | 37 
> ++
>  1 file changed, 37 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt 
> b/Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
> new file mode 100644
> index ..64dd9c1c0584
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/allwinner,xr819.txt
> @@ -0,0 +1,37 @@
> +Allwinner XRadio wireless SDIO devices
> +
> +This node provides properties for controlling the XRadio wireless device. The
> +node is expected to be specified as a child node to the SDIO controller that
> +connects the device to the system.
> +
> +Required properties:
> +
> + - compatible : Should be "allwinner,xr819".

reg is also required.

> +
> +Optional properties:
> + - interrupt-parent : the phandle for the interrupt controller to which the
> + device interrupts are connected.
> + - interrupts : specifies attributes for the out-of-band interrupt 
> (host-wake).
> + When not specified the device will use in-band SDIO interrupts.
> +
> +Example:
> +
> +mmc1: mmc@01c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_a>;
> + vmmc-supply = <_vcc_wifi>;
> + mmc-pwrseq = <_pwrseq>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";

Don't show status in examples.

> +
> + xr819: sdio_wifi@1 {

wifi@1

> + reg = <1>;
> + compatible = "allwinner,xr819";
> + interrupt-parent = <>;
> + interrupts = <6 10 IRQ_TYPE_EDGE_RISING>;
> + };
> +};
> -- 
> 2.13.0
> 

[PATCH] qtfnmac: Tidy up DMA mask setting

[Robin Murphy]

As the only caller of dma_supported() outside of DMA API internals, the
qtfnmac driver stands out and invites scrutiny. Thankfully, it's not
being used for evil, but it is entirely redundant, since it open-codes a
check that the DMA mask setting functions are going to perform anyway.
In fact, the whole qtnf_pcie_init_dma_mask() function is nothing more
than a rather long-winded implementation of dma_set_mask_and_coherent(),
so let's just use that directly.

Signed-off-by: Robin Murphy 
---
 .../net/wireless/quantenna/qtnfmac/pearl/pcie.c| 28 +-
 1 file changed, 1 insertion(+), 27 deletions(-)

diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c 
b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index 7fc4f0d6a9ad..2c065ffda070 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -274,32 +274,6 @@ static int qtnf_pcie_init_memory(struct qtnf_pcie_bus_priv 
*priv)
return 0;
 }
 
-static int
-qtnf_pcie_init_dma_mask(struct qtnf_pcie_bus_priv *priv, u64 dma_mask)
-{
-   int ret;
-
-   ret = dma_supported(>pdev->dev, dma_mask);
-   if (!ret) {
-   pr_err("DMA mask %llu not supported\n", dma_mask);
-   return ret;
-   }
-
-   ret = pci_set_dma_mask(priv->pdev, dma_mask);
-   if (ret) {
-   pr_err("failed to set DMA mask %llu\n", dma_mask);
-   return ret;
-   }
-
-   ret = pci_set_consistent_dma_mask(priv->pdev, dma_mask);
-   if (ret) {
-   pr_err("failed to set consistent DMA mask %llu\n", dma_mask);
-   return ret;
-   }
-
-   return ret;
-}
-
 static void qtnf_tune_pcie_mps(struct qtnf_pcie_bus_priv *priv)
 {
struct pci_dev *pdev = priv->pdev;
@@ -1212,7 +1186,7 @@ static int qtnf_pcie_probe(struct pci_dev *pdev, const 
struct pci_device_id *id)
goto err_base;
}
 
-   ret = qtnf_pcie_init_dma_mask(pcie_priv, DMA_BIT_MASK(32));
+   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
if (ret) {
pr_err("PCIE DMA mask init failed\n");
goto err_base;
-- 
2.12.2.dirty

Re: [PATCH v1 5/6] uuid: Kill uapi/uuid.h

[Christoph Hellwig]

> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index 29d6699d5a06..1c68709123aa 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -36,7 +36,7 @@ typedef uint16_t__u16;
>  typedef unsigned char__u8;
>  typedef struct {
>   __u8 b[16];
> -} uuid_le;
> +} guid_t;
>  
>  /* Big exception to the "don't include kernel headers into userspace, which
>   * even potentially has different endianness and word sizes, since
> @@ -134,7 +134,7 @@ static inline void add_wildcard(char *str)
>   strcat(str + len, "*");
>  }
>  
> -static inline void add_uuid(char *str, uuid_le uuid)
> +static inline void add_uuid(char *str, guid_t uuid)
>  {
>   int len = strlen(str);

This should probably be split into a separate patch.

Re: [PATCH v1 4/6] vmbus: Switch to use new generic UUID API

[Christoph Hellwig]

On Wed, Jul 19, 2017 at 09:28:55PM +0300, Andy Shevchenko wrote:
> There are new types and helpers that are supposed to be used in new code.
> 
> As a preparation to get rid of legacy types and API functions do
> the conversion here.

Can you split the uapi changes into a separate patch?

I'd love to kill the guid_le userspace exposure, but I'd also like to
see how current userspace uses them.  Obviously your change is not
a break in the ABI, but it is a break in the API.  I would prefer if
we could not expose it, but I'd like to hear feedback from the consumers
of these UAPI headers - the fields aren't used in kernel space at all,
but userspace might be using it, and we'll need to look into alternatives
for it.

Re: brcfmac: add possibility to turn off powersave on wiphy

[Dan Williams]

On Fri, 2017-07-21 at 23:19 +0200, Rafal wrote:
> On Fri, 21 Jul 2017, Dan Williams wrote:
> 
> > On Fri, 2017-07-21 at 16:56 +0200, Rafal wrote:
> > > I have a board with ap6212 chip and I have encountered two
> > > problems
> > > with the brcmfmac driver operating with this device. First
> > > problem I
> > > describe below, second one in separate mail.
> > > 
> > > 
> > > Namely, I have noticed quite poor connection with the device
> > > despite
> > > good signal strength. Ping to the device was very uneven, about
> > > 50 -
> > > 100 ms in average, 10 - 20% of packets loss. After some
> > > investigations I have found that problem is caused by powersave
> > > feature on wiphy (BRCMF_C_SET_PM command). When the value is set
> > > to
> > > PM_OFF, the problem does not appear - ping is quite stable, ~2ms.
> > > When set to PM_FAST, the ping is bad.
> > > 
> > > The brcmfmac driver currently does not have possibility to turn
> > > off
> > > the powersave feature. I have added the possibility on 4.11.6
> > > kernel
> > 
> > I don't think that's true?  The driver implements the nl80211
> > set_power_mgmt hook, which lets you turn off powersave with
> > 'iw'.  That
> > seems like a much better option than a module parameter.  I know
> > other
> > drivers have the module parameter, but I personally consider that
> > legacy/holdover, given that we have runtime toggles for this kind
> > of
> > thing.
> > 
> > brcmf_cfg80211_set_power_mgmt() should do what you need, right?
> 
> Yes, it does.
> 
> In fact, I needed only a parameter in OF database. This is a bug in
> the
> device or firmware and I needed to disable the feature for this chip.
> Many device drivers allow to specify in OF database that driver
> should
> use a quirk. This is similar situation.

Does the power management issue cause problems before any association
happens?  If not, then I'd suggest 'iw' in startup scripts somewhere. 
Or better yet, use the normal quirk method of detecting the hardware
version via IDs or detecting the firmware via version or feature
strings and quirking on that.

Dan

> I have added the kernel parameter as an additional feature. I thought
> that not all platforms are using devicetree database. But maybe it is
> a
> bad idea.
> 
> Rafal
> 
> > 
> > Dan
> > 

Re: [PATCH] iwlwifi: Demote messages about fw flags size to info

[Coelho, Luciano]

On Fri, 2017-07-21 at 07:51 -0700, João Paulo Rechi Vita wrote:
> These messages are not reporting a real error, just the fact that the
> firmware knows about more flags then the driver.
> 
> Currently these messages are presented to the user during boot if there
> is no bootsplash covering the console, sometimes even if the boot splash
> is enabled but has not started yet by the time this message is shown.
> 
> Demoting it to the info level helps having a clean boot process.
> 
> Signed-off-by: João Paulo Rechi Vita 
> ---

The idea with this error is that if the firmware is too new and includes
a TLV that we are not aware of, there can be unexpected issues.  For
instance, sometimes the FW API changes some of its structures and we use
TLVs to know which one to use.  If a new struct is in use by the
firmware but not by the driver, problems will occur.

Recently we accidentally omitted one TLV from the driver and released a
new firmware that had it set... That's the error you are currently
seeing.  We have a bugzilla entry[1] and it is fixed in our internal
tree.  The fix will be sent upstream in the next -fixes round we send
out.

This specific case is harmless, but I'd rather keep this message as an
error, because in other situations it could lead to unexpected
behavioir, so I prefer to keep it very visible.


[1] https://bugzilla.kernel.org/show_bug.cgi?id=196195

--
Cheers,
Luca.

[PATCH] ath10k: Make ath10k report discarded packets to mac80211

[Ignacio Núñez Hernanz]

From 2caef0e851a23cc9e979a3f36a2ae0d964cfeba7 Mon Sep 17 00:00:00 2001
From: Ignacio Nunez Hernanz 
Date: Mon, 24 Jul 2017 11:52:48 +0200
Subject: [PATCH] ath10k: Make ath10k report discarded packets to mac80211

Whenever ath10k firmware discards a packet (HTT_TX_COMPL_STATE_DISCARD
flag), the skb is freed and mac80211 does not get feedback through
ieee80211_tx_status().

Instead, make sure that the IEEE80211_TX_STAT_ACK flag is disabled and
let the packet go through, like ath9k does.

Signed-off-by: Ignacio Nunez Hernanz 
---
 drivers/net/wireless/ath/ath10k/txrx.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/txrx.c 
b/drivers/net/wireless/ath/ath10k/txrx.c

index d4986f626c35..37537530de76 100644
--- a/drivers/net/wireless/ath/ath10k/txrx.c
+++ b/drivers/net/wireless/ath/ath10k/txrx.c
@@ -102,11 +102,6 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
 memset(>status, 0, sizeof(info->status));
 trace_ath10k_txrx_tx_unref(ar, tx_done->msdu_id);

-if (tx_done->status == HTT_TX_COMPL_STATE_DISCARD) {
-ieee80211_free_txskb(htt->ar->hw, msdu);
-return 0;
-}
-
 if (!(info->flags & IEEE80211_TX_CTL_NO_ACK))
 info->flags |= IEEE80211_TX_STAT_ACK;

@@ -117,6 +112,13 @@ int ath10k_txrx_tx_unref(struct ath10k_htt *htt,
 (info->flags & IEEE80211_TX_CTL_NO_ACK))
 info->flags |= IEEE80211_TX_STAT_NOACK_TRANSMITTED;

+if (tx_done->status == HTT_TX_COMPL_STATE_DISCARD) {
+  if (info->flags & IEEE80211_TX_CTL_NO_ACK)
+info->flags &= ~IEEE80211_TX_STAT_NOACK_TRANSMITTED;
+  else
+info->flags &= ~IEEE80211_TX_STAT_ACK;
+}
+
 ieee80211_tx_status(htt->ar->hw, msdu);
 /* we do not own the msdu anymore */

--
2.13.1

Re: WARN_ON_ONCE(work > weight) in napi_poll()

[Andrey Ryabinin]

On 07/18/2017 09:47 AM, Ryan Hsu wrote:
> On 07/11/2017 06:19 PM, Igor Mitsyanko wrote:
> 
>> On 07/11/2017 10:28 AM, Andrey Ryabinin wrote:
>>>
>>> It gave me this:
>>>
>>> [118648.825347] #1 quota too big 72 64 16
>>> [118648.825351] #2 quota too big 72 64 16
>>> [118648.825471] [ cut here ]
>>> [118648.825484] WARNING: CPU: 0 PID: 0 at ../net/core/dev.c:5274 
>>> net_rx_action+0x258/0x360
>>>
>>> So this means that we didn't met the condition bellow, i.e. 
>>> skb_queue_empty() returned true.
>>>
>>>  ath10k_htt_txrx_compl_task():
>>>
>>>  if ((quota > ATH10K_NAPI_QUOTA_LIMIT) &&
>>>  !skb_queue_empty(>rx_in_ord_compl_q)) {
>>>  resched_napi = true;
>>>  goto exit;
>>>  }
>>>
 Also WLAN.RM.2.0-00180-QCARMSWPZ-1 firmware is a bit old, could you also 
 update firmware to give it a try?
 https://github.com/kvalo/ath10k-firmware/tree/master/QCA6174/hw3.0/4.4

>>>
>>> Will try.
>>>
>>
>> Maybe ath10k_htt_rx_in_ord_ind() has to accept "budget_left" parameter and 
>> use it to limit number of processed MSDUs in queued AMSDU and saving rest 
>> for later (NAPI has to be rescheduled in this case).
>> It seems natural that this problem happens with current logic, in case AMSDU 
>> in Rx queue has more elements then left in budget.
> 
> Thanks, likely in current logic, it does have chance to exceed the budget 
> while dequeuing from the last list.
> 
> Can you give it a try this one? for QCA6174 reorder is offload, so this 
> should be good enough for your case to test, will have to check non-offload 
> reorder case... but let me know if you're seeing something different
> 

I've been running with this patch almost a week and haven't seen the WARNING. 
One week is usually enough to trigger it several times.
I guess we can assume that the patch fixed the problem.

[PATCH] ath9k: fix more-data flag for buffered multicast packets

[Felix Fietkau]

The flag needs to be cleared for the last packet in the list, not the
first one. Fixes some issues with multicast packet loss for powersave
clients connected to an ath9k AP.

Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/ath/ath9k/xmit.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 30efe79e9d89..2f663e19f2b9 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2451,7 +2451,6 @@ void ath_tx_cabq(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
.txq = sc->beacon.cabq
};
struct ath_tx_info info = {};
-   struct ieee80211_hdr *hdr;
struct ath_buf *bf_tail = NULL;
struct ath_buf *bf;
LIST_HEAD(bf_q);
@@ -2495,14 +2494,8 @@ void ath_tx_cabq(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
if (list_empty(_q))
return;
 
-   bf = list_first_entry(_q, struct ath_buf, list);
-   hdr = (struct ieee80211_hdr *) bf->bf_mpdu->data;
-
-   if (hdr->frame_control & cpu_to_le16(IEEE80211_FCTL_MOREDATA)) {
-   hdr->frame_control &= ~cpu_to_le16(IEEE80211_FCTL_MOREDATA);
-   dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
-   sizeof(*hdr), DMA_TO_DEVICE);
-   }
+   bf = list_last_entry(_q, struct ath_buf, list);
+   ath9k_set_moredata(sc, bf, false);
 
ath_txq_lock(sc, txctl.txq);
ath_tx_fill_desc(sc, bf, txctl.txq, 0);
-- 
2.13.0

Re: brcm43430 sdio wifi regression with 4.13-rc1

[James Hughes]

On 23 July 2017 at 08:08, Hans de Goede  wrote:
> Hi,
>
> On 22-07-17 21:53, Arend van Spriel wrote:
>>
>> On 22-07-17 21:19, Ian Molton wrote:
>>>
>>> On 22/07/17 20:18, Ian Molton wrote:

 On 22/07/17 19:43, Hans de Goede wrote:
>
> Hi,
>
> When upgrading my devel environment to 4.13-rc1+ I noticed that
> the brcm43430 sdio wifi on a Chuwi Hi8 plus stopped working:


 There is a fix for this:

 https://patchwork.kernel.org/patch/9836383/
>>>
>>>
>>> Sorry, ignore me - this was a fix for the other 4.13-rc1 regression.
>>> Arend is looking into he other one. It affects me too.
>>>
>>> It appears to be the firmware going astray.
>>
>>
>> It is still an enigma although admittedly I did not put much time in it
>> this week. The change below fixes it as the device goes haywire from
>> this command. At least this was reported by Stefan Wahren ("brcmfmac:
>> BCM43431 won't get probed on Raspberry Pi Zero W") on linux-wireless
>> mailing list. Still I can not explain it. Could be that there is not
>> enough free memory on the device.
>
>
> As mentioned in my original mail, switching firmware version seems to
> fix this. linux-firmware has:
>
> [hans@shalem ~]$ strings
> brcm-firmware/brcmfmac43430-sdio.bin.7.45.41.26.ucode1043.2060 | tail -n1
> 43430a1-roml/sdio-g-p2p-pool-pno-pktfilter-keepalive-aoe-mchan-tdls-proptxstatus-ampduhostreorder-lpc-sr-bcmcps
> Version: 7.45.41.26 CRC: a75d4f1b Date: Mon 2016-08-29 20:53:22 CEST Ucode
> Ver: 1043.2060 FWID: 01-4527cfab
>
> Where as this one (from the android image on the tablet) does work:
>
> [hans@shalem ~]$ strings
> brcm-firmware/brcmfmac43430-sdio.bin.7.45.77.0.ucode1043.2054 | tail -n1
> 43430a1-roml/sdio-g-pool-p2p-pno-pktfilter-keepalive-aoe-mchan-proptxstatus-ampduhostreorder-lpc-wl11u-rcc-fmc-wepso-okc-anqpo-11nprop-ndoe-tdls-hs20sta-clm_4335_ss-hwapwar-ivwar-srfast
> Version: 7.45.77.0 CRC: c1a399d4 Date: Wed 2016-03-30 11:31:45 CST Ucode
> Ver: 1043.2054 FWID: 01-ee8a6268
>
> Here: https://www.spinics.net/lists/linux-wireless/msg164304.html
> you write that the firmware in linux-firmware does not have the
> gscan feature, the check for which is causing the issue, enabled,
> could it be the other firmware build does have it enabled? It does seem
> to have a bunch of extra things enabled. Maybe there simply is an error
> in the error-handling in the firmware when it is disabled ?
>
> I've put all firmware versions I have here:
>
> http://jwrdegoede.danny.cz/brcm-firmware/
>
> Regards,
>
> Hans
>
>
>
>
>>
>> Regards,
>> Arend
>> ---
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
>> index d21258d..def120c 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
>> @@ -159,8 +159,9 @@ void brcmf_feat_attach(struct brcmf_pub *drvr)
>>
>>  brcmf_feat_firmware_capabilities(ifp);
>>  memset(_cfg, 0, sizeof(gscan_cfg));
>> -   brcmf_feat_iovar_data_set(ifp, BRCMF_FEAT_GSCAN, "pfn_gscan_cfg",
>> - _cfg, sizeof(gscan_cfg));
>> +   if (drvr->bus_if->chip != BRCM_CC_43430_CHIP_ID)
>> +   brcmf_feat_iovar_data_set(ifp, BRCMF_FEAT_GSCAN,
>> "pfn_gscan_cfg",
>> + _cfg, sizeof(gscan_cfg));
>>  brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_PNO, "pfn");
>>  if (drvr->bus_if->wowl_supported)
>>  brcmf_feat_iovar_int_get(ifp, BRCMF_FEAT_WOWL, "wowl");
>>
>

May or may not be useful, but we have just had a bug report on
Raspberry Pi that is filled with these mailbox messages. Don't seem to
be related to this scan issue, but the mailbox error is the same. I am
not enough of an expert on Wifi to really comment, or see whether this
patch would help.

https://www.raspberrypi.org/forums/viewtopic.php?f=28=189046

Re: Madwifi porting to Ath9k

[Oleksij Rempel]

Am 24.07.2017 um 08:08 schrieb Arul jothi:
> Hi Oleksij,
> 
>Thanks for your reply. I am new to the linux wireless.
> Does ath9k has support for PCF implementation ? I couldn't find any
> reference about PCF in ath9k.
> 
> Do you mean porting madwifi code to ath9k is straight forward ?.
> Please give some link or guideliness.

- Isolate PCF code in Madwifi
- port it to the ath9k if possible
- do lots of testing
- send patches for review.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: Madwifi porting to Ath9k

[Arul jothi]

Hi Oleksij,

   Thanks for your reply. I am new to the linux wireless.
Does ath9k has support for PCF implementation ? I couldn't find any
reference about PCF in ath9k.

Do you mean porting madwifi code to ath9k is straight forward ?.
Please give some link or guideliness.

Regards,
Arul.

On Mon, Jul 24, 2017 at 2:01 PM, Oleksij Rempel  wrote:
> Am 23.07.2017 um 15:54 schrieb Arul jothi:
>> Hi,
>>
>>   I have AR7161 based board which is using customized madwifi driver
>> with PCF implementation.
>> I need to port the driver to new board based on AR9344.
>> What should be the approach I should take
>>
>> 1.   Build Madwifi with current AR9344 Openwrt build
>>
>> 2.   Implement PCF with current Ath9k driver.
>>
>>
>> Please advise which approach I should take. Can someone help me with
>> some clue on that.
>> Thanks in advance.
>
> In long term it is preferable to extend upstream version of the driver
> (ath9k) aaand upstream you patches as well.
>
> ath9k has big developer community and good testing coverage.
>
> --
> Regards,
> Oleksij
>

Re: Madwifi porting to Ath9k

[Oleksij Rempel]

Am 23.07.2017 um 15:54 schrieb Arul jothi:
> Hi,
> 
>   I have AR7161 based board which is using customized madwifi driver
> with PCF implementation.
> I need to port the driver to new board based on AR9344.
> What should be the approach I should take
> 
> 1.   Build Madwifi with current AR9344 Openwrt build
> 
> 2.   Implement PCF with current Ath9k driver.
> 
> 
> Please advise which approach I should take. Can someone help me with
> some clue on that.
> Thanks in advance.

In long term it is preferable to extend upstream version of the driver
(ath9k) aaand upstream you patches as well.

ath9k has big developer community and good testing coverage.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature