RE: rt2800 and BeagleBone Black kernel panic when connecting to access point

[Craig McQueen]

Vishal Thanki wrote:
> Hi,
> 
> On Wed, Apr 27, 2016 at 02:21:36PM +1000, Craig McQueen wrote:
> > I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392
> chipset). I've been testing it on a BeagleBone Black running an Ubuntu 16.04
> image (4.4.6 kernel).
> >
> > 1) Install Ubuntu 16.04 on a BeagleBone Black.
> > 2) Add lines to /etc/network/interfaces for the device to connect to a
> WPA2 access point.
> > 3) Plug the rt2800 USB Wi-Fi device into the BeagleBone Black.
> >
> > Apparently when it tries to connect to the access point, I get a kernel 
> > panic.
> If I don't configure it (step 2 above) then the kernel panic doesn't happen.
> >
> > I've tested this with two access points: my Android phone acting as a
> hotspot, and a cheap TP-Link TD-W8968.
> >
> > Serial debug console shows:
> > ...
> 
> I have seen a similar crash and fixed it as a part of following commit:
> 
> 8b4c0009313f3d42e2540e3e1f776097dd0db73d
> 
> But it would be helpful if you can get paste the entire kernel log.
> Because in my case, I used to see a USB Disconnect event for the rt2800
> driver and the crash was caused due to that.

Okay, see the attached file. I can't see a USB Disconnect event for the rt2800, 
until the end (line 561, timestamp 222.861630) which is when I unplugged the 
USB hub.

-- 
Craig McQueen

[  112.308639] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:3:1101]
[  140.309750] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:3:1101]
[  168.310661] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:3:1101]
[  196.311519] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:3:1101]
[  222.813266] cpts: unable to obtain a time stamp

craigm@beaglebone-craig:~$ dmesg
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.6-ti-r15 (root@b3-jetson-tk1-2gb) (gcc version 
5.3.1 20160330 (Ubuntu/Linaro 5.3.1-13ubuntu3) ) #1 SMP Tue Apr 5 12:32:22 UTC 
2016
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine model: TI AM335x BeagleBone Black
[0.00] cma: Reserved 24 MiB at 0x9e00
[0.00] Memory policy: Data cache writeback
[0.00] On node 0 totalpages: 130560
[0.00] free_area_init_node: node 0, pgdat c0c25540, node_mem_map 
df96d000
[0.00]   Normal zone: 1152 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 130560 pages, LIFO batch:31
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES2.1 (sgx neon )
[0.00] PERCPU: Embedded 13 pages/cpu @df925000 s24268 r8192 d20788 
u53248
[0.00] pcpu-alloc: s24268 r8192 d20788 u53248 alloc=13*4096
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 129408
[0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 
root=/dev/mmcblk0p1 rootfstype=ext4 rootwait coherent_pool=1M quiet 
cape_universal=enable
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Memory: 474464K/522240K available (7303K kernel code, 912K 
rwdata, 3696K rodata, 584K init, 906K bss, 23200K reserved, 24576K 
cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
   vector  : 0x - 0x1000   (   4 kB)
   fixmap  : 0xffc0 - 0xfff0   (3072 kB)
   vmalloc : 0xe080 - 0xff80   ( 496 MB)
   lowmem  : 0xc000 - 0xe000   ( 512 MB)
   pkmap   : 0xbfe0 - 0xc000   (   2 MB)
   modules : 0xbf80 - 0xbfe0   (   6 MB)
 .text : 0xc0008000 - 0xc0ac5f34   (11000 kB)
 .init : 0xc0ac6000 - 0xc0b58000   ( 584 kB)
 .data : 0xc0b58000 - 0xc0c3c100   ( 913 kB)
  .bss : 0xc0c3f000 - 0xc0d21b90   ( 907 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00]  Build-time adjustment of leaf fanout to 32.
[0.00]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 
interrupts
[0.00] OMAP clockevent source: timer2 at 2400 Hz
[0.11] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 
89478484971ns
[0.30] 

Re: rt2800 and BeagleBone Black kernel panic when connecting to access point

[Vishal Thanki]

Hi,

On Wed, Apr 27, 2016 at 02:21:36PM +1000, Craig McQueen wrote:
> I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 
> chipset). I've been testing it on a BeagleBone Black running an Ubuntu 16.04 
> image (4.4.6 kernel).
> 
> 1) Install Ubuntu 16.04 on a BeagleBone Black.
> 2) Add lines to /etc/network/interfaces for the device to connect to a WPA2 
> access point.
> 3) Plug the rt2800 USB Wi-Fi device into the BeagleBone Black.
> 
> Apparently when it tries to connect to the access point, I get a kernel 
> panic. If I don't configure it (step 2 above) then the kernel panic doesn't 
> happen.
> 
> I've tested this with two access points: my Android phone acting as a 
> hotspot, and a cheap TP-Link TD-W8968.
> 
> Serial debug console shows:
> 
> [  306.884793] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor 
> Request 0x07 failed for offset 0x1004 with error -110
> [  306.996804] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor 
> Request 0x06 failed for offset 0x1004 with error -110
> [  307.057021] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor 
> Request 0x07 failed for offset 0x0500 with error -19
> [  307.102417] Unable to handle kernel NULL pointer dereference at virtual 
> address 002c
> [  307.110768] pgd = ddd34000
> [  307.113555] [002c] *pgd=
> [  307.117257] Internal error: Oops: 5 [#1] SMP THUMB2
> [  307.122269] Modules linked in: arc4 rt2800usb rt2800lib rt2x00usb 
> rt2x00lib mac80211 crc_ccitt cfg80211 rfkill snd_soc_simple_card omap_aes 
> omap_sham usb_f_ecm g_ether usb_f_rndis u_ether libcomposite omap_rng 
> rng_core snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap spi_omap2_mcspi 
> snd_soc_hdmi_codec snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd 
> soundcore evdev uio_pdrv_genirq uio tilcdc tda998x
> [  307.159448] CPU: 0 PID: 875 Comm: wpa_supplicant Not tainted 4.4.6-ti-r15 
> #1
> [  307.166672] Hardware name: Generic AM33XX (Flattened Device Tree)
> [  307.172921] task: dcf56180 ti: dd8e6000 task.ti: dd8e6000
> [  307.178470] PC is at _raw_spin_lock_irqsave+0x14/0x40
> [  307.183755] LR is at rt2x00queue_get_entry+0x1e/0x54 [rt2x00lib]
> [  307.189928] pc : []lr : []psr: 800b01b3
> [  307.189928] sp : dd8e79a0  ip :   fp : dc94f900
> [  307.201687] r10: c0b5ba88  r9 : dcda6928  r8 : dcda692c
> [  307.207042] r7 : 0054  r6 : 002c  r5 :   r4 : 0002
> [  307.213731] r3 : 0150  r2 : 002c  r1 : 0001  r0 : 800b0193
> [  307.220423] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA Thumb  
> Segment none
> [  307.228007] Control: 50c5387d  Table: 9dd34019  DAC: 0051
> [  307.233896] Process wpa_supplicant (pid: 875, stack limit = 0xdd8e6218)
> [  307.240675] Stack: (0xdd8e79a0 to 0xdd8e8000)
> [  307.245159] 79a0: 0150 0002  0054 ddf26de0 bfac8803 
> ddf26de0 ddf27144
> [  307.253559] 79c0: dcda6800  dcda692c bfac8971  c04fc087 
> c000a439 dde057c0
> [  307.261945] 79e0: dc94f900 bfaab2ff bfaab2e9 dc94f900 000b0113 c04fc1d3 
> ddcc4038 dc94f914
> [  307.270331] 7a00: dcda6924 dd8e7a14  c04fc2dd df925d8c dd8e7a14 
> dd8e7a14 dc8ba606
> [  307.278715] 7a20: df925d80 dcda6938   000f4240 c095df60 
> c095dfa8 dcda6934
> [  307.287099] 7a40: 0018 c0034acf c0b5b098 0006 c0c29d8c 0040 
> dd8e6000 dd8e7b90
> [  307.295483] 7a60: 0007 c0034c85 004c4b29  0101 dd8e7a68 
> c0b5b080 c0c40380
> [  307.303889] 7a80: 000a 06e1 c0b5b140 00400140 c00856ed 200b0113 
> e000 dddfc2bc
> [  307.312282] 7aa0:  0304 dd8e7b90 ddf0e840 000f c0034ea7 
> 01ff c0034f33
> [  307.320666] 7ac0: 001e dddfc000 da84ec40 c0628085 dd8e7ca0 dddfc090 
> 6013 
> [  307.329050] 7ae0: da84ec40 dd8e7b90 ddf0e840 0005  ddf0e840 
> 000f c05f11e5
> [  307.337437] 7b00:  0020 7ea0 ddf0e840 0020 c014402d 
>  7ea0
> [  307.351143] 7b20:    dd8e7e50 dd8e7e4c dd8e7e48 
> dd8e7e40 dd8e7e44
> [  307.364750] 7b40: dd8e7e48      
> 024152c0 dd8e7e24
> [  307.378341] 7b60: c0b5d930  dd8e7f74 dd8e7b88 c0b5ba88 dd8e6000 
> 004c4b29 
> [  307.391976] 7b80: 0001 3b9aca00 a6ad6574 0048  00db 
>  dcf56180
> [  307.405640] 7ba0:   0008 ddf0e840 00db  
> dd8e7b90 c01439a1
> [  307.419316] 7bc0: dc026784 dc026784 dc026780 ddf4bcc0 00db  
> dd8e7b90 c01439a1
> [  307.433008] 7be0: dc026204 dc026204 dc026200 ddf4bf00 00db  
> dd8e7b90 c01439a1
> [  307.446684] 7c00: dc02612c dc02612c dc026128 ddf4bc00 00db  
> dd8e7b90 c01439a1
> [  307.460325] 7c20: dc026984 dc026984 dc026980 dc060cc0 00db  
> dd8e7b90 c01439a1
> [  307.473925] 7c40: dc026144 dc026144 dc026140 dc0603c0 00db  
> dd8e7b90 c01439a1
> [  307.487339] 7c60: ddb1b104 ddb1b104 ddb1b100 dc0609c0 

rt2800 and BeagleBone Black soft lockup when unplugging from USB hub

[Craig McQueen]

I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 chipset). 
I've been testing it on a BeagleBone Black running an Ubuntu 16.04 image (4.4.6 
kernel), with a USB hub.

When I unplug the Wi-Fi device from the USB hub, and it's connected to an 
access point, and then I unplug it, the OS appears to lock up. I get messages 
about a soft lockup on the serial console:

[ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9764.136701] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9792.136701] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9820.136699] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9848.136696] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]

This will repeat indefinitely, until I unplug the hub, which resolves the soft 
lockup and then the system seems to function normally.

I've attached a dmesg log of the soft lockup stack traces. They seem to 
indicate a lockup in workqueue rt2x00usb_work_rxdone() (specifically in 
usb_hcd_submit_urb() called from rt2x00usb_kick_rx_entry() called from 
rt2x00usb_clear_entry()).

I originally found this bug on a 3.14.x kernel built with Yocto for a 
BeagleBone Black-based product. So it seems this is a bug that has been around 
for some time.

-- 
Craig McQueen

[ 9736.136702] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9764.136701] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9792.136701] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9820.136699] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9848.136696] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9852.998151] cpts: unable to obtain a time stamp

craigm@beaglebone-craig:~$ dmesg
...
[ 9366.664797] usb 1-1: new high-speed USB device number 4 using musb-hdrc
[ 9366.796197] usb 1-1: New USB device found, idVendor=2109, idProduct=2812
[ 9366.796248] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9366.796279] usb 1-1: Product: USB2.0 Hub 
[ 9366.796308] usb 1-1: Manufacturer: VIA Labs, Inc. 
[ 9366.809649] hub 1-1:1.0: USB hub found
[ 9366.813937] hub 1-1:1.0: 4 ports detected
[ 9371.836876] usb 1-1.1: new high-speed USB device number 5 using musb-hdrc
[ 9371.953209] usb 1-1.1: New USB device found, idVendor=2001, idProduct=3c20
[ 9371.953259] usb 1-1.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 9371.953291] usb 1-1.1: Product: 802.11 n WLAN
[ 9371.953319] usb 1-1.1: Manufacturer: Ralink
[ 9371.953348] usb 1-1.1: SerialNumber: 1.0
[ 9373.264832] usb 1-1.1: reset high-speed USB device number 5 using musb-hdrc
[ 9373.374188] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 5392, rev 0223 
detected
[ 9373.391020] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 5372 detected
[ 9373.402442] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 9373.427413] usbcore: registered new interface driver rt2800usb
[ 9373.572855] rt2800usb 1-1.1:1.0 wlx9cd64384611d: renamed from wlan0
[ 9373.920791] ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading 
firmware file 'rt2870.bin'
[ 9373.922515] ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware 
detected - version: 0.29
[ 9374.076725] IPv6: ADDRCONF(NETDEV_UP): wlx9cd64384611d: link is not ready
[ 9382.591520] wlx9cd64384611d: authenticate with e8:94:f6:5a:95:9a
[ 9382.629936] wlx9cd64384611d: send auth to e8:94:f6:5a:95:9a (try 1/3)
[ 9382.631970] wlx9cd64384611d: authenticated
[ 9382.644913] wlx9cd64384611d: associate with e8:94:f6:5a:95:9a (try 1/3)
[ 9382.647039] wlx9cd64384611d: RX AssocResp from e8:94:f6:5a:95:9a 
(capab=0x411 status=0 aid=1)
[ 9382.656390] wlx9cd64384611d: associated
[ 9382.656516] IPv6: ADDRCONF(NETDEV_CHANGE): wlx9cd64384611d: link becomes 
ready
[ 9708.136709] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! 
[kworker/u2:0:1129]
[ 9708.144990] Modules linked in: rt2800usb rt2800lib rt2x00usb rt2x00lib 
crc_ccitt ccm arc4 rtl8192cu rtl_usb rtl8192c_common rtlwifi mac80211 cfg80211 
rfkill snd_soc_simple_card omap_sham omap_aes usb_f_ecm g_ether usb_f_rndis 
u_ether libcomposite omap_rng rng_core snd_soc_davinci_mcasp snd_soc_edma 
snd_soc_omap spi_omap2_mcspi snd_soc_hdmi_codec snd_soc_core snd_pcm_dmaengine 
snd_pcm snd_timer snd soundcore evdev uio_pdrv_genirq uio tilcdc tda998x
[ 9708.145353] CPU: 0 PID: 1129 Comm: kworker/u2:0 Not tainted 4.4.6-ti-r15 #1
[ 9708.145379] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 9708.145477] Workqueue: phy1 rt2x00usb_work_rxdone [rt2x00usb]
[ 9708.145508] task: ddbb5b00 ti: ddf48000 task.ti: ddf48000
[ 9708.145556] PC is at v7_dma_inv_range+0x36/0x40
[ 9708.145585] LR is at __dma_page_cpu_to_dev+0x21/0x74
[ 9708.145614] pc : []lr : []psr: 800e0033
   sp : ddf49d10  

RE: rt2800 and BeagleBone Black kernel panic when connecting to access point

[Craig McQueen]

I previously wrote:
> 
> I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392
> chipset). I've been testing it on a BeagleBone Black running an Ubuntu 16.04
> image (4.4.6 kernel).
> 
> 1) Install Ubuntu 16.04 on a BeagleBone Black.
> 2) Add lines to /etc/network/interfaces for the device to connect to a WPA2
> access point.
> 3) Plug the rt2800 USB Wi-Fi device into the BeagleBone Black.
> 
> Apparently when it tries to connect to the access point, I get a kernel 
> panic. If
> I don't configure it (step 2 above) then the kernel panic doesn't happen.
> 
> I've tested this with two access points: my Android phone acting as a
> hotspot, and a cheap TP-Link TD-W8968.

I should add an extra interesting detail: if I plug the Wi-Fi device into a USB 
hub, instead of directly into the BeagleBone Black, then the kernel panic 
doesn't happen, and I'm able to use it successfully (although with other 
problems which I'll report in further e-mails).

-- 
Craig McQueen


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

rt2800 and BeagleBone Black kernel panic when connecting to access point

[Craig McQueen]

I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 chipset). 
I've been testing it on a BeagleBone Black running an Ubuntu 16.04 image (4.4.6 
kernel).

1) Install Ubuntu 16.04 on a BeagleBone Black.
2) Add lines to /etc/network/interfaces for the device to connect to a WPA2 
access point.
3) Plug the rt2800 USB Wi-Fi device into the BeagleBone Black.

Apparently when it tries to connect to the access point, I get a kernel panic. 
If I don't configure it (step 2 above) then the kernel panic doesn't happen.

I've tested this with two access points: my Android phone acting as a hotspot, 
and a cheap TP-Link TD-W8968.

Serial debug console shows:

[  306.884793] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 
0x07 failed for offset 0x1004 with error -110
[  306.996804] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 
0x06 failed for offset 0x1004 with error -110
[  307.057021] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 
0x07 failed for offset 0x0500 with error -19
[  307.102417] Unable to handle kernel NULL pointer dereference at virtual 
address 002c
[  307.110768] pgd = ddd34000
[  307.113555] [002c] *pgd=
[  307.117257] Internal error: Oops: 5 [#1] SMP THUMB2
[  307.122269] Modules linked in: arc4 rt2800usb rt2800lib rt2x00usb rt2x00lib 
mac80211 crc_ccitt cfg80211 rfkill snd_soc_simple_card omap_aes omap_sham 
usb_f_ecm g_ether usb_f_rndis u_ether libcomposite omap_rng rng_core 
snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap spi_omap2_mcspi 
snd_soc_hdmi_codec snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd 
soundcore evdev uio_pdrv_genirq uio tilcdc tda998x
[  307.159448] CPU: 0 PID: 875 Comm: wpa_supplicant Not tainted 4.4.6-ti-r15 #1
[  307.166672] Hardware name: Generic AM33XX (Flattened Device Tree)
[  307.172921] task: dcf56180 ti: dd8e6000 task.ti: dd8e6000
[  307.178470] PC is at _raw_spin_lock_irqsave+0x14/0x40
[  307.183755] LR is at rt2x00queue_get_entry+0x1e/0x54 [rt2x00lib]
[  307.189928] pc : []lr : []psr: 800b01b3
[  307.189928] sp : dd8e79a0  ip :   fp : dc94f900
[  307.201687] r10: c0b5ba88  r9 : dcda6928  r8 : dcda692c
[  307.207042] r7 : 0054  r6 : 002c  r5 :   r4 : 0002
[  307.213731] r3 : 0150  r2 : 002c  r1 : 0001  r0 : 800b0193
[  307.220423] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA Thumb  Segment 
none
[  307.228007] Control: 50c5387d  Table: 9dd34019  DAC: 0051
[  307.233896] Process wpa_supplicant (pid: 875, stack limit = 0xdd8e6218)
[  307.240675] Stack: (0xdd8e79a0 to 0xdd8e8000)
[  307.245159] 79a0: 0150 0002  0054 ddf26de0 bfac8803 
ddf26de0 ddf27144
[  307.253559] 79c0: dcda6800  dcda692c bfac8971  c04fc087 
c000a439 dde057c0
[  307.261945] 79e0: dc94f900 bfaab2ff bfaab2e9 dc94f900 000b0113 c04fc1d3 
ddcc4038 dc94f914
[  307.270331] 7a00: dcda6924 dd8e7a14  c04fc2dd df925d8c dd8e7a14 
dd8e7a14 dc8ba606
[  307.278715] 7a20: df925d80 dcda6938   000f4240 c095df60 
c095dfa8 dcda6934
[  307.287099] 7a40: 0018 c0034acf c0b5b098 0006 c0c29d8c 0040 
dd8e6000 dd8e7b90
[  307.295483] 7a60: 0007 c0034c85 004c4b29  0101 dd8e7a68 
c0b5b080 c0c40380
[  307.303889] 7a80: 000a 06e1 c0b5b140 00400140 c00856ed 200b0113 
e000 dddfc2bc
[  307.312282] 7aa0:  0304 dd8e7b90 ddf0e840 000f c0034ea7 
01ff c0034f33
[  307.320666] 7ac0: 001e dddfc000 da84ec40 c0628085 dd8e7ca0 dddfc090 
6013 
[  307.329050] 7ae0: da84ec40 dd8e7b90 ddf0e840 0005  ddf0e840 
000f c05f11e5
[  307.337437] 7b00:  0020 7ea0 ddf0e840 0020 c014402d 
 7ea0
[  307.351143] 7b20:    dd8e7e50 dd8e7e4c dd8e7e48 
dd8e7e40 dd8e7e44
[  307.364750] 7b40: dd8e7e48      
024152c0 dd8e7e24
[  307.378341] 7b60: c0b5d930  dd8e7f74 dd8e7b88 c0b5ba88 dd8e6000 
004c4b29 
[  307.391976] 7b80: 0001 3b9aca00 a6ad6574 0048  00db 
 dcf56180
[  307.405640] 7ba0:   0008 ddf0e840 00db  
dd8e7b90 c01439a1
[  307.419316] 7bc0: dc026784 dc026784 dc026780 ddf4bcc0 00db  
dd8e7b90 c01439a1
[  307.433008] 7be0: dc026204 dc026204 dc026200 ddf4bf00 00db  
dd8e7b90 c01439a1
[  307.446684] 7c00: dc02612c dc02612c dc026128 ddf4bc00 00db  
dd8e7b90 c01439a1
[  307.460325] 7c20: dc026984 dc026984 dc026980 dc060cc0 00db  
dd8e7b90 c01439a1
[  307.473925] 7c40: dc026144 dc026144 dc026140 dc0603c0 00db  
dd8e7b90 c01439a1
[  307.487339] 7c60: ddb1b104 ddb1b104 ddb1b100 dc0609c0 00db  
dd8e7b90 c01439a1
[  307.500597] 7c80: dde03844 dde03844 dde03840 dc060e40 00db  
dd8e7b90 c01439a1
[  307.513712] 7ca0: dde037c4 dde037c4 dde037c0 ddb7b000 dcf0c480 c0627d0b 
0004 0002
[  307.526882] 7cc0: ffed dc8ba606 

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Ben Greear]

On 04/26/2016 01:07 PM, Krishna Chaitanya wrote:

On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle  wrote:

Johannes Berg  writes:


On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:


The thing is, it actually works just fine with the patch I posted
to fix mac80211, and at any rate, even if the mac80211 patch isn't
applied, the ath10k driver works just fine in HT mode.


This patch has no implications on HT, and I wasn't planning on applying
the mac80211 patch.


Yeah, makes sense. I'm planning to apply this soon.


As I said, I have no objections to doing the (Broadcom) vendor specific
IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
the spec IEs when they're explicitly specified to be used only in the
5.2 GHz band.


But we really should have this, any volunteers? :) I think it shouldn't
be too hard to do so this would be a good project for someone looking
for a simple, but useful, task on wireless stack.

Are these Broadcom IEs documented somewhere? If yes,
then its a matter of parsing them and adding support to
minstrel_ht, isn't it? major work would be in minstrel.



For ath10k, rate-ctrl is done in the firmware, so
no work at all in minstrel-ht.

The end result, as far as I can tell,
is you would just have to tell mac80211 to allow
VHT on 2.4Ghz, and revert this patch that Kalle is proposing.

Maybe someone that actually knows about these IEs can explain why
they are worth using?

Thanks,
Ben

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

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Krishna Chaitanya]

On Tue, Apr 26, 2016 at 5:33 PM, Valo, Kalle  wrote:
> Johannes Berg  writes:
>
>> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>>
>>> The thing is, it actually works just fine with the patch I posted
>>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>>> applied, the ath10k driver works just fine in HT mode.
>>
>> This patch has no implications on HT, and I wasn't planning on applying
>> the mac80211 patch.
>
> Yeah, makes sense. I'm planning to apply this soon.
>
>> As I said, I have no objections to doing the (Broadcom) vendor specific
>> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
>> the spec IEs when they're explicitly specified to be used only in the
>> 5.2 GHz band.
>
> But we really should have this, any volunteers? :) I think it shouldn't
> be too hard to do so this would be a good project for someone looking
> for a simple, but useful, task on wireless stack.
Are these Broadcom IEs documented somewhere? If yes,
then its a matter of parsing them and adding support to
minstrel_ht, isn't it? major work would be in minstrel.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel WiFi regression on linux-next

[Luca Coelho]

On Tue, 2016-04-26 at 10:14 -0700, Mitchel Humpherys wrote:
> Hello,

Hello Mitchel,


> WiFi on my Acer Aspire 5739G is currently broken on linux-next.  I
> bisected it to the following commit:
> 
> commit 97f95c93c8ed5177371e75275f236513152fa308
> Author: Sara Sharon 
> Date:   Mon Mar 7 16:55:20 2016 +0200
> 
> iwlwifi: remove support for fw older than -16.ucode
> 
> This issue was already reported here [1].  I'm just adding some more
> hardware details (and am not subscribed to linux-wireless so I can't
> reply over there).
> 
> It's failing with:
> 
> iwlwifi :05:00.0: enabling device ( -> 0002)
> iwlwifi :05:00.0: can't disable ASPM; OS doesn't have ASPM
> control
> iwlwifi :05:00.0: Driver unable to support your firmware API.
> Driver supports v5, firmware is v139658497.
> iwlwifi :05:00.0: Direct firmware load for iwlwifi-5000-
> 4.ucode failed with error -2
> iwlwifi :05:00.0: request for firmware file 'iwlwifi-5000-
> 4.ucode' failed.
> iwlwifi :05:00.0: Direct firmware load for iwlwifi-5000-
> 3.ucode failed with error -2
> iwlwifi :05:00.0: request for firmware file 'iwlwifi-5000-
> 3.ucode' failed.
> iwlwifi :05:00.0: Driver unable to support your firmware API.
> Driver supports v5, firmware is v135791116.
> iwlwifi :05:00.0: Driver unable to support your firmware API.
> Driver supports v5, firmware is v84148496.
> iwlwifi :05:00.0: no suitable firmware found!

This was fixed in a patch I sent to Kalle yesterday and he merged
today:

http://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next
.git/commit/?id=f0d8f38cd909e072833a06b79939256c4aebe3a0

HTH.

--
Cheers,
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Intel WiFi regression on linux-next

[Mitchel Humpherys]

Hello,

WiFi on my Acer Aspire 5739G is currently broken on linux-next.  I
bisected it to the following commit:

commit 97f95c93c8ed5177371e75275f236513152fa308
Author: Sara Sharon 
Date:   Mon Mar 7 16:55:20 2016 +0200

iwlwifi: remove support for fw older than -16.ucode

This issue was already reported here [1].  I'm just adding some more
hardware details (and am not subscribed to linux-wireless so I can't
reply over there).

It's failing with:

iwlwifi :05:00.0: enabling device ( -> 0002)
iwlwifi :05:00.0: can't disable ASPM; OS doesn't have ASPM control
iwlwifi :05:00.0: Driver unable to support your firmware API. Driver 
supports v5, firmware is v139658497.
iwlwifi :05:00.0: Direct firmware load for iwlwifi-5000-4.ucode failed 
with error -2
iwlwifi :05:00.0: request for firmware file 'iwlwifi-5000-4.ucode' 
failed.
iwlwifi :05:00.0: Direct firmware load for iwlwifi-5000-3.ucode failed 
with error -2
iwlwifi :05:00.0: request for firmware file 'iwlwifi-5000-3.ucode' 
failed.
iwlwifi :05:00.0: Driver unable to support your firmware API. Driver 
supports v5, firmware is v135791116.
iwlwifi :05:00.0: Driver unable to support your firmware API. Driver 
supports v5, firmware is v84148496.
iwlwifi :05:00.0: no suitable firmware found!

Here's some more info on my wireless chipset:

05:00.0 Network controller: Intel Corporation WiFi Link 5100
Subsystem: Intel Corporation WiFi Link 5100 AGN
Flags: bus master, fast devsel, latency 0, IRQ 31
Memory at c040 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-1e-65-ff-ff-80-25-f6
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

The laptop isn't _that_ old so I'm surprised the driver is ripping out
support for it...  Is there some other driver I should be using?


[1] https://www.mail-archive.com/linux-wireless@vger.kernel.org/msg22688.html


-- 
Mitch
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 0/8] netlink: align attributes when needed (patchset #3)

[David Miller]

From: Lars Ellenberg 
Date: Tue, 26 Apr 2016 13:54:27 +0200

> On Tue, Apr 26, 2016 at 10:06:10AM +0200, Nicolas Dichtel wrote:
>> 
>> This is the continuation (series #3) of the work done to align netlink
>> attributes when these attributes contain some 64-bit fields.
>> 
>> It's the last patchset from what I've seen.
>> 
>> The last user of nla_put_u64() is block/drbd. This module does not use
>> standard netlink API (see all the stuff in include/linux/genl_magic_struct.h
>> and include/linux/genl_magic_func.h). I didn't modify it because it's seems
>> hard to do it whithout testing and fully understanding the context
> 
> Something like this should just work.

Unfortunately we had problems using unspec, that's why an explicit new
padding attribute is added for each netlink attribute set.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()

[David Miller]

From: Jan Kara 
Date: Tue, 26 Apr 2016 13:08:48 +0200

> On Tue 26-04-16 10:06:13, Nicolas Dichtel wrote:
>> Signed-off-by: Nicolas Dichtel 
> 
> OK, so I somewhat miss a description of what will this do to the netlink
> message so that I can judge whether the change is fine for the userspace
> counterpart parsing these messages. AFAIU this changes the message format
> by adding a QUOTA_NL_A_PAD field before each 64-bit field which needs an
> alignment, am I guessing right? Thus when the userspace counterpart uses
> genlmsg_parse() it should just silently ignore these attributes if I read
> the documentation right. Did I understand this correctly?

All userspace components using netlink should always ignore attributes
they do not recognize in dumps.

This is one of the most basic principles of netlink.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] Sampling Holes in Minstrel when VHT is enabled

[Krishna Chaitanya]

Hi,

With the current design, occasionally we are seeing issues
where minstrel sends 3x3 rates for our 2x2 chip.

IMHO, couple of things can cause this

1) update_caps doesn't take local HW capabilities in to account

