Re: [1/6] mwifiex: parse adhoc start/join result

[Kalle Valo]

> Even if ADHOC start or join attempt is failed, these commands
> are returned with success status by firmware. Actual connection
> result is provided inside command response.
> 
> This patch parses the adhoc connection result and resets
> connection state variables if connection is not successful.
> 
> Signed-off-by: Amitkumar Karwar 
> Signed-off-by: Cathy Luo 

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

d5556e87610e mwifiex: parse adhoc start/join result
d2b0c735ebac mwifiex: handle start AP error paths correctly
658cb59232b1 mwifiex: set regulatory info from EEPROM
947d315257f9 mwifiex: don't follow AP if country code received from EEPROM
7cfd829cfe55 mwifiex: correction in region code to country mapping

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

Re: [v2] wlcore/wl12xx: spi: fix oops on firmware load

[Kalle Valo]

> The maximum chunks used by the function is
> (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE + 1).
> The original commands array had space for
> (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) commands.
> When the last chunk is used (len > 4 * WSPI_MAX_CHUNK_SIZE), the last
> command is stored outside the bounds of the commands array.
> 
> Oops 5 (page fault) is generated during current wl1271 firmware load
> attempt:
> 
> root@debian-armhf:~# ifconfig wlan0 up
> [  294.312399] Unable to handle kernel paging request at virtual address
> 00203fc4
> [  294.320173] pgd = de528000
> [  294.323028] [00203fc4] *pgd=
> [  294.326916] Internal error: Oops: 5 [#1] SMP ARM
> [  294.331789] Modules linked in: bnep rfcomm bluetooth ipv6 arc4 wl12xx
> wlcore mac80211 musb_dsps cfg80211 musb_hdrc usbcore usb_common
> wlcore_spi omap_rng rng_core musb_am335x omap_wdt cpufreq_dt thermal_sys
> hwmon
> [  294.351838] CPU: 0 PID: 1827 Comm: ifconfig Not tainted
> 4.2.0-2-g3e9ad27-dirty #78
> [  294.360154] Hardware name: Generic AM33XX (Flattened Device Tree)
> [  294.366557] task: dc9d6d40 ti: de55 task.ti: de55
> [  294.372236] PC is at __spi_validate+0xa8/0x2ac
> [  294.376902] LR is at __spi_sync+0x78/0x210
> [  294.381200] pc : []lr : []psr: 6013
> [  294.381200] sp : de551998  ip : de5519d8  fp : 0020
> [  294.393242] r10: de551c8c  r9 : de5519d8  r8 : de3a9000
> [  294.398730] r7 : de3a9258  r6 : de3a9400  r5 : de551a48  r4 :
> 00203fbc
> [  294.405577] r3 :   r2 :   r1 :   r0 :
> de3a9000
> [  294.412420] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
> Segment user
> [  294.419918] Control: 10c5387d  Table: 9e528019  DAC: 0015
> [  294.425954] Process ifconfig (pid: 1827, stack limit = 0xde550218)
> [  294.432437] Stack: (0xde551998 to 0xde552000)
> 
> ...
> 
> [  294.883613] [] (__spi_validate) from []
> (__spi_sync+0x78/0x210)
> [  294.891670] [] (__spi_sync) from []
> (wl12xx_spi_raw_write+0xfc/0x148 [wlcore_spi])
> [  294.901661] [] (wl12xx_spi_raw_write [wlcore_spi]) from
> [] (wlcore_boot_upload_firmware+0x1ec/0x458 [wlcore])
> [  294.914038] [] (wlcore_boot_upload_firmware [wlcore]) from
> [] (wl12xx_boot+0xc10/0xfac [wl12xx])
> [  294.925161] [] (wl12xx_boot [wl12xx]) from []
> (wl1271_op_add_interface+0x5b0/0x910 [wlcore])
> [  294.936364] [] (wl1271_op_add_interface [wlcore]) from
> [] (ieee80211_do_open+0x44c/0xf7c [mac80211])
> [  294.947963] [] (ieee80211_do_open [mac80211]) from
> [] (__dev_open+0xa8/0x110)
> [  294.957307] [] (__dev_open) from []
> (__dev_change_flags+0x88/0x148)
> [  294.965713] [] (__dev_change_flags) from []
> (dev_change_flags+0x18/0x48)
> [  294.974576] [] (dev_change_flags) from []
> (devinet_ioctl+0x6b4/0x7d0)
> [  294.983191] [] (devinet_ioctl) from []
> (sock_ioctl+0x1e4/0x2bc)
> [  294.991244] [] (sock_ioctl) from []
> (do_vfs_ioctl+0x420/0x6b0)
> [  294.999208] [] (do_vfs_ioctl) from []
> (SyS_ioctl+0x6c/0x7c)
> [  295.006880] [] (SyS_ioctl) from []
> (ret_fast_syscall+0x0/0x54)
> [  295.014835] Code: e1550004 e2444034 0a7d e5953018 (e5942008)
> [  295.021544] ---[ end trace 66ed188198f4e24e ]---
> 
> Signed-off-by: Uri Mashiach 
> Acked-by: Igor Grinberg 
> Cc: sta...@vger.kernel.org

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

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

RE: [PATCH 5/6] mwifiex: add iw vendor command support

[Amitkumar Karwar]

Hi Kalle,

> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Friday, December 11, 2015 2:32 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam; Jeff
> CF Chen
> Subject: Re: [PATCH 5/6] mwifiex: add iw vendor command support
> 
> Amitkumar Karwar  writes:
> 
> > From: chunfan chen 
> >
> > The patch allows user to
> > 1. Enable turbo mode in firmware using following command.
> > iw dev mlan0 vendor send 0x005043 0x00 0x01
> >
> > 2. Download configuration data to FW using following command iw dev
> > mlan0 vendor send 0x005043 0x01 filename
> >
> > Signed-off-by: chunfan chen 
> > Signed-off-by: Amitkumar Karwar 
> 
> Stuff like this gives me nightmares and I'm going to put this patch to
> deferred state for now as I don't want to even think what to do. In the
> mean time people can convince me should I take this or not.
> 

Actually we intend to download following types of configuration data in hex 
format to firmware.
1)  Txpower limit table - It includes information about maximum allowed 
transmit power limits for all data rates and channels combination.
2)  Device calibration data

I support "iw vendor" gives an option to download hex data. 

Could you please guide how can we improve this patch? OR Any other better 
approach to meet the requirement?

Regards,
Amitkumar

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

Re: [PATCH V2 13/13] brcmfmac: add arp offload ip address table configuration support

[Kalle Valo]

Arend van Spriel  writes:

> On 12/10/2015 01:43 PM, Arend van Spriel wrote:
>> From: Franky Lin 
>>
>> Obtain ipv4 address through inetaddr notification for ARP offload host
>> ip table configuration.
>
> Turns out this patch has a sparse warning, ie. would not work on
> big-endian system. We have a fix for that. Should I mark this patch as
> dropped in patchwork?

Yeah, that's the best way. For example you could use state "Changes
Requested" and then it automatically gets dropped from my queue.

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

Re: prism54: fix compare_const_fl.cocci warnings

[Kalle Valo]

> Move constants to the right of binary operators.
> 
> Generated by: scripts/coccinelle/misc/compare_const_fl.cocci
> 
> Signed-off-by: Fengguang Wu 
> Signed-off-by: Julia Lawall 

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

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

Re: cw1200: remove some dead code

[Kalle Valo]

> If the mode is NL80211_IFTYPE_UNSPECIFIED then we return success at the
> start of the function so this condition is never true.
> 
> Signed-off-by: Dan Carpenter 

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

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

Re: iwlegacy: cleanup end of il_send_add_sta()

[Kalle Valo]

> This code causes a static checker warning because we check for
> "if (ret == 0)" but we have already had verified that was true.  Clean
> it up a little.
> 
> Signed-off-by: Dan Carpenter 
> Acked-by: Stanislaw Gruszka 

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

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

Re: mwifiex: fix semicolon.cocci warnings

[Kalle Valo]

> Remove unneeded semicolon.
> 
> Generated by: scripts/coccinelle/misc/semicolon.cocci
> 
> Signed-off-by: Fengguang Wu 
> Signed-off-by: Julia Lawall 

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

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

Re: mwifiex: remove an unneeded condition

[Kalle Valo]

> We already know that "wep_key->key_length" is set so there is no need to
> check again.  Also the last curly brace was indented too far.
> 
> Signed-off-by: Dan Carpenter 

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

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

Re: prism54: off by one BUG_ON() test

[Kalle Valo]

> This code was supposed to trigger a BUG() if we truncate the output but
> it's off by one so it allows one character to be truncated.  Really
> drivers shouldn't call BUG_ON() and especially for something minor like
> this so I've changed it to a WARN_ON().
> 
> Signed-off-by: Dan Carpenter 

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

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

Re: brcm80211: fix compare_const_fl.cocci warnings

[Kalle Valo]

> Move constants to the right of binary operators.
> 
> Generated by: scripts/coccinelle/misc/compare_const_fl.cocci
> 
> Signed-off-by: Fengguang Wu 
> Signed-off-by: Julia Lawall 

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

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

Re: iwlegacy: mark il_adjust_beacon_interval as noinline

[Kalle Valo]

> With the new optimized do_div() code, some versions of gcc
> produce obviously incorrect code that leads to a link error
> in iwlegacy/common.o:
> 
> drivers/built-in.o: In function `il_send_rxon_timing':
> :(.text+0xa6b4d4): undefined reference to `ilog2_NaN'
> :(.text+0xa6b4f0): undefined reference to `__aeabi_uldivmod'
> 
> In a few thousand randconfig builds, I have seen this problem
> a couple of times in this file, but never anywhere else in the
> kernel, so we can try to work around this in the only file
> that shows the behavior, by marking the il_adjust_beacon_interval
> function as noinline, which convinces gcc to use the unoptimized
> do_div() all the time.
> 
> Signed-off-by: Arnd Bergmann 
> Acked-by: Nicolas Pitre 
> Acked-by: Stanislaw Gruszka 

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

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

Re: [PATCH V2 13/13] brcmfmac: add arp offload ip address table configuration support

[Arend van Spriel]

On 12/11/2015 10:29 AM, Kalle Valo wrote:

Arend van Spriel  writes:


On 12/10/2015 01:43 PM, Arend van Spriel wrote:

From: Franky Lin 

Obtain ipv4 address through inetaddr notification for ARP offload host
ip table configuration.


Turns out this patch has a sparse warning, ie. would not work on
big-endian system. We have a fix for that. Should I mark this patch as
dropped in patchwork?


Yeah, that's the best way. For example you could use state "Changes
Requested" and then it automatically gets dropped from my queue.


will do that.

Thanks,
Arend


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

Re: brcmfmac: only lock and unlock fws if fws is not null

[Kalle Valo]

> From: Colin Ian King 
> 
> There is a null ptr check for fws to set bcmc_credit_check, however,
> there a lock and unlock on fws should only performed if fwts is
> also not null to also avoid a potential null pointer deference.
> 
> Signed-off-by: Colin Ian King 
> Acked-by: Arend van Spriel 

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

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

Re: [V2] wlcore: split wl12xx/wl18xx sg parameters

[Kalle Valo]

> Align to new wl18xx sg parameters.
> This requires to split both wl12xx/wl18xx enumerators.
> 
> Signed-off-by: Guy Mishol 
> Acked-by: Eliad Peller 

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

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

Re: hostap: fix an error code in prism2_config()

[Kalle Valo]

> The current code returns success if prism2_init_local_data() fails, but
> we want to return an error code.  Also we can remove the bogus
> ret initializer because it is wrong and never used.
> 
> Signed-off-by: Dan Carpenter 

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

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

Re: [v2] rtlwifi: fix memory leak for USB device

[Kalle Valo]

> Free skb for received frames with a wrong checksum. This can happen
> pretty rapidly, exhausting all memory.
> 
> This fixes a memleak (detected with kmemleak). Originally found while
> using monitor mode, but it also appears during managed mode (once the
> link is up).
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Peter Wu 
> ACKed-by: Larry Finger 

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

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

Re: [PATCH] ath9k: fix inconsistent indenting on return statement

[Kalle Valo]

Colin King  writes:

> From: Colin Ian King 
>
> minor change, indenting is one tab out.
>
> Signed-off-by: Colin Ian King 

Applied to ath.git, thanks.

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

Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

[Johannes Berg]

On Mon, 2015-11-23 at 09:37 +0800, Dave Young wrote:

> Seems there're a lot of other wireless messages. Should we refactor 
> them as well? I still did not get chance to see where is the code.
> (My wireless driver being used is iwlwifi)

Most are probably from net/mac80211/.

> # dmesg|grep "Limiting TX power"|wc
>    4128   49600  360052
> 

I fixed this one recently, due to a bug it was printed all the time
instead of just once when taking effect.

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

Re: [PATCH] wcn36xx: handle rx skb allocation failure to avoid system crash

[fengwei.yin]

On 2015/12/2 13:27, Fengwei Yin wrote:

Lawrence reported that git clone could make system crash on a
Qualcomm ARM soc based device (DragonBoard, 1G memory without
swap) running 64bit Debian.

It's turned out the crash is related with rx skb allocation
failure. git could consume more than 600MB anonymous memory.
And system is in extremely memory shortage case.

But driver didn't handle the rx allocation failure case. This patch
doesn't submit skb to upper layer if rx skb allocation fails.
Instead, it reuse the old skb for rx DMA again. It's more like
drop the packets if system is in memory shortage case.

With this change, git clone is OOMed instead of system crash.

Reported-by: King, Lawrence 
Signed-off-by: Fengwei Yin 
---
  drivers/net/wireless/ath/wcn36xx/dxe.c | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
b/drivers/net/wireless/ath/wcn36xx/dxe.c
index f8dfa05..8887c0f 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -474,11 +474,20 @@ static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
struct wcn36xx_dxe_desc *dxe = ctl->desc;
dma_addr_t  dma_addr;
struct sk_buff *skb;
+   int ret = 0;

while (!(dxe->ctrl & WCN36XX_DXE_CTRL_VALID_MASK)) {
skb = ctl->skb;
dma_addr = dxe->dst_addr_l;
-   wcn36xx_dxe_fill_skb(wcn->dev, ctl);
+   ret = wcn36xx_dxe_fill_skb(wcn->dev, ctl);
+   if (0 == ret) {
+   /* new skb allocation ok. Use the new one and queue
+* the old one to network system.
+*/
+   dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
+   DMA_FROM_DEVICE);
+   wcn36xx_rx_skb(wcn, skb);
+   }

switch (ch->ch_type) {
case WCN36XX_DXE_CH_RX_L:
@@ -495,9 +504,6 @@ static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
wcn36xx_warn("Unknown channel\n");
}

-   dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
-DMA_FROM_DEVICE);
-   wcn36xx_rx_skb(wcn, skb);
ctl = ctl->next;
dxe = ctl->desc;
}



Ping I am sure this is a fix according to the test I did.

Regards
Yin, Fengwei

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

Re: [PATCH v3] ath9k: feeding entropy in kernel from ADC capture

[Kalle Valo]

miaoq...@codeaurora.org writes:

> From: Miaoqing Pan 
>
> This patch is derived from
> commit 6301566e0b2d ("ath9k: export HW random number generator"),
>
> We evaluated the entropy of the ADC data on QCA9531, QCA9561, QCA955x,
> and AR9340, and it has sufficient quality random data (at least 10 bits
> and up to 22 bits of min-entropy for a 32-bit value). We conservatively
> assume the min-entropy is 10 bits out of 32 bits. Thus, ATH9K_RNG_BUF_SIZE
> is set to 320 (u32) i.e., 1.25 kilobytes of data is inserted to fill up
> the pool as soon as the entropy counter becomes 896/4096 (set by random.c).
> Since ADC was not designed to be a dedicated HW RNG, we do not want to bind
> it to /dev/hwrng framework directly. This patch feeds the entropy directly
> from the WiFi driver to the input pool. The ADC register output is only
> used as a seed for the Linux entropy pool. No conditioning is needed,
> since all the conditioning is performed by the pool itself.
>
> Signed-off-by: Miaoqing Pan 

Applied to ath.git, thanks.

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

[PATCHv2] mac80211: allow drivers to report (non-)monitor frames

[Grzegorz Bajorski]

Some drivers offload some frames internally (e.g.
AddBa). Reporting such frames to mac80211 would
only confuse MLME. However it would be useful to
be able to pass such frames to monitor interfaces
for sniffing purposes, e.g. when running AP +
monitor.

To do that allow drivers to tell mac80211 whether
a given frame should be:
 - processed but not delivered to any monitor vif
 - not processed but delievered to monitor vifs
   only

Signed-off-by: Grzegorz Bajorski 
---

Notes:
v2:
 * fix commit log [Johannes]

 include/net/mac80211.h | 11 +++
 net/mac80211/rx.c  |  5 +++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 7c30faf..a35e584 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1014,6 +1014,14 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info 
*info)
  * @RX_FLAG_AMPDU_DELIM_CRC_KNOWN: The delimiter CRC field is known (the CRC
  * is stored in the @ampdu_delimiter_crc field)
  * @RX_FLAG_LDPC: LDPC was used
+ * @RX_FLAG_ONLY_MONITOR: Report frame only to monitor interfaces without
+ * processing it in any regular way.
+ * This is useful if drivers offload some frames but still want to report
+ * them for sniffing purposes.
+ * @RX_FLAG_SKIP_MONITOR: Process and report frame to all interfaces except
+ * monitor interfaces.
+ * This is useful if drivers offload some frames but still want to report
+ * them for sniffing purposes.
  * @RX_FLAG_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3
  * @RX_FLAG_10MHZ: 10 MHz (half channel) was used
  * @RX_FLAG_5MHZ: 5 MHz (quarter channel) was used
@@ -1054,6 +1062,8 @@ enum mac80211_rx_flags {
RX_FLAG_MACTIME_END = BIT(21),
RX_FLAG_VHT = BIT(22),
RX_FLAG_LDPC= BIT(23),
+   RX_FLAG_ONLY_MONITOR= BIT(24),
+   RX_FLAG_SKIP_MONITOR= BIT(25),
RX_FLAG_STBC_MASK   = BIT(26) | BIT(27),
RX_FLAG_10MHZ   = BIT(28),
RX_FLAG_5MHZ= BIT(29),
@@ -1072,6 +1082,7 @@ enum mac80211_rx_flags {
  * @RX_VHT_FLAG_160MHZ: 160 MHz was used
  * @RX_VHT_FLAG_BF: packet was beamformed
  */
+
 enum mac80211_rx_vht_flags {
RX_VHT_FLAG_80MHZ   = BIT(0),
RX_VHT_FLAG_160MHZ  = BIT(1),
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 1f82753..43ad7a5 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -122,7 +122,8 @@ static inline bool should_drop_frame(struct sk_buff *skb, 
int present_fcs_len,
hdr = (void *)(skb->data + rtap_vendor_space);
 
if (status->flag & (RX_FLAG_FAILED_FCS_CRC |
-   RX_FLAG_FAILED_PLCP_CRC))
+   RX_FLAG_FAILED_PLCP_CRC |
+   RX_FLAG_ONLY_MONITOR))
return true;
 
if (unlikely(skb->len < 16 + present_fcs_len + rtap_vendor_space))
@@ -507,7 +508,7 @@ ieee80211_rx_monitor(struct ieee80211_local *local, struct 
sk_buff *origskb,
return NULL;
}
 
-   if (!local->monitors) {
+   if (!local->monitors || (status->flag & RX_FLAG_SKIP_MONITOR)) {
if (should_drop_frame(origskb, present_fcs_len,
  rtap_vendor_space)) {
dev_kfree_skb(origskb);
-- 
2.3.7

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

Re: [PATCH] wcn36xx: handle rx skb allocation failure to avoid system crash

[fengwei.yin]

On 2015/12/11 21:37, Bob Copeland wrote:

On Fri, Dec 11, 2015 at 09:14:04PM +0800, fengwei.yin wrote:


On 2015/12/2 13:27, Fengwei Yin wrote:

Lawrence reported that git clone could make system crash on a
Qualcomm ARM soc based device (DragonBoard, 1G memory without
swap) running 64bit Debian.

It's turned out the crash is related with rx skb allocation
failure. git could consume more than 600MB anonymous memory.
And system is in extremely memory shortage case.

But driver didn't handle the rx allocation failure case. This patch
doesn't submit skb to upper layer if rx skb allocation fails.
Instead, it reuse the old skb for rx DMA again. It's more like
drop the packets if system is in memory shortage case.

With this change, git clone is OOMed instead of system crash.

Reported-by: King, Lawrence 
Signed-off-by: Fengwei Yin 


Concept makes sense to me, but:

Thanks for looking at it.




dma_addr = dxe->dst_addr_l;
-   wcn36xx_dxe_fill_skb(wcn->dev, ctl);
+   ret = wcn36xx_dxe_fill_skb(wcn->dev, ctl);
+   if (0 == ret) {


I find this "success handling" to be unclear and traditionally this
kind of thing is a source of bugs; how about instead:


+   /* new skb allocation ok. Use the new one and queue
+* the old one to network system.
+*/
+   dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
+   DMA_FROM_DEVICE);
+   wcn36xx_rx_skb(wcn, skb);
+   }


ret = wcn36xx_dxe_fill_skb(wcn->dev, ctl);

/* skip this frame if we can't alloc a new rx buffer */
if (ret)
   goto drop;

This can't work because we need to initialize the DMA for the old skb again.
Which is done in following
switch (ch->ch_type) {
block.

Regards
Yin, Fengwei




switch (ch->ch_type) {
case WCN36XX_DXE_CH_RX_L:
@@ -495,9 +504,6 @@ static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
wcn36xx_warn("Unknown channel\n");
}

-   dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
-DMA_FROM_DEVICE);
-   wcn36xx_rx_skb(wcn, skb);


drop:


ctl = ctl->next;
dxe = ctl->desc;
}



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

Re: [PATCH] wcn36xx: handle rx skb allocation failure to avoid system crash

[Bob Copeland]

On Fri, Dec 11, 2015 at 09:14:04PM +0800, fengwei.yin wrote:
> 
> On 2015/12/2 13:27, Fengwei Yin wrote:
> >Lawrence reported that git clone could make system crash on a
> >Qualcomm ARM soc based device (DragonBoard, 1G memory without
> >swap) running 64bit Debian.
> >
> >It's turned out the crash is related with rx skb allocation
> >failure. git could consume more than 600MB anonymous memory.
> >And system is in extremely memory shortage case.
> >
> >But driver didn't handle the rx allocation failure case. This patch
> >doesn't submit skb to upper layer if rx skb allocation fails.
> >Instead, it reuse the old skb for rx DMA again. It's more like
> >drop the packets if system is in memory shortage case.
> >
> >With this change, git clone is OOMed instead of system crash.
> >
> >Reported-by: King, Lawrence 
> >Signed-off-by: Fengwei Yin 

Concept makes sense to me, but:

> > dma_addr = dxe->dst_addr_l;
> >-wcn36xx_dxe_fill_skb(wcn->dev, ctl);
> >+ret = wcn36xx_dxe_fill_skb(wcn->dev, ctl);
> >+if (0 == ret) {

I find this "success handling" to be unclear and traditionally this
kind of thing is a source of bugs; how about instead:

> >+/* new skb allocation ok. Use the new one and queue
> >+ * the old one to network system.
> >+ */
> >+dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
> >+DMA_FROM_DEVICE);
> >+wcn36xx_rx_skb(wcn, skb);
> >+}

   ret = wcn36xx_dxe_fill_skb(wcn->dev, ctl);

   /* skip this frame if we can't alloc a new rx buffer */
   if (ret)
  goto drop;

> > switch (ch->ch_type) {
> > case WCN36XX_DXE_CH_RX_L:
> >@@ -495,9 +504,6 @@ static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
> > wcn36xx_warn("Unknown channel\n");
> > }
> >
> >-dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
> >- DMA_FROM_DEVICE);
> >-wcn36xx_rx_skb(wcn, skb);

drop:

> > ctl = ctl->next;
> > dxe = ctl->desc;
> > }

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

Re: [PATCH 1/2] ath6kl: fix tx/rx antenna reporting for 2x2 devices.

[Kalle Valo]

gree...@candelatech.com writes:

> From: Ben Greear 
>
> My previous patch incorrectly reported the antenna
> for 2x2 devices.  It should be a mask instead of
> a numeric count.  This patch fixes that.
>
> Signed-off-by: Ben Greear 

Both patches applied, thanks.

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

Re: [linux-next] iwl_mvm_get_key_sta_id() suspicious RCU usage

[Johannes Berg]

On Fri, 2015-12-11 at 22:44 +0900, Sergey Senozhatsky wrote:

> [ 6385.246300] drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1226
> suspicious rcu_dereference_protected() usage!
> 

Funny, Laura Abbott also reported this bug earlier today :)

I've sent out a fix, you can see it here:
https://patchwork.ozlabs.org/patch/87/

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

Re: [PATCH] wcn36xx: handle rx skb allocation failure to avoid system crash

[Bob Copeland]

On Fri, Dec 11, 2015 at 09:44:54PM +0800, fengwei.yin wrote:
> >/* skip this frame if we can't alloc a new rx buffer */
> >if (ret)
> >   goto drop;
> This can't work because we need to initialize the DMA for the old skb again.
> Which is done in following
>   switch (ch->ch_type) {
> block.

Hmm, good point.  You could still move that out to a function like this:

diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
b/drivers/net/wireless/ath/wcn36xx/dxe.c
index f8dfa05..fd447bf 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -467,6 +467,27 @@ out_err:
 
 }
 
+/* or whatever name makes sense... */
+static void wcn36xx_restart_dma(struct wcn36xx *wcn,
+   struct wcn36xx_dxe_ch *ch,
+   struct wcn36xx_dxe_desc *dxe)
+{
+   switch (ch->ch_type) {
+   case WCN36XX_DXE_CH_RX_L:
+   dxe->ctrl = WCN36XX_DXE_CTRL_RX_L;
+   wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
+  WCN36XX_DXE_INT_CH1_MASK);
+   break;
+   case WCN36XX_DXE_CH_RX_H:
+   dxe->ctrl = WCN36XX_DXE_CTRL_RX_H;
+   wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
+  WCN36XX_DXE_INT_CH3_MASK);
+   break;
+   default:
+   wcn36xx_warn("Unknown channel\n");
+   }
+}
+
 static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
 struct wcn36xx_dxe_ch *ch)
 {
@@ -478,26 +499,18 @@ static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
while (!(dxe->ctrl & WCN36XX_DXE_CTRL_VALID_MASK)) {
skb = ctl->skb;
dma_addr = dxe->dst_addr_l;
-   wcn36xx_dxe_fill_skb(wcn->dev, ctl);
+   ret = wcn36xx_dxe_fill_skb(wcn->dev, ctl);
 
-   switch (ch->ch_type) {
-   case WCN36XX_DXE_CH_RX_L:
-   dxe->ctrl = WCN36XX_DXE_CTRL_RX_L;
-   wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
-  WCN36XX_DXE_INT_CH1_MASK);
-   break;
-   case WCN36XX_DXE_CH_RX_H:
-   dxe->ctrl = WCN36XX_DXE_CTRL_RX_H;
-   wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
-  WCN36XX_DXE_INT_CH3_MASK);
-   break;
-   default:
-   wcn36xx_warn("Unknown channel\n");
-   }
+   /* skip this frame in OOM condition */
+   if (ret)
+   goto drop;
 
dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
 DMA_FROM_DEVICE);
wcn36xx_rx_skb(wcn, skb);
+
+drop:
+   wcn36xx_restart_dma(wcn, ch, dxe);
ctl = ctl->next;
dxe = ctl->desc;
}



...that said, not really sure it's worth it now that the 'goto' is only
skipping two lines.  So, I would be ok with the original patch too.

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

[PATCH] cfg80211: remove CFG80211_REG_DEBUG

[Johannes Berg]

From: Johannes Berg 

Instead of having this Kconfig option, which just *floods* the
kernel log,
 * remove the per-channel prints that are fairly useless anyway
 * convert the conditional printing to pr_debug()

Signed-off-by: Johannes Berg 
---
 net/wireless/Kconfig |  13 --
 net/wireless/reg.c   | 122 ++-
 2 files changed, 34 insertions(+), 101 deletions(-)

diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index da72ed32f143..ec3bf30dd526 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -61,19 +61,6 @@ config CFG80211_DEVELOPER_WARNINGS
  on it (or mac80211).
 
 
-config CFG80211_REG_DEBUG
-   bool "cfg80211 regulatory debugging"
-   depends on CFG80211
-   default n
-   ---help---
- You can enable this if you want to debug regulatory changes.
- For more information on cfg80211 regulatory refer to the wireless
- wiki:
-
- http://wireless.kernel.org/en/developers/Regulatory
-
- If unsure, say N.
-
 config CFG80211_CERTIFICATION_ONUS
bool "cfg80211 certification onus"
depends on CFG80211 && EXPERT
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 0a4f5481ab83..6c1ea28f73cf 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -60,13 +60,6 @@
 #include "regdb.h"
 #include "nl80211.h"
 
-#ifdef CONFIG_CFG80211_REG_DEBUG
-#define REG_DBG_PRINT(format, args...) \
-   printk(KERN_DEBUG pr_fmt(format), ##args)
-#else
-#define REG_DBG_PRINT(args...)
-#endif
-
 /*
  * Grace period we give before making sure all current interfaces reside on
  * channels allowed by the current regulatory domain.
@@ -178,12 +171,10 @@ enum nl80211_dfs_regions reg_get_dfs_region(struct wiphy 
*wiphy)
if (wiphy_regd->dfs_region == regd->dfs_region)
goto out;
 
-   REG_DBG_PRINT("%s: device specific dfs_region "
- "(%s) disagrees with cfg80211's "
- "central dfs_region (%s)\n",
- dev_name(>dev),
- reg_dfs_region_str(wiphy_regd->dfs_region),
- reg_dfs_region_str(regd->dfs_region));
+   pr_debug("%s: device specific dfs_region (%s) disagrees with cfg80211's 
central dfs_region (%s)\n",
+dev_name(>dev),
+reg_dfs_region_str(wiphy_regd->dfs_region),
+reg_dfs_region_str(regd->dfs_region));
 
 out:
return regd->dfs_region;
@@ -541,7 +532,7 @@ static DECLARE_DELAYED_WORK(crda_timeout, 
crda_timeout_work);
 
 static void crda_timeout_work(struct work_struct *work)
 {
-   REG_DBG_PRINT("Timeout while waiting for CRDA to reply, restoring 
regulatory settings\n");
+   pr_debug("Timeout while waiting for CRDA to reply, restoring regulatory 
settings\n");
rtnl_lock();
reg_crda_timeouts++;
restore_regulatory_settings(true);
@@ -583,7 +574,7 @@ static int call_crda(const char *alpha2)
 
if (!is_world_regdom((char *) alpha2))
pr_debug("Calling CRDA for country: %c%c\n",
-   alpha2[0], alpha2[1]);
+alpha2[0], alpha2[1]);
else
pr_debug("Calling CRDA to update world regulatory domain\n");
 
@@ -1130,42 +1121,6 @@ const char *reg_initiator_name(enum 
nl80211_reg_initiator initiator)
 }
 EXPORT_SYMBOL(reg_initiator_name);
 
-static void chan_reg_rule_print_dbg(const struct ieee80211_regdomain *regd,
-   struct ieee80211_channel *chan,
-   const struct ieee80211_reg_rule *reg_rule)
-{
-#ifdef CONFIG_CFG80211_REG_DEBUG
-   const struct ieee80211_power_rule *power_rule;
-   const struct ieee80211_freq_range *freq_range;
-   char max_antenna_gain[32], bw[32];
-
-   power_rule = _rule->power_rule;
-   freq_range = _rule->freq_range;
-
-   if (!power_rule->max_antenna_gain)
-   snprintf(max_antenna_gain, sizeof(max_antenna_gain), "N/A");
-   else
-   snprintf(max_antenna_gain, sizeof(max_antenna_gain), "%d mBi",
-power_rule->max_antenna_gain);
-
-   if (reg_rule->flags & NL80211_RRF_AUTO_BW)
-   snprintf(bw, sizeof(bw), "%d KHz, %d KHz AUTO",
-freq_range->max_bandwidth_khz,
-reg_get_max_bandwidth(regd, reg_rule));
-   else
-   snprintf(bw, sizeof(bw), "%d KHz",
-freq_range->max_bandwidth_khz);
-
-   REG_DBG_PRINT("Updating information on frequency %d MHz with regulatory 
rule:\n",
- chan->center_freq);
-
-   REG_DBG_PRINT("(%d KHz - %d KHz @ %s), (%s, %d mBm)\n",
- freq_range->start_freq_khz, freq_range->end_freq_khz,
- bw, max_antenna_gain,
- power_rule->max_eirp);
-#endif
-}
-
 static uint32_t 

Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages

[Johannes Berg]

On Sun, 2015-11-15 at 15:31 +0800, Dave Young wrote:
> cfg80211 module prints a lot of messages like below. Actually
> printing once is acceptable but sometimes it will print again and
> again, it looks very annoying. It is better to change these detail
> messages to debugging only.
> 

Despite the objections, I've applied this patch now.

I've made one change: keeping the alpha2 (e.g. "US") printed in some of
the pr_err() cases in this file.
I also got rid of CONFIG_CFG80211_REG_DEBUG in a separate patch.

I somewhat agree with the objections, but if the kernel is with
CONFIG_DYNAMIC_DEBUG then it's really simple to get the messages back
by enabling them for this file.

Where the messages were used as an indication of something having gone
awry at a different level (e.g. mac80211 disconnect) I don't really
quite agree - that then perhaps should have a more explicit (and less
noisy) message.

I also agree that the regulatory code is quite opaque, and the way it
arrives at certain conclusions is not always obvious. These messages
don't help all that much though since they don't contain the actual
input to the decisions. I think for that, we'd be much better served
with some kind of tracepoint or so that records all the information.

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

[PATCH] regulatory: fix world regulatory domain data

[Johannes Berg]

From: Johannes Berg 

The precise rule definition here isn't really valid, it would
be rejected if it came from userspace due to the bandwidth it
specifies being bigger than the rule's width.

This is fairly much inconsequential since the other rule before
it does enable the bandwidth, but express that better by using
the NL80211_RRF_AUTO_BW flag.

Signed-off-by: Johannes Berg 
---
 net/wireless/reg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index d53ef141055b..ce8b78fc8525 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -222,8 +222,8 @@ static const struct ieee80211_regdomain world_regdom = {
/* IEEE 802.11b/g, channels 1..11 */
REG_RULE(2412-10, 2462+10, 40, 6, 20, 0),
/* IEEE 802.11b/g, channels 12..13. */
-   REG_RULE(2467-10, 2472+10, 40, 6, 20,
-   NL80211_RRF_NO_IR),
+   REG_RULE(2467-10, 2472+10, 20, 6, 20,
+   NL80211_RRF_NO_IR | NL80211_RRF_AUTO_BW),
/* IEEE 802.11 channel 14 - Only JP enables
 * this and for 802.11b only */
REG_RULE(2484-10, 2484+10, 20, 6, 20,
-- 
2.6.2

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

[PATCH] regulatory: fix world regdomain

[Johannes Berg]

From: Johannes Berg 

Back in 2012, in commit 6d87df6f9657 ("regdb: allow 40 MHz on world
roaming channels 12/13") I evidently broke the world regulatory data
to the point where it was always discarded by the kernel because the
40 MHz bandwidth doesn't fit into the rule range.

Around the same time, I updated the in-kernel regulatory domain with
the same mistake, but unlike the userspace data, the in-kernel data
isn't actually checked for validity.

The end result was that the (inconsequentially invalid) data in the
kernel was always used because the userspace data was rejected.

Fix this by changing the rule to 20 MHz and adding the AUTO-BW flag.
It seems that Janusz had made a similar change in commit 5cfc8073ce35
("wireless-regdb: set AUTO bandwidth for world regulatory"), but it
was reverted for unknown reasons a little less than half a year later
(commit cfa3734b11b2).

The kernel uses very similar invalid rules, but it never checks them
for validity and just uses them, so HT40- ends up getting enabled on
these channels. Thus, when the kernel requests the world regdomain
from userspace, gets the invalid data and rejects it, it falls back
to using the built-in data which is very similar and not validated.

I've tested this now, and the ruleset is now accepted by the kernel
and results in the correct data.

This also means that Jouni's 160 MHz fixes were inconsequentialy and
only the corresponding kernel changes could have been used.

Signed-off-by: Johannes Berg 
---
 db.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/db.txt b/db.txt
index a6eb033db25d..13cc7ada23d9 100644
--- a/db.txt
+++ b/db.txt
@@ -2,7 +2,7 @@
 country 00:
(2402 - 2472 @ 40), (20)
# Channel 12 - 13.
-   (2457 - 2482 @ 40), (20), NO-IR
+   (2457 - 2482 @ 20), (20), NO-IR, AUTO-BW
# Channel 14. Only JP enables this and for 802.11b only
(2474 - 2494 @ 20), (20), NO-IR, NO-OFDM
# Channel 36 - 48
-- 
2.6.2

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

[PATCH v2] regulatory: fix world regulatory domain data

[Johannes Berg]

From: Johannes Berg 

The rule definitions here aren't really valid, they would
be rejected if it came from userspace due to the bandwidth
specified being bigger than the rule's width.

This is fairly much inconsequential since the other rules
around them do enable the bandwidth, but express that better
using the NL80211_RRF_AUTO_BW flag.

Signed-off-by: Johannes Berg 
---
 net/wireless/reg.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index d53ef141055b..6474d42b40a9 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -222,20 +222,22 @@ static const struct ieee80211_regdomain world_regdom = {
/* IEEE 802.11b/g, channels 1..11 */
REG_RULE(2412-10, 2462+10, 40, 6, 20, 0),
/* IEEE 802.11b/g, channels 12..13. */
-   REG_RULE(2467-10, 2472+10, 40, 6, 20,
-   NL80211_RRF_NO_IR),
+   REG_RULE(2467-10, 2472+10, 20, 6, 20,
+   NL80211_RRF_NO_IR | NL80211_RRF_AUTO_BW),
/* IEEE 802.11 channel 14 - Only JP enables
 * this and for 802.11b only */
REG_RULE(2484-10, 2484+10, 20, 6, 20,
NL80211_RRF_NO_IR |
NL80211_RRF_NO_OFDM),
/* IEEE 802.11a, channel 36..48 */
-   REG_RULE(5180-10, 5240+10, 160, 6, 20,
-NL80211_RRF_NO_IR),
+   REG_RULE(5180-10, 5240+10, 80, 6, 20,
+NL80211_RRF_NO_IR |
+NL80211_RRF_AUTO_BW),
 
/* IEEE 802.11a, channel 52..64 - DFS required */
-   REG_RULE(5260-10, 5320+10, 160, 6, 20,
+   REG_RULE(5260-10, 5320+10, 80, 6, 20,
NL80211_RRF_NO_IR |
+   NL80211_RRF_AUTO_BW |
NL80211_RRF_DFS),
 
/* IEEE 802.11a, channel 100..144 - DFS required */
-- 
2.6.2

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

Re: iwlwifi - L1 Enabled - LTR Enabled loop

[Johannes Berg]

On Fri, 2015-12-11 at 15:17 -0800, Luis R. Rodriguez wrote:
> 
> I just tried a base config from opensuse, then localmodconfig, then
> 'make xenconfig' (which I need) and that worked. I can't debug
> further but I think this config might help debug this further:
> 
> http://drvbp1.linux-foundation.org/~mcgrof/tmp/config-iwl-fail.txt
> 
> So -- my new config works, but I have no idea what fixed it, a config
> option obviously. Not sure what though.
> 

Can you post the good one too?

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

Re: [PATCH] iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id

[Laura Abbott]

On 12/11/2015 12:13 AM, Johannes Berg wrote:

From: Johannes Berg 

Properly protect the RCU dereference in iwl_mvm_get_key_sta_id() when
coming from iwl_mvm_update_tkip_key() which cannot hold the mvm->mutex
by moving the call into the RCU critical section.
Modify the check to use rcu_dereference_check() to permit this.

Fixes: 9513c5e18a0d ("iwlwifi: mvm: Avoid dereferencing sta if it was already 
flushed")
Reported-by: Laura Abbott 
Signed-off-by: Johannes Berg 


Thanks, it's working for me.

Tested-by: Laura Abbott 



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

Re: iwlwifi - L1 Enabled - LTR Enabled loop

[Luis R. Rodriguez]

On Fri, Dec 11, 2015 at 10:59 AM, Luis R. Rodriguez
 wrote:
> I could bisect *if this issue
> is not known*, but it may take a while...

So this is interesting..

The opensuse 4.2.4 kernel worked, but I tried my own vanilla 4.2.4
kernel and that didn't work. This lead me to believe this might be a
config issue. I tried the same config on v4.3, v4.2 and v4.2.4 and all
fail with the same issue!

I just tried a base config from opensuse, then localmodconfig, then
'make xenconfig' (which I need) and that worked. I can't debug further
but I think this config might help debug this further:

http://drvbp1.linux-foundation.org/~mcgrof/tmp/config-iwl-fail.txt

So -- my new config works, but I have no idea what fixed it, a config
option obviously. Not sure what though.

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

Re: [linux-next] iwl_mvm_get_key_sta_id() suspicious RCU usage

[Sergey Senozhatsky]

On (12/12/15 09:05), Sergey Senozhatsky wrote:
> On (12/11/15 14:49), Johannes Berg wrote:
> > On Fri, 2015-12-11 at 22:44 +0900, Sergey Senozhatsky wrote:
> > 
> > > [ 6385.246300] drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1226
> > > suspicious rcu_dereference_protected() usage!
> > > 
> > 
> > Funny, Laura Abbott also reported this bug earlier today :)
> > 
> > I've sent out a fix, you can see it here:
> > https://patchwork.ozlabs.org/patch/87/
> > 
> 

had to replace 'drivers/net/wireless/iwlwifi/mvm/sta.c' with
drivers/net/wireless/intel/iwlwifi/mvm/sta.c'

I'll report back if any problems show up.

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

Re: [linux-next] iwl_mvm_get_key_sta_id() suspicious RCU usage

[Sergey Senozhatsky]

On (12/11/15 14:49), Johannes Berg wrote:
> On Fri, 2015-12-11 at 22:44 +0900, Sergey Senozhatsky wrote:
> 
> > [ 6385.246300] drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1226
> > suspicious rcu_dereference_protected() usage!
> > 
> 
> Funny, Laura Abbott also reported this bug earlier today :)
> 
> I've sent out a fix, you can see it here:
> https://patchwork.ozlabs.org/patch/87/
> 

Great, thanks!

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

Re: [PATCH v7] Add new mac80211 driver mwlwifi.

[Grant Grundler]

[resending as plain textgmail...grrrh.]

On Fri, Dec 11, 2015 at 4:46 PM, Grant Grundler  wrote:
> Sorry for the late response...just one point below
>
> On Fri, Nov 20, 2015 at 3:22 AM, Johannes Berg 
> wrote:
>>
>> > +#define MWL_DRV_NAME KBUILD_MODNAME
>> > +#define MWL_DRV_VERSION   "10.3.0.14"
>>
>> versions like that are generally fairly useless since you don't update
>> them for every commit ...
>
>
> When backporting to other kernel trees, it's extremely handy to have a
> DRV_VERSION.
>
> Checking if a particular kernel build has the expected driver version
> trivial.  "mod_info" dumps the driver version for modules (which this will
> usually be too).
>
> And yes, it won't get updated for every commit only because other version
> control might encapsulate those changes. Not every distro makes their build
> versioning accessible to outsiders. So it's still helpful even if not
> perfect.
>
> Marvell can update this every time they resync with their own internal
> versions.
>
> cheers,
> grant
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] wcn36xx: handle rx skb allocation failure to avoid system crash

[fengwei.yin]

On 2015/12/11 22:08, Bob Copeland wrote:

On Fri, Dec 11, 2015 at 09:44:54PM +0800, fengwei.yin wrote:

/* skip this frame if we can't alloc a new rx buffer */
if (ret)
   goto drop;

This can't work because we need to initialize the DMA for the old skb again.
Which is done in following
switch (ch->ch_type) {
block.


Hmm, good point.  You could still move that out to a function like this:

diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
b/drivers/net/wireless/ath/wcn36xx/dxe.c
index f8dfa05..fd447bf 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -467,6 +467,27 @@ out_err:

  }

+/* or whatever name makes sense... */
+static void wcn36xx_restart_dma(struct wcn36xx *wcn,
+   struct wcn36xx_dxe_ch *ch,
+   struct wcn36xx_dxe_desc *dxe)
+{
+   switch (ch->ch_type) {
+   case WCN36XX_DXE_CH_RX_L:
+   dxe->ctrl = WCN36XX_DXE_CTRL_RX_L;
+   wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
+  WCN36XX_DXE_INT_CH1_MASK);
+   break;
+   case WCN36XX_DXE_CH_RX_H:
+   dxe->ctrl = WCN36XX_DXE_CTRL_RX_H;
+   wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
+  WCN36XX_DXE_INT_CH3_MASK);
+   break;
+   default:
+   wcn36xx_warn("Unknown channel\n");
+   }
+}
+
  static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
 struct wcn36xx_dxe_ch *ch)
  {
@@ -478,26 +499,18 @@ static int wcn36xx_rx_handle_packets(struct wcn36xx *wcn,
while (!(dxe->ctrl & WCN36XX_DXE_CTRL_VALID_MASK)) {
skb = ctl->skb;
dma_addr = dxe->dst_addr_l;
-   wcn36xx_dxe_fill_skb(wcn->dev, ctl);
+   ret = wcn36xx_dxe_fill_skb(wcn->dev, ctl);

-   switch (ch->ch_type) {
-   case WCN36XX_DXE_CH_RX_L:
-   dxe->ctrl = WCN36XX_DXE_CTRL_RX_L;
-   wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
-  WCN36XX_DXE_INT_CH1_MASK);
-   break;
-   case WCN36XX_DXE_CH_RX_H:
-   dxe->ctrl = WCN36XX_DXE_CTRL_RX_H;
-   wcn36xx_dxe_write_register(wcn, WCN36XX_DXE_ENCH_ADDR,
-  WCN36XX_DXE_INT_CH3_MASK);
-   break;
-   default:
-   wcn36xx_warn("Unknown channel\n");
-   }
+   /* skip this frame in OOM condition */
+   if (ret)
+   goto drop;

dma_unmap_single(wcn->dev, dma_addr, WCN36XX_PKT_SIZE,
 DMA_FROM_DEVICE);
wcn36xx_rx_skb(wcn, skb);
+
+drop:
+   wcn36xx_restart_dma(wcn, ch, dxe);
ctl = ctl->next;
dxe = ctl->desc;
}



...that said, not really sure it's worth it now that the 'goto' is only
skipping two lines.  So, I would be ok with the original patch too.


I don't want to introduce "goto". But I really like your choice to create
wcn36xx_restart_dma. I will keep some original patch to avoid "goto" and
adopt the function wcn36xx_restart_dma. Will send the patch out.

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

Re: [PATCH V2 06/13] brcmfmac: Add support for PCIE 4350 revision 5 device

[Kalle Valo]

Arend van Spriel  writes:

> From: Hante Meuleman 
>
> Reviewed-by: Arend Van Spriel 
> Reviewed-by: Pieter-Paul Giesberts 
> Signed-off-by: Hante Meuleman 
> Change-Id: I72b519ec6a7ff0d36f076df06d042f0c5894142c
> Reviewed-on: http://hnd-swgit.sj.broadcom.com:8080/5513
> Signed-off-by: Arend van Spriel 

You forgot this one. But I'll fix it before I apply it, unless I forget
it :)

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

Re: [PATCH V2 11/13] brcmfmac: Change error print in debug print

[Kalle Valo]

Arend van Spriel  writes:

> From: Hante Meuleman 
>
> The pcie suspend and resume routines contain some error prints,
> which should have been debug prints.
>
> Reviewed-by: Arend Van Spriel 
> Reviewed-by: Pieter-Paul Giesberts 
> Signed-off-by: Hante Meuleman 
> Change-Id: Ibafe5d38301ee8f5e86889259ddeaea4dcae4cee
> Reviewed-on: http://hnd-swgit.sj.broadcom.com:8080/5581
> Reviewed-by: brcm80211 ci 
> Signed-off-by: Arend van Spriel 

I'll fix this one also.

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

Re: [PATCH V5] wlcore/wl18xx: fw logger over sdio

[Kalle Valo]

Guy Mishol  writes:

> From: Shahar Patury 
>
> enable the FW Logger to work over the SDIO interface instead of only
> over UART.
> in new design we will use fw internal memory instead of packet ram
> that was used in older (and wl12xx) design.
> this change will reduce the impact on tp and stability.
> adding new event to notify fw logger is ready to be read.
> adding dynamic configuration to debugfs.
>
> Signed-off-by: Shahar Patury 

If you submit a patch written by someone else you should add your own
Signed-off-by line. Hence I can't take this in this form, so please
resend.

Also please format your commit logs properly: use capitalisation,
cleanly word wrap the lines and so on. It should look like something you
could give your english teacher without she having a heart attack :)

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

Re: [PATCH 5/6] mwifiex: add iw vendor command support

[Kalle Valo]

Amitkumar Karwar  writes:

> From: chunfan chen 
>
> The patch allows user to
> 1. Enable turbo mode in firmware using
> following command.
> iw dev mlan0 vendor send 0x005043 0x00 0x01
>
> 2. Download configuration data to FW using
> following command
> iw dev mlan0 vendor send 0x005043 0x01 filename
>
> Signed-off-by: chunfan chen 
> Signed-off-by: Amitkumar Karwar 

Stuff like this gives me nightmares and I'm going to put this patch to
deferred state for now as I don't want to even think what to do. In the
mean time people can convince me should I take this or not.

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

ath10k and mac80211 number of chains meaning

[Simon Malthieu]

Hi,

I would like to know the exact meaning of "chains" member of struct 
sta_info. mac80211 sta_info.h states :


"@chains: chains ever used for RX from this station"

In ath9k, it is incremented when testing each value of the chain_signal 
array (code here is ath9k common.c) :


if (rssi != ATH9K_RSSI_BAD) {
rxs->chains |= BIT(j);
rxs->chain_signal[j] = ah->noise + rssi;
}

I did this in ath10k (htt-rx.c l.874) on the model of a patch published 
on the mailing list :


static void ath10k_htt_rx_h_signal(struct ath10k *ar,
   struct ieee80211_rx_status *status,
   struct htt_rx_desc *rxd)
{
u8 signal_per_chain;
int i;
for (i = 0; i< IEEE80211_MAX_CHAINS; i++)
{
signal_per_chain = rxd->ppdu_start.rssi_chains[i].pri20_mhz;
if (signal_per_chain != ATH10K_RSSI_BAD) // = 0x80
{
status->chains |= BIT(i);
status->chain_signal[i] = ATH10K_DEFAULT_NOISE_FLOOR + 
signal_per_chain;

}
}
/* FIXME: Get real NF */
status->signal = ATH10K_DEFAULT_NOISE_FLOOR +
 rxd->ppdu_start.rssi_comb;
status->flag &= ~RX_FLAG_NO_SIGNAL_VAL;
}

But when I configure the number of antennas (iw phy0 set antennas - iw 
3.15) lower than the maximum of antennas, chains doesn't change, i.e. 
there is still a correct value in chain_signal of the disabled antennas 
(the value is not updated though).


I don't understand how a signal value can be received from a STA if the 
antennas configuration doesn't allow it.


If it is not a bug, should i check rx_chain_mask in the driver to verify 
the antennas configuration instead of chains ?


Thanks for your help

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

Re: [PATCH V2 11/13] brcmfmac: Change error print in debug print

[Arend van Spriel]

On 12/11/2015 09:40 AM, Kalle Valo wrote:

Arend van Spriel  writes:


From: Hante Meuleman 

The pcie suspend and resume routines contain some error prints,
which should have been debug prints.

Reviewed-by: Arend Van Spriel 
Reviewed-by: Pieter-Paul Giesberts 
Signed-off-by: Hante Meuleman 
Change-Id: Ibafe5d38301ee8f5e86889259ddeaea4dcae4cee
Reviewed-on: http://hnd-swgit.sj.broadcom.com:8080/5581
Reviewed-by: brcm80211 ci 
Signed-off-by: Arend van Spriel 


I'll fix this one also.


Thanks, Kalle

I could blame gedit, but that is a bit lame. Sorry for the inconvenience.

Regards,
Arend

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

Re: [PATCH V2 13/13] brcmfmac: add arp offload ip address table configuration support

[Arend van Spriel]

On 12/10/2015 01:43 PM, Arend van Spriel wrote:

From: Franky Lin 

Obtain ipv4 address through inetaddr notification for ARP offload host
ip table configuration.


Turns out this patch has a sparse warning, ie. would not work on 
big-endian system. We have a fix for that. Should I mark this patch as 
dropped in patchwork?


Regards,
Arend


Signed-off-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
  .../wireless/broadcom/brcm80211/brcmfmac/core.c| 108 +
  .../wireless/broadcom/brcm80211/brcmfmac/core.h|   2 +
  2 files changed, 110 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 3a39192..2631f6f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -620,6 +621,8 @@ static int brcmf_netdev_stop(struct net_device *ndev)

brcmf_cfg80211_down(ndev);

+   brcmf_fil_iovar_data_set(ifp, "arp_hostip_clear", NULL, 0);
+
brcmf_net_setcarrier(ifp, false);

return 0;
@@ -940,6 +943,98 @@ int brcmf_get_next_free_bsscfgidx(struct brcmf_pub *drvr)
return available ? bsscfgidx : -ENOMEM;
  }

+#ifdef CONFIG_INET
+#define ARPOL_MAX_ENTRIES  8
+static int brcmf_inetaddr_changed(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+   struct brcmf_pub *drvr = container_of(nb, struct brcmf_pub,
+ inetaddr_notifier);
+   struct in_ifaddr *ifa = data;
+   struct net_device *ndev = ifa->ifa_dev->dev;
+   struct brcmf_if *ifp;
+   int idx, i, ret;
+   u32 val;
+   u32 addr_table[ARPOL_MAX_ENTRIES] = {0};
+
+   /* Find out if the notification is meant for us */
+   for (idx = 0; idx < BRCMF_MAX_IFS; idx++) {
+   ifp = drvr->iflist[idx];
+   if (ifp && ifp->ndev == ndev)
+   break;
+   if (idx == BRCMF_MAX_IFS - 1)
+   return NOTIFY_DONE;
+   }
+
+   /* check if arp offload is supported */
+   ret = brcmf_fil_iovar_int_get(ifp, "arpoe", );
+   if (ret)
+   return NOTIFY_OK;
+
+   /* old version only support primary index */
+   ret = brcmf_fil_iovar_int_get(ifp, "arp_version", );
+   if (ret)
+   val = 1;
+   if (val == 1)
+   ifp = drvr->iflist[0];
+
+   /* retrieve the table from firmware */
+   ret = brcmf_fil_iovar_data_get(ifp, "arp_hostip", addr_table,
+  sizeof(addr_table));
+   if (ret) {
+   brcmf_err("fail to get arp ip table err:%d\n", ret);
+   return NOTIFY_OK;
+   }
+
+   for (i = 0; i < ARPOL_MAX_ENTRIES; i++)
+   if (ifa->ifa_address == addr_table[i])
+   break;
+
+   switch (action) {
+   case NETDEV_UP:
+   if (i == ARPOL_MAX_ENTRIES) {
+   brcmf_dbg(TRACE, "add %pI4 to arp table\n",
+ >ifa_address);
+   /* set it directly */
+   ret = brcmf_fil_iovar_int_set(ifp, "arp_hostip",
+ ifa->ifa_address);
+   if (ret)
+   brcmf_err("add arp ip err %d\n", ret);
+   }
+   break;
+   case NETDEV_DOWN:
+   if (i < ARPOL_MAX_ENTRIES) {
+   addr_table[i] = 0;
+   brcmf_dbg(TRACE, "remove %pI4 from arp table\n",
+ >ifa_address);
+   /* clear the table in firmware */
+   ret = brcmf_fil_iovar_data_set(ifp, "arp_hostip_clear",
+  NULL, 0);
+   if (ret) {
+   brcmf_err("fail to clear arp ip table err:%d\n",
+ ret);
+   return NOTIFY_OK;
+   }
+   for (i = 0; i < ARPOL_MAX_ENTRIES; i++) {
+   if (addr_table[i] != 0) {
+   brcmf_fil_iovar_int_set(ifp,
+   "arp_hostip",
+   addr_table[i]);
+   if (ret)
+   brcmf_err("add arp ip err %d\n",
+ ret);
+   }
+   }
+   }
+   break;
+   default:
+

RE: [PATCH] mwifiex: parse hscfg_gpio info from device tree

[Amitkumar Karwar]

Hi Kalle,

> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Friday, December 11, 2015 2:04 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Nishant Sarmukadam; Xinming Hu;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH] mwifiex: parse hscfg_gpio info from device tree
> 
> + devicetree list
> 
> Amitkumar Karwar  writes:
> 
> > From: Xinming Hu 
> >
> > This patch reads hscfg_gpio from device tree and update internal
> > variable
> >
> > Signed-off-by: Xinming Hu 
> > Signed-off-by: Amitkumar Karwar 
> > ---
> >  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> > b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> > index e486867..d28a53f 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> > @@ -1459,10 +1459,21 @@ int mwifiex_dnld_dt_cfgdata(struct
> > mwifiex_private *priv,  #ifdef CONFIG_OF
> > struct property *prop;
> > size_t len = strlen(prefix);
> > +   u32 data;
> > int ret;
> >
> > /* look for all matching property names */
> > for_each_property_of_node(node, prop) {
> > +   if (!strncmp(prop->name, "marvell,hscfg_gpio",
> > +strlen("marvell,hscfg_gpio"))) {
> > +   if (!of_property_read_u32(priv->adapter->dt_node,
> > + prop->name, )) {
> > +   dev_dbg(priv->adapter->dev,
> > +   "hscfg gpio = 0x%x\n", data);
> > +   priv->adapter->hs_cfg.gpio = data;
> > +   }
> > +   }
> 
> I don't see this documented in Documentation/devicetree/bindings. Please
> create a binding document and review it with the device tree
> maintainers.
> 
> Actually when looking mwifiex close I see that it uses more undocumented
> device tree interfaces:
> 
> marvell_cfgdata
> marvell,caldata
> marvell,00_txpwrlimit
> 
> I think these all should be properly documented and reviewed. But I'll
> let the device tree people chime in what's the best way.
> 

Thanks for the review.
Sure. We will document existing DT interfaces and create updated version of 
this patch which includes documentation in bindings.

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

[PATCH] nl80211: Fix potential memory leak in nl80211_connect

[Ola Olsson]

Free cached keys if the last early return path is taken.

Signed-off-by: Ola Olsson 
---
 net/wireless/nl80211.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c71e274..4b5ff71 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7941,8 +7941,10 @@ static int nl80211_connect(struct sk_buff *skb, struct 
genl_info *info)
if (nla_get_flag(info->attrs[NL80211_ATTR_USE_RRM])) {
if (!(rdev->wiphy.features &
  NL80211_FEATURE_DS_PARAM_SET_IE_IN_PROBES) ||
-   !(rdev->wiphy.features & NL80211_FEATURE_QUIET))
+   !(rdev->wiphy.features & NL80211_FEATURE_QUIET)) {
+   kzfree(connkeys);
return -EINVAL;
+   }
connect.flags |= ASSOC_REQ_USE_RRM;
}
 
-- 
1.7.9.5

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

[PATCH] iwlwifi: mvm: protect RCU dereference in iwl_mvm_get_key_sta_id

[Johannes Berg]

From: Johannes Berg 

Properly protect the RCU dereference in iwl_mvm_get_key_sta_id() when
coming from iwl_mvm_update_tkip_key() which cannot hold the mvm->mutex
by moving the call into the RCU critical section.
Modify the check to use rcu_dereference_check() to permit this.

Fixes: 9513c5e18a0d ("iwlwifi: mvm: Avoid dereferencing sta if it was already 
flushed")
Reported-by: Laura Abbott 
Signed-off-by: Johannes Berg 
---
 drivers/net/wireless/iwlwifi/mvm/sta.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/mvm/sta.c 
b/drivers/net/wireless/iwlwifi/mvm/sta.c
index 354acbde088e..2b976b110207 100644
--- a/drivers/net/wireless/iwlwifi/mvm/sta.c
+++ b/drivers/net/wireless/iwlwifi/mvm/sta.c
@@ -1222,8 +1222,8 @@ static u8 iwl_mvm_get_key_sta_id(struct iwl_mvm *mvm,
mvmvif->ap_sta_id != IWL_MVM_STATION_COUNT) {
u8 sta_id = mvmvif->ap_sta_id;
 
-   sta = rcu_dereference_protected(mvm->fw_id_to_mac_id[sta_id],
-   lockdep_is_held(>mutex));
+   sta = rcu_dereference_check(mvm->fw_id_to_mac_id[sta_id],
+   lockdep_is_held(>mutex));
/*
 * It is possible that the 'sta' parameter is NULL,
 * for example when a GTK is removed - the sta_id will then
@@ -1590,14 +1590,15 @@ void iwl_mvm_update_tkip_key(struct iwl_mvm *mvm,
 u16 *phase1key)
 {
struct iwl_mvm_sta *mvm_sta;
-   u8 sta_id = iwl_mvm_get_key_sta_id(mvm, vif, sta);
+   u8 sta_id;
bool mcast = !(keyconf->flags & IEEE80211_KEY_FLAG_PAIRWISE);
 
-   if (WARN_ON_ONCE(sta_id == IWL_MVM_STATION_COUNT))
-   return;
-
rcu_read_lock();
 
+   sta_id = iwl_mvm_get_key_sta_id(mvm, vif, sta);
+   if (WARN_ON_ONCE(sta_id == IWL_MVM_STATION_COUNT))
+   goto unlock;
+
if (!sta) {
sta = rcu_dereference(mvm->fw_id_to_mac_id[sta_id]);
if (WARN_ON(IS_ERR_OR_NULL(sta))) {
@@ -1609,6 +1610,8 @@ void iwl_mvm_update_tkip_key(struct iwl_mvm *mvm,
mvm_sta = iwl_mvm_sta_from_mac80211(sta);
iwl_mvm_send_sta_key(mvm, mvm_sta, keyconf, mcast,
 iv32, phase1key, CMD_ASYNC, keyconf->hw_key_idx);
+
+ unlock:
rcu_read_unlock();
 }
 
-- 
2.6.2

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

Re: [PATCH v2 11/13] ath9k: MCC add sta_ap_ratio module param

[Kalle Valo]

Janusz Dziedzic  writes:

> In case of MCC we can setup STA/AP(GO) ratio.
> Eg. setting sta_ap_ratio=80
> STA will get 80% of time, while AP(GO) 20%.
> Setup correct ctwindow.
>
> Signed-off-by: Janusz Dziedzic 

Why? What's the use case?

And isn't there a better way to do this? Like using nl80211 (via
wpasupplicant?) or debugfs?

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

[linux-next] iwl_mvm_get_key_sta_id() suspicious RCU usage

[Sergey Senozhatsky]

Hi,

linux-next 20151211

[ 6385.246285] ===
[ 6385.246288] [ INFO: suspicious RCU usage. ]
[ 6385.246294] 4.4.0-rc4-next-20151211-dbg-00015-g7b65ef3-dirty #302 Not tainted
[ 6385.246296] ---
[ 6385.246300] drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1226 suspicious 
rcu_dereference_protected() usage!
[ 6385.246303] 
   other info that might help us debug this:

[ 6385.246308] 
   rcu_scheduler_active = 1, debug_locks = 0
[ 6385.246313] 4 locks held by irq/30-iwlwifi/246:
[ 6385.246316]  #0:  (sync_cmd_lockdep_map){..}, at: [] 
iwl_pcie_irq_handler+0x5/0xaf4 [iwlwifi]
[ 6385.246341]  #1:  (&(>lock)->rlock){+.+...}, at: [] 
iwl_pcie_irq_handler+0x427/0xaf4 [iwlwifi]
[ 6385.246356]  #2:  (rcu_read_lock){..}, at: [] 
ieee80211_rx_napi+0x139/0x8f2 [mac80211]
[ 6385.246408]  #3:  (&(>rx_path_lock)->rlock){+.-...}, at: 
[] ieee80211_rx_handlers+0x33/0x21c3 [mac80211]
[ 6385.246448] 
   stack backtrace:
[ 6385.246455] CPU: 0 PID: 246 Comm: irq/30-iwlwifi Not tainted 
4.4.0-rc4-next-20151211-dbg-00015-g7b65ef3-dirty #302
[ 6385.246459]   8800c65678e0 811e7d72 
88041af55100
[ 6385.246467]  8800c6567910 8107dabe  
88041c6d2048
[ 6385.246474]  880416a30a08 88041c6d2048 8800c6567930 
a04f5106
[ 6385.246480] Call Trace:
[ 6385.246490]  [] dump_stack+0x4b/0x63
[ 6385.246497]  [] lockdep_rcu_suspicious+0xf7/0x100
[ 6385.246517]  [] iwl_mvm_get_key_sta_id.part.0+0x60/0x7f 
[iwlmvm]
[ 6385.246533]  [] iwl_mvm_update_tkip_key+0x43/0x22d [iwlmvm]
[ 6385.246544]  [] iwl_mvm_mac_update_tkip_key+0x1c/0x1e 
[iwlmvm]
[ 6385.246578]  [] ieee80211_tkip_decrypt_data+0x22f/0x44e 
[mac80211]
[ 6385.246584]  [] ? lock_acquire+0x101/0x188
[ 6385.246611]  [] ieee80211_crypto_tkip_decrypt+0xc8/0x113 
[mac80211]
[ 6385.246645]  [] ieee80211_rx_handlers+0xa68/0x21c3 
[mac80211]
[ 6385.246677]  [] 
ieee80211_prepare_and_rx_handle+0x81f/0x86f [mac80211]
[ 6385.246706]  [] ? ieee80211_rx_napi+0x139/0x8f2 [mac80211]
[ 6385.246711]  [] ? __lock_is_held+0x3c/0x57
[ 6385.246748]  [] ieee80211_rx_napi+0x640/0x8f2 [mac80211]
[ 6385.246767]  [] iwl_mvm_rx_rx_mpdu+0x651/0x660 [iwlmvm]
[ 6385.246781]  [] iwl_mvm_rx+0x58/0x1e6 [iwlmvm]
[ 6385.246793]  [] iwl_pcie_irq_handler+0x960/0xaf4 [iwlwifi]
[ 6385.246800]  [] ? __schedule+0x716/0xaf9
[ 6385.246806]  [] ? irq_finalize_oneshot+0xd0/0xd0
[ 6385.246812]  [] irq_thread_fn+0x1d/0x34
[ 6385.246817]  [] irq_thread+0x10d/0x1b5
[ 6385.246823]  [] ? wake_threads_waitq+0x2d/0x2d
[ 6385.246828]  [] ? irq_thread_dtor+0x98/0x98
[ 6385.246833]  [] kthread+0xf8/0x100
[ 6385.246840]  [] ? kthread_create_on_node+0x1c7/0x1c7
[ 6385.246847]  [] ret_from_fork+0x3f/0x70
[ 6385.246852]  [] ? kthread_create_on_node+0x1c7/0x1c7

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

Re: iwlwifi A-MSDU tx

[Stefan Sperling]

Hi Emmanuel,

Thanks a bunch, this worked out quite well for me.
I got what I was aiming for out of this already but I still have some
additional questions if you don't mind.

Do you know of a good way to generate A-MSDUs?
One way I found is to run:
  top -d .01
on the AP and watching this top over SSH from my associated OpenBSD client.

It seems only locally generated packets will trigger A-MSDUs.
I suppose forwarded frames always fit the interface MTU and don't
trigger A-MSDUs. Is there a way to test this with forwarded traffic?

One issue I discovered is that OpenBSD (with my partly uncommitted 11n
patch set) cannot decrypt encrypted A-MSDUs sent by iwlwifi.
Frames carrying normal MSDUs have a CCMP header and are decrypted correctly.
But frames carrying A-MSDUs have a wep/tkip header (wireshark shows
"WEP parameters" instead of CCMP parameters") and decryption fails on
OpenBSD in ieee80211_ccmp_decrypt() because the ExtIV bit is not set.
It doesn't look like the source of this problem is at OpenBSD's end since
CCMP is required for HT. So in case the firmware doesn't produce CCMP for
A-MSDUs, this would be a problem in the firmware. Can you confirm this?
I also tried running iwlwifi in software crypto mode but the AP would
not send A-MSDUs at all in that case.

On the receiving OpenBSD side I'm currently limited to 4k A-MSDU and it
turns out the AP won't send more than 2 subframes per A-MSDU in this case.
To test with more than 2 subframes I applied the following crude patch which
makes the AP send more subframes but crashes the firmware after the frame
is sent. The driver recovers fine and traffic keeps flowing but that's
not pretty. Do you have a better idea? If not, no problem. I mainly did
this to confirm that OpenBSD won't crash handling A-MSDU with more than
2 subframes, which it won't.

Thanks again,
Stefan

diff --git a/drivers/net/wireless/iwlwifi/mvm/tx.c 
b/drivers/net/wireless/iwlwifi/mvm/tx.c
index 7ece5c1..b3d562d 100644
--- a/drivers/net/wireless/iwlwifi/mvm/tx.c
+++ b/drivers/net/wireless/iwlwifi/mvm/tx.c
@@ -448,7 +448,7 @@ static int iwl_mvm_tx_tso(struct iwl_mvm *mvm, struct 
sk_buff *skb,
struct iwl_mvm_sta *mvmsta = iwl_mvm_sta_from_mac80211(sta);
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (void *)skb->data;
-   unsigned int mss = skb_shinfo(skb)->gso_size;
+   unsigned int mss = skb_shinfo(skb)->gso_size / 2;
struct sk_buff *tmp, *next;
char cb[sizeof(skb->cb)];
unsigned int num_subframes, tcp_payload_len, subf_len, max_amsdu_len;

On Fri, Dec 04, 2015 at 12:30:52PM +0200, Emmanuel Grumbach wrote:
> Adding the right mailing list this time.
> 
> On Fri, Dec 4, 2015 at 10:18 AM, Emmanuel Grumbach  
> wrote:
> > On Fri, Dec 4, 2015 at 9:35 AM, Emmanuel Grumbach  
> > wrote:
> >> Hi,
> >>
> >> On Fri, Dec 4, 2015 at 12:05 AM, Stefan Sperling  wrote:
> >>> Hi Emmanuel,
> >>>
> >>> As part of implementing 802.11n support in OpenBSD I'm looking for
> >>> an AP which sends A-MSDUs. Preferrably under software control rather
> >>> than firmware.
> >>>
> >>> I found your iwlwifi A-MSDU patches at
> >>> http://marc.info/?l=linux-wireless=144553311122495=2
> >>> and http://marc.info/?l=linux-wireless=144553311822496=2
> >>>
> >>> Would these patches make it possible to run an AP with an 5300 or 7260
> >>> card and send A-MSDUs? That would be great as I have the necessary 
> >>> hardware.
> >>
> >> 7260 will go. Not 5300.
> >> Note that this code simulates Tx TCP Csum offload. I did that to write
> >> the code while we still don't have the hardware that has this
> >> capability. But for testing purposes, it should do the work. The
> >> testing teams have reported that AP mode didn't work quite well with
> >> this and I haven't taken the time to look into yet, but if you see
> >> issues, please report them or even better: fix them :)
> >>
> >>>
> >>> Which Linux tree do these patches apply to? I've tried the following
> >>> but had no luck in getting these patches applied without rejects:
> >>>
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git
> >>>
> >>
> >> Right. These patches had a long internal review cycle. They are now
> >> merge in our internal tree.
> >> You can find them in our internal tree [1] (backport based). I will
> >> push them soon in iwlwifi-next.git.
> >
> > I forgot to mention that you need to change the define of
> > IWL_MVM_SW_TX_CSUM_OFFLOAD to 1.
> >
> >>
> >> [1] - 
> >> https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/
> >> Please read 
> >> https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release#how_to_install_the_driver.
> >>
> >>> Thanks,
> >>> Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to 

iwlwifi - L1 Enabled - LTR Enabled loop

[Luis R. Rodriguez]

Using 4.4-rc4 and today's wireless-testing (master-2015-12-10), and
the latest firmware on linux-firmware, my wireless driver runs into a
non-functional loop rambling about "L1 Enabled - LTR Enabled loop".
Reverting back to an older kernel works. I could bisect *if this issue
is not known*, but it may take a while... If you are already
suspicious of a commit lemme know, and I can try to revert. Otherwise
if there's a firmware version that is supposed to work I'm happy to
try that.

Device: Intel dual band wireless AC 7260, REV=0x144
Firmware version: 16.242414.0 (linux-firmware upstream)

I also tried:

Firmware version: 17.246894.0 op_mode iwlmvm (latest on
iwlwifi/linux-firmware.git)

I run into the same issue with this version as well though.

The log:

[   18.914370] cfg80211: World regulatory domain updated:
[   18.915114] cfg80211:  DFS Master region: unset
[   18.915127] cfg80211:   (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp), (dfs_cac_time)
[   18.916599] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz),
(N/A, 2000 mBm), (N/A)
[   18.917351] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz),
(N/A, 2000 mBm), (N/A)
[   18.918082] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz),
(N/A, 2000 mBm), (N/A)
[   18.918805] cfg80211:   (517 KHz - 525 KHz @ 8 KHz,
16 KHz AUTO), (N/A, 2000 mBm), (N/A)
[   18.919530] cfg80211:   (525 KHz - 533 KHz @ 8 KHz,
16 KHz AUTO), (N/A, 2000 mBm), (0 s)
[   18.920247] cfg80211:   (549 KHz - 573 KHz @ 16 KHz),
(N/A, 2000 mBm), (0 s)
[   18.920965] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz),
(N/A, 2000 mBm), (N/A)
[   18.921692] cfg80211:   (5724 KHz - 6372 KHz @ 216
KHz), (N/A, 0 mBm), (N/A)
[   19.059414] Intel(R) Wireless WiFi driver for Linux
[   19.060123] Copyright(c) 2003- 2015 Intel Corporation
[   19.061091] iwlwifi :03:00.0: Direct firmware load for
iwlwifi-7260-19.ucode failed with error -2
[   19.061792] iwlwifi :03:00.0: Direct firmware load for
iwlwifi-7260-18.ucode failed with error -2
[   19.062414] iwlwifi :03:00.0: Direct firmware load for
iwlwifi-7260-17.ucode failed with error -2
[   19.590098] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b39a)
[   19.673094] iwlwifi :03:00.0: loaded firmware version
16.242414.0 op_mode iwlmvm
[   22.439870] iwlwifi :03:00.0: Detected Intel(R) Dual Band
Wireless AC 7260, REV=0x144
[   22.440809] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   22.442616] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   22.645773] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   22.737314] iwlwifi :03:00.0 wlp3s0: renamed from wlan0
[   33.288237] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   33.288489] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[   33.477404] iwlwifi :03:00.0: L1 Enabled - LTR Enabled

[ etc ]

[  100.421430] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  100.421686] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  100.604345] iwlwifi :03:00.0: L1 Enabled - LTR Enabled
[  100.604633] iwlwifi :03:00.0: L1 Enabled - LTR Enabled

[ it goes on forever ]

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

Re: [PATCH] mwifiex: parse hscfg_gpio info from device tree

[Kalle Valo]

+ devicetree list

Amitkumar Karwar  writes:

> From: Xinming Hu 
>
> This patch reads hscfg_gpio from device tree and update
> internal variable
>
> Signed-off-by: Xinming Hu 
> Signed-off-by: Amitkumar Karwar 
> ---
>  drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
> b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> index e486867..d28a53f 100644
> --- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> +++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
> @@ -1459,10 +1459,21 @@ int mwifiex_dnld_dt_cfgdata(struct mwifiex_private 
> *priv,
>  #ifdef CONFIG_OF
>   struct property *prop;
>   size_t len = strlen(prefix);
> + u32 data;
>   int ret;
>  
>   /* look for all matching property names */
>   for_each_property_of_node(node, prop) {
> + if (!strncmp(prop->name, "marvell,hscfg_gpio",
> +  strlen("marvell,hscfg_gpio"))) {
> + if (!of_property_read_u32(priv->adapter->dt_node,
> +   prop->name, )) {
> + dev_dbg(priv->adapter->dev,
> + "hscfg gpio = 0x%x\n", data);
> + priv->adapter->hs_cfg.gpio = data;
> + }
> + }

I don't see this documented in Documentation/devicetree/bindings. Please
create a binding document and review it with the device tree
maintainers.

Actually when looking mwifiex close I see that it uses more undocumented
device tree interfaces:

marvell_cfgdata
marvell,caldata
marvell,00_txpwrlimit

I think these all should be properly documented and reviewed. But I'll
let the device tree people chime in what's the best way.

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