* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Kalle Valo @ 2016-11-23 19:26 UTC (permalink / raw)
To: Jason Cooper
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Andrew Lunn
In-Reply-To: <20161123191539.GF2799@io.lakedaemon.net>
Jason Cooper <jason@lakedaemon.net> writes:
> All,
>
> I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
> board (Marvell Armada 370 SoC). Every day or so I get a consistent
> crash that brings down the whole board. I've attached three oops I
> captured on the serial port.
>
> I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
> at me as "this would fix it". And since it takes a day or so to trigger
> the oops, bisecting would be a bit brutal. Does anyone have any insight
> into this?
Is this a regression, meaning that it didn't crash on older kernels but
crashes on newer ones? Or has it always crashed?
--
Kalle Valo
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 19:15 UTC (permalink / raw)
To: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel
Cc: Kalle Valo, Thomas Petazzoni, Gregory CLEMENT, Andrew Lunn
All,
I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
board (Marvell Armada 370 SoC). Every day or so I get a consistent
crash that brings down the whole board. I've attached three oops I
captured on the serial port.
I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
at me as "this would fix it". And since it takes a day or so to trigger
the oops, bisecting would be a bit brutal. Does anyone have any insight
into this?
thx,
Jason.
------- oops from v4.2.8 ------------------------------------------
[ 3572.897994] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[ 3572.906134] pgd = c0004000
[ 3572.908891] [00000020] *pgd=00000000
[ 3572.912504] Internal error: Oops: 5 [#1] SMP ARM
[ 3572.917142] Modules linked in: tun ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge ipv6 ath9k ath9k_common ath9k_hw led_class ath
[ 3572.930749] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.2.8 #57
[ 3572.937915] Hardware name: Marvell Armada 370/XP (Device Tree)
[ 3572.943774] task: c06fdd30 ti: c06f8000 task.ti: c06f8000
[ 3572.949208] PC is at ath_cmn_process_fft+0xac/0x4a0 [ath9k_common]
[ 3572.955421] LR is at ath_cmn_process_fft+0xc8/0x4a0 [ath9k_common]
[ 3572.961631] pc : [<bf081f44>] lr : [<bf081f60>] psr: 80000153
[ 3572.961631] sp : c06f9ca0 ip : 00000000 fp : 00000000
[ 3572.973160] r10: dc9a8010 r9 : 00000000 r8 : c06fa4d0
[ 3572.978409] r7 : 0000006c r6 : dd3abfc0 r5 : c06fad88 r4 : 00000000
[ 3572.984965] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[ 3572.991522] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 3572.998951] Control: 10c5387d Table: 1c894019 DAC: 00000015
[ 3573.004723] Process swapper/0 (pid: 0, stack limit = 0xc06f8220)
[ 3573.010756] Stack: (0xc06f9ca0 to 0xc06fa000)
[ 3573.015137] 9ca0: c0734e31 dfbe3f40 c06f6f40 c06f6f40 c06fae34 c0734184 00989680 00000003
[ 3573.023356] 9cc0: dff6cde0 00000008 c06f9df4 00000069 dca0ab8c c0098b44 00000985 00000fc0
[ 3573.031573] 9ce0: c0733700 dffa0560 00000002 c001b6ac 000000c0 00000000 00000000 00000000
[ 3573.039790] 9d00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.048006] 9d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.056222] 9d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3573.064438] 9d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 dc9a8010
[ 3573.072654] 9d80: 00000000 dc983d18 dc983d00 dc983d00 00000002 dd045c90 dca08d40 bf090e64
[ 3573.080872] 9da0: d364463c 00000000 edf3c980 0000033f 0000033f 000001fa dc9a8010 00000000
[ 3573.089090] 9dc0: d3644890 00000000 dc9a8038 dca083e0 dd3abfc0 00000000 dd3abfc0 dca097ac
[ 3573.097306] 9de0: dc9a8038 00000002 00000001 dca083e0 00000100 d364463c 2602006c 018eff80
[ 3573.105522] 9e00: 80808000 00808080 20000001 00000000 00000000 00000000 00000000 00000000
[ 3573.113739] 9e20: 00000000 00000000 c06f9e68 dca08d40 00000001 dc9a8010 dca09708 c06f9e68
[ 3573.121955] 9e40: c06f4294 c06f8000 00000006 bf08e698 bf08e5dc dca096d0 dca096d4 00000000
[ 3573.130172] 9e60: c0735bc0 c0027e4c 00000000 c06fa098 00000100 c06f8000 c06f9e88 40000006
[ 3573.138389] 9e80: c06fa080 c0028030 ed5b3300 0000033f c06fa080 c06f4308 0000000a c0735bc0
[ 3573.146606] 9ea0: c06fa100 0004fe8e c051e380 00200000 c06f8000 c06f5444 00000000 00000000
[ 3573.154823] 9ec0: 00000001 df405000 c06fa484 c0759f80 c06f8000 c00283d8 c06f5444 c005b838
[ 3573.163041] 9ee0: c0341814 00000001 c0759f80 c06f9f20 000003ff c0009410 c034180c c0341814
[ 3573.171257] 9f00: 80000153 ffffffff c06f9f54 ed5b20c4 0000033f ed5b20c4 c06f8000 c0013340
[ 3573.179474] 9f20: 00000000 fffffffa 1f4ed000 dfbe3f40 ecf52c5b 0000033f dfbe34d0 00000001
[ 3573.187691] 9f40: ed5b20c4 0000033f ed5b20c4 c06f8000 0000001a c06f9f68 c034180c c0341814
[ 3573.195908] 9f60: 80000153 ffffffff 00000000 00000000 ed5b20c4 0000033f dfbe34d0 c051e374
[ 3573.204125] 9f80: dfbe34d0 c072a608 c06f64c8 c06fa51c c06f4364 c06fa524 c06f8000 c00535ec
[ 3573.212343] 9fa0: c06f9fa0 c0734dd1 dfffce00 ffffffff dfffce00 c06b5c6c ffffffff ffffffff
[ 3573.220559] 9fc0: 00000000 c06b5670 00000000 c06ea990 00000000 c0735294 c06fa4c0 c06ea98c
[ 3573.228777] 9fe0: c06fee2c 00004059 561f5811 00000000 00000000 0000807c 00000000 00000000
[ 3573.237025] [<bf081f44>] (ath_cmn_process_fft [ath9k_common]) from [<bf090e64>] (ath_rx_tasklet+0xa14/0xafc [ath9k])
[ 3573.247613] [<bf090e64>] (ath_rx_tasklet [ath9k]) from [<bf08e698>] (ath9k_tasklet+0xbc/0x20c [ath9k])
[ 3573.256981] [<bf08e698>] (ath9k_tasklet [ath9k]) from [<c0027e4c>] (tasklet_action+0x7c/0x110)
[ 3573.265641] [<c0027e4c>] (tasklet_action) from [<c0028030>] (__do_softirq+0xf8/0x23c)
[ 3573.273513] [<c0028030>] (__do_softirq) from [<c00283d8>] (irq_exit+0x78/0xb0)
[ 3573.280778] [<c00283d8>] (irq_exit) from [<c005b838>] (__handle_domain_irq+0x60/0xb0)
[ 3573.288651] [<c005b838>] (__handle_domain_irq) from [<c0009410>] (armada_370_xp_handle_irq+0x50/0xbc)
[ 3573.297917] [<c0009410>] (armada_370_xp_handle_irq) from [<c0013340>] (__irq_svc+0x40/0x54)
[ 3573.306306] Exception stack(0xc06f9f20 to 0xc06f9f68)
[ 3573.311385] 9f20: 00000000 fffffffa 1f4ed000 dfbe3f40 ecf52c5b 0000033f dfbe34d0 00000001
[ 3573.319602] 9f40: ed5b20c4 0000033f ed5b20c4 c06f8000 0000001a c06f9f68 c034180c c0341814
[ 3573.327816] 9f60: 80000153 ffffffff
[ 3573.331331] [<c0013340>] (__irq_svc) from [<c0341814>] (cpuidle_enter_state+0xdc/0x248)
[ 3573.339385] [<c0341814>] (cpuidle_enter_state) from [<c00535ec>] (cpu_startup_entry+0x170/0x234)
[ 3573.348218] [<c00535ec>] (cpu_startup_entry) from [<c06b5c6c>] (start_kernel+0x3b0/0x3bc)
[ 3573.356436] Code: e59c9004 e3e0b000 e5938000 ea000002 (e7990102)
[ 3573.362634] ---[ end trace 47b32564cd3160db ]---
[ 3573.367281] Kernel panic - not syncing: Fatal exception in interrupt
[ 3573.373667] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
------- oops from v4.8.6 ---------------------------------------------
[231233.388543] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[231233.396804] pgd = c0004000
[231233.399614] [00000020] *pgd=00000000
[231233.403311] Internal error: Oops: 17 [#1] SMP ARM
[231233.408124] Modules linked in: ath9k ath9k_common ath9k_hw ath
[231233.414132] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
[231233.420165] Hardware name: Marvell Armada 370/XP (Device Tree)
[231233.426111] task: c0b091c0 task.stack: c0b00000
[231233.430760] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
[231233.437060] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
[231233.443357] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
[231233.443357] sp : c0b01cd0 ip : 00000000 fp : 00000000
[231233.455059] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
[231233.460394] r7 : 00000000 r6 : dbef9440 r5 : c0b03da0 r4 : 00000000
[231233.467037] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[231233.473682] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
[231233.481023] Control: 10c5387d Table: 1e614019 DAC: 00000051
[231233.486882] Process swapper/0 (pid: 0, stack limit = 0xc0b00220)
[231233.493001] Stack: (0xc0b01cd0 to 0xc0b02000)
[231233.497466] 1cc0: fffffffa 3b9ac9ff 003c8995 c0b44d30
[231233.505770] 1ce0: dda18010 00000000 c0b01e14 c017ad48 ffffffff dee1ac84 c0b44d30 c0b44b00
[231233.514073] 1d00: 0000099e 00000440 0001bef9 c01176f4 00000002 00000786 00000000 00000000
[231233.522377] 1d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.530680] 1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.538984] 1d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.547287] 1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[231233.555591] 1da0: dda18010 dda18010 00000000 defaa3d8 defaa3c0 defaa3c0 dee18e40 de5b4a18
[231233.563895] 1dc0: dda18010 bf08a9d0 071a3710 00000056 00989680 00000000 071a393a 00000056
[231233.572199] 1de0: 000001fb dee18440 00000000 dbef9440 dee198b0 00000014 dda18038 dee1a97c
[231233.580504] 1e00: dbef9440 00000002 00000001 dee18440 0036f478 071a3710 2422006c 018fff07
[231233.588807] 1e20: 80252900 01168e85 40000000 00000000 00000000 00000000 00000000 00000000
[231233.597110] 1e40: 00000000 00000000 c0a4a2c0 dee18e40 dda18010 dee19808 00000001 c0b00000
[231233.605414] 1e60: c0a4a2c0 c0b02080 40000006 bf088810 dee197d0 dee197d4 00000000 c0b01e88
[231233.613717] 1e80: c0b00000 c0126b88 00000000 00000006 c0b00000 c0b02098 c0b02080 00000100
[231233.622021] 1ea0: c0b02080 c0126d74 df405000 c0b01f30 c0b01ea8 c0b3bf80 0000000a 0160605b
[231233.630324] 1ec0: c0b02100 00200100 df488a20 c0a4d500 00000000 00000000 00000001 df405000
[231233.638629] 1ee0: c0b01f30 00000000 c0b03524 c0127120 c0a4d500 c01635e4 c04b7318 20000153
[231233.646933] 1f00: c0b61040 00000001 c0b61040 c010145c c04b7318 20000153 ffffffff c0b01f64
[231233.655236] 1f20: 0028571c c0b00000 00000000 c010bd8c 00000000 0000d24e 1f194000 dfbe31c0
[231233.663540] 1f40: 37d25f82 0000d24e dfbe2590 00000001 0028571c 0000d24e 00000000 c0b03524
[231233.671843] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff 00000051 00000000
[231233.680148] 1f80: dfbe2590 c0b00000 c0b034d4 00000001 dfbe2590 c0b2e070 c0a4e588 c0b0352c
[231233.688452] 1fa0: c0b03524 c015a240 c0b01fa8 c0b3b0f4 00000000 ffffffff 00000000 c0a00c54
[231233.696756] 1fc0: ffffffff ffffffff 00000000 c0a0068c 00000000 c0a3ba28 c0b3b614 c0b034c0
[231233.705059] 1fe0: c0a3ba24 c0b0a3a8 00004059 561f5811 00000000 0000807c 00000000 00000000
[231233.713401] [<bf07bec4>] (ath_cmn_process_fft [ath9k_common]) from [<bf08a9d0>] (ath_rx_tasklet+0x47c/0xb20 [ath9k])
[231233.724079] [<bf08a9d0>] (ath_rx_tasklet [ath9k]) from [<bf088810>] (ath9k_tasklet+0x1dc/0x218 [ath9k])
[231233.733623] [<bf088810>] (ath9k_tasklet [ath9k]) from [<c0126b88>] (tasklet_action+0x74/0x110)
[231233.742367] [<c0126b88>] (tasklet_action) from [<c0126d74>] (__do_softirq+0xfc/0x218)
[231233.750324] [<c0126d74>] (__do_softirq) from [<c0127120>] (irq_exit+0x7c/0xb4)
[231233.757678] [<c0127120>] (irq_exit) from [<c01635e4>] (__handle_domain_irq+0x60/0xb4)
[231233.765637] [<c01635e4>] (__handle_domain_irq) from [<c010145c>] (armada_370_xp_handle_irq+0x48/0xa8)
[231233.774989] [<c010145c>] (armada_370_xp_handle_irq) from [<c010bd8c>] (__irq_svc+0x6c/0x90)
[231233.783463] Exception stack(0xc0b01f30 to 0xc0b01f78)
[231233.788625] 1f20: 00000000 0000d24e 1f194000 dfbe31c0
[231233.796930] 1f40: 37d25f82 0000d24e dfbe2590 00000001 0028571c 0000d24e 00000000 c0b03524
[231233.805232] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff
[231233.811974] [<c010bd8c>] (__irq_svc) from [<c04b7318>] (cpuidle_enter_state+0x18c/0x2b4)
[231233.820202] [<c04b7318>] (cpuidle_enter_state) from [<c015a240>] (cpu_startup_entry+0x17c/0x220)
[231233.829124] [<c015a240>] (cpu_startup_entry) from [<c0a00c54>] (start_kernel+0x368/0x374)
[231233.837430] Code: e5933000 e1d330b4 e58d3030 ea000002 (e7970102)
[231233.843714] ---[ end trace 0a5139f91be0a117 ]---
[231233.848460] Kernel panic - not syncing: Fatal exception in interrupt
[231233.854937] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
------- oops from v4.8.6 #2 ------------------------------------------
[42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
[42059.311799] pgd = c0004000
[42059.314522] [00000020] *pgd=00000000
[42059.318162] Internal error: Oops: 17 [#1] SMP ARM
[42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
[42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
[42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
[42059.340613] task: c0b091c0 task.stack: c0b00000
[42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
[42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
[42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
[42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
[42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
[42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
[42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
[42059.387487] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
[42059.394741] Control: 10c5387d Table: 1ef48019 DAC: 00000051
[42059.400513] Process swapper/0 (pid: 0, stack limit = 0xc0b00220)
[42059.406545] Stack: (0xc0b01cd0 to 0xc0b02000)
[42059.410924] 1cc0: fffffffa 3b9ac9ff 0047c6ce c0b44d30
[42059.419141] 1ce0: de6a0010 00000000 c0b01e14 c017ad48 ffffffff dee0ac84 c0b44d30 c0b44b00
[42059.427357] 1d00: 0000099e 00000340 0001cfbd c01176f4 00000002 00000786 00000080 00000000
[42059.435573] 1d20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.443789] 1d40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.452005] 1d60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.460220] 1d80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[42059.468437] 1da0: de6a0010 de6a0010 00000000 deec5b58 deec5b40 deec5b40 dee08e40 de631ff0
[42059.476653] 1dc0: de6a0010 bf08a9d0 8918a8c8 00000002 00000000 00000000 8918aaa1 00000002
[42059.484869] 1de0: 00000200 dee08440 00000000 dcfbd340 dee098b0 00000014 de6a0038 dee0a97c
[42059.493085] 1e00: dcfbd340 00000002 00000001 dee08440 00fc2540 8918a8c8 0502006c 018e026c
[42059.501301] 1e20: 80202600 016d5ab7 40000100 00000000 00000000 00000000 00000000 00000000
[42059.509518] 1e40: 00000000 00000000 c0a4a2c0 dee08e40 de6a0010 dee09808 00000001 c0b00000
[42059.517734] 1e60: c0a4a2c0 c0b02080 40000006 bf088810 dee097d0 dee097d4 00000000 c0b01e88
[42059.525950] 1e80: c0b00000 c0126b88 00000000 00000006 c0b00000 c0b02098 c0b02080 00000100
[42059.534166] 1ea0: c0b02080 c0126d74 df405000 c0b01f30 c0b01ea8 c0b3bf80 0000000a 003fb83a
[42059.542382] 1ec0: c0b02100 00200100 df486a20 c0a4d500 00000000 00000000 00000001 df405000
[42059.550599] 1ee0: c0b01f30 00000000 c0b03524 c0127120 c0a4d500 c01635e4 c04b7318 20000153
[42059.558816] 1f00: c0b61040 00000001 c0b61040 c010145c c04b7318 20000153 ffffffff c0b01f64
[42059.567031] 1f20: 006895c7 c0b00000 00000000 c010bd8c 00000000 00002640 1f194000 dfbe31c0
[42059.575248] 1f40: b1708859 00002640 dfbe2590 00000001 006895c7 00002640 00000000 c0b03524
[42059.583464] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff 00000051 00000000
[42059.591681] 1f80: dfbe2590 c0b00000 c0b034d4 00000001 dfbe2590 c0b2e070 c0a4e588 c0b0352c
[42059.599897] 1fa0: c0b03524 c015a240 c0b01fa8 c0b3b0f4 00000000 ffffffff 00000000 c0a00c54
[42059.608114] 1fc0: ffffffff ffffffff 00000000 c0a0068c 00000000 c0a3ba28 c0b3b614 c0b034c0
[42059.616330] 1fe0: c0a3ba24 c0b0a3a8 00004059 561f5811 00000000 0000807c 00000000 00000000
[42059.624586] [<bf07bec4>] (ath_cmn_process_fft [ath9k_common]) from [<bf08a9d0>] (ath_rx_tasklet+0x47c/0xb20 [ath9k])
[42059.635176] [<bf08a9d0>] (ath_rx_tasklet [ath9k]) from [<bf088810>] (ath9k_tasklet+0x1dc/0x218 [ath9k])
[42059.644631] [<bf088810>] (ath9k_tasklet [ath9k]) from [<c0126b88>] (tasklet_action+0x74/0x110)
[42059.653288] [<c0126b88>] (tasklet_action) from [<c0126d74>] (__do_softirq+0xfc/0x218)
[42059.661157] [<c0126d74>] (__do_softirq) from [<c0127120>] (irq_exit+0x7c/0xb4)
[42059.668423] [<c0127120>] (irq_exit) from [<c01635e4>] (__handle_domain_irq+0x60/0xb4)
[42059.676295] [<c01635e4>] (__handle_domain_irq) from [<c010145c>] (armada_370_xp_handle_irq+0x48/0xa8)
[42059.685559] [<c010145c>] (armada_370_xp_handle_irq) from [<c010bd8c>] (__irq_svc+0x6c/0x90)
[42059.693946] Exception stack(0xc0b01f30 to 0xc0b01f78)
[42059.699021] 1f20: 00000000 00002640 1f194000 dfbe31c0
[42059.707237] 1f40: b1708859 00002640 dfbe2590 00000001 006895c7 00002640 00000000 c0b03524
[42059.715453] 1f60: 0d5e8652 c0b01f80 c04b7310 c04b7318 20000153 ffffffff
[42059.722107] [<c010bd8c>] (__irq_svc) from [<c04b7318>] (cpuidle_enter_state+0x18c/0x2b4)
[42059.730247] [<c04b7318>] (cpuidle_enter_state) from [<c015a240>] (cpu_startup_entry+0x17c/0x220)
[42059.739081] [<c015a240>] (cpu_startup_entry) from [<c0a00c54>] (start_kernel+0x368/0x374)
[42059.747299] Code: e5933000 e1d330b4 e58d3030 ea000002 (e7970102)
[42059.753488] ---[ end trace d9b5665c4c165fb1 ]---
[42059.758151] Kernel panic - not syncing: Fatal exception in interrupt
[42059.764541] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
----------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCHv3,1/2] ath10k: add per peer htt tx stats support for 10.4
From: Kalle Valo @ 2016-11-23 19:40 UTC (permalink / raw)
To: akolli; +Cc: ath10k, Anilkumar Kolli, akolli, linux-wireless
In-Reply-To: <1479227849-10042-1-git-send-email-akolli@qti.qualcomm.com>
akolli@qti.qualcomm.com wrote:
> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>
> Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
> event, Firmware sends one HTT event for every four PPDUs.
> HTT payload has success pkts/bytes, failed pkts/bytes, retry
> pkts/bytes and rate info per ppdu.
> Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
> which are nowadays enabled by default.
>
> Parse peer stats and update the tx rate information per STA.
>
> tx rate, Peer stats are tested on QCA4019 with Firmware version
> 10.4-3.2.1-00028.
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
2 patches applied to ath-next branch of ath.git, thanks.
cec17c382140 ath10k: add per peer htt tx stats support for 10.4
5608eaf7b086 ath10k: add support for per sta tx bitrate
--
https://patchwork.kernel.org/patch/9430197/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: fix monitor vdev for receiving other bss frames
From: Kalle Valo @ 2016-11-23 19:42 UTC (permalink / raw)
To: Manoharan, Rajkumar; +Cc: ath10k, linux-wireless, Rajkumar Manoharan, rmanohar
In-Reply-To: <1479510658-8326-1-git-send-email-rmanohar@qca.qualcomm.com>
"Manoharan, Rajkumar" <rmanohar@qca.qualcomm.com> wrote:
> In order to receive other BSS entries in mesh mode, Monitor vdev
> is created whenever filter flag is set with OTHER_BSS. Recently
> it is root caused that setting promisc filter for Mesh interface
> is causing performance and stability issues. To fix this issue,
> firmware will configure appropriate rxfilters by default for mesh
> vdev during vdev creation. This change fixes monitor vdev creation
> based on firmware IE
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
705d7aa06220 ath10k: fix monitor vdev for receiving other bss frames
--
https://patchwork.kernel.org/patch/9437519/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 19:34 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Andrew Lunn
In-Reply-To: <87a8cqgfpp.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
On Wed, Nov 23, 2016 at 09:26:42PM +0200, Kalle Valo wrote:
> Jason Cooper <jason@lakedaemon.net> writes:
> > I have a Ubiquiti SR-71 mini-pcie ath9k card in a Globalscale Mirabox
> > board (Marvell Armada 370 SoC). Every day or so I get a consistent
> > crash that brings down the whole board. I've attached three oops I
> > captured on the serial port.
> >
> > I looked at the commits from v4.8.6 to v4.9-rc6, and nothing jumped out
> > at me as "this would fix it". And since it takes a day or so to trigger
> > the oops, bisecting would be a bit brutal. Does anyone have any insight
> > into this?
>
> Is this a regression, meaning that it didn't crash on older kernels but
> crashes on newer ones? Or has it always crashed?
iirc, it's always done this. It's one of my spare wifi backhauls that
spends most of it's time in a cardboard box waiting for a task,
collecting dust. Kinda like the toys in Toy Story.
I pulled it out a month or so ago and the behavior started. It had
4.2.8 on it at the time. I upgraded to latest stable a few weeks ago
(v4.8.6) and I'm getting the same issue.
When I originally set it up, it didn't run long enough for me to recall
if the issue occurred. Best I recall, that was with v4.2.8.
thx,
Jason.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Russell King - ARM Linux @ 2016-11-23 19:51 UTC (permalink / raw)
To: Jason Cooper
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123191539.GF2799@io.lakedaemon.net>
On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> ------- oops from v4.8.6 #2 ------------------------------------------
> [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> [42059.311799] pgd = c0004000
> [42059.314522] [00000020] *pgd=00000000
> [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> [42059.340613] task: c0b091c0 task.stack: c0b00000
> [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
Well, the good news is that it's reproducable.
It looks like it could be this:
static int
ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
{
for_each_online_cpu(i)
ret += relay_buf_full(rc->buf[i]);
where i = 8 (r2) and rc->buf is r7. That's just a guess though, as
there's precious little to go on with the Code: line - modern GCCs
don't give us much with the Code: line anymore to figure out what's
going on without the exact object files.
e5933000 ldr r3, [r3]
e1d330b4 ldrh r3, [r3, #4]
e58d3030 str r3, [sp, #48] ; 0x30
ea000002 b 1c <foo+0x1c>
e7970102 ldr r0, [r7, r2, lsl #2]
What makes me wonder though is that if i=8, that means you must have a
system with 9 online CPUs, which is probably unlikely - or maybe that's
the problem, for_each_online_cpu() is going wrong...
If it's not that line of code, I don't see what else it would be based
on the output of my compiler - there's only one case in my disassembly
that corresponds with the single code line that we have to go on, and
it's this:
a44: e5983020 ldr r3, [r8, #32]
a48: e793010a ldr r0, [r3, sl, lsl #2] <===
a4c: ebfffffe bl 0 <relay_buf_full>
a50: e0844000 add r4, r4, r0
a54: e59f9434 ldr r9, [pc, #1076]
a58: e28a2001 add r2, sl, #1
a5c: e3a01004 mov r1, #4
a60: e1a00009 mov r0, r9
a64: ebfffffe bl 0 <_find_next_bit_le>
a68: e5953000 ldr r3, [r5]
a6c: e1500003 cmp r0, r3
a70: e1a0a000 mov sl, r0
a74: bafffff2 blt a44 <ath_cmn_process_fft+0xa8>
I'm debating now about whether we need to dump more of the code in the
oops - both before and after the faulting instruction...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 20:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123195120.GE14217@n2100.armlinux.org.uk>
Hi Russell,
On Wed, Nov 23, 2016 at 07:51:20PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> > ------- oops from v4.8.6 #2 ------------------------------------------
> > [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> > [42059.311799] pgd = c0004000
> > [42059.314522] [00000020] *pgd=00000000
> > [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> > [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> > [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> > [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> > [42059.340613] task: c0b091c0 task.stack: c0b00000
> > [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> > [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> > [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> > [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> > [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> > [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> > [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
>
> Well, the good news is that it's reproducable.
>
> It looks like it could be this:
>
> static int
> ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
> {
> for_each_online_cpu(i)
> ret += relay_buf_full(rc->buf[i]);
ahhh, my config has NR_CPUS=4, this SoC is uniprocessor. I'm going to
give it a go with SMP=no. This config is a lightly modified
mvebu_v7_defconfig. However, NR_CPUS isn't set in mvebu_v7_defconfig.
Only in multi_v7_defconfig.
I suspect ath9k uses different logic for setting up the relay buffer(s)
than for the code you referenced.
If SMP=no fails to fail ( :-P ) then we'll know where to start digging.
thx,
Jason.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 20:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123195120.GE14217@n2100.armlinux.org.uk>
On Wed, Nov 23, 2016 at 07:51:20PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 07:15:39PM +0000, Jason Cooper wrote:
> > ------- oops from v4.8.6 #2 ------------------------------------------
> > [42059.303625] Unable to handle kernel NULL pointer dereference at virtual address 00000020
> > [42059.311799] pgd = c0004000
> > [42059.314522] [00000020] *pgd=00000000
> > [42059.318162] Internal error: Oops: 17 [#1] SMP ARM
> > [42059.322889] Modules linked in: ath9k ath9k_common ath9k_hw ath
> > [42059.328809] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6 #37
> > [42059.334755] Hardware name: Marvell Armada 370/XP (Device Tree)
> > [42059.340613] task: c0b091c0 task.stack: c0b00000
> > [42059.345176] PC is at ath_cmn_process_fft+0xa0/0x578 [ath9k_common]
> > [42059.351388] LR is at ath_cmn_process_fft+0xc4/0x578 [ath9k_common]
> > [42059.357598] pc : [<bf07bec4>] lr : [<bf07bee8>] psr: 80000153
> > [42059.357598] sp : c0b01cd0 ip : 00000000 fp : 00000000
> > [42059.369127] r10: c0b034d4 r9 : 00000069 r8 : 0000006c
> > [42059.374374] r7 : 00000000 r6 : dcfbd340 r5 : c0b03da0 r4 : 00000000
> > [42059.380930] r3 : 00000001 r2 : 00000008 r1 : 00000004 r0 : 00000000
>
> Well, the good news is that it's reproducable.
>
> It looks like it could be this:
>
> static int
> ath_cmn_is_fft_buf_full(struct ath_spec_scan_priv *spec_priv)
> {
> for_each_online_cpu(i)
> ret += relay_buf_full(rc->buf[i]);
>
> where i = 8 (r2) and rc->buf is r7. That's just a guess though, as
> there's precious little to go on with the Code: line - modern GCCs
> don't give us much with the Code: line anymore to figure out what's
> going on without the exact object files.
>
> e5933000 ldr r3, [r3]
> e1d330b4 ldrh r3, [r3, #4]
> e58d3030 str r3, [sp, #48] ; 0x30
> ea000002 b 1c <foo+0x1c>
> e7970102 ldr r0, [r7, r2, lsl #2]
>
As requested on irc:
-------------->8--------------------------------------------------------
drivers/net/wireless/ath/ath9k/common-spectral.o: file format elf32-littlearm
Disassembly of section .text:
...
00000754 <ath_cmn_process_fft>:
754: e92d4ff0 push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
758: e24dd0d4 sub sp, sp, #212 ; 0xd4
75c: e1a04002 mov r4, r2
760: e1a06001 mov r6, r1
764: e58d0024 str r0, [sp, #36] ; 0x24
768: e3a01000 mov r1, #0
76c: e58d2018 str r2, [sp, #24]
770: e28d0049 add r0, sp, #73 ; 0x49
774: e3a02087 mov r2, #135 ; 0x87
778: ebfffffe bl 0 <memset>
77c: e5d44007 ldrb r4, [r4, #7]
780: e20430fd and r3, r4, #253 ; 0xfd
784: e3530024 cmp r3, #36 ; 0x24
788: 13540005 cmpne r4, #5
78c: 13a04001 movne r4, #1
790: 03a04000 moveq r4, #0
794: 13a00000 movne r0, #0
798: 0a000001 beq 7a4 <ath_cmn_process_fft+0x50>
79c: e28dd0d4 add sp, sp, #212 ; 0xd4
7a0: e8bd8ff0 pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
7a4: e59d3018 ldr r3, [sp, #24]
7a8: e1d380b4 ldrh r8, [r3, #4]
7ac: e2489003 sub r9, r8, #3
7b0: e0863009 add r3, r6, r9
7b4: e5d30002 ldrb r0, [r3, #2]
7b8: e2000010 and r0, r0, #16
7bc: e21000ff ands r0, r0, #255 ; 0xff
7c0: 0afffff5 beq 79c <ath_cmn_process_fft+0x48>
7c4: e59d3024 ldr r3, [sp, #36] ; 0x24
7c8: e3005000 movw r5, #0
7cc: e3405000 movt r5, #0
7d0: e3e0b000 mvn fp, #0
7d4: e5932000 ldr r2, [r3]
7d8: e5937004 ldr r7, [r3, #4]
7dc: e5923438 ldr r3, [r2, #1080] ; 0x438
7e0: e58d2010 str r2, [sp, #16]
7e4: e5933000 ldr r3, [r3]
7e8: e1d330b4 ldrh r3, [r3, #4]
7ec: e58d3030 str r3, [sp, #48] ; 0x30
7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
7f4: e7970102 ldr r0, [r7, r2, lsl #2]
7f8: ebfffffe bl 0 <relay_buf_full>
7fc: e0844000 add r4, r4, r0
800: e300a000 movw sl, #0
804: e28b2001 add r2, fp, #1
808: e340a000 movt sl, #0
80c: e3a01004 mov r1, #4
810: e1a0000a mov r0, sl
814: ebfffffe bl 0 <_find_next_bit_le>
818: e5953000 ldr r3, [r5]
81c: e1500003 cmp r0, r3
820: e1a0b000 mov fp, r0
824: e2802008 add r2, r0, #8
828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
82c: e59a0000 ldr r0, [sl]
830: e200000f and r0, r0, #15
834: ebfffffe bl 0 <__sw_hweight32>
838: e1540000 cmp r4, r0
83c: 0a000092 beq a8c <ath_cmn_process_fft+0x338>
840: e59d3010 ldr r3, [sp, #16]
844: e5932030 ldr r2, [r3, #48] ; 0x30
848: e5923018 ldr r3, [r2, #24]
84c: e3530001 cmp r3, #1
850: 0a000090 beq a98 <ath_cmn_process_fft+0x344>
854: 3a000119 bcc cc0 <ath_cmn_process_fft+0x56c>
858: e3530002 cmp r3, #2
85c: 1a000110 bne ca4 <ath_cmn_process_fft+0x550>
860: e3003000 movw r3, #0
864: e5921014 ldr r1, [r2, #20]
868: e1a00003 mov r0, r3
86c: e592301c ldr r3, [r2, #28]
870: e3002000 movw r2, #0
874: e3a0b087 mov fp, #135 ; 0x87
878: e1a0c002 mov ip, r2
87c: e1a02000 mov r2, r0
880: e3402000 movt r2, #0
884: e58d2034 str r2, [sp, #52] ; 0x34
888: e1a0200c mov r2, ip
88c: e3a0a08a mov sl, #138 ; 0x8a
890: e3402000 movt r2, #0
894: e58d2044 str r2, [sp, #68] ; 0x44
898: e1d120b4 ldrh r2, [r1, #4]
89c: e3a01080 mov r1, #128 ; 0x80
8a0: e58d1020 str r1, [sp, #32]
8a4: e1520003 cmp r2, r3
8a8: 33a03003 movcc r3, #3
8ac: 23a03002 movcs r3, #2
8b0: e58d3038 str r3, [sp, #56] ; 0x38
8b4: e2483002 sub r3, r8, #2
8b8: e58d3014 str r3, [sp, #20]
8bc: e3530000 cmp r3, #0
8c0: da000071 ble a8c <ath_cmn_process_fft+0x338>
8c4: e3a03000 mov r3, #0
8c8: e28aa002 add sl, sl, #2
8cc: e1a04003 mov r4, r3
8d0: e58d3028 str r3, [sp, #40] ; 0x28
8d4: e1a05004 mov r5, r4
8d8: e24b3001 sub r3, fp, #1
8dc: e1a07006 mov r7, r6
8e0: e58d302c str r3, [sp, #44] ; 0x2c
8e4: e58db01c str fp, [sp, #28]
8e8: e1a03009 mov r3, r9
8ec: e58d8010 str r8, [sp, #16]
8f0: e1a09004 mov r9, r4
8f4: ea00002c b 9ac <ath_cmn_process_fft+0x258>
8f8: e3520007 cmp r2, #7
8fc: e1a05003 mov r5, r3
900: e086b004 add fp, r6, r4
904: 8a00006f bhi ac8 <ath_cmn_process_fft+0x374>
908: e59d202c ldr r2, [sp, #44] ; 0x2c
90c: e1530002 cmp r3, r2
910: a3a09001 movge r9, #1
914: ba0000dd blt c90 <ath_cmn_process_fft+0x53c>
918: e59d101c ldr r1, [sp, #28]
91c: e2812002 add r2, r1, #2
920: e1520005 cmp r2, r5
924: ba000058 blt a8c <ath_cmn_process_fft+0x338>
928: e1510005 cmp r1, r5
92c: aa000092 bge b7c <ath_cmn_process_fft+0x428>
930: e5d7001f ldrb r0, [r7, #31]
934: e5d71020 ldrb r1, [r7, #32]
938: e1500001 cmp r0, r1
93c: 1a000052 bne a8c <ath_cmn_process_fft+0x338>
940: e58d3040 str r3, [sp, #64] ; 0x40
944: e1a01004 mov r1, r4
948: e59d3044 ldr r3, [sp, #68] ; 0x44
94c: e1a0000b mov r0, fp
950: e58d203c str r2, [sp, #60] ; 0x3c
954: e12fff33 blx r3
958: e3500000 cmp r0, #0
95c: e59d203c ldr r2, [sp, #60] ; 0x3c
960: e59d3040 ldr r3, [sp, #64] ; 0x40
964: 1a00008e bne ba4 <ath_cmn_process_fft+0x450>
968: e59d2010 ldr r2, [sp, #16]
96c: e152000a cmp r2, sl
970: da0000c9 ble c9c <ath_cmn_process_fft+0x548>
974: e59d9028 ldr r9, [sp, #40] ; 0x28
978: e2842001 add r2, r4, #1
97c: e0867002 add r7, r6, r2
980: e3590000 cmp r9, #0
984: 13a09000 movne r9, #0
988: 1a000003 bne 99c <ath_cmn_process_fft+0x248>
98c: e59d2020 ldr r2, [sp, #32]
990: e2425002 sub r5, r2, #2
994: e0844005 add r4, r4, r5
998: e2842001 add r2, r4, #1
99c: e1a04002 mov r4, r2
9a0: e59d2014 ldr r2, [sp, #20]
9a4: e1540002 cmp r4, r2
9a8: aa000037 bge a8c <ath_cmn_process_fft+0x338>
9ac: e59d2010 ldr r2, [sp, #16]
9b0: e152000a cmp r2, sl
9b4: e7d62004 ldrb r2, [r6, r4]
9b8: daffffce ble 8f8 <ath_cmn_process_fft+0x1a4>
9bc: e3520007 cmp r2, #7
9c0: e2855001 add r5, r5, #1
9c4: e086b004 add fp, r6, r4
9c8: 8a000002 bhi 9d8 <ath_cmn_process_fft+0x284>
9cc: e59d202c ldr r2, [sp, #44] ; 0x2c
9d0: e1550002 cmp r5, r2
9d4: aaffffcf bge 918 <ath_cmn_process_fft+0x1c4>
9d8: e3590000 cmp r9, #0
9dc: 0affffed beq 998 <ath_cmn_process_fft+0x244>
9e0: e59d201c ldr r2, [sp, #28]
9e4: e1520005 cmp r2, r5
9e8: 1affffe1 bne 974 <ath_cmn_process_fft+0x220>
9ec: ea00007e b bec <ath_cmn_process_fft+0x498>
9f0: e597e000 ldr lr, [r7]
9f4: e24b201f sub r2, fp, #31
9f8: e597c004 ldr ip, [r7, #4]
9fc: e2871021 add r1, r7, #33 ; 0x21
a00: e5973008 ldr r3, [r7, #8]
a04: e28d0068 add r0, sp, #104 ; 0x68
a08: e58de049 str lr, [sp, #73] ; 0x49
a0c: e58dc04d str ip, [sp, #77] ; 0x4d
a10: e597e010 ldr lr, [r7, #16]
a14: e597c014 ldr ip, [r7, #20]
a18: e58d3051 str r3, [sp, #81] ; 0x51
a1c: e597300c ldr r3, [r7, #12]
a20: e58de059 str lr, [sp, #89] ; 0x59
a24: e58dc05d str ip, [sp, #93] ; 0x5d
a28: e58d3055 str r3, [sp, #85] ; 0x55
a2c: e1d7c1bc ldrh ip, [r7, #28]
a30: e5973018 ldr r3, [r7, #24]
a34: e5d7e01f ldrb lr, [r7, #31]
a38: e1cdc6b5 strh ip, [sp, #101] ; 0x65
a3c: e58d3061 str r3, [sp, #97] ; 0x61
a40: e5cde067 strb lr, [sp, #103] ; 0x67
a44: ebfffffe bl 0 <memcpy>
a48: e59d3038 ldr r3, [sp, #56] ; 0x38
a4c: e59d1024 ldr r1, [sp, #36] ; 0x24
a50: e59d0018 ldr r0, [sp, #24]
a54: e58d300c str r3, [sp, #12]
a58: e59d3030 ldr r3, [sp, #48] ; 0x30
a5c: e58d3008 str r3, [sp, #8]
a60: e1cd2fd8 ldrd r2, [sp, #248] ; 0xf8
a64: e1cd20f0 strd r2, [sp]
a68: e28d2049 add r2, sp, #73 ; 0x49
a6c: e59d3034 ldr r3, [sp, #52] ; 0x34
a70: e12fff33 blx r3
a74: e3a01087 mov r1, #135 ; 0x87
a78: e28d0049 add r0, sp, #73 ; 0x49
a7c: ebfffffe bl 0 <__memzero>
a80: e59d1020 ldr r1, [sp, #32]
a84: e28d0049 add r0, sp, #73 ; 0x49
a88: ebfffffe bl 0 <add_device_randomness>
a8c: e3a00001 mov r0, #1
a90: e28dd0d4 add sp, sp, #212 ; 0xd4
a94: e8bd8ff0 pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
a98: e58d3038 str r3, [sp, #56] ; 0x38
a9c: e3003000 movw r3, #0
aa0: e3002000 movw r2, #0
aa4: e3403000 movt r3, #0
aa8: e3402000 movt r2, #0
aac: e58d3034 str r3, [sp, #52] ; 0x34
ab0: e3a0b03c mov fp, #60 ; 0x3c
ab4: e3a03038 mov r3, #56 ; 0x38
ab8: e58d2044 str r2, [sp, #68] ; 0x44
abc: e3a0a03f mov sl, #63 ; 0x3f
ac0: e58d3020 str r3, [sp, #32]
ac4: eaffff7a b 8b4 <ath_cmn_process_fft+0x160>
ac8: e59db01c ldr fp, [sp, #28]
acc: e153000b cmp r3, fp
ad0: 0a00005e beq c50 <ath_cmn_process_fft+0x4fc>
ad4: e06b5005 rsb r5, fp, r5
ad8: e2855001 add r5, r5, #1
adc: e3550003 cmp r5, #3
ae0: 979ff105 ldrls pc, [pc, r5, lsl #2]
ae4: eaffffd7 b a48 <ath_cmn_process_fft+0x2f4>
ae8: 00000b0c andeq r0, r0, ip, lsl #22
aec: 00000af8 strdeq r0, [r0], -r8
af0: 00000b20 andeq r0, r0, r0, lsr #22
af4: 000009f0 strdeq r0, [r0], -r0 ; <UNPREDICTABLE>
af8: e1a0200b mov r2, fp
afc: e1a01007 mov r1, r7
b00: e28d0049 add r0, sp, #73 ; 0x49
b04: ebfffffe bl 0 <memcpy>
b08: eaffffce b a48 <ath_cmn_process_fft+0x2f4>
b0c: e24b2001 sub r2, fp, #1
b10: e1a01007 mov r1, r7
b14: e28d004a add r0, sp, #74 ; 0x4a
b18: ebfffffe bl 0 <memcpy>
b1c: eaffffc9 b a48 <ath_cmn_process_fft+0x2f4>
b20: e597e000 ldr lr, [r7]
b24: e24b2020 sub r2, fp, #32
b28: e597c004 ldr ip, [r7, #4]
b2c: e2871021 add r1, r7, #33 ; 0x21
b30: e5973008 ldr r3, [r7, #8]
b34: e28d0069 add r0, sp, #105 ; 0x69
b38: e58de04a str lr, [sp, #74] ; 0x4a
b3c: e58dc04e str ip, [sp, #78] ; 0x4e
b40: e597e010 ldr lr, [r7, #16]
b44: e597c014 ldr ip, [r7, #20]
b48: e58d3052 str r3, [sp, #82] ; 0x52
b4c: e597300c ldr r3, [r7, #12]
b50: e58de05a str lr, [sp, #90] ; 0x5a
b54: e58dc05e str ip, [sp, #94] ; 0x5e
b58: e5d7e01f ldrb lr, [r7, #31]
b5c: e1d7c1bc ldrh ip, [r7, #28]
b60: e58d3056 str r3, [sp, #86] ; 0x56
b64: e5973018 ldr r3, [r7, #24]
b68: e1cdc6b6 strh ip, [sp, #102] ; 0x66
b6c: e5cde068 strb lr, [sp, #104] ; 0x68
b70: e58d3062 str r3, [sp, #98] ; 0x62
b74: ebfffffe bl 0 <memcpy>
b78: eaffffb2 b a48 <ath_cmn_process_fft+0x2f4>
b7c: e58d3040 str r3, [sp, #64] ; 0x40
b80: e1a01004 mov r1, r4
b84: e59d3044 ldr r3, [sp, #68] ; 0x44
b88: e1a0000b mov r0, fp
b8c: e58d203c str r2, [sp, #60] ; 0x3c
b90: e12fff33 blx r3
b94: e3500000 cmp r0, #0
b98: e59d203c ldr r2, [sp, #60] ; 0x3c
b9c: e59d3040 ldr r3, [sp, #64] ; 0x40
ba0: 0a00000e beq be0 <ath_cmn_process_fft+0x48c>
ba4: e5d7101f ldrb r1, [r7, #31]
ba8: e5d70020 ldrb r0, [r7, #32]
bac: e59dc01c ldr ip, [sp, #28]
bb0: e15c0005 cmp ip, r5
bb4: d1510000 cmple r1, r0
bb8: 03a01001 moveq r1, #1
bbc: 13a01000 movne r1, #0
bc0: e1520005 cmp r2, r5
bc4: d3a02000 movle r2, #0
bc8: c2012001 andgt r2, r1, #1
bcc: e3520000 cmp r2, #0
bd0: 0a00001a beq c40 <ath_cmn_process_fft+0x4ec>
bd4: e5db2001 ldrb r2, [fp, #1]
bd8: e3520007 cmp r2, #7
bdc: 9affff6d bls 998 <ath_cmn_process_fft+0x244>
be0: e59d201c ldr r2, [sp, #28]
be4: e1520005 cmp r2, r5
be8: 1affff5e bne 968 <ath_cmn_process_fft+0x214>
bec: e58d303c str r3, [sp, #60] ; 0x3c
bf0: e1a02007 mov r2, r7
bf4: e59d3038 ldr r3, [sp, #56] ; 0x38
bf8: e1cd8fd8 ldrd r8, [sp, #248] ; 0xf8
bfc: e59d1024 ldr r1, [sp, #36] ; 0x24
c00: e58d300c str r3, [sp, #12]
c04: e59d3030 ldr r3, [sp, #48] ; 0x30
c08: e1cd80f0 strd r8, [sp]
c0c: e59d0018 ldr r0, [sp, #24]
c10: e58d3008 str r3, [sp, #8]
c14: e59d3034 ldr r3, [sp, #52] ; 0x34
c18: e12fff33 blx r3
c1c: e58d0028 str r0, [sp, #40] ; 0x28
c20: e1a00007 mov r0, r7
c24: e59d1020 ldr r1, [sp, #32]
c28: ebfffffe bl 0 <add_device_randomness>
c2c: e59d3010 ldr r3, [sp, #16]
c30: e153000a cmp r3, sl
c34: e59d303c ldr r3, [sp, #60] ; 0x3c
c38: caffff4d bgt 974 <ath_cmn_process_fft+0x220>
c3c: eaffff92 b a8c <ath_cmn_process_fft+0x338>
c40: e59d202c ldr r2, [sp, #44] ; 0x2c
c44: e1520005 cmp r2, r5
c48: 1affffe4 bne be0 <ath_cmn_process_fft+0x48c>
c4c: eaffffe0 b bd4 <ath_cmn_process_fft+0x480>
c50: e59d3038 ldr r3, [sp, #56] ; 0x38
c54: e59d1024 ldr r1, [sp, #36] ; 0x24
c58: e59d0018 ldr r0, [sp, #24]
c5c: e58d300c str r3, [sp, #12]
c60: e59d3030 ldr r3, [sp, #48] ; 0x30
c64: e58d3008 str r3, [sp, #8]
c68: e1cd2fd8 ldrd r2, [sp, #248] ; 0xf8
c6c: e1cd20f0 strd r2, [sp]
c70: e1a02007 mov r2, r7
c74: e59d3034 ldr r3, [sp, #52] ; 0x34
c78: e12fff33 blx r3
c7c: e1a00007 mov r0, r7
c80: e59d1020 ldr r1, [sp, #32]
c84: ebfffffe bl 0 <add_device_randomness>
c88: e3a00001 mov r0, #1
c8c: eaffff7f b a90 <ath_cmn_process_fft+0x33c>
c90: e59d201c ldr r2, [sp, #28]
c94: e1530002 cmp r3, r2
c98: 0affffd3 beq bec <ath_cmn_process_fft+0x498>
c9c: e59db01c ldr fp, [sp, #28]
ca0: eaffff8b b ad4 <ath_cmn_process_fft+0x380>
ca4: e3000000 movw r0, #0
ca8: e300119a movw r1, #410 ; 0x19a
cac: e3400000 movt r0, #0
cb0: e3a03000 mov r3, #0
cb4: e58d3038 str r3, [sp, #56] ; 0x38
cb8: ebfffffe bl 0 <warn_slowpath_null>
cbc: eaffff76 b a9c <ath_cmn_process_fft+0x348>
cc0: e3a03000 mov r3, #0
cc4: e58d3038 str r3, [sp, #56] ; 0x38
cc8: eaffff73 b a9c <ath_cmn_process_fft+0x348>
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Russell King - ARM Linux @ 2016-11-23 21:17 UTC (permalink / raw)
To: Jason Cooper
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123205917.GI2799@io.lakedaemon.net>
On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:
> As requested on irc:
Thanks.
> 7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
> 7f4: e7970102 ldr r0, [r7, r2, lsl #2]
> 7f8: ebfffffe bl 0 <relay_buf_full>
> 7fc: e0844000 add r4, r4, r0
> 800: e300a000 movw sl, #0
> 804: e28b2001 add r2, fp, #1
> 808: e340a000 movt sl, #0
> 80c: e3a01004 mov r1, #4
> 810: e1a0000a mov r0, sl
> 814: ebfffffe bl 0 <_find_next_bit_le>
> 818: e5953000 ldr r3, [r5]
> 81c: e1500003 cmp r0, r3
> 820: e1a0b000 mov fp, r0
> 824: e2802008 add r2, r0, #8
> 828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
Okay, so i was 0, so running UP probably isn't going to help. r7 is
also spec_priv->rfs_chan_spec_scan.
So, I think the question is... how is this NULL - and has it always
been NULL...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: Jason Cooper @ 2016-11-23 21:40 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-wireless, Linux ARM Kernel, ath9k-devel, ath9k-devel,
Thomas Petazzoni, Gregory CLEMENT, Kalle Valo, Andrew Lunn
In-Reply-To: <20161123211745.GF14217@n2100.armlinux.org.uk>
On Wed, Nov 23, 2016 at 09:17:45PM +0000, Russell King - ARM Linux wrote:
> On Wed, Nov 23, 2016 at 08:59:17PM +0000, Jason Cooper wrote:
> > As requested on irc:
>
> Thanks.
>
> > 7f0: ea000002 b 800 <ath_cmn_process_fft+0xac>
> > 7f4: e7970102 ldr r0, [r7, r2, lsl #2]
> > 7f8: ebfffffe bl 0 <relay_buf_full>
> > 7fc: e0844000 add r4, r4, r0
> > 800: e300a000 movw sl, #0
> > 804: e28b2001 add r2, fp, #1
> > 808: e340a000 movt sl, #0
> > 80c: e3a01004 mov r1, #4
> > 810: e1a0000a mov r0, sl
> > 814: ebfffffe bl 0 <_find_next_bit_le>
> > 818: e5953000 ldr r3, [r5]
> > 81c: e1500003 cmp r0, r3
> > 820: e1a0b000 mov fp, r0
> > 824: e2802008 add r2, r0, #8
> > 828: bafffff1 blt 7f4 <ath_cmn_process_fft+0xa0>
>
> Okay, so i was 0, so running UP probably isn't going to help. r7 is
> also spec_priv->rfs_chan_spec_scan.
>
> So, I think the question is... how is this NULL - and has it always
> been NULL...
The problem appears to be that ath_cmn_process_fft() isn't called that
often. When it is, it crashes in ath_cmn_is_fft_buf_full() because
spec_priv->rfs_chan_spec_scan is NULL when ATH9K_DEBUGFS=n. :-(
I'm running with ATH9K_DEBUGFS=y now. If it goes a couple of days
without crashing, I'll gin up a patch.
thx,
Jason.
^ permalink raw reply
* [PATCH 1/2] nl80211: Use different attrs for BSSID and random MAC addr in scan req
From: Jouni Malinen @ 2016-11-23 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Vamsi Krishna, Jouni Malinen
From: Vamsi Krishna <vamsin@qti.qualcomm.com>
NL80211_ATTR_MAC was used to set both the specific BSSID to be scanned
and the random MAC address to be used when privacy is enabled. When both
the features are enabled, both the BSSID and the local MAC address were
getting same value causing Probe Request frames to go with unintended
DA. Hence, this has been fixed by using a different NL80211_ATTR_BSSID
attribute to set the specific BSSID (which was the more recent addition
in cfg80211) for a scan.
Backwards compatibility with old userspace software is maintained to
some extend by allowing NL80211_ATTR_MAC to be used to set the specific
BSSID when scanning without enabling random MAC address use.
Scanning with random source MAC address was introduced by commit
ad2b26abc157 ("cfg80211: allow drivers to support random MAC addresses
for scan") and the issue was introduced with the addition of the second
user for the same attribute in commit 818965d39177 ("cfg80211: Allow a
scan request for a specific BSSID").
Fixes: 818965d39177 ("cfg80211: Allow a scan request for a specific BSSID")
Signed-off-by: Vamsi Krishna <vamsin@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
include/uapi/linux/nl80211.h | 8 +++++++-
net/wireless/nl80211.c | 16 +++++++++++++++-
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 259c9c7..984a35ac 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -323,7 +323,7 @@
* @NL80211_CMD_GET_SCAN: get scan results
* @NL80211_CMD_TRIGGER_SCAN: trigger a new scan with the given parameters
* %NL80211_ATTR_TX_NO_CCK_RATE is used to decide whether to send the
- * probe requests at CCK rate or not. %NL80211_ATTR_MAC can be used to
+ * probe requests at CCK rate or not. %NL80211_ATTR_BSSID can be used to
* specify a BSSID to scan for; if not included, the wildcard BSSID will
* be used.
* @NL80211_CMD_NEW_SCAN_RESULTS: scan notification (as a reply to
@@ -1977,6 +1977,10 @@ enum nl80211_commands {
* @NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED: Indicates whether or not multicast
* packets should be send out as unicast to all stations (flag attribute).
*
+ * @NL80211_ATTR_BSSID: The BSSID of the AP (various uses). Note that
+ * %NL80211_ATTR_MAC has also been used in various commands/events for
+ * specifying the BSSID.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2381,6 +2385,8 @@ enum nl80211_attrs {
NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED,
+ NL80211_ATTR_BSSID,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e4f718e..8db5cb1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -404,6 +404,7 @@ enum nl80211_multicast_groups {
.len = FILS_MAX_KEK_LEN },
[NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
[NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
+ [NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
};
/* policy for the key attributes */
@@ -6703,7 +6704,20 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
request->no_cck =
nla_get_flag(info->attrs[NL80211_ATTR_TX_NO_CCK_RATE]);
- if (info->attrs[NL80211_ATTR_MAC])
+ /* Initial implementation used NL80211_ATTR_MAC to set the specific
+ * BSSID to scan for. This was problematic because that same attribute
+ * was already used for another purpose (local random MAC address). The
+ * NL80211_ATTR_BSSID attribute was added to fix this. For backwards
+ * compatibility with older userspace components, also use the
+ * NL80211_ATTR_MAC value here if it can be determined to be used for
+ * the specific BSSID use case instead of the random MAC address
+ * (NL80211_ATTR_SCAN_FLAGS is used to enable random MAC address use).
+ */
+ if (info->attrs[NL80211_ATTR_BSSID])
+ memcpy(request->bssid,
+ nla_data(info->attrs[NL80211_ATTR_BSSID]), ETH_ALEN);
+ else if (!info->attrs[NL80211_ATTR_SCAN_FLAGS] &&
+ info->attrs[NL80211_ATTR_MAC])
memcpy(request->bssid, nla_data(info->attrs[NL80211_ATTR_MAC]),
ETH_ALEN);
else
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Jouni Malinen @ 2016-11-23 22:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, vamsi krishna, Jouni Malinen
In-Reply-To: <1479938857-1788-1-git-send-email-jouni@qca.qualcomm.com>
From: vamsi krishna <vamsin@qti.qualcomm.com>
Enhance sched scan to support option of finding a better BSS while in
connected state. Firmware scans the medium and reports when it finds a
known BSS which has a significantly better RSSI than the current
connected BSS.
Signed-off-by: vamsi krishna <vamsin@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
---
include/net/cfg80211.h | 17 +++++++++++++++++
include/uapi/linux/nl80211.h | 17 +++++++++++++++++
net/wireless/nl80211.c | 32 ++++++++++++++++++++++++++++++--
3 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ef42749..c62c42a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1626,6 +1626,20 @@ struct cfg80211_sched_scan_plan {
* cycle. The driver may ignore this parameter and start
* immediately (or at any other time), if this feature is not
* supported.
+ * @relative_rssi: Relative RSSI threshold to restrict scan result reporting in
+ * connected state to cases where a matching BSS is determined to have a
+ * significantly better RSSI than the current connected BSS.
+ * @relative_rssi_5g_pref: The amount of RSSI preference that is given to a
+ * 5 GHz BSS over 2.4 GHz BSS while looking for better BSSs in connected
+ * state.
+ * If the current connected BSS is in the 2.4 GHz band, other BSSs in the
+ * 2.4 GHz band to be reported should have better RSSI by @relative_rssi
+ * and other BSSs in the 5 GHz band to be reported should have better RSSI
+ * by (@relative_rssi - @relative_rssi_5g_pref).
+ * If the current connected BSS is in the 5 GHz band, other BSSs in the
+ * 2.4 GHz band to be reported should have better RSSI by
+ * (@relative_rssi + @relative_rssi_5g_pref) and other BSSs in the 5 GHz
+ * band to be reported should have better RSSI by by @relative_rssi.
*/
struct cfg80211_sched_scan_request {
struct cfg80211_ssid *ssids;
@@ -1645,6 +1659,9 @@ struct cfg80211_sched_scan_request {
u8 mac_addr[ETH_ALEN] __aligned(2);
u8 mac_addr_mask[ETH_ALEN] __aligned(2);
+ int relative_rssi;
+ int relative_rssi_5g_pref;
+
/* internal */
struct wiphy *wiphy;
struct net_device *dev;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 984a35ac..34b16a4 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1981,6 +1981,16 @@ enum nl80211_commands {
* %NL80211_ATTR_MAC has also been used in various commands/events for
* specifying the BSSID.
*
+ * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI: Relative RSSI threshold by which
+ * other BSSs has to be better than the current connected BSS so that they
+ * get reported to user space. This will give an opportunity to userspace
+ * to consider connecting to other matching BSSs which have better RSSI
+ * than the current connected BSS.
+ *
+ * @NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF: The amount of RSSI preference
+ * to be given to 5 GHz APs over 2.4 GHz APs while searching for better
+ * BSSs than the current connected BSS.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2387,6 +2397,9 @@ enum nl80211_attrs {
NL80211_ATTR_BSSID,
+ NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
+ NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -4698,6 +4711,9 @@ enum nl80211_feature_flags {
* configuration (AP/mesh) with VHT rates.
* @NL80211_EXT_FEATURE_FILS_STA: This driver supports Fast Initial Link Setup
* with user space SME (NL80211_CMD_AUTHENTICATE) in station mode.
+ * @NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS: The driver supports sched_scan
+ * for reporting BSSs with better RSSI than the current connected BSS
+ * (%NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI).
*
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4713,6 +4729,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_BEACON_RATE_HT,
NL80211_EXT_FEATURE_BEACON_RATE_VHT,
NL80211_EXT_FEATURE_FILS_STA,
+ NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8db5cb1..af018a5 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -405,6 +405,8 @@ enum nl80211_multicast_groups {
[NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
[NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
[NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
+ [NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI] = { .type = NLA_U32 },
+ [NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF] = { .type = NLA_U32 },
};
/* policy for the key attributes */
@@ -6856,6 +6858,7 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
size_t ie_len;
struct nlattr *tb[NL80211_SCHED_SCAN_MATCH_ATTR_MAX + 1];
s32 default_match_rssi = NL80211_SCAN_RSSI_THOLD_OFF;
+ int bbr;
if (!is_valid_ie_attr(attrs[NL80211_ATTR_IE]))
return ERR_PTR(-EINVAL);
@@ -6950,6 +6953,13 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
if (!n_plans || n_plans > wiphy->max_sched_scan_plans)
return ERR_PTR(-EINVAL);
+ bbr = wiphy_ext_feature_isset(
+ wiphy, NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS);
+ if (!bbr &&
+ (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI] ||
+ attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF]))
+ return ERR_PTR(-EINVAL);
+
request = kzalloc(sizeof(*request)
+ sizeof(*request->ssids) * n_ssids
+ sizeof(*request->match_sets) * n_match_sets
@@ -7156,6 +7166,14 @@ static int nl80211_abort_scan(struct sk_buff *skb, struct genl_info *info)
request->delay =
nla_get_u32(attrs[NL80211_ATTR_SCHED_SCAN_DELAY]);
+ if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI])
+ request->relative_rssi = nla_get_s32(
+ attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI]);
+
+ if (attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF])
+ request->relative_rssi_5g_pref = nla_get_s32(
+ attrs[NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF]);
+
err = nl80211_parse_sched_scan_plans(wiphy, n_plans, request, attrs);
if (err)
goto out_free;
@@ -9649,7 +9667,8 @@ static int nl80211_send_wowlan_tcp(struct sk_buff *msg,
return 0;
}
-static int nl80211_send_wowlan_nd(struct sk_buff *msg,
+static int nl80211_send_wowlan_nd(struct wiphy *wiphy,
+ struct sk_buff *msg,
struct cfg80211_sched_scan_request *req)
{
struct nlattr *nd, *freqs, *matches, *match, *scan_plans, *scan_plan;
@@ -9670,6 +9689,15 @@ static int nl80211_send_wowlan_nd(struct sk_buff *msg,
if (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_DELAY, req->delay))
return -ENOBUFS;
+ if (wiphy_ext_feature_isset(
+ wiphy, NL80211_EXT_FEATURE_SCHED_SCAN_BETTER_BSS) &&
+ (nla_put_u32(msg, NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI,
+ req->relative_rssi) ||
+ nla_put_u32(msg,
+ NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF,
+ req->relative_rssi_5g_pref)))
+ return -ENOBUFS;
+
freqs = nla_nest_start(msg, NL80211_ATTR_SCAN_FREQUENCIES);
if (!freqs)
return -ENOBUFS;
@@ -9783,7 +9811,7 @@ static int nl80211_get_wowlan(struct sk_buff *skb, struct genl_info *info)
goto nla_put_failure;
if (nl80211_send_wowlan_nd(
- msg,
+ &rdev->wiphy, msg,
rdev->wiphy.wowlan_config->nd_config))
goto nla_put_failure;
--
1.9.1
^ permalink raw reply related
* Re: wl1251 & mac address & calibration data
From: Pavel Machek @ 2016-11-23 22:23 UTC (permalink / raw)
To: Pali Rohár
Cc: Michal Kazior, Kalle Valo, Ivaylo Dimitrov, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <201611221805.13606@pali>
[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]
Hi!
> > > As wl1251.ko does not accept mac_address as module parameter, such
> > > modprobe hook does not help -- as there is absolutely no way from
> > > userspace to set or change (permanent) mac address.
> >
> > Quoting modprobe.d manual:
> > > install modulename command...
> > >
> > > This command instructs modprobe to run your
> > > command instead of inserting the module in the
> > > kernel as normal. The command can be any shell
> > > command: this allows you to do any kind of
> > > complex processing you might wish. [...]
>
> I know. But this do not allow me to send mac address to kernel -- as
> kernel does not support such command yet (reason for my first
> question).
Plus, this does not really work for cases where wl1251 is not a
module.
> > You can hook up a script that cooks up wl1251-nvs.bin (caldata,
> > macaddr) and then insmod the actual wl1251.ko module. Or you can just
> > cook up the nvs on first device boot and store it in /lib/firmware
> > (possibly overwriting the "generic" wl1251 from linux-firmware).
>
> This is what I would like to prevent -- overwriting (possible readonly)
> system files with some device specific. It is really bad idea!
Agreed.
"ifconfig hw ether XX" normally sets the address. I guess that's
ioctl? And I guess we should use similar mechanism for permanent
address.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: Break-it testing for wifi
From: Jouni Malinen @ 2016-11-23 22:29 UTC (permalink / raw)
To: Ben Greear; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <5834797B.2090805@candelatech.com>
On Tue, Nov 22, 2016 at 08:59:39AM -0800, Ben Greear wrote:
> On 11/22/2016 02:56 AM, Johannes Berg wrote:
> >On Mon, 2016-11-21 at 08:10 -0800, Ben Greear wrote:
> >>1) Allow supplicant to do bad state-machine transitions (start 4-way
> >>before associating, for instance).
> >
> >Why would you do that? In order to test the AP implementation?
>
> Yes. And really, you should be able to do similar things on the AP to test stations,
> or on IBSS/Mesh devices, etc. hostapd already has some options to corrupt or
> drop a percentage of various management frames. Supplicant does not as far
> as I know.
I'm not sure adding a specific option to corrupt or drop a management
frame is the best approach here. Both hostapd and wpa_supplicant have
multiple mechanisms to enable testing in CONFIG_TESTING_OPTIONS=y builds
and the most flexible cases allow the management and EAPOL frame
processing to be handled by a test script through the control interface.
This provides much more control on how to misbehave and allows that to
be done at higher layer components without having to hardcode stuff in
hostapd/wpa_supplicant (or kernel for that matter). In case of
mac80211_hwsim tests, this is done in the python scripts (see
tests/hwsim directory in hostap.git).
> Currently, supplicant can (at least with some small patches that I carry),
> add custom information elements to probe requests and similar. But, some things
> are built by mac80211 (rate-sets advertised, for instance). So, I was thinking of slightly extending
> the API so that user-space could over-ride whatever mac80211 might normally
> build itself. That lets you more properly fuzz things from user space.
For many cases, I'd expect it to be more flexible to override full frame
payload from a test script rather than come up with more detailed (and
more complex to implement) APIs.. As far as cfg80211/mac80211 is
concerned, it might be convenient to have a command that allows user
space to force a STA entry to a specific state when working in station
mode (hostapd can already do this in AP mode). This would allow the
existing offchannel management frame TX/RX operations to be used to
perform arbitrary exchanges and with the forced state changes, this
could cover more cases related to negotiating unexpected combinations or
exchanges frames in unexpected sequence, etc.
> >>4) Maybe some specific tests like putting in over-flow sized lengths
> >>of IEs.
> >
> >Again, fuzzing would cover this?
>
> Yes, but for ease of use, and to cover frames generated by mac80211, I
> was thinking:
>
> echo 0.25 > /debug/.../wlan0/mgt_fuzzer
>
> The fuzzer would then corrupt 25% of the management frames. And instead of just randomly
> scribbling, it could also parse the frames and do some more clever (and still pseudo-random)
> modifications to the frames, like re-writing IEs with bad lengths, flipping bits in specific portions of the
> frame we feel might find problems, etc.
Why would this be in mac80211? I would much rather handle this type of
fuzzing operations in user space and just provide generic interfaces in
cfg80211 to allow the messages to be exchanged. For most parts, this
capability exists already today..
> >>Has anyone done anything similar they would like to share?
> >>
> >>Johannes: Any interest in having such a framework in upstream
> >>kernels?
hostap.git tests/hwsim has quite a few such functions in testing use. I
don't think I'd support kernel changes in the style that you are
thinking of here, but I would very much support providing more generic
interfaces, where required, to allow this type of testing to be
performed from user space scripts.
> Well, there is a decent chance you could crash some firmware if you sent
> corrupted EAPOL frames to it. And just possibly some drivers inspect packets as well,
> so I was thinking that fully transmitting the frames out of the system might
> have some use. And specifically for me, I am trying to test remote systems,
> so hwsim would not be useful for that.
>
Lots of this capability is already there in mac80211, cfg80211, hostapd,
and wpa_supplicant.. While mac80211_hwsim tests are one of the main use
cases for this, this works fine with any mac80211-based driver for
over-the-air testing as well. For AP mode, it is possible to override
most of management frame and EAPOL processing. For STA mode, EAPOL
processing can be fully overridden and quite a few management frame
exchanges can also be handled from test scripts through wpa_supplicant
control interface, but there may still exists some more constraints on
preventing some testing combinations.
> But, if local Linux (and local userspace) itself is the test target, then hwsim should give some very good
> test coverage.
Please keep in mind that almost anything that can tested with
mac80211_hwsim can also be used with real WLAN hardware when using
mac80211-based drivers..
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-11-23 22:39 UTC (permalink / raw)
To: Pavel Machek
Cc: Michal Kazior, Kalle Valo, Ivaylo Dimitrov, Sebastian Reichel,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel
In-Reply-To: <20161123222335.GA4788@amd>
[-- Attachment #1: Type: Text/Plain, Size: 2153 bytes --]
On Wednesday 23 November 2016 23:23:35 Pavel Machek wrote:
> Hi!
>
> > > > As wl1251.ko does not accept mac_address as module parameter,
> > > > such modprobe hook does not help -- as there is absolutely no
> > > > way from userspace to set or change (permanent) mac address.
> > >
> > > Quoting modprobe.d manual:
> > > > install modulename command...
> > > >
> > > > This command instructs modprobe to run your
> > > > command instead of inserting the module in the
> > > > kernel as normal. The command can be any shell
> > > > command: this allows you to do any kind of
> > > > complex processing you might wish. [...]
> >
> > I know. But this do not allow me to send mac address to kernel --
> > as kernel does not support such command yet (reason for my first
> > question).
>
> Plus, this does not really work for cases where wl1251 is not a
> module.
Yes, this is another problem.
> > > You can hook up a script that cooks up wl1251-nvs.bin (caldata,
> > > macaddr) and then insmod the actual wl1251.ko module. Or you can
> > > just cook up the nvs on first device boot and store it in
> > > /lib/firmware (possibly overwriting the "generic" wl1251 from
> > > linux-firmware).
> >
> > This is what I would like to prevent -- overwriting (possible
> > readonly) system files with some device specific. It is really bad
> > idea!
>
> Agreed.
>
> "ifconfig hw ether XX" normally sets the address. I guess that's
> ioctl?
This sets temporary address and it is ioctl. IIRC same as what ethtool
uses. (ifconfig is already deprecated).
> And I guess we should use similar mechanism for permanent
> address.
I'm not sure here... Above ioctl ↑↑↑ is for changing temporary mac
address. But here we do not want to change permanent mac address. We
want to tell kernel driver current permanent mac address which is stored
in permanent mac address storage (in N900 case in mtd). Just like
userspace helper as kernel driver do not have code which can read
permanent mac address.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH v2 0/7] Fix -Wunused-but-set-variable in mwifiex/
From: Kirtika Ruchandani @ 2016-11-24 1:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
This patchset is part of the effort led by Arnd Bergmann to clean up
warnings in the kernel. This and following patchsets will focus on
"-Wunused-but-set-variable" as it among the noisier ones. These were
found compiling with W=1.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
Changes in v2:
- Reapplied patches on top of wireless-drivers-next.
- Patch 5/7 ("mwifiex: Remove unused 'pm_flag' variable") had to be
redone slightly. The others applied cleanly with 'patch -p1'.
Kirtika Ruchandani (7):
mwifiex: Removed unused mwifiex_private* 'priv' variable
mwifiex: Remove unused 'chan_num' variable
mwifiex: Remove unused 'sta_ptr' variable
mwifiex: Remove unused 'adapter'variable
mwifiex: Remove unused 'pm_flag' variable
mwifiex: Removed unused 'pkt_type' variable
mwifiex: Remove unused 'bcd_usb' variable
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 --
drivers/net/wireless/marvell/mwifiex/main.c | 3 ---
drivers/net/wireless/marvell/mwifiex/scan.c | 8 +++-----
drivers/net/wireless/marvell/mwifiex/sdio.c | 5 -----
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 2 --
drivers/net/wireless/marvell/mwifiex/usb.c | 3 +--
6 files changed, 4 insertions(+), 19 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* [PATCH v2 1/7] mwifiex: Removed unused mwifiex_private* 'priv' variable
From: Kirtika Ruchandani @ 2016-11-24 1:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
Commit bec568ff5107 removed the last remaining usage of struct
mwifiex_private* priv in mwifiex_fw_dpc(), by removing the call to
mwifiex_del_virtual_intf().
Compiling mwifiex/ with W=1 gives the following warning, fix it.
mwifiex/main.c: In function ‘mwifiex_fw_dpc’:
mwifiex/main.c:520:26: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable]
Fixes: bec568ff5107 ("mwifiex: failure path handling in mwifiex_add_virtual_intf()")
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/main.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index eac44fe..e5c3a8a 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -518,7 +518,6 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
{
int ret;
char fmt[64];
- struct mwifiex_private *priv;
struct mwifiex_adapter *adapter = context;
struct mwifiex_fw_image fw;
bool init_failed = false;
@@ -576,8 +575,6 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
goto err_init_fw;
}
- priv = adapter->priv[MWIFIEX_BSS_ROLE_STA];
-
if (!adapter->wiphy) {
if (mwifiex_register_cfg80211(adapter)) {
mwifiex_dbg(adapter, ERROR,
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 2/7] mwifiex: Remove unused 'chan_num' variable
From: Kirtika Ruchandani @ 2016-11-24 1:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
Commit b5413e6b2228 removed all uses of chan_num in mwifiex_config_scan().
Compiling mwifiex with W=1 gives the following warning, fix it.
mwifiex/scan.c: In function ‘mwifiex_config_scan’:
mwifiex/scan.c:830:6: warning: variable ‘chan_num’ set but not used [-Wunused-but-set-variable]
Fixes: b5413e6b2228 ("mwifiex: increase the number of nodes in command pool")
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/scan.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c b/drivers/net/wireless/marvell/mwifiex/scan.c
index 98ce072..1816916 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -827,7 +827,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
u32 num_probes;
u32 ssid_len;
u32 chan_idx;
- u32 chan_num;
u32 scan_type;
u16 scan_dur;
u8 channel;
@@ -1105,13 +1104,12 @@ mwifiex_config_scan(struct mwifiex_private *priv,
mwifiex_dbg(adapter, INFO,
"info: Scan: Scanning current channel only\n");
}
- chan_num = chan_idx;
} else {
mwifiex_dbg(adapter, INFO,
"info: Scan: Creating full region channel list\n");
- chan_num = mwifiex_scan_create_channel_list(priv, user_scan_in,
- scan_chan_list,
- *filtered_scan);
+ mwifiex_scan_create_channel_list(priv, user_scan_in,
+ scan_chan_list,
+ *filtered_scan);
}
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 3/7] mwifiex: Remove unused 'sta_ptr' variable
From: Kirtika Ruchandani @ 2016-11-24 1:25 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
Commit 429d90d2212b introduced mwifiex_cmd_tdls_oper() which initializes
struct mwifiex_sta_node* sta_ptr, but does not use it. Compiling with W=1 gives
the following warning, fix it.
mwifiex/sta_cmd.c: In function ‘mwifiex_cmd_tdls_oper’:
mwifiex/sta_cmd.c:1732:27: warning: variable ‘sta_ptr’ set but not used [-Wunused-but-set-variable]
Fixes: 429d90d2212b ("mwifiex: add cfg80211 tdls_oper handler support")
Cc: Avinash Patil <patila@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index bcd6408..768c519 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1746,7 +1746,6 @@ mwifiex_cmd_tdls_oper(struct mwifiex_private *priv,
{
struct host_cmd_ds_tdls_oper *tdls_oper = &cmd->params.tdls_oper;
struct mwifiex_ds_tdls_oper *oper = data_buf;
- struct mwifiex_sta_node *sta_ptr;
struct host_cmd_tlv_rates *tlv_rates;
struct mwifiex_ie_types_htcap *ht_capab;
struct mwifiex_ie_types_qos_info *wmm_qos_info;
@@ -1764,7 +1763,6 @@ mwifiex_cmd_tdls_oper(struct mwifiex_private *priv,
tdls_oper->reason = 0;
memcpy(tdls_oper->peer_mac, oper->peer_mac, ETH_ALEN);
- sta_ptr = mwifiex_get_sta_entry(priv, oper->peer_mac);
pos = (u8 *)tdls_oper + sizeof(struct host_cmd_ds_tdls_oper);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 4/7] mwifiex: Remove unused 'adapter'variable
From: Kirtika Ruchandani @ 2016-11-24 1:25 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
Commit 3935ccc14d2c introduced mwifiex_tm_cmd() which initializes
struct mwifiex_adapter* adapter, but doesn't use it.
Compiling with W=1 gives the following warning, fix it.
mwifiex/cfg80211.c: In function ‘mwifiex_tm_cmd’:
mwifiex/cfg80211.c:3973:26: warning: variable ‘adapter’ set but not used [-Wunused-but-set-variable]
Fixes: 3935ccc14d2c ("mwifiex: add cfg80211 testmode support")
Cc: Xinming Hu <huxm@marvell.com>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index c26469a..a231f09 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -3980,13 +3980,11 @@ static int mwifiex_tm_cmd(struct wiphy *wiphy, struct wireless_dev *wdev,
struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev->netdev);
struct mwifiex_ds_misc_cmd *hostcmd;
struct nlattr *tb[MWIFIEX_TM_ATTR_MAX + 1];
- struct mwifiex_adapter *adapter;
struct sk_buff *skb;
int err;
if (!priv)
return -EINVAL;
- adapter = priv->adapter;
err = nla_parse(tb, MWIFIEX_TM_ATTR_MAX, data, len,
mwifiex_tm_policy);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 5/7] mwifiex: Remove unused 'pm_flag' variable
From: Kirtika Ruchandani @ 2016-11-24 1:26 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
mwifiex_sdio_resume() intializes pm_flag, just like
mwifiex_sdio_suspend(), but does not use it. Compiling with W=1 gives
the following warning, fix it.
mwifiex/sdio.c: In function ‘mwifiex_sdio_resume’:
mwifiex/sdio.c:234:16: warning: variable ‘pm_flag’ set but not used [-Wunused-but-set-variable]
sdio_get_host_pm_caps() is just an acessor, so the call to it is safe
to remove. The unused variable seems to be present since
5e6e3a92b9a4 which introduced mwifiex_sdio_resume().
Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Cc: Bing Zhao <bzhao@marvell.com>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 0d00db5..6c9f16e 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -186,9 +186,7 @@ static int mwifiex_sdio_resume(struct device *dev)
struct sdio_func *func = dev_to_sdio_func(dev);
struct sdio_mmc_card *card;
struct mwifiex_adapter *adapter;
- mmc_pm_flag_t pm_flag = 0;
- pm_flag = sdio_get_host_pm_caps(func);
card = sdio_get_drvdata(func);
if (!card || !card->adapter) {
dev_err(dev, "resume: invalid card or adapter\n");
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 6/7] mwifiex: Removed unused 'pkt_type' variable
From: Kirtika Ruchandani @ 2016-11-24 1:26 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
Commit 92263a841b15 introduced mwifiex_deaggr_sdio_pkt which initializes
variable pkt_type but does not use it. Compiling with W=1 gives the following
warning, fix it.
mwifiex/sdio.c: In function ‘mwifiex_deaggr_sdio_pkt’:
mwifiex/sdio.c:1198:6: warning: variable ‘pkt_type’ set but not used [-Wunused-but-set-variable]
Fixes: 92263a841b15 ("mwifiex: add SDIO rx single port aggregation")
Cc: Zhaoyang Liu <liuzy@marvell.com>
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 6c9f16e..09c586f 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -1134,7 +1134,6 @@ static void mwifiex_deaggr_sdio_pkt(struct mwifiex_adapter *adapter,
{
u32 total_pkt_len, pkt_len;
struct sk_buff *skb_deaggr;
- u32 pkt_type;
u16 blk_size;
u8 blk_num;
u8 *data;
@@ -1155,8 +1154,6 @@ static void mwifiex_deaggr_sdio_pkt(struct mwifiex_adapter *adapter,
break;
}
pkt_len = le16_to_cpu(*(__le16 *)(data + SDIO_HEADER_OFFSET));
- pkt_type = le16_to_cpu(*(__le16 *)(data + SDIO_HEADER_OFFSET +
- 2));
if ((pkt_len + SDIO_HEADER_OFFSET) > blk_size) {
mwifiex_dbg(adapter, ERROR,
"%s: error in pkt_len,\t"
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 7/7] mwifiex: Remove unused 'bcd_usb' variable
From: Kirtika Ruchandani @ 2016-11-24 1:27 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: Arnd Bergmann, Kalle Valo, linux-wireless, Nishant Sarmukadam,
Zhaoyang Liu, Bing Zhao, Xinming Hu, Avinash Patil
In-Reply-To: <cover.1479950323.git.kirtika@google.com>
mwifiex_usb_probe() defines and sets bcd_usb but does not use it,
Compiling with W=1 gives the following warning, fix it.
mwifiex/usb.c: In function ‘mwifiex_usb_probe’:
mwifiex/usb.c:383:41: warning: variable ‘bcd_usb’ set but not used [-Wunused-but-set-variable]
The unused variable seems to be present since 4daffe354366 which introduced
mwifiex_usb_probe().
Fixes: 4daffe354366 ("mwifiex: add support for Marvell USB8797 chipset")
Cc: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
drivers/net/wireless/marvell/mwifiex/usb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
index c3f696a..c563160 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -379,7 +379,7 @@ static int mwifiex_usb_probe(struct usb_interface *intf,
struct usb_endpoint_descriptor *epd;
int ret, i;
struct usb_card_rec *card;
- u16 id_vendor, id_product, bcd_device, bcd_usb;
+ u16 id_vendor, id_product, bcd_device;
card = devm_kzalloc(&intf->dev, sizeof(*card), GFP_KERNEL);
if (!card)
@@ -390,7 +390,6 @@ static int mwifiex_usb_probe(struct usb_interface *intf,
id_vendor = le16_to_cpu(udev->descriptor.idVendor);
id_product = le16_to_cpu(udev->descriptor.idProduct);
bcd_device = le16_to_cpu(udev->descriptor.bcdDevice);
- bcd_usb = le16_to_cpu(udev->descriptor.bcdUSB);
pr_debug("info: VID/PID = %X/%X, Boot2 version = %X\n",
id_vendor, id_product, bcd_device);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 0/4] Fix -Wunused-but-set-variable in net/mac80211/
From: Kirtika Ruchandani @ 2016-11-24 4:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, netdev, linux-wireless, Marek Kwaczynski,
David Spinadel, Alexander Bondar, Michal Kazior
This patchset is part of the effort led by Arnd Bergmann to clean up
warnings in the kernel. This and following patchsets will focus on
"-Wunused-but-set-variable" as it among the noisier ones. These were
found compiling with W=1.
Kirtika Ruchandani (4):
mac80211: Removed unused 'i' variable
mac80211: Remove unused 'len' variable
mac80211: Removed unused 'struct ieee80211_supported_band*' variable
mac80211: Remove unused 'beaconint_us' variable
net/mac80211/chan.c | 4 +---
net/mac80211/mlme.c | 4 ----
net/mac80211/scan.c | 8 +++-----
net/mac80211/vht.c | 4 ----
4 files changed, 4 insertions(+), 16 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* [PATCH 1/4] mac80211: Removed unused 'i' variable
From: Kirtika Ruchandani @ 2016-11-24 4:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, netdev, linux-wireless, Marek Kwaczynski,
David Spinadel, Alexander Bondar, Michal Kazior
In-Reply-To: <cover.1479962513.git.kirtika@chromium.org>
Commit 5bcae31d9 (mac80211: implement multi-vif in-place reservations)
introduced ieee80211_vif_use_reserved_switch() with a counter variable
'i' that is set but not used. Compiling with W=1 gives the following
warning, fix it.
net/mac80211/chan.c: In function ‘ieee80211_vif_use_reserved_switch’:
net/mac80211/chan.c:1273:6: warning: variable ‘i’ set but not used [-Wunused-but-set-variable]
This is a harmless warning, and is only being fixed to reduce the
noise obtained with W=1 in the kernel.
Fixes: 5bcae31d9 ("mac80211: implement multi-vif in-place reservations")
Cc: Michal Kazior <michal.kazior@tieto.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
---
net/mac80211/chan.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index e75cbf6..7550fd2 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -1270,7 +1270,7 @@ static int ieee80211_vif_use_reserved_switch(struct ieee80211_local *local)
struct ieee80211_sub_if_data *sdata, *sdata_tmp;
struct ieee80211_chanctx *ctx, *ctx_tmp, *old_ctx;
struct ieee80211_chanctx *new_ctx = NULL;
- int i, err, n_assigned, n_reserved, n_ready;
+ int err, n_assigned, n_reserved, n_ready;
int n_ctx = 0, n_vifs_switch = 0, n_vifs_assign = 0, n_vifs_ctxless = 0;
lockdep_assert_held(&local->mtx);
@@ -1391,8 +1391,6 @@ static int ieee80211_vif_use_reserved_switch(struct ieee80211_local *local)
* Update all structures, values and pointers to point to new channel
* context(s).
*/
-
- i = 0;
list_for_each_entry(ctx, &local->chanctx_list, list) {
if (ctx->replace_state != IEEE80211_CHANCTX_REPLACES_OTHER)
continue;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox