[PATCH 1/2] ath9k: rename ini_modes_rxgain_5g_xlna to ini_modes_rxgain_xlna

[miaoqing]

From: Miaoqing Pan 

rename the variable as preparation for using the array with 2.4 GHz
band, etc.

Signed-off-by: Miaoqing Pan 
---
 drivers/net/wireless/ath/ath9k/ar9003_hw.c  | 10 +-
 drivers/net/wireless/ath/ath9k/ar9003_phy.c |  4 ++--
 drivers/net/wireless/ath/ath9k/hw.h |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_hw.c 
b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
index 79fd3b2..8b238c1 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
@@ -857,7 +857,7 @@ static void ar9003_rx_gain_table_mode0(struct ath_hw *ah)
   qca956x_1p0_common_rx_gain_table);
INIT_INI_ARRAY(&ah->ini_modes_rx_gain_bounds,
   qca956x_1p0_common_rx_gain_bounds);
-   INIT_INI_ARRAY(&ah->ini_modes_rxgain_5g_xlna,
+   INIT_INI_ARRAY(&ah->ini_modes_rxgain_xlna,
   qca956x_1p0_xlna_only);
} else if (AR_SREV_9580(ah))
INIT_INI_ARRAY(&ah->iniModesRxGain,
@@ -942,7 +942,7 @@ static void ar9003_rx_gain_table_mode2(struct ath_hw *ah)
   ar9462_2p1_baseband_core_mix_rxgain);
INIT_INI_ARRAY(&ah->ini_modes_rxgain_bb_postamble,
   ar9462_2p1_baseband_postamble_mix_rxgain);
-   INIT_INI_ARRAY(&ah->ini_modes_rxgain_5g_xlna,
+   INIT_INI_ARRAY(&ah->ini_modes_rxgain_xlna,
   ar9462_2p1_baseband_postamble_5g_xlna);
} else if (AR_SREV_9462_20(ah)) {
INIT_INI_ARRAY(&ah->iniModesRxGain,
@@ -951,7 +951,7 @@ static void ar9003_rx_gain_table_mode2(struct ath_hw *ah)
   ar9462_2p0_baseband_core_mix_rxgain);
INIT_INI_ARRAY(&ah->ini_modes_rxgain_bb_postamble,
   ar9462_2p0_baseband_postamble_mix_rxgain);
-   INIT_INI_ARRAY(&ah->ini_modes_rxgain_5g_xlna,
+   INIT_INI_ARRAY(&ah->ini_modes_rxgain_xlna,
   ar9462_2p0_baseband_postamble_5g_xlna);
}
 }
@@ -961,12 +961,12 @@ static void ar9003_rx_gain_table_mode3(struct ath_hw *ah)
if (AR_SREV_9462_21(ah)) {
INIT_INI_ARRAY(&ah->iniModesRxGain,
   ar9462_2p1_common_5g_xlna_only_rxgain);
-   INIT_INI_ARRAY(&ah->ini_modes_rxgain_5g_xlna,
+   INIT_INI_ARRAY(&ah->ini_modes_rxgain_xlna,
   ar9462_2p1_baseband_postamble_5g_xlna);
} else if (AR_SREV_9462_20(ah)) {
INIT_INI_ARRAY(&ah->iniModesRxGain,
   ar9462_2p0_common_5g_xlna_only_rxgain);
-   INIT_INI_ARRAY(&ah->ini_modes_rxgain_5g_xlna,
+   INIT_INI_ARRAY(&ah->ini_modes_rxgain_xlna,
   ar9462_2p0_baseband_postamble_5g_xlna);
}
 }
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 1ad66b7..296a69e 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -926,12 +926,12 @@ static int ar9003_hw_process_ini(struct ath_hw *ah,
 */
if ((ar9003_hw_get_rx_gain_idx(ah) == 2) ||
(ar9003_hw_get_rx_gain_idx(ah) == 3)) {
-   REG_WRITE_ARRAY(&ah->ini_modes_rxgain_5g_xlna,
+   REG_WRITE_ARRAY(&ah->ini_modes_rxgain_xlna,
modesIndex, regWrites);
}
 
if (AR_SREV_9561(ah) && (ar9003_hw_get_rx_gain_idx(ah) == 0))
-   REG_WRITE_ARRAY(&ah->ini_modes_rxgain_5g_xlna,
+   REG_WRITE_ARRAY(&ah->ini_modes_rxgain_xlna,
modesIndex, regWrites);
}
 
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index e8454db..4f0a3f6 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -919,7 +919,7 @@ struct ath_hw {
struct ar5416IniArray iniCckfirJapan2484;
struct ar5416IniArray iniModes_9271_ANI_reg;
struct ar5416IniArray ini_radio_post_sys2ant;
-   struct ar5416IniArray ini_modes_rxgain_5g_xlna;
+   struct ar5416IniArray ini_modes_rxgain_xlna;
struct ar5416IniArray ini_modes_rxgain_bb_core;
struct ar5416IniArray ini_modes_rxgain_bb_postamble;
 
-- 
1.9.1

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

[PATCH 2/2] ath9k: fix QCA9561 XLNA rxgain initial

[miaoqing]

From: Miaoqing Pan 

A small bugfix for commit ede6a5e7b859 ("ath9k: Add QCA956x HW support").
I guess I would have skipped renaming (that initial QCA956x commit has
been there already for almost a year with the "5g" in the name) and move
the call outside AR_SREV_9462_20_OR_LATER() to make it reachable.

Signed-off-by: Miaoqing Pan 
---
 drivers/net/wireless/ath/ath9k/ar9003_phy.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c 
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 296a69e..201425e 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -929,16 +929,15 @@ static int ar9003_hw_process_ini(struct ath_hw *ah,
REG_WRITE_ARRAY(&ah->ini_modes_rxgain_xlna,
modesIndex, regWrites);
}
-
-   if (AR_SREV_9561(ah) && (ar9003_hw_get_rx_gain_idx(ah) == 0))
-   REG_WRITE_ARRAY(&ah->ini_modes_rxgain_xlna,
-   modesIndex, regWrites);
}
 
if (AR_SREV_9550(ah) || AR_SREV_9561(ah))
REG_WRITE_ARRAY(&ah->ini_modes_rx_gain_bounds, modesIndex,
regWrites);
 
+   if (AR_SREV_9561(ah) && (ar9003_hw_get_rx_gain_idx(ah) == 0))
+   REG_WRITE_ARRAY(&ah->ini_modes_rxgain_xlna,
+   modesIndex, regWrites);
/*
 * TXGAIN initvals.
 */
-- 
1.9.1

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

Re: [PATCH 1/2] drivers: staging: wilc1000: Replace message queue with standard Linux lists

[Dan Carpenter]

On Mon, Sep 28, 2015 at 11:43:55PM +0530, Chandra S Gorentla wrote:
>  - The message queue is replaced with standard Linux linked list
>  - kmem_cache is used for list members
>  - A check for return value of receive method is added
>  - GFP_ATOMIC is changed to GFP_KERNEL
>  - A few other related minor changes

These should be listed and explained.

>  
>   while (1) {
> - wilc_mq_recv(&gMsgQHostIF, &msg, sizeof(struct host_if_msg), 
> &u32Ret);
> + ret = wilc_mq_recv(&gMsgQHostIF, &msg,
> + sizeof(struct host_if_msg), &u32Ret);
> + if (ret)
> + continue;
> +

I asked before if this was a forever loop and never got a response.
Also what does this have to do with list macros?

regards,
dan carpenter
--
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] ath9k: feeding entropy in kernel from ADC capture

[miaoqing]

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 
---
 drivers/net/wireless/ath/ath9k/Kconfig  |  11 
 drivers/net/wireless/ath/ath9k/Makefile |   1 +
 drivers/net/wireless/ath/ath9k/ath9k.h  |  22 +++
 drivers/net/wireless/ath/ath9k/main.c   |   4 ++
 drivers/net/wireless/ath/ath9k/rng.c| 106 
 5 files changed, 144 insertions(+)
 create mode 100644 drivers/net/wireless/ath/ath9k/rng.c

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
b/drivers/net/wireless/ath/ath9k/Kconfig
index fee0cad..40fa915 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -176,3 +176,14 @@ config ATH9K_HTC_DEBUGFS
depends on ATH9K_HTC && DEBUG_FS
---help---
  Say Y, if you need access to ath9k_htc's statistics.
+
+config ATH9K_HWRNG
+   bool "Random number generator support"
+   depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
+   default y
+   ---help---
+ This option incorporates the ADC register output as a source of
+ randomness into Linux entropy pool (/dev/urandom and /dev/random)
+
+ Say Y, feeds the entropy directly from the WiFi driver to the input
+ pool.
diff --git a/drivers/net/wireless/ath/ath9k/Makefile 
b/drivers/net/wireless/ath/ath9k/Makefile
index ecda613..76f9dc3 100644
--- a/drivers/net/wireless/ath/ath9k/Makefile
+++ b/drivers/net/wireless/ath/ath9k/Makefile
@@ -15,6 +15,7 @@ ath9k-$(CONFIG_ATH9K_DFS_DEBUGFS) += dfs_debug.o
 ath9k-$(CONFIG_ATH9K_DFS_CERTIFIED) += dfs.o
 ath9k-$(CONFIG_ATH9K_TX99) += tx99.o
 ath9k-$(CONFIG_ATH9K_WOW) += wow.o
+ath9k-$(CONFIG_ATH9K_HWRNG) += rng.o
 
 ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o
 
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index c85c479..cd74f68 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "common.h"
 #include "debug.h"
@@ -1039,6 +1040,11 @@ struct ath_softc {
u32 wow_intr_before_sleep;
bool force_wow;
 #endif
+
+#ifdef CONFIG_ATH9K_HWRNG
+   u32 rng_last;
+   struct task_struct *rng_task;
+#endif
 };
 
 //
@@ -1061,6 +1067,22 @@ static inline int ath9k_tx99_send(struct ath_softc *sc,
 }
 #endif /* CONFIG_ATH9K_TX99 */
 
+/***/
+/* Random Number Generator */
+/***/
+#ifdef CONFIG_ATH9K_HWRNG
+void ath9k_rng_start(struct ath_softc *sc);
+void ath9k_rng_stop(struct ath_softc *sc);
+#else
+static inline void ath9k_rng_start(struct ath_softc *sc)
+{
+}
+
+static inline void ath9k_rng_stop(struct ath_softc *sc)
+{
+}
+#endif
+
 static inline void ath_read_cachesize(struct ath_common *common, int *csz)
 {
common->bus_ops->read_cachesize(common, csz);
diff --git a/drivers/net/wireless/ath/ath9k/main.c 
b/drivers/net/wireless/ath/ath9k/main.c
index 323eb33..39ba17f 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -739,6 +739,8 @@ static int ath9k_start(struct ieee80211_hw *hw)
 
ath9k_ps_restore(sc);
 
+   ath9k_rng_start(sc);
+
return 0;
 }
 
@@ -828,6 +830,8 @@ static void ath9k_stop(struct ieee80211_hw *hw)
 
ath9k_deinit_channel_context(sc);
 
+   ath9k_rng_stop(sc);
+
mutex_lock(&sc->mutex);
 
ath_cancel_work(sc);
diff --git a/drivers/net/wireless/ath/ath9k/rng.c 
b/drivers/net/wireless/ath/ath9k/rng.c
new file mode 100644
index 000..519b3c8
--- /dev/null
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -0,0 +1,106 @@
+/*
+ * Copyright (c) 2015 Qualcomm Atheros, Inc.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN

Re: [PATCH 1/2] drivers: staging: wilc1000: Replace message queue with standard Linux lists

[Greg KH]

On Mon, Sep 28, 2015 at 11:43:55PM +0530, Chandra S Gorentla wrote:
>  - The message queue is replaced with standard Linux linked list
>  - kmem_cache is used for list members

Why?

>  - A check for return value of receive method is added
>  - GFP_ATOMIC is changed to GFP_KERNEL

Why?  Are you sure that is safe?

>  - A few other related minor changes

Be specific please.

thanks,

greg k-h
--
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 2/2] drivers: staging: wilc1000: wilc_msgqueue.c: Remove code that no effect

[Greg KH]

On Tue, Sep 29, 2015 at 12:07:43AM +0530, Chandra Gorentla wrote:
> Please do not review this.  This is duplicate to -
> [PATCH 2/2] drivers: staging: wilc1000: wilc_msgqueue.c: Remove ineffective 
> code

I don't understand, you sent 2 2/2 patches, which one do I look at?

Please just resend the whole series.

thanks,

greg k-h
--
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] staging: wilc1000: remove wilc_platform include file

[Greg KH]

On Wed, Sep 23, 2015 at 06:03:49PM +0900, Chaehyun Lim wrote:
> This patch removes wilc_platform.h include file in wilc_oswrapper.h
> Because wilc_platform.h have several standard header files so that some
> header file should be included .c file to avoid compilation errors.
> 
> Signed-off-by: Chaehyun Lim 
> ---
>  drivers/staging/wilc1000/coreconfigurator.c | 1 +
>  drivers/staging/wilc1000/host_interface.c   | 4 
>  drivers/staging/wilc1000/wilc_oswrapper.h   | 2 --
>  drivers/staging/wilc1000/wilc_wlan_if.h | 2 +-
>  4 files changed, 6 insertions(+), 3 deletions(-)

This patch, and 6/6 doesn't apply to the tree anymore, can you rebase
and resend them?

thanks,

greg k-h
--
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 3/4] staging: wilc1000: remove define WILC_PARSE_SCAN_IN_HOST

[Greg KH]

On Wed, Sep 23, 2015 at 04:10:54PM +0900, Glen Lee wrote:
> The define WILC_PARSE_SCAN_IN_HOST is always used in the driver, so just
> delete ifdef WILC_PARSE_SCAN_IN_HOST line, ifndef WILC_PARSE_SCAN_IN_HOST
> line and it's related codes. Finally, remove define in Makefile.
> 
> Signed-off-by: Glen Lee 
> ---
>  drivers/staging/wilc1000/Makefile |  1 -
>  drivers/staging/wilc1000/host_interface.c | 62 
> ---
>  drivers/staging/wilc1000/wilc_wlan_if.h   |  3 +-
>  3 files changed, 1 insertion(+), 65 deletions(-)

This and the 4/4 patch does not apply to my tree, please rebase and
resend.

thanks,

greg kh
--
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

CT firmware beta-15 can now do A-MSDU with IBSS interfaces.

[Ben Greear]

Here is the changelog note.  This requires some corresponding driver patches to
enable the A-MSDU with IBSS because the ath10k hardware (or maybe firmware bug)
causes the BSSID in A-MSDU packets to be all zeros.

So, in CT 4.0 and 4.2 kernels there is a patch that allows all-zero BSSIDs
on IBSS interfaces.  Only tested on 4.2 so far.

This gives a modest performance gain, depending on RF environment.

I also have had a bug in the beta-15 rate-ctrl code for a week or two,
and I fixed that today as well.  Performance should be back up to
previous rates.


In addition, the ath10k firmware was always adding Legacy /b and /ag
IEs to probe requests, and the mac80211 stack was as well.  I have fixed
CT firmware to not crap itself when requested to not send any legacy
IEs, and this allows the host to have full control.  This also keeps
duplicate IEs off the air.  For backwards compat, if you want to take
advantage of this feature, you need CT kernels (or patches).


From release notes:

  *  Allow disabling firmware-added legacy, HT and VHT related IEs in probe 
requests.
 The host can do a better job of adding these, and this keeps there from 
being
 duplicated IEs in probe requests.  Requires kernel patch to take advantage 
of
 these new features.

  *  IBSS:  Allow enabling A-MSDU for IBSS.  It appears there is a bug in the
 hardware or firmware that causes the BSSID to be zero when diong A-MSDU 
frames
 for IBSS interfaces.  I cannot figure out how to fix that, and it may just 
not
 be fixable due to hardware issues.

 But, the receiving host could be configured (hacked?) to just match on the
 destination address and ignore the BSSID address, and then it appears to 
work
 just fine.

 CT Kernel (4.2 now, maybe 4.0 soon) has patches to allow enabling IBSS 
A-MSDU
 in the CT firmware.  By default, A-MSDU is (still) disabled for IBSS.

 # Enable A-MSDU IBSS on wiphy0 radio.
 echo 0x50001 > /debug/ieee80211/wiphy0/ath10k/ct_special
 # Disable A-MSDU IBSS on wiphy0 radio.
 echo 0x5 > /debug/ieee80211/wiphy0/ath10k/ct_special


http://www.candelatech.com/ath10k.php


http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.0.dev.y/.git;a=summary
http://dmz2.candelatech.com/git/gitweb.cgi?p=linux-4.2.dev.y/.git;a=summary

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

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

Re: [wireless-regdb] wireless-regdb: Update regulatory rules for South Africa (ZA) on 5GHz

[Karl Möller]

Here is an older draft document, dated end 2014 directly from the regulator 
(ICASA):

http://www.icasa.org.za/Portals/0/Regulations/Working%20Docmuents/Radio%20Frequency%20Spectrum%20Regulations/DraftRevRadioFreq.pdf

Notice on page end 80 / top 81 that it lists:

"DFS & Transmitter Power Control Obligatory” for the band in question, which is 
now deleted in the final document published in March this year.

Regards
Karl

> On 28 Sep 2015, at 7:42 PM, Johannes Berg  wrote:
> 
> On Mon, 2015-09-28 at 11:07 -0500, Seth Forshee wrote:
>> On Mon, Sep 28, 2015 at 09:44:20AM +0200, Johannes Berg wrote:
>>> 
 The bands don’t quite match up and DFS/TPC is (apparently) not 
 required for 5470 - 5725. More importantly, the max transmitted 
 power
 seems to be 1W/30dBm e.i.r.p and not 27dBm.
>>> 
>>> Without checking now, just a note: we sometimes have lower limits 
>>> here
>>> due to spectral power density, indoor/outdoor or TPC requirements.
>> 
>> One of the documents says that the TPC requirement for that range was
>> lifted in March 2015, so if it was lowered for TPC then we may be 
>> able to bump it up to 30 dBm.
>> 
> 
> That's very well possible then - the typical TCP requirement is "1/2 of
> the power w/o TPC", which would match the 3dB
> 
> 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] mac80211: fix oops in ieee80211_beacon_get_tim

[Helmut Schaa]

Christian Lamparter  schrieb:
>This patch fixes a crash which is triggered
>by __ieee80211_beacon_get returning NULL.

Ouch, thanks for catching this!
Helmut

>This causes sky_copy to crash later unless
>the hardware supports BEACON_TX_STATUS
>feature.
>
>Signed-off-by: Christian Lamparter 
>---
>"mac80211: Copy tx'ed beacons to monitor mode" added the skb_copy.
>There are few other possibilities to do this. This is just one.
>---
> net/mac80211/tx.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
>index f7317a7..666e46b 100644
>--- a/net/mac80211/tx.c
>+++ b/net/mac80211/tx.c
>@@ -3530,6 +3530,9 @@ struct sk_buff *ieee80211_beacon_get_tim(struct
>ieee80211_hw *hw,
>   struct ieee80211_supported_band *sband;
>   int shift;
> 
>+  if (!bcn)
>+  return bcn;
>+
>   if (tim_offset)
>   *tim_offset = offs.tim_offset;
> 

--
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] mac80211: fix oops in ieee80211_beacon_get_tim

[Christian Lamparter]

This patch fixes a crash which is triggered
by __ieee80211_beacon_get returning NULL.
This causes sky_copy to crash later unless
the hardware supports BEACON_TX_STATUS
feature.

Signed-off-by: Christian Lamparter 
---
"mac80211: Copy tx'ed beacons to monitor mode" added the skb_copy.
There are few other possibilities to do this. This is just one.
---
 net/mac80211/tx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index f7317a7..666e46b 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3530,6 +3530,9 @@ struct sk_buff *ieee80211_beacon_get_tim(struct 
ieee80211_hw *hw,
struct ieee80211_supported_band *sband;
int shift;
 
+   if (!bcn)
+   return bcn;
+
if (tim_offset)
*tim_offset = offs.tim_offset;
 
-- 
2.5.3

--
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 2/2] drivers: staging: wilc1000: wilc_msgqueue.c: Remove code that no effect

[Chandra Gorentla]

Please do not review this.  This is duplicate to -
[PATCH 2/2] drivers: staging: wilc1000: wilc_msgqueue.c: Remove ineffective code

On Mon, Sep 28, 2015 at 11:43:56PM +0530, Chandra S Gorentla wrote:
> Signed-off-by: Chandra S Gorentla 
> ---
>  drivers/staging/wilc1000/wilc_msgqueue.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c 
> b/drivers/staging/wilc1000/wilc_msgqueue.c
> index a01ada4..1a411d3 100644
> --- a/drivers/staging/wilc1000/wilc_msgqueue.c
> +++ b/drivers/staging/wilc1000/wilc_msgqueue.c
> @@ -133,11 +133,6 @@ int wilc_mq_recv(WILC_MsgQueueHandle *pHandle,
>   down(&pHandle->hSem);
>  
>   /* other non-timeout scenarios */
> - if (result) {
> - PRINT_ER("Non-timeout\n");
> - return result;
> - }
> -
>   if (pHandle->bExiting) {
>   PRINT_ER("pHandle fail\n");
>   return -EFAULT;
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] staging: rtl8723au: Fix resource leak

[Jes Sorensen]

Mateusz Kulikowski  writes:
> Firmware was not released properly if kmemdup fails.
>
> Addresses-Coverity-Id: 1269118
> Signed-off-by: Mateusz Kulikowski 
> ---
>  drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Acked-by: Jes Sorensen 

>
> diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c 
> b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> index cd014f7..ecf54ee 100644
> --- a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> +++ b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> @@ -249,13 +249,13 @@ int rtl8723a_FirmwareDownload(struct rtw_adapter 
> *padapter)
>   goto Exit;
>   }
>   firmware_buf = kmemdup(fw->data, fw->size, GFP_KERNEL);
> + fw_size = fw->size;
> + release_firmware(fw);
>   if (!firmware_buf) {
>   rtStatus = _FAIL;
>   goto Exit;
>   }
>   buf = firmware_buf;
> - fw_size = fw->size;
> - release_firmware(fw);
>  
>   /*  To Check Fw header. Added by tynli. 2009.12.04. */
>   pFwHdr = (struct rt_8723a_firmware_hdr *)firmware_buf;
--
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 1/2] drivers: staging: wilc1000: Replace message queue with standard Linux lists

[Chandra S Gorentla]

 - The message queue is replaced with standard Linux linked list
 - kmem_cache is used for list members
 - A check for return value of receive method is added
 - GFP_ATOMIC is changed to GFP_KERNEL
 - A few other related minor changes

Signed-off-by: Chandra S Gorentla 
---
 - Comments of Dan Carpenter are taken care
   - If receive method return value not checked, case statement for previous
 message may get executed if not done
   - Indication of usage of 'kmem_cache' is added to the description
   - Memory allocation donw outside spin_lock; GFP_ATOMIC replaced
 with GFP_KERNEL
   - spin_lock, spin_unlock are matched
   - goto statements removed
   - Unrelated changes moved to a different patch
   - PRINT_ERR can be taken up in a seperate patch

 drivers/staging/wilc1000/host_interface.c |  7 ++-
 drivers/staging/wilc1000/wilc_msgqueue.c  | 73 +--
 drivers/staging/wilc1000/wilc_platform.h  |  5 ++-
 3 files changed, 40 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 62f4a8a..954656d 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -4304,11 +4304,16 @@ static int hostIFthread(void *pvArg)
u32 u32Ret;
struct host_if_msg msg;
tstrWILC_WFIDrv *pstrWFIDrv;
+   int ret;
 
memset(&msg, 0, sizeof(struct host_if_msg));
 
while (1) {
-   wilc_mq_recv(&gMsgQHostIF, &msg, sizeof(struct host_if_msg), 
&u32Ret);
+   ret = wilc_mq_recv(&gMsgQHostIF, &msg,
+   sizeof(struct host_if_msg), &u32Ret);
+   if (ret)
+   continue;
+
pstrWFIDrv = (tstrWILC_WFIDrv *)msg.drvHandler;
if (msg.id == HOST_IF_MSG_EXIT) {
PRINT_D(GENERIC_DBG, "THREAD: Exiting HostIfThread\n");
diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c 
b/drivers/staging/wilc1000/wilc_msgqueue.c
index 869736a..a01ada4 100644
--- a/drivers/staging/wilc1000/wilc_msgqueue.c
+++ b/drivers/staging/wilc1000/wilc_msgqueue.c
@@ -12,9 +12,15 @@
  */
 int wilc_mq_create(WILC_MsgQueueHandle *pHandle)
 {
+   pHandle->msg_cache = kmem_cache_create("wilc_message_queue",
+   sizeof(Message),
+   0, SLAB_POISON, NULL);
+   if (!pHandle->msg_cache)
+   return -ENOMEM;
+
spin_lock_init(&pHandle->strCriticalSection);
sema_init(&pHandle->hSem, 0);
-   pHandle->pstrMessageList = NULL;
+   INIT_LIST_HEAD(&pHandle->msg_list_head);
pHandle->u32ReceiversCount = 0;
pHandle->bExiting = false;
return 0;
@@ -28,6 +34,7 @@ int wilc_mq_create(WILC_MsgQueueHandle *pHandle)
  */
 int wilc_mq_destroy(WILC_MsgQueueHandle *pHandle)
 {
+   Message *msg;
pHandle->bExiting = true;
 
/* Release any waiting receiver thread. */
@@ -36,13 +43,16 @@ int wilc_mq_destroy(WILC_MsgQueueHandle *pHandle)
pHandle->u32ReceiversCount--;
}
 
-   while (pHandle->pstrMessageList) {
-   Message *pstrMessge = pHandle->pstrMessageList->pstrNext;
-
-   kfree(pHandle->pstrMessageList);
-   pHandle->pstrMessageList = pstrMessge;
+   while (!list_empty(&pHandle->msg_list_head)) {
+   msg = list_first_entry(&pHandle->msg_list_head,
+   Message, link);
+   list_del(&msg->link);
+   kfree(msg->pvBuffer);
+   kmem_cache_free(pHandle->msg_cache, msg);
}
 
+   kmem_cache_destroy(pHandle->msg_cache);
+
return 0;
 }
 
@@ -55,61 +65,40 @@ int wilc_mq_destroy(WILC_MsgQueueHandle *pHandle)
 int wilc_mq_send(WILC_MsgQueueHandle *pHandle,
 const void *pvSendBuffer, u32 u32SendBufferSize)
 {
-   int result = 0;
unsigned long flags;
Message *pstrMessage = NULL;
 
if ((!pHandle) || (u32SendBufferSize == 0) || (!pvSendBuffer)) {
PRINT_ER("pHandle or pvSendBuffer is null\n");
-   result = -EFAULT;
-   goto ERRORHANDLER;
+   return -EFAULT;
}
 
if (pHandle->bExiting) {
PRINT_ER("pHandle fail\n");
-   result = -EFAULT;
-   goto ERRORHANDLER;
+   return -EFAULT;
}
 
-   spin_lock_irqsave(&pHandle->strCriticalSection, flags);
-
/* construct a new message */
-   pstrMessage = kmalloc(sizeof(Message), GFP_ATOMIC);
+   pstrMessage = kmem_cache_zalloc(pHandle->msg_cache, GFP_KERNEL);
if (!pstrMessage)
return -ENOMEM;
+
pstrMessage->u32Length = u32SendBufferSize;
-   pstrMessage->pstrNext = NULL;
-   pstrMessage->pvBuffer = kmalloc(u32SendBufferSize, GFP_ATOMIC);
+   pstrMessage->pvBuffer = kma

Pending patches in patchwork and their states

[Kalle Valo]

Arend van Spriel  writes:

> If my administration is correct there are 29 patches pending. Any
> chance these will get applied. Or did I miss some remarks requiring a
> resend.

Yeah, I have been lagging behind patches due to other stuff and I have
64 patches pending right now. Sorry about that, I should get to them in
a day or two. Here's a short summary how I use patchwork. Hopefully it
makes it easier for people to follow their patch status and I get less
emails ;)

If the patch in patchwork is in state New or Under Review they are on my
queue and waiting my action:

https://patchwork.kernel.org/project/linux-wireless/list/

If the patch is Deferred it means that there was a problem and I look at
the patch more closely later (when I have more time etc):

https://patchwork.kernel.org/project/linux-wireless/list/?state=10

Awaiting Upstream means that I cannot apply the patch right now due to a
mising patch in some other component, for example to mac80211. I will
apply the patch once the dependency is available in my tree:

https://patchwork.kernel.org/project/linux-wireless/list/?state=8

Any other state means that the patch is out of my radar due to one
reason or another, and a resend is needed to get the patch active again:

Rejected = In my opinion not acceptable patch
RFC = Request For Comments, submitter didn't officially send the patch yet
Not Applicaple = Not a wireless patch
Changes Requested = Needs a new version due to review comments
Superseded = A new version of the patch submitted without comments

And Accepted state of course means that I have commited the patch :)

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

[PATCH 2/2] drivers: staging: wilc1000: wilc_msgqueue.c: Remove code that no effect

[Chandra S Gorentla]

Signed-off-by: Chandra S Gorentla 
---
 drivers/staging/wilc1000/wilc_msgqueue.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c 
b/drivers/staging/wilc1000/wilc_msgqueue.c
index a01ada4..1a411d3 100644
--- a/drivers/staging/wilc1000/wilc_msgqueue.c
+++ b/drivers/staging/wilc1000/wilc_msgqueue.c
@@ -133,11 +133,6 @@ int wilc_mq_recv(WILC_MsgQueueHandle *pHandle,
down(&pHandle->hSem);
 
/* other non-timeout scenarios */
-   if (result) {
-   PRINT_ER("Non-timeout\n");
-   return result;
-   }
-
if (pHandle->bExiting) {
PRINT_ER("pHandle fail\n");
return -EFAULT;
-- 
2.1.4

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

[PATCH 2/2] drivers: staging: wilc1000: wilc_msgqueue.c: Remove ineffective code

[Chandra S Gorentla]

Signed-off-by: Chandra S Gorentla 
---
 drivers/staging/wilc1000/wilc_msgqueue.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c 
b/drivers/staging/wilc1000/wilc_msgqueue.c
index a01ada4..1a411d3 100644
--- a/drivers/staging/wilc1000/wilc_msgqueue.c
+++ b/drivers/staging/wilc1000/wilc_msgqueue.c
@@ -133,11 +133,6 @@ int wilc_mq_recv(WILC_MsgQueueHandle *pHandle,
down(&pHandle->hSem);
 
/* other non-timeout scenarios */
-   if (result) {
-   PRINT_ER("Non-timeout\n");
-   return result;
-   }
-
if (pHandle->bExiting) {
PRINT_ER("pHandle fail\n");
return -EFAULT;
-- 
2.1.4

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

Re: [PATCH 00/16] brcmfmac: new device support and P2P fixes

[Arend van Spriel]

On 09/18/2015 10:08 PM, Arend van Spriel wrote:

This series is intended for v4.4 containing the following highlights:

* support for BCM4350, BCM4365, and BCM4366 PCIE devices.
* fixed for legacy P2P and P2P device handling.
* correct set and get tx-power.

The series should be applied to master branch of the wireless-drivers-next
repository after the series sent earlier with
Message-ID: <1440620104-2715-1-git-send-email-ar...@broadcom.com>
and patch "brcmfmac: Reset PCIE devices after recognition." with
Message-ID: <1440684846-17214-1-git-send-email-ar...@broadcom.com>.


Hi Kalle,

If my administration is correct there are 29 patches pending. Any chance 
these will get applied. Or did I miss some remarks requiring a resend.


Regards,
Arend


Hante Meuleman (16):
   brcmfmac: Fix exception handling.
   brcmfmac: Add support for the BCM4350 PCIE device.
   brcmfmac: Fix set and get tx-power functions.
   brcmfmac: Only assign primary netdev to if2bss array.
   brcmfmac: Inform p2p module about p2pon through API
   brcmfmac: Fix bug in flowring management.
   brcmfmac: Make p2pon module param always available.
   brcmfmac: Workaround in change vif for wpa_supplicant support.
   brcmfmac: Deleting of p2p device is leaking memory.
   brcmfmac: Only handle p2p_stop_device if vif is valid
   brcmfmac: Fix p2p bug for older firmwares.
   brcmfmac: Add module parameter to disable features.
   brcmfmac: Fix race condition bug when deleting p2p interface.
   brcmfmac: Add support for the BCM4365 and BCM4366 PCIE devices.
   brcmfmac: Fix TDLS setup by properly handling p2p noif.
   brcmfmac: Accept events when TDLS is used in combination with p2p.

  drivers/net/wireless/brcm80211/brcmfmac/cfg80211.c | 186 +++--
  drivers/net/wireless/brcm80211/brcmfmac/cfg80211.h |   3 +-
  drivers/net/wireless/brcm80211/brcmfmac/chip.c | 111 ++--
  drivers/net/wireless/brcm80211/brcmfmac/core.c |  34 +++-
  drivers/net/wireless/brcm80211/brcmfmac/feature.c  |  13 ++
  drivers/net/wireless/brcm80211/brcmfmac/flowring.h |   2 +-
  drivers/net/wireless/brcm80211/brcmfmac/fweh.c |  26 ++-
  drivers/net/wireless/brcm80211/brcmfmac/fweh.h |   3 +
  drivers/net/wireless/brcm80211/brcmfmac/p2p.c  |  92 ++
  drivers/net/wireless/brcm80211/brcmfmac/p2p.h  |   5 +-
  drivers/net/wireless/brcm80211/brcmfmac/pcie.c |  31 
  .../net/wireless/brcm80211/include/brcm_hw_ids.h   |  11 ++
  include/linux/bcma/bcma.h  |   2 +
  13 files changed, 331 insertions(+), 188 deletions(-)



--
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: [wireless-regdb] wireless-regdb: Update regulatory rules for South Africa (ZA) on 5GHz

[Johannes Berg]

On Mon, 2015-09-28 at 11:07 -0500, Seth Forshee wrote:
> On Mon, Sep 28, 2015 at 09:44:20AM +0200, Johannes Berg wrote:
> > 
> > > The bands don’t quite match up and DFS/TPC is (apparently) not 
> > > required for 5470 - 5725. More importantly, the max transmitted 
> > > power
> > > seems to be 1W/30dBm e.i.r.p and not 27dBm.
> > 
> > Without checking now, just a note: we sometimes have lower limits 
> > here
> > due to spectral power density, indoor/outdoor or TPC requirements.
> 
> One of the documents says that the TPC requirement for that range was
> lifted in March 2015, so if it was lowered for TPC then we may be 
> able to bump it up to 30 dBm.
> 

That's very well possible then - the typical TCP requirement is "1/2 of
the power w/o TPC", which would match the 3dB

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] ath10k: only advertise mesh support in raw mode

[Peter Oh]

Hi,

On 09/28/2015 05:59 AM, Bob Copeland wrote:

Rather than always advertising mesh support and then generating
an error when the user attempts to bring up the device without
rawmode, only advertise it when available: that is, if the module
is loaded with rawmode=1, the firmware supports it, and the
device/firmware supports an AP virtual interface internally.

Signed-off-by: Bob Copeland 
---
Actually, I think this is perhaps worse than just spitting out an
error on interface up, but I'm sending anyway because it was requested
a couple of times in review.

The reason this is so ugly is that the structures in question are
defined const in the API; when also declared const in the driver,
they go into the .rodata section and the interface limit types
cannot be changed without causing a fault.  So this patch removes
const in a bunch of places and adds casts to const where required.

Another approach might be changing cfg80211 to silently remove interface
types from advertised combinations when the given mode is not also
in interface_modes, instead of warning and failing registration as it
does today.  But this would make errors here harder to spot.

Or we can keep it the way it is with the driver failing and showing an
error on add interface.  I'm okay with any of these approaches really.
I prefer the current design to this new approach because drivers already 
know if it's mesh capable or not at build time, hence adding runtime 
configuration is redundant.

One more thing we have to think about is enabling mesh in only raw mode.
In standard view point, mesh is only available in raw mode on ath10k, 
however ath10k is also able to run mesh in native WiFi mode in current 
mac80211 design since mac80211 handles packets per interface. So that 
mac80211 knows that packets are for mesh without looking at mesh control 
present bit when they come into mesh interface.
Because of the reason allowing mesh in raw mode on ath10k is too much 
strict in my opinion.

  drivers/net/wireless/ath/ath10k/mac.c | 98
++-
  1 file changed, 63 insertions(+), 35 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 20d002c..c689613 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4209,11 +4209,6 @@ static int ath10k_add_interface(struct ieee80211_hw
*hw,
arvif->vdev_type = WMI_VDEV_TYPE_IBSS;
break;
case NL80211_IFTYPE_MESH_POINT:
-   if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags)) {
-   ret = -EINVAL;
-   ath10k_warn(ar, "must load driver with rawmode=1
to add mesh interfaces\n");
-   goto err;
-   }
arvif->vdev_type = WMI_VDEV_TYPE_AP;
break;
case NL80211_IFTYPE_AP:
@@ -6755,7 +6750,7 @@ void ath10k_mac_destroy(struct ath10k *ar)
ieee80211_free_hw(ar->hw);
  }
  
-static const struct ieee80211_iface_limit ath10k_if_limits[] = {

+static struct ieee80211_iface_limit ath10k_if_limits[] = {
{
.max= 8,
.types  = BIT(NL80211_IFTYPE_STATION)
@@ -6772,23 +6767,17 @@ static const struct ieee80211_iface_limit
ath10k_if_limits[] = {
{
.max= 7,
.types  = BIT(NL80211_IFTYPE_AP)
-#ifdef CONFIG_MAC80211_MESH
-   | BIT(NL80211_IFTYPE_MESH_POINT)
-#endif
},
  };
  
-static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = {

+static struct ieee80211_iface_limit ath10k_10x_if_limits[] = {
{
.max= 8,
.types  = BIT(NL80211_IFTYPE_AP)
-#ifdef CONFIG_MAC80211_MESH
-   | BIT(NL80211_IFTYPE_MESH_POINT)
-#endif
},
  };
  
-static const struct ieee80211_iface_combination ath10k_if_comb[] = {

+static struct ieee80211_iface_combination ath10k_if_comb[] = {
{
.limits = ath10k_if_limits,
.n_limits = ARRAY_SIZE(ath10k_if_limits),
@@ -6798,7 +6787,7 @@ static const struct ieee80211_iface_combination
ath10k_if_comb[] = {
},
  };
  
-static const struct ieee80211_iface_combination ath10k_10x_if_comb[] = {

+static struct ieee80211_iface_combination ath10k_10x_if_comb[] = {
{
.limits = ath10k_10x_if_limits,
.n_limits = ARRAY_SIZE(ath10k_10x_if_limits),
@@ -6814,7 +6803,7 @@ static const struct ieee80211_iface_combination
ath10k_10x_if_comb[] = {
},
  };
  
-static const struct ieee80211_iface_limit ath10k_tlv_if_limit[] = {

+static struct ieee80211_iface_limit ath10k_tlv_if_limit[] = {
{
.max = 2,
.types = BIT(NL80211_IFTYPE_STATION),
@@ -6822,9 +6811,6 @@ static const struct ieee80211_iface_limit
ath10k_tlv_if_limit[] = {
{
.max = 2,
.types = BIT(NL80211_IFTYPE_AP) |
-#ifdef CONFIG_MAC80211_MESH
-BIT(NL80211_IFTYPE_MESH_PO

Re: [wireless-regdb] wireless-regdb: Update regulatory rules for South Africa (ZA) on 5GHz

[Seth Forshee]

On Mon, Sep 28, 2015 at 09:44:20AM +0200, Johannes Berg wrote:
> 
> > The bands don’t quite match up and DFS/TPC is (apparently) not 
> > required for 5470 - 5725. More importantly, the max transmitted power
> > seems to be 1W/30dBm e.i.r.p and not 27dBm.
> 
> Without checking now, just a note: we sometimes have lower limits here
> due to spectral power density, indoor/outdoor or TPC requirements.

One of the documents says that the TPC requirement for that range was
lifted in March 2015, so if it was lowered for TPC then we may be able
to bump it up to 30 dBm.

Seth
--
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 V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[David Laight]

From: James Bottomley 
> Sent: 28 September 2015 16:12
> > > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' 
> > > > operations.
> > >
> > > That's different: it's an atomic RMW operation.  The problem with the
> > > alpha was that the operation wasn't atomic (meaning that it can't be
> > > interrupted and no intermediate output states are visible).
> >
> > It is only atomic if prefixed by the 'lock' prefix.
> > Normally the read and write are separate bus cycles.
> 
> The essential point is that x86 has atomic bit ops and byte writes.
> Early alpha did not.

Early alpha didn't have any byte accesses.

On x86 if you have the following:
struct {
char  a;
volatile char b;
} *foo;
foo->a |= 4;

The compiler is likely to generate a 'bis #4, 0(rbx)' (or similar)
and the cpu will do two 32bit memory cycles that read and write
the 'volatile' field 'b'.
(gcc definitely used to do this...)

A lot of fields were made 32bit (and probably not bitfields) in the linux
kernel tree a year or two ago to avoid this very problem.

> > > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > > I believe the recent versions of gcc won't do wider accesses for 
> > > > volatile data.
> > >
> > > I don't understand this comment.  You seem to be implying gcc would do a
> > > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > > instruction exists to perform the operation on all architectures.
> >
> > Read the object code and weep...
> > It is most likely to happen for operations that are rmw (eg bit set).
> > For instance the arm cpu has limited offsets for 16bit accesses, for
> > normal structures the compiler is likely to use a 32bit rmw sequence
> > for a 16bit field that has a large offset.
> > The C language allows the compiler to do it for any access (IIRC including
> > volatiles).
> 
> I think you might be confusing different things.  Most RISC CPUs can't
> do 32 bit store immediates because there aren't enough bits in their
> arsenal, so they tend to split 32 bit loads into a left and right part
> (first the top then the offset).  This (and other things) are mostly
> what you see in code.  However, 32 bit register stores are still atomic,
> which is all we require.  It's not really the compiler's fault, it's
> mostly an architectural limitation.

No, I'm not talking about how 32bit constants are generated.
I'm talking about structure offsets.

David

N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[James Bottomley]

On Mon, 2015-09-28 at 14:50 +, David Laight wrote:
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> > Sent: 28 September 2015 15:27
> > On Mon, 2015-09-28 at 08:58 +, David Laight wrote:
> > > From: Rafael J. Wysocki
> > > > Sent: 27 September 2015 15:09
> > > ...
> > > > > > Say you have three adjacent fields in a structure, x, y, z, each 
> > > > > > one byte long.
> > > > > > Initially, all of them are equal to 0.
> > > > > >
> > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > > >
> > > > > > What's the result?
> > > > >
> > > > > I think every CPU's  cache architecure guarantees adjacent store
> > > > > integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
> > > > > thinking of old alpha SMP system where the lowest store width is 32 
> > > > > bits
> > > > > and thus you have to do RMW to update a byte, this was usually fixed 
> > > > > by
> > > > > padding (assuming the structure is not packed).  However, it was such 
> > > > > a
> > > > > problem that even the later alpha chips had byte extensions.
> > >
> > > Does linux still support those old Alphas?
> > >
> > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> > 
> > That's different: it's an atomic RMW operation.  The problem with the
> > alpha was that the operation wasn't atomic (meaning that it can't be
> > interrupted and no intermediate output states are visible).
> 
> It is only atomic if prefixed by the 'lock' prefix.
> Normally the read and write are separate bus cycles.

The essential point is that x86 has atomic bit ops and byte writes.
Early alpha did not.

> > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > I believe the recent versions of gcc won't do wider accesses for volatile 
> > > data.
> > 
> > I don't understand this comment.  You seem to be implying gcc would do a
> > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > instruction exists to perform the operation on all architectures.
> 
> Read the object code and weep...
> It is most likely to happen for operations that are rmw (eg bit set).
> For instance the arm cpu has limited offsets for 16bit accesses, for
> normal structures the compiler is likely to use a 32bit rmw sequence
> for a 16bit field that has a large offset.
> The C language allows the compiler to do it for any access (IIRC including
> volatiles).

I think you might be confusing different things.  Most RISC CPUs can't
do 32 bit store immediates because there aren't enough bits in their
arsenal, so they tend to split 32 bit loads into a left and right part
(first the top then the offset).  This (and other things) are mostly
what you see in code.  However, 32 bit register stores are still atomic,
which is all we require.  It's not really the compiler's fault, it's
mostly an architectural limitation.

James


--
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 V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[David Laight]

From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: 28 September 2015 15:27
> On Mon, 2015-09-28 at 08:58 +, David Laight wrote:
> > From: Rafael J. Wysocki
> > > Sent: 27 September 2015 15:09
> > ...
> > > > > Say you have three adjacent fields in a structure, x, y, z, each one 
> > > > > byte long.
> > > > > Initially, all of them are equal to 0.
> > > > >
> > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > >
> > > > > What's the result?
> > > >
> > > > I think every CPU's  cache architecure guarantees adjacent store
> > > > integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
> > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > padding (assuming the structure is not packed).  However, it was such a
> > > > problem that even the later alpha chips had byte extensions.
> >
> > Does linux still support those old Alphas?
> >
> > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> 
> That's different: it's an atomic RMW operation.  The problem with the
> alpha was that the operation wasn't atomic (meaning that it can't be
> interrupted and no intermediate output states are visible).

It is only atomic if prefixed by the 'lock' prefix.
Normally the read and write are separate bus cycles.
 
> > You still have to ensure the compiler doesn't do wider rmw cycles.
> > I believe the recent versions of gcc won't do wider accesses for volatile 
> > data.
> 
> I don't understand this comment.  You seem to be implying gcc would do a
> 64 bit RMW for a 32 bit store ... that would be daft when a single
> instruction exists to perform the operation on all architectures.

Read the object code and weep...
It is most likely to happen for operations that are rmw (eg bit set).
For instance the arm cpu has limited offsets for 16bit accesses, for
normal structures the compiler is likely to use a 32bit rmw sequence
for a 16bit field that has a large offset.
The C language allows the compiler to do it for any access (IIRC including
volatiles).

David

[wireless-testing:master 10/15] net/ipv4/arp.c:660:14: error: 'net' redeclared as different kind of symbol

[kbuild test robot]

tree:   
https://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git 
master
head:   75281915cd10d5ae6fe7a78bfd9fd3cce988c77b
commit: 290da6ceeb8f58d63f0810593c95753825b52f57 [10/15] Merge branch 'master' 
of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
config: mips-jz4740 (attached as .config)
reproduce:
  wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
  chmod +x ~/bin/make.cross
  git checkout 290da6ceeb8f58d63f0810593c95753825b52f57
  # save the attached .config to linux build tree
  make.cross ARCH=mips 

Note: the wireless-testing/master HEAD 75281915cd10d5ae6fe7a78bfd9fd3cce988c77b 
builds fine.
  It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

   net/ipv4/arp.c: In function 'arp_process':
>> net/ipv4/arp.c:660:14: error: 'net' redeclared as different kind of symbol
 struct net *net = dev_net(dev);
 ^
   net/ipv4/arp.c:648:36: note: previous definition of 'net' was here
static int arp_process(struct net *net, struct sock *sk, struct sk_buff 
*skb)
   ^

vim +/net +660 net/ipv4/arp.c

^1da177e Linus Torvalds2005-04-16  644  /*
^1da177e Linus Torvalds2005-04-16  645   *  Process an arp request.
^1da177e Linus Torvalds2005-04-16  646   */
^1da177e Linus Torvalds2005-04-16  647  
0c4b51f0 Eric W. Biederman 2015-09-15  648  static int arp_process(struct net 
*net, struct sock *sk, struct sk_buff *skb)
^1da177e Linus Torvalds2005-04-16  649  {
^1da177e Linus Torvalds2005-04-16  650  struct net_device *dev = 
skb->dev;
faa9dcf7 Eric Dumazet  2010-06-03  651  struct in_device *in_dev = 
__in_dev_get_rcu(dev);
^1da177e Linus Torvalds2005-04-16  652  struct arphdr *arp;
^1da177e Linus Torvalds2005-04-16  653  unsigned char *arp_ptr;
^1da177e Linus Torvalds2005-04-16  654  struct rtable *rt;
e0260fed Mark Ryden2007-12-19  655  unsigned char *sha;
9e12bb22 Al Viro   2006-09-26  656  __be32 sip, tip;
^1da177e Linus Torvalds2005-04-16  657  u16 dev_type = dev->type;
^1da177e Linus Torvalds2005-04-16  658  int addr_type;
^1da177e Linus Torvalds2005-04-16  659  struct neighbour *n;
c346dca1 YOSHIFUJI Hideaki 2008-03-25 @660  struct net *net = dev_net(dev);
63d008a4 Jiri Benc 2015-09-22  661  struct dst_entry *reply_dst = 
NULL;
56022a8f Salam Noureddine  2013-12-24  662  bool is_garp = false;
^1da177e Linus Torvalds2005-04-16  663  
^1da177e Linus Torvalds2005-04-16  664  /* arp_rcv below verifies the 
ARP header and verifies the device
^1da177e Linus Torvalds2005-04-16  665   * is ARP'able.
^1da177e Linus Torvalds2005-04-16  666   */
^1da177e Linus Torvalds2005-04-16  667  
51456b29 Ian Morris2015-04-03  668  if (!in_dev)

:: The code at line 660 was first introduced by commit
:: c346dca10840a874240c78efe3f39acf4312a1f2 [NET] NETNS: Omit 
net_device->nd_net without CONFIG_NET_NS.

:: TO: YOSHIFUJI Hideaki 
:: CC: YOSHIFUJI Hideaki 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[James Bottomley]

On Mon, 2015-09-28 at 08:58 +, David Laight wrote:
> From: Rafael J. Wysocki
> > Sent: 27 September 2015 15:09
> ...
> > > > Say you have three adjacent fields in a structure, x, y, z, each one 
> > > > byte long.
> > > > Initially, all of them are equal to 0.
> > > >
> > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > >
> > > > What's the result?
> > >
> > > I think every CPU's  cache architecure guarantees adjacent store
> > > integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
> > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > padding (assuming the structure is not packed).  However, it was such a
> > > problem that even the later alpha chips had byte extensions.
> 
> Does linux still support those old Alphas?
> 
> The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.

That's different: it's an atomic RMW operation.  The problem with the
alpha was that the operation wasn't atomic (meaning that it can't be
interrupted and no intermediate output states are visible).

> > OK, thanks!
> 
> You still have to ensure the compiler doesn't do wider rmw cycles.
> I believe the recent versions of gcc won't do wider accesses for volatile 
> data.

I don't understand this comment.  You seem to be implying gcc would do a
64 bit RMW for a 32 bit store ... that would be daft when a single
instruction exists to perform the operation on all architectures.

James


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

ath.git tree moved to kernel.org

[Kalle Valo]

Hi,

I moved my ath.git tree to kernel.org:

git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git

cgit:

https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/

I'll try to manually update the old location for a while but sooner than
later I remove the old tree. I strongly recommend to switching to the
new location asap.

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

[PATCH] ath10k: Disable PCI PS for QCA988X and QCA99X0

[akolli]

From: Anilkumar Kolli 

This patch disables PCI PS for QCA988X and QCA99X0, Since PCI PS is
validated for QCA6174, let it be enabled only for QCA6174. It would be
better to execute PCI PS related functions only for the supported devices.

PCI time out issue is observed with QCA99X0 on x86 platform, We will
disable PCI PS for QCA988X and QCA99X0 until PCI PS is properly implemented.

Taking and releasing ps_lock is causing higher CPU consumption. Michal Kazior
suggested ps_lock overhead to be reworked so that ath10k_pci_wake/sleep
functions are called less often, i.e. move the powersave logic up (only during
irq handling, tx path, submitting fw commands).

Signed-off-by: Anilkumar Kolli 
---

 drivers/net/wireless/ath/ath10k/pci.c | 83 ++-
 drivers/net/wireless/ath/ath10k/pci.h |  6 +++
 2 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/pci.c 
b/drivers/net/wireless/ath/ath10k/pci.c
index 1046ab6..36b6f34 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -465,12 +465,53 @@ static int ath10k_pci_wake_wait(struct ath10k *ar)
return -ETIMEDOUT;
 }
 
+static int ath10k_pci_force_wake(struct ath10k *ar)
+{
+   struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+   unsigned long flags;
+   int ret = 0;
+
+   spin_lock_irqsave(&ar_pci->ps_lock, flags);
+
+   if (!ar_pci->ps_awake) {
+   iowrite32(PCIE_SOC_WAKE_V_MASK,
+   ar_pci->mem + PCIE_LOCAL_BASE_ADDRESS +
+   PCIE_SOC_WAKE_ADDRESS);
+
+   ret = ath10k_pci_wake_wait(ar);
+   if (ret == 0)
+   ar_pci->ps_awake = true;
+   }
+
+   spin_unlock_irqrestore(&ar_pci->ps_lock, flags);
+
+   return ret;
+}
+
+static void ath10k_pci_force_sleep(struct ath10k *ar)
+{
+   struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+   unsigned long flags;
+
+   spin_lock_irqsave(&ar_pci->ps_lock, flags);
+
+   iowrite32(PCIE_SOC_WAKE_RESET,
+   ar_pci->mem + PCIE_LOCAL_BASE_ADDRESS +
+   PCIE_SOC_WAKE_ADDRESS);
+   ar_pci->ps_awake = false;
+
+   spin_unlock_irqrestore(&ar_pci->ps_lock, flags);
+}
+
 static int ath10k_pci_wake(struct ath10k *ar)
 {
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
unsigned long flags;
int ret = 0;
 
+   if (ar_pci->pci_ps == 0)
+   return ret;
+
spin_lock_irqsave(&ar_pci->ps_lock, flags);
 
ath10k_dbg(ar, ATH10K_DBG_PCI_PS, "pci ps wake refcount %lu awake %d\n",
@@ -502,6 +543,9 @@ static void ath10k_pci_sleep(struct ath10k *ar)
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
unsigned long flags;
 
+   if (ar_pci->pci_ps == 0)
+   return;
+
spin_lock_irqsave(&ar_pci->ps_lock, flags);
 
ath10k_dbg(ar, ATH10K_DBG_PCI_PS, "pci ps sleep refcount %lu awake 
%d\n",
@@ -544,6 +588,11 @@ static void ath10k_pci_sleep_sync(struct ath10k *ar)
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
unsigned long flags;
 
+   if (ar_pci->pci_ps == 0) {
+   ath10k_pci_force_sleep(ar);
+   return;
+   }
+
del_timer_sync(&ar_pci->ps_timer);
 
spin_lock_irqsave(&ar_pci->ps_lock, flags);
@@ -2397,6 +2446,15 @@ static int ath10k_pci_hif_resume(struct ath10k *ar)
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
struct pci_dev *pdev = ar_pci->pdev;
u32 val;
+   int ret = 0;
+
+   if (ar_pci->pci_ps == 0) {
+   ret = ath10k_pci_force_wake(ar);
+   if (ret) {
+   ath10k_err(ar, "failed to wake up target: %d\n", ret);
+   return ret;
+   }
+   }
 
/* Suspend/Resume resets the PCI configuration space, so we have to
 * re-disable the RETRY_TIMEOUT register (0x41) to keep PCI Tx retries
@@ -2407,7 +2465,7 @@ static int ath10k_pci_hif_resume(struct ath10k *ar)
if ((val & 0xff00) != 0)
pci_write_config_dword(pdev, 0x40, val & 0x00ff);
 
-   return 0;
+   return ret;
 }
 #endif
 
@@ -2501,6 +2559,16 @@ static irqreturn_t ath10k_pci_interrupt_handler(int irq, 
void *arg)
 {
struct ath10k *ar = arg;
struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+   int ret;
+
+   if (ar_pci->pci_ps == 0) {
+   ret = ath10k_pci_force_wake(ar);
+   if (ret) {
+   ath10k_warn(ar, "failed to wake device up on irq: \
+   %d\n", ret);
+   return IRQ_NONE;
+   }
+   }
 
if (ar_pci->num_msi_intrs == 0) {
if (!ath10k_pci_irq_pending(ar))
@@ -2908,17 +2976,21 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
struct ath10k_pci *ar_pci;
enum ath10k_hw_rev hw_rev;
   

[PATCH] ath10k: only advertise mesh support in raw mode

[Bob Copeland]

Rather than always advertising mesh support and then generating
an error when the user attempts to bring up the device without
rawmode, only advertise it when available: that is, if the module
is loaded with rawmode=1, the firmware supports it, and the
device/firmware supports an AP virtual interface internally.

Signed-off-by: Bob Copeland 
---
Actually, I think this is perhaps worse than just spitting out an
error on interface up, but I'm sending anyway because it was requested
a couple of times in review.

The reason this is so ugly is that the structures in question are
defined const in the API; when also declared const in the driver,
they go into the .rodata section and the interface limit types
cannot be changed without causing a fault.  So this patch removes
const in a bunch of places and adds casts to const where required.

Another approach might be changing cfg80211 to silently remove interface
types from advertised combinations when the given mode is not also
in interface_modes, instead of warning and failing registration as it
does today.  But this would make errors here harder to spot.

Or we can keep it the way it is with the driver failing and showing an
error on add interface.  I'm okay with any of these approaches really.

 drivers/net/wireless/ath/ath10k/mac.c | 98 ++-
 1 file changed, 63 insertions(+), 35 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 20d002c..c689613 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4209,11 +4209,6 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
arvif->vdev_type = WMI_VDEV_TYPE_IBSS;
break;
case NL80211_IFTYPE_MESH_POINT:
-   if (!test_bit(ATH10K_FLAG_RAW_MODE, &ar->dev_flags)) {
-   ret = -EINVAL;
-   ath10k_warn(ar, "must load driver with rawmode=1 to add 
mesh interfaces\n");
-   goto err;
-   }
arvif->vdev_type = WMI_VDEV_TYPE_AP;
break;
case NL80211_IFTYPE_AP:
@@ -6755,7 +6750,7 @@ void ath10k_mac_destroy(struct ath10k *ar)
ieee80211_free_hw(ar->hw);
 }
 
-static const struct ieee80211_iface_limit ath10k_if_limits[] = {
+static struct ieee80211_iface_limit ath10k_if_limits[] = {
{
.max= 8,
.types  = BIT(NL80211_IFTYPE_STATION)
@@ -6772,23 +6767,17 @@ static const struct ieee80211_iface_limit 
ath10k_if_limits[] = {
{
.max= 7,
.types  = BIT(NL80211_IFTYPE_AP)
-#ifdef CONFIG_MAC80211_MESH
-   | BIT(NL80211_IFTYPE_MESH_POINT)
-#endif
},
 };
 
-static const struct ieee80211_iface_limit ath10k_10x_if_limits[] = {
+static struct ieee80211_iface_limit ath10k_10x_if_limits[] = {
{
.max= 8,
.types  = BIT(NL80211_IFTYPE_AP)
-#ifdef CONFIG_MAC80211_MESH
-   | BIT(NL80211_IFTYPE_MESH_POINT)
-#endif
},
 };
 
-static const struct ieee80211_iface_combination ath10k_if_comb[] = {
+static struct ieee80211_iface_combination ath10k_if_comb[] = {
{
.limits = ath10k_if_limits,
.n_limits = ARRAY_SIZE(ath10k_if_limits),
@@ -6798,7 +6787,7 @@ static const struct ieee80211_iface_combination 
ath10k_if_comb[] = {
},
 };
 
-static const struct ieee80211_iface_combination ath10k_10x_if_comb[] = {
+static struct ieee80211_iface_combination ath10k_10x_if_comb[] = {
{
.limits = ath10k_10x_if_limits,
.n_limits = ARRAY_SIZE(ath10k_10x_if_limits),
@@ -6814,7 +6803,7 @@ static const struct ieee80211_iface_combination 
ath10k_10x_if_comb[] = {
},
 };
 
-static const struct ieee80211_iface_limit ath10k_tlv_if_limit[] = {
+static struct ieee80211_iface_limit ath10k_tlv_if_limit[] = {
{
.max = 2,
.types = BIT(NL80211_IFTYPE_STATION),
@@ -6822,9 +6811,6 @@ static const struct ieee80211_iface_limit 
ath10k_tlv_if_limit[] = {
{
.max = 2,
.types = BIT(NL80211_IFTYPE_AP) |
-#ifdef CONFIG_MAC80211_MESH
-BIT(NL80211_IFTYPE_MESH_POINT) |
-#endif
 BIT(NL80211_IFTYPE_P2P_CLIENT) |
 BIT(NL80211_IFTYPE_P2P_GO),
},
@@ -6834,7 +6820,7 @@ static const struct ieee80211_iface_limit 
ath10k_tlv_if_limit[] = {
},
 };
 
-static const struct ieee80211_iface_limit ath10k_tlv_qcs_if_limit[] = {
+static struct ieee80211_iface_limit ath10k_tlv_qcs_if_limit[] = {
{
.max = 2,
.types = BIT(NL80211_IFTYPE_STATION),
@@ -6846,9 +6832,6 @@ static const struct ieee80211_iface_limit 
ath10k_tlv_qcs_if_limit[] = {
{
.max = 1,
.types = BIT(NL80211_IFTYPE_AP) |
-#ifdef CONFIG_MAC80211_MESH
-BIT(NL80211_IFTYPE_MESH_POI

Re: Low latency communication over wifi

[Bastian Bittorf]

* Johannes Berg  [28.09.2015 14:38]:
> Depends what you're measuring, but ping should apply the same DSCP tag
> on the response I believe.

your are right, I did not know this till yet 8-)
(i applied 0xb8 with 'ping -c1 -Q' just for testing)

14:49:52.491925 IP (tos 0xb8, ttl 64, id 51117, offset 0, flags [+], proto ICMP 
(1), 
length 1500) 192.168.2.1 > 192.168.2.103: ICMP echo reply, id 14925, 
seq 1, length 1480
14:49:52.491993 IP (tos 0xb8, ttl 64, id 51117, offset 1480, flags [none], 
proto ICMP (1),
length 48) 192.168.2.1 > 192.168.2.103: icmp

bye, bastian
--
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 V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[Rafael J. Wysocki]

On Monday, September 28, 2015 10:24:58 AM Arnd Bergmann wrote:
> On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> > On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > > On 25 September 2015 at 15:19, Rafael J. Wysocki  
> > > > wrote:
> > > > > So if you allow something like debugfs to update your structure, how
> > > > > do you make sure there is the proper locking?
> > > > 
> > > > Not really sure at all.. Isn't there some debugfs locking that will
> > > > jump in, to avoid updation of fields to the same device?
> > > 
> > > No, if you need any locking to access variable, you cannot use the
> > > simple debugfs helpers but have to provide your own functions.
> > > 
> > > > >> Anyway, that problem isn't here for sure as its between two
> > > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > > >
> > > > > I guess it might be more convenient to fold this into the other patch,
> > > > > because we seem to be splitting hairs here.
> > > > 
> > > > I can and that's what I did. But then Arnd asked me to separate it
> > > > out. I can fold it back if that's what you want.
> > > 
> > > It still makes sense to keep it separate I think, the patch is clearly
> > > different from the other parts.
> > 
> > I just don't see much point in going from unsigned long to u32 and then
> > from 32 to bool if we can go directly to bool in one go.
> 
> It's only important to keep the 34-file multi-subsystem trivial cleanup
> that doesn't change any functionality separate from the bugfix.

Which isn't a bugfix really, because the EC code is not run on any big-endian
systems to my knowledge.  And it won't matter after the [2/2] anyway.

And the changelog of it doesn't really makes sense, because it talks about
future systems, but after the [2/2] no future systems will run that code in
the first place.

> If you like to avoid patching one of the files twice, the alternative would
> be to first change the API for all other instances from u32 to bool
> and leave ACPI alone, and then do the second patch that changes ACPI
> from long to bool.

My point is that this patch doesn't matter.  It doesn't really fix anything
and the result of it goes away after the second patch.

The only marginal value of having it as a separate commit is in case if
(a) we need to revert the [2/2] for some reason and (b) ACPI-based ARM systems
(the big-endian ones) become full-hardware at one point.  You know what the
chances of that are, though. :-)

That said I've ACKed the patch, because I don't care that much.  I'm not exactly
sure why you care either.

Thanks,
Rafael

--
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: Low latency communication over wifi

[Johannes Berg]

On Mon, 2015-09-28 at 14:15 +0200, Bastian Bittorf wrote:
> * Johannes Berg  [28.09.2015 14:00]:
> > > > # you have to add some magic for matching your data
> > > > e.g. $IPT -t mangle -I OUTPUT -j DSCP --set-dscp-class CS7
> > > 
> > > Again, this is ping -Q equivalent, right? I was doing
> > 
> > Yes.
> 
> IMHO this is not the same: you have to do it on both ends.
> (also the iptables thingy)
> 

Depends what you're measuring, but ping should apply the same DSCP tag
on the response I believe.

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: Low latency communication over wifi

[Bastian Bittorf]

* Johannes Berg  [28.09.2015 14:00]:
> > > # you have to add some magic for matching your data
> > > e.g. $IPT -t mangle -I OUTPUT -j DSCP --set-dscp-class CS7
> > 
> > Again, this is ping -Q equivalent, right? I was doing
> 
> Yes.

IMHO this is not the same: you have to do it on both ends.
(also the iptables thingy)

bye, bastian
--
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] staging: rtl8723au: Fix resource leak

[Sudip Mukherjee]

On Sun, Sep 27, 2015 at 09:48:19PM +0200, Mateusz Kulikowski wrote:
> Firmware was not released properly if kmemdup fails.
> 
> Addresses-Coverity-Id: 1269118
> Signed-off-by: Mateusz Kulikowski 
> ---
Not seen your v2 while replying to your v1. Sorry for the noise.

regards
sudip
--
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] staging: rtl8723au: Fix resource leak

[Sudip Mukherjee]

On Sun, Sep 27, 2015 at 09:30:54PM +0200, Mateusz Kulikowski wrote:
> Firmware was not released properly if kmemdup fails.
> 
> Addresses-Coverity-Id: 1269118
> Signed-off-by: Mateusz Kulikowski 
> ---
>  drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c 
> b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> index cd014f7..87bb87f 100644
> --- a/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> +++ b/drivers/staging/rtl8723au/hal/rtl8723a_hal_init.c
> @@ -249,13 +249,13 @@ int rtl8723a_FirmwareDownload(struct rtw_adapter 
> *padapter)
>   goto Exit;
>   }
>   firmware_buf = kmemdup(fw->data, fw->size, GFP_KERNEL);
> + release_firmware(fw);
>   if (!firmware_buf) {
>   rtStatus = _FAIL;
>   goto Exit;
>   }
>   buf = firmware_buf;
>   fw_size = fw->size;
> - release_firmware(fw);
You are releasing the firmware and then accessing fw->size here. That
just introduced a NULL pointer dereference.

regards
sudip
--
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] drivers: staging: wilc1000: Replace message queue with standard Linux lists

[Dan Carpenter]

On Sun, Sep 27, 2015 at 07:43:18PM +0530, Chandra S Gorentla wrote:
> The message queue is replaced with standard Linux linked list.  A check for
> return value of receive method is added.
> 
> Signed-off-by: Chandra S Gorentla 
> ---
>  drivers/staging/wilc1000/host_interface.c |  7 +++-
>  drivers/staging/wilc1000/wilc_msgqueue.c  | 62 
> ++-
>  drivers/staging/wilc1000/wilc_platform.h  |  5 ++-
>  3 files changed, 36 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/host_interface.c 
> b/drivers/staging/wilc1000/host_interface.c
> index 62f4a8a..8d0776f 100644
> --- a/drivers/staging/wilc1000/host_interface.c
> +++ b/drivers/staging/wilc1000/host_interface.c
> @@ -4304,11 +4304,16 @@ static int hostIFthread(void *pvArg)
>   u32 u32Ret;
>   struct host_if_msg msg;
>   tstrWILC_WFIDrv *pstrWFIDrv;
> + int recv_ret;

Name it "ret".

int ret;

>  
>   memset(&msg, 0, sizeof(struct host_if_msg));
>  
>   while (1) {
> - wilc_mq_recv(&gMsgQHostIF, &msg, sizeof(struct host_if_msg), 
> &u32Ret);
> + recv_ret = wilc_mq_recv(&gMsgQHostIF, &msg,
> + sizeof(struct host_if_msg), &u32Ret);
> + if (recv_ret)
> + continue;

This looks like a forever loop.

> +
>   pstrWFIDrv = (tstrWILC_WFIDrv *)msg.drvHandler;
>   if (msg.id == HOST_IF_MSG_EXIT) {
>   PRINT_D(GENERIC_DBG, "THREAD: Exiting HostIfThread\n");
> diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c 
> b/drivers/staging/wilc1000/wilc_msgqueue.c
> index 869736a..67617d5 100644
> --- a/drivers/staging/wilc1000/wilc_msgqueue.c
> +++ b/drivers/staging/wilc1000/wilc_msgqueue.c
> @@ -12,9 +12,15 @@
>   */
>  int wilc_mq_create(WILC_MsgQueueHandle *pHandle)
>  {
> + pHandle->msg_cache = kmem_cache_create("wilc_message_queue",
> + sizeof(Message),
> + 0, SLAB_POISON, NULL);
> + if (!pHandle->msg_cache)
> + return -ENOMEM;

This is a separate thing from using list macros.  Or maybe it's not but
that isn't explained in the changelog.  Do one thing per patch so it's
easier to review.

> +
>   spin_lock_init(&pHandle->strCriticalSection);
>   sema_init(&pHandle->hSem, 0);
> - pHandle->pstrMessageList = NULL;
> + INIT_LIST_HEAD(&pHandle->msg_list_head);
>   pHandle->u32ReceiversCount = 0;
>   pHandle->bExiting = false;
>   return 0;
> @@ -28,6 +34,7 @@ int wilc_mq_create(WILC_MsgQueueHandle *pHandle)
>   */
>  int wilc_mq_destroy(WILC_MsgQueueHandle *pHandle)
>  {
> + Message *msg;
>   pHandle->bExiting = true;
>  
>   /* Release any waiting receiver thread. */
> @@ -36,13 +43,16 @@ int wilc_mq_destroy(WILC_MsgQueueHandle *pHandle)
>   pHandle->u32ReceiversCount--;
>   }
>  
> - while (pHandle->pstrMessageList) {
> - Message *pstrMessge = pHandle->pstrMessageList->pstrNext;
> -
> - kfree(pHandle->pstrMessageList);
> - pHandle->pstrMessageList = pstrMessge;
> + while (!list_empty(&pHandle->msg_list_head)) {
> + msg = list_first_entry(&pHandle->msg_list_head,
> + Message, link);
> + list_del(&msg->link);
> + kfree(msg->pvBuffer);
> + kmem_cache_free(pHandle->msg_cache, msg);
>   }
>  
> + kmem_cache_destroy(pHandle->msg_cache);
> +
>   return 0;
>  }
>  
> @@ -74,41 +84,28 @@ int wilc_mq_send(WILC_MsgQueueHandle *pHandle,
>   spin_lock_irqsave(&pHandle->strCriticalSection, flags);
>  
>   /* construct a new message */
> - pstrMessage = kmalloc(sizeof(Message), GFP_ATOMIC);
> - if (!pstrMessage)
> + pstrMessage = kmem_cache_zalloc(pHandle->msg_cache, GFP_ATOMIC);
> + if (!pstrMessage) {
> + spin_unlock_irqrestore(&pHandle->strCriticalSection, flags);
>   return -ENOMEM;
> + }

Do the allocation outside the lock so it doesn't have to be atomic.

>   pstrMessage->u32Length = u32SendBufferSize;
> - pstrMessage->pstrNext = NULL;
>   pstrMessage->pvBuffer = kmalloc(u32SendBufferSize, GFP_ATOMIC);
>   if (!pstrMessage->pvBuffer) {
> + kmem_cache_free(pHandle->msg_cache, pstrMessage);
>   result = -ENOMEM;
>   goto ERRORHANDLER;

This goto is meaningless now that it doesn't handle any errors.  Just do
a direct return.  Except, wait, aren't we holding a couple locks?  This
looks buggy.

>   }
>   memcpy(pstrMessage->pvBuffer, pvSendBuffer, u32SendBufferSize);
>  
>   /* add it to the message queue */
> - if (!pHandle->pstrMessageList) {
> - pHandle->pstrMessageList  = pstrMessage;
> - } else {
> - Message *pstrTailMsg = pHandle->pstrMessageList;
> -
> - while (pstrTailMsg->pstrNext)
> - ps

BCM43602 firmware reports multiple BRCMF_E_DEAUTH

[Rafał Miłecki]

Hi,

I'm using recent brcmfmac and brcmfmac43602-pcie.ap.bin that currently
sits in linux-firmware.git.

In OpenWrt we have hostapd with a feature of banning STAs. It works in
a quite simple way. Whenever hostapd gets NL80211_CMD_NEW_STATION for
STA that is banned it sends NL80211_CMD_DEL_STATION.

The problem is that in such case BCM43602 firmware happens to randomly
send more than 1 BRCMF_E_DEAUTH event. It seems it can send random
amount between 1 and 3. Looks a bit like some kind of race. It's
nothing really critical, just makes hostapd log a bit confusing.

Could someone at Broadcom look at firmware source to see if you can
fix this, please?

-- 
Rafał
Sun Sep 27 19:15:22 2015 kern.info kernel: [ 1047.886433] brcmfmac: 
[brcmf_notify_connect_status_ap] event:8:BRCMF_E_ASSOC_IND 
e->addr:78:d6:f0:9b:aa:bb
Sun Sep 27 19:15:22 2015 daemon.info hostapd: wlan0: STA 78:d6:f0:9b:aa:bb IEEE 
802.11: associated
Sun Sep 27 19:15:22 2015 daemon.info hostapd: Station 78:d6:f0:9b:aa:bb assoc 
rejected by ubus handler.

Sun Sep 27 19:15:22 2015 kern.info kernel: [ 1047.897751] brcmfmac: 
[brcmf_notify_connect_status_ap] event:5:BRCMF_E_DEAUTH 
e->addr:78:d6:f0:9b:aa:bb
Sun Sep 27 19:15:22 2015 daemon.info hostapd: wlan0: STA 78:d6:f0:9b:aa:bb IEEE 
802.11: disassociated

Sun Sep 27 19:15:22 2015 kern.info kernel: [ 1047.908085] brcmfmac: 
[brcmf_notify_connect_status_ap] event:5:BRCMF_E_DEAUTH 
e->addr:78:d6:f0:9b:aa:bb
Sun Sep 27 19:15:22 2015 daemon.info hostapd: wlan0: STA 78:d6:f0:9b:aa:bb IEEE 
802.11: disassociated

Sun Sep 27 19:15:22 2015 kern.info kernel: [ 1048.414031] brcmfmac: 
[brcmf_notify_connect_status_ap] event:5:BRCMF_E_DEAUTH 
e->addr:78:d6:f0:9b:aa:bb
Sun Sep 27 19:15:22 2015 daemon.info hostapd: wlan0: STA 78:d6:f0:9b:aa:bb IEEE 
802.11: disassociated

RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[David Laight]

From: Rafael J. Wysocki
> Sent: 27 September 2015 15:09
...
> > > Say you have three adjacent fields in a structure, x, y, z, each one byte 
> > > long.
> > > Initially, all of them are equal to 0.
> > >
> > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > >
> > > What's the result?
> >
> > I think every CPU's  cache architecure guarantees adjacent store
> > integrity, even in the face of SMP, so it's x==1 and y==2.  If you're
> > thinking of old alpha SMP system where the lowest store width is 32 bits
> > and thus you have to do RMW to update a byte, this was usually fixed by
> > padding (assuming the structure is not packed).  However, it was such a
> > problem that even the later alpha chips had byte extensions.

Does linux still support those old Alphas?

The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.

> OK, thanks!

You still have to ensure the compiler doesn't do wider rmw cycles.
I believe the recent versions of gcc won't do wider accesses for volatile data.

David

N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'

[Arnd Bergmann]

On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > On 25 September 2015 at 15:19, Rafael J. Wysocki  
> > > wrote:
> > > > So if you allow something like debugfs to update your structure, how
> > > > do you make sure there is the proper locking?
> > > 
> > > Not really sure at all.. Isn't there some debugfs locking that will
> > > jump in, to avoid updation of fields to the same device?
> > 
> > No, if you need any locking to access variable, you cannot use the
> > simple debugfs helpers but have to provide your own functions.
> > 
> > > >> Anyway, that problem isn't here for sure as its between two
> > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > >
> > > > I guess it might be more convenient to fold this into the other patch,
> > > > because we seem to be splitting hairs here.
> > > 
> > > I can and that's what I did. But then Arnd asked me to separate it
> > > out. I can fold it back if that's what you want.
> > 
> > It still makes sense to keep it separate I think, the patch is clearly
> > different from the other parts.
> 
> I just don't see much point in going from unsigned long to u32 and then
> from 32 to bool if we can go directly to bool in one go.

It's only important to keep the 34-file multi-subsystem trivial cleanup
that doesn't change any functionality separate from the bugfix. If you
like to avoid patching one of the files twice, the alternative would
be to first change the API for all other instances from u32 to bool
and leave ACPI alone, and then do the second patch that changes ACPI
from long to bool.

Arnd
--
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: [wireless-regdb] wireless-regdb: Update regulatory rules for South Africa (ZA) on 5GHz

[Johannes Berg]

> The bands don’t quite match up and DFS/TPC is (apparently) not 
> required for 5470 - 5725. More importantly, the max transmitted power
> seems to be 1W/30dBm e.i.r.p and not 27dBm.

Without checking now, just a note: we sometimes have lower limits here
due to spectral power density, indoor/outdoor or TPC requirements.

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: Low latency communication over wifi

[Johannes Berg]

On Sat, 2015-09-26 at 12:24 +0200, Pavel Machek wrote:
> 
> That would be equivalent to ping -Q, right? It does not seem to have
> any effect :-(. I'd expect at least local machine to use shorter waits
> for medium, and thus drop packets instead of waiting.

Correct. But it won't *drop* packets, it just increases the chances of
getting medium access.

> > # you have to add some magic for matching your data
> > e.g. $IPT -t mangle -I OUTPUT -j DSCP --set-dscp-class CS7
> 
> Again, this is ping -Q equivalent, right? I was doing

Yes.

> ping -c 300 -i .2 -Q $[56*4] -s 500 amd
> 300 packets transmitted, 300 received, 0% packet loss, time 60989ms
> rtt min/avg/max/mdev = 2.155/8.599/44.475/5.677 ms
> 300 packets transmitted, 300 received, +1 duplicates, 0% packet loss, time 
> 61030ms
> rtt min/avg/max/mdev = 2.158/23.809/300.956/49.969 ms, pipe 2
> 
> I would expect packet loss, but got long delays instead.

See above :)

> > also you should consider force the ACK-timing to 450m / Class1
> > and forbid retransmission in minstrel
> 
> Yes, disabling retransmission would be useful. How would I do that?
> 
It won't work on Intel devices though since they don't use
minstrel(_ht)

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