2) While calculating sample_idx, we use MCS_GROUP_RATES
which can cause a sampling hole.

For eg: if sample_idx: 78, group will be 7 it is HT
so rate_idx will be : 8  +  (2-1) * 8 = 16 = 3x3 MCS0 20 MHz.

ideally we should add

a) local hw_checks and update groups.supported accordingly.

b) use the formula index % get_max_group_rates (or) replace all
instances of MCS_GROUP_RATES for HT with 8.
(in set_rate, get_sampling_rate etc..)


-- 
Thanks,
Regards,
Chaitanya T K.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 0/8] netlink: align attributes when needed (patchset #3)

[David Miller]

From: Nicolas Dichtel 
Date: Tue, 26 Apr 2016 10:06:10 +0200

> The last user of nla_put_u64() is block/drbd. This module does not use
> standard netlink API (see all the stuff in include/linux/genl_magic_struct.h
> and include/linux/genl_magic_func.h).

Yet another example where doing things in a special unique way creates
headaches and pain for everyone... sigh.

> I didn't modify it because it's seems hard to do it whithout testing
> and fully understanding the context (for example, why
> include/linux/drbd_genl.h is not part of uapi?).  Any thoughts?

I think you'll need to work with the drbd maintainer(s) to resolve
this and test the result.

Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ath10k: fix kernel panic, move arvifs list head init before htt init

[akolli]

From: Anilkumar Kolli 

It is observed that while loading and unloading ath10k modules
in an infinite loop, before ath10k_core_start() completion HTT
rx frames are received, while processing these frames,
dereferencing the arvifs list code is getting hit before
initilizing the arvifs list, causing a kernel panic.

This patch initilizes the arvifs list before initilizing htt.

Fixes the below issue:
 [] (ath10k_htt_rx_pktlog_completion_handler+0x278/0xd08 
[ath10k_core])
 [] (ath10k_htt_rx_pktlog_completion_handler [ath10k_core])
 [] (ath10k_htt_txrx_compl_task+0x5f4/0xeb0 [ath10k_core])
 [] (ath10k_htt_txrx_compl_task [ath10k_core])
 [] (tasklet_action+0x8c/0xec)
 [] (tasklet_action)
 [] (__do_softirq+0xf8/0x228)
 [] (__do_softirq)  [] (run_ksoftirqd+0x30/0x90)
 Code: e5954ad8 e2899008 e1540009 0a0d (e5943008)
 ---[ end trace 71de5c2e011dbf56 ]---
 Kernel panic - not syncing: Fatal exception in interrupt

Fixes: 500ff9f9389d ("ath10k: implement chanctx API")
Cc: sta...@vger.kernel.org

Signed-off-by: Anilkumar Kolli 
---
 drivers/net/wireless/ath/ath10k/core.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index b2c7fe3d30a4..83e02f292828 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1822,6 +1822,10 @@ int ath10k_core_start(struct ath10k *ar, enum 
ath10k_firmware_mode mode)
goto err_hif_stop;
}
 
+   ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1;
+
+   INIT_LIST_HEAD(>arvifs);
+
/* we don't care about HTT in UTF mode */
if (mode == ATH10K_FIRMWARE_MODE_NORMAL) {
status = ath10k_htt_setup(>htt);
@@ -1835,10 +1839,6 @@ int ath10k_core_start(struct ath10k *ar, enum 
ath10k_firmware_mode mode)
if (status)
goto err_hif_stop;
 
-   ar->free_vdev_map = (1LL << ar->max_num_vdevs) - 1;
-
-   INIT_LIST_HEAD(>arvifs);
-
return 0;
 
 err_hif_stop:
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ath10k: Move spectral related structures under ath10k debugfs

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

Spectral related structures are accessed / modified only if ath10k
debugfs is enabled, so it makes more sense to move them under
ATH10K_DEBUGFS

Signed-off-by: Mohammed Shafi Shajakhan 
---
[compile tested disabling ATH10K_DEBUGFS]

 drivers/net/wireless/ath/ath10k/core.h |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index c23c373..48fffef 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -868,8 +868,6 @@ struct ath10k {
 
 #ifdef CONFIG_ATH10K_DEBUGFS
struct ath10k_debug debug;
-#endif
-
struct {
/* relay(fs) channel for spectral scan */
struct rchan *rfs_chan_spec_scan;
@@ -878,6 +876,7 @@ struct ath10k {
enum ath10k_spectral_mode mode;
struct ath10k_spec_scan config;
} spectral;
+#endif
 
struct {
/* protected by conf_mutex */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mwifiex: change sleep cookie poll count

[Amitkumar Karwar]

From: Shengzhen Li 

Sometimes current polling count is not sufficient.
This patch increases it to 100.

Signed-off-by: Shengzhen Li 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/pcie.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.h 
b/drivers/net/wireless/marvell/mwifiex/pcie.h
index 5770b43..9a1d09d 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.h
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.h
@@ -117,7 +117,7 @@
 /* FW awake cookie after FW ready */
 #define FW_AWAKE_COOKIE
(0xAA55AA55)
 #define MWIFIEX_DEF_SLEEP_COOKIE   0xBEEFBEEF
-#define MWIFIEX_MAX_DELAY_COUNT5
+#define MWIFIEX_MAX_DELAY_COUNT100
 
 struct mwifiex_pcie_card_reg {
u16 cmd_addr_lo;
-- 
1.8.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()

[Jan Kara]

On Tue 26-04-16 14:31:58, Nicolas Dichtel wrote:
> Le 26/04/2016 13:08, Jan Kara a écrit :
> > On Tue 26-04-16 10:06:13, Nicolas Dichtel wrote:
> >> Signed-off-by: Nicolas Dichtel 
> > 
> > OK, so I somewhat miss a description of what will this do to the netlink
> > message so that I can judge whether the change is fine for the userspace
> > counterpart parsing these messages. AFAIU this changes the message format
> > by adding a QUOTA_NL_A_PAD field before each 64-bit field which needs an
> > alignment, am I guessing right? Thus when the userspace counterpart uses
> > genlmsg_parse() it should just silently ignore these attributes if I read
> > the documentation right. Did I understand this correctly?
> Yes, that's it.

OK, then feel free to add:

Acked-by: Jan Kara 

to the quota patch.

Honza

-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()

[Nicolas Dichtel]

Le 26/04/2016 13:08, Jan Kara a écrit :
> On Tue 26-04-16 10:06:13, Nicolas Dichtel wrote:
>> Signed-off-by: Nicolas Dichtel 
> 
> OK, so I somewhat miss a description of what will this do to the netlink
> message so that I can judge whether the change is fine for the userspace
> counterpart parsing these messages. AFAIU this changes the message format
> by adding a QUOTA_NL_A_PAD field before each 64-bit field which needs an
> alignment, am I guessing right? Thus when the userspace counterpart uses
> genlmsg_parse() it should just silently ignore these attributes if I read
> the documentation right. Did I understand this correctly?
Yes, that's it.


Regards,
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Drbd-dev] [PATCH net-next 0/8] netlink: align attributes when needed (patchset #3)

[Lars Ellenberg]

On Tue, Apr 26, 2016 at 01:54:27PM +0200, Lars Ellenberg wrote:
> On Tue, Apr 26, 2016 at 10:06:10AM +0200, Nicolas Dichtel wrote:
> > 
> > This is the continuation (series #3) of the work done to align netlink
> > attributes when these attributes contain some 64-bit fields.
> > 
> > It's the last patchset from what I've seen.
> > 
> > The last user of nla_put_u64() is block/drbd. This module does not use
> > standard netlink API (see all the stuff in include/linux/genl_magic_struct.h
> > and include/linux/genl_magic_func.h). I didn't modify it because it's seems
> > hard to do it whithout testing and fully understanding the context
> 
> Something like this should just work.

> + * @attrtype: attribute type
> + * @value: numeric value
> + */
> +static inline int nla_put_u64_64bit_unspec(struct sk_buff *skb, int attrtype,
> + u64 value)
> +{
> + return nla_put_64bit(skb, attrtype, sizeof(u64), , NLA_UNSPEC);

Ok, I confused attribute and policy type there for a sec.
Anyways, 0 works just fine,
all our nested attribute enums are != 0,
because nla_parse skips type 0.

Lars

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Radu P]

On Tue, Apr 26, 2016 at 1:03 PM, Johannes Berg
 wrote:
> On Tue, 2016-04-26 at 12:54 +0100, Radu P wrote:
>> Is there a way running
>>
>> ./iw dev wlanX link
>>
>> but to get the output for the 5 Ghz frequency?
>> now I am getting only this:
>>
>> freq: 2432
>> tx bitrate: 130.0 MBit/s MCS 14 short GI
>
> Sure: connect to a 5 GHz AP first :)
>
> johannes

What a journey. The router has both frequencies. Changed the BSSID and
now I am in the AC world.
Thank you all for your help!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ath10k: release pre_cal_file while unloading driver

[Valo, Kalle]

Rajkumar Manoharan  writes:

> Failing to release pre_cal_file caldata on deinit causes memory leak.
>
> Fixes: b131129d9657 ("ath10k: fix calibration init sequence of qca99x0")
> Signed-off-by: Rajkumar Manoharan 

Doesn't apply, please rebase.

Applying: ath10k: release pre_cal_file while unloading driver
fatal: sha1 information is lacking or useless 
(drivers/net/wireless/ath/ath10k/core.c).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 ath10k: release pre_cal_file while unloading driver

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Valo, Kalle]

Johannes Berg  writes:

> On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:
>
>> The thing is, it actually works just fine with the patch I posted
>> to fix mac80211, and at any rate, even if the mac80211 patch isn't
>> applied, the ath10k driver works just fine in HT mode.
>
> This patch has no implications on HT, and I wasn't planning on applying
> the mac80211 patch.

Yeah, makes sense. I'm planning to apply this soon.

> As I said, I have no objections to doing the (Broadcom) vendor specific
> IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
> the spec IEs when they're explicitly specified to be used only in the
> 5.2 GHz band.

But we really should have this, any volunteers? :) I think it shouldn't
be too hard to do so this would be a good project for someone looking
for a simple, but useful, task on wireless stack.

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Johannes Berg]

On Tue, 2016-04-26 at 12:54 +0100, Radu P wrote:
> Is there a way running
> 
> ./iw dev wlanX link
> 
> but to get the output for the 5 Ghz frequency?
> now I am getting only this:
> 
> freq: 2432
> tx bitrate: 130.0 MBit/s MCS 14 short GI

Sure: connect to a 5 GHz AP first :)

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 0/8] netlink: align attributes when needed (patchset #3)

[Lars Ellenberg]

On Tue, Apr 26, 2016 at 10:06:10AM +0200, Nicolas Dichtel wrote:
> 
> This is the continuation (series #3) of the work done to align netlink
> attributes when these attributes contain some 64-bit fields.
> 
> It's the last patchset from what I've seen.
> 
> The last user of nla_put_u64() is block/drbd. This module does not use
> standard netlink API (see all the stuff in include/linux/genl_magic_struct.h
> and include/linux/genl_magic_func.h). I didn't modify it because it's seems
> hard to do it whithout testing and fully understanding the context

Something like this should just work.

diff --git a/include/linux/genl_magic_struct.h 
b/include/linux/genl_magic_struct.h
index eecd19b..5715dac 100644
--- a/include/linux/genl_magic_struct.h
+++ b/include/linux/genl_magic_struct.h
@@ -80,7 +80,7 @@ extern void CONCAT_(GENL_MAGIC_FAMILY, 
_genl_unregister)(void);
nla_get_u32, nla_put_u32, true)
 #define __u64_field(attr_nr, attr_flag, name)  \
__field(attr_nr, attr_flag, name, NLA_U64, __u64, \
-   nla_get_u64, nla_put_u64, false)
+   nla_get_u64, nla_put_u64_64bit_unspec, false)
 #define __str_field(attr_nr, attr_flag, name, maxlen) \
