Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

[Larry Finger]

On 09/17/2016 03:59 PM, Jes Sorensen wrote:

Larry Finger  writes:

As soon as debugging is turned on, the logs are filled with messages
reporting the interrupt status. As this quantity is usually zero, this
output is not needed. In fact, there will be a report if the status is
not zero, thus the debug line in question could probably be deleted.
Rather than taking that action, I have changed it to only be printed
when the RTL8XXXU_DEBUG_USB bit is set in the debug mask.


Wrong flag, please add a RTL8XXXU_DEBUG_INTERRUPT flag instead and use
that.

Which device do you see this with?


OK. I will change the flag.

I found this with a TP-Link TL-MN8200ND, which has some variant of the RTL8188CU 
chip. It transmits, but I see no evidence that the receiver is functioning at 
all. The same is true for driver rtl8192cu. Only the driver from Realtek's web 
site actually works.


One other problem that I have found is that the debug option on module load 
seems to be ignored. So far, I've had to hard wire the flags. Once I find the 
reason, I'll send a patch for that as well.


Larry

Re: [PATCH 2/4] carl9170: fix debugfs crashes

[Greg KH]

On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote:
> Ben Greear reported:
> > I see lots of instability as soon as I load up the carl9710 NIC.
> > My application is going to be poking at it's debugfs files...
> >
> > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> > [carl9170] at addr 8801bc1208b0
> > Read of size 8 by task btserver/5888
> > ===
> > BUG kmalloc-256 (Tainted: GW  ): kasan: bad access detected
> > ---
> >
> > INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
> >...
> 
> This breakage was caused by the introduction of intermediate
> fops in debugfs by commit 9fd4dcece43a
> ("debugfs: prevent access to possibly dead file_operations at file open")

Because of this, these should all be backported to 4.7-stable, and
4.8-stable, right?

thanks,

greg k-h

Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

[Jes Sorensen]

Larry Finger  writes:
> As soon as debugging is turned on, the logs are filled with messages
> reporting the interrupt status. As this quantity is usually zero, this
> output is not needed. In fact, there will be a report if the status is
> not zero, thus the debug line in question could probably be deleted.
> Rather than taking that action, I have changed it to only be printed
> when the RTL8XXXU_DEBUG_USB bit is set in the debug mask.

Wrong flag, please add a RTL8XXXU_DEBUG_INTERRUPT flag instead and use
that.

Which device do you see this with?

Thanks,
Jes

Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

[Jes Sorensen]

Joe Perches  writes:
> On Sat, 2016-09-17 at 12:09 -0500, Larry Finger wrote:
>> As soon as debugging is turned on, the logs are filled with messages
>> reporting the interrupt status. As this quantity is usually zero, this
>> output is not needed. In fact, there will be a report if the status is
>> not zero, thus the debug line in question could probably be deleted.
>> Rather than taking that action, I have changed it to only be printed
>> when the RTL8XXXU_DEBUG_USB bit is set in the debug mask.
>
> There are many uses of
>   if (rtl8xxxu_debug & ) {
>   dev_info(dev, ...)
>
> Emitting debugging information at KERN_INFO is odd.

Not at all, it's a pain to enable it in debug fs post loading the
driver, especially if you need the output immediately during driver
init. That is why the flags are there.

> I think it'd be nicer to use dev_dbg for all these cases
> and as well use some new macro that includes the test
>
> Something like:
>
> #define rtl8xxxu_dbg(type, fmt, ...)  \
> do {  \
>   if (rtl8xxxu_debug & (type))\
>   dev_dbg(dev, fmt, ##__VA_ARGS__);   \
> } while (0)

Yuck yuck yuck, no thanks!

Any attempt of adding that kinda grossness to the driver will get a
NACK.

There is a reason the debug flag is there - it allows you to enable
specific items on driver load. If you enable that flag, expect to see
stuff in your log.

Jes

[PATCH 3/4] b43: fix debugfs crash

[Christian Lamparter]

This patch fixes a crash that happens because b43's
debugfs code expects file->f_op to be a pointer to
its own b43_debugfs_fops struct. This is no longer
the case since commit 9fd4dcece43a
("debugfs: prevent access to possibly dead file_operations at file open")

Reviewed-by: Nicolai Stange 
Signed-off-by: Christian Lamparter 
---
 drivers/net/wireless/broadcom/b43/debugfs.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/b43/debugfs.c 
b/drivers/net/wireless/broadcom/b43/debugfs.c
index b4bcd94..7704638 100644
--- a/drivers/net/wireless/broadcom/b43/debugfs.c
+++ b/drivers/net/wireless/broadcom/b43/debugfs.c
@@ -524,7 +524,8 @@ static ssize_t b43_debugfs_read(struct file *file, char 
__user *userbuf,
goto out_unlock;
}
 
-   dfops = container_of(file->f_op, struct b43_debugfs_fops, fops);
+   dfops = container_of(debugfs_real_fops(file),
+struct b43_debugfs_fops, fops);
if (!dfops->read) {
err = -ENOSYS;
goto out_unlock;
@@ -585,7 +586,8 @@ static ssize_t b43_debugfs_write(struct file *file,
goto out_unlock;
}
 
-   dfops = container_of(file->f_op, struct b43_debugfs_fops, fops);
+   dfops = container_of(debugfs_real_fops(file),
+struct b43_debugfs_fops, fops);
if (!dfops->write) {
err = -ENOSYS;
goto out_unlock;
-- 
2.9.3

[PATCH 4/4] b43legacy: fix debugfs crash

[Christian Lamparter]

This patch fixes a crash that happens because b43legacy's
debugfs code expects file->f_op to be a pointer to its own
b43legacy_debugfs_fops struct. This is no longer the case
since commit 9fd4dcece43a
("debugfs: prevent access to possibly dead file_operations at file open")

Reviewed-by: Nicolai Stange 
Signed-off-by: Christian Lamparter 
---
 drivers/net/wireless/broadcom/b43legacy/debugfs.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/b43legacy/debugfs.c 
b/drivers/net/wireless/broadcom/b43legacy/debugfs.c
index 090910e..82ef56e 100644
--- a/drivers/net/wireless/broadcom/b43legacy/debugfs.c
+++ b/drivers/net/wireless/broadcom/b43legacy/debugfs.c
@@ -221,7 +221,8 @@ static ssize_t b43legacy_debugfs_read(struct file *file, 
char __user *userbuf,
goto out_unlock;
}
 
-   dfops = container_of(file->f_op, struct b43legacy_debugfs_fops, fops);
+   dfops = container_of(debugfs_real_fops(file),
+struct b43legacy_debugfs_fops, fops);
if (!dfops->read) {
err = -ENOSYS;
goto out_unlock;
@@ -287,7 +288,8 @@ static ssize_t b43legacy_debugfs_write(struct file *file,
goto out_unlock;
}
 
-   dfops = container_of(file->f_op, struct b43legacy_debugfs_fops, fops);
+   dfops = container_of(debugfs_real_fops(file),
+struct b43legacy_debugfs_fops, fops);
if (!dfops->write) {
err = -ENOSYS;
goto out_unlock;
-- 
2.9.3

[PATCH 1/4] debugfs: introduce a public file_operations accessor

[Christian Lamparter]

This patch introduces an accessor which can be used
by the users of debugfs (drivers, fs, ...) to get the
original file_operations struct. It also removes the
REAL_FOPS_DEREF macro in file.c and converts the code
to use the public version.

Previously, REAL_FOPS_DEREF was only available within
the file.c of debugfs. But having a public getter
available for debugfs users is important as some
drivers (carl9170 and b43) use the pointer of the
original file_operations in conjunction with container_of()
within their debugfs implementations.

Reviewed-by: Nicolai Stange 
Signed-off-by: Christian Lamparter 
---
 fs/debugfs/file.c   | 13 +
 include/linux/debugfs.h | 17 +
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 592059f..309f4e9 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -97,9 +97,6 @@ EXPORT_SYMBOL_GPL(debugfs_use_file_finish);
 
 #define F_DENTRY(filp) ((filp)->f_path.dentry)
 
-#define REAL_FOPS_DEREF(dentry)\
-   ((const struct file_operations *)(dentry)->d_fsdata)
-
 static int open_proxy_open(struct inode *inode, struct file *filp)
 {
const struct dentry *dentry = F_DENTRY(filp);
@@ -112,7 +109,7 @@ static int open_proxy_open(struct inode *inode, struct file 
*filp)
goto out;
}
 
-   real_fops = REAL_FOPS_DEREF(dentry);
+   real_fops = debugfs_real_fops(filp);
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not clean up after itself at exit? */
@@ -143,7 +140,7 @@ static ret_type full_proxy_ ## name(proto)  
\
 {  \
const struct dentry *dentry = F_DENTRY(filp);   \
const struct file_operations *real_fops =   \
-   REAL_FOPS_DEREF(dentry);\
+   debugfs_real_fops(filp);\
int srcu_idx;   \
ret_type r; \
\
@@ -176,7 +173,7 @@ static unsigned int full_proxy_poll(struct file *filp,
struct poll_table_struct *wait)
 {
const struct dentry *dentry = F_DENTRY(filp);
-   const struct file_operations *real_fops = REAL_FOPS_DEREF(dentry);
+   const struct file_operations *real_fops = debugfs_real_fops(filp);
int srcu_idx;
unsigned int r = 0;
 
@@ -193,7 +190,7 @@ static unsigned int full_proxy_poll(struct file *filp,
 static int full_proxy_release(struct inode *inode, struct file *filp)
 {
const struct dentry *dentry = F_DENTRY(filp);
-   const struct file_operations *real_fops = REAL_FOPS_DEREF(dentry);
+   const struct file_operations *real_fops = debugfs_real_fops(filp);
const struct file_operations *proxy_fops = filp->f_op;
int r = 0;
 
@@ -241,7 +238,7 @@ static int full_proxy_open(struct inode *inode, struct file 
*filp)
goto out;
}
 
-   real_fops = REAL_FOPS_DEREF(dentry);
+   real_fops = debugfs_real_fops(filp);
real_fops = fops_get(real_fops);
if (!real_fops) {
/* Huh? Module did not cleanup after itself at exit? */
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 1438e23..4d3f0d1 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -45,6 +45,23 @@ extern struct dentry *arch_debugfs_dir;
 
 extern struct srcu_struct debugfs_srcu;
 
+/**
+ * debugfs_real_fops - getter for the real file operation
+ * @filp: a pointer to a struct file
+ *
+ * Must only be called under the protection established by
+ * debugfs_use_file_start().
+ */
+static inline const struct file_operations *debugfs_real_fops(struct file 
*filp)
+   __must_hold(_srcu)
+{
+   /*
+* Neither the pointer to the struct file_operations, nor its
+* contents ever change -- srcu_dereference() is not needed here.
+*/
+   return filp->f_path.dentry->d_fsdata;
+}
+
 #if defined(CONFIG_DEBUG_FS)
 
 struct dentry *debugfs_create_file(const char *name, umode_t mode,
-- 
2.9.3

[PATCH 2/4] carl9170: fix debugfs crashes

[Christian Lamparter]

Ben Greear reported:
> I see lots of instability as soon as I load up the carl9710 NIC.
> My application is going to be poking at it's debugfs files...
>
> BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0
> [carl9170] at addr 8801bc1208b0
> Read of size 8 by task btserver/5888
> ===
> BUG kmalloc-256 (Tainted: GW  ): kasan: bad access detected
> ---
>
> INFO: Allocated in seq_open+0x50/0x100 age=2690 cpu=2 pid=772
>...

This breakage was caused by the introduction of intermediate
fops in debugfs by commit 9fd4dcece43a
("debugfs: prevent access to possibly dead file_operations at file open")

Thankfully, the original/real fops are still available in d_fsdata.

Reported-by: Ben Greear 
Reviewed-by: Nicolai Stange 
Signed-off-by: Christian Lamparter 
---
 drivers/net/wireless/ath/carl9170/debug.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/carl9170/debug.c 
b/drivers/net/wireless/ath/carl9170/debug.c
index 01a0919..ad7ffd5 100644
--- a/drivers/net/wireless/ath/carl9170/debug.c
+++ b/drivers/net/wireless/ath/carl9170/debug.c
@@ -75,7 +75,7 @@ static ssize_t carl9170_debugfs_read(struct file *file, char 
__user *userbuf,
 
if (!ar)
return -ENODEV;
-   dfops = container_of(file->f_path.dentry->d_fsdata,
+   dfops = container_of(debugfs_real_fops(file),
 struct carl9170_debugfs_fops, fops);
 
if (!dfops->read)
@@ -128,7 +128,7 @@ static ssize_t carl9170_debugfs_write(struct file *file,
 
if (!ar)
return -ENODEV;
-   dfops = container_of(file->f_path.dentry->d_fsdata,
+   dfops = container_of(debugfs_real_fops(file),
 struct carl9170_debugfs_fops, fops);
if (!dfops->write)
return -ENOSYS;
-- 
2.9.3

rtl8821ae WiFi does not work

[Antony Polukhin]

Hi,

I have a rtl8821ae wifi and it is almost impossible to use. Please
help. Here are the details:


[1.] One line summary of the problem:
rtl8821ae WiFi does not work

[2.] Full description of the problem/report:
Download speed drops down to 50KB/s or less really often. Instead of
2.5 MB/s connection speed, I have an average of less than 100KB/s,
with rare peeks up to 2.5MB/s and common dropdowns to less that
50KB/s. Latency is huge: if I pause downloading at the speed of 50KB/s
and try to download some very simple web page, it may take a few
minutes.

Router info:

Vendor Netgear
Hardware Version WNDR4000
Firmware Version V1.0.2.4_9.1.86
GUI Language Version V1.0.2.4_2.1.17.1

Router firmware is up-to-date, I've updated it a few days ago. It uses
2.4GHz b/g/n and there's no way to disable 802.11n or force only
802.11b/g usage. Other Linux devices work well with that router.

[3.] Keywords:


[4.] Kernel version (from /proc/version):
Linux version 4.8.0-040800rc6-generic (kernel@gloin) (gcc version
6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11) ) #201609121119 SMP Mon Sep 12
15:21:03 UTC 2016

[5.] Output of Oops.. message:

[6.] A small shell script or example program which triggers the problem:

[7.] Environment:
Description:Ubuntu 16.04.1 LTS
Release:16.04

[7.1.] Software
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux antishkka-amd 4.8.0-040800rc6-generic #201609121119 SMP Mon Sep
12 15:21:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

GNU C5.4.0
GNU Make4.1
Binutils2.26.1
Util-linux2.27.1
Mount2.27.1
Module-init-tools22
E2fsprogs1.42.13
Pcmciautils018
PPP2.4.7
Linux C Library2.23
Dynamic linker (ldd)2.23
Linux C++ Library6.0.21
Procps3.3.10
Net-tools1.60
Kbd1.15.5
Console-tools1.15.5
Sh-utils8.25
Udev229
Wireless-tools30
Modules Loadedablk_helper ac acpi_cpufreq aesni_intel
aes_x86_64 ahci amdgpu amdkfd arc4 autofs4 battery binfmt_misc
bluetooth bnep btbcm btcoexist btintel btrtl btusb button ccm cfg80211
crc16 crc32c_intel crc32_pclmul crct10dif_pclmul cryptd ctr drm
drm_kms_helper efi_pstore efivarfs efivars ehci_hcd ehci_pci evdev
ext4 fam15h_power fat fb_sys_fops fjes fscrypto fuse gf128mul
ghash_clmulni_intel glue_helper i2c_algo_bit i2c_designware_core
i2c_designware_platform i2c_piix4 irqbypass jbd2 joydev k10temp kvm
kvm_amd libahci libata lp lrw mac80211 mbcache media mii nls_cp437
nls_utf8 parport parport_pc ppdev psmouse r8169 radeon rfcomm rfkill
rtl8821ae rtl_pci rtlwifi scsi_mod sd_mod serio_raw sg shpchp snd
snd_hda_codec snd_hda_codec_generic snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_core snd_hda_intel snd_hwdep snd_pcm
snd_rawmidi snd_seq snd_seq_device snd_seq_midi snd_seq_midi_event
snd_timer soundcore syscopyarea sysfillrect sysimgblt tpm tpm_tis
tpm_tis_core ttm usb_common usbcore uvcvideo vfat video videobuf2_core
videobuf2_memops videobuf2_v4l2 videobuf2_vmalloc videodev wmi
xhci_hcd xhci_pci

[7.2.] Processor information (from /proc/cpuinfo):
processor: 0
vendor_id: AuthenticAMD
cpu family: 21
model: 96
model name: AMD FX-8800P Radeon R7, 12 Compute Cores 4C+8G
stepping: 1
microcode: 0x6006110
cpu MHz: 1400.000
cache size: 1024 KB
physical id: 0
siblings: 4
core id: 0
cpu cores: 2
apicid: 16
initial apicid: 0
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl
nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor
ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand
lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse
3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm
topoext perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate
vmmcall fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock
nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter
pfthreshold avic overflow_recov
bugs: fxsave_leak sysret_ss_attrs null_seg
bogomips: 4192.20
TLB size: 1536 4K pages
clflush size: 64
cache_alignment: 64
address sizes: 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro acc_power [13]

processor: 1
vendor_id: AuthenticAMD
cpu family: 21
model: 96
model name: AMD FX-8800P Radeon R7, 12 Compute Cores 4C+8G
stepping: 1
microcode: 0x6006110
cpu MHz: 1400.000
cache size: 1024 KB
physical id: 0
siblings: 4
core id: 0
cpu cores: 2
apicid: 17
initial apicid: 1
fpu: yes
fpu_exception: yes
cpuid 

Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

[Joe Perches]

On Sat, 2016-09-17 at 12:09 -0500, Larry Finger wrote:
> As soon as debugging is turned on, the logs are filled with messages
> reporting the interrupt status. As this quantity is usually zero, this
> output is not needed. In fact, there will be a report if the status is
> not zero, thus the debug line in question could probably be deleted.
> Rather than taking that action, I have changed it to only be printed
> when the RTL8XXXU_DEBUG_USB bit is set in the debug mask.

There are many uses of
if (rtl8xxxu_debug & ) {
dev_info(dev, ...)

Emitting debugging information at KERN_INFO is odd.

I think it'd be nicer to use dev_dbg for all these cases
and as well use some new macro that includes the test

Something like:

#define rtl8xxxu_dbg(type, fmt, ...)\
do {\
if (rtl8xxxu_debug & (type))\
dev_dbg(dev, fmt, ##__VA_ARGS__);   \
} while (0)

> Signed-off-by: Larry Finger 
> ---
>  drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> 
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 9f6dbb4..236f33c 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -5260,7 +5260,8 @@ static void rtl8xxxu_int_complete(struct urb *urb)
>   struct device *dev = >udev->dev;
>   int ret;
>  
> - dev_dbg(dev, "%s: status %i\n", __func__, urb->status);
> + if (rtl8xxxu_debug & RTL8XXXU_DEBUG_USB)
> + dev_dbg(dev, "%s: status %i\n", __func__, urb->status);
>   if (urb->status == 0) {
>   usb_anchor_urb(urb, >int_anchor);
>   ret = usb_submit_urb(urb, GFP_ATOMIC);
> 
> 

Re: ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

Am 17.09.2016 um 18:14 schrieb Oleksij Rempel:
> Am 17.09.2016 um 17:52 schrieb bruce m beach:
 Hm.. found here one report about bad perfomance on this driver
 https://ubuntuforums.org/showthread.php?t=2312343

 affected persons seems to use WEP encryption.

 What encryption do are you using?
>>
>> I just wish I could do some testing on a single machine. Every test
>> suite I've seen always involves 2 machines. Why can't I use the wifi
>> chip on the mother board and the ar9271(a usb stick) to test basic
>> communications on the ar9271. The problem is I don't know where to begin.
>>
>> Bruce
>>
> 
> i didn't tried it myself:
> https://unix.stackexchange.com/questions/122050/send-traffic-to-self-over-physical-network-on-ubuntu
> 
> but last suggestion looks interesting.
> 

or this:
https://www.spinics.net/lists/netdev/msg152621.html

please share if you get it work :D

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: ath9k_htc kernel driver regression affecting throughput

[Oleksij Rempel]

Am 17.09.2016 um 17:52 schrieb bruce m beach:
>>> Hm.. found here one report about bad perfomance on this driver
>>> https://ubuntuforums.org/showthread.php?t=2312343
>>>
>>> affected persons seems to use WEP encryption.
>>>
>>> What encryption do are you using?
> 
> I just wish I could do some testing on a single machine. Every test
> suite I've seen always involves 2 machines. Why can't I use the wifi
> chip on the mother board and the ar9271(a usb stick) to test basic
> communications on the ar9271. The problem is I don't know where to begin.
> 
> Bruce
> 

i didn't tried it myself:
https://unix.stackexchange.com/questions/122050/send-traffic-to-self-over-physical-network-on-ubuntu

but last suggestion looks interesting.

-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

[PATCH 5/5] wlcore: wl18xx: Use chip specific configuration firmware

[Tony Lindgren]

Use the wl18xx specific config firmware we now have available.

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

diff --git a/drivers/net/wireless/ti/wl18xx/main.c 
b/drivers/net/wireless/ti/wl18xx/main.c
--- a/drivers/net/wireless/ti/wl18xx/main.c
+++ b/drivers/net/wireless/ti/wl18xx/main.c
@@ -1397,25 +1397,24 @@ static int wl18xx_get_pg_ver(struct wl1271 *wl, s8 *ver)
return ret;
 }
 
-#define WL18XX_CONF_FILE_NAME "ti-connectivity/wl18xx-conf.bin"
-
 static int wl18xx_load_conf_file(struct device *dev, struct wlcore_conf *conf,
-struct wl18xx_priv_conf *priv_conf)
+struct wl18xx_priv_conf *priv_conf,
+const char *file)
 {
struct wlcore_conf_file *conf_file;
const struct firmware *fw;
int ret;
 
-   ret = request_firmware(, WL18XX_CONF_FILE_NAME, dev);
+   ret = request_firmware(, file, dev);
if (ret < 0) {
wl1271_error("could not get configuration binary %s: %d",
-WL18XX_CONF_FILE_NAME, ret);
+file, ret);
return ret;
}
 
if (fw->size != WL18XX_CONF_SIZE) {
-   wl1271_error("configuration binary file size is wrong, expected 
%zu got %zu",
-WL18XX_CONF_SIZE, fw->size);
+   wl1271_error("%s configuration binary size is wrong, expected 
%zu got %zu",
+file, WL18XX_CONF_SIZE, fw->size);
ret = -EINVAL;
goto out_release;
}
@@ -1448,9 +1447,12 @@ static int wl18xx_load_conf_file(struct device *dev, 
struct wlcore_conf *conf,
 
 static int wl18xx_conf_init(struct wl1271 *wl, struct device *dev)
 {
+   struct platform_device *pdev = wl->pdev;
+   struct wlcore_platdev_data *pdata = dev_get_platdata(>dev);
struct wl18xx_priv *priv = wl->priv;
 
-   if (wl18xx_load_conf_file(dev, >conf, >conf) < 0) {
+   if (wl18xx_load_conf_file(dev, >conf, >conf,
+ pdata->family->cfg_name) < 0) {
wl1271_warning("falling back to default config");
 
/* apply driver default configuration */
@@ -2141,4 +2143,3 @@ MODULE_PARM_DESC(num_rx_desc_param,
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Luciano Coelho ");
 MODULE_FIRMWARE(WL18XX_FW_NAME);
-MODULE_FIRMWARE(WL18XX_CONF_FILE_NAME);
-- 
2.9.3

[PATCHv2 0/5] Fix wlcore config firwmare annoyances

[Tony Lindgren]

Hi all,

Here are some patches to fix the firmware loading for wl12xx/wl18xx
when the same rootfs is used on multiple WLAN chip variants.

Changes since v1:

- Fix copy paste typo for the SPI related changes as noted by
  Kalle Valo

- Fix uninitialized ret variable warning as noted by Kalle Valo

Regards,

Tony

Tony Lindgren (5):
  wlcore: Prepare family to fix nvs file handling
  wlcore: sdio: Populate config firmware data
  wlcore: spi: Populate config firmware data
  wlcore: Fix config firmware loading issues
  wlcore: wl18xx: Use chip specific configuration firmware

 drivers/net/wireless/ti/wl18xx/main.c | 19 
 drivers/net/wireless/ti/wlcore/boot.c | 15 --
 drivers/net/wireless/ti/wlcore/main.c | 36 ++-
 drivers/net/wireless/ti/wlcore/sdio.c | 76 +++
 drivers/net/wireless/ti/wlcore/spi.c  | 48 +--
 drivers/net/wireless/ti/wlcore/wlcore_i.h | 12 ++---
 6 files changed, 123 insertions(+), 83 deletions(-)

-- 
2.9.3

[PATCH 1/5] wlcore: Prepare family to fix nvs file handling

[Tony Lindgren]

Move struct wilink_family_data to be available for all TI WLAN
variants. And fix familiy typo, it should be just family.

Looks like wl12xx use two different nvs.bin files and wl18xx
uses a different conf.bin file.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/spi.c  | 12 
 drivers/net/wireless/ti/wlcore/wlcore_i.h |  7 +++
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -80,17 +80,13 @@
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
 
-struct wilink_familiy_data {
-   char name[8];
-};
-
-static const struct wilink_familiy_data *wilink_data;
+static const struct wilink_family_data *wilink_data;
 
-static const struct wilink_familiy_data wl18xx_data = {
+static const struct wilink_family_data wl18xx_data = {
.name = "wl18xx",
 };
 
-static const struct wilink_familiy_data wl12xx_data = {
+static const struct wilink_family_data wl12xx_data = {
.name = "wl12xx",
 };
 
@@ -461,7 +457,7 @@ static int wlcore_probe_of(struct spi_device *spi, struct 
wl12xx_spi_glue *glue,
return -ENODEV;
 
wilink_data = of_id->data;
-   dev_info(>dev, "selected chip familiy is %s\n",
+   dev_info(>dev, "selected chip family is %s\n",
 wilink_data->name);
 
if (of_find_property(dt_node, "clock-xtal", NULL))
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h 
b/drivers/net/wireless/ti/wlcore/wlcore_i.h
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -42,6 +42,12 @@
  */
 #define WL12XX_NVS_NAME "ti-connectivity/wl1271-nvs.bin"
 
+struct wilink_family_data {
+   const char *name;
+   const char *nvs_name;   /* wl12xx nvs file */
+   const char *cfg_name;   /* wl18xx cfg file */
+};
+
 #define WL1271_TX_SECURITY_LO16(s) ((u16)((s) & 0x))
 #define WL1271_TX_SECURITY_HI32(s) ((u32)(((s) >> 16) & 0x))
 #define WL1271_TX_SQN_POST_RECOVERY_PADDING 0xff
@@ -208,6 +214,7 @@ struct wl1271_if_operations {
 
 struct wlcore_platdev_data {
struct wl1271_if_operations *if_ops;
+   const struct wilink_family_data *family;
 
bool ref_clock_xtal;/* specify whether the clock is XTAL or not */
u32 ref_clock_freq; /* in Hertz */
-- 
2.9.3

[PATCH 3/5] wlcore: spi: Populate config firmware data

[Tony Lindgren]

Configure the config firmware names and make it available
in platform data.

Let's also fix the order of the struct wilink_family_data
while at it.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/spi.c | 42 
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -79,15 +79,19 @@
 #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
+static const struct wilink_family_data wl127x_data = {
+   .name = "wl127x",
+   .nvs_name = "ti-connectivity/wl127x-nvs.bin",
+};
 
-static const struct wilink_family_data *wilink_data;
+static const struct wilink_family_data wl128x_data = {
+   .name = "wl128x",
+   .nvs_name = "ti-connectivity/wl128x-nvs.bin",
+};
 
 static const struct wilink_family_data wl18xx_data = {
.name = "wl18xx",
-};
-
-static const struct wilink_family_data wl12xx_data = {
-   .name = "wl12xx",
+   .cfg_name = "ti-connectivity/wl18xx-conf.bin",
 };
 
 struct wl12xx_spi_glue {
@@ -425,10 +429,10 @@ static struct wl1271_if_operations spi_ops = {
 };
 
 static const struct of_device_id wlcore_spi_of_match_table[] = {
-   { .compatible = "ti,wl1271", .data = _data},
-   { .compatible = "ti,wl1273", .data = _data},
-   { .compatible = "ti,wl1281", .data = _data},
-   { .compatible = "ti,wl1283", .data = _data},
+   { .compatible = "ti,wl1271", .data = _data},
+   { .compatible = "ti,wl1273", .data = _data},
+   { .compatible = "ti,wl1281", .data = _data},
+   { .compatible = "ti,wl1283", .data = _data},
{ .compatible = "ti,wl1801", .data = _data},
{ .compatible = "ti,wl1805", .data = _data},
{ .compatible = "ti,wl1807", .data = _data},
@@ -456,9 +460,9 @@ static int wlcore_probe_of(struct spi_device *spi, struct 
wl12xx_spi_glue *glue,
if (!of_id)
return -ENODEV;
 
-   wilink_data = of_id->data;
+   pdev_data->family = of_id->data;
dev_info(>dev, "selected chip family is %s\n",
-wilink_data->name);
+pdev_data->family->name);
 
if (of_find_property(dt_node, "clock-xtal", NULL))
pdev_data->ref_clock_xtal = true;
@@ -475,13 +479,15 @@ static int wlcore_probe_of(struct spi_device *spi, struct 
wl12xx_spi_glue *glue,
 static int wl1271_probe(struct spi_device *spi)
 {
struct wl12xx_spi_glue *glue;
-   struct wlcore_platdev_data pdev_data;
+   struct wlcore_platdev_data *pdev_data;
struct resource res[1];
int ret;
 
-   memset(_data, 0x00, sizeof(pdev_data));
+   pdev_data = devm_kzalloc(>dev, sizeof(*pdev_data), GFP_KERNEL);
+   if (!pdev_data)
+   return -ENOMEM;
 
-   pdev_data.if_ops = _ops;
+   pdev_data->if_ops = _ops;
 
glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -505,7 +511,7 @@ static int wl1271_probe(struct spi_device *spi)
return PTR_ERR(glue->reg);
}
 
-   ret = wlcore_probe_of(spi, glue, _data);
+   ret = wlcore_probe_of(spi, glue, pdev_data);
if (ret) {
dev_err(glue->dev,
"can't get device tree parameters (%d)\n", ret);
@@ -518,7 +524,7 @@ static int wl1271_probe(struct spi_device *spi)
return ret;
}
 
-   glue->core = platform_device_alloc(wilink_data->name,
+   glue->core = platform_device_alloc(pdev_data->family->name,
   PLATFORM_DEVID_AUTO);
if (!glue->core) {
dev_err(glue->dev, "can't allocate platform_device\n");
@@ -539,8 +545,8 @@ static int wl1271_probe(struct spi_device *spi)
goto out_dev_put;
}
 
-   ret = platform_device_add_data(glue->core, _data,
-  sizeof(pdev_data));
+   ret = platform_device_add_data(glue->core, pdev_data,
+  sizeof(*pdev_data));
if (ret) {
dev_err(glue->dev, "can't add platform data\n");
goto out_dev_put;
-- 
2.9.3

[PATCH 4/5] wlcore: Fix config firmware loading issues

[Tony Lindgren]

Booting multiple wl12xx and wl18xx devices using the same rootfs is
a pain. You currently have to symlink the right nvs file depending
on the wl12xx type.

For example, with wl1271-nvs.bin being a symlink to wl127x-nvs.bin
by default and trying to bring up a wl128x based device:

wlcore: ERROR nvs size is not as expected: 1113 != 912
wlcore: ERROR NVS file is needed during boot
wlcore: ERROR NVS file is needed during boot
wlcore: ERROR firmware boot failed despite 3 retries

Note that wl18xx uses a separate config firmware wl18xx-conf.bin
that can be generated with tools using the following two git repos:

git.ti.com/wilink8-wlan/18xx-ti-utils
git.ti.com/wilink8-wlan/wl18xx_fw

So let's not configure the nvs file for wl18xx as it's not needed
AFAIK. If it turns out that we also need the nvs file for wl18xx,
we can just add it to the config firmware data for wl18xx.

Let's fix the issue by using the chip specific config firmware
data, and make sure we produce understandable warnings if something
is missing.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/boot.c | 15 +
 drivers/net/wireless/ti/wlcore/main.c | 36 ---
 drivers/net/wireless/ti/wlcore/wlcore_i.h |  7 --
 3 files changed, 35 insertions(+), 23 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/boot.c 
b/drivers/net/wireless/ti/wlcore/boot.c
--- a/drivers/net/wireless/ti/wlcore/boot.c
+++ b/drivers/net/wireless/ti/wlcore/boot.c
@@ -282,6 +282,9 @@ EXPORT_SYMBOL_GPL(wlcore_boot_upload_firmware);
 
 int wlcore_boot_upload_nvs(struct wl1271 *wl)
 {
+   struct platform_device *pdev = wl->pdev;
+   struct wlcore_platdev_data *pdev_data = dev_get_platdata(>dev);
+   const char *nvs_name = "unknown";
size_t nvs_len, burst_len;
int i;
u32 dest_addr, val;
@@ -293,6 +296,9 @@ int wlcore_boot_upload_nvs(struct wl1271 *wl)
return -ENODEV;
}
 
+   if (pdev_data && pdev_data->family)
+   nvs_name = pdev_data->family->nvs_name;
+
if (wl->quirks & WLCORE_QUIRK_LEGACY_NVS) {
struct wl1271_nvs_file *nvs =
(struct wl1271_nvs_file *)wl->nvs;
@@ -310,8 +316,9 @@ int wlcore_boot_upload_nvs(struct wl1271 *wl)
if (wl->nvs_len != sizeof(struct wl1271_nvs_file) &&
(wl->nvs_len != WL1271_INI_LEGACY_NVS_FILE_SIZE ||
 wl->enable_11a)) {
-   wl1271_error("nvs size is not as expected: %zu != %zu",
-   wl->nvs_len, sizeof(struct wl1271_nvs_file));
+   wl1271_error("%s size is not as expected: %zu != %zu",
+nvs_name, wl->nvs_len,
+sizeof(struct wl1271_nvs_file));
kfree(wl->nvs);
wl->nvs = NULL;
wl->nvs_len = 0;
@@ -328,8 +335,8 @@ int wlcore_boot_upload_nvs(struct wl1271 *wl)
if (nvs->general_params.dual_mode_select)
wl->enable_11a = true;
} else {
-   wl1271_error("nvs size is not as expected: %zu != %zu",
-wl->nvs_len,
+   wl1271_error("%s size is not as expected: %zu != %zu",
+nvs_name, wl->nvs_len,
 sizeof(struct wl128x_nvs_file));
kfree(wl->nvs);
wl->nvs = NULL;
diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -6413,9 +6413,12 @@ static void wlcore_nvs_cb(const struct firmware *fw, 
void *context)
goto out;
}
wl->nvs_len = fw->size;
-   } else {
+   } else if (pdev_data->family->nvs_name) {
wl1271_debug(DEBUG_BOOT, "Could not get nvs file %s",
-WL12XX_NVS_NAME);
+pdev_data->family->nvs_name);
+   wl->nvs = NULL;
+   wl->nvs_len = 0;
+   } else {
wl->nvs = NULL;
wl->nvs_len = 0;
}
@@ -6510,21 +6513,29 @@ static void wlcore_nvs_cb(const struct firmware *fw, 
void *context)
 
 int wlcore_probe(struct wl1271 *wl, struct platform_device *pdev)
 {
-   int ret;
+   struct wlcore_platdev_data *pdev_data = dev_get_platdata(>dev);
+   const char *nvs_name;
+   int ret = 0;
 
-   if (!wl->ops || !wl->ptable)
+   if (!wl->ops || !wl->ptable || !pdev_data)
return -EINVAL;
 
wl->dev = >dev;
wl->pdev = pdev;
platform_set_drvdata(pdev, wl);
 
-   ret = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
- 

[PATCH 2/5] wlcore: sdio: Populate config firmware data

[Tony Lindgren]

Configure the config firmware names and make it available
in platform data.

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

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -216,17 +216,33 @@ static struct wl1271_if_operations sdio_ops = {
 };
 
 #ifdef CONFIG_OF
+
+static const struct wilink_family_data wl127x_data = {
+   .name = "wl127x",
+   .nvs_name = "ti-connectivity/wl127x-nvs.bin",
+};
+
+static const struct wilink_family_data wl128x_data = {
+   .name = "wl128x",
+   .nvs_name = "ti-connectivity/wl128x-nvs.bin",
+};
+
+static const struct wilink_family_data wl18xx_data = {
+   .name = "wl18xx",
+   .cfg_name = "ti-connectivity/wl18xx-conf.bin",
+};
+
 static const struct of_device_id wlcore_sdio_of_match_table[] = {
-   { .compatible = "ti,wl1271" },
-   { .compatible = "ti,wl1273" },
-   { .compatible = "ti,wl1281" },
-   { .compatible = "ti,wl1283" },
-   { .compatible = "ti,wl1801" },
-   { .compatible = "ti,wl1805" },
-   { .compatible = "ti,wl1807" },
-   { .compatible = "ti,wl1831" },
-   { .compatible = "ti,wl1835" },
-   { .compatible = "ti,wl1837" },
+   { .compatible = "ti,wl1271", .data = _data },
+   { .compatible = "ti,wl1273", .data = _data },
+   { .compatible = "ti,wl1281", .data = _data },
+   { .compatible = "ti,wl1283", .data = _data },
+   { .compatible = "ti,wl1801", .data = _data },
+   { .compatible = "ti,wl1805", .data = _data },
+   { .compatible = "ti,wl1807", .data = _data },
+   { .compatible = "ti,wl1831", .data = _data },
+   { .compatible = "ti,wl1835", .data = _data },
+   { .compatible = "ti,wl1837", .data = _data },
{ }
 };
 
@@ -234,9 +250,13 @@ static int wlcore_probe_of(struct device *dev, int *irq,
   struct wlcore_platdev_data *pdev_data)
 {
struct device_node *np = dev->of_node;
+   const struct of_device_id *of_id;
+
+   of_id = of_match_node(wlcore_sdio_of_match_table, np);
+   if (!of_id)
+   return -ENODEV;
 
-   if (!np || !of_match_node(wlcore_sdio_of_match_table, np))
-   return -ENODATA;
+   pdev_data->family = of_id->data;
 
*irq = irq_of_parse_and_map(np, 0);
if (!*irq) {
@@ -263,7 +283,7 @@ static int wlcore_probe_of(struct device *dev, int *irq,
 static int wl1271_probe(struct sdio_func *func,
  const struct sdio_device_id *id)
 {
-   struct wlcore_platdev_data pdev_data;
+   struct wlcore_platdev_data *pdev_data;
struct wl12xx_sdio_glue *glue;
struct resource res[1];
mmc_pm_flag_t mmcflags;
@@ -275,14 +295,15 @@ static int wl1271_probe(struct sdio_func *func,
if (func->num != 0x02)
return -ENODEV;
 
-   memset(_data, 0x00, sizeof(pdev_data));
-   pdev_data.if_ops = _ops;
+   pdev_data = devm_kzalloc(>dev, sizeof(*pdev_data), GFP_KERNEL);
+   if (!pdev_data)
+   return -ENOMEM;
 
-   glue = kzalloc(sizeof(*glue), GFP_KERNEL);
-   if (!glue) {
-   dev_err(>dev, "can't allocate glue\n");
-   goto out;
-   }
+   pdev_data->if_ops = _ops;
+
+   glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
+   if (!glue)
+   return -ENOMEM;
 
glue->dev = >dev;
 
@@ -292,16 +313,16 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
-   ret = wlcore_probe_of(>dev, , _data);
+   ret = wlcore_probe_of(>dev, , pdev_data);
if (ret)
-   goto out_free_glue;
+   goto out;
 
/* if sdio can keep power while host is suspended, enable wow */
mmcflags = sdio_get_host_pm_caps(func);
dev_dbg(glue->dev, "sdio PM caps = 0x%x\n", mmcflags);
 
if (mmcflags & MMC_PM_KEEP_POWER)
-   pdev_data.pwr_in_suspend = true;
+   pdev_data->pwr_in_suspend = true;
 
sdio_set_drvdata(func, glue);
 
@@ -323,7 +344,7 @@ static int wl1271_probe(struct sdio_func *func,
if (!glue->core) {
dev_err(glue->dev, "can't allocate platform_device");
ret = -ENOMEM;
-   goto out_free_glue;
+   goto out;
}
 
glue->core->dev.parent = >dev;
@@ -341,8 +362,8 @@ static int wl1271_probe(struct sdio_func *func,
goto out_dev_put;
}
 
-   ret = platform_device_add_data(glue->core, _data,
-  sizeof(pdev_data));
+   ret = platform_device_add_data(glue->core, pdev_data,
+

ath9k_htc kernel driver regression affecting throughput

[bruce m beach]

>> Hm.. found here one report about bad perfomance on this driver
>> https://ubuntuforums.org/showthread.php?t=2312343
>>
>> affected persons seems to use WEP encryption.
>>
>> What encryption do are you using?

I just wish I could do some testing on a single machine. Every test
suite I've seen always involves 2 machines. Why can't I use the wifi
chip on the mother board and the ar9271(a usb stick) to test basic
communications on the ar9271. The problem is I don't know where to begin.

Bruce

Re: [PATCH 0/5] Fix wlcore config firwmare annoyances

[Tony Lindgren]

* Kalle Valo  [160917 08:25]:
> Tony Lindgren  writes:
> 
> > Hi all,
> >
> > Here are some patches to fix the firmware loading for wl12xx/wl18xx
> > when the same rootfs is used on multiple WLAN chip variants.
> >
> > Regards,
> >
> > Tony
> >
> > Tony Lindgren (5):
> >   wlcore: Prepare family to fix nvs file handling
> >   wlcore: sdio: Populate config firmware data
> >   wlcore: sdio: Populate config firmware data
> >   wlcore: Fix config firmware loading issues
> >   wlcore: wl18xx: Use chip specific configuration firmware
> 
> I saw a new warning which I think is a valid one:
> 
> drivers/net/wireless/ti/wlcore/main.c: In function 'wlcore_probe':
> drivers/net/wireless/ti/wlcore/main.c:6518:6: warning: 'ret' may be used 
> uninitialized in this function [-Wuninitialized]

Oops sorry about that, will check and repost.

Regards,

Tony

Re: mwifiex: fix error handling in mwifiex_create_custom_regdomain

[Kalle Valo]

Bob Copeland  wrote:
> smatch reports:
> 
> sta_cmdresp.c:1053 mwifiex_create_custom_regdomain() warn: possible memory 
> leak of 'regd'
> 
> Indeed, mwifiex_create_custom_regdomain() returns NULL in the
> case that channel is missing in the TLV without freeing regd.
> 
> Moreover, some other error paths in this function return ERR_PTR
> values which are assigned without checking to the regd field in
> the mwifiex_adapter struct.  The latter is only null-checked where
> used.
> 
> Fix by freeing regd in the error path, and only update
> priv->adapter->regd if the returned pointer is valid.
> 
> Cc: Amitkumar Karwar 
> Cc: Nishant Sarmukadam 
> Signed-off-by: Bob Copeland 

Thanks, 1 patch applied to wireless-drivers-next.git:

92ca4f92eca7 mwifiex: fix error handling in mwifiex_create_custom_regdomain

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9331337/

Re: [PATCH 0/5] Fix wlcore config firwmare annoyances

[Kalle Valo]

Tony Lindgren  writes:

> Hi all,
>
> Here are some patches to fix the firmware loading for wl12xx/wl18xx
> when the same rootfs is used on multiple WLAN chip variants.
>
> Regards,
>
> Tony
>
> Tony Lindgren (5):
>   wlcore: Prepare family to fix nvs file handling
>   wlcore: sdio: Populate config firmware data
>   wlcore: sdio: Populate config firmware data
>   wlcore: Fix config firmware loading issues
>   wlcore: wl18xx: Use chip specific configuration firmware

I saw a new warning which I think is a valid one:

drivers/net/wireless/ti/wlcore/main.c: In function 'wlcore_probe':
drivers/net/wireless/ti/wlcore/main.c:6518:6: warning: 'ret' may be used 
uninitialized in this function [-Wuninitialized]

-- 
Kalle Valo

Re: [1/1] rtl8xxxu: Implement 8192e specific power down sequence

[Kalle Valo]

Jes Sorensen  wrote:
> From: Jes Sorensen 
> 
> This powers down the 8192e correctly, or at least to the point where
> the firmware will load again, when reloading the driver module.
> 
> Signed-off-by: Jes Sorensen 

Thanks, 1 patch applied to wireless-drivers-next.git:

f1785fbf7c0b rtl8xxxu: Implement 8192e specific power down sequence

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9329843/

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

[Kalle Valo]

Johannes Berg  writes:

> On Sat, 2016-09-17 at 18:01 +0300, Kalle Valo wrote:
>> 
>> Sorry, I was unclear. I meant the whole file
> [...]

Argh, I meant the whole driver of course, not just the file.

> Ah, ok - yeah, I think you're right - I think the supported_band ones
> can be, for example, and probably others as well.

Maybe also some of the pci related.

-- 
Kalle Valo

Re: pull-request: iwlwifi-next 2016-09-15-2

[Kalle Valo]

Luca Coelho  writes:

> This is v2 of my pull-request.  I have fixed the compilation error with
> alpha (and possibly other) platforms.
>
> I'll send v2 of the changed patch as a reply to this email.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit 76f8c0e17edc6eba43f84952e5a87c7f50f69370:
>
>   iwlwifi: pcie: remove dead code (2016-08-30 14:16:43 +0300)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
> tags/iwlwifi-next-for-kalle-2016-09-15-2

Pulled, thanks.

-- 
Kalle Valo

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

[Johannes Berg]

On Sat, 2016-09-17 at 18:01 +0300, Kalle Valo wrote:
> 
> Sorry, I was unclear. I meant the whole file
[...]

Ah, ok - yeah, I think you're right - I think the supported_band ones
can be, for example, and probably others as well.

johannes

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

[Kalle Valo]

Johannes Berg  writes:

>> I guess some of these static variables could be also const, but
>> didn't check.
>
> I think both bitrates and channels can't be, due to cfg80211 writing
> some (global) flags there on init.

Sorry, I was unclear. I meant the whole file, not just what was in my
mail:

qtnfmac/cfg80211.c:static struct ieee80211_rate qtnf_rates[] = {
qtnfmac/cfg80211.c:static struct ieee80211_channel qtnf_channels_2ghz[] = {
qtnfmac/cfg80211.c:static struct ieee80211_supported_band qtnf_band_2ghz = {
qtnfmac/cfg80211.c:static struct ieee80211_channel qtnf_channels_5ghz[] = {
qtnfmac/cfg80211.c:static struct ieee80211_supported_band qtnf_band_5ghz = {
qtnfmac/cfg80211.c:static struct cfg80211_ops qtn_cfg80211_ops = {
qtnfmac/pcie.c:static struct qtnf_bus_ops qtnf_pcie_bus_ops = {
qtnfmac/pcie.c:static struct attribute *qtnf_sysfs_entries[] = {
qtnfmac/pcie.c:static struct attribute_group qtnf_attrs_group = {
qtnfmac/pcie.c:static struct pci_device_id qtnf_pcie_devid_table[] = {
qtnfmac/pcie.c:static struct pci_driver qtnf_pcie_drv_data = {

Anyway, nothing important. Just something which I started to wonder
while reading the code.
 
-- 
Kalle Valo

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

[Johannes Berg]

> drivers/net/wireless/quantenna/qtnfmac/event.c: In function
> `qtnf_event_handle_scan_complete':
> drivers/net/wireless/quantenna/qtnfmac/event.c:342:2: warning:
> passing argument 2 of `cfg80211_scan_done' makes pointer from integer
> without a cast [enabled by default]

Yes, cfg80211_scan_done() changed fairly recently for sure.

> ./include/net/cfg80211.h:4104:6: note: expected `struct
> cfg80211_scan_info *' but argument is of type `u32'
> drivers/net/wireless/quantenna/qtnfmac/cfg80211.c: In function
> `qtnf_virtual_intf_cleanup':
> drivers/net/wireless/quantenna/qtnfmac/cfg80211.c:1093:4: warning:
> passing argument 2 of `cfg80211_scan_done' makes pointer from integer
> without a cast [enabled by default]
> ./include/net/cfg80211.h:4104:6: note: expected `struct
> cfg80211_scan_info *' but argument is of type `int'
> 

These also seem related.

> > +F:   drivers/net/wireless/quantenna/qtnfmac

> The include directory is not listed.

Should really just stop after quantenna/ I'd think? As long as it's
just a single driver, you might as well claim maintenance over
everything there :)

> I guess some of these static variables could be also const, but
> didn't check.

I think both bitrates and channels can't be, due to cfg80211 writing
some (global) flags there on init.

johannes

Re: pull-request: iwlwifi 2016-09-15

[Kalle Valo]

Luca Coelho  writes:

> Hi Kalle,
>
> Here is one more patch intended for 4.8.  It's small and low risk, just
> moving some lines of code around, to prevent a firmware crash in
> certain situations.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit a904a08b5fee5317ff0f7b8212aa5d0776795a52:
>
>   iwlwifi: mvm: Advertise support for AP channel width change (2016-08-29 
> 22:29:06 +0300)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
> tags/iwlwifi-for-kalle-2016-09-15

Pulled, thanks.

-- 
Kalle Valo

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

[Kalle Valo]

Igor Mitsyanko  writes:

> thank for review and sorry for long delays in replies. A parallel
> thread with Dave a discussion was initiated regarding HW platform
> samples availability. Current driver implementation supports a newer
> QSR10G platform, which availability is limited due to the platform
> still being in development stage. We're working on supporting
> Quantenna's current QSR1000 platform too, what would be the best
> approach to this:
> - have QSR1000 platform support ready, amend it to current patch and
> post it as a new patch revision (there should be a certain amount of
> new code);
> - have current patch accepted by community first, and then post a new
> patch (adding new platform support) one on top of it.

I prefer the latter option. Let's first try to get the driver applied
and then you can submit more features as followup patches.

-- 
Kalle Valo

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

[Kalle Valo]

 writes:

> From: Avinash Patil 
>
> This patch adds support for new FullMAC WiFi driver for Quantenna
> QSR10G chipsets.
>
> QSR10G is Quantenna's 8x8, 160M, 11ac offering.
> QSR10G supports 2 simultaneous WMACs- one 5G and one 2G. 5G WMAC
> supports 160M, 8x8 configuration.
> FW supports 8 concurrent virtual interfaces on each WMAC.
>
> Patch introduces 2 new drivers- qtnfmac.ko for interfacing with
> kernel/cfg80211 and qtnfmac_pcie.ko for PCIe bus interface.
>
> Signed-off-by: Dmitrii Lebed 
> Signed-off-by: Sergei Maksimenko 
> Signed-off-by: Sergey Matyukevich 
> Signed-off-by: Bindu Therthala 
> Signed-off-by: Huizhao Wang 
> Signed-off-by: Kamlesh Rath 
> Signed-off-by: Avinash Patil 
> Signed-off-by: Igor Mitsyanko 

More comments:

> +/* FW names */
> +
> +#define QTN_PCI_FW_NAME  "pearl-linux.lzma.img"

The firmware name gives no indication what this file is about (remember
that linux-firmware.git has a lot of files). Please name it properly,
don't just use what is used in by firmware build scripts :) Take into
account also future hw support, all firmware files need to coexist in
the same repository without user invention. In a way the firmware
filename is part of kernel/userspace interface and needs to be stable.

For example, you could use something like "qtnfmac/qsr10g.img" (assuming
qsr10g is the name of chip).

I forgot already, is the firmware image ready for submission to
linux-firmware.git?

> + pr_info("%s: %sregistered mgmt frame type 0x%x\n", __func__,
> + reg ? "" : "un", frame_type);

The driver seems to be quite spammy with info messages:

qtnfmac/cfg80211.c: pr_info("%s: %sregistered mgmt frame type 0x%x\n", 
__func__,
qtnfmac/cfg80211.c: pr_info("QTNF: %s cipher=%x, idx=%u, pairwise=%u\n", 
__func__,
qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u, pairwise=%u\n", __func__, 
key_index,
qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u, unicast=%u, multicast=%u\n", 
__func__,
qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u\n", __func__, key_index);
qtnfmac/cfg80211.c: pr_info("%s: initiator=%d, alpha=%c%c, macid=%d\n", 
__func__,
qtnfmac/cfg80211.c: pr_info("%s: MAX_IF: %zu; MODES: %.4X; RADAR WIDTHS: 
%.2X\n", __func__,
qtnfmac/cfg80211.c: pr_info("macid=%d, phymode=%#x\n", mac->macid, 
mac->macinfo.phymode);
qtnfmac/commands.c: pr_info("%s: unexpected TLV type: 
%.4X\n",
qtnfmac/commands.c: pr_info("%s: STA %pM not found\n", 
__func__, sta_mac);
qtnfmac/commands.c: pr_info("country-code from EP: %c%c\n", 
hwinfo->country_code[0],
qtnfmac/commands.c: pr_info("fw_version = %d, num_mac=%d, mac_bitmap=%#x\n",
qtnfmac/commands.c: pr_info("iface limit record 
count=%zu\n", record_count);
qtnfmac/commands.c: pr_info("MAC%d reported channels %d\n",
qtnfmac/init.c: pr_info("%s: macid=%d\n", __func__, macid);
qtnfmac/pcie.c: pr_info("enabled PCIE MSI interrupt\n");
qtnfmac/pcie.c: pr_info("%s: BAR[%u] vaddr=0x%p busaddr=0x%p len=%u\n",
qtnfmac/pcie.c: pr_info("%s: set mps to %d (was %d, max %d)\n",
qtnfmac/pcie.c: pr_info("fw download started: fw start addr = 0x%p, size=%d\n",
qtnfmac/pcie.c: pr_info("fw download completed: totally sent %d blocks\n", blk);
qtnfmac/pcie.c: pr_info("RC is ready to boot EP...\n");
qtnfmac/pcie.c: pr_info("starting download firmware %s...\n", bus->fwname);
qtnfmac/pcie.c: pr_info("successful init of PCI device %x\n", 
pdev->device);
qtnfmac/pcie.c: pr_info("Register Quantenna FullMAC PCIE driver\n");
qtnfmac/pcie.c: pr_info("Unregister Quantenna FullMAC PCIE driver\n");
qtnfmac/trans.c:pr_info("%s: interrupted\n", __func__);
qtnfmac/trans.c:pr_info("%s: skb dropped\n", __func__);

Usualle the preference is that driver is quiet until something goes
wrong. I hope some of these could be debug messages.

> --- /dev/null
> +++ b/drivers/net/wireless/quantenna/qtnfmac/pcie.c
> @@ -0,0 +1,1374 @@
> +/**
> + * Copyright (c) 2015-2016 Quantenna Communications, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + **/
> +
> +#undef DEBUG

Why?

-- 
Kalle Valo

Re: pull-request: wireless-drivers-next 2016-09-15

[David Miller]

From: Kalle Valo 
Date: Thu, 15 Sep 2016 18:09:21 +0300

> here's the first pull request for 4.9. The ones I want to point out are
> the FIELD_PREP() and FIELD_GET() macros added to bitfield.h, which are
> reviewed by Linus, and make it possible to remove util.h from mt7601u.
> 
> Also we have new HW support to various drivers and other smaller
> features, the signed tag below contains more information. And I pulled
> my ath-current (uses older net tree as the baseline) branch to fix a
> conflict in ath10k.
> 
> Once again the diffstat from git request-pull was wrong. I fixed it by
> manually copying the diffstat from a test pull against net-next, so
> everything should be ok. But please let me know if there are any
> problems.

Pulled, thanks Kalle.

Re: [athk9] beacon.c:642 ath9k_calculate_summary_state dump

[Kalle Valo]

Vidar Haarr  writes:

> I'm seeing the message below spammed continously in journald, even
> with 4.8-rc6. It's so bad that it throttles the CPU performance every
> few seconds.
>
> I found https://patchwork.kernel.org/patch/9247699/ which seems related.

[...]

> sep. 17 11:38:36 edbpc kernel: WARNING: CPU: 0 PID: 1684 at
> /home/kernel/COD/linux/drivers/net/wireless/ath/ath9k/beacon.c:642
> ath9k_calculate_summary_state+0x135/0x390 [ath9k]

Looks like exactly the same problem, but the fix (below) is not in
v4.8-rc6. Should be in -rc7 which Linus hopefully releases on Sunday.
Please test that and report if the problem continues.

05860bed491b ath9k: fix client mode beacon configuration

-- 
Kalle Valo

[athk9] beacon.c:642 ath9k_calculate_summary_state dump

[Vidar Haarr]

Hi,

I'm seeing the message below spammed continously in journald, even
with 4.8-rc6. It's so bad that it throttles the CPU performance every
few seconds.

I found https://patchwork.kernel.org/patch/9247699/ which seems related.

I am not subscribed to linux-wireless.

First, here's some system info, then the stack trace at the bottom.
$ lspci
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM
Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210
Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset
Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 2 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC
Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family
6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family
SMBus Controller (rev 04)
02:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network
Adapter (rev 01)

$ sudo lshw -class network
[sudo] passord for folk:
  *-network
   description: Wireless interface
   product: AR9462 Wireless Network Adapter
   vendor: Qualcomm Atheros
   physical id: 0
   bus info: pci@:02:00.0
   logical name: wlan0
   version: 01
   serial: 24:ec:99:7f:0e:30
   width: 64 bits
   clock: 33MHz
   capabilities: pm msi pciexpress bus_master cap_list rom
ethernet physical wireless
   configuration: broadcast=yes driver=ath9k
driverversion=4.8.0-040800rc6-generic firmware=N/A ip=192.168.1.176
latency=0 link=yes multicast=yes wireless=IEEE 802.11
   resources: irq:17 memory:f040-f047 memory:f048-f048

$ uname -a
Linux edbpc 4.8.0-040800rc6-generic #201609121119 SMP Mon Sep 12
15:21:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

rfkill list all
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no


sep. 17 11:38:36 edbpc kernel: WARNING: CPU: 0 PID: 1684 at
/home/kernel/COD/linux/drivers/net/wireless/ath/ath9k/beacon.c:642
ath9k_calculate_summary_state+0x135/0x390 [ath9k]
sep. 17 11:38:36 edbpc kernel: Modules linked in: fuse ctr ccm
binfmt_misc nls_utf8 nls_cp437 vfat fat intel_rapl
x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic arc4 snd_hda_intel
snd_hda_codec snd_hda_core ath9k snd_hwdep ath9k_common ath9k_hw
snd_pcm ath kvm_intel snd_seq_midi uvcvideo snd_seq_midi_event
mac80211 kvm videobuf2_vmalloc snd_rawmidi irqbypass videobuf2_memops
snd_seq crct10dif_pclmul videobuf2_v4l2 crc32_pclmul videobuf2_core
snd_seq_device videodev ghash_clmulni_intel cryptd intel_cstate
cfg80211 media intel_rapl_perf snd_timer ath3k btusb btrtl btbcm
btintel efi_pstore bluetooth snd joydev rfkill efivars lpc_ich
serio_raw sg shpchp mei_me soundcore mfd_core mei evdev fujitsu_laptop
battery ac tpm_tis tpm_tis_core tpm lp parport loop efivarfs
sep. 17 11:38:36 edbpc kernel:  ip_tables x_tables autofs4 ext4 crc16
jbd2 fscrypto mbcache hid_generic usbhid hid uas usb_storage sd_mod
i915 ahci crc32c_intel libahci libata psmouse i2c_algo_bit scsi_mod
drm_kms_helper xhci_pci syscopyarea ehci_pci xhci_hcd sysfillrect
ehci_hcd sysimgblt fb_sys_fops usbcore drm usb_common fan thermal
video fjes button
sep. 17 11:38:36 edbpc kernel: CPU: 0 PID: 1684 Comm: kworker/u16:0
Tainted: GW   4.8.0-040800rc6-generic #201609121119
sep. 17 11:38:36 edbpc kernel: Hardware name: FUJITSU LIFEBOOK
UH572/FJNBB31  , BIOS 2.15 07/29/2013
sep. 17 11:38:36 edbpc kernel: Workqueue: phy0 ieee80211_scan_work [mac80211]
sep. 17 11:38:36 edbpc kernel:  0286 189cb902
ab33fb84 
sep. 17 11:38:36 edbpc kernel:   ab07f69e
96690ec45580 96690ec46e10
sep. 17 11:38:36 edbpc kernel:  96690ec74018 96690ec74018
966912773360 966912773360
sep. 17 11:38:36 edbpc kernel: Call Trace:
sep. 17 11:38:36 edbpc kernel:  [] ? dump_stack+0x5c/0x78
sep. 17 11:38:36 edbpc kernel:  [] ? __warn+0xbe/0xe0
sep. 17 11:38:36 edbpc kernel:  [] ?
ath9k_calculate_summary_state+0x135/0x390 [ath9k]
sep. 17 11:38:36 edbpc kernel:  [] ?
ath_complete_reset+0x22/0x130 [ath9k]
sep. 17 11:38:36 edbpc