[linux-stable] 4fc2942b6e kernel BUG at kernel/time/hrtimer.c:109!

[kernel test robot]

Hi Marc,

We find this oops in linux-4.4.y. The gcc-6 compiled mainline kernel is fine.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.4.y

commit 4fc2942b6e2de2efc8a9d3784d4b0d3543149613
Author: Marc Zyngier 
AuthorDate: Fri Jan 15 17:41:09 2016 +
Commit: Greg Kroah-Hartman 
CommitDate: Thu Sep 15 08:27:44 2016 +0200

 hrtimer: Catch illegal clockids
 
 [ Upstream commit 9006a01829a50cfd6bbd4980910ed46e895e93d7 ]
 
 It is way too easy to take any random clockid and feed it to
 the hrtimer subsystem. At best, it gets mapped to a monotonic
 base, but it would be better to just catch illegal values as
 early as possible.
 
 This patch does exactly that, mapping illegal clockids to an
 illegal base index, and panicing when we detect the illegal
 condition.
 
 Signed-off-by: Marc Zyngier 
 Cc: Tomasz Nowicki 
 Cc: Christoffer Dall 
 Link: 
http://lkml.kernel.org/r/1452879670-16133-3-git-send-email-marc.zyng...@arm.com
 Signed-off-by: Thomas Gleixner 
 Signed-off-by: Sasha Levin 
 Signed-off-by: Greg Kroah-Hartman 

+-++++
| | 8a840b7f37 | 4fc2942b6e 
| e30ab9304d |
+-++++
| boot_successes  | 63 | 0  
| 0  |
| boot_failures   | 0  | 22 
| 19 |
| kernel_BUG_at_kernel/time/hrtimer.c | 0  | 22 
| 19 |
| invalid_opcode:#[##]| 0  | 22 
| 19 |
| invalid_opcode:#[##]DEBUG_PAGEALLOC_DEBUG_PAGEALLOC | 0  | 22 
| 19 |
| RIP:hrtimer_init| 0  | 22 
| 19 |
| calltrace:init_mac80211_hwsim   | 0  | 22 
| 19 |
| Kernel_panic-not_syncing:Fatal_exception| 0  | 22 
| 19 |
+-++++

[   38.061932] ieee80211 phy0: hwaddr 02:00:00:00:00:00 registered
[   38.063663] [ cut here ]
[   38.063663] [ cut here ]
[   38.064964] kernel BUG at kernel/time/hrtimer.c:109!
[   38.064964] kernel BUG at kernel/time/hrtimer.c:109!
[   38.066793] invalid opcode:  [#1] 
[   38.066793] invalid opcode:  [#1] DEBUG_PAGEALLOC DEBUG_PAGEALLOC 

[   38.068273] CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.20-00072-g4fc2942 #10
[   38.068273] CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.20-00072-g4fc2942 #10
[   38.070239] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   38.070239] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   38.073047] task: 8805c000 ti: 8806 task.ti: 
8806
[   38.073047] task: 8805c000 ti: 8806 task.ti: 
8806
[   38.075115] RIP: 0010:[] 
[   38.075115] RIP: 0010:[]  [] 
hrtimer_init+0x2a/0x41
  [] hrtimer_init+0x2a/0x41
[   38.077344] RSP: 0018:88063d98  EFLAGS: 00010246
[   38.077344] RSP: 0018:88063d98  EFLAGS: 00010246
[   38.078821] RAX: 0004 RBX: 88001d2a7498 RCX: 
[   38.078821] RAX: 0004 RBX: 88001d2a7498 RCX: 
[   38.080782] RDX:  RSI: 0004 RDI: 88001d2a74d8
[   38.080782] RDX:  RSI: 0004 RDI: 88001d2a74d8
[   38.082755] RBP: 88063d98 R08: 88001d2a7498 R09: 
[   38.082755] RBP: 88063d98 R08: 88001d2a7498 R09: 
[   38.084714] R10: 88001d295e68 R11: 83e1dc08 R12: 81c740e1
[   38.084714] R10: 88001d295e68 R11: 83e1dc08 R12: 81c740e1
[   38.086674] R13: 88063e38 R14:  R15: 
[   38.086674] R13: 88063e38 R14:  R15: 
[   38.088647] FS:  () GS:82c21000() 
knlGS:
[   38.088647] FS:  () GS:82c21000() 
knlGS:
[   38.090864] CS:  0010 DS:  ES:  CR0: 80050033
[   38.090864] CS:  0010 DS:  ES:  CR0: 80050033
[   38.092438] CR2: 7fa2354bb8ec CR3: 1d8ba000 CR4: 001406f0
[   38.092438] CR2: 7fa2354bb8ec CR3: 1d8ba000 CR4: 001406f0
[   

[RFC 2/5] iwlwifi: fix request_module() use

[Luis R. Rodriguez]

The return value of request_module() being 0 does not mean that the
driver which was requested has loaded. To properly check that the driver
was loaded each driver can use internal mechanisms to vet the driver is
now present. The helper try_then_request_module() was added to help with
this, allowing drivers to specify their own validation as the first
argument.

On iwlwifi the use case is a bit more complicated given that the value
we need to check for is protected with a mutex later used on the
module_init() of the module we are asking for. If we were to lock and
request_module() we'd deadlock. iwlwifi needs its own wrapper then so
it can handle its special locking requirements.

Signed-off-by: Luis R. Rodriguez 
---
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 34 
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index e198d6f5fcea..6beb92d19ea7 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1231,6 +1231,29 @@ static void _iwl_op_mode_stop(struct iwl_drv *drv)
}
 }
 
+static void iwlwifi_try_load_op(struct iwlwifi_opmode_table *op,
+   struct iwl_drv *drv)
+{
+   int ret = 0;
+
+   ret = request_module("%s", op->name);
+   if (ret)
+   goto out;
+
+   mutex_lock(_opmode_table_mtx);
+   if (!op->ops)
+   ret = -ENOENT;
+   mutex_unlock(_opmode_table_mtx);
+
+out:
+#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
+   if (ret)
+   IWL_ERR(drv,
+   "failed to load module %s (error %d), is dynamic 
loading enabled?\n",
+   op->name, ret);
+#endif
+}
+
 /**
  * iwl_req_fw_callback - callback when firmware was loaded
  *
@@ -1471,15 +1494,8 @@ static void iwl_req_fw_callback(const struct firmware 
*ucode_raw, void *context)
 * else from proceeding if the module fails to load
 * or hangs loading.
 */
-   if (load_module) {
-   err = request_module("%s", op->name);
-#ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
-   if (err)
-   IWL_ERR(drv,
-   "failed to load module %s (error %d), is 
dynamic loading enabled?\n",
-   op->name, err);
-#endif
-   }
+   if (load_module)
+   iwlwifi_try_load_op(op, drv);
goto free;
 
  try_again:
-- 
2.11.0

[RFC 0/5] iwlwifi: enhance final opmode work

[Luis R. Rodriguez]

Although these are iwlwifi patches, there are some core module, async,
firmware questions I'd appreciate a bit more review from folks on -- tx!

Firmware folks / async folks / module folks:

I started to look to generalize the way the iwlwifi driver uses the
firmware API to request for firmware through a series of API versions,
to chain firmware requests. I had to start examining its firmware
callback carefully as it used request_module() and because the driver
data API [0] (an evolution of the firmware API) I've been developing
uses async_schedule() instead of workqueues. Although I had started
using workqueues to match the old firmware API I went with
async_schedule() since I noticed most drivers using an async callback
also had to add a completion struct on their drivers and later waited
for completion at some other point. Using async framework we can just
give users a cookie, and they can use that to sync for completion.

One of the limitations of using async_schedule() though is we cannot
request_module() synchronously on async calls given that the module
initialization code will call async_synchronize_full() if the module
being initialized happened to have used async work on its initialization
routine, otherwise we'd deadlock.

So, I either I change back to workqueus or we live happy with either:

   a) Use request_module_nowait() on async calls -- this works
   b) If you need request_module() on your async call, consider a
  workqueue

Module folks:

One of the issues with a) is that contrary to try_then_request_module()
which helps validate module loading we have had no common generic
lightweight form to validate a module loaded correctly if you use
request_module_nowait(). You can surely use a module notifier with
register_module_notifier() -- but again, that is not lightweight, quick
and easy. From the look of it though, most current users simply call
request_module_nowait() and hope for the best -- there are no verifiers.
That's probably fine (?) -- other than failures can be silent. At least
iwlwifi would want to make a beep about failures it seems, so I went
with b).

In this series I went with b) but still note that iwlwifi cannot use
bare try_then_request_module() cleanly -- so it has its own wrapper (see
patch 02).

iwlfifi folks:

This patch series does not depend on the driver data API, but its is an
example of b). It also contains a series of other fixes and enhancements
for iwlwifi's opmode final work worth revising -- regardless of what
happens with the driver data API. With these patches average boot time
seems to improve slightly, but I'd expect much more testing would be
required before making any clear determination. I used 5 boots per patch.
I started with next-20170213. Following data is average boot times as
per systemd-analyze. The vanilla kernel (patch-00) got more testing as
I'm also using this a base for other testing -- 100 boots.

patch-00 Startup finished in  2.64057s (kernel) +  5.52668s (initrd) +  
11.3024s (userspace) =  19.4707s
patch-01 Startup finished in2.574s (kernel) +   5.1505s (initrd) +  
11.0698s (userspace) =  18.7952s
patch-02 Startup finished in2.618s (kernel) +   5.3102s (initrd) +  
11.1736s (userspace) =  19.1026s
patch-03 Startup finished in   2.5612s (kernel) +   5.3274s (initrd) +  
11.0226s (userspace) =  18.9122s
patch-04 Startup finished in   2.5475s (kernel) +   5.0895s (initrd) +  
10.9272s (userspace) =  18.5652s

[0] 
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170206-driver-data-try2

Luis R. Rodriguez (5):
  iwlwifi: fix drv cleanup on opmode registration failure
  iwlwifi: fix request_module() use
  iwlwifi: share opmode start work code
  iwlwifi: move opmode loading to shared routine
  iwlwifi: convert final opmode work into a workqueue

 drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 140 +++
 1 file changed, 100 insertions(+), 40 deletions(-)

-- 
2.11.0

[RFC 5/5] iwlwifi: convert final opmode work into a workqueue

[Luis R. Rodriguez]

This lets us offload and share all the final opmode related work
necessary for either an opmode driver or new device. This has the most
impact for opmode drivers as this now offloads opmode start for each
device onto the workqueue.

Signed-off-by: Luis R. Rodriguez 
---
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index 6cfbc3c6e0d6..d39a5c73afdc 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -145,6 +145,8 @@ static struct iwlwifi_opmode_table {
[DVM_OP_MODE] = { .name = "iwldvm", .ops = NULL },
[MVM_OP_MODE] = { .name = "iwlmvm", .ops = NULL },
 };
+static void iwlwifi_opmode_dowork(struct work_struct *work);
+static DECLARE_WORK(iwlwifi_opmode_work, iwlwifi_opmode_dowork);
 
 #define IWL_DEFAULT_SCAN_CHANNELS 40
 
@@ -1291,7 +1293,7 @@ static void iwlwifi_opmode_start(struct 
iwlwifi_opmode_table *op)
iwlwifi_opmode_start_drv(op, drv);
 }
 
-static void iwlwifi_opmode_dowork(void)
+static void iwlwifi_opmode_dowork(struct work_struct *unused_work)
 {
unsigned int i;
struct iwlwifi_opmode_table *op;
@@ -1530,7 +1532,7 @@ static void iwl_req_fw_callback(const struct firmware 
*ucode_raw, void *context)
 
mutex_unlock(_opmode_table_mtx);
 
-   iwlwifi_opmode_dowork();
+   schedule_work(_opmode_work);
goto free;
 
  try_again:
@@ -1614,6 +1616,7 @@ struct iwl_drv *iwl_drv_start(struct iwl_trans *trans)
 void iwl_drv_stop(struct iwl_drv *drv)
 {
wait_for_completion(>request_firmware_complete);
+   cancel_work_sync(_opmode_work);
 
_iwl_op_mode_stop(drv);
 
@@ -1667,7 +1670,7 @@ int iwl_opmode_register(const char *name, const struct 
iwl_op_mode_ops *ops)
mutex_unlock(_opmode_table_mtx);
 
if (!ret)
-   iwlwifi_opmode_dowork();
+   schedule_work(_opmode_work);
 
return ret;
 }
-- 
2.11.0

[RFC 1/5] iwlwifi: fix drv cleanup on opmode registration failure

[Luis R. Rodriguez]

The firmware async callback handles the device's opmode start
call, but optionally also allows opmode registration to take
care of its opmode start. If the firmware callback handles it
its error path in case of opmode start failure has a few pieces
of code missing from the opmode registration. The opmode
registration hanlder has no cleanup at all. Sync both error
paths.

This should in theory fix a detangled drv from the drv list should
either of the opmode modules loaded and handled registration for the
drv.

The path of having the opmode registration deal with the drv
opmode start is actually the more common path. The other path,
from the async callback is rathe rare (1/8 or so times for me) --
it happens when the the opmode driver's init routine completed
prior to the driver's async callback opmode start call.

Signed-off-by: Luis R. Rodriguez 
---
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index be466a074c1d..e198d6f5fcea 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1611,8 +1611,13 @@ int iwl_opmode_register(const char *name, const struct 
iwl_op_mode_ops *ops)
continue;
op->ops = ops;
/* TODO: need to handle exceptional case */
-   list_for_each_entry(drv, >drv, list)
+   list_for_each_entry(drv, >drv, list) {
drv->op_mode = _iwl_op_mode_start(drv, op);
+   if (!drv->op_mode) {
+   complete(>request_firmware_complete);
+   device_release_driver(drv->trans->dev);
+   }
+   }
 
mutex_unlock(_opmode_table_mtx);
return 0;
-- 
2.11.0

[RFC 3/5] iwlwifi: share opmode start work code

[Luis R. Rodriguez]

The firmware async callback and the opmode registration share
some functionality -- to start the drv's opmode. Move this work
into a helper which is shared. This should help us share fixes
should these diverging code paths change.

Signed-off-by: Luis R. Rodriguez 
---
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 93 +++-
 1 file changed, 63 insertions(+), 30 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index 6beb92d19ea7..4a1937c77f90 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -102,6 +102,7 @@ static struct dentry *iwl_dbgfs_root;
  * @op_mode: the running op_mode
  * @trans: transport layer
  * @dev: for debug prints only
+ * @start_requested: start op has been requested and is pending on this device
  * @fw_index: firmware revision to try loading
  * @firmware_name: composite filename of ucode file to load
  * @request_firmware_complete: the firmware has been obtained from user space
@@ -113,6 +114,7 @@ struct iwl_drv {
struct iwl_op_mode *op_mode;
struct iwl_trans *trans;
struct device *dev;
+   bool start_requested;
 
int fw_index;   /* firmware we're trying to load */
char firmware_name[64]; /* name of firmware file to load */
@@ -1254,6 +1256,48 @@ static void iwlwifi_try_load_op(struct 
iwlwifi_opmode_table *op,
 #endif
 }
 
+static void iwlwifi_opmode_start_drv(struct iwlwifi_opmode_table *op,
+struct iwl_drv *drv)
+{
+   if (!drv->start_requested)
+   return;
+
+   drv->op_mode = _iwl_op_mode_start(drv, op);
+   drv->start_requested = false;
+
+   /*
+* Complete the firmware request last so that
+* a driver unbind (stop) doesn't run while we
+* are doing the start() above.
+*/
+   complete(>request_firmware_complete);
+
+   if (!drv->op_mode)
+   device_release_driver(drv->trans->dev);
+}
+
+static void iwlwifi_opmode_start(struct iwlwifi_opmode_table *op)
+{
+   struct iwl_drv *drv;
+
+   list_for_each_entry(drv, >drv, list)
+   iwlwifi_opmode_start_drv(op, drv);
+}
+
+static void iwlwifi_opmode_dowork(void)
+{
+   unsigned int i;
+   struct iwlwifi_opmode_table *op;
+
+   mutex_lock(_opmode_table_mtx);
+   for (i = 0; i < ARRAY_SIZE(iwlwifi_opmode_table); i++) {
+   op = _opmode_table[i];
+   if (op->ops)
+   iwlwifi_opmode_start(op);
+   }
+   mutex_unlock(_opmode_table_mtx);
+}
+
 /**
  * iwl_req_fw_callback - callback when firmware was loaded
  *
@@ -1467,27 +1511,14 @@ static void iwl_req_fw_callback(const struct firmware 
*ucode_raw, void *context)
IWL_INFO(drv, "loaded firmware version %s op_mode %s\n",
 drv->fw.fw_version, op->name);
 
+   drv->start_requested = true;
/* add this device to the list of devices using this op_mode */
list_add_tail(>list, >drv);
 
-   if (op->ops) {
-   drv->op_mode = _iwl_op_mode_start(drv, op);
-
-   if (!drv->op_mode) {
-   mutex_unlock(_opmode_table_mtx);
-   goto out_unbind;
-   }
-   } else {
+   if (!op->ops)
load_module = true;
-   }
-   mutex_unlock(_opmode_table_mtx);
 
-   /*
-* Complete the firmware request last so that
-* a driver unbind (stop) doesn't run while we
-* are doing the start() above.
-*/
-   complete(>request_firmware_complete);
+   mutex_unlock(_opmode_table_mtx);
 
/*
 * Load the module last so we don't block anything
@@ -1496,6 +1527,7 @@ static void iwl_req_fw_callback(const struct firmware 
*ucode_raw, void *context)
 */
if (load_module)
iwlwifi_try_load_op(op, drv);
+   iwlwifi_opmode_dowork();
goto free;
 
  try_again:
@@ -1617,8 +1649,8 @@ IWL_EXPORT_SYMBOL(iwlwifi_mod_params);
 int iwl_opmode_register(const char *name, const struct iwl_op_mode_ops *ops)
 {
int i;
-   struct iwl_drv *drv;
struct iwlwifi_opmode_table *op;
+   int ret = -EIO;
 
mutex_lock(_opmode_table_mtx);
for (i = 0; i < ARRAY_SIZE(iwlwifi_opmode_table); i++) {
@@ -1626,20 +1658,15 @@ int iwl_opmode_register(const char *name, const struct 
iwl_op_mode_ops *ops)
if (strcmp(op->name, name))
continue;
op->ops = ops;
-   /* TODO: need to handle exceptional case */
-   list_for_each_entry(drv, >drv, list) {
-   drv->op_mode = _iwl_op_mode_start(drv, op);
-   if (!drv->op_mode) {
-   complete(>request_firmware_complete);
-   

[RFC 4/5] iwlwifi: move opmode loading to shared routine

[Luis R. Rodriguez]

This helps us compartmentalize all last required opmode work
and declutter the async firmware callback.

Signed-off-by: Luis R. Rodriguez 
---
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 33 +++-
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index 4a1937c77f90..6cfbc3c6e0d6 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -139,6 +139,8 @@ static struct iwlwifi_opmode_table {
const char *name;   /* name: iwldvm, iwlmvm, etc */
const struct iwl_op_mode_ops *ops;  /* pointer to op_mode ops */
struct list_head drv;   /* list of devices using this op_mode */
+   bool load_requested;/* Do we need to load a driver ? */
+   struct iwl_drv *drv_req;/* Device that set load_requested */
 } iwlwifi_opmode_table[] = {   /* ops set when driver is initialized */
[DVM_OP_MODE] = { .name = "iwldvm", .ops = NULL },
[MVM_OP_MODE] = { .name = "iwlmvm", .ops = NULL },
@@ -1233,27 +1235,32 @@ static void _iwl_op_mode_stop(struct iwl_drv *drv)
}
 }
 
-static void iwlwifi_try_load_op(struct iwlwifi_opmode_table *op,
-   struct iwl_drv *drv)
+/* We have to unlock and then lock for the caller */
+static void iwlwifi_try_load_op(struct iwlwifi_opmode_table *op)
 {
int ret = 0;
 
+   mutex_unlock(_opmode_table_mtx);
+
ret = request_module("%s", op->name);
-   if (ret)
+   if (ret) {
+   mutex_lock(_opmode_table_mtx);
goto out;
+   }
 
mutex_lock(_opmode_table_mtx);
if (!op->ops)
ret = -ENOENT;
-   mutex_unlock(_opmode_table_mtx);
 
 out:
 #ifdef CONFIG_IWLWIFI_OPMODE_MODULAR
if (ret)
-   IWL_ERR(drv,
+   IWL_ERR(op->drv_req,
"failed to load module %s (error %d), is dynamic 
loading enabled?\n",
op->name, ret);
 #endif
+   op->load_requested = false;
+   op->drv_req = NULL;
 }
 
 static void iwlwifi_opmode_start_drv(struct iwlwifi_opmode_table *op,
@@ -1294,6 +1301,8 @@ static void iwlwifi_opmode_dowork(void)
op = _opmode_table[i];
if (op->ops)
iwlwifi_opmode_start(op);
+   else if (op->load_requested)
+   iwlwifi_try_load_op(op);
}
mutex_unlock(_opmode_table_mtx);
 }
@@ -1317,7 +1326,6 @@ static void iwl_req_fw_callback(const struct firmware 
*ucode_raw, void *context)
size_t trigger_tlv_sz[FW_DBG_TRIGGER_MAX];
u32 api_ver;
int i;
-   bool load_module = false;
bool usniffer_images = false;
 
fw->ucode_capa.max_probe_length = IWL_DEFAULT_MAX_PROBE_LENGTH;
@@ -1515,18 +1523,13 @@ static void iwl_req_fw_callback(const struct firmware 
*ucode_raw, void *context)
/* add this device to the list of devices using this op_mode */
list_add_tail(>list, >drv);
 
-   if (!op->ops)
-   load_module = true;
+   if (!op->ops) {
+   op->load_requested = true;
+   op->drv_req = drv;
+   }
 
mutex_unlock(_opmode_table_mtx);
 
-   /*
-* Load the module last so we don't block anything
-* else from proceeding if the module fails to load
-* or hangs loading.
-*/
-   if (load_module)
-   iwlwifi_try_load_op(op, drv);
iwlwifi_opmode_dowork();
goto free;
 
-- 
2.11.0

Re: [kbuild-all] drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

[Fengguang Wu]

Hi Kalle,

On Thu, Feb 16, 2017 at 03:18:48PM +0200, Kalle Valo wrote:

Arend Van Spriel  writes:


On 16-2-2017 11:01, Kalle Valo wrote:

Arend Van Spriel  writes:


On 16-2-2017 10:39, Rafał Miłecki wrote:

On 02/16/2017 10:31 AM, Kalle Valo wrote:

(Adding linux-wireless)

Arend or Rafał, would you be able to look at this build problem? Kbuild
found the build errors below, apparently a very old issue. It just
blames me now because I moved the driver to a new directory :)


It is a very old issue. The thing is that the issue can not really occur
because we have this:

# common flags
subdir-ccflags-$(CONFIG_BRCMDBG)+= -DDEBUG

in drivers/net/wireless/broadcom/brcm80211/Makefile. So no clue what
happens in the "kbuild test robot" scenario.


I actually tried to reproduce this with kbuild bot's instructions and
was surprised to see that the build worked ok for me. So the issue is
not that simple.


Hi Kalle,

Here is the old email exchange we had about this [1]. In my opinion this
is a Kbuild issue that needs to be looked into.

Regards,
Arend

[1] http://www.spinics.net/lists/linux-wireless/msg142122.html


Heh, I had completely forgotten that we had discussed this before :)

Fengguang and the kbuild bot team, do you have any ideas why only the
bot is seeing this?


I guess the root cause is due to the robot's doing partial builds like
these

   make drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.o
   make drivers/net/wireless/broadcom/brcm80211/brcmfmac/

The solution I come about is to climb up to higher level dirs like 


   make drivers/net/wireless/

which is less likely to have Makefile tricks and still maintain fast
enough build tests.

Thanks,
Fengguang

[RFC V2 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI

[Vasanthakumar Thiagarajan]

For non-ETSI regulatory domain, CAC result on DFS channel
may not be valid once moving out of that channel (as done
during remain-on-channel, scannning and off-channel tx).
Running CAC on an operating DFS channel after every off-channel
operation will only add complexity and disturb the current
link. Better do not allow any off-channel switch from a DFS
operating channel in non-ETSI domain.

Signed-off-by: Vasanthakumar Thiagarajan 
---

V2:
Addressing below comments from Johannes

- Add locking assertion to cfg80211_off_channel_oper_allowed()
- Protect wdev->chandef access with wdev_lock()

 net/wireless/nl80211.c | 52 ++
 1 file changed, 52 insertions(+)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 63dfa60..94c84bd 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6506,6 +6506,19 @@ static int nl80211_parse_random_mac(struct nlattr 
**attrs,
return 0;
 }
 
+static bool cfg80211_off_channel_oper_allowed(struct wireless_dev *wdev)
+{
+   ASSERT_WDEV_LOCK(wdev);
+
+   if (!cfg80211_beaconing_iface_active(wdev))
+   return true;
+
+   if (!(wdev->chandef.chan->flags & IEEE80211_CHAN_RADAR))
+   return true;
+
+   return regulatory_pre_cac_allowed(wdev->wiphy);
+}
+
 static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
 {
struct cfg80211_registered_device *rdev = info->user_ptr[0];
@@ -6631,6 +6644,25 @@ static int nl80211_trigger_scan(struct sk_buff *skb, 
struct genl_info *info)
 
request->n_channels = i;
 
+   wdev_lock(wdev);
+   if (!cfg80211_off_channel_oper_allowed(wdev)) {
+   struct ieee80211_channel *chan;
+
+   if (request->n_channels != 1) {
+   wdev_unlock(wdev);
+   err = -EBUSY;
+   goto out_free;
+   }
+
+   chan = request->channels[0];
+   if (chan->center_freq != wdev->chandef.chan->center_freq) {
+   wdev_unlock(wdev);
+   err = -EBUSY;
+   goto out_free;
+   }
+   }
+   wdev_unlock(wdev);
+
i = 0;
if (n_ssids) {
nla_for_each_nested(attr, info->attrs[NL80211_ATTR_SCAN_SSIDS], 
tmp) {
@@ -9053,6 +9085,7 @@ static int nl80211_remain_on_channel(struct sk_buff *skb,
struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct wireless_dev *wdev = info->user_ptr[1];
struct cfg80211_chan_def chandef;
+   const struct cfg80211_chan_def *compat_chandef;
struct sk_buff *msg;
void *hdr;
u64 cookie;
@@ -9081,6 +9114,18 @@ static int nl80211_remain_on_channel(struct sk_buff *skb,
if (err)
return err;
 
+   wdev_lock(wdev);
+   if (!cfg80211_off_channel_oper_allowed(wdev) &&
+   !cfg80211_chandef_identical(>chandef, )) {
+   compat_chandef = cfg80211_chandef_compatible(>chandef,
+);
+   if (compat_chandef != ) {
+   wdev_unlock(wdev);
+   return -EBUSY;
+   }
+   }
+   wdev_unlock(wdev);
+
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
if (!msg)
return -ENOMEM;
@@ -9256,6 +9301,13 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct 
genl_info *info)
if (!chandef.chan && params.offchan)
return -EINVAL;
 
+   wdev_lock(wdev);
+   if (params.offchan && !cfg80211_off_channel_oper_allowed(wdev)) {
+   wdev_unlock(wdev);
+   return -EBUSY;
+   }
+   wdev_unlock(wdev);
+
params.buf = nla_data(info->attrs[NL80211_ATTR_FRAME]);
params.len = nla_len(info->attrs[NL80211_ATTR_FRAME]);
 
-- 
1.9.1

[RFC V2 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain

[Vasanthakumar Thiagarajan]

DFS requirement for ETSI domain (section 4.7.1.4 in
ETSI EN 301 893 V1.8.1) is the only one which explicitly
states that once DFS channel is marked as available afer
the CAC, this channel will remain in available state even
moving to a different operating channel. But the same is
not explicitly stated in FCC DFS requirement. Also, Pre-CAC
requriements are not explicitly mentioned in FCC requirement.
Current implementation in keeping DFS channel in available
state is same as described in ETSI domain.

For ETSI DFS domain, this patch gives a grace period of 2 seconds
since the completion of successful CAC before moving the channel's
DFS state to 'usable' from 'available' state. The same grace period
is checked against the channel's dfs_state_entered timestamp while
deciding if a DFS channel is available for operation. There is a new
radar event, NL80211_RADAR_PRE_CAC_EXPIRED, reported when DFS channel
is moved from available to usable state after the grace period. Also
make sure the DFS channel state is reset to usable once the beaconing
operation on that channel is brought down (like stop_ap, leave_ibss
and leave_mesh) in non-ETSI domain.

Signed-off-by: Vasanthakumar Thiagarajan 
---

V2:
Address below comments from Johannes
 
- Make 5G specific function names generic
- Rewrite helper function which checks if the 20Mhz channel
  in operating bandwidth with comment.
- Remove regulatory_get_pre_cac_timeout() and use 
regulatory_pre_cac_allowed()
  directly.

 include/uapi/linux/nl80211.h |   5 +++
 net/wireless/ap.c|   5 +++
 net/wireless/chan.c  | 101 +++
 net/wireless/core.h  |  10 +
 net/wireless/ibss.c  |   1 +
 net/wireless/mesh.c  |   1 +
 net/wireless/mlme.c  |  40 +
 net/wireless/reg.c   |  28 
 net/wireless/reg.h   |  14 ++
 9 files changed, 196 insertions(+), 9 deletions(-)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index d6c62ee..9d2d2b1 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4893,12 +4893,17 @@ enum nl80211_smps_mode {
  * change to the channel status.
  * @NL80211_RADAR_NOP_FINISHED: The Non-Occupancy Period for this channel is
  * over, channel becomes usable.
+ * @NL80211_RADAR_PRE_CAC_EXPIRED: Channel Availability Check done on this
+ * non-operating channel is expired and no longer valid. New CAC must
+ * be done on this channel before starting the operation. This is not
+ * applicable for ETSI dfs domain where pre-CAC is valid for ever.
  */
 enum nl80211_radar_event {
NL80211_RADAR_DETECTED,
NL80211_RADAR_CAC_FINISHED,
NL80211_RADAR_CAC_ABORTED,
NL80211_RADAR_NOP_FINISHED,
+   NL80211_RADAR_PRE_CAC_EXPIRED,
 };
 
 /**
diff --git a/net/wireless/ap.c b/net/wireless/ap.c
index bdad1f9..25666d3 100644
--- a/net/wireless/ap.c
+++ b/net/wireless/ap.c
@@ -32,6 +32,11 @@ int __cfg80211_stop_ap(struct cfg80211_registered_device 
*rdev,
rdev_set_qos_map(rdev, dev, NULL);
if (notify)
nl80211_send_ap_stopped(wdev);
+
+   /* Should we apply the grace period during beaconing interface
+* shutdown also?
+*/
+   cfg80211_sched_dfs_chan_update(rdev);
}
 
return err;
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 5497d022..099f13c 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -456,6 +456,107 @@ bool cfg80211_chandef_dfs_usable(struct wiphy *wiphy,
return (r1 + r2 > 0);
 }
 
+/*
+ * Checks if center frequency of chan falls with in the bandwidth
+ * range of chandef.
+ */
+bool cfg80211_is_sub_chan(struct cfg80211_chan_def *chandef,
+ struct ieee80211_channel *chan)
+{
+   int width;
+   u32 cf_offset, freq;
+
+   if (chandef->chan->center_freq == chan->center_freq)
+   return true;
+
+   width = cfg80211_chandef_get_width(chandef);
+   if (width <= 20)
+   return false;
+
+   cf_offset = width / 2 - 10;
+
+   for (freq = chandef->center_freq1 - width / 2 + 10;
+freq <= chandef->center_freq1 + width / 2 - 10; freq += 20) {
+   if (chan->center_freq == freq)
+   return true;
+   }
+
+   if (!chandef->center_freq2)
+   return false;
+
+   for (freq = chandef->center_freq2 - width / 2 + 10;
+freq <= chandef->center_freq2 + width / 2 - 10; freq += 20) {
+   if (chan->center_freq == freq)
+   return true;
+   }
+
+   return false;
+}
+
+bool cfg80211_beaconing_iface_active(struct wireless_dev *wdev)
+{
+   bool active = false;
+
+   ASSERT_WDEV_LOCK(wdev);
+
+   if (!wdev->chandef.chan)
+  

[RFC V2 3/3] cfg80211: Share Channel DFS state across wiphys of same DFS domain

[Vasanthakumar Thiagarajan]

Sharing DFS channel state across multiple wiphys (radios) could
be useful with multiple radios on the system. When one radio
completes CAC and markes the channel available another radio
can use this information and start beaconing without really doing
CAC.

Whenever there is a state change in dfs channel associated to
a particular wiphy the the same state change is propagated to
other wiphys having the same DFS reg domain configuration.
Also when a new wiphy is created the dfs channel state of
other existing wiphys of same DFS domain is copied.

Signed-off-by: Vasanthakumar Thiagarajan 
---

V2:
- Make 5G specific DFS chan state share logic generic (Johannes)

 net/wireless/chan.c |  30 ++
 net/wireless/core.c |  37 +
 net/wireless/core.h |   6 +++
 net/wireless/mlme.c |  10 +
 net/wireless/reg.c  | 117 
 net/wireless/reg.h  |  22 ++
 6 files changed, 215 insertions(+), 7 deletions(-)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 099f13c..b8aa5a7 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -531,16 +531,11 @@ bool cfg80211_beaconing_iface_active(struct wireless_dev 
*wdev)
return active;
 }
 
-bool cfg80211_any_wiphy_oper_chan(struct wiphy *wiphy,
- struct ieee80211_channel *chan)
+static bool cfg80211_is_wiphy_oper_chan(struct wiphy *wiphy,
+   struct ieee80211_channel *chan)
 {
struct wireless_dev *wdev;
 
-   ASSERT_RTNL();
-
-   if (!(chan->flags & IEEE80211_CHAN_RADAR))
-   return false;
-
list_for_each_entry(wdev, >wdev_list, list) {
wdev_lock(wdev);
if (!cfg80211_beaconing_iface_active(wdev)) {
@@ -558,6 +553,27 @@ bool cfg80211_any_wiphy_oper_chan(struct wiphy *wiphy,
return false;
 }
 
+bool cfg80211_any_wiphy_oper_chan(struct wiphy *wiphy,
+ struct ieee80211_channel *chan)
+{
+   struct cfg80211_registered_device *rdev;
+
+   ASSERT_RTNL();
+
+   if (!(chan->flags & IEEE80211_CHAN_RADAR))
+   return false;
+
+   list_for_each_entry(rdev, _rdev_list, list) {
+   if (!reg_dfs_domain_same(wiphy, >wiphy))
+   continue;
+
+   if (cfg80211_is_wiphy_oper_chan(>wiphy, chan))
+   return true;
+   }
+
+   return false;
+}
+
 static bool cfg80211_get_chans_dfs_available(struct wiphy *wiphy,
 u32 center_freq,
 u32 bandwidth)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 903fc419..d61c408 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -357,6 +357,38 @@ static void cfg80211_sched_scan_stop_wk(struct work_struct 
*work)
rtnl_unlock();
 }
 
+static void cfg80211_propagate_radar_detect_wk(struct work_struct *work)
+{
+   struct cfg80211_registered_device *rdev;
+
+   rdev = container_of(work, struct cfg80211_registered_device,
+   propagate_radar_detect_wk);
+
+   rtnl_lock();
+
+   regulatory_propagate_dfs_state(>wiphy, >radar_chandef,
+  NL80211_DFS_UNAVAILABLE,
+  NL80211_RADAR_DETECTED);
+
+   rtnl_unlock();
+}
+
+static void cfg80211_propagate_cac_done_wk(struct work_struct *work)
+{
+   struct cfg80211_registered_device *rdev;
+
+   rdev = container_of(work, struct cfg80211_registered_device,
+   propagate_cac_done_wk);
+
+   rtnl_lock();
+
+   regulatory_propagate_dfs_state(>wiphy, >cac_done_chandef,
+  NL80211_DFS_AVAILABLE,
+  NL80211_RADAR_CAC_FINISHED);
+
+   rtnl_unlock();
+}
+
 /* exported functions */
 
 struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int sizeof_priv,
@@ -456,6 +488,9 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, 
int sizeof_priv,
spin_lock_init(>destroy_list_lock);
INIT_WORK(>destroy_work, cfg80211_destroy_iface_wk);
INIT_WORK(>sched_scan_stop_wk, cfg80211_sched_scan_stop_wk);
+   INIT_WORK(>propagate_radar_detect_wk,
+ cfg80211_propagate_radar_detect_wk);
+   INIT_WORK(>propagate_cac_done_wk, cfg80211_propagate_cac_done_wk);
 
 #ifdef CONFIG_CFG80211_DEFAULT_PS
rdev->wiphy.flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT;
@@ -914,6 +949,8 @@ void wiphy_unregister(struct wiphy *wiphy)
flush_work(>destroy_work);
flush_work(>sched_scan_stop_wk);
flush_work(>mlme_unreg_wk);
+   flush_work(>propagate_radar_detect_wk);
+   flush_work(>propagate_cac_done_wk);
 
 #ifdef CONFIG_PM
if (rdev->wiphy.wowlan_config && rdev->ops->set_wakeup)
diff --git a/net/wireless/core.h b/net/wireless/core.h

[RFC V2 0/3] Pre-CAC and sharing DFS state across multiple radios

[Vasanthakumar Thiagarajan]

Currently irrespective of dfs domain and radar detection activity
pre-CAC results for a wiphy are retained till the wiphy is detroyed.
This may not be preferred in non-ETSI dfs domain where pre-CAC is not
explicitly mentioned in the respective DFS requirement spec. This patch
set modifies the current behaviour of pre-CAC for non-ETSI domain by
giving 2 seconds grace period for dfs master interface to start operating
on the CAC completed channel.

This patch set also adds support to share dfs channel state across
multiple radios of the same regulatory configuration.

Vasanthakumar Thiagarajan (3):
  cfg80211: Make pre-CAC results valid only for ETSI domain
  cfg80211: Disallow moving out of operating DFS channel in non-ETSI
  cfg80211: Share Channel DFS state across wiphys of same DFS domain

 include/uapi/linux/nl80211.h |   5 ++
 net/wireless/ap.c|   5 ++
 net/wireless/chan.c  | 117 ++
 net/wireless/core.c  |  37 +++
 net/wireless/core.h  |  16 +
 net/wireless/ibss.c  |   1 +
 net/wireless/mesh.c  |   1 +
 net/wireless/mlme.c  |  50 ---
 net/wireless/nl80211.c   |  52 
 net/wireless/reg.c   | 145 +++
 net/wireless/reg.h   |  36 +++
 11 files changed, 456 insertions(+), 9 deletions(-)

-- 
1.9.1

[PATCH] ath9k_htc: Add support of AirTies 1eda:2315 AR9271 device

[Dmitry Tunin]

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=1eda ProdID=2315 Rev=01.08
S:  Manufacturer=ATHEROS
S:  Product=USB2.0 WLAN
S:  SerialNumber=12345
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)

Signed-off-by: Dmitry Tunin 
Cc: sta...@vger.kernel.org
---
 drivers/net/wireless/ath/ath9k/hif_usb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index de2d212..05dd056 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -37,6 +37,7 @@ static struct usb_device_id ath9k_hif_usb_ids[] = {
{ USB_DEVICE(0x0cf3, 0xb002) }, /* Ubiquiti WifiStation */
{ USB_DEVICE(0x057c, 0x8403) }, /* AVM FRITZ!WLAN 11N v2 USB */
{ USB_DEVICE(0x0471, 0x209e) }, /* Philips (or NXP) PTA01 */
+   { USB_DEVICE(0x1eda, 0x2315) }, /* AirTies */
 
{ USB_DEVICE(0x0cf3, 0x7015),
  .driver_info = AR9287_USB },  /* Atheros */
-- 
2.7.4

TL-WN823N

[madmaxxx]

Hi,

I have a problem with rtl8xxxu driver, which seems to not work with a
dongle tp-link TL-WN823N model. I just filled out a 4.9.10 kernel and the
device is not fully recognized .. I can only scan network and not link.

Thank you

lsusb:
Bus 002 Device 002: ID 2357:0109

dmesg:
[gio feb 16 16:08:33 2017] usb 2-1: Vendor: Realtek
[gio feb 16 16:08:33 2017] usb 2-1: Product: \x03802.11n NI
[gio feb 16 16:08:33 2017] usb 2-1: Serial:
[gio feb 16 16:08:33 2017] usb 2-1: rtl8192eu_parse_efuse: dumping efuse 
(0x200 bytes):

[gio feb 16 16:08:33 2017] usb 2-1: 00: 29 81 00 7c 01 40 03 00
[gio feb 16 16:08:33 2017] usb 2-1: 08: 40 74 04 50 14 00 00 00
[gio feb 16 16:08:33 2017] usb 2-1: 10: 28 28 28 29 29 29 2a 2a
[gio feb 16 16:08:33 2017] usb 2-1: 18: 2b 2b 2b f2 ef ef ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 20: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 28: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 30: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 38: ff ff 28 28 28 28 28 28
[gio feb 16 16:08:33 2017] usb 2-1: 40: 2a 2a 29 2a 2a f2 ef ef
[gio feb 16 16:08:33 2017] usb 2-1: 48: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 50: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 58: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 60: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 68: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 70: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 78: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 80: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 88: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 90: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 98: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: a0: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: a8: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: b0: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: b8: a1 22 21 00 00 00 ff ff
[gio feb 16 16:08:33 2017] usb 2-1: c0: ff 01 00 10 00 00 00 ff
[gio feb 16 16:08:33 2017] usb 2-1: c8: 00 00 ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: d0: 57 23 09 01 e7 47 02 98
[gio feb 16 16:08:33 2017] usb 2-1: d8: de d0 1e a4 d7 0a 03 52
[gio feb 16 16:08:33 2017] usb 2-1: e0: 65 61 6c 74 65 6b 20 0e
[gio feb 16 16:08:33 2017] usb 2-1: e8: 03 38 30 32 2e 31 31 6e
[gio feb 16 16:08:33 2017] usb 2-1: f0: 20 4e 49 43 20 00 00 ff
[gio feb 16 16:08:33 2017] usb 2-1: f8: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 100: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 108: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 110: ff ff ff ff ff ff ff 0d
[gio feb 16 16:08:33 2017] usb 2-1: 118: 03 00 05 00 30 00 00 00
[gio feb 16 16:08:33 2017] usb 2-1: 120: 00 93 ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 128: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 130: f6 a8 98 2d 03 92 98 00
[gio feb 16 16:08:33 2017] usb 2-1: 138: fc 8c 00 11 9b 44 02 0a
[gio feb 16 16:08:33 2017] usb 2-1: 140: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 148: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 150: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 158: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 160: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 168: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 170: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 178: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 180: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 188: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 190: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 198: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1a0: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1a8: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1b0: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1b8: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1c0: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1c8: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1d0: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1d8: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1e0: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1e8: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1f0: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: 1f8: ff ff ff ff ff ff ff ff
[gio feb 16 16:08:33 2017] usb 2-1: RTL8192EU rev B (SMIC) 2T2R, TX 
queues 3, WiFi=1, BT=0, GPS=0, HI PA=0

[gio feb 16 16:08:33 2017] usb 2-1: RTL8192EU MAC: 98:de:d0:1e:a4:d7
[gio feb 16 16:08:33 2017] usb 2-1: rtl8xxxu: Loading firmware 
rtlwifi/rtl8192eu_nic.bin

pull-request: wireless-drivers-next 2017-02-17

[Kalle Valo]

Hi Dave,

few -next patches I'm still hoping to get to 4.11 to keep my backlog
short, nothing major here. Please let me know if there are any problems.

Kalle

The following changes since commit 3b03cc0783b03ddd668ff3f86419bc67d0664e89:

  net: natsemi: ns83820: use new api ethtool_{get|set}_link_ksettings 
(2017-02-12 22:32:17 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
tags/wireless-drivers-next-for-davem-2017-02-16

for you to fetch changes up to b065d3f59ff1905922194bd17c79543289317fc7:

  Merge ath-next from 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-02-15 
16:01:04 +0200)


wireless-drivers-next patches for 4.11

Mostly small fixes, not really any new features.

Major changes:

ath10k

* when trying older firmware versions don't confuse user with error messages

ath9k

* fix crash in AP mode (regression)
* fix relayfs crash (regression)
* fix initialisation with AR9340 and AR9550


Amadeusz Sławiński (3):
  ath10k: remove ath10k_vif_to_arvif()
  ath10k: use size_t for len variables
  ath10k: fix comment

Arnd Bergmann (1):
  rt2500usb: don't mark register accesses as inline

Brian Norris (1):
  mwifiex: don't enable/disable IRQ 0 during suspend/resume

Christian Lamparter (1):
  ath9k: use correct OTP register offsets for the AR9340 and AR9550

Erik Stromdahl (1):
  ath10k: fetch firmware images in a loop

Felix Fietkau (1):
  ath9k: clean up and fix ath_tx_count_airtime

Iain Hunter (1):
  wlcore: disable multicast filter in AP mode

Julia Lawall (1):
  rtlwifi: btcoexist: fix semicolon.cocci warnings

Kalle Valo (4):
  ath10k: fix napi crash during rmmod when probe firmware fails
  ath10k: add directory to board data error message
  ath10k: convert warning about non-existent OTP board id to debug message
  Merge ath-next from git://git.kernel.org/.../kvalo/ath.git

Larry Finger (3):
  rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a2ant.c
  rtlwifi: btcoexist: Fix if == else warnings in halbtc8821a1ant.c
  rtlwifi: btcoexist: Fix if == else warnings in halbtc8723b1ant.c

Michal Kazior (1):
  ath10k: silence firmware file probing warnings

Ryan Hsu (1):
  ath10k: fix the garage chars in board file name creation

Sven Eckelmann (1):
  ath9k: Access rchan::buf only with per_cpu helper

Tobias Klauser (3):
  ath6kl: Use net_device_stats from struct net_device
  orinoco: Use net_device_stats from struct net_device
  brcmfmac: Use net_device_stats from struct net_device

 drivers/net/wireless/ath/ath10k/core.c |  72 
 drivers/net/wireless/ath/ath10k/debug.c|  49 +++---
 drivers/net/wireless/ath/ath10k/hw.h   |   4 +
 drivers/net/wireless/ath/ath10k/mac.c  |  68 
 drivers/net/wireless/ath/ath10k/mac.h  |   7 +-
 drivers/net/wireless/ath/ath10k/p2p.c  |   2 +-
 drivers/net/wireless/ath/ath10k/pci.c  |   3 +-
 drivers/net/wireless/ath/ath10k/spectral.c |   7 +-
 drivers/net/wireless/ath/ath10k/testmode.c |   5 +-
 drivers/net/wireless/ath/ath10k/wmi.c  |   2 +-
 drivers/net/wireless/ath/ath10k/wmi.h  |   2 +-
 drivers/net/wireless/ath/ath6kl/core.h |   1 -
 drivers/net/wireless/ath/ath6kl/main.c |   8 -
 drivers/net/wireless/ath/ath6kl/txrx.c |  22 +--
 drivers/net/wireless/ath/ath9k/ar9003_eeprom.h |   4 +-
 drivers/net/wireless/ath/ath9k/common-spectral.c   |   2 +-
 drivers/net/wireless/ath/ath9k/xmit.c  |  52 ++
 .../wireless/broadcom/brcm80211/brcmfmac/core.c|  26 +--
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|   2 -
 drivers/net/wireless/intersil/orinoco/main.c   |  27 +--
 drivers/net/wireless/intersil/orinoco/orinoco.h|   2 -
 .../net/wireless/intersil/orinoco/orinoco_usb.c|   6 +-
 drivers/net/wireless/marvell/mwifiex/main.c|   8 +-
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c |  19 +--
 .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c|  24 +--
 .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c|  18 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c| 187 +++--
 drivers/net/wireless/ti/wlcore/main.c  |  15 ++
 28 files changed, 213 insertions(+), 431 deletions(-)

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

[Kalle Valo]

Arend Van Spriel  writes:

> On 16-2-2017 11:01, Kalle Valo wrote:
>> Arend Van Spriel  writes:
>> 
>>> On 16-2-2017 10:39, Rafał Miłecki wrote:
 On 02/16/2017 10:31 AM, Kalle Valo wrote:
> (Adding linux-wireless)
>
> Arend or Rafał, would you be able to look at this build problem? Kbuild
> found the build errors below, apparently a very old issue. It just
> blames me now because I moved the driver to a new directory :)
>>>
>>> It is a very old issue. The thing is that the issue can not really occur
>>> because we have this:
>>>
>>> # common flags
>>> subdir-ccflags-$(CONFIG_BRCMDBG)+= -DDEBUG
>>>
>>> in drivers/net/wireless/broadcom/brcm80211/Makefile. So no clue what
>>> happens in the "kbuild test robot" scenario.
>> 
>> I actually tried to reproduce this with kbuild bot's instructions and
>> was surprised to see that the build worked ok for me. So the issue is
>> not that simple.
>
> Hi Kalle,
>
> Here is the old email exchange we had about this [1]. In my opinion this
> is a Kbuild issue that needs to be looked into.
>
> Regards,
> Arend
>
> [1] http://www.spinics.net/lists/linux-wireless/msg142122.html

Heh, I had completely forgotten that we had discussed this before :)

Fengguang and the kbuild bot team, do you have any ideas why only the
bot is seeing this?

-- 
Kalle Valo

Re: [kbuild-all] drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

[Fengguang Wu]

Hi all,

Yes sorry, it's a false report related to how we do bisects.


CONFIG_BRCM_TRACING=y
CONFIG_BRCMDBG=y

but DEBUG is not defined.

I think it would help if CONFIG_BRCMDBG set DEBUG
or if some of the tests for DEBUG used CONFIG_BRCMDBG instead.


Arend or Rafał, would you be able to look at this build problem? Kbuild
found the build errors below, apparently a very old issue. It just
blames me now because I moved the driver to a new directory :)


It is a very old issue. The thing is that the issue can not really occur
because we have this:

# common flags
subdir-ccflags-$(CONFIG_BRCMDBG)+= -DDEBUG

in drivers/net/wireless/broadcom/brcm80211/Makefile. So no clue what
happens in the "kbuild test robot" scenario.


As an optimization, the robot often does "partial builds" during bisects.
For example, when the error is found in

   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c

It'll try

   make drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.o

And verify the bisect result with

   make drivers/net/wireless/broadcom/brcm80211/brcmfmac/

However in this case the whole dir is moved, so both logics failed to
give correct results. We'll check how to improve this. Sorry for the
confusions!


I actually tried to reproduce this with kbuild bot's instructions and
was surprised to see that the build worked ok for me. So the issue is
not that simple.


Hi Kalle,

Here is the old email exchange we had about this [1]. In my opinion this
is a Kbuild issue that needs to be looked into.

Regards,
Arend

[1] http://www.spinics.net/lists/linux-wireless/msg142122.html


Thanks,
Fengguang

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

[Arend Van Spriel]

On 16-2-2017 11:01, Kalle Valo wrote:
> Arend Van Spriel  writes:
> 
>> On 16-2-2017 10:39, Rafał Miłecki wrote:
>>> On 02/16/2017 10:31 AM, Kalle Valo wrote:
 (Adding linux-wireless)

 Randy Dunlap  writes:

> On 02/07/17 02:02, kbuild test robot wrote:
>> Hi Kalle,
>>
>> FYI, the error/warning still remains.
>>
>> tree:  
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> master
>> head:   8b1b41ee74f9712c355d66dc105bbea663ae0afd
>> commit: 05491d2ccf20b20a1375303441fbbfbd12b24a4f brcm80211: move
>> under broadcom vendor directory
>> date:   1 year, 3 months ago
>> config: mips-allyesconfig (attached as .config)
>> compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
>> reproduce:
>> wget
>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>>
>> -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> git checkout 05491d2ccf20b20a1375303441fbbfbd12b24a4f
>> # save the attached .config to linux build tree
>> make.cross ARCH=mips
>>
>> All errors (new ones prefixed by >>):
> n
> when both:
>
> CONFIG_BRCM_TRACING=y
> CONFIG_BRCMDBG=y
>
> but DEBUG is not defined.
>
> I think it would help if CONFIG_BRCMDBG set DEBUG
> or if some of the tests for DEBUG used CONFIG_BRCMDBG instead.

 Arend or Rafał, would you be able to look at this build problem? Kbuild
 found the build errors below, apparently a very old issue. It just
 blames me now because I moved the driver to a new directory :)
>>
>> It is a very old issue. The thing is that the issue can not really occur
>> because we have this:
>>
>> # common flags
>> subdir-ccflags-$(CONFIG_BRCMDBG)+= -DDEBUG
>>
>> in drivers/net/wireless/broadcom/brcm80211/Makefile. So no clue what
>> happens in the "kbuild test robot" scenario.
> 
> I actually tried to reproduce this with kbuild bot's instructions and
> was surprised to see that the build worked ok for me. So the issue is
> not that simple.

Hi Kalle,

Here is the old email exchange we had about this [1]. In my opinion this
is a Kbuild issue that needs to be looked into.

Regards,
Arend

[1] http://www.spinics.net/lists/linux-wireless/msg142122.html

Re: [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

[Rafał Miłecki]

On 2017-02-16 09:38, Arend Van Spriel wrote:

On 16-2-2017 8:26, Rafał Miłecki wrote:

From: Rafał Miłecki 

Failing to load NVRAM file isn't critical if we manage to get platform
one in the fallback path. It means warnings like:
[   10.801506] brcmfmac :01:00.0: Direct firmware load for 
brcm/brcmfmac43602-pcie.txt failed with error -2

are unnecessary & disturbing for people with platform NVRAM. This is
very common case for Broadcom home routers.

So instead of printing warning immediately with the firmware subsystem
let's first try our fallback code. If that fails as well, then it's a
right moment to print an error.

This should reduce amount of false reports from users seeing this
warning while having wireless working perfectly fine.


There are of course people with issues who take this warning as a straw
to clutch.


Signed-off-by: Rafał Miłecki 
---
V2: Update commit message as it wasn't clear enough (thanks Andy) & 
add extra

messages to the firmware.c.

Kalle, Arend: this patch is strictly related to the bigger 1/2. Could 
you ack
this change as I expect this patchset to be picked by Ming, Luis or 
Greg?

---
 .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c  | 16 
+++-

 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git 
a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c

index c7c1e9906500..510a76d99eee 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -462,8 +462,14 @@ static void brcmf_fw_request_nvram_done(const 
struct firmware *fw, void *ctx)

raw_nvram = false;
} else {
data = bcm47xx_nvram_get_contents(_len);
-   if (!data && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
-   goto fail;
+   if (!data) {
+   brcmf_dbg(TRACE, "Failed to get platform NVRAM\n");
+   if (!(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL)) {
+brcmf_err("Loading NVRAM from %s and using platform one both 
failed\n",

+ fwctx->nvram_name);
+   goto fail;
+   }
+   }
raw_nvram = true;
}

@@ -504,9 +510,9 @@ static void brcmf_fw_request_code_done(const 
struct firmware *fw, void *ctx)

return;
}
fwctx->code = fw;
-   ret = request_firmware_nowait(THIS_MODULE, true, fwctx->nvram_name,
- fwctx->dev, GFP_KERNEL, fwctx,
- brcmf_fw_request_nvram_done);
+   ret = request_firmware_async(THIS_MODULE, FW_OPT_NO_WARN,
+fwctx->nvram_name, fwctx->dev, GFP_KERNEL,
+fwctx, brcmf_fw_request_nvram_done);


You changed the behaviour, because of your change in patch 1/2:

-   fw_work->opt_flags = FW_OPT_NOWAIT | FW_OPT_FALLBACK |
-   (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
+   fw_work->opt_flags = FW_OPT_NOWAIT | opt_flags;

So: (FW_OPT_NOWAIT | FW_OPT_UEVENT) vs (FW_OPT_NOWAIT | FW_OPT_NO_WARN)


Sorry, I didn't realize brcmfmac needs FW_OPT_UEVENT. I'll re-add it in 
V3, just

let me wait to see if there will be more comments.

Re: [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

[Arend Van Spriel]

On 16-2-2017 10:32, Rafał Miłecki wrote:
> On 2017-02-16 10:18, Arend Van Spriel wrote:
>> On 16-2-2017 10:04, Rafał Miłecki wrote:
>>> On 2017-02-16 09:38, Arend Van Spriel wrote:
 On 16-2-2017 8:26, Rafał Miłecki wrote:
> From: Rafał Miłecki 
>
> Failing to load NVRAM file isn't critical if we manage to get platform
> one in the fallback path. It means warnings like:
> [   10.801506] brcmfmac :01:00.0: Direct firmware load for
> brcm/brcmfmac43602-pcie.txt failed with error -2
> are unnecessary & disturbing for people with platform NVRAM. This is
> very common case for Broadcom home routers.
>
> So instead of printing warning immediately with the firmware subsystem
> let's first try our fallback code. If that fails as well, then it's a
> right moment to print an error.
>
> This should reduce amount of false reports from users seeing this
> warning while having wireless working perfectly fine.

 There are of course people with issues who take this warning as a straw
 to clutch.

> Signed-off-by: Rafał Miłecki 
> ---
> V2: Update commit message as it wasn't clear enough (thanks Andy) &
> add extra
> messages to the firmware.c.
>
> Kalle, Arend: this patch is strictly related to the bigger 1/2. Could
> you ack
> this change as I expect this patchset to be picked by Ming, Luis or
> Greg?
> ---
>  .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c  | 16
> +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git
> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> index c7c1e9906500..510a76d99eee 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> @@ -462,8 +462,14 @@ static void brcmf_fw_request_nvram_done(const
> struct firmware *fw, void *ctx)
>  raw_nvram = false;
>  } else {
>  data = bcm47xx_nvram_get_contents(_len);
> -if (!data && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
> -goto fail;
> +if (!data) {
> +brcmf_dbg(TRACE, "Failed to get platform NVRAM\n");
> +if (!(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL)) {
> +brcmf_err("Loading NVRAM from %s and using platform
> one both failed\n",
> +  fwctx->nvram_name);
> +goto fail;
> +}
> +}
>  raw_nvram = true;
>  }
>
> @@ -504,9 +510,9 @@ static void brcmf_fw_request_code_done(const
> struct firmware *fw, void *ctx)
>  return;
>  }
>  fwctx->code = fw;
> -ret = request_firmware_nowait(THIS_MODULE, true,
> fwctx->nvram_name,
> -  fwctx->dev, GFP_KERNEL, fwctx,
> -  brcmf_fw_request_nvram_done);
> +ret = request_firmware_async(THIS_MODULE, FW_OPT_NO_WARN,
> + fwctx->nvram_name, fwctx->dev, GFP_KERNEL,
> + fwctx, brcmf_fw_request_nvram_done);

 You changed the behaviour, because of your change in patch 1/2:

 -fw_work->opt_flags = FW_OPT_NOWAIT | FW_OPT_FALLBACK |
 -(uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
 +fw_work->opt_flags = FW_OPT_NOWAIT | opt_flags;

 So: (FW_OPT_NOWAIT | FW_OPT_UEVENT) vs (FW_OPT_NOWAIT | FW_OPT_NO_WARN)
>>>
>>> Sorry, I didn't realize brcmfmac needs FW_OPT_UEVENT. I'll re-add it in
>>> V3, just
>>> let me wait to see if there will be more comments.
>>
>> To be honest whether or not FW_OPT_UEVENT is needed should not be
>> something a driver needs to concern about. It is really a system
>> configuration issue if you ask me. So the only thing we could do is to
>> have it just in case.
> 
> Drivers always got a choice (see bool uevent) so I didn't want to change
> it.

Sure, I know. I just wanted to vent an opinion for the firmware_class
maintainers.

Regards,
Arend

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

[Kalle Valo]

Arend Van Spriel  writes:

> On 16-2-2017 10:39, Rafał Miłecki wrote:
>> On 02/16/2017 10:31 AM, Kalle Valo wrote:
>>> (Adding linux-wireless)
>>>
>>> Randy Dunlap  writes:
>>>
 On 02/07/17 02:02, kbuild test robot wrote:
> Hi Kalle,
>
> FYI, the error/warning still remains.
>
> tree:  
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head:   8b1b41ee74f9712c355d66dc105bbea663ae0afd
> commit: 05491d2ccf20b20a1375303441fbbfbd12b24a4f brcm80211: move
> under broadcom vendor directory
> date:   1 year, 3 months ago
> config: mips-allyesconfig (attached as .config)
> compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>
> -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 05491d2ccf20b20a1375303441fbbfbd12b24a4f
> # save the attached .config to linux build tree
> make.cross ARCH=mips
>
> All errors (new ones prefixed by >>):
n
 when both:

 CONFIG_BRCM_TRACING=y
 CONFIG_BRCMDBG=y

 but DEBUG is not defined.

 I think it would help if CONFIG_BRCMDBG set DEBUG
 or if some of the tests for DEBUG used CONFIG_BRCMDBG instead.
>>>
>>> Arend or Rafał, would you be able to look at this build problem? Kbuild
>>> found the build errors below, apparently a very old issue. It just
>>> blames me now because I moved the driver to a new directory :)
>
> It is a very old issue. The thing is that the issue can not really occur
> because we have this:
>
> # common flags
> subdir-ccflags-$(CONFIG_BRCMDBG)+= -DDEBUG
>
> in drivers/net/wireless/broadcom/brcm80211/Makefile. So no clue what
> happens in the "kbuild test robot" scenario.

I actually tried to reproduce this with kbuild bot's instructions and
was surprised to see that the build worked ok for me. So the issue is
not that simple.

-- 
Kalle Valo

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

[Arend Van Spriel]

On 16-2-2017 10:39, Rafał Miłecki wrote:
> On 02/16/2017 10:31 AM, Kalle Valo wrote:
>> (Adding linux-wireless)
>>
>> Randy Dunlap  writes:
>>
>>> On 02/07/17 02:02, kbuild test robot wrote:
 Hi Kalle,

 FYI, the error/warning still remains.

 tree:  
 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 master
 head:   8b1b41ee74f9712c355d66dc105bbea663ae0afd
 commit: 05491d2ccf20b20a1375303441fbbfbd12b24a4f brcm80211: move
 under broadcom vendor directory
 date:   1 year, 3 months ago
 config: mips-allyesconfig (attached as .config)
 compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
 reproduce:
 wget
 https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross

 -O ~/bin/make.cross
 chmod +x ~/bin/make.cross
 git checkout 05491d2ccf20b20a1375303441fbbfbd12b24a4f
 # save the attached .config to linux build tree
 make.cross ARCH=mips

 All errors (new ones prefixed by >>):
>>>
>>> when both:
>>>
>>> CONFIG_BRCM_TRACING=y
>>> CONFIG_BRCMDBG=y
>>>
>>> but DEBUG is not defined.
>>>
>>> I think it would help if CONFIG_BRCMDBG set DEBUG
>>> or if some of the tests for DEBUG used CONFIG_BRCMDBG instead.
>>
>> Arend or Rafał, would you be able to look at this build problem? Kbuild
>> found the build errors below, apparently a very old issue. It just
>> blames me now because I moved the driver to a new directory :)

It is a very old issue. The thing is that the issue can not really occur
because we have this:

# common flags
subdir-ccflags-$(CONFIG_BRCMDBG)+= -DDEBUG

in drivers/net/wireless/broadcom/brcm80211/Makefile. So no clue what
happens in the "kbuild test robot" scenario.

Regards,
Arend

> Something like this maybe? Note I didn't test it with above config.
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> index 6687812770cc..8c7695fde482 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> @@ -108,7 +108,7 @@ do {\
>  extern int brcmf_msg_level;
> 
>  struct brcmf_pub;
> -#ifdef DEBUG
> +#ifdef CONFIG_BRCMDBG
>  void brcmf_debugfs_init(void);
>  void brcmf_debugfs_exit(void);
>  int brcmf_debug_attach(struct brcmf_pub *drvr);
> 

Re: [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

[Rafał Miłecki]

On 2017-02-16 10:18, Arend Van Spriel wrote:

On 16-2-2017 10:04, Rafał Miłecki wrote:

On 2017-02-16 09:38, Arend Van Spriel wrote:

On 16-2-2017 8:26, Rafał Miłecki wrote:

From: Rafał Miłecki 

Failing to load NVRAM file isn't critical if we manage to get 
platform

one in the fallback path. It means warnings like:
[   10.801506] brcmfmac :01:00.0: Direct firmware load for
brcm/brcmfmac43602-pcie.txt failed with error -2
are unnecessary & disturbing for people with platform NVRAM. This is
very common case for Broadcom home routers.

So instead of printing warning immediately with the firmware 
subsystem
let's first try our fallback code. If that fails as well, then it's 
a

right moment to print an error.

This should reduce amount of false reports from users seeing this
warning while having wireless working perfectly fine.


There are of course people with issues who take this warning as a 
straw

to clutch.


Signed-off-by: Rafał Miłecki 
---
V2: Update commit message as it wasn't clear enough (thanks Andy) &
add extra
messages to the firmware.c.

Kalle, Arend: this patch is strictly related to the bigger 1/2. 
Could

you ack
this change as I expect this patchset to be picked by Ming, Luis or
Greg?
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c  | 16
+++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git
a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index c7c1e9906500..510a76d99eee 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -462,8 +462,14 @@ static void brcmf_fw_request_nvram_done(const
struct firmware *fw, void *ctx)
 raw_nvram = false;
 } else {
 data = bcm47xx_nvram_get_contents(_len);
-if (!data && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
-goto fail;
+if (!data) {
+brcmf_dbg(TRACE, "Failed to get platform NVRAM\n");
+if (!(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL)) {
+brcmf_err("Loading NVRAM from %s and using platform
one both failed\n",
+  fwctx->nvram_name);
+goto fail;
+}
+}
 raw_nvram = true;
 }

@@ -504,9 +510,9 @@ static void brcmf_fw_request_code_done(const
struct firmware *fw, void *ctx)
 return;
 }
 fwctx->code = fw;
-ret = request_firmware_nowait(THIS_MODULE, true, 
fwctx->nvram_name,

-  fwctx->dev, GFP_KERNEL, fwctx,
-  brcmf_fw_request_nvram_done);
+ret = request_firmware_async(THIS_MODULE, FW_OPT_NO_WARN,
+ fwctx->nvram_name, fwctx->dev, GFP_KERNEL,
+ fwctx, brcmf_fw_request_nvram_done);


You changed the behaviour, because of your change in patch 1/2:

-fw_work->opt_flags = FW_OPT_NOWAIT | FW_OPT_FALLBACK |
-(uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
+fw_work->opt_flags = FW_OPT_NOWAIT | opt_flags;

So: (FW_OPT_NOWAIT | FW_OPT_UEVENT) vs (FW_OPT_NOWAIT | 
FW_OPT_NO_WARN)


Sorry, I didn't realize brcmfmac needs FW_OPT_UEVENT. I'll re-add it 
in

V3, just
let me wait to see if there will be more comments.


To be honest whether or not FW_OPT_UEVENT is needed should not be
something a driver needs to concern about. It is really a system
configuration issue if you ask me. So the only thing we could do is to
have it just in case.


Drivers always got a choice (see bool uevent) so I didn't want to change 
it.

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

[Rafał Miłecki]

On 02/16/2017 10:31 AM, Kalle Valo wrote:

(Adding linux-wireless)

Randy Dunlap  writes:


On 02/07/17 02:02, kbuild test robot wrote:

Hi Kalle,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   8b1b41ee74f9712c355d66dc105bbea663ae0afd
commit: 05491d2ccf20b20a1375303441fbbfbd12b24a4f brcm80211: move
under broadcom vendor directory
date:   1 year, 3 months ago
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 05491d2ccf20b20a1375303441fbbfbd12b24a4f
# save the attached .config to linux build tree
make.cross ARCH=mips

All errors (new ones prefixed by >>):


when both:

CONFIG_BRCM_TRACING=y
CONFIG_BRCMDBG=y

but DEBUG is not defined.

I think it would help if CONFIG_BRCMDBG set DEBUG
or if some of the tests for DEBUG used CONFIG_BRCMDBG instead.


Arend or Rafał, would you be able to look at this build problem? Kbuild
found the build errors below, apparently a very old issue. It just
blames me now because I moved the driver to a new directory :)


Something like this maybe? Note I didn't test it with above config.

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
index 6687812770cc..8c7695fde482 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
@@ -108,7 +108,7 @@ do {
\
 extern int brcmf_msg_level;

 struct brcmf_pub;
-#ifdef DEBUG
+#ifdef CONFIG_BRCMDBG
 void brcmf_debugfs_init(void);
 void brcmf_debugfs_exit(void);
 int brcmf_debug_attach(struct brcmf_pub *drvr);

Re: drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6: error: redefinition of 'brcmf_debugfs_init'

[Kalle Valo]

(Adding linux-wireless)

Randy Dunlap  writes:

> On 02/07/17 02:02, kbuild test robot wrote:
>> Hi Kalle,
>> 
>> FYI, the error/warning still remains.
>> 
>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
>> master
>> head:   8b1b41ee74f9712c355d66dc105bbea663ae0afd
>> commit: 05491d2ccf20b20a1375303441fbbfbd12b24a4f brcm80211: move
>> under broadcom vendor directory
>> date:   1 year, 3 months ago
>> config: mips-allyesconfig (attached as .config)
>> compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
>> reproduce:
>> wget
>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>> -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> git checkout 05491d2ccf20b20a1375303441fbbfbd12b24a4f
>> # save the attached .config to linux build tree
>> make.cross ARCH=mips 
>> 
>> All errors (new ones prefixed by >>):
>
> when both:
>
> CONFIG_BRCM_TRACING=y
> CONFIG_BRCMDBG=y
>
> but DEBUG is not defined.
>
> I think it would help if CONFIG_BRCMDBG set DEBUG
> or if some of the tests for DEBUG used CONFIG_BRCMDBG instead.

Arend or Rafał, would you be able to look at this build problem? Kbuild
found the build errors below, apparently a very old issue. It just
blames me now because I moved the driver to a new directory :)

>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:58:6:
>> error: redefinition of 'brcmf_debugfs_init'
void brcmf_debugfs_init(void)
 ^~
   In file included from 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h:20:0,
from 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:24:
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h:118:20: note: 
previous definition of 'brcmf_debugfs_init' was here
static inline void brcmf_debugfs_init(void)
   ^~
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:65:6:
>> error: redefinition of 'brcmf_debugfs_exit'
void brcmf_debugfs_exit(void)
 ^~
   In file included from 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h:20:0,
from 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:24:
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h:121:20: note: 
previous definition of 'brcmf_debugfs_exit' was here
static inline void brcmf_debugfs_exit(void)
   ^~
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:74:5:
>> error: redefinition of 'brcmf_debug_attach'
int brcmf_debug_attach(struct brcmf_pub *drvr)
^~
   In file included from 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h:20:0,
from 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:24:
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h:124:19: note: 
previous definition of 'brcmf_debug_attach' was here
static inline int brcmf_debug_attach(struct brcmf_pub *drvr)
  ^~
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c: In function 
'brcmf_debug_attach':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:81:6:
>> error: 'struct brcmf_pub' has no member named 'dbgfs_dir'
 drvr->dbgfs_dir = debugfs_create_dir(dev_name(dev), root_folder);
 ^~
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:82:17: error: 
'struct brcmf_pub' has no member named 'dbgfs_dir'
 if (IS_ERR(drvr->dbgfs_dir))
^~
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:83:22: error: 
'struct brcmf_pub' has no member named 'dbgfs_dir'
  return PTR_ERR(drvr->dbgfs_dir);
 ^~
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c: At top level:
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:90:6:
>> error: redefinition of 'brcmf_debug_detach'
void brcmf_debug_detach(struct brcmf_pub *drvr)
 ^~
   In file included from 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h:20:0,
from 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:24:
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h:128:20: note: 
previous definition of 'brcmf_debug_detach' was here
static inline void brcmf_debug_detach(struct brcmf_pub *drvr)
   ^~
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c: In function 
'brcmf_debug_detach':
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:94:26: error: 
'struct brcmf_pub' has no member named 'dbgfs_dir'
 if (!IS_ERR_OR_NULL(drvr->dbgfs_dir))
 ^~
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c:95:32: error: 
'struct brcmf_pub' has no member named 'dbgfs_dir'
  debugfs_remove_recursive(drvr->dbgfs_dir);
   ^~
   

Re: [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

[Arend Van Spriel]

On 16-2-2017 10:04, Rafał Miłecki wrote:
> On 2017-02-16 09:38, Arend Van Spriel wrote:
>> On 16-2-2017 8:26, Rafał Miłecki wrote:
>>> From: Rafał Miłecki 
>>>
>>> Failing to load NVRAM file isn't critical if we manage to get platform
>>> one in the fallback path. It means warnings like:
>>> [   10.801506] brcmfmac :01:00.0: Direct firmware load for
>>> brcm/brcmfmac43602-pcie.txt failed with error -2
>>> are unnecessary & disturbing for people with platform NVRAM. This is
>>> very common case for Broadcom home routers.
>>>
>>> So instead of printing warning immediately with the firmware subsystem
>>> let's first try our fallback code. If that fails as well, then it's a
>>> right moment to print an error.
>>>
>>> This should reduce amount of false reports from users seeing this
>>> warning while having wireless working perfectly fine.
>>
>> There are of course people with issues who take this warning as a straw
>> to clutch.
>>
>>> Signed-off-by: Rafał Miłecki 
>>> ---
>>> V2: Update commit message as it wasn't clear enough (thanks Andy) &
>>> add extra
>>> messages to the firmware.c.
>>>
>>> Kalle, Arend: this patch is strictly related to the bigger 1/2. Could
>>> you ack
>>> this change as I expect this patchset to be picked by Ming, Luis or
>>> Greg?
>>> ---
>>>  .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c  | 16
>>> +++-
>>>  1 file changed, 11 insertions(+), 5 deletions(-)
>>>
>>> diff --git
>>> a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>>> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>>> index c7c1e9906500..510a76d99eee 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
>>> @@ -462,8 +462,14 @@ static void brcmf_fw_request_nvram_done(const
>>> struct firmware *fw, void *ctx)
>>>  raw_nvram = false;
>>>  } else {
>>>  data = bcm47xx_nvram_get_contents(_len);
>>> -if (!data && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
>>> -goto fail;
>>> +if (!data) {
>>> +brcmf_dbg(TRACE, "Failed to get platform NVRAM\n");
>>> +if (!(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL)) {
>>> +brcmf_err("Loading NVRAM from %s and using platform
>>> one both failed\n",
>>> +  fwctx->nvram_name);
>>> +goto fail;
>>> +}
>>> +}
>>>  raw_nvram = true;
>>>  }
>>>
>>> @@ -504,9 +510,9 @@ static void brcmf_fw_request_code_done(const
>>> struct firmware *fw, void *ctx)
>>>  return;
>>>  }
>>>  fwctx->code = fw;
>>> -ret = request_firmware_nowait(THIS_MODULE, true, fwctx->nvram_name,
>>> -  fwctx->dev, GFP_KERNEL, fwctx,
>>> -  brcmf_fw_request_nvram_done);
>>> +ret = request_firmware_async(THIS_MODULE, FW_OPT_NO_WARN,
>>> + fwctx->nvram_name, fwctx->dev, GFP_KERNEL,
>>> + fwctx, brcmf_fw_request_nvram_done);
>>
>> You changed the behaviour, because of your change in patch 1/2:
>>
>> -fw_work->opt_flags = FW_OPT_NOWAIT | FW_OPT_FALLBACK |
>> -(uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
>> +fw_work->opt_flags = FW_OPT_NOWAIT | opt_flags;
>>
>> So: (FW_OPT_NOWAIT | FW_OPT_UEVENT) vs (FW_OPT_NOWAIT | FW_OPT_NO_WARN)
> 
> Sorry, I didn't realize brcmfmac needs FW_OPT_UEVENT. I'll re-add it in
> V3, just
> let me wait to see if there will be more comments.

To be honest whether or not FW_OPT_UEVENT is needed should not be
something a driver needs to concern about. It is really a system
configuration issue if you ask me. So the only thing we could do is to
have it just in case.

Regards,
Arend

Re: [PATCH V2 2/2] brcmfmac: don't warn user about NVRAM if fallback to platform one succeeds

[Arend Van Spriel]

On 16-2-2017 8:26, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Failing to load NVRAM file isn't critical if we manage to get platform
> one in the fallback path. It means warnings like:
> [   10.801506] brcmfmac :01:00.0: Direct firmware load for 
> brcm/brcmfmac43602-pcie.txt failed with error -2
> are unnecessary & disturbing for people with platform NVRAM. This is
> very common case for Broadcom home routers.
> 
> So instead of printing warning immediately with the firmware subsystem
> let's first try our fallback code. If that fails as well, then it's a
> right moment to print an error.
> 
> This should reduce amount of false reports from users seeing this
> warning while having wireless working perfectly fine.

There are of course people with issues who take this warning as a straw
to clutch.

> Signed-off-by: Rafał Miłecki 
> ---
> V2: Update commit message as it wasn't clear enough (thanks Andy) & add extra
> messages to the firmware.c.
> 
> Kalle, Arend: this patch is strictly related to the bigger 1/2. Could you ack
> this change as I expect this patchset to be picked by Ming, Luis or Greg?
> ---
>  .../net/wireless/broadcom/brcm80211/brcmfmac/firmware.c  | 16 
> +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> index c7c1e9906500..510a76d99eee 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
> @@ -462,8 +462,14 @@ static void brcmf_fw_request_nvram_done(const struct 
> firmware *fw, void *ctx)
>   raw_nvram = false;
>   } else {
>   data = bcm47xx_nvram_get_contents(_len);
> - if (!data && !(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL))
> - goto fail;
> + if (!data) {
> + brcmf_dbg(TRACE, "Failed to get platform NVRAM\n");
> + if (!(fwctx->flags & BRCMF_FW_REQ_NV_OPTIONAL)) {
> + brcmf_err("Loading NVRAM from %s and using 
> platform one both failed\n",
> +   fwctx->nvram_name);
> + goto fail;
> + }
> + }
>   raw_nvram = true;
>   }
>  
> @@ -504,9 +510,9 @@ static void brcmf_fw_request_code_done(const struct 
> firmware *fw, void *ctx)
>   return;
>   }
>   fwctx->code = fw;
> - ret = request_firmware_nowait(THIS_MODULE, true, fwctx->nvram_name,
> -   fwctx->dev, GFP_KERNEL, fwctx,
> -   brcmf_fw_request_nvram_done);
> + ret = request_firmware_async(THIS_MODULE, FW_OPT_NO_WARN,
> +  fwctx->nvram_name, fwctx->dev, GFP_KERNEL,
> +  fwctx, brcmf_fw_request_nvram_done);

You changed the behaviour, because of your change in patch 1/2:

-   fw_work->opt_flags = FW_OPT_NOWAIT | FW_OPT_FALLBACK |
-   (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
+   fw_work->opt_flags = FW_OPT_NOWAIT | opt_flags;

So: (FW_OPT_NOWAIT | FW_OPT_UEVENT) vs (FW_OPT_NOWAIT | FW_OPT_NO_WARN)

Regards,
Arend

Re: [PATCH 2/2] brcmfmac: don't warn user if loading firmware file with NVRAM fails

[Rafał Miłecki]

On 2017-02-16 02:19, Andy Shevchenko wrote:
On Thu, Feb 16, 2017 at 12:29 AM, Rafał Miłecki  
wrote:

From: Rafał Miłecki 

This isn't critical as we use platform NVRAM as fallback and it's very
common case of all Broadcom home routers. Thanks for the new firmware
loading function we can achieve this by simply passing FW_OPT_NO_WARN.



What kind of warning you are talking about?

On Intel Edison brcmfmac isn't backed up by NVRAM (there no such) and
the platform is not ACPI-based. The warning might be crucial for
debugging Wi-Fi issues on such platforms.


Sorry, I should have tried better with that commit message. V2 in a 
second.