__array(attr_nr, attr_flag, name, NLA_NUL_STRING, char, maxlen, \
nla_strlcpy, nla_put, false)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index e589cb3..38ba770 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -871,6 +871,18 @@ static inline int nla_put_u64_64bit(struct sk_buff *skb, 
int attrtype,
 }
 
 /**
+ * nla_put_u64_64bit_unspec - nla_put_u64_64bit() with padattr = 0
+ * @skb: socket buffer to add attribute to
+ * @attrtype: attribute type
+ * @value: numeric value
+ */
+static inline int nla_put_u64_64bit_unspec(struct sk_buff *skb, int attrtype,
+   u64 value)
+{
+   return nla_put_64bit(skb, attrtype, sizeof(u64), , NLA_UNSPEC);
+}
+
+/**
  * nla_put_be64 - Add a __be64 netlink attribute to a socket buffer and align 
it
  * @skb: socket buffer to add attribute to
  * @attrtype: attribute type

> (for
> example, why include/linux/drbd_genl.h is not part of uapi?).
> Any thoughts?

probably should be.

Thanks,

Lars

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] ath10k: update bss channel survey information

[Valo, Kalle]

Rajkumar Manoharan  writes:

> During hw scan, firmware sends two channel information events (pre-
> complete, complete) to host for each channel change. The snap shot of cycle
> counters (rx_clear and total) between these two events are given for
> survey dump. In order to get latest survey statistics of all channels, a
> scan request has to be issued. In general, an AP DUT is brought up, it
> won't leave BSS channel except few cases like overlapping bss or radar
> detection. So survey statistics of bss channel is always referring to
> older data that are collected before starting AP (either ACS/OBSS scan).
>
> To collect latest survey information from target, firmware provides WMI
> interface to read cycle counters from hardware. For each survey dump
> request, BSS channel cycle counters are read and cleared in hardware.
> This makes sure that behavior is in align with ath9k survey report.
> So survey dump always gives snap shot of cycle counters b/w two survey
> requests.
>
> Signed-off-by: Yanbo Li 
> Signed-off-by: Rajkumar Manoharan 

This patch adds new sparse warnings:

drivers/net/wireless/ath/ath10k/wmi.c:4824:33: warning: incorrect type in 
argument 2 (different base types)
drivers/net/wireless/ath/ath10k/wmi.c:4824:33:expected int [signed] freq
drivers/net/wireless/ath/ath10k/wmi.c:4824:33:got restricted __le32 
[usertype] freq
drivers/net/wireless/ath/ath10k/wmi.c:4833:27: warning: incorrect type in 
assignment (different base types)
drivers/net/wireless/ath/ath10k/wmi.c:4833:27:expected signed char [signed] 
[usertype] [explicitly-signed] noise
drivers/net/wireless/ath/ath10k/wmi.c:4833:27:got restricted __le32 
[usertype] noise_floor

-- 
Kalle Valo--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Radu P]

On Tue, Apr 26, 2016 at 12:40 PM, Kalle Valo  wrote:
> Radu P  writes:
>
>> With the latest iw from the git repo I get:
>>
>> VHT Capabilities (0x038071a0):
>> Max MPDU length: 3895
>> Supported Channel Width: neither 160 nor 80+80
>> short GI (80 MHz)
>> TX STBC
>> SU Beamformee
>> VHT RX MCS set:
>> 1 streams: MCS 0-9
>> 2 streams: MCS 0-9
>> 3 streams: not supported
>> 4 streams: not supported
>> 5 streams: not supported
>> 6 streams: not supported
>> 7 streams: not supported
>> 8 streams: not supported
>> VHT RX highest supported: 0 Mbps
>> VHT TX MCS set:
>> 1 streams: MCS 0-9
>> 2 streams: MCS 0-9
>> 3 streams: not supported
>> 4 streams: not supported
>> 5 streams: not supported
>> 6 streams: not supported
>> 7 streams: not supported
>> 8 streams: not supported
>> VHT TX highest supported: 0 Mbps
>>
>> Is it OK that it is reporting  "VHT TX highest supported: 0 Mbps" ?
>
> Yeah, zero just means that the highest support rate is not defined. I
> guess it's nicer if iw would print "Not defined" instead of "0 Mbps" but
> nobody hasn't implemented that yet.
>
> --
> Kalle Valo


Is there a way running

./iw dev wlanX link

but to get the output for the 5 Ghz frequency?
now I am getting only this:

freq: 2432
tx bitrate: 130.0 MBit/s MCS 14 short GI
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Kalle Valo]

Radu P  writes:

> With the latest iw from the git repo I get:
>
> VHT Capabilities (0x038071a0):
> Max MPDU length: 3895
> Supported Channel Width: neither 160 nor 80+80
> short GI (80 MHz)
> TX STBC
> SU Beamformee
> VHT RX MCS set:
> 1 streams: MCS 0-9
> 2 streams: MCS 0-9
> 3 streams: not supported
> 4 streams: not supported
> 5 streams: not supported
> 6 streams: not supported
> 7 streams: not supported
> 8 streams: not supported
> VHT RX highest supported: 0 Mbps
> VHT TX MCS set:
> 1 streams: MCS 0-9
> 2 streams: MCS 0-9
> 3 streams: not supported
> 4 streams: not supported
> 5 streams: not supported
> 6 streams: not supported
> 7 streams: not supported
> 8 streams: not supported
> VHT TX highest supported: 0 Mbps
>
> Is it OK that it is reporting  "VHT TX highest supported: 0 Mbps" ?

Yeah, zero just means that the highest support rate is not defined. I
guess it's nicer if iw would print "Not defined" instead of "0 Mbps" but
nobody hasn't implemented that yet.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Kalle Valo]

Krishna Chaitanya  writes:

> On Tue, Apr 26, 2016 at 4:20 PM, Kalle Valo  wrote:
>>
>> Radu P  writes:
>>
>> > iw list|grep -i VHT  <- still nothing
>>

[...]

> "iw phy " should give necessary info.

AFAICS "iw phy" and "iw list" are identical commands.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Radu P]

On Tue, Apr 26, 2016 at 12:04 PM, Krishna Chaitanya
 wrote:
> On Tue, Apr 26, 2016 at 4:20 PM, Kalle Valo  wrote:
>>
>> Radu P  writes:
>>
>> > iw list|grep -i VHT  <- still nothing
>>
>> Maybe your iw is too old? I didn't see anything either (using stock iw
>> from Ubuntu 14.04) but then I upgraded to the latest one from git and
>> now I see:
>>
>>VHT Capabilities (0x338001b2):
>> Max MPDU length: 11454
>> Supported Channel Width: neither 160 nor 80+80
>> RX LDPC
>> short GI (80 MHz)
>> TX STBC
>> RX antenna pattern consistency
>> TX antenna pattern consistency
>> VHT RX MCS set:
>> 1 streams: MCS 0-9
>> 2 streams: MCS 0-9
>> 3 streams: MCS 0-9
>> 4 streams: not supported
>> 5 streams: not supported
>> 6 streams: not supported
>> 7 streams: not supported
>> 8 streams: not supported
>> VHT RX highest supported: 0 Mbps
>> VHT TX MCS set:
>> 1 streams: MCS 0-9
>> 2 streams: MCS 0-9
>> 3 streams: MCS 0-9
>> 4 streams: not supported
>> 5 streams: not supported
>> 6 streams: not supported
>> 7 streams: not supported
>> 8 streams: not supported
>> VHT TX highest supported: 0 Mbps
>>
>> And please don't top post.
>>
>> --
> "iw phy " should give necessary info.



With the latest iw from the git repo I get:

VHT Capabilities (0x038071a0):
Max MPDU length: 3895
Supported Channel Width: neither 160 nor 80+80
short GI (80 MHz)
TX STBC
SU Beamformee
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: not supported
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps

Is it OK that it is reporting  "VHT TX highest supported: 0 Mbps" ?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()

[Jan Kara]

On Tue 26-04-16 10:06:13, Nicolas Dichtel wrote:
> Signed-off-by: Nicolas Dichtel 

OK, so I somewhat miss a description of what will this do to the netlink
message so that I can judge whether the change is fine for the userspace
counterpart parsing these messages. AFAIU this changes the message format
by adding a QUOTA_NL_A_PAD field before each 64-bit field which needs an
alignment, am I guessing right? Thus when the userspace counterpart uses
genlmsg_parse() it should just silently ignore these attributes if I read
the documentation right. Did I understand this correctly?

Honza

> ---
>  fs/quota/netlink.c | 12 +++-
>  include/uapi/linux/quota.h |  1 +
>  2 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/quota/netlink.c b/fs/quota/netlink.c
> index d07a2f91d858..8b252673d454 100644
> --- a/fs/quota/netlink.c
> +++ b/fs/quota/netlink.c
> @@ -47,7 +47,7 @@ void quota_send_warning(struct kqid qid, dev_t dev,
>   void *msg_head;
>   int ret;
>   int msg_size = 4 * nla_total_size(sizeof(u32)) +
> -2 * nla_total_size(sizeof(u64));
> +2 * nla_total_size_64bit(sizeof(u64));
>  
>   /* We have to allocate using GFP_NOFS as we are called from a
>* filesystem performing write and thus further recursion into
> @@ -68,8 +68,9 @@ void quota_send_warning(struct kqid qid, dev_t dev,
>   ret = nla_put_u32(skb, QUOTA_NL_A_QTYPE, qid.type);
>   if (ret)
>   goto attr_err_out;
> - ret = nla_put_u64(skb, QUOTA_NL_A_EXCESS_ID,
> -   from_kqid_munged(_user_ns, qid));
> + ret = nla_put_u64_64bit(skb, QUOTA_NL_A_EXCESS_ID,
> + from_kqid_munged(_user_ns, qid),
> + QUOTA_NL_A_PAD);
>   if (ret)
>   goto attr_err_out;
>   ret = nla_put_u32(skb, QUOTA_NL_A_WARNING, warntype);
> @@ -81,8 +82,9 @@ void quota_send_warning(struct kqid qid, dev_t dev,
>   ret = nla_put_u32(skb, QUOTA_NL_A_DEV_MINOR, MINOR(dev));
>   if (ret)
>   goto attr_err_out;
> - ret = nla_put_u64(skb, QUOTA_NL_A_CAUSED_ID,
> -   from_kuid_munged(_user_ns, current_uid()));
> + ret = nla_put_u64_64bit(skb, QUOTA_NL_A_CAUSED_ID,
> + from_kuid_munged(_user_ns, current_uid()),
> + QUOTA_NL_A_PAD);
>   if (ret)
>   goto attr_err_out;
>   genlmsg_end(skb, msg_head);
> diff --git a/include/uapi/linux/quota.h b/include/uapi/linux/quota.h
> index 38baddb807f5..4d2489ef6f10 100644
> --- a/include/uapi/linux/quota.h
> +++ b/include/uapi/linux/quota.h
> @@ -191,6 +191,7 @@ enum {
>   QUOTA_NL_A_DEV_MAJOR,
>   QUOTA_NL_A_DEV_MINOR,
>   QUOTA_NL_A_CAUSED_ID,
> + QUOTA_NL_A_PAD,
>   __QUOTA_NL_A_MAX,
>  };
>  #define QUOTA_NL_A_MAX (__QUOTA_NL_A_MAX - 1)
> -- 
> 2.8.1
> 
> 
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Krishna Chaitanya]

On Tue, Apr 26, 2016 at 4:20 PM, Kalle Valo  wrote:
>
> Radu P  writes:
>
> > iw list|grep -i VHT  <- still nothing
>
> Maybe your iw is too old? I didn't see anything either (using stock iw
> from Ubuntu 14.04) but then I upgraded to the latest one from git and
> now I see:
>
>VHT Capabilities (0x338001b2):
> Max MPDU length: 11454
> Supported Channel Width: neither 160 nor 80+80
> RX LDPC
> short GI (80 MHz)
> TX STBC
> RX antenna pattern consistency
> TX antenna pattern consistency
> VHT RX MCS set:
> 1 streams: MCS 0-9
> 2 streams: MCS 0-9
> 3 streams: MCS 0-9
> 4 streams: not supported
> 5 streams: not supported
> 6 streams: not supported
> 7 streams: not supported
> 8 streams: not supported
> VHT RX highest supported: 0 Mbps
> VHT TX MCS set:
> 1 streams: MCS 0-9
> 2 streams: MCS 0-9
> 3 streams: MCS 0-9
> 4 streams: not supported
> 5 streams: not supported
> 6 streams: not supported
> 7 streams: not supported
> 8 streams: not supported
> VHT TX highest supported: 0 Mbps
>
> And please don't top post.
>
> --
"iw phy " should give necessary info.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Kalle Valo]

Radu P  writes:

> iw list|grep -i VHT  <- still nothing

Maybe your iw is too old? I didn't see anything either (using stock iw
from Ubuntu 14.04) but then I upgraded to the latest one from git and
now I see:

   VHT Capabilities (0x338001b2):
Max MPDU length: 11454
Supported Channel Width: neither 160 nor 80+80
RX LDPC
short GI (80 MHz)
TX STBC
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 0 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: not supported
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 0 Mbps

And please don't top post.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Radu P]

iw list|grep -i VHT  <- still nothing

iw dev wlanX link
Connected to *.* (on wlan1)
SSID: *
freq: 2432
RX: 45056569 bytes (38259 packets)
TX: 5239816 bytes (27324 packets)
signal: -54 dBm
tx bitrate: 144.4 MBit/s MCS 15 short GIc0:3e:0f:d6:54:b9

bss flags: short-preamble short-slot-time
dtim period: 1
beacon int: 100

On Tue, Apr 26, 2016 at 11:00 AM, Johannes Berg
 wrote:
> On Tue, 2016-04-26 at 02:56 -0600, Reinoud Koornstra wrote:
>> I'm also using the 7620 AC.
>> When I type:
>>
>> sudo iw dev wlp0s4 scan I see:
>>
>
> "scan" is completely irrelevant for what actually ends up getting used.
> "link" is relevant, but if you want to see the hardware capabilities
> (like what iwconfig is displaying - that field has no relation to the
> connection at all) then you need "iw list" or so.
>
> johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Johannes Berg]

On Tue, 2016-04-26 at 02:56 -0600, Reinoud Koornstra wrote:
> I'm also using the 7620 AC.
> When I type:
> 
> sudo iw dev wlp0s4 scan I see:
> 

"scan" is completely irrelevant for what actually ends up getting used.
"link" is relevant, but if you want to see the hardware capabilities
(like what iwconfig is displaying - that field has no relation to the
connection at all) then you need "iw list" or so.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Radu P]

I get no output when running:

iw dev wlan1 scan|grep VHT

Switched to firmware 16 and same result.

On Tue, Apr 26, 2016 at 10:01 AM, Kalle Valo  wrote:
> Radu P  writes:
>
>> These is the relevant data:
>>
>> firmware-version: 17.265642.0
>>
>> [  292.689871] iwlwifi :04:00.0: loaded firmware version
>> 17.265642.0 op_mode iwlmvm
>> [  292.702902] iwlwifi :04:00.0: Detected Intel(R) Dual Band
>> Wireless AC 7260, REV=0x144
>>
>> wlan1 IEEE 802.11abgn <- not AC
>>
>> Kernel version: 4.4.0-21-generic #37~14.04.1-Ubuntu
>>
>> AC mode is working with Windows 10.
>
> Don't use iwconfig, it's ancient and deprecated. Use iw instead.
>
> --
> Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2] rt2800lib: enable MFP if hw crypt is disabled

[Kalle Valo]

Kalle Valo  writes:

>> If rt2800usb is loaded with nohwcrypt=1, mac80211 takes
>> care of the crypto with software encryption/decryption
>> and thus, MFP can be used.
>> 
>> Tested for secured mesh using ath9k_htc and ath9k.
>> 
>> Signed-off-by: Chun-Yeow Yeoh 
>> 
>> v2: set MFP correctly (Stanislaw Gruszka)
>> Acked-by: Stanislaw Gruszka 
>
> Thanks, applied to wireless-drivers-next.git.

Afterwards I edited out the change log from the commit log. Add that
after the "---" line so that git won't include it.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2] rtlwifi: rtl8821ae: Make sure loop counter is signed on allarchitectures

[Kalle Valo]

Kalle Valo  writes:

>> The for-loop condition does not work correctly on architectures where
>> "char" is unsigned. Fix it by using an "int", which may also result in
>> more efficient code.
>> 
>> v2: Remove unneeded initialization.
>> 
>> Signed-off-by: David Müller 
>> Acked-by: Larry Finger 
>
> Thanks, applied to wireless-drivers-next.git.

But afterwards I removed the change log. That doesn't belong to the
commit log, please add that after "---" line separator.

Also in patchwork your name has (ELSOFT AG), I edited that out.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: iwlwifi: fix fw version reading for DVM devices

[Kalle Valo]

> From: Luca Coelho 
> 
> In commit 97f95c93c8ed ("iwlwifi: remove support for fw older than
> -16.ucode") we accidentally changed the fw version reading code for
> DVM devices.  The code intended to remove the old fw version API,
> because all MVM firmwares version 16 and above that we support don't
> use it anymore.  But DVM devices still use the old FW API.
> 
> Fix that by bringing the code back in.
> 
> Reported-by: Pat Erley 
> Tested-by: Kalle Valo 
> Fixes: 97f95c93c8ed ("iwlwifi: remove support for fw older than-16.ucode")
> Signed-off-by: Luca Coelho 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2] rt2800lib: enable MFP if hw crypt is disabled

[Kalle Valo]

> If rt2800usb is loaded with nohwcrypt=1, mac80211 takes
> care of the crypto with software encryption/decryption
> and thus, MFP can be used.
> 
> Tested for secured mesh using ath9k_htc and ath9k.
> 
> Signed-off-by: Chun-Yeow Yeoh 
> 
> v2: set MFP correctly (Stanislaw Gruszka)
> Acked-by: Stanislaw Gruszka 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: brcmfmac: testing the wrong variable in brcmf_rx_hdrpull()

[Kalle Valo]

> Smatch complains about this code:
> 
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c:335 
> brcmf_rx_hdrpull()
> error: we previously assumed '*ifp' could be null (see line 333)
> 
> The problem is that we recently changed these from "ifp" to "*ifp" but
> there was one that we didn't update.
> 
> -   if (ret || !ifp || !ifp->ndev) {
> +   if (ret || !(*ifp) || !(*ifp)->ndev) {
> if (ret != -ENODATA && ifp)
>^^^
> -   ifp->stats.rx_errors++;
> +   (*ifp)->stats.rx_errors++;
> 
> I have updated it to *ifp as well.  We always call this function is a
> non-NULL "ifp" pointer, btw.
> 
> Fixes: c462ebcdfe42 ('brcmfmac: create common function for handling 
> brcmf_proto_hdrpull()')
> Signed-off-by: Dan Carpenter 
> Acked-by: Arend van Spriel 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [1/2] mwifiex: missing error code on allocation failure

[Kalle Valo]

> We accidentally return success instead of -ENOMEM.
> 
> Signed-off-by: Dan Carpenter 

Thanks, 2 patches applied to wireless-drivers-next.git:

e0bdef0f75f0 mwifiex: missing error code on allocation failure
394f0ed53108 mwifiex: fix loop timeout in mwifiex_prog_fw_w_helper()

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [01/16] rtl8xxxu: Rename rtl8723bu_update_rate_mask() tortl8xxxu_gen2_update_rate_mask()

[Kalle Valo]

> From: Jes Sorensen 
> 
> Update the name of rtl8723bu_update_rate_mask() to make it reflect
> it's applicable for all/most gen2 N parts.
> 
> Signed-off-by: Jes Sorensen 

Thanks, 16 patches applied to wireless-drivers-next.git:

a8c8dfa59319 rtl8xxxu: Rename rtl8723bu_update_rate_mask() to 
rtl8xxxu_gen2_update_rate_mask()
32353a784f43 rtl8xxxu: Rename rtl8723bu_report_connect() to 
rtl8xxxu_gen2_report_connect()
beb5531619c6 rtl8xxxu: Rename rtl8723au_report_connect() to 
rtl8xxxu_gen1_report_connect()
3a56bf6aa13c rtl8xxxu: Rename rtl8723bu_config_channel() to 
rtl8xxxu_gen2_config_channel()
6a07b7915afe rtl8xxxu: Rename rtl8723b_disable_rf() to 
rtl8xxxu_gen2_disable_rf()
7eb1400c2479 rtl8xxxu: Rename rtl8723a_disable_rf() to 
rtl8xxxu_gen1_disable_rf()
e09718c2fddf rtl8xxxu: Rename rtl8723au_config_channel() to 
rtl8xxxu_gen1_config_channel()
c6e39da02e17 rtl8xxxu: Rename rtl8723au_update_rate_mask() to 
rtl8xxxu_update_rate_mask()
28466e921402 rtl8xxxu: Rename rtl8723au_phy_iq_calibrate() to 
rtl8xxxu_gen1_phy_iq_calibrate()
de7c189c342d rtl8xxxu: Rename rtl8723au_init_phy_bb() to 
rtl8xxxu_gen1_init_phy_bb()
42a3bc7a2a85 rtl8xxxu: Rename rtl8723a_set_tx_power() to 
rtl8xxxu_gen1_set_tx_power()
8396a41cf747 rtl8xxxu: Rename rtl8723a_enable_rf() to rtl8xxxu_gen1_enable_rf()
8db71451e5c4 rtl8xxxu: Rename rtl8723a_mac_init_table to 
rtl8xxxu_gen1_mac_init_table
5ac74145487d rtl8xxxu: Rename rtl8723b_channel_to_group()
85f466350abf rtl8xxxu: Rename rtl8723bu_simularity_compare()
04a74a9f8af0 rtl8xxxu: Rename rtl8723au_iqk_phy_iq_bb_reg

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex: stop background scan when net device closed

[Kalle Valo]

> From: Xinming Hu 
> 
> Transmit data path should not touch background scan. We will stop
> background scan when net device is closed.
> 
> Signed-off-by: Xinming Hu 
> Signed-off-by: Amitkumar Karwar 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v7,1/2] dt: bindings: add MARVELL's sd8xxx wireless device

[Kalle Valo]

> From: Xinming Hu 
> 
> Add device tree binding documentation for MARVELL's sd8xxx
> (sd8897 and sd8997) wlan chip.
> 
> Signed-off-by: Xinming Hu 
> Signed-off-by: Amitkumar Karwar 
> Acked-by: Rob Herring 

Thanks, 2 patches applied to wireless-drivers-next.git:

84039920bdff dt: bindings: add MARVELL's sd8xxx wireless device
ce4f6f0c353b mwifiex: add platform specific wakeup interrupt support

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: brcmf: Fix null pointer exception in bcdc_hdrpull

[Kalle Valo]

> From: Per Forlin 
> 
> In fwsignal.c: brcmf_fws_commit_skb()
> ...
> if (rc < 0) {
>   entry->transit_count--;
> if (entry->suppressed)
>   entry->suppr_transit_count--;
>   (void)brcmf_proto_hdrpull(fws->drvr, false, skb, NULL);
>  ^^^
> goto rollback;
> }
> ...
> 
> The call to hdrpull will trigger a null pointer exception
> unless a null check is made in the method implementation.
> 
> Signed-off-by: Per Forlin 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [V11] brcmfmac: add support for nl80211 BSS_SELECT feature

[Kalle Valo]

> Announce support for nl80211 feature BSS_SELECT and process
> BSS selection behaviour provided in .connect() callback.
> 
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Franky (Zhenhui) Lin 
> Reviewed-by: Pieter-Paul Giesberts 
> Reviewed-by: Lei Zhang 
> Signed-off-by: Arend van Spriel 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2] rtlwifi: rtl8821ae: Make sure loop counter is signed on allarchitectures

[Kalle Valo]

> The for-loop condition does not work correctly on architectures where
> "char" is unsigned. Fix it by using an "int", which may also result in
> more efficient code.
> 
> v2: Remove unneeded initialization.
> 
> Signed-off-by: David Müller 
> Acked-by: Larry Finger 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v3] prism54: isl_38xx: Replace 'struct timeval'

[Kalle Valo]

> 'struct timeval' uses a 32-bit seconds field which will overflow in
> year 2038 and beyond. This patch is part of a larger effort to remove
> all instances of 'struct timeval' from the kernel and replace them
> with 64-bit timekeeping variables.
> The patch also fixes the debug printf specifier to avoid the
> seconds value being truncated.
> The patch was build-tested / debugged by removing the
> "if VERBOSE > SHOW_ERROR_MESSAGES" guards.
> 
> Signed-off-by: Tina Ruchandani 
> Suggested-by: Arnd Bergmann 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [MOREWORK, 14/19] rtl818x_pci: Fix a memory leak in rtl8180_init_rx_ring

[Kalle Valo]

> From: Jia-Ju Bai 
> 
> When dev_alloc_skb or pci_dma_mapping_error in rtl8180_init_rx_ring fails,
> the memory allocated by pci_zalloc_consistent is not freed.
> 
> This patch fixes the bug by adding pci_free_consistent
> in error handling code.
> 
> Signed-off-by: Jia-Ju Bai 
> Signed-off-by: Julian Calaby 

Thanks, applied to wireless-drivers-next.git.

Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] ti: Convert wl1271_ logging macros to dev_ or pr_

[Kalle Valo]

Joe Perches  writes:

> Use the more common logging mechanism passing wl->dev where
> appropriate.  Remove the macros.  Add argument struct wl1271 *wl to
> some functions to make these logging mechanisms work.
>
> Miscellanea:
>
> o Coalesce formats, add required trailing \n to formats
>   Some formats already had previously incorrect \n uses
> o Realign arguments
> o Correct a couple typos and grammar defects
> o Split a multiple line error message to multiple calls of dev_err
> o Add #define pr_fmt when pr_ is used
> o Remove unnecessary/duplicate pr_fmt use from wl1271_debug macro
>
> Signed-off-by: Joe Perches 

Doesn't apply anymore:

Applying: ti: Convert wl1271_ logging macros to dev_ or pr_
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/ti/wlcore/wlcore_i.h
Auto-merging drivers/net/wireless/ti/wlcore/tx.c
Auto-merging drivers/net/wireless/ti/wlcore/scan.c
Auto-merging drivers/net/wireless/ti/wlcore/rx.c
Auto-merging drivers/net/wireless/ti/wlcore/ps.c
Auto-merging drivers/net/wireless/ti/wlcore/main.c
Auto-merging drivers/net/wireless/ti/wlcore/cmd.c
CONFLICT (content): Merge conflict in drivers/net/wireless/ti/wlcore/cmd.c
Auto-merging drivers/net/wireless/ti/wl18xx/tx.c
Auto-merging drivers/net/wireless/ti/wl18xx/scan.c
Auto-merging drivers/net/wireless/ti/wl18xx/main.c
Auto-merging drivers/net/wireless/ti/wl18xx/event.c
Auto-merging drivers/net/wireless/ti/wl18xx/debugfs.c
Auto-merging drivers/net/wireless/ti/wl18xx/cmd.c
Auto-merging drivers/net/wireless/ti/wl12xx/scan.c
Auto-merging drivers/net/wireless/ti/wl12xx/main.c
Failed to merge in the changes.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Kalle Valo]

Radu P  writes:

> These is the relevant data:
>
> firmware-version: 17.265642.0
>
> [  292.689871] iwlwifi :04:00.0: loaded firmware version
> 17.265642.0 op_mode iwlmvm
> [  292.702902] iwlwifi :04:00.0: Detected Intel(R) Dual Band
> Wireless AC 7260, REV=0x144
>
> wlan1 IEEE 802.11abgn <- not AC
>
> Kernel version: 4.4.0-21-generic #37~14.04.1-Ubuntu
>
> AC mode is working with Windows 10.

Don't use iwconfig, it's ancient and deprecated. Use iw instead.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Reinoud Koornstra]

Btw, iwconfig is deprecated, you should use iw instead.
Another way of seeing it:

reinoud@router-dev:/var/log$ sudo iw dev wlp4s0 link
Connected to 00:30:44:1d:cf:2b (on wlp4s0)
   SSID: Mipam5g
   freq: 5240
   RX: 1134508422 bytes (1235653 packets)
   TX: 120716536 bytes (668942 packets)
   signal: -60 dBm
   tx bitrate: 400.0 MBit/s VHT-MCS 9 40MHz short GI VHT-NSS 2

   bss flags:  short-slot-time
   dtim period:1
   beacon int: 100

again, VHT, hence 11ac. :)

On Tue, Apr 26, 2016 at 1:20 AM, Radu P  wrote:
> Hello,
>
> These is the relevant data:
>
> firmware-version: 17.265642.0
>
> [  292.689871] iwlwifi :04:00.0: loaded firmware version
> 17.265642.0 op_mode iwlmvm
> [  292.702902] iwlwifi :04:00.0: Detected Intel(R) Dual Band
> Wireless AC 7260, REV=0x144
>
> wlan1 IEEE 802.11abgn <- not AC
>
> Kernel version: 4.4.0-21-generic #37~14.04.1-Ubuntu
>
> AC mode is working with Windows 10.
>
> Any help is appreciated!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Intel 7260 AC only using 802.11n not AC

[Reinoud Koornstra]

I'm also using the 7620 AC.
When I type:

sudo iw dev wlp0s4 scan I see:

reinoud@router-dev:~/openwrt$ sudo iw dev wlp4s0 scan
BSS 00:30:44:1d:cf:2b(on wlp4s0) -- associated
[SNIP]
VHT capabilities:
   VHT Capabilities (0x31c12820):
   Max MPDU length: 3895
   Supported Channel Width: neither 160 nor 80+80
   short GI (80 MHz)
   SU Beamformer
   +HTC-VHT
   RX antenna pattern consistency
   TX antenna pattern consistency
   VHT RX MCS set:
   1 streams: MCS 0-9
   2 streams: MCS 0-9
   3 streams: not supported
   4 streams: not supported
   5 streams: not supported
   6 streams: not supported
   7 streams: not supported
   8 streams: not supported
   VHT RX highest supported: 780 Mbps
   VHT TX MCS set:
   1 streams: MCS 0-9
   2 streams: MCS 0-9
   3 streams: not supported
   4 streams: not supported
   5 streams: not supported
   6 streams: not supported
   7 streams: not supported
   8 streams: not supported
   VHT TX highest supported: 780 Mbps
   VHT operation:
* channel width: 0 (20 or 40 MHz)
* center freq segment 1: 0
* center freq segment 2: 0
* VHT basic MCS set: 0xfffa
   WPS: * Version: 1.0
* Wi-Fi Protected Setup State: 2 (Configured)
* Response Type: 3 (AP)
* UUID: bc329e00-1dd8-11b2-8601-0030441dcf2b
* Manufacturer: Cradlepoint Technology
* Model: Cradlepoint Access Point
* Model Number: CPDEV
* Serial Number: 12345678
* Primary Device Type: 6-0050f204-1
* Device name: CradlepointAP
* Config methods: Label, PBC
* RF Bands: 0x2

Hence, my 7620 does support 11c.
 [9.704827] iwlwifi :04:00.0: loaded firmware version
16.242414.0 op_mode iwlmvm
 [9.840382] iwlwifi :04:00.0: Detected Intel(R) Dual Band
Wireless AC 7260, REV=0x144
 [9.840428] iwlwifi :04:00.0: L1 Disabled - LTR Enabled
 [9.840657] iwlwifi :04:00.0: L1 Disabled - LTR Enabled

On Tue, Apr 26, 2016 at 1:20 AM, Radu P  wrote:
> Hello,
>
> These is the relevant data:
>
> firmware-version: 17.265642.0
>
> [  292.689871] iwlwifi :04:00.0: loaded firmware version
> 17.265642.0 op_mode iwlmvm
> [  292.702902] iwlwifi :04:00.0: Detected Intel(R) Dual Band
> Wireless AC 7260, REV=0x144
>
> wlan1 IEEE 802.11abgn <- not AC
>
> Kernel version: 4.4.0-21-generic #37~14.04.1-Ubuntu
>
> AC mode is working with Windows 10.
>
> Any help is appreciated!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] mt76: add driver code for MT76x2e

[Kalle Valo]

Felix Fietkau  writes:

> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>
> Signed-off-by: Felix Fietkau 

A little more overview would be nice, for example what works and what
doesn't?

What about the firmware images? Will they be available from
linux-firmware.git?

Otherwise looks really good.

> +MODULE_LICENSE("GPL");

"GPL v2"?

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ath10k: release pre_cal_file while unloading driver

[Rajkumar Manoharan]

Failing to release pre_cal_file caldata on deinit causes memory leak.

Fixes: b131129d9657 ("ath10k: fix calibration init sequence of qca99x0")
Signed-off-by: Rajkumar Manoharan 
---
 drivers/net/wireless/ath/ath10k/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 5f846bd4054c..6e37184abab6 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -712,6 +712,9 @@ static void ath10k_core_free_firmware_files(struct ath10k 
*ar)
if (!IS_ERR(ar->cal_file))
release_firmware(ar->cal_file);
 
+   if (!IS_ERR(ar->pre_cal_file))
+   release_firmware(ar->pre_cal_file);
+
ath10k_swap_code_seg_release(ar);
 
ar->otp = NULL;
@@ -723,6 +726,7 @@ static void ath10k_core_free_firmware_files(struct ath10k 
*ar)
ar->firmware_len = 0;
 
ar->cal_file = NULL;
+   ar->pre_cal_file = NULL;
 }
 
 static int ath10k_fetch_cal_file(struct ath10k *ar)
-- 
2.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] mt76: add common code shared between multiple chipsets

[Kalle Valo]

Felix Fietkau  writes:

> This will be used by drivers for MT76x2e, MT7603e and MT7628
>
> Signed-off-by: Felix Fietkau 

[...]

> +static int
> +mt76_get_of_eeprom(struct mt76_dev *dev, int len)
> +{
> +#ifdef CONFIG_OF
> + struct device_node *np = dev->dev->of_node;
> + struct mtd_info *mtd;
> + const __be32 *list;
> + const char *part;
> + phandle phandle;
> + int offset = 0;
> + int size;
> + size_t retlen;
> + int ret;
> +
> + if (!np)
> + return -ENOENT;
> +
> + list = of_get_property(np, "mediatek,mtd-eeprom", );
> + if (!list)
> + return -ENOENT;
> +
> + phandle = be32_to_cpup(list++);
> + if (!phandle)
> + return -ENOENT;
> +
> + np = of_find_node_by_phandle(phandle);
> + if (!np)
> + return -EINVAL;
> +
> + part = of_get_property(np, "label", NULL);
> + if (!part)
> + part = np->name;
> +
> + mtd = get_mtd_device_nm(part);
> + if (IS_ERR(mtd))
> + return PTR_ERR(mtd);
> +
> + if (size <= sizeof(*list))
> + return -EINVAL;
> +
> + offset = be32_to_cpup(list);
> + ret = mtd_read(mtd, offset, len, , dev->eeprom.data);
> + put_mtd_device(mtd);
> + if (ret)
> + return ret;
> +
> + if (retlen < len)
> + return -EINVAL;
> +
> + return 0;
> +#else
> + return -ENOENT;
> +#endif
> +}
> +
> +void
> +mt76_eeprom_override(struct mt76_dev *dev)
> +{
> +#ifdef CONFIG_OF
> + struct device_node *np = dev->dev->of_node;
> + const __be32 *val;
> + const u8 *mac;
> + int size;
> +
> + if (!np)
> + return;
> +
> + val = of_get_property(np, "mediatek,2ghz", );
> + if (val)
> + dev->cap.has_2ghz = be32_to_cpup(val);
> +
> + val = of_get_property(np, "mediatek,5ghz", );
> + if (val)
> + dev->cap.has_5ghz = be32_to_cpup(val);
> +
> + mac = of_get_mac_address(np);
> + if (mac)
> + memcpy(dev->macaddr, mac, ETH_ALEN);
> +#endif

All device tree properties need a binding document in
Documentation/devicetree/bindings/ which will be reviewed by the device
tree maintainers.

> +MODULE_LICENSE("GPL");

"GPL v2"?

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] mt76: add common code shared between multiple chipsets

[Kalle Valo]

Kalle Valo  writes:

> Felix Fietkau  writes:
>
>> This will be used by drivers for MT76x2e, MT7603e and MT7628
>>
>> Signed-off-by: Felix Fietkau 
>
> I applied these to the pending branch in wireless-drivers-next so that
> kbuild can do it's magic.

It found one issue:

>> drivers/net/wireless/mediatek/mt76/built-in.o:(__tracepoints+0x1c): multiple 
>> definition of `__tracepoint_reg_read'
   drivers/net/wireless/mediatek/mt7601u/built-in.o:(__tracepoints+0x24c): 
first defined here
   drivers/net/wireless/mediatek/mt76/built-in.o: In function 
`mt76_insert_hdr_pad':
>> (.text+0x383): multiple definition of `mt76_insert_hdr_pad'
   drivers/net/wireless/mediatek/mt7601u/built-in.o:(.text+0x8e2d): first 
defined here
>> drivers/net/wireless/mediatek/mt76/built-in.o:(__tracepoints+0x0): multiple 
>> definition of `__tracepoint_reg_write'
   drivers/net/wireless/mediatek/mt7601u/built-in.o:(__tracepoints+0x230): 
first defined here
   drivers/net/wireless/mediatek/mt76/built-in.o: In function 
`mt76_remove_hdr_pad':
>> (.text+0x350): multiple definition of `mt76_remove_hdr_pad'
   drivers/net/wireless/mediatek/mt7601u/built-in.o:(.text+0x8dfa): first 
defined here

More info in the email kbuild sent.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] nl80211: use nla_put_u64_64bit() for the remaining u64 attributes

[Nicolas Dichtel]

Le 26/04/2016 09:54, Johannes Berg a écrit :
> From: Johannes Berg 
> 
> Nicolas converted most users, but didn't realize some were generated
> by macros. Convert those over as well.
> 
> Signed-off-by: Johannes Berg 
Acked-by: Nicolas Dichtel 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 2/8] drivers/wireless: use nla_put_u64_64bit()

[Nicolas Dichtel]

Signed-off-by: Nicolas Dichtel 
---
 drivers/net/wireless/mac80211_hwsim.c | 2 +-
 drivers/net/wireless/mac80211_hwsim.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mac80211_hwsim.c 
b/drivers/net/wireless/mac80211_hwsim.c
index c757f14c4c00..9ed0ed1bf514 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -1030,7 +1030,7 @@ static void mac80211_hwsim_tx_frame_nl(struct 
ieee80211_hw *hw,
data->pending_cookie++;
cookie = data->pending_cookie;
info->rate_driver_data[0] = (void *)cookie;
-   if (nla_put_u64(skb, HWSIM_ATTR_COOKIE, cookie))
+   if (nla_put_u64_64bit(skb, HWSIM_ATTR_COOKIE, cookie, HWSIM_ATTR_PAD))
goto nla_put_failure;
 
genlmsg_end(skb, msg_head);
diff --git a/drivers/net/wireless/mac80211_hwsim.h 
b/drivers/net/wireless/mac80211_hwsim.h
index 66e1c73bd507..39f22467ca2a 100644
--- a/drivers/net/wireless/mac80211_hwsim.h
+++ b/drivers/net/wireless/mac80211_hwsim.h
@@ -148,6 +148,7 @@ enum {
HWSIM_ATTR_RADIO_NAME,
HWSIM_ATTR_NO_VIF,
HWSIM_ATTR_FREQ,
+   HWSIM_ATTR_PAD,
__HWSIM_ATTR_MAX,
 };
 #define HWSIM_ATTR_MAX (__HWSIM_ATTR_MAX - 1)
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 4/8] sock_diag: align nlattr properly when needed

[Nicolas Dichtel]

I also fix the value of INET_DIAG_MAX. It's wrong since commit 8f840e47f190
which is only in net-next right now, thus I didn't make a separate patch.

Fixes: 8f840e47f190 ("sctp: add the sctp_diag.c file")
Signed-off-by: Nicolas Dichtel 
---
 include/uapi/linux/inet_diag.h | 4 +++-
 net/core/sock_diag.c   | 2 +-
 net/ipv4/inet_diag.c   | 9 ++---
 net/sctp/sctp_diag.c   | 5 +++--
 4 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/include/uapi/linux/inet_diag.h b/include/uapi/linux/inet_diag.h
index f5f3629dd553..a16643705669 100644
--- a/include/uapi/linux/inet_diag.h
+++ b/include/uapi/linux/inet_diag.h
@@ -115,9 +115,11 @@ enum {
INET_DIAG_SKV6ONLY,
INET_DIAG_LOCALS,
INET_DIAG_PEERS,
+   INET_DIAG_PAD,
+   __INET_DIAG_MAX,
 };
 
-#define INET_DIAG_MAX INET_DIAG_SKV6ONLY
+#define INET_DIAG_MAX (__INET_DIAG_MAX - 1)
 
 /* INET_DIAG_MEM */
 
diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
index ca9e35bbe13c..6b10573cc9fa 100644
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -120,7 +120,7 @@ static size_t sock_diag_nlmsg_size(void)
 {
return NLMSG_ALIGN(sizeof(struct inet_diag_msg)
   + nla_total_size(sizeof(u8)) /* INET_DIAG_PROTOCOL */
-  + nla_total_size(sizeof(struct tcp_info))); /* INET_DIAG_INFO */
+  + nla_total_size_64bit(sizeof(struct tcp_info))); /* 
INET_DIAG_INFO */
 }
 
 static void sock_diag_broadcast_destroy_work(struct work_struct *work)
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index ad7956fa659a..25af1243649b 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -220,8 +220,9 @@ int inet_sk_diag_fill(struct sock *sk, struct 
inet_connection_sock *icsk,
}
 
if ((ext & (1 << (INET_DIAG_INFO - 1))) && handler->idiag_info_size) {
-   attr = nla_reserve(skb, INET_DIAG_INFO,
-  handler->idiag_info_size);
+   attr = nla_reserve_64bit(skb, INET_DIAG_INFO,
+handler->idiag_info_size,
+INET_DIAG_PAD);
if (!attr)
goto errout;
 
@@ -1078,7 +1079,9 @@ int inet_diag_handler_get_info(struct sk_buff *skb, 
struct sock *sk)
}
 
attr = handler->idiag_info_size
-   ? nla_reserve(skb, INET_DIAG_INFO, handler->idiag_info_size)
+   ? nla_reserve_64bit(skb, INET_DIAG_INFO,
+   handler->idiag_info_size,
+   INET_DIAG_PAD)
: NULL;
if (attr)
info = nla_data(attr);
diff --git a/net/sctp/sctp_diag.c b/net/sctp/sctp_diag.c
index bb2d8d9608e9..84829fff3bc9 100644
--- a/net/sctp/sctp_diag.c
+++ b/net/sctp/sctp_diag.c
@@ -161,8 +161,9 @@ static int inet_sctp_diag_fill(struct sock *sk, struct 
sctp_association *asoc,
if (ext & (1 << (INET_DIAG_INFO - 1))) {
struct nlattr *attr;
 
-   attr = nla_reserve(skb, INET_DIAG_INFO,
-  sizeof(struct sctp_info));
+   attr = nla_reserve_64bit(skb, INET_DIAG_INFO,
+sizeof(struct sctp_info),
+INET_DIAG_PAD);
if (!attr)
goto errout;
 
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 1/8] macsec: use nla_put_u64_64bit()

[Nicolas Dichtel]

Signed-off-by: Nicolas Dichtel 
---
 drivers/net/macsec.c   | 121 ++---
 include/uapi/linux/if_link.h   |   1 +
 include/uapi/linux/if_macsec.h |   6 ++
 3 files changed, 95 insertions(+), 33 deletions(-)

diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
index 6caa72402de7..a172a1ffa151 100644
--- a/drivers/net/macsec.c
+++ b/drivers/net/macsec.c
@@ -1405,9 +1405,10 @@ static sci_t nla_get_sci(const struct nlattr *nla)
return (__force sci_t)nla_get_u64(nla);
 }
 
