Re: [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.

2017-05-10 Thread Kalle Valo 
Su Kang Yin  writes:

> On 11 May 2017 at 11:55, Kalle Valo wrote:
>> Su Kang Yin writes:
>>
>>> Without this patch QCA9888 is not working. Also I have to update
>>> board2.bin from Kalle's git repo.
>>
>> More details would be good to know, as the behaviour seems to vary quite
>> a lot. What platform are you using, x86, some ARM board or what? And
>> what kernel exactly?
>
> Kernel 4.9.25 on X86 Intel Atom
>
> Panic message is something like that:

Thanks, this was very helpful.

-- 
Kalle Valo

Re: [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.

2017-05-10 Thread Su Kang Yin 
On 11 May 2017 at 11:55, Kalle Valo wrote:
> Su Kang Yin writes:
>
>> Without this patch QCA9888 is not working. Also I have to update
>> board2.bin from Kalle's git repo.
>
> More details would be good to know, as the behaviour seems to vary quite
> a lot. What platform are you using, x86, some ARM board or what? And
> what kernel exactly?

Kernel 4.9.25 on X86 Intel Atom

Panic message is something like that:

Workqueue: ath10k_aux_wq ath10k_wmi_event_service_ready_work [ath10k_core]
task: 880036433a00 ti: 88003644 task.ti: 88003644
RIP: 0010:[]  [] new_slab+0x39a/0x410
RSP: 0018:880036443b58  EFLAGS: 00010092
RAX: 0006 RBX: 024082c4 RCX: 
RDX: 0006 RSI: 88021e30dd08 RDI: 88021e30dd08
RBP: 880036443b90 R08:  R09: 
R10:  R11: 0372 R12: 88021dc01200
R13: 88021dc00cc0 R14: 88021dc01200 R15: 0001
FS:  () GS:88021e30() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f3e65c1c730 CR3: 01e06000 CR4: 001406e0
Stack:
  8127a4fc 0a01ff10 024082c4 88021dc01200
  88021dc00cc0 88021dc01200 0001 880036443c58
  81247ac6 88021e31b360 880036433a00 880036433a00
Call Trace:
  [] ? __d_lookup+0x9c/0x160
  [] ___slab_alloc+0x396/0x4a0
  [] ?
ath10k_wmi_event_service_ready_work+0x5ad/0x800 [ath10k_core]
  [] ? alloc_kmem_pages+0x9/0x10
  [] ? kmalloc_order+0x13/0x40
  [] ?
ath10k_wmi_event_service_ready_work+0x5ad/0x800 [ath10k_core]

-- Yin

Re: [PATCH] [ath10k] go back to using dma_alloc_coherent() for firmware scratch memory.

2017-05-10 Thread Kalle Valo 
Su Kang Yin  writes:

> Without this patch QCA9888 is not working. Also I have to update
> board2.bin from Kalle's git repo.

More details would be good to know, as the behaviour seems to vary quite
a lot. What platform are you using, x86, some ARM board or what? And
what kernel exactly?

-- 
Kalle Valo

Re: [PATCH] libertas: Avoid reading past end of buffer

2017-05-10 Thread Kalle Valo 
Joe Perches  writes:

> unrelated trivia:
>
> lbs_deb_enter is used incorrectly here at
> function exit as both enter and leave calls.
>
> That type of copy/paste defect may be common.
>
> $ git grep -w lbs_deb_enter | wc -l
> 148
> $ git grep -w lbs_deb_leave | wc -l
> 71
>
> One would expect these numbers to be the same.
>
> Another option would be to delete all these
> calls as ftrace function tracing works well.

Yeah, deleting all the enter/exit calls would be better.

-- 
Kalle Valo

Re: [PATCH] libertas: Avoid reading past end of buffer

2017-05-10 Thread Joe Perches 
On Wed, 2017-05-10 at 12:24 -0700, Kees Cook wrote:
> Using memcpy() from a string that is shorter than the length copied means
> the destination buffer is being filled with arbitrary data from the kernel
> rodata segment. 

another bit of trivia:

> diff --git a/drivers/net/wireless/marvell/libertas/mesh.c 
> b/drivers/net/wireless/marvell/libertas/mesh.c
[]
> @@ -1170,17 +1170,11 @@ int lbs_mesh_ethtool_get_sset_count(struct net_device 
> *dev, int sset)
[]
> + memcpy(s, *mesh_stat_strings, sizeof(mesh_stat_strings));

That * isn't necessary.

Re: [PATCH] libertas: Avoid reading past end of buffer

2017-05-10 Thread Joe Perches 
On Wed, 2017-05-10 at 12:24 -0700, Kees Cook wrote:
> Using memcpy() from a string that is shorter than the length copied means
[]
> diff --git a/drivers/net/wireless/marvell/libertas/mesh.c 
> b/drivers/net/wireless/marvell/libertas/mesh.c
[]
> @@ -1170,17 +1170,11 @@ int lbs_mesh_ethtool_get_sset_count(struct net_device 
> *dev, int sset)
>  void lbs_mesh_ethtool_get_strings(struct net_device *dev,
>   uint32_t stringset, uint8_t *s)
>  {
> - int i;
> -
>   lbs_deb_enter(LBS_DEB_ETHTOOL);
>  
>   switch (stringset) {
>   case ETH_SS_STATS:
> - for (i = 0; i < MESH_STATS_NUM; i++) {
> - memcpy(s + i * ETH_GSTRING_LEN,
> - mesh_stat_strings[i],
> - ETH_GSTRING_LEN);
> - }
> + memcpy(s, *mesh_stat_strings, sizeof(mesh_stat_strings));
>   break;
>   }
>   lbs_deb_enter(LBS_DEB_ETHTOOL);

unrelated trivia:

lbs_deb_enter is used incorrectly here at
function exit as both enter and leave calls.

That type of copy/paste defect may be common.

$ git grep -w lbs_deb_enter | wc -l
148
$ git grep -w lbs_deb_leave | wc -l
71

One would expect these numbers to be the same.

Another option would be to delete all these
calls as ftrace function tracing works well.

[PATCH] ath10k: add configurable debugging.

2017-05-10 Thread Adrian Chadd 
This adds a few configurable debugging options:

* driver debugging and tracing is now configurable per device
* driver debugging and tracing is now configurable at runtime
* the debugging / tracing is not run at all (besides a mask check)
  unless the specific debugging bitmap field is configured.

Signed-off-by: Adrian Chadd 
---
 drivers/net/wireless/ath/ath10k/core.c  |   2 +
 drivers/net/wireless/ath/ath10k/core.h  |   2 +
 drivers/net/wireless/ath/ath10k/debug.c | 101 
 drivers/net/wireless/ath/ath10k/debug.h |  44 +-
 4 files changed, 125 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index eea111d704c5..fcb068cb0248 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2444,6 +2444,8 @@ struct ath10k *ath10k_core_create(size_t priv_size, 
struct device *dev,
ar->hw_rev = hw_rev;
ar->hif.ops = hif_ops;
ar->hif.bus = bus;
+   ar->debug_mask = ath10k_debug_mask;
+   ar->trace_debug_mask = ath10k_debug_mask;
 
switch (hw_rev) {
case ATH10K_HW_QCA988X:
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 8fc08a5043db..07e392a377d0 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -762,6 +762,8 @@ struct ath10k {
struct device *dev;
u8 mac_addr[ETH_ALEN];
 
+   u32 debug_mask;
+   u32 trace_debug_mask;
enum ath10k_hw_rev hw_rev;
u16 dev_id;
u32 chip_id;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 389fcb7a9fd0..017360a26b40 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2418,6 +2418,79 @@ int ath10k_debug_create(struct ath10k *ar)
return 0;
 }
 
+#ifdef CONFIG_ATH10K_DEBUGFS
+static ssize_t ath10k_write_debug_mask(struct file *file,
+  const char __user *ubuf,
+  size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   int ret;
+   u32 val;
+
+if (kstrtou32_from_user(ubuf, count, 0, ))
+return -EINVAL;
+
+   ar->debug_mask = val;
+   ret = count;
+
+   return ret;
+}
+
+static ssize_t ath10k_read_debug_mask(struct file *file, char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+   char buf[32];
+   struct ath10k *ar = file->private_data;
+   int len = 0;
+
+   len = scnprintf(buf, sizeof(buf) - len, "0x%x\n", ar->debug_mask);
+   return simple_read_from_buffer(ubuf, count, ppos, buf, len);
+}
+
+static const struct file_operations fops_debug_mask = {
+   .read = ath10k_read_debug_mask,
+   .write = ath10k_write_debug_mask,
+   .open = simple_open
+};
+
+static ssize_t ath10k_write_trace_debug_mask(struct file *file,
+const char __user *ubuf,
+size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   int ret;
+   u32 val;
+
+if (kstrtou32_from_user(ubuf, count, 0, ))
+return -EINVAL;
+
+   ar->trace_debug_mask = val;
+   ret = count;
+
+   return ret;
+}
+
+static ssize_t ath10k_read_trace_debug_mask(struct file *file,
+   char __user *ubuf,
+   size_t count, loff_t *ppos)
+{
+   char buf[32];
+   struct ath10k *ar = file->private_data;
+   int len = 0;
+
+   len = scnprintf(buf, sizeof(buf) - len, "0x%x\n",
+   ar->trace_debug_mask);
+   return simple_read_from_buffer(ubuf, count, ppos, buf, len);
+}
+
+static const struct file_operations fops_trace_debug_mask = {
+   .read = ath10k_read_trace_debug_mask,
+   .write = ath10k_write_trace_debug_mask,
+   .open = simple_open
+};
+#endif /* CONFIG_ATH10K_DEBUGFS */
+
+
 void ath10k_debug_destroy(struct ath10k *ar)
 {
vfree(ar->debug.fw_crash_data);
@@ -2448,6 +2521,13 @@ int ath10k_debug_register(struct ath10k *ar)
init_completion(>debug.tpc_complete);
init_completion(>debug.fw_stats_complete);
 
+#ifdef CONFIG_ATH10K_DEBUG
+   debugfs_create_file("debug", S_IRUSR, ar->debug.debugfs_phy, ar,
+   _debug_mask);
+   debugfs_create_file("trace_debug", S_IRUSR, ar->debug.debugfs_phy, ar,
+   _trace_debug_mask);
+#endif
+
debugfs_create_file("fw_stats", 0400, ar->debug.debugfs_phy, ar,
_fw_stats);
 
@@ -2536,7 +2616,7 @@ void ath10k_debug_unregister(struct ath10k *ar)
 #endif /* CONFIG_ATH10K_DEBUGFS */
 
 #ifdef CONFIG_ATH10K_DEBUG
-void ath10k_dbg(struct ath10k

pull-request: iwlwifi firmwares update 2017-05-10

2017-05-10 Thread Luca Coelho 
Hi Kyle,

The last time we pushed new -22 firmwares, we forgot to update the
relevant version for 3168 devices.  This pull-request contains only this
update.

Please pull or let me know if there are any issues.

Cheers,
Luca.


The following changes since commit ade8332383e228cbdcfc605b5e5ef3aa51211401:

  Merge branch 'master' of git://git.marvell.com/mwifiex-firmware (2017-04-22 
11:25:59 -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-05-10

for you to fetch changes up to ca89d62df8fbeb0b8131437dfd5b8098c85f8164:

  iwlwifi: update -22 firmware for 3168 (2017-05-10 23:43:18 +0300)


Update firmware for 3168

* update -22 firmware binaries for iwlwifi device 3168


Emmanuel Grumbach (1):
  iwlwifi: update -22 firmware for 3168

 WHENCE|   2 +-
 iwlwifi-3168-22.ucode | Bin 1028032 -> 1028092 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)

[PATCH] libertas: Avoid reading past end of buffer

2017-05-10 Thread Kees Cook 
Using memcpy() from a string that is shorter than the length copied means
the destination buffer is being filled with arbitrary data from the kernel
rodata segment. Instead, redefine the stat strings to be ETH_GSTRING_LEN
sizes, like other drivers. This lets us use a single memcpy that does not
leak rodata contents. Additionally adjust indentation to keep checkpatch.pl
happy.

This was found with the future CONFIG_FORTIFY_SOURCE feature.

Cc: Daniel Micay 
Signed-off-by: Kees Cook 
---
v2: use ETH_GSTRING_LEN; joe
---
 drivers/net/wireless/marvell/libertas/mesh.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/marvell/libertas/mesh.c 
b/drivers/net/wireless/marvell/libertas/mesh.c
index d0c881dd5846..6076c83ce5ab 100644
--- a/drivers/net/wireless/marvell/libertas/mesh.c
+++ b/drivers/net/wireless/marvell/libertas/mesh.c
@@ -1108,15 +1108,15 @@ void lbs_mesh_set_txpd(struct lbs_private *priv,
  * Ethtool related
  */
 
-static const char * const mesh_stat_strings[] = {
-   "drop_duplicate_bcast",
-   "drop_ttl_zero",
-   "drop_no_fwd_route",
-   "drop_no_buffers",
-   "fwded_unicast_cnt",
-   "fwded_bcast_cnt",
-   "drop_blind_table",
-   "tx_failed_cnt"
+static const char mesh_stat_strings[MESH_STATS_NUM][ETH_GSTRING_LEN] = {
+   "drop_duplicate_bcast",
+   "drop_ttl_zero",
+   "drop_no_fwd_route",
+   "drop_no_buffers",
+   "fwded_unicast_cnt",
+   "fwded_bcast_cnt",
+   "drop_blind_table",
+   "tx_failed_cnt"
 };
 
 void lbs_mesh_ethtool_get_stats(struct net_device *dev,
@@ -1170,17 +1170,11 @@ int lbs_mesh_ethtool_get_sset_count(struct net_device 
*dev, int sset)
 void lbs_mesh_ethtool_get_strings(struct net_device *dev,
uint32_t stringset, uint8_t *s)
 {
-   int i;
-
lbs_deb_enter(LBS_DEB_ETHTOOL);
 
switch (stringset) {
case ETH_SS_STATS:
-   for (i = 0; i < MESH_STATS_NUM; i++) {
-   memcpy(s + i * ETH_GSTRING_LEN,
-   mesh_stat_strings[i],
-   ETH_GSTRING_LEN);
-   }
+   memcpy(s, *mesh_stat_strings, sizeof(mesh_stat_strings));
break;
}
lbs_deb_enter(LBS_DEB_ETHTOOL);
-- 
2.7.4


-- 
Kees Cook
Pixel Security

Re: [PATCH] libertas: Avoid reading past end of buffer

2017-05-10 Thread Kees Cook 
On Tue, May 9, 2017 at 9:33 PM, Joe Perches  wrote:
> On Tue, 2017-05-09 at 16:23 -0700, Kees Cook wrote:
>> Using memcpy() from a string that is shorter than the length copied means
>> the destination buffer is being filled with arbitrary data from the kernel
>> rodata segment. Instead, use strncpy() which will fill the trailing bytes
>> with zeros. Additionally adjust indentation to keep checkpatch.pl happy.
>>
>> This was found with the future CONFIG_FORTIFY_SOURCE feature.
> []
>> diff --git a/drivers/net/wireless/marvell/libertas/mesh.c 
>> b/drivers/net/wireless/marvell/libertas/mesh.c
> []
>> @@ -1177,9 +1177,9 @@ void lbs_mesh_ethtool_get_strings(struct net_device 
>> *dev,
>>   switch (stringset) {
>>   case ETH_SS_STATS:
>>   for (i = 0; i < MESH_STATS_NUM; i++) {
>> - memcpy(s + i * ETH_GSTRING_LEN,
>> - mesh_stat_strings[i],
>> - ETH_GSTRING_LEN);
>> + strncpy(s + i * ETH_GSTRING_LEN,
>> + mesh_stat_strings[i],
>> + ETH_GSTRING_LEN);
>>   }
>
> The better solution is to declare
> mesh_stat_strings in in the normal way
>
> ---
>  drivers/net/wireless/marvell/libertas/mesh.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas/mesh.c 
> b/drivers/net/wireless/marvell/libertas/mesh.c
> index d0c881dd5846..a535e7f48d2d 100644
> --- a/drivers/net/wireless/marvell/libertas/mesh.c
> +++ b/drivers/net/wireless/marvell/libertas/mesh.c
> @@ -1108,15 +1108,15 @@ void lbs_mesh_set_txpd(struct lbs_private *priv,
>   * Ethtool related
>   */
>
> -static const char * const mesh_stat_strings[] = {
> -   "drop_duplicate_bcast",
> -   "drop_ttl_zero",
> -   "drop_no_fwd_route",
> -   "drop_no_buffers",
> -   "fwded_unicast_cnt",
> -   "fwded_bcast_cnt",
> -   "drop_blind_table",
> -   "tx_failed_cnt"
> +static const char mesh_stat_strings[][ETH_GSTRING_LEN] = {
> +   "drop_duplicate_bcast",
> +   "drop_ttl_zero",
> +   "drop_no_fwd_route",
> +   "drop_no_buffers",
> +   "fwded_unicast_cnt",
> +   "fwded_bcast_cnt",
> +   "drop_blind_table",
> +   "tx_failed_cnt",
>  };
>
>  void lbs_mesh_ethtool_get_stats(struct net_device *dev,

Ah yeah! And that simplifies the memcpy too, since it can just do it
in one go. New patch on the way...

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH] wcn36xx: Close SMD channel on device removal

2017-05-10 Thread Bjorn Andersson 
On Wed 10 May 00:27 PDT 2017, Arend van Spriel wrote:

> On 5/10/2017 1:03 AM, Bjorn Andersson wrote:
> > On Mon 08 May 23:17 PDT 2017, Kalle Valo wrote:
> > 
> > > Bjorn Andersson  writes:
> > > 
> > > > The SMD channel is not the primary WCNSS channel and must explicitly be
> > > > closed as the device is removed, or the channel will already by open on
> > > > a subsequent probe call in e.g. the case of reloading the kernel module.
> > > > 
> > > > This issue was introduced because I simplified the underlying SMD
> > > > implementation while the SMD adaptions of the driver sat on the mailing
> > > > list, but missed to update these patches. The patch does however only
> > > > apply back to the transition to rpmsg, hence the limited Fixes.
> > > > 
> > > > Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from 
> > > > smd to rpmsg")
> > > > Reported-by: Eyal Ilsar 
> > > > Signed-off-by: Bjorn Andersson 
> > > 
> > > As this is a regression I'll queue this to 4.12.
> > > 
> > 
> > Thanks.
> > 
> > > But if this is an older bug (didn't quite understand your description
> > > though) should there be a separate patch for stable releases?
> > > 
> > 
> > AFAICT this never worked, as it seems I did the rework in SMD while we
> > tried to figure out the dependency issues we had with moving to SMD. So
> > v4.9 through v4.11 has SMD support - with this bug.
> > 
> > How do I proceed, do you want me to write up a fix for stable@? Do I
> > send that out as an ordinary patch?
> 
> If the patch applies cleanly on branches linux-4.9.y through linux-4.11.y in
> the stable repository you can go for '--- Option 1 ---' as described in
> /Documentation/stable_kernel_rules.txt.
> 

It does not, before v4.12 it's a completely different function to call
to close the channel.

But "Option 3" describes the situation, thanks for the reference. I'll
try to find the time to verify the patch on v4.11 and send it to
stable@.

Regards,
Bjorn

Re: [PATCH] ath10k: add configurable debugging.

2017-05-10 Thread Adrian Chadd 
grr, no. lemme go re-add that and resubmit.

thanks!


-a


On 10 May 2017 at 09:44, Steve deRosier  wrote:
> Hi Adrian,
>
> On Wed, May 10, 2017 at 9:25 AM, Adrian Chadd  wrote:
>
>> diff --git a/drivers/net/wireless/ath/ath10k/debug.h 
>> b/drivers/net/wireless/ath/ath10k/debug.h
>> index 257d10985c6e..7bd461927029 100644
>> --- a/drivers/net/wireless/ath/ath10k/debug.h
>> +++ b/drivers/net/wireless/ath/ath10k/debug.h
>> @@ -200,27 +200,43 @@ void ath10k_sta_update_rx_duration(struct ath10k *ar,
>>  #endif /* CONFIG_MAC80211_DEBUGFS */
>>
>>  #ifdef CONFIG_ATH10K_DEBUG
>> -__printf(3, 4) void ath10k_dbg(struct ath10k *ar,
>> +static inline int
>> +_ath10k_do_dbg(struct ath10k *ar, enum ath10k_debug_mask mask)
>> +{
>> +   if (ar->trace_debug_mask & mask)
>> +   return (1);
>> +   if (ar->debug_mask & mask)
>> +   return (1);
>> +   return (0);
>> +}
>> +
>> +void _ath10k_dbg(struct ath10k *ar,
>>enum ath10k_debug_mask mask,
>>const char *fmt, ...);
>> -void ath10k_dbg_dump(struct ath10k *ar,
>> +
>> +void _ath10k_dbg_dump(struct ath10k *ar,
>>  enum ath10k_debug_mask mask,
>>  const char *msg, const char *prefix,
>>  const void *buf, size_t len);
>> +
>> +#defineath10k_dbg(ar, mask, ...)
>>\
>> +   do {\
>> +   if (_ath10k_do_dbg(ar, mask)) { \
>> +   _ath10k_dbg((ar), (mask), __VA_ARGS__); \
>> +   };  \
>> +   } while (0)
>> +
>
> Looks to me you dropped the "__printf(3, 4)" safety check. Was that 
> intentional?
>
> Thanks,
> - Steve

Re: [PATCH] ath10k: add configurable debugging.

2017-05-10 Thread Steve deRosier 
Hi Adrian,

On Wed, May 10, 2017 at 9:25 AM, Adrian Chadd  wrote:

> diff --git a/drivers/net/wireless/ath/ath10k/debug.h 
> b/drivers/net/wireless/ath/ath10k/debug.h
> index 257d10985c6e..7bd461927029 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.h
> +++ b/drivers/net/wireless/ath/ath10k/debug.h
> @@ -200,27 +200,43 @@ void ath10k_sta_update_rx_duration(struct ath10k *ar,
>  #endif /* CONFIG_MAC80211_DEBUGFS */
>
>  #ifdef CONFIG_ATH10K_DEBUG
> -__printf(3, 4) void ath10k_dbg(struct ath10k *ar,
> +static inline int
> +_ath10k_do_dbg(struct ath10k *ar, enum ath10k_debug_mask mask)
> +{
> +   if (ar->trace_debug_mask & mask)
> +   return (1);
> +   if (ar->debug_mask & mask)
> +   return (1);
> +   return (0);
> +}
> +
> +void _ath10k_dbg(struct ath10k *ar,
>enum ath10k_debug_mask mask,
>const char *fmt, ...);
> -void ath10k_dbg_dump(struct ath10k *ar,
> +
> +void _ath10k_dbg_dump(struct ath10k *ar,
>  enum ath10k_debug_mask mask,
>  const char *msg, const char *prefix,
>  const void *buf, size_t len);
> +
> +#defineath10k_dbg(ar, mask, ...) 
>   \
> +   do {\
> +   if (_ath10k_do_dbg(ar, mask)) { \
> +   _ath10k_dbg((ar), (mask), __VA_ARGS__); \
> +   };  \
> +   } while (0)
> +

Looks to me you dropped the "__printf(3, 4)" safety check. Was that intentional?

Thanks,
- Steve

[PATCH] ath10k: add configurable debugging.

2017-05-10 Thread Adrian Chadd 
This adds a few configurable debugging options:

* driver debugging and tracing is now configurable per device
* driver debugging and tracing is now configurable at runtime
* the debugging / tracing is not run at all (besides a mask check)
  unless the specific debugging bitmap field is configured.

Signed-off-by: Adrian Chadd 
---
 drivers/net/wireless/ath/ath10k/core.c  |   2 +
 drivers/net/wireless/ath/ath10k/core.h  |   2 +
 drivers/net/wireless/ath/ath10k/debug.c | 101 
 drivers/net/wireless/ath/ath10k/debug.h |  44 +-
 4 files changed, 125 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index eea111d704c5..fcb068cb0248 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2444,6 +2444,8 @@ struct ath10k *ath10k_core_create(size_t priv_size, 
struct device *dev,
ar->hw_rev = hw_rev;
ar->hif.ops = hif_ops;
ar->hif.bus = bus;
+   ar->debug_mask = ath10k_debug_mask;
+   ar->trace_debug_mask = ath10k_debug_mask;
 
switch (hw_rev) {
case ATH10K_HW_QCA988X:
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 8fc08a5043db..07e392a377d0 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -762,6 +762,8 @@ struct ath10k {
struct device *dev;
u8 mac_addr[ETH_ALEN];
 
+   u32 debug_mask;
+   u32 trace_debug_mask;
enum ath10k_hw_rev hw_rev;
u16 dev_id;
u32 chip_id;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 389fcb7a9fd0..017360a26b40 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -2418,6 +2418,79 @@ int ath10k_debug_create(struct ath10k *ar)
return 0;
 }
 
+#ifdef CONFIG_ATH10K_DEBUGFS
+static ssize_t ath10k_write_debug_mask(struct file *file,
+  const char __user *ubuf,
+  size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   int ret;
+   u32 val;
+
+if (kstrtou32_from_user(ubuf, count, 0, ))
+return -EINVAL;
+
+   ar->debug_mask = val;
+   ret = count;
+
+   return ret;
+}
+
+static ssize_t ath10k_read_debug_mask(struct file *file, char __user *ubuf,
+ size_t count, loff_t *ppos)
+{
+   char buf[32];
+   struct ath10k *ar = file->private_data;
+   int len = 0;
+
+   len = scnprintf(buf, sizeof(buf) - len, "0x%x\n", ar->debug_mask);
+   return simple_read_from_buffer(ubuf, count, ppos, buf, len);
+}
+
+static const struct file_operations fops_debug_mask = {
+   .read = ath10k_read_debug_mask,
+   .write = ath10k_write_debug_mask,
+   .open = simple_open
+};
+
+static ssize_t ath10k_write_trace_debug_mask(struct file *file,
+const char __user *ubuf,
+size_t count, loff_t *ppos)
+{
+   struct ath10k *ar = file->private_data;
+   int ret;
+   u32 val;
+
+if (kstrtou32_from_user(ubuf, count, 0, ))
+return -EINVAL;
+
+   ar->trace_debug_mask = val;
+   ret = count;
+
+   return ret;
+}
+
+static ssize_t ath10k_read_trace_debug_mask(struct file *file,
+   char __user *ubuf,
+   size_t count, loff_t *ppos)
+{
+   char buf[32];
+   struct ath10k *ar = file->private_data;
+   int len = 0;
+
+   len = scnprintf(buf, sizeof(buf) - len, "0x%x\n",
+   ar->trace_debug_mask);
+   return simple_read_from_buffer(ubuf, count, ppos, buf, len);
+}
+
+static const struct file_operations fops_trace_debug_mask = {
+   .read = ath10k_read_trace_debug_mask,
+   .write = ath10k_write_trace_debug_mask,
+   .open = simple_open
+};
+#endif /* CONFIG_ATH10K_DEBUGFS */
+
+
 void ath10k_debug_destroy(struct ath10k *ar)
 {
vfree(ar->debug.fw_crash_data);
@@ -2448,6 +2521,13 @@ int ath10k_debug_register(struct ath10k *ar)
init_completion(>debug.tpc_complete);
init_completion(>debug.fw_stats_complete);
 
+#ifdef CONFIG_ATH10K_DEBUG
+   debugfs_create_file("debug", S_IRUSR, ar->debug.debugfs_phy, ar,
+   _debug_mask);
+   debugfs_create_file("trace_debug", S_IRUSR, ar->debug.debugfs_phy, ar,
+   _trace_debug_mask);
+#endif
+
debugfs_create_file("fw_stats", 0400, ar->debug.debugfs_phy, ar,
_fw_stats);
 
@@ -2536,7 +2616,7 @@ void ath10k_debug_unregister(struct ath10k *ar)
 #endif /* CONFIG_ATH10K_DEBUGFS */
 
 #ifdef CONFIG_ATH10K_DEBUG
-void ath10k_dbg(struct ath10k

Re: [v2,1/3] ath9k: Support channels in licensed bands

2017-05-10 Thread Ben Greear 

On 05/10/2017 03:30 AM, Tom Psyborg wrote:



On 9 May 2017 at 19:50, Adrian Chadd > wrote:


(Note note: some of those channels have non-megahertz boundaries,
which means ... yeah, hello inter-operability boundaries. Hilarious.)



-adrian



From what I can tell, it seems like as long as your both points are configured 
with identical settings, you can use any channel/frequency/bandwidth combination
that hardware supports. Possibly even 802.11ac at 2.4 GHz if we got more than 
100MHz of bandwidth from 2.4 to 2.5 GHz. The solution i've made myself doesn't
include all available channels but can serve as an example: 
https://forum.openwrt.org/viewtopic.php?pid=353870#p353870 primary/sec HT 
channel option should also
be further extended.

Cheers, Tom


I've successfully used 802.11ac VHT-40 on 2.4Ghz band with ath10k...it just 
requires a few small changes
in the mac80211 stack to allow it to be configuredjust FYI.

Thanks,
Ben

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

Re: Cubieboard2 + hostapd + 100 wireless devices

2017-05-10 Thread Marek Floriańczyk 
Dnia środa, 10 maja 2017 11:31:17 CEST Stanislaw Gruszka pisze:
> On Sun, May 07, 2017 at 02:19:25PM +0200, Marek Floriańczyk wrote:
>
> 
> If RT5370 works for you I would stick with it. RTxxx chips with rt2800
> driver are capable to support up to 190 stations with HW encryption and
> 11n aggregation (something that you are not interested). Theoretically
> more stations can be added and those should fallback to software
> encryption and frame aggregation will not be done, but I'm not sure if
> anyone test that.
> 
> I'm also not sure if many people test 11b, perhaps 11g would be better
> choice. BTW, what kernel version are you using (I'm curious if 11b
> still works on latest kernels) ?
> 
> Stanislaw

Hi,

Thanks for answer.
I'm using Linux cubieboard2 4.9.12-sunxi 
This is Armbian based on Debian Jessie

I'm using "b" mode on hostapd because our modules:
http://www.electrodragon.com/product/esp-12f-esp8266-wifi-board/
have +20dBm when in "b" mode - that's what docs say.

I still have problems when 80 devices are connected, after a few minutes some 
of them (10-20) deauthenticate with AP. 
When reporting from hostapd_cli, sta changes from:

flags=[AUTH][ASSOC][AUTHORIZED][SHORT_PREAMBLE][WMM]
aid=69
capability=0x31
listen_interval=100
supported_rates=8b 96 82 84 0c 18 30 60 6c 12 24 48
timeout_next=NULLFUNC POLL
dot11RSNAStatsSTAAddress=5c:cf:7f:ff:eb:ee
dot11RSNAStatsVersion=1
dot11RSNAStatsSelectedPairwiseCipher=00-50-f2-2
dot11RSNAStatsTKIPLocalMICFailures=0
dot11RSNAStatsTKIPRemoteMICFailures=0
hostapdWPAPTKState=11
hostapdWPAPTKGroupState=0
rx_packets=18
tx_packets=17
rx_bytes=3295
tx_bytes=3490
inactive_msec=134370
connected_time=832

To:

flags=[AUTH]
aid=0
capability=0x0
listen_interval=0
supported_rates=
timeout_next=NULLFUNC POLL
rx_packets=2
tx_packets=2
rx_bytes=48
tx_bytes=143
inactive_msec=1980

When I have only 20some devices it works always, but with more devices 
something goes wrong

I'm running hostapd in debug mode now, and I have found station:
2c:3a:e8:00:33:e0
That deauthenticate with AP, but I don't know why, 
reason_code=3 "station is leaving (or has left) IBSS or ESS"

Any help would be appreciated ;)

Best Regards
Marek
1494425876.349802: nl80211: BSS Event 59 (NL80211_CMD_FRAME) received for wlan2
1494425876.349952: nl80211: RX frame da=7c:dd:90:84:79:cc sa=2c:3a:e8:00:33:e0 bssid=7c:dd:90:84:79:cc freq=2437 ssi_signal=-43 fc=0xc0 seq_ctrl=0x450 stype=12 (WLAN_FC_STYPE_DEAUTH) len=26
1494425876.350132: wlan2: Event RX_MGMT (19) received
1494425876.350254: wlan2: mgmt::deauth
1494425876.350382: wlan2: deauthentication: STA=2c:3a:e8:00:33:e0 reason_code=3
1494425876.350518: 1494425876.350526: wlan2: STA 2c:3a:e8:00:33:e0 IEEE 802.11: deauthenticated
1494425876.350683: 1494425876.350691: wlan2: STA 2c:3a:e8:00:33:e0 MLME: MLME-DEAUTHENTICATE.indication(2c:3a:e8:00:33:e0, 3)
1494425876.350845: 1494425876.350853: wlan2: STA 2c:3a:e8:00:33:e0 MLME: MLME-DELETEKEYS.request(2c:3a:e8:00:33:e0)
1494425876.351468: nl80211: sta_remove -> DEL_STATION wlan2 2c:3a:e8:00:33:e0 --> 0 (Success)
1494425876.351681: ap_free_sta: cancel ap_handle_timer for 2c:3a:e8:00:33:e0
1494425876.351978: nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlan2
1494425876.352135: nl80211: Delete station 2c:3a:e8:00:33:e0
1494425876.352441: nl80211: BSS Event 59 (NL80211_CMD_FRAME) received for wlan2
1494425876.352599: nl80211: RX frame da=7c:dd:90:84:79:cc sa=2c:3a:e8:00:33:e0 bssid=7c:dd:90:84:79:cc freq=2437 ssi_signal=-41 fc=0xb0 seq_ctrl=0x460 stype=11 (WLAN_FC_STYPE_AUTH) len=30
1494425876.352783: wlan2: Event RX_MGMT (19) received
1494425876.352900: mgmt::auth
1494425876.353251: authentication: STA=2c:3a:e8:00:33:e0 auth_alg=0 auth_transaction=1 status_code=0 wep=0 seq_ctrl=0x460
1494425876.353425:   New STA
1494425876.354104: ap_sta_add: register ap_handle_timer timeout for 2c:3a:e8:00:33:e0 (300 seconds - ap_max_inactivity)
1494425876.354721: nl80211: sta_remove -> DEL_STATION wlan2 2c:3a:e8:00:33:e0 --> -2 (No such file or directory)
1494425876.354943: nl80211: Add STA 2c:3a:e8:00:33:e0
1494425876.355185:   * supported rates - hexdump(len=0): [NULL]
1494425876.355346:   * capability=0x0
1494425876.355458:   * aid=1 (UNASSOC_STA workaround)
1494425876.355675:   * listen_interval=0
1494425876.355810:   * flags set=0x0 mask=0xa0
1494425876.356195: 1494425876.356205: wlan2: STA 2c:3a:e8:00:33:e0 IEEE 802.11: authentication OK (open system)
1494425876.356594: 1494425876.356604: wlan2: STA 2c:3a:e8:00:33:e0 MLME: MLME-AUTHENTICATE.indication(2c:3a:e8:00:33:e0, OPEN_SYSTEM)
1494425876.356958: 1494425876.356966: wlan2: STA 2c:3a:e8:00:33:e0 MLME: MLME-DELETEKEYS.request(2c:3a:e8:00:33:e0)
1494425876.357128: authentication reply: STA=2c:3a:e8:00:33:e0 auth_alg=0 auth_transaction=2 resp=0 (IE len=0)
1494425876.357266: nl80211: send_mlme - da= 2c:3a:e8:00:33:e0 noack=0 freq=0 no_cck=0 offchanok=0 wait_time=0 fc=0xb0 (WLAN_FC_STYPE_AUTH) nlmode=3
1494425876.357400: nl80211: send_mlme -> send_frame

Re: [PATCH] mac80211: Validate michael MIC before attempting packet decode.

2017-05-10 Thread Jouni Malinen 
On Tue, May 09, 2017 at 02:16:31PM -0400, Michael Skeffington wrote:
> In order to allow wpa_supplicant to correctly identify a perceived WPA TKIP 
> key
> recovery attack the michael MIC must be checked before the packet decode is
> attempted.  A packet with an invalid MIC will always fail a decrypt check 
> which
> previously was being checked first.  Therefore the MIC failure bit of
> status flags
> describing the error would remain unset.

Which driver and WLAN hardware are you using? Michael MIC is encrypted,
so to be able to check that, the frame will obviously need to be
decrypted first. If that WEP decryption fails, this frame needs to be
dropped without indicating Michael MIC failure. WEP part here is
completely independent of Michael MIC.

It is possible that there is a driver that handles these steps in
hardware/firmware and if so, that driver may have a bug if you do not
see Michael MIC failures reported correctly. Anyway, as Johannes pointed
out, this part in mac80211 is in the correct sequence and that cannot be
changed since it would completely break TKIP for more or less all
software-based cases.

-- 
Jouni MalinenPGP id EFC895FA

Re: [PATCH] mac80211: Validate michael MIC before attempting packet decode.

2017-05-10 Thread Johannes Berg 
On Tue, 2017-05-09 at 14:16 -0400, Michael Skeffington wrote:
> In order to allow wpa_supplicant to correctly identify a perceived
> WPA TKIP key
> recovery attack the michael MIC must be checked before the packet
> decode is
> attempted.  A packet with an invalid MIC will always fail a decrypt
> check which
> previously was being checked first.  Therefore the MIC failure bit of
> status flags
> describing the error would remain unset.

This isn't how the Michael MIC works. I have no idea what problem
you're trying to solve, but this is not the solution.

johannes

Re: Cubieboard2 + hostapd + 100 wireless devices

2017-05-10 Thread Stanislaw Gruszka 
On Sun, May 07, 2017 at 02:19:25PM +0200, Marek Floriańczyk wrote:
> Hello all,
> 
> I need to set up such a configuration:
> Cubieboard2 with Debian Jessie, Hostapd 2.6 as an AP, usb wifi dongle + 100 
> devices with NodeMCU module:
> http://www.electrodragon.com/product/esp-12f-esp8266-wifi-board/
> 
> I'm using usb wifi dongle based on Ralink RT5370 Wireless Adapter,
> after I have switched hostapd network mode to "b" it works quite well (tested 
> with 70 devices). Only text commands are going to be send from server to 
> devices, so I don't need high speed, I need reliability.
> 
> Has someone any experience with such a setup ?
> Would one recommend different wifi dongle (maybe more powerful), with 
> different 
> chipset?

If RT5370 works for you I would stick with it. RTxxx chips with rt2800
driver are capable to support up to 190 stations with HW encryption and
11n aggregation (something that you are not interested). Theoretically
more stations can be added and those should fallback to software
encryption and frame aggregation will not be done, but I'm not sure if
anyone test that.

I'm also not sure if many people test 11b, perhaps 11g would be better
choice. BTW, what kernel version are you using (I'm curious if 11b
still works on latest kernels) ?

Stanislaw

[PATCH] ath9k: check ah->curchan when updating tx power

2017-05-10 Thread Stanislaw Gruszka 
When driver fail to reset card ah->curchan value stay NULL. When
later driver try to update tx power it oops by using ah->curchan
(calltrace is shown below).

This problem were reported at various places and for some it was
fixed by making ath9k_hw_chip_reset() do not fail. I have this bug
report on some oldish RHEL kernel with AR9285, however it's hard to
debug where reset fail when kernel OOPS, so I think this patch
should be applied. Hopefully ah->curchan is not used unconditionally
on other places until is initialized on ath9k_config().

ath: phy0: Chip reset failed
ath: phy0: Unable to reset hardware; reset status -22 (freq 2412 MHz)
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] ath9k_hw_set_txpowerlimit+0x25/0x80 [ath9k_hw]
Oops:  [#1] SMP

Call Trace:
 [] ? ath9k_cmn_update_txpow+0x1a/0x30 [ath9k_common]
 [] ? ath_complete_reset+0x4e/0x130 [ath9k]
 [] ? ath9k_start+0x127/0x1e0 [ath9k]
 [] ? ieee80211_do_open+0x30f/0x910 [mac80211]
 [] ? dev_open+0x8d/0xf0

Signed-off-by: Stanislaw Gruszka 
---
 drivers/net/wireless/ath/ath9k/common.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/common.c 
b/drivers/net/wireless/ath/ath9k/common.c
index c67d0e0..099f3d4 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -369,7 +369,7 @@ void ath9k_cmn_update_txpow(struct ath_hw *ah, u16 
cur_txpow,
 {
struct ath_regulatory *reg = ath9k_hw_regulatory(ah);
 
-   if (reg->power_limit != new_txpow)
+   if (ah->curchan && reg->power_limit != new_txpow)
ath9k_hw_set_txpowerlimit(ah, new_txpow, false);
 
/* read back in case value is clamped */
-- 
1.7.1

Re: [PATCH] wcn36xx: Close SMD channel on device removal

2017-05-10 Thread Arend van Spriel 

On 5/10/2017 1:03 AM, Bjorn Andersson wrote:

On Mon 08 May 23:17 PDT 2017, Kalle Valo wrote:


Bjorn Andersson  writes:


The SMD channel is not the primary WCNSS channel and must explicitly be
closed as the device is removed, or the channel will already by open on
a subsequent probe call in e.g. the case of reloading the kernel module.

This issue was introduced because I simplified the underlying SMD
implementation while the SMD adaptions of the driver sat on the mailing
list, but missed to update these patches. The patch does however only
apply back to the transition to rpmsg, hence the limited Fixes.

Fixes: 5052de8deff5 ("soc: qcom: smd: Transition client drivers from smd to 
rpmsg")
Reported-by: Eyal Ilsar 
Signed-off-by: Bjorn Andersson 


As this is a regression I'll queue this to 4.12.



Thanks.


But if this is an older bug (didn't quite understand your description
though) should there be a separate patch for stable releases?



AFAICT this never worked, as it seems I did the rework in SMD while we
tried to figure out the dependency issues we had with moving to SMD. So
v4.9 through v4.11 has SMD support - with this bug.

How do I proceed, do you want me to write up a fix for stable@? Do I
send that out as an ordinary patch?


If the patch applies cleanly on branches linux-4.9.y through 
linux-4.11.y in the stable repository you can go for '--- Option 1 ---' 
as described in /Documentation/stable_kernel_rules.txt.


Regards,
Arend