Re: [PATCH] mac80211: Update last_ack status for all except probing frames

2017-10-31 Thread Igor Mitsyanko 

On 10/30/2017 05:29 PM, Rajkumar Manoharan wrote:


Update last_ack status for all except station probing frames
(i.e null data). Otherwise the station inactivity duration is
cleared whenever AP is checking presence of idle stations by sending
null data frame for every inactive threshold (ap_max_inactivity).
Though the station is idle for longer period, the inactive
time in station dump is restricted ap_max_inactivity threshold.

Signed-off-by: Rajkumar Manoharan 
---


To clarify: wouldn't it break hostapd's "inactivity timeot kick-out" 
logic in hostapd? As hostapd generates NULL frames to idle stations to 
reset their inactivity time, otherwise it will disassociate a station, 
after an ap_max_inactivity period.

Re: pull-request: wireless-drivers 2017-10-31

2017-10-31 Thread David Miller 
From: Kalle Valo 
Date: Tue, 31 Oct 2017 17:19:24 +0200

> here's a pull request to net tree for 4.14. Due to the ath10k security
> issue I would like to get this to 4.14 still.
> 
> Please let me know if there are any problems.

Pulled, thanks a lot.

Re: rtlwifi oops

2017-10-31 Thread nirinA raseliarison 

On 10/31/2017 06:11 AM, Barry Day wrote:

On Sun, Oct 29, 2017 at 01:08:24AM +0300, nirinA raseliarison wrote:

[  145.966016] usb 2-1.4: new high-speed USB device number 4 using ehci-pci
[  146.045808] usb 2-1.4: New USB device found, idVendor=0bda,
idProduct=8178
[  146.045811] usb 2-1.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[  146.045812] usb 2-1.4: Product: 802.11n WLAN Adapter
[  146.045813] usb 2-1.4: Manufacturer: Realtek
[  146.045814] usb 2-1.4: SerialNumber: 00e04c01
[  146.202043] rtl8192cu: Chip version 0x11
[  146.278549] rtl8192cu: Board Type 0
[  146.278790] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[  146.278823] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[  146.278938] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[  146.279113] usbcore: registered new interface driver rtl8192cu
[  146.281706] usbcore: registered new interface driver rtl8xxxu
--
nirinA


It appears that both rtl8192cu and rtl8xxxu are being loaded for the
one device.

Try blacklisting one of them.


both seem to work fine; i'll use rtl8192cu and blacklist rtl8xxxu.

thanks,


Barry


--
nirinA

Re: iwlwifi crash with hostapd

2017-10-31 Thread Mario Theodoridis 



On 31.10.2017 20:25, Mario Theodoridis wrote:

Hi James,


On 24.10.2017 23:01, James Cameron wrote:

But it is only a warning.  If connections aren't dying, it may not be
important to you.


Regarding whether wifi hangs, it's usually takes a while to get going 
and then disappears. Sunday night i ended up rebooting into the 4.4-79 
kernel because the 4.13 just got too ridiculous.

I.e. Wlan off, wlan on no longer worked.



Please check you are using the most recent linux-firmware?


Just in case i haven't answered that it's at 1.169



Several methods, though by far the most common seems to be personal
experience with offsets.

When you don't have that personal experience, the methods are;

1.  using GDB against the .o file,

2.  using binutils objdump to disassemble .o file or vmlinuz,

3.  using GCC to generate assembly listings,

See https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks right down
the end of page for the GDB method.


I have gotten around to that part, yet, as i was busy with the
above, but it seems later versions have issues, too.


However, you're still testing old source code.

Several changes made since are worth testing, please either
cherry-pick the patches or test a 4.14 rc kernel, and without
involving dkms or virtualbox.

Or, if new firmware fixes the problem, go with that instead.


I just managed to patch the 5.1.30 dkms package so i wouldn't need to 
update to virtualbox-5.2.



Here are the results with the 4.14-rc7 kernel.
As last time i appended what fills my syslog now.


Yes, maybe i ought to attach them ;)

--
Mit freundlichen Grüßen/Best regards

Mario Theodoridis

## wireless info START ##

Report from: 31 Oct 2017 19:27 CET +0100

Booted last: 31 Oct 2017 00:00 CET +0100

Script from: 25 Mar 2017 07:04 UTC +

# release ###

Distributor ID: Ubuntu
Description:Ubuntu 16.04.3 LTS
Release:16.04
Codename:   xenial

# kernel 

Linux 4.14.0-041400rc7-generic #201710292231 SMP Sun Oct 29 22:32:07 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux

Parameters: ro

# desktop ###

/usr/share/xsessions/plasma

# lspci #

00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (2) 
I219-V [8086:15b8] (rev 31)
Subsystem: Gigabyte Technology Co., Ltd Ethernet Connection (2) I219-V 
[1458:e000]
Kernel driver in use: e1000e

03:00.0 Ethernet controller [0200]: Intel Corporation 82546GB Gigabit Ethernet 
Controller [8086:1079] (rev 03)
Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter 
[8086:117a]
Kernel driver in use: e1000

03:00.1 Ethernet controller [0200]: Intel Corporation 82546GB Gigabit Ethernet 
Controller [8086:1079] (rev 03)
Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter 
[8086:117a]
Kernel driver in use: e1000

03:01.0 Ethernet controller [0200]: Intel Corporation 82557/8/9/0/1 Ethernet 
Pro 100 [8086:1229] (rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter 
[8086:000c]
Kernel driver in use: e100

07:00.0 Network controller [0280]: Intel Corporation Wireless 7260 [8086:08b1] 
(rev 73)
Subsystem: Intel Corporation Dual Band Wireless-AC 7260 [8086:4070]
Kernel driver in use: iwlwifi

# lsusb #

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046a:0011 Cherry GmbH G83 (RS 6000) Keyboard
Bus 001 Device 002: ID 046d:c06b Logitech, Inc. G700 Wireless Gaming Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

# PCMCIA card info ##

# rfkill 

0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no

# lsmod #

iwlmvm368640  0
mac80211  778240  1 iwlmvm
iwlwifi   270336  1 iwlmvm
cfg80211  614400  3 iwlmvm,iwlwifi,mac80211
wmi24576  0

# interfaces 

auto lo enp3s1 enp3s0f0 br0
iface lo inet loopback

iface enp3s1 inet manual
  pre-up ip link set dev enp3s1 up
  post-down ip link set dev enp3s1 down

iface enp3s0f0 inet static
  address 192.168.23.3
  netmask 255.255.255.0
  pre-up iptables-restore < /etc/iptables.rules
  up route add -net 192.168.123.0/24 gw 192.168.23.4 dev enp3s0f0
  up route add -net 192.168.8.0/24 gw 192.168.23.4 dev enp3s0f0

iface br0 inet static
  address 192.168.7.3
  netmask 255.255.255.0
  gateway 192.168.7.1
  pre-up iptables-restore < /etc/iptables.rules
  bridge_ports enp3s0f1 enp0s31f6
  bridge_stp off
  bridge_fd 0
  bridge_maxwait 0

# ifconfig ##

br0   Link encap:Ethernet  HWaddr   
  inet addr:192.168.7.3  Bcast:192.168.7.255  Mask:255.255.255.0
  inet6 addr: fe80::/64 Scope:Link
  UP BROADCAST

Re: iwlwifi crash with hostapd

2017-10-31 Thread Mario Theodoridis 

Hi James,


On 24.10.2017 23:01, James Cameron wrote:

But it is only a warning.  If connections aren't dying, it may not be
important to you.


Regarding whether wifi hangs, it's usually takes a while to get going 
and then disappears. Sunday night i ended up rebooting into the 4.4-79 
kernel because the 4.13 just got too ridiculous.

I.e. Wlan off, wlan on no longer worked.



Please check you are using the most recent linux-firmware?


Just in case i haven't answered that it's at 1.169



Several methods, though by far the most common seems to be personal
experience with offsets.

When you don't have that personal experience, the methods are;

1.  using GDB against the .o file,

2.  using binutils objdump to disassemble .o file or vmlinuz,

3.  using GCC to generate assembly listings,

See https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks right down
the end of page for the GDB method.


I have gotten around to that part, yet, as i was busy with the
above, but it seems later versions have issues, too.


However, you're still testing old source code.

Several changes made since are worth testing, please either
cherry-pick the patches or test a 4.14 rc kernel, and without
involving dkms or virtualbox.

Or, if new firmware fixes the problem, go with that instead.


I just managed to patch the 5.1.30 dkms package so i wouldn't need to 
update to virtualbox-5.2.



Here are the results with the 4.14-rc7 kernel.
As last time i appended what fills my syslog now.


--
Mit freundlichen Grüßen/Best regards

Mario Theodoridis

Re: [PATCH v2] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)

2017-10-31 Thread Seth Forshee 
On Tue, Oct 31, 2017 at 11:39:13PM +0600, WoWz89 wrote:
> Здравствуйте, Seth.
> 
> Вы писали 20 октября 2017 г., 21:06:51:
> 
> > Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
> > based on the documents at [1] and [2].
> 
> > v2: Also add DFS region
> Good afternoon, when will the update ?

I'm planning to get anything pending applied and a new release out in
the next couple of days.

Re: [v3,1/3] rsi: sdio: add WOWLAN support for S3 suspend state

2017-10-31 Thread Amitkumar Karwar 
On Tue, Oct 31, 2017 at 8:54 PM, Kalle Valo  wrote:
> Kalle Valo  writes:
>
>> Amitkumar Karwar  wrote:
>>
>>> From: Karun Eagalapati 
>>>
>>> WoWLAN is supported in RS9113 device through GPIO pin2.
>>> wowlan config frame is internally sent to firmware in mac80211
>>> suspend handler. Also beacon miss threshold and keep-alive time
>>> values are increased to avoid un-necessary disconnection with AP.
>>>
>>> Signed-off-by: Karun Eagalapati 
>>> Signed-off-by: Amitkumar Karwar 
>>
>> 3 patches applied to wireless-drivers-next.git, thanks.
>>
>> f3ac4e7394a1 rsi: sdio: add WOWLAN support for S3 suspend state
>> b6c8d06c8a64 rsi: sdio: Add WOWLAN support for S4 hibernate state
>> 063848c3e155 rsi: sdio: Add WOWLAN support for S5 shutdown state
>
> Kbuild bot found build problems with the first patch. (Amit should have
> the details in the mail from kbuild bot.) I need a fix by tomorrow
> (wednesday) or I need to revert these. Otherwise I cannot submit a pull
> request to Dave.
>

I'll submit a fix for this by tomorrow.

Regards,
Amit

Re: [PATCH v2] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)

2017-10-31 Thread WoWz89 
Здравствуйте, Seth.

Вы писали 20 октября 2017 г., 21:06:51:

> Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
> based on the documents at [1] and [2].

> v2: Also add DFS region
Good afternoon, when will the update ?
> [1]
> http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> [2] http://adilet.zan.kz/rus/docs/P01379_

> Signed-off-by: Seth Forshee 
> ---
>  db.txt | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)

> diff --git a/db.txt b/db.txt
> index 9d129f2e542b..10c84ee1ca5d 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -691,8 +691,14 @@ country KY: DFS-FCC
> (5490 - 5730 @ 160), (24), DFS
> (5735 - 5835 @ 80), (30)
>  
> -country KZ:
> +# Source:
> +#
> http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_chastot_no34.pdf
> +# http://adilet.zan.kz/rus/docs/P01379_
> +country KZ: DFS-ETSI
> (2402 - 2482 @ 40), (20)
> +   (5150 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
> +   (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
> +   (5470 - 5725 @ 80), (20), NO-OUTDOOR, DFS
>  
>  country LB: DFS-FCC
> (2402 - 2482 @ 40), (20)



-- 
С уважением,
 WoWz89  mailto:wow...@mail.ru

Re: PROBLEM: Issue with wireless driver after resume from suspend.

2017-10-31 Thread Matteo Croce 
On Tue, Oct 31, 2017 at 7:51 AM, Anil Nair  wrote:
> Hi All,
>
> I am having a issue with the wireless driver in my laptop. Attached 
> information
> pertaining to the issue.
>
>   [1.] One line summary of the problem:
>
>   Wifi not working after resuming from suspend state.
>
>   [2.] Full description of the problem/report:
>
>   I had put my laptop in suspend mode, after resmuing the laptop from suspend
>   mode wifi stopped working, or rather not responding I tried switching the
>   airplane mode on then off still no effect.
>
>   [3.] Keywords (i.e., modules, networking, kernel):
>
>   Networking particularly Wireless Networking.
>
>   [4.] Kernel information
>
>   4.13.5
>
>   [4.1.] Kernel version (from /proc/version):
>
>   Linux version 4.13.5anil-1017 (root@anilnair-lenovo)
>   (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5))
>   #1 SMP Sat Oct 14 12:30:16 IST 2017
>
>   [4.2.] Kernel .config file:
>
>   Attached in the below mail file named config_kernel.txt
>
>   [5.] Most recent kernel version which did not have the bug:
>
>   4.4.0
>
>   [6.] Output of Oops.. message (if applicable) with symbolic information
>resolved (see Documentation/admin-guide/oops-tracing.rst)
>
>   Attached in the below mail file named error_log.txt
>
>   [8.1.] Software (add the output of the ver_linux script here)
>
>   Attached in the below mail file named software_version.txt
>
>   [8.2.] Processor information (from /proc/cpuinfo):
>
>   Attached in the below mail file named cpu_config.txt
>
>   [8.3.] Module information (from /proc/modules):
>
>   Attached in the below mail file named modules_config.txt
>
>   [8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
>
>   Attached in the below mail file named ioports_config.txt,iomem_config.txt,
>
>   [8.5.] PCI information ('lspci -vvv' as root)
>
>   Attached in the below mail file named pci_config.txt
>
>   [8.6.] SCSI information (from /proc/scsi/scsi)
>
>   Attached in the below mail file named cpu_config.txt
>
>   [X.] Other notes, patches, fixes, workarounds:
>
>   A reboot fixes the issue.
>
>   All Files are compressed in the tar and sent.
>   Let me know what went wrong and how can i fix it.
>   Let me know if any further information is required.
>
>   Thanking You.
>
>   --
>   Regards,
>   Anil Nair
>

I have the same issue with ath10k and kernel 4.13.10.
If I suspend the system when the card is up it won't work anymore
until I rmmod and modprobe ath10k_pci again.
rmmod after suspend can take up to 10 minutes and sometimes crashes the system.
Removing the driver _before_ suspend and inserting it back after
resume actually works and it's what I'm using as not-so-temporary
workaround.

Regards,
-- 
Matteo Croce
per aspera ad upstream

Re: ath10k: Wifi slow on the XPS13 (9360) (QCA6174)

2017-10-31 Thread Thorsten Leemhuis 
Lo! On 29.10.2017 08:27, Kalle Valo wrote:
> [..]
> sorry for the late reply, I'm having problems keeping up with all the
> email. 

No worries, this problem is nothing new, I just thought it might be good
to finally bring this to ath10k, as I got the impressions it had not
gotten proper attention there yet.

> Thorsten Leemhuis  writes:
>> On 03.10.2017 01:40, Ryan Hsu wrote:
>>> On 10/01/2017 01:59 AM, Thorsten Leemhuis wrote:
> ath10k_pci :3a:00.0: Direct firmware load for
> ath10k/pre-cal-pci-:3a:00.0.bin failed with error -2
> ath10k_pci :3a:00.0: Direct firmware load for
> ath10k/cal-pci-:3a:00.0.bin failed with error -2
 Do they have anything to do with this? Hardware is
>>> This error message is confusing since QCA6174 is not supporting
>>> pre-calibration feature, this reminds me that we need to clean this up.
>> I guess that would be good to avoid confusion. But while at it: If you
>> have a minute, could you please explain to me how to properly set up the
>> wifi firmware files for my Dell XPS13 (9360)? The reasons why I'm
>> asking: Sending data via wifi is really slow on my laptop (scp copies
>> only get 2 to 5 MByte/s on networks that are known to be a lot faster).
>> I wonder if the firmware files or the calibration data is part of the
>> reason wifi Tx is slow. The machine is normally shipped with a slightly
>> enhanced Ubuntu 16.04. That among others contains a package with the
>> machine specific files board.bin and board-2.bin that replace the files
>> normally installed in /lib/firmware/ath10k/QCA6174/hw3.0/ Are those
>> machine specific files crucial to have or are the one from the
>> linux-firmware repo good enoguh? I'm using Fedora and could copy the
>> ones from Ubuntu over, but obviously they will get overwritten every
>> time Fedora ships a new linux-firmware package – IOW: every few weeks :-/
> Yes, the board file can affect throughtput, _both_ TCP and UDP. I don't
> know what board files Ubuntu is shipping but we should try to get those
> into upstream.

Out of curiosity (don't spend time answering this is you are busy): Is
there even a mechanism for this? Kind of "take
firmwaredir/board-Dell_Inc.-XPS_13_9360.bin if it exists and
firmwaredir/board.bin otherwise? Or can one file serve all machines?

>> Side note: You find a lot of reports about slow wifi is you search the
>> net with terms like "9360 wifi slow linux". Ubuntu fixed that a few
>> months ago with this patch:
>> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/commit/?id=9690f19f07fee2acb2b04ea5eaa5db184ee175d5
>> Some bugs about this:
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1692836
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041
> But this again about interraction between ath10k and TCP stack. And it
> _only_ affects TCP, UDP should be unaffected.

Ahh, sorry, missed that. Seems I didn't properly read the second
launchpad link above. Sorry.

> So whenever testing
> throughput please always measure both TCP and UDP because then it's
> easier to pinpoint the reason.

Is there any data I could provide that might help getting this soled
once and for all?

>> But from what I gathered by searching the net and asking on #ath10k I
>> got the impression that patch is a massive ugly hack and no way
>> acceptable upstream.  Is that correct?
> Yes, it's a horrible hack and I cannot apply that. And like you said
> #1692836, also Eric Dumazet (one of TCP maintainers) agrees with that
Ahh, had missed that, sorry.

>> If yes: is there maybe a proper fix out there somewhere?
> Unfortunately there still is no good solution. In a week there's Netdev
> 2.2 and we have Linux Wireless summit there. We should bring up this
> topic there.

Thx for picking this up, much appreciated! Ciao, Thorsten

RE: [EXT] Re: pull-request mwifiex-firmware 2017-10-30

2017-10-31 Thread Ganapathi Bhat 
Hi Brian,

> -Original Message-
> From: Brian Norris [mailto:briannor...@chromium.org]
> Sent: Tuesday, October 31, 2017 1:18 AM
> To: Ganapathi Bhat
> Cc: linux-firmw...@kernel.org; linux-wireless@vger.kernel.org; James Cao;
> Cathy Luo; Mangesh Malusare; Xinming Hu; Zhiyuan Yang; Karthik
> Doddayennegere Ananthapadmanabha
> Subject: Re: [EXT] Re: pull-request mwifiex-firmware 2017-10-30
>
> On Mon, Oct 30, 2017 at 12:02 PM, Ganapathi Bhat 
> wrote:
> > Ok, prepared the follow up patch.  Let me also know if we can send a
> merge request while previous one is pending?
> > If that is not the case I will send it as soon as the current request is 
> > merged.
>
> That's not up to me. I'm sure the maintainer will let you know if they need
> something, eventually. It's so trivial, I don't see why they couldn't just 
> pull it
> in without any more fuss.

I have sent another pull request, which has correct version info.

I hereby inform maintainers to ignore this particular request and consider the 
latest pull request.

Thanks,
Ganapathi

pull-request mwifiex-firmware 2017-10-31

2017-10-31 Thread Ganapathi Bhat 
The following changes since commit e0494e95192ac5329989f4d128cf95c417d618cc:

  linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-08-01 
23:55:30 +0530)

are available in the git repository at:

  git://git.marvell.com/mwifiex-firmware.git

for you to fetch changes up to db3e1855ea46bc1a22b8bbecb400c2909c551cf5:

  linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-10-31 
20:49:53 +0530)


Ganapathi Bhat (1):
  linux-firmware: update Marvell PCIe-USB8997 firmware image

 WHENCE|   2 +-
 mrvl/pcieusb8997_combo_v4.bin | Bin 620800 -> 622532 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)