-static int nla_put_sci(struct sk_buff *skb, int attrtype, sci_t value)
+static int nla_put_sci(struct sk_buff *skb, int attrtype, sci_t value,
+  int padattr)
 {
-   return nla_put_u64(skb, attrtype, (__force u64)value);
+   return nla_put_u64_64bit(skb, attrtype, (__force u64)value, padattr);
 }
 
 static struct macsec_tx_sa *get_txsa_from_nl(struct net *net,
@@ -2131,16 +2132,36 @@ static int copy_rx_sc_stats(struct sk_buff *skb,
sum.InPktsUnusedSA+= tmp.InPktsUnusedSA;
}
 
-   if (nla_put_u64(skb, MACSEC_RXSC_STATS_ATTR_IN_OCTETS_VALIDATED, 
sum.InOctetsValidated) ||
-   nla_put_u64(skb, MACSEC_RXSC_STATS_ATTR_IN_OCTETS_DECRYPTED, 
sum.InOctetsDecrypted) ||
-   nla_put_u64(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_UNCHECKED, 
sum.InPktsUnchecked) ||
-   nla_put_u64(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_DELAYED, 
sum.InPktsDelayed) ||
-   nla_put_u64(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_OK, sum.InPktsOK) ||
-   nla_put_u64(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_INVALID, 
sum.InPktsInvalid) ||
-   nla_put_u64(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_LATE, 
sum.InPktsLate) ||
-   nla_put_u64(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_NOT_VALID, 
sum.InPktsNotValid) ||
-   nla_put_u64(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_NOT_USING_SA, 
sum.InPktsNotUsingSA) ||
-   nla_put_u64(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_UNUSED_SA, 
sum.InPktsUnusedSA))
+   if (nla_put_u64_64bit(skb, MACSEC_RXSC_STATS_ATTR_IN_OCTETS_VALIDATED,
+ sum.InOctetsValidated,
+ MACSEC_RXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_RXSC_STATS_ATTR_IN_OCTETS_DECRYPTED,
+ sum.InOctetsDecrypted,
+ MACSEC_RXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_UNCHECKED,
+ sum.InPktsUnchecked,
+ MACSEC_RXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_DELAYED,
+ sum.InPktsDelayed,
+ MACSEC_RXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_OK,
+ sum.InPktsOK,
+ MACSEC_RXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_INVALID,
+ sum.InPktsInvalid,
+ MACSEC_RXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_LATE,
+ sum.InPktsLate,
+ MACSEC_RXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_NOT_VALID,
+ sum.InPktsNotValid,
+ MACSEC_RXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_NOT_USING_SA,
+ sum.InPktsNotUsingSA,
+ MACSEC_RXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_RXSC_STATS_ATTR_IN_PKTS_UNUSED_SA,
+ sum.InPktsUnusedSA,
+ MACSEC_RXSC_STATS_ATTR_PAD))
return -EMSGSIZE;
 
return 0;
@@ -2169,10 +2190,18 @@ static int copy_tx_sc_stats(struct sk_buff *skb,
sum.OutOctetsEncrypted += tmp.OutOctetsEncrypted;
}
 
-   if (nla_put_u64(skb, MACSEC_TXSC_STATS_ATTR_OUT_PKTS_PROTECTED, 
sum.OutPktsProtected) ||
-   nla_put_u64(skb, MACSEC_TXSC_STATS_ATTR_OUT_PKTS_ENCRYPTED, 
sum.OutPktsEncrypted) ||
-   nla_put_u64(skb, MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_PROTECTED, 
sum.OutOctetsProtected) ||
-   nla_put_u64(skb, MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_ENCRYPTED, 
sum.OutOctetsEncrypted))
+   if (nla_put_u64_64bit(skb, MACSEC_TXSC_STATS_ATTR_OUT_PKTS_PROTECTED,
+ sum.OutPktsProtected,
+ MACSEC_TXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_TXSC_STATS_ATTR_OUT_PKTS_ENCRYPTED,
+ sum.OutPktsEncrypted,
+ MACSEC_TXSC_STATS_ATTR_PAD) ||
+   nla_put_u64_64bit(skb, MACSEC_TXSC_STATS_ATTR_OUT_OCTETS_PROTECTED,
+ 

[PATCH net-next 0/8] netlink: align attributes when needed (patchset #3)

[Nicolas Dichtel]

This is the continuation (series #3) of the work done to align netlink
attributes when these attributes contain some 64-bit fields.

It's the last patchset from what I've seen.

The last user of nla_put_u64() is block/drbd. This module does not use
standard netlink API (see all the stuff in include/linux/genl_magic_struct.h
and include/linux/genl_magic_func.h). I didn't modify it because it's seems
hard to do it whithout testing and fully understanding the context (for
example, why include/linux/drbd_genl.h is not part of uapi?).
Any thoughts?

 Documentation/networking/gen_stats.txt  |   6 +-
 drivers/net/macsec.c| 121 +++-
 drivers/net/wireless/mac80211_hwsim.c   |   2 +-
 drivers/net/wireless/mac80211_hwsim.h   |   1 +
 fs/quota/netlink.c  |  12 ++--
 include/net/gen_stats.h |   6 +-
 include/uapi/linux/gen_stats.h  |   1 +
 include/uapi/linux/if_link.h|   1 +
 include/uapi/linux/if_macsec.h  |   6 ++
 include/uapi/linux/inet_diag.h  |   4 +-
 include/uapi/linux/openvswitch.h|   2 +
 include/uapi/linux/pkt_cls.h|   2 +
 include/uapi/linux/quota.h  |   1 +
 include/uapi/linux/rtnetlink.h  |   1 +
 include/uapi/linux/tc_act/tc_bpf.h  |   1 +
 include/uapi/linux/tc_act/tc_connmark.h |   1 +
 include/uapi/linux/tc_act/tc_csum.h |   1 +
 include/uapi/linux/tc_act/tc_defact.h   |   1 +
 include/uapi/linux/tc_act/tc_gact.h |   1 +
 include/uapi/linux/tc_act/tc_ife.h  |   1 +
 include/uapi/linux/tc_act/tc_ipt.h  |   1 +
 include/uapi/linux/tc_act/tc_mirred.h   |   1 +
 include/uapi/linux/tc_act/tc_nat.h  |   1 +
 include/uapi/linux/tc_act/tc_pedit.h|   1 +
 include/uapi/linux/tc_act/tc_skbedit.h  |   1 +
 include/uapi/linux/tc_act/tc_vlan.h |   1 +
 net/core/gen_stats.c|  35 +
 net/core/neighbour.c|   3 +-
 net/core/rtnetlink.c|   4 +-
 net/core/sock_diag.c|   2 +-
 net/ipv4/inet_diag.c|   9 ++-
 net/openvswitch/datapath.c  |  27 +++
 net/sched/act_api.c |   7 +-
 net/sched/act_bpf.c |   3 +-
 net/sched/act_connmark.c|   3 +-
 net/sched/act_csum.c|   2 +-
 net/sched/act_gact.c|   2 +-
 net/sched/act_ife.c |   2 +-
 net/sched/act_ipt.c |   2 +-
 net/sched/act_mirred.c  |   2 +-
 net/sched/act_nat.c |   2 +-
 net/sched/act_pedit.c   |   2 +-
 net/sched/act_simple.c  |   2 +-
 net/sched/act_skbedit.c |   2 +-
 net/sched/act_vlan.c|   2 +-
 net/sched/cls_u32.c |   7 +-
 net/sched/sch_api.c |   6 +-
 net/sctp/sctp_diag.c|   5 +-
 48 files changed, 211 insertions(+), 98 deletions(-)

Comments are welcomed,
Regards,
Nicolas

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 8/8] sched: align nlattr properly when needed

[Nicolas Dichtel]

Signed-off-by: Nicolas Dichtel 
---
 Documentation/networking/gen_stats.txt  |  6 --
 include/net/gen_stats.h |  6 --
 include/uapi/linux/gen_stats.h  |  1 +
 include/uapi/linux/pkt_cls.h|  2 ++
 include/uapi/linux/rtnetlink.h  |  1 +
 include/uapi/linux/tc_act/tc_bpf.h  |  1 +
 include/uapi/linux/tc_act/tc_connmark.h |  1 +
 include/uapi/linux/tc_act/tc_csum.h |  1 +
 include/uapi/linux/tc_act/tc_defact.h   |  1 +
 include/uapi/linux/tc_act/tc_gact.h |  1 +
 include/uapi/linux/tc_act/tc_ife.h  |  1 +
 include/uapi/linux/tc_act/tc_ipt.h  |  1 +
 include/uapi/linux/tc_act/tc_mirred.h   |  1 +
 include/uapi/linux/tc_act/tc_nat.h  |  1 +
 include/uapi/linux/tc_act/tc_pedit.h|  1 +
 include/uapi/linux/tc_act/tc_skbedit.h  |  1 +
 include/uapi/linux/tc_act/tc_vlan.h |  1 +
 net/core/gen_stats.c| 35 -
 net/sched/act_api.c |  7 +--
 net/sched/act_bpf.c |  3 ++-
 net/sched/act_connmark.c|  3 ++-
 net/sched/act_csum.c|  2 +-
 net/sched/act_gact.c|  2 +-
 net/sched/act_ife.c |  2 +-
 net/sched/act_ipt.c |  2 +-
 net/sched/act_mirred.c  |  2 +-
 net/sched/act_nat.c |  2 +-
 net/sched/act_pedit.c   |  2 +-
 net/sched/act_simple.c  |  2 +-
 net/sched/act_skbedit.c |  2 +-
 net/sched/act_vlan.c|  2 +-
 net/sched/cls_u32.c |  7 ---
 net/sched/sch_api.c |  6 --
 33 files changed, 72 insertions(+), 37 deletions(-)

diff --git a/Documentation/networking/gen_stats.txt 
b/Documentation/networking/gen_stats.txt
index 70e6275b757a..ff630a87b511 100644
--- a/Documentation/networking/gen_stats.txt
+++ b/Documentation/networking/gen_stats.txt
@@ -33,7 +33,8 @@ my_dumping_routine(struct sk_buff *skb, ...)
 {
struct gnet_dump dump;
 
-   if (gnet_stats_start_copy(skb, TCA_STATS2, >lock, ) < 0)
+   if (gnet_stats_start_copy(skb, TCA_STATS2, >lock, ,
+ TCA_PAD) < 0)
goto rtattr_failure;
 
if (gnet_stats_copy_basic(, >bstats) < 0 ||
@@ -56,7 +57,8 @@ existing TLV types.
 my_dumping_routine(struct sk_buff *skb, ...)
 {
 if (gnet_stats_start_copy_compat(skb, TCA_STATS2, TCA_STATS,
-   TCA_XSTATS, >lock, ) < 0)
+TCA_XSTATS, >lock, ,
+TCA_PAD) < 0)
goto rtattr_failure;
...
 }
diff --git a/include/net/gen_stats.h b/include/net/gen_stats.h
index cbafa3768d48..610cd397890e 100644
--- a/include/net/gen_stats.h
+++ b/include/net/gen_stats.h
@@ -19,17 +19,19 @@ struct gnet_dump {
/* Backward compatibility */
int   compat_tc_stats;
int   compat_xstats;
+   int   padattr;
void *xstats;
int   xstats_len;
struct tc_stats   tc_stats;
 };
 
 int gnet_stats_start_copy(struct sk_buff *skb, int type, spinlock_t *lock,
- struct gnet_dump *d);
+ struct gnet_dump *d, int padattr);
 
 int gnet_stats_start_copy_compat(struct sk_buff *skb, int type,
 int tc_stats_type, int xstats_type,
-spinlock_t *lock, struct gnet_dump *d);
+spinlock_t *lock, struct gnet_dump *d,
+int padattr);
 
 int gnet_stats_copy_basic(struct gnet_dump *d,
  struct gnet_stats_basic_cpu __percpu *cpu,
diff --git a/include/uapi/linux/gen_stats.h b/include/uapi/linux/gen_stats.h
index 6487317ea619..52deccc2128e 100644
--- a/include/uapi/linux/gen_stats.h
+++ b/include/uapi/linux/gen_stats.h
@@ -10,6 +10,7 @@ enum {
TCA_STATS_QUEUE,
TCA_STATS_APP,
TCA_STATS_RATE_EST64,
+   TCA_STATS_PAD,
__TCA_STATS_MAX,
 };
 #define TCA_STATS_MAX (__TCA_STATS_MAX - 1)
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index c43c5f78b9c4..84660905fedf 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -66,6 +66,7 @@ enum {
TCA_ACT_OPTIONS,
TCA_ACT_INDEX,
TCA_ACT_STATS,
+   TCA_ACT_PAD,
__TCA_ACT_MAX
 };
 
@@ -173,6 +174,7 @@ enum {
TCA_U32_PCNT,
TCA_U32_MARK,
TCA_U32_FLAGS,
+   TCA_U32_PAD,
__TCA_U32_MAX
 };
 
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index a94e0b69c769..262f0379d83a 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -542,6 +542,7 @@ enum {
TCA_FCNT,
TCA_STATS2,
TCA_STAB,
+   TCA_PAD,
__TCA_MAX
 };
 

[PATCH net-next 7/8] neigh: align nlattr properly when needed

[Nicolas Dichtel]

Signed-off-by: Nicolas Dichtel 
---
 net/core/neighbour.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 6a395d440228..29dd8cc22bbf 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1857,7 +1857,8 @@ static int neightbl_fill_info(struct sk_buff *skb, struct 
neigh_table *tbl,
ndst.ndts_table_fulls   += st->table_fulls;
}
 
-   if (nla_put(skb, NDTA_STATS, sizeof(ndst), ))
+   if (nla_put_64bit(skb, NDTA_STATS, sizeof(ndst), ,
+ NDTA_PAD))
goto nla_put_failure;
}
 
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 3/8] fs/quota: use nla_put_u64_64bit()

[Nicolas Dichtel]

Signed-off-by: Nicolas Dichtel 
---
 fs/quota/netlink.c | 12 +++-
 include/uapi/linux/quota.h |  1 +
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/fs/quota/netlink.c b/fs/quota/netlink.c
index d07a2f91d858..8b252673d454 100644
--- a/fs/quota/netlink.c
+++ b/fs/quota/netlink.c
@@ -47,7 +47,7 @@ void quota_send_warning(struct kqid qid, dev_t dev,
void *msg_head;
int ret;
int msg_size = 4 * nla_total_size(sizeof(u32)) +
-  2 * nla_total_size(sizeof(u64));
+  2 * nla_total_size_64bit(sizeof(u64));
 
/* We have to allocate using GFP_NOFS as we are called from a
 * filesystem performing write and thus further recursion into
@@ -68,8 +68,9 @@ void quota_send_warning(struct kqid qid, dev_t dev,
ret = nla_put_u32(skb, QUOTA_NL_A_QTYPE, qid.type);
if (ret)
goto attr_err_out;
-   ret = nla_put_u64(skb, QUOTA_NL_A_EXCESS_ID,
- from_kqid_munged(_user_ns, qid));
+   ret = nla_put_u64_64bit(skb, QUOTA_NL_A_EXCESS_ID,
+   from_kqid_munged(_user_ns, qid),
+   QUOTA_NL_A_PAD);
if (ret)
goto attr_err_out;
ret = nla_put_u32(skb, QUOTA_NL_A_WARNING, warntype);
@@ -81,8 +82,9 @@ void quota_send_warning(struct kqid qid, dev_t dev,
ret = nla_put_u32(skb, QUOTA_NL_A_DEV_MINOR, MINOR(dev));
if (ret)
goto attr_err_out;
-   ret = nla_put_u64(skb, QUOTA_NL_A_CAUSED_ID,
- from_kuid_munged(_user_ns, current_uid()));
+   ret = nla_put_u64_64bit(skb, QUOTA_NL_A_CAUSED_ID,
+   from_kuid_munged(_user_ns, current_uid()),
+   QUOTA_NL_A_PAD);
if (ret)
goto attr_err_out;
genlmsg_end(skb, msg_head);
diff --git a/include/uapi/linux/quota.h b/include/uapi/linux/quota.h
index 38baddb807f5..4d2489ef6f10 100644
--- a/include/uapi/linux/quota.h
+++ b/include/uapi/linux/quota.h
@@ -191,6 +191,7 @@ enum {
QUOTA_NL_A_DEV_MAJOR,
QUOTA_NL_A_DEV_MINOR,
QUOTA_NL_A_CAUSED_ID,
+   QUOTA_NL_A_PAD,
__QUOTA_NL_A_MAX,
 };
 #define QUOTA_NL_A_MAX (__QUOTA_NL_A_MAX - 1)
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 5/8] ovs: align nlattr properly when needed

[Nicolas Dichtel]

I also fix commit 8b32ab9e6ef1: use nla_total_size_64bit() for
OVS_FLOW_ATTR_USED in ovs_flow_cmd_msg_size().

Fixes: 8b32ab9e6ef1 ("ovs: use nla_put_u64_64bit()")
Signed-off-by: Nicolas Dichtel 
---
 include/uapi/linux/openvswitch.h |  2 ++
 net/openvswitch/datapath.c   | 27 +++
 2 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/include/uapi/linux/openvswitch.h b/include/uapi/linux/openvswitch.h
index d6be1fb778a5..bb0d515b7654 100644
--- a/include/uapi/linux/openvswitch.h
+++ b/include/uapi/linux/openvswitch.h
@@ -84,6 +84,7 @@ enum ovs_datapath_attr {
OVS_DP_ATTR_STATS,  /* struct ovs_dp_stats */
OVS_DP_ATTR_MEGAFLOW_STATS, /* struct ovs_dp_megaflow_stats */
OVS_DP_ATTR_USER_FEATURES,  /* OVS_DP_F_*  */
+   OVS_DP_ATTR_PAD,
__OVS_DP_ATTR_MAX
 };
 
@@ -253,6 +254,7 @@ enum ovs_vport_attr {
OVS_VPORT_ATTR_UPCALL_PID, /* array of u32 Netlink socket PIDs for */
/* receiving upcalls */
OVS_VPORT_ATTR_STATS,   /* struct ovs_vport_stats */
+   OVS_VPORT_ATTR_PAD,
__OVS_VPORT_ATTR_MAX
 };
 
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 22d9a5316304..856bd8dba676 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -738,9 +738,9 @@ static size_t ovs_flow_cmd_msg_size(const struct 
sw_flow_actions *acts,
len += nla_total_size(acts->orig_len);
 
return len
-   + nla_total_size(sizeof(struct ovs_flow_stats)) /* 
OVS_FLOW_ATTR_STATS */
+   + nla_total_size_64bit(sizeof(struct ovs_flow_stats)) /* 
OVS_FLOW_ATTR_STATS */
+ nla_total_size(1) /* OVS_FLOW_ATTR_TCP_FLAGS */
-   + nla_total_size(8); /* OVS_FLOW_ATTR_USED */
+   + nla_total_size_64bit(8); /* OVS_FLOW_ATTR_USED */
 }
 
 /* Called with ovs_mutex or RCU read lock. */
@@ -759,7 +759,9 @@ static int ovs_flow_cmd_fill_stats(const struct sw_flow 
*flow,
return -EMSGSIZE;
 
if (stats.n_packets &&
-   nla_put(skb, OVS_FLOW_ATTR_STATS, sizeof(struct ovs_flow_stats), 
))
+   nla_put_64bit(skb, OVS_FLOW_ATTR_STATS,
+ sizeof(struct ovs_flow_stats), ,
+ OVS_FLOW_ATTR_PAD))
return -EMSGSIZE;
 
if ((u8)ntohs(tcp_flags) &&
@@ -1435,8 +1437,8 @@ static size_t ovs_dp_cmd_msg_size(void)
size_t msgsize = NLMSG_ALIGN(sizeof(struct ovs_header));
 
msgsize += nla_total_size(IFNAMSIZ);
-   msgsize += nla_total_size(sizeof(struct ovs_dp_stats));
-   msgsize += nla_total_size(sizeof(struct ovs_dp_megaflow_stats));
+   msgsize += nla_total_size_64bit(sizeof(struct ovs_dp_stats));
+   msgsize += nla_total_size_64bit(sizeof(struct ovs_dp_megaflow_stats));
msgsize += nla_total_size(sizeof(u32)); /* OVS_DP_ATTR_USER_FEATURES */
 
return msgsize;
@@ -1463,13 +1465,13 @@ static int ovs_dp_cmd_fill_info(struct datapath *dp, 
struct sk_buff *skb,
goto nla_put_failure;
 
get_dp_stats(dp, _stats, _megaflow_stats);
-   if (nla_put(skb, OVS_DP_ATTR_STATS, sizeof(struct ovs_dp_stats),
-   _stats))
+   if (nla_put_64bit(skb, OVS_DP_ATTR_STATS, sizeof(struct ovs_dp_stats),
+ _stats, OVS_DP_ATTR_PAD))
goto nla_put_failure;
 
-   if (nla_put(skb, OVS_DP_ATTR_MEGAFLOW_STATS,
-   sizeof(struct ovs_dp_megaflow_stats),
-   _megaflow_stats))
+   if (nla_put_64bit(skb, OVS_DP_ATTR_MEGAFLOW_STATS,
+ sizeof(struct ovs_dp_megaflow_stats),
+ _megaflow_stats, OVS_DP_ATTR_PAD))
goto nla_put_failure;
 
if (nla_put_u32(skb, OVS_DP_ATTR_USER_FEATURES, dp->user_features))
@@ -1838,8 +1840,9 @@ static int ovs_vport_cmd_fill_info(struct vport *vport, 
struct sk_buff *skb,
goto nla_put_failure;
 
ovs_vport_get_stats(vport, _stats);
-   if (nla_put(skb, OVS_VPORT_ATTR_STATS, sizeof(struct ovs_vport_stats),
-   _stats))
+   if (nla_put_64bit(skb, OVS_VPORT_ATTR_STATS,
+ sizeof(struct ovs_vport_stats), _stats,
+ OVS_VPORT_ATTR_PAD))
goto nla_put_failure;
 
if (ovs_vport_get_upcall_portids(vport, skb))
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 6/8] rtnl: align nlattr properly when needed

[Nicolas Dichtel]

Signed-off-by: Nicolas Dichtel 
---
 net/core/rtnetlink.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 9efc1f34ef3b..5503dfe6a050 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -876,7 +876,7 @@ static noinline size_t if_nlmsg_size(const struct 
net_device *dev,
   + nla_total_size(IFNAMSIZ) /* IFLA_IFNAME */
   + nla_total_size(IFALIASZ) /* IFLA_IFALIAS */
   + nla_total_size(IFNAMSIZ) /* IFLA_QDISC */
-  + nla_total_size(sizeof(struct rtnl_link_ifmap))
+  + nla_total_size_64bit(sizeof(struct rtnl_link_ifmap))
   + nla_total_size(sizeof(struct rtnl_link_stats))
   + nla_total_size_64bit(sizeof(struct rtnl_link_stats64))
   + nla_total_size(MAX_ADDR_LEN) /* IFLA_ADDRESS */
@@ -1181,7 +1181,7 @@ static int rtnl_fill_link_ifmap(struct sk_buff *skb, 
struct net_device *dev)
.dma = dev->dma,
.port= dev->if_port,
};
-   if (nla_put(skb, IFLA_MAP, sizeof(map), ))
+   if (nla_put_64bit(skb, IFLA_MAP, sizeof(map), , IFLA_PAD))
return -EMSGSIZE;
 
return 0;
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] nl80211: use nla_put_u64_64bit() for the remaining u64 attributes

[Johannes Berg]

From: Johannes Berg 

Nicolas converted most users, but didn't realize some were generated
by macros. Convert those over as well.

Signed-off-by: Johannes Berg 
---
 include/uapi/linux/nl80211.h |  4 
 net/wireless/nl80211.c   | 36 ++--
 2 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index f958a7173eb4..e23d78685a01 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2517,6 +2517,7 @@ enum nl80211_sta_bss_param {
  * attributes carrying the actual values.
  * @NL80211_STA_INFO_RX_DURATION: aggregate PPDU duration for all frames
  * received from the station (u64, usec)
+ * @NL80211_STA_INFO_PAD: attribute used for padding for 64-bit alignment
  * @__NL80211_STA_INFO_AFTER_LAST: internal
  * @NL80211_STA_INFO_MAX: highest possible station info attribute
  */
@@ -2554,6 +2555,7 @@ enum nl80211_sta_info {
NL80211_STA_INFO_BEACON_SIGNAL_AVG,
NL80211_STA_INFO_TID_STATS,
NL80211_STA_INFO_RX_DURATION,
+   NL80211_STA_INFO_PAD,
 
/* keep last */
__NL80211_STA_INFO_AFTER_LAST,
@@ -2570,6 +2572,7 @@ enum nl80211_sta_info {
  * transmitted MSDUs (not counting the first attempt; u64)
  * @NL80211_TID_STATS_TX_MSDU_FAILED: number of failed transmitted
  * MSDUs (u64)
+ * @NL80211_TID_STATS_PAD: attribute used for padding for 64-bit alignment
  * @NUM_NL80211_TID_STATS: number of attributes here
  * @NL80211_TID_STATS_MAX: highest numbered attribute here
  */
@@ -2579,6 +2582,7 @@ enum nl80211_tid_stats {
NL80211_TID_STATS_TX_MSDU,
NL80211_TID_STATS_TX_MSDU_RETRIES,
NL80211_TID_STATS_TX_MSDU_FAILED,
+   NL80211_TID_STATS_PAD,
 
/* keep last */
NUM_NL80211_TID_STATS,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 5b0d2c8c2165..9bc84a2ddd34 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3755,11 +3755,18 @@ static int nl80211_send_station(struct sk_buff *msg, 
u32 cmd, u32 portid,
goto nla_put_failure;
 
 #define PUT_SINFO(attr, memb, type) do {   \
+   BUILD_BUG_ON(sizeof(type) == sizeof(u64));  \
if (sinfo->filled & (1ULL << NL80211_STA_INFO_ ## attr) &&  \
nla_put_ ## type(msg, NL80211_STA_INFO_ ## attr,\
 sinfo->memb))  \
goto nla_put_failure;   \
} while (0)
+#define PUT_SINFO_U64(attr, memb) do { \
+   if (sinfo->filled & (1ULL << NL80211_STA_INFO_ ## attr) &&  \
+   nla_put_u64_64bit(msg, NL80211_STA_INFO_ ## attr,   \
+ sinfo->memb, NL80211_STA_INFO_PAD))   \
+   goto nla_put_failure;   \
+   } while (0)
 
PUT_SINFO(CONNECTED_TIME, connected_time, u32);
PUT_SINFO(INACTIVE_TIME, inactive_time, u32);
@@ -3776,12 +3783,12 @@ static int nl80211_send_station(struct sk_buff *msg, 
u32 cmd, u32 portid,
(u32)sinfo->tx_bytes))
goto nla_put_failure;
 
-   PUT_SINFO(RX_BYTES64, rx_bytes, u64);
-   PUT_SINFO(TX_BYTES64, tx_bytes, u64);
+   PUT_SINFO_U64(RX_BYTES64, rx_bytes);
+   PUT_SINFO_U64(TX_BYTES64, tx_bytes);
PUT_SINFO(LLID, llid, u16);
PUT_SINFO(PLID, plid, u16);
PUT_SINFO(PLINK_STATE, plink_state, u8);
-   PUT_SINFO(RX_DURATION, rx_duration, u64);
+   PUT_SINFO_U64(RX_DURATION, rx_duration);
 
switch (rdev->wiphy.signal_type) {
case CFG80211_SIGNAL_TYPE_MBM:
@@ -3849,12 +3856,13 @@ static int nl80211_send_station(struct sk_buff *msg, 
u32 cmd, u32 portid,
>sta_flags))
goto nla_put_failure;
 
-   PUT_SINFO(T_OFFSET, t_offset, u64);
-   PUT_SINFO(RX_DROP_MISC, rx_dropped_misc, u64);
-   PUT_SINFO(BEACON_RX, rx_beacon, u64);
+   PUT_SINFO_U64(T_OFFSET, t_offset);
+   PUT_SINFO_U64(RX_DROP_MISC, rx_dropped_misc);
+   PUT_SINFO_U64(BEACON_RX, rx_beacon);
PUT_SINFO(BEACON_SIGNAL_AVG, rx_beacon_signal_avg, u8);
 
 #undef PUT_SINFO
+#undef PUT_SINFO_U64
 
if (sinfo->filled & BIT(NL80211_STA_INFO_TID_STATS)) {
struct nlattr *tidsattr;
@@ -3877,19 +3885,19 @@ static int nl80211_send_station(struct sk_buff *msg, 
u32 cmd, u32 portid,
if (!tidattr)
goto nla_put_failure;
 
-#define PUT_TIDVAL(attr, memb, type) do {  \
+#define PUT_TIDVAL_U64(attr, memb) do {
\
if (tidstats->filled & BIT(NL80211_TID_STATS_ ## attr) &&   \
-   nla_put_ ## type(msg, NL80211_TID_STATS_ ## attr,   \
- 

Re: [PATCH net-next 9/9] wireless: use nla_put_u64_64bit()

[Nicolas Dichtel]

Hi Johannes,

Le 26/04/2016 09:39, Johannes Berg a écrit :
> Hi Nicholas,
> 
> Thanks for doing this.
> 
> I'll also add a fix for the macro-generated nla_put_64() in
> nl80211_send_station(), unless there was a particular reason you didn't
> take that one?
> 
> I suspect you just missed it while grepping, but wanted to ask.
Yes you're right. I missed it. Thank you for the check.

I will send the last patchset in some minutes.


Regards,
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 9/9] wireless: use nla_put_u64_64bit()

[Johannes Berg]

Hi Nicholas,

Thanks for doing this.

I'll also add a fix for the macro-generated nla_put_64() in
nl80211_send_station(), unless there was a particular reason you didn't
take that one?

I suspect you just missed it while grepping, but wanted to ask.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] wext: remove a/b/g/n from SIOCGIWNAME

[Johannes Berg]

From: Johannes Berg 

Since a/b/g/n no longer exist as spec amendements and VHT (ex 802.11ac)
wasn't handled at all, it's better to just remove the amendment strings
to avoid confusion.

Signed-off-by: Johannes Berg 
---
 net/wireless/wext-compat.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 4c89f0ca61ba..9f27221c8913 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -25,42 +25,7 @@ int cfg80211_wext_giwname(struct net_device *dev,
  struct iw_request_info *info,
  char *name, char *extra)
 {
-   struct wireless_dev *wdev = dev->ieee80211_ptr;
-   struct ieee80211_supported_band *sband;
-   bool is_ht = false, is_a = false, is_b = false, is_g = false;
-
-   if (!wdev)
-   return -EOPNOTSUPP;
-
-   sband = wdev->wiphy->bands[NL80211_BAND_5GHZ];
-   if (sband) {
-   is_a = true;
-   is_ht |= sband->ht_cap.ht_supported;
-   }
-
-   sband = wdev->wiphy->bands[NL80211_BAND_2GHZ];
-   if (sband) {
-   int i;
-   /* Check for mandatory rates */
-   for (i = 0; i < sband->n_bitrates; i++) {
-   if (sband->bitrates[i].bitrate == 10)
-   is_b = true;
-   if (sband->bitrates[i].bitrate == 60)
-   is_g = true;
-   }
-   is_ht |= sband->ht_cap.ht_supported;
-   }
-
strcpy(name, "IEEE 802.11");
-   if (is_a)
-   strcat(name, "a");
-   if (is_b)
-   strcat(name, "b");
-   if (is_g)
-   strcat(name, "g");
-   if (is_ht)
-   strcat(name, "n");
-
return 0;
 }
 EXPORT_WEXT_HANDLER(cfg80211_wext_giwname);
-- 
2.8.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] iwlwifi: fix fw version reading for DVM devices

[Coelho, Luciano]

On Mon, 2016-04-25 at 20:02 +0300, Luca Coelho wrote:
> From: Luca Coelho 
> 
> In commit 97f95c93c8ed ("iwlwifi: remove support for fw older than
> -16.ucode") we accidentally changed the fw version reading code for
> DVM devices.  The code intended to remove the old fw version API,
> because all MVM firmwares version 16 and above that we support don't
> use it anymore.  But DVM devices still use the old FW API.
> 
> Fix that by bringing the code back in.
> 
> Reported-by: Pat Erley 
> Fixes: 97f95c93c8ed ("iwlwifi: remove support for fw older than-
> 16.ucode")
> Signed-off-by: Luca Coelho 
> --- 

Kalle, I forgot to add your Tested-by.  Feel free to add it if you want
(as if I have the authority of saying this to the maintainer :P).

--
Cheers,
Luca.

Intel 7260 AC only using 802.11n not AC

[Radu P]

Hello,

These is the relevant data:

firmware-version: 17.265642.0

[  292.689871] iwlwifi :04:00.0: loaded firmware version
17.265642.0 op_mode iwlmvm
[  292.702902] iwlwifi :04:00.0: Detected Intel(R) Dual Band
Wireless AC 7260, REV=0x144

wlan1 IEEE 802.11abgn <- not AC

Kernel version: 4.4.0-21-generic #37~14.04.1-Ubuntu

AC mode is working with Windows 10.

Any help is appreciated!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz

[Johannes Berg]

On Thu, 2016-04-21 at 08:15 -0700, Ben Greear wrote:

> The thing is, it actually works just fine with the patch I posted
> to fix mac80211, and at any rate, even if the mac80211 patch isn't
> applied, the ath10k driver works just fine in HT mode.

This patch has no implications on HT, and I wasn't planning on applying
the mac80211 patch.

As I said, I have no objections to doing the (Broadcom) vendor specific
IEs for "VHT" in 2.4 GHz band, but I don't think we should advertise
the spec IEs when they're explicitly specified to be used only in the
5.2 GHz band.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html