Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz
On Wed, Apr 27, 2016 at 1:40 AM, Ben Greear wrote: > 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. Right, i think this might become more common. So may we need to change minstrel_ht as well? > 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. Ideally as this is vendor specific it makes sense to implement this at Driver/FW level rather than implementing it at a common stack like mac80211. > Maybe someone that actually knows about these IEs can explain why > they are worth using? These IE's can be parsed in the driver without any mac80211 involvement. -- 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 on disable
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). (For the following, I am testing with a USB hub, because as I said in a previous e-mail, I get a kernel panic if I try to plug it in directly to the BeagleBone Black without the hub. However, I have also had this issue on a BeagleBone Black-based device running a 3.14.x Yocto-built kernel, where I was able to use it without a hub, and this issue also occurs when the device is plugged directly into the BeagleBone Black.) If I plug in the rt2800 device, and wait for it to connect to an access point, then try to disable it by various methods, I get a kernel soft lockup. Various methods to disable the device which cause the kernel soft lockup include (while current directory is e.g. /sys/bus/usb/devices/1-1.3): echo 0 > authorized echo -1 > bConfigurationValue modprobe -r rt2800usb echo 1-1.3 > driver/unbind On the 4.4.6 kernel, they sometimes succeed, but often cause a soft lockup. On the 3.14.x Yocto-built kernel, I found they always fail if the Wi-Fi device is in-use (operating in client or access point mode) but succeed if it is idle. E.g. in a recent test doing "echo 0 > authorized", I got the following in the serial debug console: [ 172.167656] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:0:6] [ 200.167589] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:6] [ 228.167550] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:6] In this case, I was able to do a couple of successful "echo 0 > authorized" and then re-enable with "echo 1 > authorized", before the lockup occurred on a third "echo 0 > authorized". I'm attaching the corresponding dmesg dump. -- Craig McQueen [ 172.167656] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:0:6] [ 200.167589] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:6] [ 228.167550] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:0:6] 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. [
RE: rt2800 and BeagleBone Black kernel panic when connecting to access point
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] clocksource
Re: rt2800 and BeagleBone Black kernel panic when connecting to access point
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 000
rt2800 and BeagleBone Black soft lockup when unplugging from USB hub
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 ip
RE: rt2800 and BeagleBone Black kernel panic when connecting to access point
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
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 d
Re: [PATCH v2] ath10k: remove VHT capabilities from 2.4GHz
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
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
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
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)
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()
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
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)
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
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(&ar->arvifs);
+
/* we don't care about HTT in UTF mode */
if (mode == ATH10K_FIRMWARE_MODE_NORMAL) {
status = ath10k_htt_setup(&ar->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(&ar->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
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
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()
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()
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)
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), &value, 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
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
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
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
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)
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), &value, 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
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
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
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
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
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()
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(&init_user_ns, qid));
> + ret = nla_put_u64_64bit(skb, QUOTA_NL_A_EXCESS_ID,
> + from_kqid_munged(&init_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(&init_user_ns, current_uid()));
> + ret = nla_put_u64_64bit(skb, QUOTA_NL_A_CAUSED_ID,
> + from_kuid_munged(&init_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
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
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
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
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
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 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 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
> 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
> 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()
> 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
> 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()
> 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
> 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
> 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
> 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
> 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
> 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'
> '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
> 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_
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
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
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
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
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
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
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", &size);
> + 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, &retlen, 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", &size);
> + if (val)
> + dev->cap.has_2ghz = be32_to_cpup(val);
> +
> + val = of_get_property(np, "mediatek,5ghz", &size);
> + 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 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
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()
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
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()
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,
+ sum.OutOctetsProtected,
+
[PATCH net-next 0/8] netlink: align attributes when needed (patchset #3)
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
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, &mystruct->lock, &dump) < 0)
+ if (gnet_stats_start_copy(skb, TCA_STATS2, &mystruct->lock, &dump,
+ TCA_PAD) < 0)
goto rtattr_failure;
if (gnet_stats_copy_basic(&dump, &mystruct->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, &mystruct->lock, &dump) < 0)
+TCA_XSTATS, &mystruct->lock, &dump,
+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
[PATCH net-next 7/8] neigh: align nlattr properly when needed
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), &ndst)) + if (nla_put_64bit(skb, NDTA_STATS, sizeof(ndst), &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()
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(&init_user_ns, qid));
+ ret = nla_put_u64_64bit(skb, QUOTA_NL_A_EXCESS_ID,
+ from_kqid_munged(&init_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(&init_user_ns, current_uid()));
+ ret = nla_put_u64_64bit(skb, QUOTA_NL_A_CAUSED_ID,
+ from_kuid_munged(&init_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
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),
&stats))
+ nla_put_64bit(skb, OVS_FLOW_ATTR_STATS,
+ sizeof(struct ovs_flow_stats), &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, &dp_stats, &dp_megaflow_stats);
- if (nla_put(skb, OVS_DP_ATTR_STATS, sizeof(struct ovs_dp_stats),
- &dp_stats))
+ if (nla_put_64bit(skb, OVS_DP_ATTR_STATS, sizeof(struct ovs_dp_stats),
+ &dp_stats, OVS_DP_ATTR_PAD))
goto nla_put_failure;
- if (nla_put(skb, OVS_DP_ATTR_MEGAFLOW_STATS,
- sizeof(struct ovs_dp_megaflow_stats),
- &dp_megaflow_stats))
+ if (nla_put_64bit(skb, OVS_DP_ATTR_MEGAFLOW_STATS,
+ sizeof(struct ovs_dp_megaflow_stats),
+ &dp_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, &vport_stats);
- if (nla_put(skb, OVS_VPORT_ATTR_STATS, sizeof(struct ovs_vport_stats),
- &vport_stats))
+ if (nla_put_64bit(skb, OVS_VPORT_ATTR_STATS,
+ sizeof(struct ovs_vport_stats), &vport_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
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), &map)) + if (nla_put_64bit(skb, IFLA_MAP, sizeof(map), &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
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,
&sinfo->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, \
-tidstats->memb))
Re: [PATCH net-next 9/9] wireless: use nla_put_u64_64bit()
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()
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
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
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
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
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
