* 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: 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 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: 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: [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
* 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: 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
* Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: IgorMitsyanko @ 2016-11-23 17:09 UTC (permalink / raw)
To: Kalle Valo
Cc: Johannes Berg, linux-wireless, btherthala, hwang, smaksimenko,
dlebed, Igor Mitsyanko, Kamlesh Rath, Sergey Matyukevich,
Avinash Patil, Ben Hutchings, Kyle McMartin
In-Reply-To: <87d1hmnrqj.fsf@purkki.adurom.net>
On 11/23/2016 06:25 PM, Kalle Valo wrote:
> IgorMitsyanko <igor.mitsyanko.os@quantenna.com> writes:
>
>> To clarify with you and Kalle, as persons involved with
>> linux-wireless: is my understanding correct that submitting firmware
>> into linux-fimware repository is a prerequisite to accepting new
>> driver into linux-wireless?
> In my opinion the most important is that the device is usable with an
> upstream driver so that anyone can start using the driver (if they have
> the hardware).
>
>> There is an option to start Quantenna device from internal flash
>> memory, no external binary files involved. If we will introduce this
>> functionality and remove code handling external firmware for now
>> (until firmware problem resolved), would that allow driver to be
>> reviewed/accepted?
> Do all the publically available hardware contain the firmware in
> internal flash (flashed in the factory)? Or is this something which must
> be installed separately for each board's internal flash by the user?
Each board must have flash installed on it, preflashed in the factory
with uboot and firmware binary, otherwise board won't boot (won't boot
without uboot, firmware itself is not mandatory).
Booting from flash is default behavior on boards that are currently on
the market, but for developemnt purpuses it's not very convenient and
harder to upgrade.
>
> BTW, the original mail with the firmware image didn't make it to the
> list, I guess it was too big? It would be good if you could post the
> license separately so that people can see it.
>
I resent the email without binary patch to linux-wireless. Yes, it was
big, I guess next time we better use pull requests on github.
^ permalink raw reply
* [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: igor.mitsyanko.os @ 2016-11-23 16:45 UTC (permalink / raw)
To: linux-wireless
Cc: johannes, btherthala, hwang, smaksimenko, dlebed, Igor Mitsyanko,
Kamlesh Rath, Sergey Matyukevich, Avinash Patil, Igor Mitsyanko
In-Reply-To: <87d1hmnrqj.fsf@purkki.adurom.net>
From: Igor Mitsyanko <imitsyanko@quantenna.com>
QSR10G is Quantenna's 8x8, 160M, 11ac WiFi card.
Signed-off-by: Kamlesh Rath <krath@quantenna.com>
Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
Signed-off-by: Avinash Patil <avinashp@quantenna.com>
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
LICENCE.Quantenna_fmac | 74 +++++++++++++++++++++++++++++++++++++++++++++++++
WHENCE | 9 ++++++
qtn/fmac_qsr10g.img | Bin 0 -> 9559676 bytes
3 files changed, 83 insertions(+)
create mode 100644 LICENCE.Quantenna_fmac
create mode 100644 qtn/fmac_qsr10g.img
diff --git a/LICENCE.Quantenna_fmac b/LICENCE.Quantenna_fmac
new file mode 100644
index 0000000..e6f9f72
--- /dev/null
+++ b/LICENCE.Quantenna_fmac
@@ -0,0 +1,74 @@
+Copyright (c) 2016, Quantenna, Inc.
+All rights reserved.
+
+Redistribution. Reproduction and redistribution in binary form, without
+modification, for use solely in conjunction with a Quantenna, Inc. chipset, is
+permitted provided that the following conditions are met:
+
+ - Redistributions must reproduce the above copyright notice and the
+ following disclaimer in the documentation and/or other materials provided
+ with the distribution.
+
+ - Neither the name of Quantenna, Inc. nor the names of its suppliers may be
+ used to endorse or promote products derived from this Software without
+ specific prior written permission.
+
+ - No reverse engineering, decompilation, or disassembly of this Software is
+ permitted, except and solely to the extent that such a restriction is
+ impermissible pursuant to applicable law or third party license.
+
+ - Your reproduction and distribution must comply with all applicable laws,
+ including without limitation all applicable U.S., European, and other
+ export laws.
+
+Limited Patent License. Subject to your compliance with all terms of this
+license, Quantenna, Inc. (“Licensor”) grants you (“Licensee”) a limited,
+worldwide, royalty-free, non-exclusive license under the Licensed Patents to
+make, have made, use, import, offer to sell and sell the Software solely in
+conjunction with a validly purchased Quantenna, Inc. chipset. No hardware
+per se is licensed hereunder.
+
+The term “Licensed Patents” as used in this agreement means only those patents
+or patent applications owned solely and exclusively by Licensor as of the date
+of Licensor’s submission of the Software that would necessarily be infringed by
+the operation of the Software, alone, or in combination with a supported
+version of the Linux operating system. The patent license shall not apply to
+any other combinations which include the Software. The term “Licensed Patents”
+expressly excludes any patent or patent application owned by any current or
+future affiliate of Quantenna, Inc. The term “Software” as used in this
+agreement means the unmodified firmware image submitted by Licensor, under the
+terms of this license, to
+git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git.
+
+Notwithstanding anything to the contrary herein, Licensor does not grant and
+Licensee does not receive, by virtue of this agreement or the Licensor’s
+submission of any Software, any license or other rights under any patent or
+patent application owned by any current or future affiliate of Licensor or any
+other entity (other than Licensor), whether expressly, impliedly, by virtue of
+estoppel or exhaustion, or otherwise. If Licensee has a separate agreement with
+Licensor covering use of the Software, then that separate agreement shall
+control.
+
+Open Source Software. The Software may include components that are licensed
+pursuant to open source software (“Open Source Components”). Information
+regarding the Open Source Components included with the Software is available
+upon request to oslegal@quantenna.com. To the extent such Open Source
+Components are required to be licensed to you under the terms of a separate
+license (such as an open source license) then such other terms shall apply, and
+nothing herein shall be deemed or interpreted to limit any rights you may have
+under any such applicable license.
+
+DISCLAIMER. THIS SOFTWARE (INCLUDING ANY APPLICABLE OPEN SOURCE COMPONENTS) IS
+PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFREINGEMENT ARE
+EXPRESSLY DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNERS, AUTHORS, OR
+CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
+OF SUCH DAMAGE, AND REGARDLESS OF ANY FAILURE OF ESSENTIAL PURPOSE OF ANY
+LIMITED REMEDY PROVIDED HEREIN.
+
diff --git a/WHENCE b/WHENCE
index 534c2da..78f6b73 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3347,3 +3347,12 @@ File: rockchip/dptx.bin
Version: 2.9
Licence: Redistributable. See LICENCE.rockchip for details.
+
+--------------------------------------------------------------------------
+
+Driver: qtnfmac - FullMAC driver for Quantenna QSR10G wireless card
+
+File: qtn/fmac_qsr10g.img
+
+Licence: Redistributable. See LICENCE.Quantenna_fmac for details.
+
diff --git a/qtn/fmac_qsr10g.img b/qtn/fmac_qsr10g.img
new file mode 100644
index 0000000..a65e6ec
Binary files /dev/null and b/qtn/fmac_qsr10g.img differ
--
2.7.4
^ permalink raw reply related
* Re: brcmsmac: fix array out-of-bounds access in qm_log10
From: Kalle Valo @ 2016-11-23 15:47 UTC (permalink / raw)
To: Tobias Regnery
Cc: linux-wireless, arend.vanspriel, franky.lin, hante.meuleman,
brcm80211-dev-list.pdl, Tobias Regnery
In-Reply-To: <1479734949-6300-1-git-send-email-tobias.regnery@gmail.com>
Tobias Regnery <tobias.regnery@gmail.com> wrote:
> I get the following UBSAN warning during boot on my laptop:
>
> ================================================================================
> UBSAN: Undefined behaviour in drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_qmath.c:280:21
> index 32 is out of range for type 's16 [32]'
> CPU: 0 PID: 879 Comm: NetworkManager Not tainted 4.9.0-rc4 #28
> Hardware name: LENOVO Lenovo IdeaPad N581/INVALID, BIOS 5ECN96WW(V9.01) 03/14/2013
> ffff8800b74a6478 ffffffff828e59d2 0000000041b58ab3 ffffffff8398330c
> ffffffff828e5920 ffff8800b74a64a0 ffff8800b74a6450 0000000000000020
> 1ffffffff845848c ffffed0016e94bf1 ffffffffc22c2460 000000006b9c0514
> Call Trace:
> [<ffffffff828e59d2>] dump_stack+0xb2/0x110
> [<ffffffff828e5920>] ? _atomic_dec_and_lock+0x150/0x150
> [<ffffffff82968c9d>] ubsan_epilogue+0xd/0x4e
> [<ffffffff82969875>] __ubsan_handle_out_of_bounds+0xfa/0x13e
> [<ffffffff8296977b>] ? __ubsan_handle_shift_out_of_bounds+0x241/0x241
> [<ffffffffc0d48379>] ? bcma_host_pci_read16+0x59/0xa0 [bcma]
> [<ffffffffc0d48388>] ? bcma_host_pci_read16+0x68/0xa0 [bcma]
> [<ffffffffc212ad78>] ? read_phy_reg+0xe8/0x180 [brcmsmac]
> [<ffffffffc2184714>] qm_log10+0x2e4/0x350 [brcmsmac]
> [<ffffffffc2142eb8>] wlc_phy_init_lcnphy+0x538/0x1f20 [brcmsmac]
> [<ffffffffc2142980>] ? wlc_lcnphy_periodic_cal+0x5c0/0x5c0 [brcmsmac]
> [<ffffffffc1ba0c93>] ? ieee80211_open+0xb3/0x110 [mac80211]
> [<ffffffff82f73a02>] ? sk_busy_loop+0x1e2/0x840
> [<ffffffff82f7a6ce>] ? __dev_change_flags+0xae/0x220
> ...
>
> The report is valid: doing the math in this function, with an input value
> N=63 the variable s16tableIndex gets a value of 31. This value is used as
> an index in the array log_table with 32 entries. But the next line is:
>
> s16errorApproximation = (s16) qm_mulu16(u16offset,
> (u16) (log_table[s16tableIndex + 1] -
> log_table[s16tableIndex]));
>
> With s16tableIndex + 1 we are trying an out-of-bounds access to the array.
>
> The log_table array provides log2 values in q.15 format and the above
> statement tries an error approximation with the next value. To fix this
> issue add the next value to the array and update the comment accordingly.
>
> Signed-off-by: Tobias Regnery <tobias.regnery@gmail.com>
A note to myself: this patch seems to be corrupted in patchwork web interface,
need to check that when commiting the formatting is ok.
--
https://patchwork.kernel.org/patch/9439423/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2,1/9] rt2800: correctly report MCS TX parameters
From: Kalle Valo @ 2016-11-23 15:39 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa, Mathias Kresin
In-Reply-To: <1479462241-9299-2-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> We should only set IEEE80211_HT_MCS_TX_RX_DIF when TX and RX MCS sets
> are not equal, i.e. when number of tx streams is different than
> number of RX streams.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
9 patches applied to wireless-drivers-next.git, thanks.
cea5b03d8a10 rt2800: correctly report MCS TX parameters
b29a1c1f08f3 rt2800usb: do not wipe out USB_DMA_CFG settings
770e4b730a73 rt2800: OFDM rates are mandatory
b4c449b1b803 rt2800: do not overwrite WPDMA_GLO_CFG_WP_DMA_BURST_SIZE
be82de9d64e2 rt2800: correct AUTO_RSP_CFG
231aeca1e19e rt2800: correct TX_SW_CFG1 for 5592
6c40063d5a61 rt2800: use RTS/CTS protection instead of CTS-to-self
8d79b0078278 rt2800: tune *_PROT_CFG parameters
159a55a64d44 rt2800: disable CCK rates on HT
--
https://patchwork.kernel.org/patch/9436109/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/7] mwifiex: Removed unused mwifiex_private* 'priv' variable
From: Kalle Valo @ 2016-11-23 15:36 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: Amitkumar Karwar, Arnd Bergmann, linux-wireless,
Nishant Sarmukadam, Zhaoyang Liu, Bing Zhao, Xinming Hu,
Avinash Patil
In-Reply-To: <ad72403d4d99a1b13ea7f99b0ea992b23aa2ea09.1479458373.git.kirtika@google.com>
Kirtika Ruchandani <kirtika.ruchandani@gmail.com> wrote:
> 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>
Failed to apply to wireless-drivers-next:
Applying: mwifiex: Remove unused 'pm_flag' variable
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/marvell/mwifiex/sdio.c
CONFLICT (content): Merge conflict in drivers/net/wireless/marvell/mwifiex/sdio.c
Failed to merge in the changes.
Patch failed at 0001 mwifiex: Remove unused 'pm_flag' variable
7 patches set to Changes Requested.
9435943 [1/7] mwifiex: Removed unused mwifiex_private* 'priv' variable
9435945 [2/7] mwifiex: Remove unused 'chan_num' variable
9435947 [3/7] mwifiex: Remove unused 'sta_ptr' variable
9435949 [4/7] mwifiex: Remove unused 'adapter'variable
9435951 [5/7] mwifiex: Remove unused 'pm_flag' variable
9435953 [6/7] mwifiex: Removed unused 'pkt_type' variable
9435955 [7/7] mwifiex: Remove unused 'bcd_usb' variable
--
https://patchwork.kernel.org/patch/9435943/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2] brcmfmac: update beacon IE after bss up and clear when AP stopped
From: Kalle Valo @ 2016-11-23 15:34 UTC (permalink / raw)
To: Wright Feng
Cc: arend.vanspriel, franky.lin, hante.meuleman, pieterpg,
brcm80211-dev-list.pdl, linux-wireless, Chi-Hsien Lin,
wright.feng
In-Reply-To: <20161118015952.GA22142@cypress.com>
Wright Feng <wefe@cypress.com> wrote:
> Firmware doesn't update beacon/Probe Response vendor IEs correctly when
> bss is down, so we move brcmf_config_ap_mgmt_ie after BSS up. And host
> driver should clear IEs when AP stopped so that the IEs in host side will
> be synced with in firmware side.
>
> Signed-off-by: Wright Feng <wright.feng@cypress.com>
Patch applied to wireless-drivers-next.git, thanks.
f25ba69c638b brcmfmac: update beacon IE after bss up and clear when AP stopped
--
https://patchwork.kernel.org/patch/9435643/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rt2x00: Fix incorrect usage of CONFIG_RT2X00_LIB_USB
From: Kalle Valo @ 2016-11-23 15:34 UTC (permalink / raw)
To: Vishal Thanki; +Cc: sgruszka, helmut.schaa, linux-wireless, Vishal Thanki
In-Reply-To: <1479312114-9389-1-git-send-email-vishalthanki@gmail.com>
Vishal Thanki <vishalthanki@gmail.com> wrote:
> In device removal routine, usage of "#ifdef CONFIG_RT2X00_LIB_USB"
> will not cover the case when it is configured as module. This will
> omit the entire if-block which does cleanup of URBs and cancellation
> of pending work. Changing the #ifdef to #if IS_ENABLED() to fix it.
>
> Signed-off-by: Vishal Thanki <vishalthanki@gmail.com>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
a083c8fd277b rt2x00: Fix incorrect usage of CONFIG_RT2X00_LIB_USB
--
https://patchwork.kernel.org/patch/9431983/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: Kalle Valo @ 2016-11-23 15:25 UTC (permalink / raw)
To: IgorMitsyanko
Cc: Johannes Berg, linux-wireless, btherthala, hwang, smaksimenko,
dlebed, Igor Mitsyanko, Kamlesh Rath, Sergey Matyukevich,
Avinash Patil, Ben Hutchings, Kyle McMartin
In-Reply-To: <a5075f50-25c6-18a1-bd5b-309927dacdab@quantenna.com>
IgorMitsyanko <igor.mitsyanko.os@quantenna.com> writes:
> To clarify with you and Kalle, as persons involved with
> linux-wireless: is my understanding correct that submitting firmware
> into linux-fimware repository is a prerequisite to accepting new
> driver into linux-wireless?
In my opinion the most important is that the device is usable with an
upstream driver so that anyone can start using the driver (if they have
the hardware).
> There is an option to start Quantenna device from internal flash
> memory, no external binary files involved. If we will introduce this
> functionality and remove code handling external firmware for now
> (until firmware problem resolved), would that allow driver to be
> reviewed/accepted?
Do all the publically available hardware contain the firmware in
internal flash (flashed in the factory)? Or is this something which must
be installed separately for each board's internal flash by the user?
BTW, the original mail with the firmware image didn't make it to the
list, I guess it was too big? It would be good if you could post the
license separately so that people can see it.
--
Kalle Valo
^ permalink raw reply
* Re: [1/7] wil6210: fix net queue stop/wake
From: Kalle Valo @ 2016-11-23 14:51 UTC (permalink / raw)
To: Maya Erez; +Cc: Kalle Valo, Dedy Lansky, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1477720287-17606-2-git-send-email-qca_merez@qca.qualcomm.com>
Maya Erez <qca_merez@qca.qualcomm.com> wrote:
> From: Dedy Lansky <qca_dlansky@qca.qualcomm.com>
>
> Driver calls to netif_tx_stop_all_queues/netif_tx_wake_all_queues are
> inconsistent. In several cases, driver can get to a situation where net
> queues are stopped forever and data cannot be sent.
>
> The fix is to stop net queues if there is at least one vring which is
> "full" and to wake net queues if all vrings are not "full".
>
> Signed-off-by: Dedy Lansky <qca_dlansky@qca.qualcomm.com>
> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
6 patches applied to ath-next branch of ath.git, thanks.
f9e3033ff7eb wil6210: fix net queue stop/wake
2c207eb8e6ab wil6210: add support for power save enable / disable
dfb5b098e0f4 wil6210: fix deadlock when using fw_no_recovery option
035859a5117b wil6210: add support for abort scan
cbf795c195fb wil6210: align to latest auto generated wmi.h
3fea18d079e2 wil6210: support NL80211_ATTR_WIPHY_RETRY_SHORT
--
https://patchwork.kernel.org/patch/9403059/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k: fix NULL pointer dereference
From: Kalle Valo @ 2016-11-23 13:59 UTC (permalink / raw)
To: miaoqing pan; +Cc: linux-wireless, ath9k-devel, devin.tuchsen, Miaoqing Pan
In-Reply-To: <1479288188-3793-1-git-send-email-miaoqing@codeaurora.org>
miaoqing pan <miaoqing@codeaurora.org> wrote:
> From: Miaoqing Pan <miaoqing@codeaurora.org>
>
> relay_open() may return NULL, check the return value to avoid the crash.
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
> IP: [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
> PGD 41cf28067 PUD 41be92067 PMD 0
> Oops: 0000 [#1] SMP
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.6+ #35
> Hardware name: Hewlett-Packard h8-1080t/2A86, BIOS 6.15 07/04/2011
> task: ffffffff81e0c4c0 task.stack: ffffffff81e00000
> RIP: 0010:[<ffffffffa01a95c5>] [<ffffffffa01a95c5>] ath_cmn_process_fft+0xd5/0x700 [ath9k_common]
> RSP: 0018:ffff88041f203ca0 EFLAGS: 00010293
> RAX: 0000000000000000 RBX: 000000000000059f RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffffffff81f0ca98
> RBP: ffff88041f203dc8 R08: ffffffffffffffff R09: 00000000000000ff
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffffffff81f0ca98 R14: 0000000000000000 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000040 CR3: 000000041b6ec000 CR4: 00000000000006f0
> Stack:
> 0000000000000363 00000000000003f3 00000000000003f3 00000000000001f9
> 000000000000049a 0000000001252c04 ffff88041f203e44 ffff880417b4bfd0
> 0000000000000008 ffff88041785b9c0 0000000000000002 ffff88041613dc60
>
> Call Trace:
> <IRQ>
> [<ffffffffa01b6441>] ath9k_tasklet+0x1b1/0x220 [ath9k]
> [<ffffffff8105d8dd>] tasklet_action+0x4d/0xf0
> [<ffffffff8105dde2>] __do_softirq+0x92/0x2a0
>
> Reported-by: Devin Tuchsen <devin.tuchsen@gmail.com>
> Tested-by: Devin Tuchsen <devin.tuchsen@gmail.com>
> Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
40bea976c72b ath9k: fix NULL pointer dereference
--
https://patchwork.kernel.org/patch/9431163/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success
From: Kalle Valo @ 2016-11-23 13:58 UTC (permalink / raw)
To: Matthias Schiffer
Cc: kvalo, ath9k-devel, linux-wireless, ath9k-devel, miaoqing
In-Reply-To: <44116a7bca8524a187083916bdea535145e7a23a.1479232041.git.mschiffer@universe-factory.net>
Matthias Schiffer <mschiffer@universe-factory.net> wrote:
> Commit b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and
> SOC") refactored ath9k_hw_gpio_get() to support both WMAC and SOC GPIOs,
> changing the return on success from 1 to BIT(gpio). This broke some callers
> like ath_is_rfkill_set().
>
> Instead of fixing all callers, change ath9k_hw_gpio_get() back to only
> return 0 or 1.
>
> Fixes: b2d70d4944c1 ("ath9k: make GPIO API to support both of WMAC and SOC")
> Cc: <stable@vger.kernel.org> # v4.7+
> Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Patch applied to ath-next branch of ath.git, thanks.
91851cc7a939 ath9k: fix ath9k_hw_gpio_get() to return 0 or 1 on success
--
https://patchwork.kernel.org/patch/9430247/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: add spectral scan support to wmi-tlv
From: Kalle Valo @ 2016-11-23 13:57 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless, Michal Kazior
In-Reply-To: <1479130000-11551-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> wrote:
> Command structure and event flow doesn't seem to
> be any different compared to existing
> implementation for other firmware branches.
>
> This patch effectively adds in-driver support for
> spectral scanning on QCA61x4 and QCA9377.
>
> Tested QCA9377 w/ WLAN.TF.1.0-00267-1.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Patch applied to ath-next branch of ath.git, thanks.
5a401f36ba30 ath10k: add spectral scan support to wmi-tlv
--
https://patchwork.kernel.org/patch/9427503/
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 null deref on wmi-tlv when trying spectral scan
From: Kalle Valo @ 2016-11-23 13:56 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless, Michal Kazior
In-Reply-To: <1479129923-11083-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> wrote:
> WMI ops wrappers did not properly check for null
> function pointers for spectral scan. This caused
> null dereference crash with WMI-TLV based firmware
> which doesn't implement spectral scan.
>
> The crash could be triggered with:
>
> ip link set dev wlan0 up
> echo background > /sys/kernel/debug/ieee80211/phy0/ath10k/spectral_scan_ctl
>
> The crash looked like this:
>
> [ 168.031989] BUG: unable to handle kernel NULL pointer dereference at (null)
> [ 168.037406] IP: [< (null)>] (null)
> [ 168.040395] PGD cdd4067 PUD fa0f067 PMD 0
> [ 168.043303] Oops: 0010 [#1] SMP
> [ 168.045377] Modules linked in: ath10k_pci(O) ath10k_core(O) ath mac80211 cfg80211 [last unloaded: cfg80211]
> [ 168.051560] CPU: 1 PID: 1380 Comm: bash Tainted: G W O 4.8.0 #78
> [ 168.054336] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
> [ 168.059183] task: ffff88000c460c00 task.stack: ffff88000d4bc000
> [ 168.061736] RIP: 0010:[<0000000000000000>] [< (null)>] (null)
> ...
> [ 168.100620] Call Trace:
> [ 168.101910] [<ffffffffa03b9566>] ? ath10k_spectral_scan_config+0x96/0x200 [ath10k_core]
> [ 168.104871] [<ffffffff811386e2>] ? filemap_fault+0xb2/0x4a0
> [ 168.106696] [<ffffffffa03b97e6>] write_file_spec_scan_ctl+0x116/0x280 [ath10k_core]
> [ 168.109618] [<ffffffff812da3a1>] full_proxy_write+0x51/0x80
> [ 168.111443] [<ffffffff811957b8>] __vfs_write+0x28/0x120
> [ 168.113090] [<ffffffff812f1a2d>] ? security_file_permission+0x3d/0xc0
> [ 168.114932] [<ffffffff8109b912>] ? percpu_down_read+0x12/0x60
> [ 168.116680] [<ffffffff811965f8>] vfs_write+0xb8/0x1a0
> [ 168.118293] [<ffffffff81197966>] SyS_write+0x46/0xa0
> [ 168.119912] [<ffffffff818f2972>] entry_SYSCALL_64_fastpath+0x1a/0xa4
> [ 168.121737] Code: Bad RIP value.
> [ 168.123318] RIP [< (null)>] (null)
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Patch applied to ath-next branch of ath.git, thanks.
18ae68fff392 ath10k: fix null deref on wmi-tlv when trying spectral scan
--
https://patchwork.kernel.org/patch/9427495/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [2/4] ath10k: implement offset_tsf ieee80211_op
From: Kalle Valo @ 2016-11-23 13:54 UTC (permalink / raw)
To: Pedersen, Thomas; +Cc: ath10k, Thomas Pedersen, linux-wireless
In-Reply-To: <20160928235631.9197-3-twp@qca.qualcomm.com>
"Pedersen, Thomas" <twp@qca.qualcomm.com> wrote:
> Current set_tsf is implemented in terms of TSF_INCREMENT
> only. Instead support new WMI command TSF_DECREMENT and
> export these through offset_tsf. Advantage is we get
> more accurate TSF adjustments, and don't calculate wrong
> offset in case absolute TSF was calculated from rx_mactime
> (actual TSF).
>
> The new WMI command is available in firmware
> 10.4-3.2.1-00033 for QCA4019 chips. Old drivers on new
> firmware or vice versa shouldn't be a problem since
> get/set tsf logic was already broken.
>
> Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
2 patches applied to ath-next branch of ath.git, thanks.
973324fff154 ath10k: implement offset_tsf ieee80211_op
f6f64cfb966d ath10k: remove set/get_tsf ieee80211_ops
--
https://patchwork.kernel.org/patch/9355377/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: advertize hardware packet loss mechanism
From: Kalle Valo @ 2016-11-23 13:53 UTC (permalink / raw)
To: Rajkumar Manoharan; +Cc: ath10k, linux-wireless, Rajkumar Manoharan, rmanohar
In-Reply-To: <20160906070841.4266-1-rmanohar@qti.qualcomm.com>
Rajkumar Manoharan <rmanohar@qti.qualcomm.com> wrote:
> Indicate hardware (or firmware) supports that CQM packet-loss report
> will be generated based on station kickout algorithm. As of now mac80211
> tracks connection loss by missing msdu counts (50) whereas ath10k
> firmware tracks them by missing ppdus (+ BAR tries). While firmware is
> trying to adapt its rate table, mac80211 might send out low_ack event to
> hostapd. This is causing frequent connect and disconnect iteration under
> noisy environment or when station is roaming around.
>
> Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
ff32eeb86aa1 ath10k: advertize hardware packet loss mechanism
--
https://patchwork.kernel.org/patch/9315811/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH 02/12] brcmfmac: add support for 43341 chip
From: Arend van Spriel @ 2016-11-23 10:25 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1479896731-5091-1-git-send-email-arend.vanspriel@broadcom.com>
This chip was already supported, but seems a device came up giving
a different chip identifier. So adding that effectively mapping to
the same firmware file as for 43340 chip.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 +
drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index b892dac..dfb0658 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -621,6 +621,7 @@ struct sdiod_drive_str {
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4330_CHIP_ID, 0xFFFFFFFF, 4330),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4334_CHIP_ID, 0xFFFFFFFF, 4334),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43340_CHIP_ID, 0xFFFFFFFF, 43340),
+ BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43341_CHIP_ID, 0xFFFFFFFF, 43340),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4335_CHIP_ID, 0xFFFFFFFF, 4335),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_43362_CHIP_ID, 0xFFFFFFFE, 43362),
BRCMF_FW_NVRAM_ENTRY(BRCM_CC_4339_CHIP_ID, 0xFFFFFFFF, 4339),
diff --git a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
index d0407d9..f1fb8a3 100644
--- a/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h
@@ -36,6 +36,7 @@
#define BRCM_CC_4330_CHIP_ID 0x4330
#define BRCM_CC_4334_CHIP_ID 0x4334
#define BRCM_CC_43340_CHIP_ID 43340
+#define BRCM_CC_43341_CHIP_ID 43341
#define BRCM_CC_43362_CHIP_ID 43362
#define BRCM_CC_4335_CHIP_ID 0x4335
#define BRCM_CC_4339_CHIP_ID 0x4339
--
1.9.1
^ permalink raw reply related
* [PATCH 00/12] brcmfmac: scheduled scan cleanup and chip support
From: Arend van Spriel @ 2016-11-23 10:25 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
This patch series contains:
* cleanup of scheduled scan code.
* fix handling schedules scan results for newer chips.
* support for bcm43341 chipset with different chip id.
* support rev6 of PCIe device interface.
The series is intended for 4.10 and applies to the master branch
of the wireless-drivers-next repository.
Arend van Spriel (11):
brcmfmac: add support for 43341 chip
brcmfmac: move pno helper functions in separate source file
brcmfmac: fix handling ssids in .sched_scan_start() callback
brcmfmac: change prototype for brcmf_do_escan()
brcmfmac: make internal escan more generic
brcmfmac: split up brcmf_pno_config() function
brcmfmac: move scheduled scan activation to pno source file
brcmfmac: use provided channels for scheduled scan
brcmfmac: remove restriction from .sched_scan_start() callback
brcmfmac: use requested scan interval in scheduled scan
brcmfmac: fix scheduled scan result handling for newer chips
Franky Lin (1):
brcmfmac: add pcie host dongle interface rev6 support
.../wireless/broadcom/brcm80211/brcmfmac/Makefile | 3 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 10 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 381 ++++++++-------------
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 4 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 23 ++
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 38 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.h | 4 +
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 171 +++++----
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 242 +++++++++++++
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.h | 40 +++
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 +
.../broadcom/brcm80211/include/brcm_hw_ids.h | 1 +
12 files changed, 588 insertions(+), 330 deletions(-)
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.h
--
1.9.1
^ permalink raw reply
* [PATCH 03/12] brcmfmac: move pno helper functions in separate source file
From: Arend van Spriel @ 2016-11-23 10:25 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1479896731-5091-1-git-send-email-arend.vanspriel@broadcom.com>
Introducing new source file for pno related functionality. Moving
existing pno functions.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
.../wireless/broadcom/brcm80211/brcmfmac/Makefile | 3 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 93 ++-----------------
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 100 +++++++++++++++++++++
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.h | 40 +++++++++
4 files changed, 150 insertions(+), 86 deletions(-)
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
create mode 100644 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.h
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
index 9e4b505..d1568be 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
@@ -35,7 +35,8 @@ brcmfmac-objs += \
firmware.o \
feature.o \
btcoex.o \
- vendor.o
+ vendor.o \
+ pno.o
brcmfmac-$(CONFIG_BRCMFMAC_PROTO_BCDC) += \
bcdc.o
brcmfmac-$(CONFIG_BRCMFMAC_PROTO_MSGBUF) += \
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 1e7c6f0..ee27095 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -32,6 +32,7 @@
#include "fwil_types.h"
#include "p2p.h"
#include "btcoex.h"
+#include "pno.h"
#include "cfg80211.h"
#include "feature.h"
#include "fwil.h"
@@ -41,16 +42,6 @@
#include "common.h"
#define BRCMF_SCAN_IE_LEN_MAX 2048
-#define BRCMF_PNO_VERSION 2
-#define BRCMF_PNO_TIME 30
-#define BRCMF_PNO_REPEAT 4
-#define BRCMF_PNO_FREQ_EXPO_MAX 3
-#define BRCMF_PNO_MAX_PFN_COUNT 16
-#define BRCMF_PNO_ENABLE_ADAPTSCAN_BIT 6
-#define BRCMF_PNO_HIDDEN_BIT 2
-#define BRCMF_PNO_WPA_AUTH_ANY 0xFFFFFFFF
-#define BRCMF_PNO_SCAN_COMPLETE 1
-#define BRCMF_PNO_SCAN_INCOMPLETE 0
#define WPA_OUI "\x00\x50\xF2" /* WPA OUI */
#define WPA_OUI_TYPE 1
@@ -3323,76 +3314,6 @@ static void brcmf_init_escan(struct brcmf_cfg80211_info *cfg)
return err;
}
-static int brcmf_dev_pno_clean(struct net_device *ndev)
-{
- int ret;
-
- /* Disable pfn */
- ret = brcmf_fil_iovar_int_set(netdev_priv(ndev), "pfn", 0);
- if (ret == 0) {
- /* clear pfn */
- ret = brcmf_fil_iovar_data_set(netdev_priv(ndev), "pfnclear",
- NULL, 0);
- }
- if (ret < 0)
- brcmf_err("failed code %d\n", ret);
-
- return ret;
-}
-
-static int brcmf_dev_pno_config(struct brcmf_if *ifp,
- struct cfg80211_sched_scan_request *request)
-{
- struct brcmf_pno_param_le pfn_param;
- struct brcmf_pno_macaddr_le pfn_mac;
- s32 err;
- u8 *mac_mask;
- int i;
-
- memset(&pfn_param, 0, sizeof(pfn_param));
- pfn_param.version = cpu_to_le32(BRCMF_PNO_VERSION);
-
- /* set extra pno params */
- pfn_param.flags = cpu_to_le16(1 << BRCMF_PNO_ENABLE_ADAPTSCAN_BIT);
- pfn_param.repeat = BRCMF_PNO_REPEAT;
- pfn_param.exp = BRCMF_PNO_FREQ_EXPO_MAX;
-
- /* set up pno scan fr */
- pfn_param.scan_freq = cpu_to_le32(BRCMF_PNO_TIME);
-
- err = brcmf_fil_iovar_data_set(ifp, "pfn_set", &pfn_param,
- sizeof(pfn_param));
- if (err) {
- brcmf_err("pfn_set failed, err=%d\n", err);
- return err;
- }
-
- /* Find out if mac randomization should be turned on */
- if (!(request->flags & NL80211_SCAN_FLAG_RANDOM_ADDR))
- return 0;
-
- pfn_mac.version = BRCMF_PFN_MACADDR_CFG_VER;
- pfn_mac.flags = BRCMF_PFN_MAC_OUI_ONLY | BRCMF_PFN_SET_MAC_UNASSOC;
-
- memcpy(pfn_mac.mac, request->mac_addr, ETH_ALEN);
- mac_mask = request->mac_addr_mask;
- for (i = 0; i < ETH_ALEN; i++) {
- pfn_mac.mac[i] &= mac_mask[i];
- pfn_mac.mac[i] |= get_random_int() & ~(mac_mask[i]);
- }
- /* Clear multi bit */
- pfn_mac.mac[0] &= 0xFE;
- /* Set locally administered */
- pfn_mac.mac[0] |= 0x02;
-
- err = brcmf_fil_iovar_data_set(ifp, "pfn_macaddr", &pfn_mac,
- sizeof(pfn_mac));
- if (err)
- brcmf_err("pfn_macaddr failed, err=%d\n", err);
-
- return err;
-}
-
static int
brcmf_cfg80211_sched_scan_start(struct wiphy *wiphy,
struct net_device *ndev,
@@ -3436,15 +3357,16 @@ static int brcmf_dev_pno_config(struct brcmf_if *ifp,
if (request->n_match_sets > 0) {
/* clean up everything */
- ret = brcmf_dev_pno_clean(ndev);
+ ret = brcmf_pno_clean(ifp);
if (ret < 0) {
brcmf_err("failed error=%d\n", ret);
return ret;
}
/* configure pno */
- if (brcmf_dev_pno_config(ifp, request))
- return -EINVAL;
+ ret = brcmf_pno_config(ifp, request);
+ if (ret < 0)
+ return ret;
/* configure each match set */
for (i = 0; i < request->n_match_sets; i++) {
@@ -3486,11 +3408,12 @@ static int brcmf_cfg80211_sched_scan_stop(struct wiphy *wiphy,
struct net_device *ndev)
{
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
+ struct brcmf_if *ifp = netdev_priv(ndev);
brcmf_dbg(SCAN, "enter\n");
- brcmf_dev_pno_clean(ndev);
+ brcmf_pno_clean(ifp);
if (cfg->sched_escan)
- brcmf_notify_escan_complete(cfg, netdev_priv(ndev), true, true);
+ brcmf_notify_escan_complete(cfg, ifp, true, true);
return 0;
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
new file mode 100644
index 0000000..2f6a4e0
--- /dev/null
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.c
@@ -0,0 +1,100 @@
+/*
+ * Copyright (c) 2016 Broadcom
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+ * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+ * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+#include <linux/netdevice.h>
+#include <net/cfg80211.h>
+
+#include "core.h"
+#include "debug.h"
+#include "pno.h"
+#include "fwil.h"
+#include "fwil_types.h"
+
+#define BRCMF_PNO_VERSION 2
+#define BRCMF_PNO_TIME 30
+#define BRCMF_PNO_REPEAT 4
+#define BRCMF_PNO_FREQ_EXPO_MAX 3
+#define BRCMF_PNO_ENABLE_ADAPTSCAN_BIT 6
+#define BRCMF_PNO_SCAN_INCOMPLETE 0
+
+int brcmf_pno_clean(struct brcmf_if *ifp)
+{
+ int ret;
+
+ /* Disable pfn */
+ ret = brcmf_fil_iovar_int_set(ifp, "pfn", 0);
+ if (ret == 0) {
+ /* clear pfn */
+ ret = brcmf_fil_iovar_data_set(ifp, "pfnclear", NULL, 0);
+ }
+ if (ret < 0)
+ brcmf_err("failed code %d\n", ret);
+
+ return ret;
+}
+
+int brcmf_pno_config(struct brcmf_if *ifp,
+ struct cfg80211_sched_scan_request *request)
+{
+ struct brcmf_pno_param_le pfn_param;
+ struct brcmf_pno_macaddr_le pfn_mac;
+ s32 err;
+ u8 *mac_mask;
+ int i;
+
+ memset(&pfn_param, 0, sizeof(pfn_param));
+ pfn_param.version = cpu_to_le32(BRCMF_PNO_VERSION);
+
+ /* set extra pno params */
+ pfn_param.flags = cpu_to_le16(1 << BRCMF_PNO_ENABLE_ADAPTSCAN_BIT);
+ pfn_param.repeat = BRCMF_PNO_REPEAT;
+ pfn_param.exp = BRCMF_PNO_FREQ_EXPO_MAX;
+
+ /* set up pno scan fr */
+ pfn_param.scan_freq = cpu_to_le32(BRCMF_PNO_TIME);
+
+ err = brcmf_fil_iovar_data_set(ifp, "pfn_set", &pfn_param,
+ sizeof(pfn_param));
+ if (err) {
+ brcmf_err("pfn_set failed, err=%d\n", err);
+ return err;
+ }
+
+ /* Find out if mac randomization should be turned on */
+ if (!(request->flags & NL80211_SCAN_FLAG_RANDOM_ADDR))
+ return 0;
+
+ pfn_mac.version = BRCMF_PFN_MACADDR_CFG_VER;
+ pfn_mac.flags = BRCMF_PFN_MAC_OUI_ONLY | BRCMF_PFN_SET_MAC_UNASSOC;
+
+ memcpy(pfn_mac.mac, request->mac_addr, ETH_ALEN);
+ mac_mask = request->mac_addr_mask;
+ for (i = 0; i < ETH_ALEN; i++) {
+ pfn_mac.mac[i] &= mac_mask[i];
+ pfn_mac.mac[i] |= get_random_int() & ~(mac_mask[i]);
+ }
+ /* Clear multi bit */
+ pfn_mac.mac[0] &= 0xFE;
+ /* Set locally administered */
+ pfn_mac.mac[0] |= 0x02;
+
+ err = brcmf_fil_iovar_data_set(ifp, "pfn_macaddr", &pfn_mac,
+ sizeof(pfn_mac));
+ if (err)
+ brcmf_err("pfn_macaddr failed, err=%d\n", err);
+
+ return err;
+}
+
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.h
new file mode 100644
index 0000000..08d701e
--- /dev/null
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pno.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2016 Broadcom
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+ * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+ * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+#ifndef _BRCMF_PNO_H
+#define _BRCMF_PNO_H
+
+#define BRCMF_PNO_SCAN_COMPLETE 1
+#define BRCMF_PNO_WPA_AUTH_ANY 0xFFFFFFFF
+#define BRCMF_PNO_HIDDEN_BIT 2
+#define BRCMF_PNO_MAX_PFN_COUNT 16
+
+/**
+ * brcmf_pno_clean - disable and clear pno in firmware.
+ *
+ * @ifp: interface object used.
+ */
+int brcmf_pno_clean(struct brcmf_if *ifp);
+
+/**
+ * brcmf_pno_config - configure pno parameters.
+ *
+ * @ifp: interface object used.
+ * @request: scheduled scan parameters.
+ */
+int brcmf_pno_config(struct brcmf_if *ifp,
+ struct cfg80211_sched_scan_request *request);
+
+#endif /* _BRCMF_PNO_H */
--
1.9.1
^ 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