pull-request mwifiex-firmware 2017-10-31

2017-10-31 Thread Ganapathi Bhat 
The following changes since commit e0494e95192ac5329989f4d128cf95c417d618cc:

  linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-08-01 
23:55:30 +0530)

are available in the git repository at:

  git://git.marvell.com/mwifiex-firmware.git

for you to fetch changes up to db3e1855ea46bc1a22b8bbecb400c2909c551cf5:

  linux-firmware: update Marvell PCIe-USB8997 firmware image (2017-10-31 
20:49:53 +0530)


Ganapathi Bhat (1):
  linux-firmware: update Marvell PCIe-USB8997 firmware image

 WHENCE|   2 +-
 mrvl/pcieusb8997_combo_v4.bin | Bin 620800 -> 622532 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)

Re: [v3,1/3] rsi: sdio: add WOWLAN support for S3 suspend state

2017-10-31 Thread Kalle Valo 
Kalle Valo  writes:

> Amitkumar Karwar  wrote:
>
>> From: Karun Eagalapati 
>> 
>> WoWLAN is supported in RS9113 device through GPIO pin2.
>> wowlan config frame is internally sent to firmware in mac80211
>> suspend handler. Also beacon miss threshold and keep-alive time
>> values are increased to avoid un-necessary disconnection with AP.
>> 
>> Signed-off-by: Karun Eagalapati 
>> Signed-off-by: Amitkumar Karwar 
>
> 3 patches applied to wireless-drivers-next.git, thanks.
>
> f3ac4e7394a1 rsi: sdio: add WOWLAN support for S3 suspend state
> b6c8d06c8a64 rsi: sdio: Add WOWLAN support for S4 hibernate state
> 063848c3e155 rsi: sdio: Add WOWLAN support for S5 shutdown state

Kbuild bot found build problems with the first patch. (Amit should have
the details in the mail from kbuild bot.) I need a fix by tomorrow
(wednesday) or I need to revert these. Otherwise I cannot submit a pull
request to Dave.

   drivers/net/wireless/rsi/rsi_91x_mac80211.c: In function
   'rsi_wow_map_triggers':
>> drivers/net/wireless/rsi/rsi_91x_mac80211.c:1767:19: error:
>> 'RSI_WOW_ANY' undeclared (first use in this function)
  wow_triggers |= RSI_WOW_ANY;
  ^~~
   drivers/net/wireless/rsi/rsi_91x_mac80211.c:1767:19: note: each
   undeclared identifier is reported only once for each function it
   appears in
>> drivers/net/wireless/rsi/rsi_91x_mac80211.c:1769:19: error:
>> 'RSI_WOW_MAGIC_PKT' undeclared (first use in this function)
  wow_triggers |= RSI_WOW_MAGIC_PKT;
  ^
>> drivers/net/wireless/rsi/rsi_91x_mac80211.c:1771:19: error:
>> 'RSI_WOW_DISCONNECT' undeclared (first use in this function)
  wow_triggers |= RSI_WOW_DISCONNECT;
  ^~
>> drivers/net/wireless/rsi/rsi_91x_mac80211.c:1774:19: error:
>> 'RSI_WOW_GTK_REKEY' undeclared (first use in this function)
  wow_triggers |= RSI_WOW_GTK_REKEY;
  ^
   drivers/net/wireless/rsi/rsi_91x_mac80211.c: In function
   'rsi_mac80211_attach':
>> drivers/net/wireless/rsi/rsi_91x_mac80211.c:1970:7: error: 'struct
>> wiphy' has no member named 'wowlan'
 wiphy->wowlan = _wowlan_support;
  ^~
   drivers/net/wireless/rsi/rsi_91x_mgmt.c: In function
   'rsi_send_wowlan_request':
>> drivers/net/wireless/rsi/rsi_91x_mgmt.c:1623:12: error:
   'RSI_WOW_GTK_REKEY' undeclared (first use in this function)
  flags |= RSI_WOW_GTK_REKEY;
   ^
   drivers/net/wireless/rsi/rsi_91x_mgmt.c:1623:12: note: each
   undeclared identifier is reported only once for each function it
   appears in


-- 
Kalle Valo

pull-request: wireless-drivers 2017-10-31

2017-10-31 Thread Kalle Valo 
Hi Dave,

here's a pull request to net tree for 4.14. Due to the ath10k security
issue I would like to get this to 4.14 still.

Please let me know if there are any problems.

Kalle

The following changes since commit a6127b4440d1f74f26b64006b2f50c9dc6d66efc:

  Merge tag 'iwlwifi-for-kalle-2017-10-06' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes (2017-10-09 
17:31:39 +0300)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2017-10-31

for you to fetch changes up to c29f56b9f425c63daa3f3163ee16493b1c67618b:

  Merge ath-current from ath.git (2017-10-31 16:26:48 +0200)


wireless-drivers fixes for 4.14

The most important here is the security vulnerabitility fix for
ath10k.

ath10k

* fix security vulnerability with missing PN check on certain hardware

* revert ath10k napi fix as it caused regressions on QCA6174

wcn36xx

* remove unnecessary rcu_read_unlock() from error path


Jia-Ju Bai (1):
  wcn36xx: Remove unnecessary rcu_read_unlock in wcn36xx_bss_info_changed

Kalle Valo (2):
  Revert "ath10k: fix napi_poll budget overflow"
  Merge ath-current from ath.git

Vasanthakumar Thiagarajan (1):
  ath10k: rebuild crypto header in rx data frames

 drivers/net/wireless/ath/ath10k/htt_rx.c  | 122 +++---
 drivers/net/wireless/ath/ath10k/rx_desc.h |   3 +
 drivers/net/wireless/ath/wcn36xx/main.c   |   1 -
 3 files changed, 98 insertions(+), 28 deletions(-)

Re: [v3] ath10k: rebuild crypto header in rx data frames

2017-10-31 Thread Sebastian Gottschall 

Am 31.10.2017 um 16:00 schrieb Kalle Valo:

Sebastian Gottschall  writes:


the following patchlines in the v3 patch look wrong

+   /* ICV */
+   if (status->flag & RX_FLAG_ICV_STRIPPED &&
+   enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+   skb_trim(msdu, msdu->len -
+    ath10k_htt_rx_crypto_tail_len(ar,
enctype));


the enctype != wpa2 isnt enough since it also belongs to ccmp-256,
gcmp modes etc.

4.14 doesn't support CCMP-256 nor GCMP modes yet. Did you check the
separate patch for 4.15:


for me ccmp-256 and gcmp works but my current tree is based on a very 
recent mac80211 version


but did not check if this support is included in 4.14 since i'm 
developing embedded wireless firmwares on different kernel versions 
using wireless backports based on recent mac80211 /ath10k etc. versions




https://patchwork.kernel.org/patch/10029097/

thanks for notifying me. havent seen it




--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [v3] ath10k: rebuild crypto header in rx data frames

2017-10-31 Thread Kalle Valo 
Sebastian Gottschall  writes:

> the following patchlines in the v3 patch look wrong
>
> +   /* ICV */
> +   if (status->flag & RX_FLAG_ICV_STRIPPED &&
> +   enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
> +   skb_trim(msdu, msdu->len -
> +    ath10k_htt_rx_crypto_tail_len(ar,
> enctype));
>
>
> the enctype != wpa2 isnt enough since it also belongs to ccmp-256,
> gcmp modes etc.

4.14 doesn't support CCMP-256 nor GCMP modes yet. Did you check the
separate patch for 4.15:

https://patchwork.kernel.org/patch/10029097/

-- 
Kalle Valo

Re: [v3] ath10k: rebuild crypto header in rx data frames

2017-10-31 Thread Vasanthakumar Thiagarajan 

Sorry top posting.

The issues in raw mode with CCMP-256, GCMP and GCMP-256 were already known and
the same was captured in the commit log. As mentioned in the commit log, raw 
mode
with these ciphers does not work even without this particular patch and it 
needs some cleanup
like done in the follow up patch https://patchwork.kernel.org/patch/10029099/.

Vasanth

From: Sebastian Gottschall 
Sent: Tuesday, October 31, 2017 8:24 PM
To: Kalle Valo
Cc: ath...@lists.infradead.org; linux-wireless@vger.kernel.org; Vasanthakumar 
Thiagarajan
Subject: Re: [v3] ath10k: rebuild crypto header in rx data frames

the same is for the MIC

+   /* MIC */
+   if ((status->flag & RX_FLAG_MIC_STRIPPED) &&
+   enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+   skb_trim(msdu, msdu->len - 8);


this code looks wrong too

Am 30.10.2017 um 10:32 schrieb Sebastian Gottschall:
> will check it tomorrow including gcmp-256, ccmp-256. was out for
> weekend :-)
>
> Am 30.10.2017 um 09:39 schrieb Kalle Valo:
>> Kalle Valo  wrote:
>>
>>> Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
>>> HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
>>> on host (mac80211) rather than firmware. Rebuild cipher header
>>> in every received data frames (that are notified through those
>>> HTT interfaces) from the rx_hdr_status tlv available in the
>>> rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
>>> flag for the packets which requires mac80211 PN/TSC check support
>>> and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
>>> QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
>>> rebuilding of cipher header to perform PN/TSC check for replay
>>> attack.
>>>
>>> Please note that removing crypto tail for CCMP-256, GCMP and
>>> GCMP-256 ciphers
>>> in raw mode needs to be fixed. Since Rx with these ciphers in raw
>>> mode does not work in the current form even without this patch and
>>> removing crypto tail for these chipers needs clean up, raw mode related
>>> issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
>>> patches.
>>>
>>> Tested-by: Manikanta Pubbisetty 
>>> Signed-off-by: Vasanthakumar Thiagarajan 
>>> Signed-off-by: Kalle Valo 
>> Patch applied to ath-current branch of ath.git, thanks.
>>
>> 7eccb738fce5 ath10k: rebuild crypto header in rx data frames
>>
>

--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [v3] ath10k: rebuild crypto header in rx data frames

2017-10-31 Thread Sebastian Gottschall 

the same is for the MIC

+   /* MIC */
+   if ((status->flag & RX_FLAG_MIC_STRIPPED) &&
+   enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+   skb_trim(msdu, msdu->len - 8);


this code looks wrong too

Am 30.10.2017 um 10:32 schrieb Sebastian Gottschall:
will check it tomorrow including gcmp-256, ccmp-256. was out for 
weekend :-)


Am 30.10.2017 um 09:39 schrieb Kalle Valo:

Kalle Valo  wrote:


Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available in the
rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
flag for the packets which requires mac80211 PN/TSC check support
and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
rebuilding of cipher header to perform PN/TSC check for replay
attack.

Please note that removing crypto tail for CCMP-256, GCMP and 
GCMP-256 ciphers

in raw mode needs to be fixed. Since Rx with these ciphers in raw
mode does not work in the current form even without this patch and
removing crypto tail for these chipers needs clean up, raw mode related
issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
patches.

Tested-by: Manikanta Pubbisetty 
Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Kalle Valo 

Patch applied to ath-current branch of ath.git, thanks.

7eccb738fce5 ath10k: rebuild crypto header in rx data frames





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: [v3] ath10k: rebuild crypto header in rx data frames

2017-10-31 Thread Sebastian Gottschall 

the following patchlines in the v3 patch look wrong

+   /* ICV */
+   if (status->flag & RX_FLAG_ICV_STRIPPED &&
+   enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+   skb_trim(msdu, msdu->len -
+    ath10k_htt_rx_crypto_tail_len(ar, 
enctype));



the enctype != wpa2 isnt enough since it also belongs to ccmp-256, gcmp 
modes etc.


my proposal

   if (status->flag & RX_FLAG_ICV_STRIPPED) {
   switch(enctype)
   {
   case HTT_RX_MPDU_ENCRYPT_WEP40:
   case HTT_RX_MPDU_ENCRYPT_WEP104:
- case HTT_RX_MPDU_ENCRYPT_TKIP_WITHOUT_MIC:
   case HTT_RX_MPDU_ENCRYPT_TKIP_WPA:
   skb_trim(msdu, msdu->len -
    ath10k_htt_rx_crypto_tail_len(ar, enctype));
   break;
   default:
   break;
  }
- }


Am 30.10.2017 um 10:32 schrieb Sebastian Gottschall:
will check it tomorrow including gcmp-256, ccmp-256. was out for 
weekend :-)


Am 30.10.2017 um 09:39 schrieb Kalle Valo:

Kalle Valo  wrote:


Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available in the
rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
flag for the packets which requires mac80211 PN/TSC check support
and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
rebuilding of cipher header to perform PN/TSC check for replay
attack.

Please note that removing crypto tail for CCMP-256, GCMP and 
GCMP-256 ciphers

in raw mode needs to be fixed. Since Rx with these ciphers in raw
mode does not work in the current form even without this patch and
removing crypto tail for these chipers needs clean up, raw mode related
issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
patches.

Tested-by: Manikanta Pubbisetty 
Signed-off-by: Vasanthakumar Thiagarajan 
Signed-off-by: Kalle Valo 

Patch applied to ath-current branch of ath.git, thanks.

7eccb738fce5 ath10k: rebuild crypto header in rx data frames





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

[PATCH v3 1/3] mac80211: Add TXQ scheduling API

2017-10-31 Thread Toke Høiland-Jørgensen 
This adds an API to mac80211 to handle scheduling of TXQs and changes the
interface between driver and mac80211 for TXQ handling as follows:

- The wake_tx_queue callback interface no longer includes the TXQ. Instead,
  the driver is expected to retrieve that from ieee80211_next_txq()

- Two new mac80211 functions are added: ieee80211_next_txq() and
  ieee80211_schedule_txq(). The former returns the next TXQ that should be
  scheduled, and is how the driver gets a queue to pull packets from. The
  latter is called internally by mac80211 to start scheduling a queue, and
  the driver is supposed to call it to re-schedule the TXQ after it is
  finished pulling packets from it (unless the queue emptied).

The ath9k and ath10k drivers are changed to use the new API.

Signed-off-by: Toke Høiland-Jørgensen 
---
Changes since v2:
- Fix build error of first patch in the series reported by the kbuild
  bot

 drivers/net/wireless/ath/ath10k/core.c |   2 -
 drivers/net/wireless/ath/ath10k/core.h |   4 -
 drivers/net/wireless/ath/ath10k/mac.c  |  55 +++--
 drivers/net/wireless/ath/ath9k/ath9k.h |   9 +-
 drivers/net/wireless/ath/ath9k/main.c  |   2 +-
 drivers/net/wireless/ath/ath9k/recv.c  |   2 -
 drivers/net/wireless/ath/ath9k/xmit.c  | 210 -
 include/net/mac80211.h |  37 +-
 net/mac80211/agg-tx.c  |   6 +-
 net/mac80211/driver-ops.h  |  12 +-
 net/mac80211/ieee80211_i.h |   5 +
 net/mac80211/main.c|   3 +
 net/mac80211/sta_info.c|   7 +-
 net/mac80211/trace.h   |  32 +
 net/mac80211/tx.c  |  49 +++-
 15 files changed, 173 insertions(+), 262 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index a4f635820f35..759df3297d48 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2561,9 +2561,7 @@ struct ath10k *ath10k_core_create(size_t priv_size, 
struct device *dev,
 
mutex_init(>conf_mutex);
spin_lock_init(>data_lock);
-   spin_lock_init(>txqs_lock);
 
-   INIT_LIST_HEAD(>txqs);
INIT_LIST_HEAD(>peers);
init_waitqueue_head(>peer_mapping_wq);
init_waitqueue_head(>htt.empty_tx_wq);
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 949ebb3e967b..3c3b158cdb20 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -347,7 +347,6 @@ struct ath10k_peer {
 };
 
 struct ath10k_txq {
-   struct list_head list;
unsigned long num_fw_queued;
unsigned long num_push_allowed;
 };
@@ -892,10 +891,7 @@ struct ath10k {
 
/* protects shared structure data */
spinlock_t data_lock;
-   /* protects: ar->txqs, artxq->list */
-   spinlock_t txqs_lock;
 
-   struct list_head txqs;
struct list_head arvifs;
struct list_head peers;
struct ath10k_peer *peer_map[ATH10K_MAX_NUM_PEER_IDS];
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5683f1a5330e..f9c70d8c9a09 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3820,12 +3820,10 @@ static void ath10k_mac_txq_init(struct ieee80211_txq 
*txq)
return;
 
artxq = (void *)txq->drv_priv;
-   INIT_LIST_HEAD(>list);
 }
 
 static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
 {
-   struct ath10k_txq *artxq;
struct ath10k_skb_cb *cb;
struct sk_buff *msdu;
int msdu_id;
@@ -3833,12 +3831,6 @@ static void ath10k_mac_txq_unref(struct ath10k *ar, 
struct ieee80211_txq *txq)
if (!txq)
return;
 
-   artxq = (void *)txq->drv_priv;
-   spin_lock_bh(>txqs_lock);
-   if (!list_empty(>list))
-   list_del_init(>list);
-   spin_unlock_bh(>txqs_lock);
-
spin_lock_bh(>htt.tx_lock);
idr_for_each_entry(>htt.pending_tx, msdu, msdu_id) {
cb = ATH10K_SKB_CB(msdu);
@@ -3968,23 +3960,17 @@ int ath10k_mac_tx_push_txq(struct ieee80211_hw *hw,
 void ath10k_mac_tx_push_pending(struct ath10k *ar)
 {
struct ieee80211_hw *hw = ar->hw;
-   struct ieee80211_txq *txq;
-   struct ath10k_txq *artxq;
-   struct ath10k_txq *last;
+   struct ieee80211_txq *txq, *first = NULL;
int ret;
int max;
 
if (ar->htt.num_pending_tx >= (ar->htt.max_num_pending_tx / 2))
return;
 
-   spin_lock_bh(>txqs_lock);
rcu_read_lock();
 
-   last = list_last_entry(>txqs, struct ath10k_txq, list);
-   while (!list_empty(>txqs)) {
-   artxq = list_first_entry(>txqs, struct ath10k_txq, list);
-   txq = container_of((void *)artxq, struct ieee80211_txq,
-  drv_priv);
+

[PATCH v3 3/3] ath9k: Switch to mac80211 airtime API

2017-10-31 Thread Toke Høiland-Jørgensen 
This removes the in-driver airtime fairness scheduling from ath9k and
switches the driver to use the API introduced in mac80211 in the
previous commit.

Signed-off-by: Toke Høiland-Jørgensen 
---
 drivers/net/wireless/ath/ath9k/ath9k.h |  7 +---
 drivers/net/wireless/ath/ath9k/debug.h |  8 -
 drivers/net/wireless/ath/ath9k/debug_sta.c | 54 --
 drivers/net/wireless/ath/ath9k/init.c  |  4 +--
 drivers/net/wireless/ath/ath9k/recv.c  |  9 ++---
 drivers/net/wireless/ath/ath9k/xmit.c  | 21 
 6 files changed, 12 insertions(+), 91 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index a5088792b769..7c7dece6cb91 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -112,8 +112,6 @@ int ath_descdma_setup(struct ath_softc *sc, struct 
ath_descdma *dd,
 #define ATH_TXFIFO_DEPTH   8
 #define ATH_TX_ERROR   0x01
 
-#define ATH_AIRTIME_QUANTUM300 /* usec */
-
 /* Stop tx traffic 1ms before the GO goes away */
 #define ATH_P2P_PS_STOP_TIME   1000
 
@@ -215,6 +213,7 @@ struct ath_buf_state {
bool stale;
u16 seqno;
unsigned long bfs_paprd_timestamp;
+   u32 airtime;
 };
 
 struct ath_buf {
@@ -259,12 +258,9 @@ struct ath_node {
 
bool sleeping;
bool no_ps_filter;
-   s64 airtime_deficit[IEEE80211_NUM_ACS];
-   u32 airtime_rx_start;
 
 #ifdef CONFIG_ATH9K_STATION_STATISTICS
struct ath_rx_rate_stats rx_rate_stats;
-   struct ath_airtime_stats airtime_stats;
 #endif
u8 key_idx[4];
 
@@ -983,7 +979,6 @@ void ath_ant_comb_scan(struct ath_softc *sc, struct 
ath_rx_status *rs);
 
 #define AIRTIME_USE_TX BIT(0)
 #define AIRTIME_USE_RX BIT(1)
-#define AIRTIME_USE_NEW_QUEUES BIT(2)
 #define AIRTIME_ACTIVE(flags) (!!(flags & (AIRTIME_USE_TX|AIRTIME_USE_RX)))
 
 struct ath_softc {
diff --git a/drivers/net/wireless/ath/ath9k/debug.h 
b/drivers/net/wireless/ath/ath9k/debug.h
index 249f8141cd00..559d9628f280 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -319,20 +319,12 @@ ath9k_debug_sync_cause(struct ath_softc *sc, u32 
sync_cause)
 void ath_debug_rate_stats(struct ath_softc *sc,
  struct ath_rx_status *rs,
  struct sk_buff *skb);
-void ath_debug_airtime(struct ath_softc *sc,
-  struct ath_node *an,
-  u32 rx, u32 tx);
 #else
 static inline void ath_debug_rate_stats(struct ath_softc *sc,
struct ath_rx_status *rs,
struct sk_buff *skb)
 {
 }
-static inline void ath_debug_airtime(struct ath_softc *sc,
- struct ath_node *an,
- u32 rx, u32 tx)
-{
-}
 #endif /* CONFIG_ATH9K_STATION_STATISTICS */
 
 #endif /* DEBUG_H */
diff --git a/drivers/net/wireless/ath/ath9k/debug_sta.c 
b/drivers/net/wireless/ath/ath9k/debug_sta.c
index efc692ee67d4..89ba95287a8b 100644
--- a/drivers/net/wireless/ath/ath9k/debug_sta.c
+++ b/drivers/net/wireless/ath/ath9k/debug_sta.c
@@ -242,59 +242,6 @@ static const struct file_operations fops_node_recv = {
.llseek = default_llseek,
 };
 
-void ath_debug_airtime(struct ath_softc *sc,
-   struct ath_node *an,
-   u32 rx,
-   u32 tx)
-{
-   struct ath_airtime_stats *astats = >airtime_stats;
-
-   astats->rx_airtime += rx;
-   astats->tx_airtime += tx;
-}
-
-static ssize_t read_airtime(struct file *file, char __user *user_buf,
-   size_t count, loff_t *ppos)
-{
-   struct ath_node *an = file->private_data;
-   struct ath_airtime_stats *astats;
-   static const char *qname[4] = {
-   "VO", "VI", "BE", "BK"
-   };
-   u32 len = 0, size = 256;
-   char *buf;
-   size_t retval;
-   int i;
-
-   buf = kzalloc(size, GFP_KERNEL);
-   if (buf == NULL)
-   return -ENOMEM;
-
-   astats = >airtime_stats;
-
-   len += scnprintf(buf + len, size - len, "RX: %u us\n", 
astats->rx_airtime);
-   len += scnprintf(buf + len, size - len, "TX: %u us\n", 
astats->tx_airtime);
-   len += scnprintf(buf + len, size - len, "Deficit: ");
-   for (i = 0; i < 4; i++)
-   len += scnprintf(buf+len, size - len, "%s: %lld us ", qname[i], 
an->airtime_deficit[i]);
-   if (len < size)
-   buf[len++] = '\n';
-
-   retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
-   kfree(buf);
-
-   return retval;
-}
-
-
-static const struct file_operations fops_airtime = {
-   .read = read_airtime,
-   .open = simple_open,
-   .owner = THIS_MODULE,
-   .llseek = default_llseek,
-};
-
-
 void ath9k_sta_add_debugfs(struct ieee80211_hw *hw,
   struct

[PATCH v3 2/3] mac80211: Add airtime account and scheduling to TXQs

2017-10-31 Thread Toke Høiland-Jørgensen 
This adds airtime accounting and scheduling to the mac80211 TXQ
scheduler. A new hardware flag, AIRTIME_ACCOUNTING, is added that
drivers can set if they support reporting airtime usage of
transmissions. When this flag is set, mac80211 will expect the actual
airtime usage to be reported in the tx_time and rx_time fields of the
respective status structs.

When airtime information is present, mac80211 will schedule TXQs
(through ieee80211_next_txq()) in a way that enforces airtime fairness
between active stations. This scheduling works the same way as the ath9k
in-driver airtime fairness scheduling.

Signed-off-by: Toke Høiland-Jørgensen 
---
 include/net/mac80211.h | 24 
 net/mac80211/debugfs.c |  1 +
 net/mac80211/debugfs_sta.c | 29 +
 net/mac80211/ieee80211_i.h |  9 +++--
 net/mac80211/main.c|  3 ++-
 net/mac80211/rx.c  |  8 
 net/mac80211/sta_info.c|  2 ++
 net/mac80211/sta_info.h|  7 +++
 net/mac80211/status.c  | 16 
 net/mac80211/tx.c  | 31 ++-
 10 files changed, 122 insertions(+), 8 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 715f45501aff..453653d082af 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1188,6 +1188,8 @@ enum mac80211_rx_encoding {
  * HT or VHT is used (%RX_FLAG_HT/%RX_FLAG_VHT)
  * @nss: number of streams (VHT and HE only)
  * @flag: %RX_FLAG_\*
+ * @airtime: Duration of frame in usec. See @IEEE80211_HW_AIRTIME_ACCOUNTING 
for
+ *   how to use this.
  * @encoding:  mac80211_rx_encoding
  * @bw:  rate_info_bw
  * @enc_flags: uses bits from  mac80211_rx_encoding_flags
@@ -1202,6 +1204,7 @@ struct ieee80211_rx_status {
u32 device_timestamp;
u32 ampdu_reference;
u32 flag;
+   u16 airtime;
u16 freq;
u8 enc_flags;
u8 encoding:2, bw:3;
@@ -2059,6 +2062,26 @@ struct ieee80211_txq {
  * The stack will not do fragmentation.
  * The callback for @set_frag_threshold should be set as well.
  *
+ * @IEEE80211_HW_AIRTIME_ACCOUNTING: Hardware supports accounting the airtime
+ *  usage of other stations and reports it in the @tx_time and/or @airtime
+ *  fields of the TX/RX status structs.
+ *  When setting this flag, the driver should ensure that the respective
+ *  fields in the TX and RX status structs are always either zero or
+ *  contains a valid duration for the frame in usec. The driver can choose
+ *  to report either or both of TX and RX airtime, but it is recommended to
+ *  report both.
+ *  The reported airtime should as a minimum include all time that is spent
+ *  transmitting to the remote station, including overhead and padding, but
+ *  not including time spent waiting for a TXOP. If the time is not 
reported
+ *  by the hardware it can in some cases be calculated from the rate and
+ *  known frame composition. When possible, the time should include any
+ *  failed transmission attempts.
+ *  For aggregated frames, there are two possible strategies to report the
+ *  airtime: Either include the airtime of the entire aggregate in the 
first
+ *  (or last) frame and leave the others at zero. Alternatively, include 
the
+ *  overhead of the full aggregate in the first or last frame and report 
the
+ *  time of each frame + padding not including the full aggregate overhead.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2101,6 +2124,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_TX_FRAG_LIST,
IEEE80211_HW_REPORTS_LOW_ACK,
IEEE80211_HW_SUPPORTS_TX_FRAG,
+   IEEE80211_HW_AIRTIME_ACCOUNTING,
 
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 5fae001f286c..20e3aa0e8464 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -211,6 +211,7 @@ static const char *hw_flag_names[] = {
FLAG(TX_FRAG_LIST),
FLAG(REPORTS_LOW_ACK),
FLAG(SUPPORTS_TX_FRAG),
+   FLAG(AIRTIME_ACCOUNTING),
 #undef FLAG
 };
 
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index b15412c21ac9..40dba446836f 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -188,6 +188,32 @@ static ssize_t sta_aqm_read(struct file *file, char __user 
*userbuf,
 }
 STA_OPS(aqm);
 
+static ssize_t sta_airtime_read(struct file *file, char __user *userbuf,
+   size_t count, loff_t *ppos)
+{
+   struct sta_info *sta = file->private_data;
+   size_t bufsz = 200;
+   char *buf = kzalloc(bufsz, GFP_KERNEL), *p = buf;
+   ssize_t rv;
+
+   if (!buf)
+   return -ENOMEM;
+
+   spin_lock_bh(>lock);
+
+   p += scnprintf(p, bufsz + buf - p,
+   "RX: %llu

[PATCH 3/3] mwifiex: cleanup rx_reorder_tbl_lock usage

2017-10-31 Thread Ganapathi Bhat 
From: Karthik Ananthapadmanabha 

Fix the incorrect usage of rx_reorder_tbl_lock spinlock:

1. We shouldn't access the fields of the elements returned by
mwifiex_11n_get_rx_reorder_tbl() after we have released spin
lock. To fix this, To fix this, aquire the spinlock before
calling this function and release the lock only after processing
the corresponding element is complete.

2. Realsing the spinlock during iteration of the list and holding
it back before next iteration is unsafe. Fix it by releasing the
lock only after iteration of the list is complete.

Signed-off-by: Karthik Ananthapadmanabha 
Signed-off-by: Ganapathi Bhat 
---
 .../net/wireless/marvell/mwifiex/11n_rxreorder.c   | 34 +-
 drivers/net/wireless/marvell/mwifiex/uap_txrx.c|  3 ++
 2 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c 
b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index 4631bc2..b99ace8 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -234,23 +234,19 @@ static int mwifiex_11n_dispatch_pkt(struct 
mwifiex_private *priv, void *payload)
 
 /*
  * This function returns the pointer to an entry in Rx reordering
- * table which matches the given TA/TID pair.
+ * table which matches the given TA/TID pair. The caller must
+ * hold rx_reorder_tbl_lock, before calling this function.
  */
 struct mwifiex_rx_reorder_tbl *
 mwifiex_11n_get_rx_reorder_tbl(struct mwifiex_private *priv, int tid, u8 *ta)
 {
struct mwifiex_rx_reorder_tbl *tbl;
-   unsigned long flags;
 
-   spin_lock_irqsave(>rx_reorder_tbl_lock, flags);
list_for_each_entry(tbl, >rx_reorder_tbl_ptr, list) {
if (!memcmp(tbl->ta, ta, ETH_ALEN) && tbl->tid == tid) {
-   spin_unlock_irqrestore(>rx_reorder_tbl_lock,
-  flags);
return tbl;
}
}
-   spin_unlock_irqrestore(>rx_reorder_tbl_lock, flags);
 
return NULL;
 }
@@ -355,11 +351,14 @@ void mwifiex_11n_del_rx_reorder_tbl_by_ta(struct 
mwifiex_private *priv, u8 *ta)
 * If we get a TID, ta pair which is already present dispatch all the
 * the packets and move the window size until the ssn
 */
+   spin_lock_irqsave(>rx_reorder_tbl_lock, flags);
tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid, ta);
if (tbl) {
mwifiex_11n_dispatch_pkt_until_start_win(priv, tbl, seq_num);
+   spin_unlock_irqrestore(>rx_reorder_tbl_lock, flags);
return;
}
+   spin_unlock_irqrestore(>rx_reorder_tbl_lock, flags);
/* if !tbl then create one */
new_node = kzalloc(sizeof(struct mwifiex_rx_reorder_tbl), GFP_KERNEL);
if (!new_node)
@@ -571,15 +570,19 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private 
*priv,
u16 pkt_index;
bool init_window_shift = false;
int ret = 0;
+   unsigned long flags;
 
+   spin_lock_irqsave(>rx_reorder_tbl_lock, flags);
tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid, ta);
if (!tbl) {
+   spin_unlock_irqrestore(>rx_reorder_tbl_lock, flags);
if (pkt_type != PKT_TYPE_BAR)
mwifiex_11n_dispatch_pkt(priv, payload);
return ret;
}
 
if ((pkt_type == PKT_TYPE_AMSDU) && !tbl->amsdu) {
+   spin_unlock_irqrestore(>rx_reorder_tbl_lock, flags);
mwifiex_11n_dispatch_pkt(priv, payload);
return ret;
}
@@ -666,6 +669,8 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private *priv,
if (!tbl->timer_context.timer_is_set ||
prev_start_win != tbl->start_win)
mwifiex_11n_rxreorder_timer_restart(tbl);
+
+   spin_unlock_irqrestore(>rx_reorder_tbl_lock, flags);
return ret;
 }
 
@@ -683,6 +688,7 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private *priv,
struct mwifiex_ra_list_tbl *ra_list;
u8 cleanup_rx_reorder_tbl;
int tid_down;
+   unsigned long flags;
 
if (type == TYPE_DELBA_RECEIVE)
cleanup_rx_reorder_tbl = (initiator) ? true : false;
@@ -693,14 +699,18 @@ int mwifiex_11n_rx_reorder_pkt(struct mwifiex_private 
*priv,
peer_mac, tid, initiator);
 
if (cleanup_rx_reorder_tbl) {
+   spin_lock_irqsave(>rx_reorder_tbl_lock, flags);
tbl = mwifiex_11n_get_rx_reorder_tbl(priv, tid,
 peer_mac);
if (!tbl) {
+   spin_unlock_irqrestore(>rx_reorder_tbl_lock,
+  flags);
mwifiex_dbg(priv->adapter, EVENT,
"event:

[PATCH 2/3] mwifiex: cleanup tx_ba_stream_tbl_lock usage

2017-10-31 Thread Ganapathi Bhat 
From: Karthik Ananthapadmanabha 

Fix the incorrect usage of tx_ba_stream_tbl_lock spinlock:

1. We shouldn't access the fields of the elements returned by
mwifiex_get_ba_status() and mwifiex_get_ba_tbl(), after we have
released the spin lock. To fix this, aquire the spinlock before
calling these functions and release the lock only after
processing the correspnding element is complete.

2. Move tx_ba_stream_tbl_lock out of mwifiex_del_ba_tbl(), to
avoid recursive spinlock. Acquire the spinlock explicitly, before
calling mwifiex_del_ba_tbl().

Signed-off-by: Karthik Ananthapadmanabha 
Signed-off-by: Ganapathi Bhat 
---
 drivers/net/wireless/marvell/mwifiex/11n.c | 45 +-
 .../net/wireless/marvell/mwifiex/11n_rxreorder.c   |  3 --
 2 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/11n.c 
b/drivers/net/wireless/marvell/mwifiex/11n.c
index 8772e39..38d7b48 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n.c
@@ -77,24 +77,19 @@ int mwifiex_fill_cap_info(struct mwifiex_private *priv, u8 
radio_type,
 
 /*
  * This function returns the pointer to an entry in BA Stream
- * table which matches the requested BA status.
+ * table which matches the requested BA status. The caller
+ * must hold tx_ba_stream_tbl_lock before calling this function.
  */
 static struct mwifiex_tx_ba_stream_tbl *
 mwifiex_get_ba_status(struct mwifiex_private *priv,
  enum mwifiex_ba_status ba_status)
 {
struct mwifiex_tx_ba_stream_tbl *tx_ba_tsr_tbl;
-   unsigned long flags;
 
-   spin_lock_irqsave(>tx_ba_stream_tbl_lock, flags);
list_for_each_entry(tx_ba_tsr_tbl, >tx_ba_stream_tbl_ptr, list) {
-   if (tx_ba_tsr_tbl->ba_status == ba_status) {
-   spin_unlock_irqrestore(>tx_ba_stream_tbl_lock,
-  flags);
+   if (tx_ba_tsr_tbl->ba_status == ba_status)
return tx_ba_tsr_tbl;
-   }
}
-   spin_unlock_irqrestore(>tx_ba_stream_tbl_lock, flags);
return NULL;
 }
 
@@ -114,9 +109,11 @@ int mwifiex_ret_11n_delba(struct mwifiex_private *priv,
struct mwifiex_tx_ba_stream_tbl *tx_ba_tbl;
struct host_cmd_ds_11n_delba *del_ba = >params.del_ba;
uint16_t del_ba_param_set = le16_to_cpu(del_ba->del_ba_param_set);
+   unsigned long flags;
 
tid = del_ba_param_set >> DELBA_TID_POS;
if (del_ba->del_result == BA_RESULT_SUCCESS) {
+   spin_lock_irqsave(>tx_ba_stream_tbl_lock, flags);
mwifiex_del_ba_tbl(priv, tid, del_ba->peer_mac_addr,
   TYPE_DELBA_SENT,
   INITIATOR_BIT(del_ba_param_set));
@@ -125,6 +122,7 @@ int mwifiex_ret_11n_delba(struct mwifiex_private *priv,
if (tx_ba_tbl)
mwifiex_send_addba(priv, tx_ba_tbl->tid,
   tx_ba_tbl->ra);
+   spin_unlock_irqrestore(>tx_ba_stream_tbl_lock, flags);
} else { /*
  * In case of failure, recreate the deleted stream in case
  * we initiated the ADDBA
@@ -135,11 +133,13 @@ int mwifiex_ret_11n_delba(struct mwifiex_private *priv,
mwifiex_create_ba_tbl(priv, del_ba->peer_mac_addr, tid,
  BA_SETUP_INPROGRESS);
 
+   spin_lock_irqsave(>tx_ba_stream_tbl_lock, flags);
tx_ba_tbl = mwifiex_get_ba_status(priv, BA_SETUP_INPROGRESS);
 
if (tx_ba_tbl)
mwifiex_del_ba_tbl(priv, tx_ba_tbl->tid, tx_ba_tbl->ra,
   TYPE_DELBA_SENT, true);
+   spin_unlock_irqrestore(>tx_ba_stream_tbl_lock, flags);
}
 
return 0;
@@ -160,6 +160,7 @@ int mwifiex_ret_11n_addba_req(struct mwifiex_private *priv,
struct host_cmd_ds_11n_addba_rsp *add_ba_rsp = >params.add_ba_rsp;
struct mwifiex_tx_ba_stream_tbl *tx_ba_tbl;
struct mwifiex_ra_list_tbl *ra_list;
+   unsigned long flags;
u16 block_ack_param_set = le16_to_cpu(add_ba_rsp->block_ack_param_set);
 
add_ba_rsp->ssn = cpu_to_le16((le16_to_cpu(add_ba_rsp->ssn))
@@ -176,14 +177,17 @@ int mwifiex_ret_11n_addba_req(struct mwifiex_private 
*priv,
ra_list->ba_status = BA_SETUP_NONE;
ra_list->amsdu_in_ampdu = false;
}
+   spin_lock_irqsave(>tx_ba_stream_tbl_lock, flags);
mwifiex_del_ba_tbl(priv, tid, add_ba_rsp->peer_mac_addr,
   TYPE_DELBA_SENT, true);
+   spin_unlock_irqrestore(>tx_ba_stream_tbl_lock, flags);
if (add_ba_rsp->add_rsp_result != BA_RESULT_TIMEOUT)

[PATCH 0/3] mwifiex: fix usage issues with spinlocks

2017-10-31 Thread Ganapathi Bhat 
This patch series fixes issues with usage of few of the spinlocks
used by the driver. To summarise it fixes below issues:

1. Driver does access the elements returned by the list, without
acquiring the lock.

2. Driver release the lock during iteration of the list and hold
it back before starting the next iteration.

3. Driver release the lock while the element is still in process.

Karthik Ananthapadmanabha (3):
  mwifiex: cleanup rx_pkt_lock usage in 11n_rxreorder.c
  mwifiex: cleanup tx_ba_stream_tbl_lock usage
  mwifiex: cleanup rx_reorder_tbl_lock usage

 drivers/net/wireless/marvell/mwifiex/11n.c | 45 +-
 .../net/wireless/marvell/mwifiex/11n_rxreorder.c   | 42 +---
 drivers/net/wireless/marvell/mwifiex/uap_txrx.c|  3 ++
 3 files changed, 58 insertions(+), 32 deletions(-)

-- 
1.9.1

[PATCH 1/3] mwifiex: cleanup rx_pkt_lock usage in 11n_rxreorder.c

2017-10-31 Thread Ganapathi Bhat 
From: Karthik Ananthapadmanabha 

Fix the incorrect usage of rx_pkt_lock spinlock. Realsing the
spinlock while the element is still in process is unsafe. The
lock must be released only after the element processing is
complete.

Signed-off-by: Karthik Ananthapadmanabha 
Signed-off-by: Ganapathi Bhat 
---
 drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c 
b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
index 1edcdda..0149c4a 100644
--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
+++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
@@ -124,9 +124,10 @@ static int mwifiex_11n_dispatch_pkt(struct mwifiex_private 
*priv, void *payload)
rx_tmp_ptr = tbl->rx_reorder_ptr[i];
tbl->rx_reorder_ptr[i] = NULL;
}
-   spin_unlock_irqrestore(>rx_pkt_lock, flags);
if (rx_tmp_ptr)
mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
+
+   spin_unlock_irqrestore(>rx_pkt_lock, flags);
}
 
spin_lock_irqsave(>rx_pkt_lock, flags);
@@ -167,8 +168,8 @@ static int mwifiex_11n_dispatch_pkt(struct mwifiex_private 
*priv, void *payload)
}
rx_tmp_ptr = tbl->rx_reorder_ptr[i];
tbl->rx_reorder_ptr[i] = NULL;
-   spin_unlock_irqrestore(>rx_pkt_lock, flags);
mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
+   spin_unlock_irqrestore(>rx_pkt_lock, flags);
}
 
spin_lock_irqsave(>rx_pkt_lock, flags);
-- 
1.9.1

Re: PROBLEM: Issue with wireless driver after resume from suspend.

2017-10-31 Thread Kalle Valo 
Luca Coelho  writes:

>> I am having a issue with the wireless driver in my laptop. Attached
>> information
>> pertaining to the issue.
>
> It would be useful to specify which wireless card you are using.  In
> this case, the problem seems to be with ath10k.

For ath10k issues please also CC ath10k list:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/support

And please copy the relevant errors from the logs to the email, faster
that way.

-- 
Kalle Valo

Re: Need support for Intel new wifi module 9462NGW

2017-10-31 Thread Chris Chiu 
Great. Thanks.

On Tue, Oct 31, 2017 at 3:25 PM, Luca Coelho  wrote:
> On Tue, 2017-10-31 at 12:13 +0800, Chris Chiu wrote:
>> Hi,
>
> Hi Chris,
>
>
>> We just have the Intel new WiFi module 9462NGW from Acer and
>> tried
>> to verify if it works on the latest linux kernel. Unfortunately it
>> seems not even detected because the PCI ID seems unknown to the
>> iwlwifi driver. Then I add the following line to
>> drivers/net/wireless/intel/iwlwifi/pcie/drv.c
>> iwl_hw_card_ids
>> {IWL_PCI_DEVICE(0x31DC, 0x02A4, iwl9460_2ac_cfg)},
>>
>> dmesg shows the following
>>
>> [   12.994422] iwlwifi :00:0c.0: Direct firmware load for
>> iwlwifi-9260-th-b0-jf-b0-33.ucode failed with error -2
>> [   12.994442] iwlwifi :00:0c.0: Direct firmware load for
>> iwlwifi-9260-th-b0-jf-b0-32.ucode failed with error -2
>> [   12.994456] iwlwifi :00:0c.0: Direct firmware load for
>> iwlwifi-9260-th-b0-jf-b0-31.ucode failed with error -2
>> [   12.994470] iwlwifi :00:0c.0: Direct firmware load for
>> iwlwifi-9260-th-b0-jf-b0-30.ucode failed with error -2
>> [   12.994473] iwlwifi :00:0c.0: no suitable firmware found!
>> [   12.994477] iwlwifi :00:0c.0: minimum version required:
>> iwlwifi-9260-th-b0-jf-b0-30
>> [   12.994479] iwlwifi :00:0c.0: maximum version supported:
>> iwlwifi-9260-th-b0-jf-b0-33
>>
>>
>>
>> I'm not able to find these missing files in linux-firmware.git and
>> any
>> other possible place. What's the status of supporting this 9462NGW?
>> Please let me know if any more information required. Thanks
>
> Unfortunately we have not published the firmware for this NIC yet.
> I'll try to get an approval to publish it today (or latest by the end
> of the week) and I'll let you know.
>
> --
> Cheers,
> Luca.

Re: Need support for Intel new wifi module 9462NGW

2017-10-31 Thread Luca Coelho 
On Tue, 2017-10-31 at 12:13 +0800, Chris Chiu wrote:
> Hi,

Hi Chris,


> We just have the Intel new WiFi module 9462NGW from Acer and
> tried
> to verify if it works on the latest linux kernel. Unfortunately it
> seems not even detected because the PCI ID seems unknown to the
> iwlwifi driver. Then I add the following line to
> drivers/net/wireless/intel/iwlwifi/pcie/drv.c
> iwl_hw_card_ids
> {IWL_PCI_DEVICE(0x31DC, 0x02A4, iwl9460_2ac_cfg)},
> 
> dmesg shows the following
> 
> [   12.994422] iwlwifi :00:0c.0: Direct firmware load for
> iwlwifi-9260-th-b0-jf-b0-33.ucode failed with error -2
> [   12.994442] iwlwifi :00:0c.0: Direct firmware load for
> iwlwifi-9260-th-b0-jf-b0-32.ucode failed with error -2
> [   12.994456] iwlwifi :00:0c.0: Direct firmware load for
> iwlwifi-9260-th-b0-jf-b0-31.ucode failed with error -2
> [   12.994470] iwlwifi :00:0c.0: Direct firmware load for
> iwlwifi-9260-th-b0-jf-b0-30.ucode failed with error -2
> [   12.994473] iwlwifi :00:0c.0: no suitable firmware found!
> [   12.994477] iwlwifi :00:0c.0: minimum version required:
> iwlwifi-9260-th-b0-jf-b0-30
> [   12.994479] iwlwifi :00:0c.0: maximum version supported:
> iwlwifi-9260-th-b0-jf-b0-33
> 
> 
> 
> I'm not able to find these missing files in linux-firmware.git and
> any
> other possible place. What's the status of supporting this 9462NGW?
> Please let me know if any more information required. Thanks

Unfortunately we have not published the firmware for this NIC yet. 
I'll try to get an approval to publish it today (or latest by the end
of the week) and I'll let you know.

--
Cheers,
Luca.

Re: PROBLEM: Issue with wireless driver after resume from suspend.

2017-10-31 Thread Luca Coelho 
On Tue, 2017-10-31 at 12:21 +0530, Anil Nair wrote:
> Hi All,

Hi,


> I am having a issue with the wireless driver in my laptop. Attached
> information
> pertaining to the issue.

It would be useful to specify which wireless card you are using.  In
this case, the problem seems to be with ath10k.


--
Cheers,
Luca.

PROBLEM: Issue with wireless driver after resume from suspend.

2017-10-31 Thread Anil Nair 
Hi All,

I am having a issue with the wireless driver in my laptop. Attached information
pertaining to the issue.
 
  [1.] One line summary of the problem:

  Wifi not working after resuming from suspend state.

  [2.] Full description of the problem/report:

  I had put my laptop in suspend mode, after resmuing the laptop from suspend
  mode wifi stopped working, or rather not responding I tried switching the 
  airplane mode on then off still no effect.

  [3.] Keywords (i.e., modules, networking, kernel):

  Networking particularly Wireless Networking.

  [4.] Kernel information

  4.13.5

  [4.1.] Kernel version (from /proc/version):

  Linux version 4.13.5anil-1017 (root@anilnair-lenovo) 
  (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)) 
  #1 SMP Sat Oct 14 12:30:16 IST 2017

  [4.2.] Kernel .config file:

  Attached in the below mail file named config_kernel.txt

  [5.] Most recent kernel version which did not have the bug:

  4.4.0

  [6.] Output of Oops.. message (if applicable) with symbolic information
   resolved (see Documentation/admin-guide/oops-tracing.rst)
  
  Attached in the below mail file named error_log.txt

  [8.1.] Software (add the output of the ver_linux script here)
  
  Attached in the below mail file named software_version.txt
  
  [8.2.] Processor information (from /proc/cpuinfo):

  Attached in the below mail file named cpu_config.txt

  [8.3.] Module information (from /proc/modules):

  Attached in the below mail file named modules_config.txt

  [8.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)

  Attached in the below mail file named ioports_config.txt,iomem_config.txt,

  [8.5.] PCI information ('lspci -vvv' as root)

  Attached in the below mail file named pci_config.txt

  [8.6.] SCSI information (from /proc/scsi/scsi)

  Attached in the below mail file named cpu_config.txt

  [X.] Other notes, patches, fixes, workarounds:
  
  A reboot fixes the issue.
  
  All Files are compressed in the tar and sent.
  Let me know what went wrong and how can i fix it.
  Let me know if any further information is required.
  
  Thanking You.
  
  --
  Regards,
  Anil Nair
  


linux-bug-reporting.tar.gz
Description: application/gzip