Linux wireless drivers development
 help / color / mirror / Atom feed
* 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

* [PATCH 2/4] mac80211: Remove unused 'len' 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 633e27132625 (mac80211: split sched scan IEs) introduced the
len variable to keep track of the return value of
ieee80211_build_preq_ies() but did not use it. Compiling with W=1
gives the following warning, fix it.

net/mac80211/scan.c: In function ‘__ieee80211_request_sched_scan_start’:
net/mac80211/scan.c:1123:9: warning: variable ‘len’ set but not used [-Wunused-but-set-variable]

This is a harmless warning and is only being fixed to reduce the noise
with W=1 in the kernel.

Fixes: 633e27132625 ("mac80211: split sched scan IEs")
Cc: David Spinadel <david.spinadel@intel.com>
Cc: Alexander Bondar <alexander.bondar@intel.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
---
 net/mac80211/scan.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 23d8ac8..faab3c4 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -1120,7 +1120,6 @@ int __ieee80211_request_sched_scan_start(struct ieee80211_sub_if_data *sdata,
 	u32 rate_masks[NUM_NL80211_BANDS] = {};
 	u8 bands_used = 0;
 	u8 *ie;
-	size_t len;
 
 	iebufsz = local->scan_ies_len + req->ie_len;
 
@@ -1145,10 +1144,9 @@ int __ieee80211_request_sched_scan_start(struct ieee80211_sub_if_data *sdata,
 
 	ieee80211_prepare_scan_chandef(&chandef, req->scan_width);
 
-	len = ieee80211_build_preq_ies(local, ie, num_bands * iebufsz,
-				       &sched_scan_ies, req->ie,
-				       req->ie_len, bands_used,
-				       rate_masks, &chandef);
+	ieee80211_build_preq_ies(local, ie, num_bands * iebufsz,
+				 &sched_scan_ies, req->ie,
+				 req->ie_len, bands_used, rate_masks, &chandef);
 
 	ret = drv_sched_scan_start(local, sdata, req, &sched_scan_ies);
 	if (ret == 0) {
-- 
2.8.0.rc3.226.g39d4020

^ permalink raw reply related

* [PATCH 3/4] mac80211: Removed unused 'struct ieee80211_supported_band*' variable
From: Kirtika Ruchandani @ 2016-11-24  4:46 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 b1bce14a7954 (mac80211: update opmode when adding new station)
refactored ieee80211_vht_handle_opmode into __ieee80211_vht_handle_opmode
and ieee80211_vht_handle_opmode leaving a set but unused variable
(sband) in the former. Compiling with W=1 gives the following warning,
fix it.

net/mac80211/vht.c: In function ‘__ieee80211_vht_handle_opmode’:
net/mac80211/vht.c:424:35: warning: variable ‘sband’ set but not used [-Wunused-but-set-variable]

Remove 'struct ieee80211_local* local' as well, it was only used to
set sband.

This is a harmless warning, and is only being fixed to reduce the
noise with W=1 in the kernel.

Fixes: b1bce14a7954 ("mac80211: update opmode when adding new station")
Cc: Marek Kwaczynski <marek.kwaczynski@tieto.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
---
 net/mac80211/vht.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
index ee71576..14920e3 100644
--- a/net/mac80211/vht.c
+++ b/net/mac80211/vht.c
@@ -420,14 +420,10 @@ u32 __ieee80211_vht_handle_opmode(struct ieee80211_sub_if_data *sdata,
 				  struct sta_info *sta, u8 opmode,
 				  enum nl80211_band band)
 {
-	struct ieee80211_local *local = sdata->local;
-	struct ieee80211_supported_band *sband;
 	enum ieee80211_sta_rx_bandwidth new_bw;
 	u32 changed = 0;
 	u8 nss;
 
-	sband = local->hw.wiphy->bands[band];
-
 	/* ignore - no support for BF yet */
 	if (opmode & IEEE80211_OPMODE_NOTIF_RX_NSS_TYPE_BF)
 		return 0;
-- 
2.8.0.rc3.226.g39d4020

^ permalink raw reply related

* [PATCH 4/4] mac80211: Remove unused 'beaconint_us' variable
From: Kirtika Ruchandani @ 2016-11-24  4:46 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 4a733ef1bea7 (mac80211: remove PM-QoS listener) removed all use
of 'beaconint_us' from ieee80211_recalc_ps() but left the variable
intact. Compiling with W=1 gives the following warning, fix it.
net/mac80211/mlme.c: In function ‘ieee80211_recalc_ps’:
net/mac80211/mlme.c:1481:7: warning: variable ‘beaconint_us’ set but not used [-Wunused-but-set-variable]

iee80211_tu_to_usec has no side-effects and is safe to remove.

Fixes: 4a733ef1bea7 ("mac80211: remove PM-QoS listener")
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
---
 net/mac80211/mlme.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 7486f2d..e883345 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1478,10 +1478,6 @@ void ieee80211_recalc_ps(struct ieee80211_local *local)
 
 	if (count == 1 && ieee80211_powersave_allowed(found)) {
 		u8 dtimper = found->u.mgd.dtim_period;
-		s32 beaconint_us;
-
-		beaconint_us = ieee80211_tu_to_usec(
-					found->vif.bss_conf.beacon_int);
 
 		timeout = local->dynamic_ps_forced_timeout;
 		if (timeout < 0)
-- 
2.8.0.rc3.226.g39d4020

^ permalink raw reply related

* Re: ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: miaoqing @ 2016-11-24  6:06 UTC (permalink / raw)
  To: Jason Cooper, 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: <aaba8b1e30dd4c22be52e50befb202b2@aptaiexm02f.ap.qualcomm.com>


>> 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.
> 

A similar patch was applied to ath-next branch: 
https://patchwork.kernel.org/patch/9431163/.

--
Miaoqing

^ permalink raw reply

* [PATCH] adm80211: Removed unused 'io_addr' 'mem_addr' variables
From: Kirtika Ruchandani @ 2016-11-24  6:40 UTC (permalink / raw)
  To: Kalle Valo; +Cc: Arnd Bergmann, Johannes Berg, linux-wireless, netdev

Initial commit cc0b88cf5ecf ([PATCH] Add adm8211 802.11b wireless driver)
introduced variables mem_addr and io_addr in adm80211_probe() that are
set but not used. Compiling with W=1 gives the following warnings,
fix them.

drivers/net/wireless/admtek/adm8211.c: In function ‘adm8211_probe’:
drivers/net/wireless/admtek/adm8211.c:1769:15: warning: variable ‘io_addr’ set but not used [-Wunused-but-set-variable]
  unsigned int io_addr, io_len;
               ^
drivers/net/wireless/admtek/adm8211.c:1768:16: warning: variable ‘mem_addr’ set but not used [-Wunused-but-set-variable]
  unsigned long mem_addr, mem_len;
                ^

These are harmless warnings and are only being fixed to reduce the
noise with W=1 in the kernel. The calls to pci_resource_start do not
have any side-effects and are safe to remove.

Fixes: cc0b88cf5ecf ("[PATCH] Add adm8211 802.11b wireless driver")
Cc: Michael Wu <flamingice@sourmilk.net>
Cc: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
---
 drivers/net/wireless/admtek/adm8211.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/admtek/adm8211.c b/drivers/net/wireless/admtek/adm8211.c
index 70ecd82..70b4da0 100644
--- a/drivers/net/wireless/admtek/adm8211.c
+++ b/drivers/net/wireless/admtek/adm8211.c
@@ -1765,8 +1765,8 @@ static int adm8211_probe(struct pci_dev *pdev,
 {
	struct ieee80211_hw *dev;
	struct adm8211_priv *priv;
-	unsigned long mem_addr, mem_len;
-	unsigned int io_addr, io_len;
+	unsigned long mem_len;
+	unsigned int io_len;
	int err;
	u32 reg;
	u8 perm_addr[ETH_ALEN];
@@ -1778,9 +1778,7 @@ static int adm8211_probe(struct pci_dev *pdev,
		return err;
	}

-	io_addr = pci_resource_start(pdev, 0);
	io_len = pci_resource_len(pdev, 0);
-	mem_addr = pci_resource_start(pdev, 1);
	mem_len = pci_resource_len(pdev, 1);
	if (io_len < 256 || mem_len < 1024) {
		printk(KERN_ERR "%s (adm8211): Too short PCI resources\n",
--
2.8.0.rc3.226.g39d4020

^ permalink raw reply related

* [PATCH 1/3] ath9k: Add a module parameter to set btcoex duty cycle
From: miaoqing @ 2016-11-24  6:53 UTC (permalink / raw)
  To: kvalo; +Cc: linux-wireless, ath9k-devel, Miaoqing Pan

From: Miaoqing Pan <miaoqing@codeaurora.org>

btcoex duty cyle allows user to balance the performance
between WLAN and BT.

Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
---
 drivers/net/wireless/ath/ath9k/gpio.c |  4 +---
 drivers/net/wireless/ath/ath9k/init.c | 10 ++++++++++
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/gpio.c b/drivers/net/wireless/ath/ath9k/gpio.c
index ddb2886..782a2f2 100644
--- a/drivers/net/wireless/ath/ath9k/gpio.c
+++ b/drivers/net/wireless/ath/ath9k/gpio.c
@@ -278,7 +278,7 @@ static void ath_init_btcoex_timer(struct ath_softc *sc)
 	struct ath_btcoex *btcoex = &sc->btcoex;
 
 	btcoex->btcoex_period = ATH_BTCOEX_DEF_BT_PERIOD;
-	btcoex->btcoex_no_stomp = (100 - ATH_BTCOEX_DEF_DUTY_CYCLE) *
+	btcoex->btcoex_no_stomp = (100 - btcoex->duty_cycle) *
 		btcoex->btcoex_period / 100;
 	btcoex->btscan_no_stomp = (100 - ATH_BTCOEX_BTSCAN_DUTY_CYCLE) *
 				   btcoex->btcoex_period / 100;
@@ -433,8 +433,6 @@ int ath9k_init_btcoex(struct ath_softc *sc)
 		break;
 	case ATH_BTCOEX_CFG_MCI:
 		ath_init_btcoex_timer(sc);
-
-		sc->btcoex.duty_cycle = ATH_BTCOEX_DEF_DUTY_CYCLE;
 		INIT_LIST_HEAD(&sc->btcoex.mci.info);
 		ath9k_hw_btcoex_init_mci(ah);
 
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 368d9b3..8edd78b 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -73,6 +73,12 @@ struct ath9k_eeprom_ctx {
 
 #endif /* CONFIG_ATH9K_CHANNEL_CONTEXT */
 
+#ifdef CONFIG_ATH9K_BTCOEX_SUPPORT
+static int ath9k_btcoex_duty_cycle = ATH_BTCOEX_DEF_DUTY_CYCLE;
+module_param_named(btcoex_duty_cycle, ath9k_btcoex_duty_cycle, int, 0444);
+MODULE_PARM_DESC(btcoex_duty_cycle, "BT coexistence duty cycle");
+#endif
+
 bool is_ath9k_unloaded;
 
 #ifdef CONFIG_MAC80211_LEDS
@@ -587,6 +593,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
 	sc->sc_ah = ah;
 	sc->dfs_detector = dfs_pattern_detector_init(common, NL80211_DFS_UNSET);
 	sc->tx99_power = MAX_RATE_POWER + 1;
+
 	init_waitqueue_head(&sc->tx_wait);
 	sc->cur_chan = &sc->chanctx[0];
 	if (!ath9k_is_chanctx_enabled())
@@ -602,6 +609,9 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
 	common->btcoex_enabled = ath9k_btcoex_enable == 1;
 	common->disable_ani = false;
 
+#ifdef CONFIG_ATH9K_BTCOEX_SUPPORT
+	sc->btcoex.duty_cycle = ath9k_btcoex_duty_cycle;
+#endif
 	/*
 	 * Platform quirks.
 	 */
-- 
1.9.1

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox