[PATCH 1/3] ieee80211: Replace bit shifts with the BIT() macro for WLAN_CAPABILITY_*.

[Quytelda Kahja]

It is neater and more consistent with the rest of the document to use the
BIT() macro from 'linux/bitops.h' to define the WLAN_CAPABILITY_*
bitmasks.  In the case of WLAN_CAPABILITY_DMG_TYPE_{IBSS, PBSS, AP},
bitshifting integers by 0 does nothing, so there is no reason to do it in
the code; replace these values with plain integers.

Signed-off-by: Quytelda Kahja 
---
 include/linux/ieee80211.h | 56 +++
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index ee6657a0ed69..58069176b432 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1588,8 +1588,8 @@ struct ieee80211_vht_operation {
 
 #define WLAN_AUTH_CHALLENGE_LEN 128
 
-#define WLAN_CAPABILITY_ESS(1<<0)
-#define WLAN_CAPABILITY_IBSS   (1<<1)
+#define WLAN_CAPABILITY_ESSBIT(0)
+#define WLAN_CAPABILITY_IBSS   BIT(1)
 
 /*
  * A mesh STA sets the ESS and IBSS capability bits to zero.
@@ -1599,37 +1599,37 @@ struct ieee80211_vht_operation {
 #define WLAN_CAPABILITY_IS_STA_BSS(cap)\
(!((cap) & (WLAN_CAPABILITY_ESS | WLAN_CAPABILITY_IBSS)))
 
-#define WLAN_CAPABILITY_CF_POLLABLE(1<<2)
-#define WLAN_CAPABILITY_CF_POLL_REQUEST(1<<3)
-#define WLAN_CAPABILITY_PRIVACY(1<<4)
-#define WLAN_CAPABILITY_SHORT_PREAMBLE (1<<5)
-#define WLAN_CAPABILITY_PBCC   (1<<6)
-#define WLAN_CAPABILITY_CHANNEL_AGILITY(1<<7)
+#define WLAN_CAPABILITY_CF_POLLABLEBIT(2)
+#define WLAN_CAPABILITY_CF_POLL_REQUESTBIT(3)
+#define WLAN_CAPABILITY_PRIVACYBIT(4)
+#define WLAN_CAPABILITY_SHORT_PREAMBLE BIT(5)
+#define WLAN_CAPABILITY_PBCC   BIT(6)
+#define WLAN_CAPABILITY_CHANNEL_AGILITYBIT(7)
 
 /* 802.11h */
-#define WLAN_CAPABILITY_SPECTRUM_MGMT  (1<<8)
-#define WLAN_CAPABILITY_QOS(1<<9)
-#define WLAN_CAPABILITY_SHORT_SLOT_TIME(1<<10)
-#define WLAN_CAPABILITY_APSD   (1<<11)
-#define WLAN_CAPABILITY_RADIO_MEASURE  (1<<12)
-#define WLAN_CAPABILITY_DSSS_OFDM  (1<<13)
-#define WLAN_CAPABILITY_DEL_BACK   (1<<14)
-#define WLAN_CAPABILITY_IMM_BACK   (1<<15)
+#define WLAN_CAPABILITY_SPECTRUM_MGMT  BIT(8)
+#define WLAN_CAPABILITY_QOSBIT(9)
+#define WLAN_CAPABILITY_SHORT_SLOT_TIMEBIT(10)
+#define WLAN_CAPABILITY_APSD   BIT(11)
+#define WLAN_CAPABILITY_RADIO_MEASURE  BIT(12)
+#define WLAN_CAPABILITY_DSSS_OFDM  BIT(13)
+#define WLAN_CAPABILITY_DEL_BACK   BIT(14)
+#define WLAN_CAPABILITY_IMM_BACK   BIT(15)
 
 /* DMG (60gHz) 802.11ad */
 /* type - bits 0..1 */
-#define WLAN_CAPABILITY_DMG_TYPE_MASK  (3<<0)
-#define WLAN_CAPABILITY_DMG_TYPE_IBSS  (1<<0) /* Tx by: STA */
-#define WLAN_CAPABILITY_DMG_TYPE_PBSS  (2<<0) /* Tx by: PCP */
-#define WLAN_CAPABILITY_DMG_TYPE_AP(3<<0) /* Tx by: AP */
-
-#define WLAN_CAPABILITY_DMG_CBAP_ONLY  (1<<2)
-#define WLAN_CAPABILITY_DMG_CBAP_SOURCE(1<<3)
-#define WLAN_CAPABILITY_DMG_PRIVACY(1<<4)
-#define WLAN_CAPABILITY_DMG_ECPAC  (1<<5)
-
-#define WLAN_CAPABILITY_DMG_SPECTRUM_MGMT  (1<<8)
-#define WLAN_CAPABILITY_DMG_RADIO_MEASURE  (1<<12)
+#define WLAN_CAPABILITY_DMG_TYPE_MASK   (BIT(0) | BIT(1))
+#define WLAN_CAPABILITY_DMG_TYPE_IBSS   1 /* Tx by: STA */
+#define WLAN_CAPABILITY_DMG_TYPE_PBSS   2 /* Tx by: PCP */
+#define WLAN_CAPABILITY_DMG_TYPE_AP 3 /* Tx by: AP */
+
+#define WLAN_CAPABILITY_DMG_CBAP_ONLY  BIT(2)
+#define WLAN_CAPABILITY_DMG_CBAP_SOURCEBIT(3)
+#define WLAN_CAPABILITY_DMG_PRIVACYBIT(4)
+#define WLAN_CAPABILITY_DMG_ECPAC  BIT(5)
+
+#define WLAN_CAPABILITY_DMG_SPECTRUM_MGMT  BIT(8)
+#define WLAN_CAPABILITY_DMG_RADIO_MEASURE  BIT(12)
 
 /* measurement */
 #define IEEE80211_SPCT_MSR_RPRT_MODE_LATE  (1<<0)
-- 
2.16.2

[PATCH 3/3] ieee80211: Replace bit shifts with the BIT() macro for 802.11g ERP IEs.

[Quytelda Kahja]

It is neater and more consistent with the rest of the document to use the
BIT() macro from 'linux/bitops.h' to define the WLAN_ERP_* bitmasks.

Signed-off-by: Quytelda Kahja 
---
 include/linux/ieee80211.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index dc361ed2fb7e..bc68d542f082 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1641,9 +1641,9 @@ struct ieee80211_vht_operation {
 #define IEEE80211_SPCT_MSR_RPRT_TYPE_RPI   2
 
 /* 802.11g ERP information element */
-#define WLAN_ERP_NON_ERP_PRESENT (1<<0)
-#define WLAN_ERP_USE_PROTECTION (1<<1)
-#define WLAN_ERP_BARKER_PREAMBLE (1<<2)
+#define WLAN_ERP_NON_ERP_PRESENT BIT(0)
+#define WLAN_ERP_USE_PROTECTION  BIT(1)
+#define WLAN_ERP_BARKER_PREAMBLE BIT(2)
 
 /* WLAN_ERP_BARKER_PREAMBLE values */
 enum {
-- 
2.16.2

[PATCH 2/3] ieee80211: Replace bit shifts with the BIT() macro for measurement masks.

[Quytelda Kahja]

It is neater and more consistent with the rest of the document to use the
BIT() macro from 'linux/bitops.h' to define the
IEEE80211_SPCT_MSR_RPRT_MODE_* bitmasks.

Signed-off-by: Quytelda Kahja 
---
 include/linux/ieee80211.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 58069176b432..dc361ed2fb7e 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1632,9 +1632,9 @@ struct ieee80211_vht_operation {
 #define WLAN_CAPABILITY_DMG_RADIO_MEASURE  BIT(12)
 
 /* measurement */
-#define IEEE80211_SPCT_MSR_RPRT_MODE_LATE  (1<<0)
-#define IEEE80211_SPCT_MSR_RPRT_MODE_INCAPABLE (1<<1)
-#define IEEE80211_SPCT_MSR_RPRT_MODE_REFUSED   (1<<2)
+#define IEEE80211_SPCT_MSR_RPRT_MODE_LATE  BIT(0)
+#define IEEE80211_SPCT_MSR_RPRT_MODE_INCAPABLE BIT(1)
+#define IEEE80211_SPCT_MSR_RPRT_MODE_REFUSED   BIT(2)
 
 #define IEEE80211_SPCT_MSR_RPRT_TYPE_BASIC 0
 #define IEEE80211_SPCT_MSR_RPRT_TYPE_CCA   1
-- 
2.16.2

Re: Query on queues in mesh mode

[Phani Siriki]

Hi Thomas

I modified the code and tried to set the TXQ parameters for mesh
interface. I didn't observe any error.

However, I modified the ath9k driver code to verify default TXQ
parameters. But I am observing same values for all the queues and the
cwmin is looks different.

To my understanding, the configured parameters using netlink library
will get effect in driver queues..

nl80211 - cfg80211 - mac80211 - ath9k

Could you please let me know if I am doing something wrong.


wifi@wifi-VirtualBox:~/chaos/get_txq_code/chaos_calmer-15.05.1/build_dir/target-mips_34kc_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2015-03-09$
quilt diff
Index: compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/debug.c
===
--- compat-wireless-2015-03-09.orig/drivers/net/wireless/ath/ath9k/debug.c
+++ compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/debug.c
@@ -639,6 +639,7 @@ static int read_file_queues(struct seq_f
 {
struct ieee80211_hw *hw = dev_get_drvdata(file->private);
struct ath_softc *sc = hw->priv;
+struct ath_hw *ah = sc->sc_ah;
struct ath_txq *txq;
int i;
static const char *qname[4] = {
@@ -648,6 +649,10 @@ static int read_file_queues(struct seq_f
for (i = 0; i < IEEE80211_NUM_ACS; i++) {
txq = sc->tx.txq_map[i];
seq_printf(file, "(%s):  ", qname[i]);
+   seq_printf(file, "(%s): %u ", "cwmin", ah->txq[i].tqi_cwmin);
+   seq_printf(file, "(%s): %u ", "cwmax", ah->txq[i].tqi_cwmax);
+   seq_printf(file, "(%s): %u ", "aifs", ah->txq[i].tqi_aifs);
+   seq_printf(file, "(%s): %u ", "burst",
ah->txq[i].tqi_burstTime);
print_queue(sc, txq, file);
}

root@OpenWrt:~# cat /sys/kernel/debug/ieee80211/phy0/ath9k/queues
(VO):  (cwmin): 4294967295 (cwmax): 1023 (aifs): 2 (burst): 0 qnum: 3
qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(VI):  (cwmin): 4294967295 (cwmax): 1023 (aifs): 2 (burst): 0 qnum: 2
qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BE):  (cwmin): 4294967295 (cwmax): 1023 (aifs): 2 (burst): 0 qnum: 1
qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(BK):  (cwmin): 4294967295 (cwmax): 1023 (aifs): 2 (burst): 0 qnum: 0
qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0
(CAB): qnum: 8 qdepth:  0 ampdu-depth:  0 pending:   0 stopped: 0

Best Regards
Phani

On Fri, Mar 16, 2018 at 10:41 AM, Phani Siriki  wrote:
> Thanks Thomas. I will try to hack the code and let you know.
>
> Best Regards
> Phani
>
> On Thu, Mar 15, 2018 at 5:31 PM, Thomas Pedersen  wrote:
>> On Wed, Mar 7, 2018 at 8:39 AM, Phani Siriki  wrote:
>>> Hi Thomas
>>>
>>> Thank you for your reply.
>>>
>>> Could you please let me know how can I verify these queues on a mesh
>>> router? (I am using TPLink router with Ath9k chipset).
>>
>> try
>>
>> $ iw mesh0 mpath dump
>>
>> The mpath queue length is under the "QLEN" heading.
>>
>>> Also, the TXQ parameters can only be set if device is in AP or P2P
>>> mode. Do you have any idea why this restriction is in place?
>>
>> I don't think there is any reason modifying the queue parameters wouldn't 
>> work
>> in mesh mode. Why don't you hack up that code and give it a try.
>>
>>> https://github.com/torvalds/linux/blob/master/net/wireless/nl80211.c
>>>
>>> static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
>>> {
>>>
>>>if (info->attrs[NL80211_ATTR_WIPHY_TXQ_PARAMS]) {
>>>
>>>if (netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_AP &&
>>>netdev->ieee80211_ptr->iftype != 
>>> NL80211_IFTYPE_P2P_GO)
>>>  return -EINVAL;
>>>...
>>> }
>>>
>>> Best Regards
>>> Phani
>>>
>>> On Tue, Mar 6, 2018 at 11:59 PM, Thomas Pedersen  wrote:
 On Thu, Mar 1, 2018 at 7:27 AM, Phani Siriki  wrote:
> Hi All
>
> I am trying to understand the queuing mechanism wireless mesh networks.
>
> As per AP mode is concerned, there are four queues (BK, BE, Vi, VO)
> and traffic is controlled based on CWmin, CWmax, AIFS and TxOP.
>
> Does, mesh mode also involve these queues? Does mesh mode have any
> queue or it is just a single queue?

 mesh mode maps to the different ACs like AP mode. The only additional
 queue in mesh is the mpath->frame_queue, which may be used if an
 active mpath for a given RA can't be found.

 --
 thomas
>>
>>
>>
>> --
>> thomas

Re: [PATCH] ath9k: Protect queue draining by rcu_read_lock()

[Ben Greear]

On 02/02/2018 02:36 AM, Toke Høiland-Jørgensen wrote:

When ath9k was switched over to use the mac80211 intermediate queues,
node cleanup now drains the mac80211 queues. However, this call path is
not protected by rcu_read_lock() as it was previously entirely internal
to the driver which uses its own locking.


As far as I can tell, this is not currently in Linus' tree.

Was this dropped on purpose?

Thanks,
Ben



This leads to a possible rcu_dereference() without holding
rcu_read_lock(); but only if a station is cleaned up while having
packets queued on the TXQ. Fix this by adding the rcu_read_lock() to the
caller in ath9k.

Fixes: 50f08edf9809 ("ath9k: Switch to using mac80211 intermediate software 
queues.")
Cc: sta...@vger.kernel.org
Reported-by: Ben Greear 
Signed-off-by: Toke Høiland-Jørgensen 
---
 drivers/net/wireless/ath/ath9k/xmit.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c 
b/drivers/net/wireless/ath/ath9k/xmit.c
index 396bf05c6bf6..d8b041f48ca8 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2892,6 +2892,8 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct 
ath_node *an)
struct ath_txq *txq;
int tidno;

+   rcu_read_lock();
+
for (tidno = 0; tidno < IEEE80211_NUM_TIDS; tidno++) {
tid = ath_node_to_tid(an, tidno);
txq = tid->txq;
@@ -2909,6 +2911,8 @@ void ath_tx_node_cleanup(struct ath_softc *sc, struct 
ath_node *an)
if (!an->sta)
break; /* just one multicast ath_atx_tid */
}
+
+   rcu_read_unlock();
 }

 #ifdef CONFIG_ATH9K_TX99




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

Re: [QUESTION] Mainline support for B43_PHY_AC wifi cards

[Rafał Miłecki]

On 23 March 2018 at 15:09, Juri Lelli  wrote:
> On 23/03/18 14:43, Rafał Miłecki wrote:
>> Hi,
>>
>> On 23 March 2018 at 10:47, Juri Lelli  wrote:
>> > I've got a Dell XPS 13 9343/0TM99H (BIOS A15 01/23/2018) mounting a
>> > BCM4352 802.11ac (rev 03) wireless card and so far I've been using it on
>> > Fedora with broadcom-wl package (which I believe installs Broadcom's STA
>> > driver?). It works good apart from occasional hiccups after suspend.
>> >
>> > I'd like to get rid of that dependency (you can understand that it's
>> > particularly annoying when testing mainline kernels), but I found out
>> > that support for my card is BROKEN in mainline [1]. Just to see what
>> > happens, I forcibly enabled it witnessing that it indeed crashes like
>> > below as Kconfig warns. :)
>> >
>> >  bcma: bus0: Found chip with id 0x4352, rev 0x03 and package 0x00
>> >  bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x2B, 
>> > class 0x0)
>> >  bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x2A, 
>> > class 0x0)
>> >  bcma: bus0: Core 2 found: ARM CR4 (manuf 0x4BF, id 0x83E, rev 0x02, class 
>> > 0x0)
>> >  bcma: bus0: Core 3 found: PCIe Gen2 (manuf 0x4BF, id 0x83C, rev 0x01, 
>> > class 0x0)
>> >  bcma: bus0: Core 4 found: USB 2.0 Device (manuf 0x4BF, id 0x81A, rev 
>> > 0x11, class 0x0)
>> >  bcma: Unsupported SPROM revision: 11
>> >  bcma: bus0: Invalid SPROM read from the PCIe card, trying to use fallback 
>> > SPROM
>> >  bcma: bus0: Using fallback SPROM failed (err -2)
>> >  bcma: bus0: No SPROM available
>> >  bcma: bus0: Bus registered
>> >  b43-phy0: Broadcom 4352 WLAN found (core revision 42)
>> >  b43-phy0: Found PHY: Analog 12, Type 11 (AC), Revision 1
>> >  b43-phy0: Found Radio: Manuf 0x17F, ID 0x2069, Revision 4, Version 0
>> >  BUG: unable to handle kernel NULL pointer dereference at 
>>
>> This isn't really useful without a full backtrace.
>
> Sure. I cut it here because I didn't expect people to debug what is
> already known to be broken (but still it seemed to carry useful
> information about the hw). :)

Please paste the remaining part if you still got it.


>> > So, question: is replacing my card the only way I can get rid of this
>> > downstream dependency? :(
>>
>> It's definitely the cheapest way. Getting AC PHY into anything usable
>> (proper setup that will allow Tx & Rx anything) would probably take
>> weeks or months of development. I'm not even going to estimate cost of
>> adding support for 802.11n and 802.11ac features. I was the last
>> person actively working on b43, right now I spend my free time on
>> other hobby projects. Few people were planning to help but it seems it
>> never worked out for them.
>
> I see. Just wondering why even if Broadcom's STA solution seems to work
> fine, it is not mainline. Maybe a maintenance problem? But Fedora ships
> with very recent kernels, so I'd expect the driver to work with mainline
> (I tried compiling that against mainline, but I got errors that I didn't
> spend time figuring out how to fix).
>
> Do you know what's the deal w.r.t. the STA driver?

Driver being closed source and company not willing to open source it
is usually a big problem getting it mainline...

-- 
Rafał

[PATCH 2/4] wireless: Use octal not symbolic permissions

[Joe Perches]

Prefer the direct use of octal for permissions.

Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace
and some typing.

Miscellanea:

o Whitespace neatening around these conversions.

Signed-off-by: Joe Perches 
---
 drivers/net/wireless/ath/ath5k/base.c  |   6 +-
 drivers/net/wireless/ath/ath5k/debug.c |  37 +++
 drivers/net/wireless/ath/ath5k/sysfs.c |   8 +-
 drivers/net/wireless/ath/ath6kl/debug.c|  43 
 drivers/net/wireless/ath/ath9k/common-debug.c  |   9 +-
 drivers/net/wireless/ath/ath9k/common-spectral.c   |  10 +-
 drivers/net/wireless/ath/ath9k/debug.c |  40 
 drivers/net/wireless/ath/ath9k/debug_sta.c |   6 +-
 drivers/net/wireless/ath/ath9k/dfs_debug.c |   4 +-
 drivers/net/wireless/ath/ath9k/htc_drv_debug.c |  16 +--
 drivers/net/wireless/ath/ath9k/tx99.c  |   4 +-
 drivers/net/wireless/ath/carl9170/debug.c  |   8 +-
 drivers/net/wireless/ath/carl9170/main.c   |   4 +-
 drivers/net/wireless/ath/wcn36xx/debug.c   |   5 +-
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  |   6 +-
 .../wireless/broadcom/brcm80211/brcmsmac/debug.c   |   2 +-
 .../broadcom/brcm80211/brcmsmac/mac80211_if.c  |   2 +-
 drivers/net/wireless/cisco/airo.c  |   6 +-
 drivers/net/wireless/intel/ipw2x00/ipw2100.c   |  29 +++---
 drivers/net/wireless/intel/ipw2x00/ipw2200.c   |  51 +-
 drivers/net/wireless/intel/ipw2x00/libipw_module.c |   2 +-
 drivers/net/wireless/intel/iwlegacy/3945-mac.c |  35 +++
 drivers/net/wireless/intel/iwlegacy/4965-mac.c |  19 ++--
 drivers/net/wireless/intel/iwlegacy/4965-rs.c  |   8 +-
 drivers/net/wireless/intel/iwlegacy/common.c   |   4 +-
 drivers/net/wireless/intel/iwlegacy/debug.c|  58 ++-
 drivers/net/wireless/intel/iwlwifi/dvm/debugfs.c   |  78 +++
 drivers/net/wireless/intel/iwlwifi/dvm/rs.c|  16 +--
 drivers/net/wireless/intel/iwlwifi/fw/debugfs.c|   2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c   |  43 
 .../net/wireless/intel/iwlwifi/mvm/debugfs-vif.c   |  40 +++-
 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c   | 110 ++---
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c   |   6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c|  12 +--
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c|  12 +--
 drivers/net/wireless/intersil/p54/main.c   |   2 +-
 drivers/net/wireless/mediatek/mt76/debugfs.c   |  10 +-
 .../net/wireless/mediatek/mt76/mt76x2_debugfs.c|   8 +-
 drivers/net/wireless/mediatek/mt7601u/debugfs.c|  16 ++-
 drivers/net/wireless/ralink/rt2x00/rt2500usb.c |   2 +-
 drivers/net/wireless/ralink/rt2x00/rt2800pci.c |   2 +-
 drivers/net/wireless/ralink/rt2x00/rt2800soc.c |   2 +-
 drivers/net/wireless/ralink/rt2x00/rt2800usb.c |   2 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00debug.c   |  64 ++--
 drivers/net/wireless/ralink/rt2x00/rt61pci.c   |   2 +-
 drivers/net/wireless/ralink/rt2x00/rt73usb.c   |   2 +-
 drivers/net/wireless/ray_cs.c  |   8 +-
 drivers/net/wireless/st/cw1200/debug.c |   6 +-
 drivers/net/wireless/st/cw1200/main.c  |   2 +-
 drivers/net/wireless/ti/wl18xx/main.c  |  27 +++--
 drivers/net/wireless/ti/wlcore/main.c  |   8 +-
 drivers/net/wireless/ti/wlcore/sdio.c  |   2 +-
 drivers/net/wireless/ti/wlcore/sysfs.c |   7 +-
 53 files changed, 427 insertions(+), 486 deletions(-)

diff --git a/drivers/net/wireless/ath/ath5k/base.c 
b/drivers/net/wireless/ath/ath5k/base.c
index 527afcf39246..a2351ef45ae0 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -73,16 +73,16 @@
 #include "trace.h"
 
 bool ath5k_modparam_nohwcrypt;
-module_param_named(nohwcrypt, ath5k_modparam_nohwcrypt, bool, S_IRUGO);
+module_param_named(nohwcrypt, ath5k_modparam_nohwcrypt, bool, 0444);
 MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption.");
 
 static bool modparam_fastchanswitch;
-module_param_named(fastchanswitch, modparam_fastchanswitch, bool, S_IRUGO);
+module_param_named(fastchanswitch, modparam_fastchanswitch, bool, 0444);
 MODULE_PARM_DESC(fastchanswitch, "Enable fast channel switching for 
AR2413/AR5413 radios.");
 
 static bool ath5k_modparam_no_hw_rfkill_switch;
 module_param_named(no_hw_rfkill_switch, ath5k_modparam_no_hw_rfkill_switch,
-   bool, S_IRUGO);
+  bool, 0444);
 MODULE_PARM_DESC(no_hw_rfkill_switch, "Ignore the GPIO RFKill switch state");
 
 
diff --git a/drivers/net/wireless/ath/ath5k/debug.c 
b/drivers/net/wireless/ath/ath5k/debug.c
index bd7f6d7b199e..3513bbec4639 100644
--- a/drivers/net/wireless/ath/ath5k/debug.c
+++ b/drivers/net/wireless/ath/ath5k/debug.c
@@ -1004,32 +1004,17 @@ 

[PATCH 3/4] net: Use octal not symbolic permissions

[Joe Perches]

Prefer the direct use of octal for permissions.

Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace
and some typing.

Miscellanea:

o Whitespace neatening around these conversions.

Signed-off-by: Joe Perches 
---
 net/8021q/vlanproc.c   |  6 ++---
 net/appletalk/atalk_proc.c |  8 +++---
 net/atm/atm_sysfs.c| 12 -
 net/atm/clip.c |  2 +-
 net/atm/lec.c  |  2 +-
 net/atm/proc.c |  2 +-
 net/ax25/af_ax25.c |  6 ++---
 net/bluetooth/rfcomm/tty.c |  4 +--
 net/bridge/br_sysfs_br.c   |  2 +-
 net/bridge/br_sysfs_if.c   | 36 -
 net/can/af_can.c   |  2 +-
 net/can/gw.c   |  2 +-
 net/ceph/ceph_common.c |  2 +-
 net/core/net-procfs.c  |  6 ++---
 net/core/net-sysfs.c   | 12 -
 net/core/sock.c|  2 +-
 net/decnet/af_decnet.c |  2 +-
 net/decnet/dn_dev.c|  2 +-
 net/decnet/dn_neigh.c  |  2 +-
 net/decnet/dn_route.c  |  2 +-
 net/dns_resolver/dns_key.c |  2 +-
 net/ipv4/arp.c |  2 +-
 net/ipv4/fib_trie.c|  6 ++---
 net/ipv4/igmp.c|  4 +--
 net/ipv4/ipconfig.c|  2 +-
 net/ipv4/netfilter/ipt_CLUSTERIP.c |  2 +-
 net/ipv4/ping.c|  2 +-
 net/ipv4/proc.c|  6 ++---
 net/ipv4/raw.c |  2 +-
 net/ipv4/route.c   |  4 +--
 net/ipv4/tcp_ipv4.c|  2 +-
 net/ipv4/udp.c |  2 +-
 net/ipv6/addrconf.c|  2 +-
 net/ipv6/anycast.c |  2 +-
 net/ipv6/ip6_flowlabel.c   |  2 +-
 net/ipv6/mcast.c   |  4 +--
 net/ipv6/proc.c|  6 ++---
 net/ipv6/raw.c |  2 +-
 net/ipv6/route.c   |  2 +-
 net/kcm/kcmproc.c  |  4 +--
 net/l2tp/l2tp_ppp.c|  2 +-
 net/llc/llc_proc.c |  4 +--
 net/mac80211/rc80211_minstrel.c|  2 +-
 net/mac80211/rc80211_minstrel_debugfs.c|  8 +++---
 net/mac80211/rc80211_minstrel_ht_debugfs.c |  8 +++---
 net/netfilter/nf_conntrack_netbios_ns.c|  2 +-
 net/netfilter/nf_conntrack_snmp.c  |  2 +-
 net/netfilter/nf_conntrack_standalone.c|  2 +-
 net/netfilter/nf_log.c |  2 +-
 net/netfilter/nf_synproxy_core.c   |  2 +-
 net/netfilter/xt_IDLETIMER.c   |  2 +-
 net/netfilter/xt_recent.c  |  4 +--
 net/netrom/af_netrom.c |  6 ++---
 net/rose/af_rose.c |  8 +++---
 net/rxrpc/af_rxrpc.c   |  2 +-
 net/sctp/proc.c| 16 ++--
 net/sunrpc/auth_gss/svcauth_gss.c  |  2 +-
 net/sunrpc/cache.c | 10 +++
 net/sunrpc/debugfs.c   |  6 ++---
 net/sunrpc/rpc_pipe.c  | 42 +++---
 net/wireless/wext-proc.c   |  2 +-
 net/x25/x25_proc.c | 12 -
 net/xfrm/xfrm_proc.c   |  2 +-
 63 files changed, 161 insertions(+), 161 deletions(-)

diff --git a/net/8021q/vlanproc.c b/net/8021q/vlanproc.c
index a662ccc166df..a627a5db2125 100644
--- a/net/8021q/vlanproc.c
+++ b/net/8021q/vlanproc.c
@@ -148,8 +148,8 @@ int __net_init vlan_proc_init(struct net *net)
if (!vn->proc_vlan_dir)
goto err;
 
-   vn->proc_vlan_conf = proc_create(name_conf, S_IFREG|S_IRUSR|S_IWUSR,
-vn->proc_vlan_dir, _fops);
+   vn->proc_vlan_conf = proc_create(name_conf, S_IFREG | 0600,
+vn->proc_vlan_dir, _fops);
if (!vn->proc_vlan_conf)
goto err;
return 0;
@@ -172,7 +172,7 @@ int vlan_proc_add_dev(struct net_device *vlandev)
if (!strcmp(vlandev->name, name_conf))
return -EINVAL;
vlan->dent =
-   proc_create_data(vlandev->name, S_IFREG|S_IRUSR|S_IWUSR,
+   proc_create_data(vlandev->name, S_IFREG | 0600,
 vn->proc_vlan_dir, _fops, vlandev);
if (!vlan->dent)
return -ENOBUFS;
diff --git a/net/appletalk/atalk_proc.c b/net/appletalk/atalk_proc.c
index a3bf9d519193..7214aea14cb3 100644
--- a/net/appletalk/atalk_proc.c
+++ b/net/appletalk/atalk_proc.c
@@ -257,22 +257,22 @@ int __init 

[PATCH 0/4] net: drivers/net: Use octal permissions

[Joe Perches]

Using octal and not symbolic permissions is preferred by many as
more readable.

https://lkml.org/lkml/2016/8/2/1945

Rather than getting these piecemeal, just do them all.
Done with checkpatch and some typing.

Joe Perches (4):
  ethernet: Use octal not symbolic permissions
  wireless: Use octal not symbolic permissions
  net: Use octal not symbolic permissions
  drivers/net: Use octal not symbolic permissions

 drivers/net/bonding/bond_procfs.c  |   2 +-
 drivers/net/bonding/bond_sysfs.c   |  73 +++---
 drivers/net/bonding/bond_sysfs_slave.c |   4 +-
 drivers/net/caif/caif_serial.c |  32 +++---
 drivers/net/caif/caif_spi.c|  16 +--
 drivers/net/caif/caif_virtio.c |  16 +--
 drivers/net/can/at91_can.c |   3 +-
 drivers/net/can/cc770/cc770.c  |   4 +-
 drivers/net/can/cc770/cc770_isa.c  |  16 +--
 drivers/net/can/grcan.c|   4 +-
 drivers/net/can/janz-ican3.c   |   6 +-
 drivers/net/can/sja1000/sja1000_isa.c  |  14 +--
 drivers/net/can/softing/softing_main.c |   4 +-
 drivers/net/can/spi/mcp251x.c  |   2 +-
 drivers/net/can/usb/esd_usb2.c |   6 +-
 drivers/net/can/vcan.c |   2 +-
 drivers/net/ethernet/8390/apne.c   |   2 +-
 drivers/net/ethernet/8390/lib8390.c|   2 +-
 drivers/net/ethernet/8390/ne.c |   2 +-
 drivers/net/ethernet/8390/ne2k-pci.c   |   2 +-
 drivers/net/ethernet/8390/smc-ultra.c  |   2 +-
 drivers/net/ethernet/8390/stnic.c  |   2 +-
 drivers/net/ethernet/8390/wd.c |   2 +-
 drivers/net/ethernet/altera/altera_tse_main.c  |   6 +-
 drivers/net/ethernet/amd/xgbe/xgbe-drv.c   |  10 +-
 drivers/net/ethernet/amd/xgbe/xgbe-main.c  |   2 +-
 drivers/net/ethernet/broadcom/bnx2.c   |   2 +-
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c   |  12 +--
 drivers/net/ethernet/broadcom/sb1250-mac.c |  10 +-
 drivers/net/ethernet/broadcom/tg3.c|   6 +-
 drivers/net/ethernet/brocade/bna/bnad.c|   2 +-
 drivers/net/ethernet/brocade/bna/bnad_debugfs.c|  10 +-
 drivers/net/ethernet/cavium/thunder/nicvf_main.c   |   2 +-
 drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c|   6 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 112 ++---
 .../net/ethernet/chelsio/cxgb4vf/cxgb4vf_main.c|  10 +-
 drivers/net/ethernet/ec_bhf.c  |   2 +-
 drivers/net/ethernet/emulex/benet/be_main.c|   6 +-
 drivers/net/ethernet/ibm/ehea/ehea_main.c  |   7 +-
 drivers/net/ethernet/ibm/ibmveth.c |   2 +-
 drivers/net/ethernet/intel/igb/igb_hwmon.c |   2 +-
 drivers/net/ethernet/intel/ixgbe/ixgbe_sysfs.c |   2 +-
 drivers/net/ethernet/marvell/mvneta.c  |   8 +-
 drivers/net/ethernet/marvell/skge.c|   2 +-
 drivers/net/ethernet/marvell/sky2.c|   2 +-
 drivers/net/ethernet/mellanox/mlx4/main.c  |  16 +--
 drivers/net/ethernet/mellanox/mlxsw/core_hwmon.c   |  10 +-
 drivers/net/ethernet/myricom/myri10ge/myri10ge.c   |  32 +++---
 .../net/ethernet/netronome/nfp/nfp_net_debugfs.c   |   6 +-
 .../net/ethernet/qlogic/netxen/netxen_nic_main.c   |  14 +--
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_sysfs.c  |  30 +++---
 drivers/net/ethernet/qualcomm/qca_debug.c  |   2 +-
 drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c|   4 +-
 drivers/net/ethernet/sfc/mcdi_mon.c|   2 +-
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  |  26 ++---
 drivers/net/ethernet/sun/niu.c |  10 +-
 drivers/net/hamradio/bpqether.c|   3 +-
 drivers/net/hamradio/yam.c |   2 +-
 drivers/net/hyperv/netvsc_drv.c|   4 +-
 drivers/net/ieee802154/at86rf230.c |   2 +-
 drivers/net/phy/spi_ks8995.c   |   2 +-
 drivers/net/ppp/ppp_generic.c  |   2 +-
 drivers/net/ppp/pppoe.c|   2 +-
 drivers/net/usb/cdc_ncm.c  |  12 +--
 drivers/net/usb/hso.c  |   8 +-
 drivers/net/wireless/ath/ath5k/base.c  |   6 +-
 drivers/net/wireless/ath/ath5k/debug.c |  37 ++-
 drivers/net/wireless/ath/ath5k/sysfs.c |   8 +-
 drivers/net/wireless/ath/ath6kl/debug.c|  43 
 drivers/net/wireless/ath/ath9k/common-debug.c  |   9 +-
 drivers/net/wireless/ath/ath9k/common-spectral.c   |  10 +-
 drivers/net/wireless/ath/ath9k/debug.c |  40 
 drivers/net/wireless/ath/ath9k/debug_sta.c |   6 +-
 drivers/net/wireless/ath/ath9k/dfs_debug.c |   4 

Re: iwlwifi intermittent beacon capture in monitor mode?

[Tyler Gray]

On Fri, Mar 23, 2018 at 12:26 PM, Johannes Berg
 wrote:
> On Fri, 2018-03-23 at 11:02 -0400, Tyler Gray wrote:
>> You mentioned the firmware can suppress beacons for powersaving.  Is
>> there any debug I could look at to see if that was happening?  I
>> posted some fw_rx_stats, would those counters be incremented before
>> that filtering would happen?  I just watched the counters during a
>> good period and a bad period.  In the "good" period I saw 15 CCK
>> packets/second, which is what I'd expect for my AP beaconing plus some
>> some probe responses and some beacons from the adjacent channel.
>> During the bad period the firmware saw 2 CCK packets in 7 seconds, and
>> none of the error counters for the bad period showed an additional 100
>> packets lost for any reason.  The two periods had fairly similar
>> plcp_err stats.
>
> I'd have to check.

It'd be great to know, or any other kind of debugging you'd suggest to
pin it down to the packet isn't received at all, it isn't making it
out of firmware, or it isn't making it out of the driver.  We did set
the debug level to 0x and that seems to generate 3-4 syslog
entries per packet received, and I again see no activity when the
beacons aren't showing up, so I'm pretty sure we're getting lost
before the driver level.

> ISTR being told that 8260 devices would make much better sniffers - any
> chances you have one of those to try?

The 7265 seems to be really popular in that 12x16mm soldered down
package, so we're kind of tied to it because it's in hardware we want
to use and there's no easy way to replace it.

> Perhaps you could file a bug on bugzilla.kernel.org so we can track this
> better.

Thanks, I'll submit something next week.

Re: [PATCH v2 2/2] drivers: remove force dma flag from buses

[kbuild test robot]

Hi Nipun,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6 next-20180323]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nipun-Gupta/dma-mapping-move-dma-configuration-to-bus-infrastructure/20180323-232307
config: i386-randconfig-x014-201811 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers//bcma/main.c: In function 'bcma_of_fill_device':
>> drivers//bcma/main.c:210:2: error: too many arguments to function 
>> 'of_dma_configure'
 of_dma_configure(>dev, node, false);
 ^~~~
   In file included from include/linux/of_platform.h:12:0,
from drivers//bcma/main.c:17:
   include/linux/of_device.h:110:19: note: declared here
static inline int of_dma_configure(struct device *dev, struct device_node 
*np)
  ^~~~

vim +/of_dma_configure +210 drivers//bcma/main.c

   198  
   199  static void bcma_of_fill_device(struct device *parent,
   200  struct bcma_device *core)
   201  {
   202  struct device_node *node;
   203  
   204  node = bcma_of_find_child_device(parent, core);
   205  if (node)
   206  core->dev.of_node = node;
   207  
   208  core->irq = bcma_of_get_irq(parent, core, 0);
   209  
 > 210  of_dma_configure(>dev, node, false);
   211  }
   212  

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


.config.gz
Description: application/gzip

Re: iwlwifi intermittent beacon capture in monitor mode?

[Johannes Berg]

On Fri, 2018-03-23 at 11:02 -0400, Tyler Gray wrote:

> I'm positive we're just in monitor mode. [snip]

Ok, it was just a thought.

> To be clear, I'm not claiming I can set two devices up anywhere,
> anytime, and run this test and see huge gaps in beacons, but we've
> tested across multiple devices and multiple brands of devices with
> 7265 cards, and we have data collected in locations that are miles
> apart that show the same behavior, so I'm confident this isn't just
> one bad card or one incredibly unlucky setup that shows the problem.
> I have determined spots where I'm far more likely to see the issue,
> but I'll maintain that outside of a pathologically bad environment, I
> should be able to see beacons from 6 feet away.
> 
> You mentioned the firmware can suppress beacons for powersaving.  Is
> there any debug I could look at to see if that was happening?  I
> posted some fw_rx_stats, would those counters be incremented before
> that filtering would happen?  I just watched the counters during a
> good period and a bad period.  In the "good" period I saw 15 CCK
> packets/second, which is what I'd expect for my AP beaconing plus some
> some probe responses and some beacons from the adjacent channel.
> During the bad period the firmware saw 2 CCK packets in 7 seconds, and
> none of the error counters for the bad period showed an additional 100
> packets lost for any reason.  The two periods had fairly similar
> plcp_err stats.

I'd have to check.

ISTR being told that 8260 devices would make much better sniffers - any
chances you have one of those to try?

> As a side note, if I have a device connect to the AP and run iperf to
> generate data, I'll capture an average of 99% of the data packets, yet
> I'll often see 0 beacons while the transfer is happening.  So it's not
> that I can't receive packets at all, and capturing those data packets
> should be a far harder task, but it seems beacons get dropped in a
> variety of cases and I can't determine why.

Interesting.

> Are there any known conflicts between the bluetooth and the wifi?  Is
> there an easy answer to the best (lowest level) way to disable
> bluetooth if so?

rmmod btusb ;-)

I don't really know for sure, but I wouldn't really expect BT to affect
single-chain RX performance much.

Perhaps you could file a bug on bugzilla.kernel.org so we can track this
better.

johannes

Re: [PATCH v2 2/2] drivers: remove force dma flag from buses

[kbuild test robot]

Hi Nipun,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc6 next-20180323]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Nipun-Gupta/dma-mapping-move-dma-configuration-to-bus-infrastructure/20180323-232307
config: i386-randconfig-x013-201811 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/base/dma-mapping.c: In function 'dma_common_configure':
>> drivers/base/dma-mapping.c:344:9: error: too many arguments to function 
>> 'of_dma_configure'
  ret = of_dma_configure(dev, dev->of_node, force_dma);
^~~~
   In file included from drivers/base/dma-mapping.c:13:0:
   include/linux/of_device.h:110:19: note: declared here
static inline int of_dma_configure(struct device *dev, struct device_node 
*np)
  ^~~~
--
   drivers/pci/pci-driver.c: In function 'pci_dma_configure':
>> drivers/pci/pci-driver.c:1544:9: error: too many arguments to function 
>> 'of_dma_configure'
  ret = of_dma_configure(dev, bridge->parent->of_node, true);
^~~~
   In file included from drivers/pci/pci-driver.c:21:0:
   include/linux/of_device.h:110:19: note: declared here
static inline int of_dma_configure(struct device *dev, struct device_node 
*np)
  ^~~~

vim +/of_dma_configure +344 drivers/base/dma-mapping.c

   332  
   333  /*
   334   * Common configuration to enable DMA API use for a device.
   335   * A bus can use this function in its 'dma_configure' callback, if
   336   * suitable for the bus.
   337   */
   338  int dma_common_configure(struct device *dev, bool force_dma)
   339  {
   340  enum dev_dma_attr attr;
   341  int ret = 0;
   342  
   343  if (dev->of_node) {
 > 344  ret = of_dma_configure(dev, dev->of_node, force_dma);
   345  } else if (has_acpi_companion(dev)) {
   346  attr = 
acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
   347  if (attr != DEV_DMA_NOT_SUPPORTED)
   348  ret = acpi_dma_configure(dev, attr);
   349  }
   350  
   351  return ret;
   352  }
   353  

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


.config.gz
Description: application/gzip

[PATCH 8/9] staging: wilc1000: split handle_rcvd_gnrl_async_info() to avoid leading tabs

[Ajay Singh]

Fix 'Too many leading tabs' issue found by checkpatch.pl script in
handle_rcvd_gnrl_async_info().

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 286 --
 1 file changed, 149 insertions(+), 137 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 74095ec..bb13adb 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1302,6 +1302,153 @@ static s32 host_int_get_assoc_res_info(struct wilc_vif 
*vif,
   u32 max_assoc_resp_info_len,
   u32 *rcvd_assoc_resp_info_len);
 
+static inline void host_int_free_user_conn_req(struct host_if_drv *hif_drv)
+{
+   hif_drv->usr_conn_req.ssid_len = 0;
+   kfree(hif_drv->usr_conn_req.ssid);
+   hif_drv->usr_conn_req.ssid = NULL;
+   kfree(hif_drv->usr_conn_req.bssid);
+   hif_drv->usr_conn_req.bssid = NULL;
+   hif_drv->usr_conn_req.ies_len = 0;
+   kfree(hif_drv->usr_conn_req.ies);
+   hif_drv->usr_conn_req.ies = NULL;
+}
+
+static inline void host_int_parse_assoc_resp_info(struct wilc_vif *vif,
+ u8 mac_status)
+{
+   struct connect_resp_info *connect_resp_info = NULL;
+   struct connect_info conn_info;
+   struct host_if_drv *hif_drv = vif->hif_drv;
+
+   memset(_info, 0, sizeof(struct connect_info));
+
+   if (mac_status == MAC_CONNECTED) {
+   u32 rcvd_assoc_resp_info_len;
+
+   memset(rcv_assoc_resp, 0, MAX_ASSOC_RESP_FRAME_SIZE);
+
+   host_int_get_assoc_res_info(vif, rcv_assoc_resp,
+   MAX_ASSOC_RESP_FRAME_SIZE,
+   _assoc_resp_info_len);
+
+   if (rcvd_assoc_resp_info_len != 0) {
+   s32 err = 0;
+
+   err = wilc_parse_assoc_resp_info(rcv_assoc_resp, 
rcvd_assoc_resp_info_len,
+_resp_info);
+   if (err) {
+   netdev_err(vif->ndev,
+  "wilc_parse_assoc_resp_info() 
returned error %d\n",
+  err);
+   } else {
+   conn_info.status = connect_resp_info->status;
+
+   if (conn_info.status == SUCCESSFUL_STATUSCODE &&
+   connect_resp_info->ies) {
+   conn_info.resp_ies_len = 
connect_resp_info->ies_len;
+   conn_info.resp_ies = 
kmalloc(connect_resp_info->ies_len, GFP_KERNEL);
+   memcpy(conn_info.resp_ies, 
connect_resp_info->ies,
+  connect_resp_info->ies_len);
+   }
+
+   if (connect_resp_info) {
+   kfree(connect_resp_info->ies);
+   kfree(connect_resp_info);
+   }
+   }
+   }
+   }
+
+   if (mac_status == MAC_CONNECTED &&
+   conn_info.status != SUCCESSFUL_STATUSCODE) {
+   netdev_err(vif->ndev,
+  "Received MAC status is MAC_CONNECTED while the 
received status code in Asoc Resp is not SUCCESSFUL_STATUSCODE\n");
+   eth_zero_addr(wilc_connected_ssid);
+   } else if (mac_status == MAC_DISCONNECTED){
+   netdev_err(vif->ndev, "Received MAC status is 
MAC_DISCONNECTED\n");
+   eth_zero_addr(wilc_connected_ssid);
+   }
+
+   if (hif_drv->usr_conn_req.bssid) {
+   memcpy(conn_info.bssid, hif_drv->usr_conn_req.bssid, 6);
+
+   if (mac_status == MAC_CONNECTED &&
+   conn_info.status == SUCCESSFUL_STATUSCODE) {
+   memcpy(hif_drv->assoc_bssid,
+  hif_drv->usr_conn_req.bssid, ETH_ALEN);
+   }
+   }
+
+   if (hif_drv->usr_conn_req.ies) {
+   conn_info.req_ies_len = hif_drv->usr_conn_req.ies_len;
+   conn_info.req_ies = kmalloc(hif_drv->usr_conn_req.ies_len,
+   GFP_KERNEL);
+   memcpy(conn_info.req_ies, hif_drv->usr_conn_req.ies,
+  hif_drv->usr_conn_req.ies_len);
+   }
+
+   del_timer(_drv->connect_timer);
+   hif_drv->usr_conn_req.conn_result(CONN_DISCONN_EVENT_CONN_RESP,
+ _info, mac_status, NULL,
+ hif_drv->usr_conn_req.arg);
+
+   if (mac_status == MAC_CONNECTED &&
+   conn_info.status == SUCCESSFUL_STATUSCODE) {
+  

[PATCH 7/9] staging: wilc1000: free allocated memory in wilc_add_rx_gtk()

[Ajay Singh]

Free memory allocated in wilc_add_rx_gtk() before returing from the
function.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index a8771d5..74095ec 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2881,8 +2881,10 @@ int wilc_add_rx_gtk(struct wilc_vif *vif, const u8 
*rx_gtk, u8 gtk_key_len,
msg.body.key_info.attr.wpa.key = kmemdup(rx_gtk,
 key_len,
 GFP_KERNEL);
-   if (!msg.body.key_info.attr.wpa.key)
+   if (!msg.body.key_info.attr.wpa.key) {
+   kfree(msg.body.key_info.attr.wpa.seq);
return -ENOMEM;
+   }
 
if (rx_mic)
memcpy(msg.body.key_info.attr.wpa.key + 16, rx_mic,
@@ -2897,10 +2899,13 @@ int wilc_add_rx_gtk(struct wilc_vif *vif, const u8 
*rx_gtk, u8 gtk_key_len,
msg.body.key_info.attr.wpa.seq_len = key_rsc_len;
 
result = wilc_enqueue_cmd();
-   if (result)
+   if (result) {
netdev_err(vif->ndev, "RX GTK\n");
-   else
+   kfree(msg.body.key_info.attr.wpa.seq);
+   kfree(msg.body.key_info.attr.wpa.key);
+   } else {
wait_for_completion(_drv->comp_test_key_block);
+   }
 
return result;
 }
-- 
2.7.4

[PATCH 9/9] staging: wilc1000: free memory allocated for general info message from firmware

[Ajay Singh]

Free allocated memory for failure scenario while processing the
information message received from the firmware. Added NULL check and used
kmemdup in the flow of handling information message.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 48 ---
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index bb13adb..d35885b 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1346,16 +1346,15 @@ static inline void 
host_int_parse_assoc_resp_info(struct wilc_vif *vif,
 
if (conn_info.status == SUCCESSFUL_STATUSCODE &&
connect_resp_info->ies) {
-   conn_info.resp_ies_len = 
connect_resp_info->ies_len;
-   conn_info.resp_ies = 
kmalloc(connect_resp_info->ies_len, GFP_KERNEL);
-   memcpy(conn_info.resp_ies, 
connect_resp_info->ies,
-  connect_resp_info->ies_len);
+   conn_info.resp_ies = 
kmemdup(connect_resp_info->ies,
+
connect_resp_info->ies_len,
+
GFP_KERNEL);
+   if (conn_info.resp_ies)
+   conn_info.resp_ies_len = 
connect_resp_info->ies_len;
}
 
-   if (connect_resp_info) {
-   kfree(connect_resp_info->ies);
-   kfree(connect_resp_info);
-   }
+   kfree(connect_resp_info->ies);
+   kfree(connect_resp_info);
}
}
}
@@ -1381,11 +1380,11 @@ static inline void 
host_int_parse_assoc_resp_info(struct wilc_vif *vif,
}
 
if (hif_drv->usr_conn_req.ies) {
-   conn_info.req_ies_len = hif_drv->usr_conn_req.ies_len;
-   conn_info.req_ies = kmalloc(hif_drv->usr_conn_req.ies_len,
+   conn_info.req_ies = kmemdup(conn_info.req_ies,
+   hif_drv->usr_conn_req.ies_len,
GFP_KERNEL);
-   memcpy(conn_info.req_ies, hif_drv->usr_conn_req.ies,
-  hif_drv->usr_conn_req.ies_len);
+   if (conn_info.req_ies)
+   conn_info.req_ies_len = hif_drv->usr_conn_req.ies_len;
}
 
del_timer(_drv->connect_timer);
@@ -1463,17 +1462,25 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif 
*vif,
u8 mac_status_additional_info;
struct host_if_drv *hif_drv = vif->hif_drv;
 
+   if (!rcvd_info->buffer) {
+   netdev_err(vif->ndev, "Received buffer is NULL\n");
+   return -EINVAL;
+   }
+
if (!hif_drv) {
netdev_err(vif->ndev, "Driver handler is NULL\n");
+   kfree(rcvd_info->buffer);
+   rcvd_info->buffer = NULL;
return -ENODEV;
}
 
if (hif_drv->hif_state == HOST_IF_WAITING_CONN_RESP ||
hif_drv->hif_state == HOST_IF_CONNECTED ||
hif_drv->usr_scan_req.scan_result) {
-   if (!rcvd_info->buffer ||
-   !hif_drv->usr_conn_req.conn_result) {
+   if (!hif_drv->usr_conn_req.conn_result) {
netdev_err(vif->ndev, "driver is null\n");
+   kfree(rcvd_info->buffer);
+   rcvd_info->buffer = NULL;
return -EINVAL;
}
 
@@ -1481,6 +1488,8 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif 
*vif,
 
if ('I' != msg_type) {
netdev_err(vif->ndev, "Received Message incorrect.\n");
+   kfree(rcvd_info->buffer);
+   rcvd_info->buffer = NULL;
return -EFAULT;
}
 
@@ -3528,12 +3537,17 @@ void wilc_gnrl_async_info_received(struct wilc *wilc, 
u8 *buffer, u32 length)
msg.vif = vif;
 
msg.body.async_info.len = length;
-   msg.body.async_info.buffer = kmalloc(length, GFP_KERNEL);
-   memcpy(msg.body.async_info.buffer, buffer, length);
+   msg.body.async_info.buffer = kmemdup(buffer, length, GFP_KERNEL);
+   if (!msg.body.async_info.buffer) {
+   mutex_unlock(_deinit_lock);
+   return;
+   }
 
result = wilc_enqueue_cmd();
-   if (result)
+   if (result) {
netdev_err(vif->ndev, "synchronous info (%d)\n", result);
+   

[PATCH 6/9] staging: wilc1000: fix to free allocated memory in wilc_add_ptk()

[Ajay Singh]

Free allocated memory in wilc_add_ptk() when it fails to enqueue the
command.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index f493c78..a8771d5 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2827,10 +2827,12 @@ int wilc_add_ptk(struct wilc_vif *vif, const u8 *ptk, 
u8 ptk_key_len,
 
result = wilc_enqueue_cmd();
 
-   if (result)
+   if (result) {
netdev_err(vif->ndev, "PTK Key\n");
-   else
+   kfree(msg.body.key_info.attr.wpa.key);
+   } else {
wait_for_completion(_drv->comp_test_key_block);
+   }
 
return result;
 }
-- 
2.7.4

[PATCH 4/9] staging: wilc1000: free memory allocated in add wep key functions

[Ajay Singh]

Free memory allocated for wep key when command enqueue is failed.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 1cc4c08..c958dd3 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2727,8 +2727,10 @@ int wilc_add_wep_key_bss_sta(struct wilc_vif *vif, const 
u8 *key, u8 len,
msg.body.key_info.attr.wep.index = index;
 
result = wilc_enqueue_cmd();
-   if (result)
+   if (result) {
netdev_err(vif->ndev, "STA - WEP Key\n");
+   kfree(msg.body.key_info.attr.wep.key);
+   }
wait_for_completion(_drv->comp_test_key_block);
 
return result;
@@ -2763,10 +2765,12 @@ int wilc_add_wep_key_bss_ap(struct wilc_vif *vif, const 
u8 *key, u8 len,
 
result = wilc_enqueue_cmd();
 
-   if (result)
+   if (result) {
netdev_err(vif->ndev, "AP - WEP Key\n");
-   else
+   kfree(msg.body.key_info.attr.wep.key);
+   } else {
wait_for_completion(_drv->comp_test_key_block);
+   }
 
return result;
 }
-- 
2.7.4

[PATCH 3/9] staging: wilc1000: free allocated memory in edit and add station functions

[Ajay Singh]

Added fix to free the allocated memory in case of failure to enqueue
the command.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 70c10bc..1cc4c08 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3709,8 +3709,10 @@ int wilc_add_station(struct wilc_vif *vif, struct 
add_sta_param *sta_param)
}
 
result = wilc_enqueue_cmd();
-   if (result)
+   if (result) {
netdev_err(vif->ndev, "wilc_mq_send fail\n");
+   kfree(add_sta_info->rates);
+   }
return result;
 }
 
@@ -3793,8 +3795,10 @@ int wilc_edit_station(struct wilc_vif *vif,
}
 
result = wilc_enqueue_cmd();
-   if (result)
+   if (result) {
netdev_err(vif->ndev, "wilc_mq_send fail\n");
+   kfree(add_sta_info->rates);
+   }
 
return result;
 }
-- 
2.7.4

[PATCH 5/9] staging: wilc1000: free allocated memory after processing wilc_send_config_pkt()

[Ajay Singh]

Free allocated memory after completing wilc_send_config_pkt() function.
Remove unncessary use of 'stamac' pointer in handle_get_inactive_time().

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index c958dd3..f493c78 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1909,7 +1909,6 @@ static s32 handle_get_inactive_time(struct wilc_vif *vif,
struct sta_inactive_t *hif_sta_inactive)
 {
s32 result = 0;
-   u8 *stamac;
struct wid wid;
struct host_if_drv *hif_drv = vif->hif_drv;
 
@@ -1920,11 +1919,11 @@ static s32 handle_get_inactive_time(struct wilc_vif 
*vif,
if (!wid.val)
return -ENOMEM;
 
-   stamac = wid.val;
-   ether_addr_copy(stamac, hif_sta_inactive->mac);
+   ether_addr_copy(wid.val, hif_sta_inactive->mac);
 
result = wilc_send_config_pkt(vif, SET_CFG, , 1,
  wilc_get_vif_idx(vif));
+   kfree(wid.val);
 
if (result) {
netdev_err(vif->ndev, "Failed to SET inactive time\n");
@@ -2225,6 +2224,7 @@ static int handle_remain_on_chan(struct wilc_vif *vif,
 
result = wilc_send_config_pkt(vif, SET_CFG, , 1,
  wilc_get_vif_idx(vif));
+   kfree(wid.val);
if (result != 0)
netdev_err(vif->ndev, "Failed to set remain on channel\n");
 
@@ -2269,6 +2269,7 @@ static int handle_register_frame(struct wilc_vif *vif,
 
result = wilc_send_config_pkt(vif, SET_CFG, , 1,
  wilc_get_vif_idx(vif));
+   kfree(wid.val);
if (result) {
netdev_err(vif->ndev, "Failed to frame register\n");
result = -EINVAL;
@@ -2300,6 +2301,7 @@ static u32 handle_listen_state_expired(struct wilc_vif 
*vif,
 
result = wilc_send_config_pkt(vif, SET_CFG, , 1,
  wilc_get_vif_idx(vif));
+   kfree(wid.val);
if (result != 0) {
netdev_err(vif->ndev, "Failed to set remain channel\n");
goto _done_;
-- 
2.7.4

[PATCH 2/9] staging: wilc1000: avoid 'NULL' pointer access in wilc_network_info_received()

[Ajay Singh]

Added 'NULL' check before accessing the allocated memory. Free up the
memory incase of failure to enqueue the command. Used kmemdup instead of
kmalloc & memcpy.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index a13998d..70c10bc 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -3453,12 +3453,15 @@ void wilc_network_info_received(struct wilc *wilc, u8 
*buffer, u32 length)
msg.vif = vif;
 
msg.body.net_info.len = length;
-   msg.body.net_info.buffer = kmalloc(length, GFP_KERNEL);
-   memcpy(msg.body.net_info.buffer, buffer, length);
+   msg.body.net_info.buffer = kmemdup(buffer, length, GFP_KERNEL);
+   if (!msg.body.net_info.buffer)
+   return;
 
result = wilc_enqueue_cmd();
-   if (result)
+   if (result) {
netdev_err(vif->ndev, "message parameters (%d)\n", result);
+   kfree(msg.body.net_info.buffer);
+   }
 }
 
 void wilc_gnrl_async_info_received(struct wilc *wilc, u8 *buffer, u32 length)
-- 
2.7.4

[PATCH 1/9] staging: wilc1000: remove unused global variables related to p2p

[Ajay Singh]

Cleanup patch to remove the unused global variables defined for p2p.

Signed-off-by: Ajay Singh 
---
 drivers/staging/wilc1000/host_interface.c | 59 ---
 1 file changed, 59 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 5082ede..a13998d 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -254,13 +254,6 @@ static u32 inactive_time;
 static u8 del_beacon;
 static u32 clients_count;
 
-static u8 *join_req;
-static u8 *info_element;
-static u8 mode_11i;
-static u8 auth_type;
-static u32 join_req_size;
-static u32 info_element_size;
-static struct wilc_vif *join_req_vif;
 #define REAL_JOIN_REQ 0
 #define FLUSHED_JOIN_REQ 1
 #define FLUSHED_BYTE_POS 79
@@ -995,39 +988,23 @@ static s32 handle_connect(struct wilc_vif *vif,
wid_list[wid_cnt].size = hif_drv->usr_conn_req.ies_len;
wid_cnt++;
 
-   if (memcmp("DIRECT-", conn_attr->ssid, 7)) {
-   info_element_size = hif_drv->usr_conn_req.ies_len;
-   info_element = kmalloc(info_element_size, GFP_KERNEL);
-   memcpy(info_element, hif_drv->usr_conn_req.ies,
-  info_element_size);
-   }
wid_list[wid_cnt].id = (u16)WID_11I_MODE;
wid_list[wid_cnt].type = WID_CHAR;
wid_list[wid_cnt].size = sizeof(char);
wid_list[wid_cnt].val = (s8 *)_drv->usr_conn_req.security;
wid_cnt++;
 
-   if (memcmp("DIRECT-", conn_attr->ssid, 7))
-   mode_11i = hif_drv->usr_conn_req.security;
-
wid_list[wid_cnt].id = (u16)WID_AUTH_TYPE;
wid_list[wid_cnt].type = WID_CHAR;
wid_list[wid_cnt].size = sizeof(char);
wid_list[wid_cnt].val = (s8 *)_drv->usr_conn_req.auth_type;
wid_cnt++;
 
-   if (memcmp("DIRECT-", conn_attr->ssid, 7))
-   auth_type = (u8)hif_drv->usr_conn_req.auth_type;
-
wid_list[wid_cnt].id = (u16)WID_JOIN_REQ_EXTENDED;
wid_list[wid_cnt].type = WID_STR;
wid_list[wid_cnt].size = 112;
wid_list[wid_cnt].val = kmalloc(wid_list[wid_cnt].size, GFP_KERNEL);
 
-   if (memcmp("DIRECT-", conn_attr->ssid, 7)) {
-   join_req_size = wid_list[wid_cnt].size;
-   join_req = kmalloc(join_req_size, GFP_KERNEL);
-   }
if (!wid_list[wid_cnt].val) {
result = -EFAULT;
goto error;
@@ -1120,11 +1097,6 @@ static s32 handle_connect(struct wilc_vif *vif,
cur_byte = wid_list[wid_cnt].val;
wid_cnt++;
 
-   if (memcmp("DIRECT-", conn_attr->ssid, 7)) {
-   memcpy(join_req, cur_byte, join_req_size);
-   join_req_vif = vif;
-   }
-
if (conn_attr->bssid)
memcpy(wilc_connected_ssid,
   conn_attr->bssid, ETH_ALEN);
@@ -1254,16 +1226,6 @@ static s32 handle_connect_timeout(struct wilc_vif *vif)
 
eth_zero_addr(wilc_connected_ssid);
 
-   if (join_req && join_req_vif == vif) {
-   kfree(join_req);
-   join_req = NULL;
-   }
-
-   if (info_element && join_req_vif == vif) {
-   kfree(info_element);
-   info_element = NULL;
-   }
-
return result;
 }
 
@@ -1519,17 +1481,6 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif 
*vif,
hif_drv->usr_conn_req.ies_len = 0;
kfree(hif_drv->usr_conn_req.ies);
hif_drv->usr_conn_req.ies = NULL;
-
-   if (join_req && join_req_vif == vif) {
-   kfree(join_req);
-   join_req = NULL;
-   }
-
-   if (info_element && join_req_vif == vif) {
-   kfree(info_element);
-   info_element = NULL;
-   }
-
hif_drv->hif_state = HOST_IF_IDLE;
scan_while_connected = false;
 
@@ -1866,16 +1817,6 @@ static void handle_disconnect(struct wilc_vif *vif)
kfree(conn_req->ies);
conn_req->ies = NULL;
 
-   if (join_req && join_req_vif == vif) {
-   kfree(join_req);
-   join_req = NULL;
-   }
-
-   if (info_element && join_req_vif == vif) {
-   kfree(info_element);
-   info_element = NULL;
-   }
-
 out:
 
complete(_drv->comp_test_disconn_block);
-- 
2.7.4

[PATCH 0/9] staging: wilc1000: fix memory leaks and checkpatch reported issues

[Ajay Singh]

This patch series contains changes to fix memory leaks, avoid NULL pointer
exceptions and checkpatch reported issue fixes.

Ajay Singh (9):
  staging: wilc1000: remove unused global variables related to p2p
  staging: wilc1000: avoid 'NULL' pointer access in
wilc_network_info_received()
  staging: wilc1000: free allocated memory in edit and add station
functions
  staging: wilc1000: free memory allocated in add wep key functions
  staging: wilc1000: free allocated memory after processing
wilc_send_config_pkt()
  staging: wilc1000: fix to free allocated memory in wilc_add_ptk()
  staging: wilc1000: free allocated memory in wilc_add_rx_gtk()
  staging: wilc1000: split handle_rcvd_gnrl_async_info() to avoid
leading tabs
  staging: wilc1000: free memory allocated for general info message from
firmware

 drivers/staging/wilc1000/host_interface.c | 421 +++---
 1 file changed, 204 insertions(+), 217 deletions(-)

-- 
2.7.4

Re: iwlwifi intermittent beacon capture in monitor mode?

[Tyler Gray]

Thanks for the reply.

I'm positive we're just in monitor mode.  I'm sure for a lot of
reasons, but I control the AP, so I'd see any connections in the
hostapd debug as well as in the pcaps if things were connecting to it.
We've been doing collection with Atheros devices for 5+ years, but
have recently been looking at the 7265.  It works great almost always,
but we've seen this quirk for some time now, and are trying to get to
the bottom of it.  This is as simple a test I could come up with to
show the problem, using just stock software.  Our ubuntu laptop does
not have network manager running, so the test is as easy as booting up
and:

rfkill unblock wifi
iw wlan0 set type monitor
ifconfig wlan0 up
iw wlan0 set channel 10
tcpdump -i wlan0 

To be clear, I'm not claiming I can set two devices up anywhere,
anytime, and run this test and see huge gaps in beacons, but we've
tested across multiple devices and multiple brands of devices with
7265 cards, and we have data collected in locations that are miles
apart that show the same behavior, so I'm confident this isn't just
one bad card or one incredibly unlucky setup that shows the problem.
I have determined spots where I'm far more likely to see the issue,
but I'll maintain that outside of a pathologically bad environment, I
should be able to see beacons from 6 feet away.

You mentioned the firmware can suppress beacons for powersaving.  Is
there any debug I could look at to see if that was happening?  I
posted some fw_rx_stats, would those counters be incremented before
that filtering would happen?  I just watched the counters during a
good period and a bad period.  In the "good" period I saw 15 CCK
packets/second, which is what I'd expect for my AP beaconing plus some
some probe responses and some beacons from the adjacent channel.
During the bad period the firmware saw 2 CCK packets in 7 seconds, and
none of the error counters for the bad period showed an additional 100
packets lost for any reason.  The two periods had fairly similar
plcp_err stats.

7 good seconds:  (beacons coming in)
ina_cnt: +152
fina_cnt: +152
plcp_err: +44
crc32_err: +3

7 bad seconds:  (No beacons coming in, basically no traffic)
ina_cnt:  +56
fina_cnt: +56
plcp_err: +54
crc32_err: +0

Any theories, other than I'm associating with the AP, as to why
changing the channel would make the beacons return for a couple of
seconds?  That log I posted was terrible to read (sorry about that)
but essentially it shows beacons totally stopped for 20 seconds.  As
soon as I change channels and back, I get around 2 seconds worth of
beacons before it freezes again, and I can do that over and over.

As a side note, if I have a device connect to the AP and run iperf to
generate data, I'll capture an average of 99% of the data packets, yet
I'll often see 0 beacons while the transfer is happening.  So it's not
that I can't receive packets at all, and capturing those data packets
should be a far harder task, but it seems beacons get dropped in a
variety of cases and I can't determine why.

Are there any known conflicts between the bluetooth and the wifi?  Is
there an easy answer to the best (lowest level) way to disable
bluetooth if so?

Thanks,
Tyler

On Fri, Mar 23, 2018 at 4:17 AM, Johannes Berg
 wrote:
> Hi,
>
> From a completely different angle than what James just said, are you
> sure you're using the 7265 NIC for *only* monitor mode? This behaviour
> would also be more or less consistent with the 7265 NIC being connected
> to the AP that you're monitoring the beacons, since it would then
> suppress beacon RX for powersaving purposes.
>
> johannes

Re: [PATCH 10/10] rsi: drop RX broadcast/multicast packets with invalid PN

[Amitkumar Karwar]

On Wed, Mar 21, 2018 at 4:25 AM, Johannes Berg
 wrote:
> On Mon, 2018-03-05 at 20:07 +0530, Amitkumar Karwar wrote:
>> From: Siva Rebbagondla 
>>
>> This patch adds a check to drop received broadcast/multicast frames
>> if
>> PN is invalid (i.e. not greater than last PN). bc_mc_pn
>> variable added for each interface
>>
> Can you say why you do this rather than letting mac80211 do it?

Thanks for your comment.
I wasn't aware that mac80211 can do this even for decrypted Rx
packets. Only thing is we need to avoid IV stripping. I will create a
patch for it.

Regards,
Amitkumar

Re: [PATCH 01/10] rsi: add support for hardware scan offload

[Amitkumar Karwar]

On Wed, Mar 21, 2018 at 4:02 AM, Johannes Berg
 wrote:
> On Thu, 2018-03-15 at 14:57 +0530, Amitkumar Karwar wrote:
>>
>> > What I don't like here is that you are duplicating functionality
>> > already
>> > existing in mac80211 and I hope there is a better way to solve the
>> > problem. Just as a a crazy idea what if the driver returns
>> > -EOPNOTSUPP
>> > when hardware scan is not possible and mac80211 falls back to
>> > software
>> > scan? But of course this depends on what Johannes thinks.
>>
>> Currently mac80211 offloads scan to driver if "ops->hw_scan" is
>> implemented. Otherwise falls back to software scan.
>> I can see below vendors have already implemented hw_scan with their
>> own scan state machine. This patch does the same thing.
>> Let me know if I missed anything here.
>
> I think the argument is that at least it looks like you're implementing
> the timing etc. in software in the driver again, which others don't do,
> they do it in firmware. Which is just software again, but we don't see
> it ;-)

Understood. Timing logic is either is hardware or mac80211 for others.

> But maybe that's not really true at all? At least in one case it seems
> you just kick off something called "bgscan".

Yes. We have different scan implementations for device is connected
and non-connected cases. In connected case, firmware will take care of
timings when driver configures bgscan parameters due to power save and
coex restrictions. In non-connected state, driver is taking care of
it.
I found hardware scan in mac80211 more suitable for our device.

Regards,
Amitkumar Karwar

Re: [QUESTION] Mainline support for B43_PHY_AC wifi cards

[Juri Lelli]

Hi,

thanks a lot for your reply!

On 23/03/18 14:43, Rafał Miłecki wrote:
> Hi,
> 
> On 23 March 2018 at 10:47, Juri Lelli  wrote:
> > I've got a Dell XPS 13 9343/0TM99H (BIOS A15 01/23/2018) mounting a
> > BCM4352 802.11ac (rev 03) wireless card and so far I've been using it on
> > Fedora with broadcom-wl package (which I believe installs Broadcom's STA
> > driver?). It works good apart from occasional hiccups after suspend.
> >
> > I'd like to get rid of that dependency (you can understand that it's
> > particularly annoying when testing mainline kernels), but I found out
> > that support for my card is BROKEN in mainline [1]. Just to see what
> > happens, I forcibly enabled it witnessing that it indeed crashes like
> > below as Kconfig warns. :)
> >
> >  bcma: bus0: Found chip with id 0x4352, rev 0x03 and package 0x00
> >  bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x2B, 
> > class 0x0)
> >  bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x2A, 
> > class 0x0)
> >  bcma: bus0: Core 2 found: ARM CR4 (manuf 0x4BF, id 0x83E, rev 0x02, class 
> > 0x0)
> >  bcma: bus0: Core 3 found: PCIe Gen2 (manuf 0x4BF, id 0x83C, rev 0x01, 
> > class 0x0)
> >  bcma: bus0: Core 4 found: USB 2.0 Device (manuf 0x4BF, id 0x81A, rev 0x11, 
> > class 0x0)
> >  bcma: Unsupported SPROM revision: 11
> >  bcma: bus0: Invalid SPROM read from the PCIe card, trying to use fallback 
> > SPROM
> >  bcma: bus0: Using fallback SPROM failed (err -2)
> >  bcma: bus0: No SPROM available
> >  bcma: bus0: Bus registered
> >  b43-phy0: Broadcom 4352 WLAN found (core revision 42)
> >  b43-phy0: Found PHY: Analog 12, Type 11 (AC), Revision 1
> >  b43-phy0: Found Radio: Manuf 0x17F, ID 0x2069, Revision 4, Version 0
> >  BUG: unable to handle kernel NULL pointer dereference at 
> 
> This isn't really useful without a full backtrace.

Sure. I cut it here because I didn't expect people to debug what is
already known to be broken (but still it seemed to carry useful
information about the hw). :)

> > So, question: is replacing my card the only way I can get rid of this
> > downstream dependency? :(
> 
> It's definitely the cheapest way. Getting AC PHY into anything usable
> (proper setup that will allow Tx & Rx anything) would probably take
> weeks or months of development. I'm not even going to estimate cost of
> adding support for 802.11n and 802.11ac features. I was the last
> person actively working on b43, right now I spend my free time on
> other hobby projects. Few people were planning to help but it seems it
> never worked out for them.

I see. Just wondering why even if Broadcom's STA solution seems to work
fine, it is not mainline. Maybe a maintenance problem? But Fedora ships
with very recent kernels, so I'd expect the driver to work with mainline
(I tried compiling that against mainline, but I got errors that I didn't
spend time figuring out how to fix).

Do you know what's the deal w.r.t. the STA driver?

Best,

- Juri

Re: [PATCH] ath10k: Implement get_expected_throughput callback

[akolli]

On 2018-03-23 19:14, Johannes Berg wrote:

On Fri, 2018-03-23 at 19:11 +0530, ako...@codeaurora.org wrote:


> > +
> > +   sinfo->expected_throughput =
> > +
> > ewma_sta_txrate_read(>ave_sta_txrate);
> > +   sinfo->filled |=
> > BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
> > +}



Yes. This looks redundant, I will remove this line,
  sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);


You don't need any of the changes here in ath10k_sta_statistics().


Hi Jaohannes,

Yes. I removed this in ath10k driver and sent a v2 patch.

Thanks,
Anil.

[PATCH v2] ath10k: Implement get_expected_throughput callback

[Anilkumar Kolli]

Enable support for 'drv_get_expected_throughput' callback.
Export expected throughput if available to cfg80211/nl80211.

Signed-off-by: Anilkumar Kolli 
Signed-off-by: Tamizh chelvam 
---
v2:
  - update the avg for all the transmitted frames(Sven)
  - remove the unnecessary NL80211_STA_INFO_EXPECTED_THROUGHPUT update(Sven)

 drivers/net/wireless/ath/ath10k/core.h   |5 +
 drivers/net/wireless/ath/ath10k/htt_rx.c |4 
 drivers/net/wireless/ath/ath10k/mac.c|9 +
 3 files changed, 18 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index fe6b30356d3b..8e10f7d83a79 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2005-2011 Atheros Communications Inc.
  * Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -37,6 +38,7 @@
 #include "thermal.h"
 #include "wow.h"
 #include "swap.h"
+#include 
 
 #define MS(_v, _f) (((_v) & _f##_MASK) >> _f##_LSB)
 #define SM(_v, _f) (((_v) << _f##_LSB) & _f##_MASK)
@@ -354,6 +356,8 @@ struct ath10k_txq {
unsigned long num_push_allowed;
 };
 
+DECLARE_EWMA(sta_txrate, 4, 16)
+
 struct ath10k_sta {
struct ath10k_vif *arvif;
 
@@ -367,6 +371,7 @@ struct ath10k_sta {
 
struct work_struct update_wk;
u64 rx_duration;
+   struct ewma_sta_txrate ave_sta_txrate;
 
 #ifdef CONFIG_MAC80211_DEBUGFS
/* protected by conf_mutex */
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 6d96f9560950..9fd8b22552c6 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2449,6 +2449,7 @@ static inline bool is_valid_legacy_rate(u8 rate)
struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
u8 rate = 0, sgi;
struct rate_info txrate;
+   u32 tx_bitrate;
 
lockdep_assert_held(>data_lock);
 
@@ -2500,6 +2501,9 @@ static inline bool is_valid_legacy_rate(u8 rate)
 
arsta->txrate.nss = txrate.nss;
arsta->txrate.bw = txrate.bw + RATE_INFO_BW_20;
+
+   tx_bitrate = cfg80211_calculate_bitrate(>txrate);
+   ewma_sta_txrate_add(>ave_sta_txrate, tx_bitrate);
 }
 
 static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 7e02ca02b28e..33e790cf5c42 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7688,6 +7688,14 @@ static void ath10k_sta_statistics(struct ieee80211_hw 
*hw,
sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_BITRATE;
 }
 
+static u32 ath10k_get_expected_throughput(struct ieee80211_hw *hw,
+ struct ieee80211_sta *sta)
+{
+   struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+
+   return ewma_sta_txrate_read(>ave_sta_txrate);
+}
+
 static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_mac_op_tx,
.wake_tx_queue  = ath10k_mac_op_wake_tx_queue,
@@ -7730,6 +7738,7 @@ static void ath10k_sta_statistics(struct ieee80211_hw *hw,
.switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
.sta_pre_rcu_remove = ath10k_mac_op_sta_pre_rcu_remove,
.sta_statistics = ath10k_sta_statistics,
+   .get_expected_throughput= ath10k_get_expected_throughput,
 
CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
 
-- 
1.7.9.5

Re: [PATCH] ath10k: Implement get_expected_throughput callback

[Johannes Berg]

On Fri, 2018-03-23 at 19:11 +0530, ako...@codeaurora.org wrote:
> 
> > > +
> > > +   sinfo->expected_throughput =
> > > +   
> > > ewma_sta_txrate_read(>ave_sta_txrate);
> > > +   sinfo->filled |=
> > > BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
> > > +}

> Yes. This looks redundant, I will remove this line,
>   sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);

You don't need any of the changes here in ath10k_sta_statistics().

johannes

Re: [QUESTION] Mainline support for B43_PHY_AC wifi cards

[Rafał Miłecki]

Hi,

On 23 March 2018 at 10:47, Juri Lelli  wrote:
> I've got a Dell XPS 13 9343/0TM99H (BIOS A15 01/23/2018) mounting a
> BCM4352 802.11ac (rev 03) wireless card and so far I've been using it on
> Fedora with broadcom-wl package (which I believe installs Broadcom's STA
> driver?). It works good apart from occasional hiccups after suspend.
>
> I'd like to get rid of that dependency (you can understand that it's
> particularly annoying when testing mainline kernels), but I found out
> that support for my card is BROKEN in mainline [1]. Just to see what
> happens, I forcibly enabled it witnessing that it indeed crashes like
> below as Kconfig warns. :)
>
>  bcma: bus0: Found chip with id 0x4352, rev 0x03 and package 0x00
>  bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x2B, class 
> 0x0)
>  bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x2A, 
> class 0x0)
>  bcma: bus0: Core 2 found: ARM CR4 (manuf 0x4BF, id 0x83E, rev 0x02, class 
> 0x0)
>  bcma: bus0: Core 3 found: PCIe Gen2 (manuf 0x4BF, id 0x83C, rev 0x01, class 
> 0x0)
>  bcma: bus0: Core 4 found: USB 2.0 Device (manuf 0x4BF, id 0x81A, rev 0x11, 
> class 0x0)
>  bcma: Unsupported SPROM revision: 11
>  bcma: bus0: Invalid SPROM read from the PCIe card, trying to use fallback 
> SPROM
>  bcma: bus0: Using fallback SPROM failed (err -2)
>  bcma: bus0: No SPROM available
>  bcma: bus0: Bus registered
>  b43-phy0: Broadcom 4352 WLAN found (core revision 42)
>  b43-phy0: Found PHY: Analog 12, Type 11 (AC), Revision 1
>  b43-phy0: Found Radio: Manuf 0x17F, ID 0x2069, Revision 4, Version 0
>  BUG: unable to handle kernel NULL pointer dereference at 

This isn't really useful without a full backtrace.


> So, question: is replacing my card the only way I can get rid of this
> downstream dependency? :(

It's definitely the cheapest way. Getting AC PHY into anything usable
(proper setup that will allow Tx & Rx anything) would probably take
weeks or months of development. I'm not even going to estimate cost of
adding support for 802.11n and 802.11ac features. I was the last
person actively working on b43, right now I spend my free time on
other hobby projects. Few people were planning to help but it seems it
never worked out for them.

Re: [PATCH] ath10k: Implement get_expected_throughput callback

[akolli]

Hi Sven,

Thanks for the review.

On 2018-03-23 13:39, Sven Eckelmann wrote:

On Freitag, 23. März 2018 13:07:00 CET Anilkumar Kolli wrote:
[...]

+static u32 ath10k_get_expected_throughput(struct ieee80211_hw *hw,
+ struct ieee80211_sta *sta)
+{
+   struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+   u32 tx_bitrate;
+
+   tx_bitrate = cfg80211_calculate_bitrate(>txrate);
+   ewma_sta_txrate_add(>ave_sta_txrate, tx_bitrate);
+
+   return ewma_sta_txrate_read(>ave_sta_txrate);
 }


Antonio and Felix, please correct me when this statement is incorrect.

The expected_throughput as initially implemented for minstrel(_ht) is 
not
about the raw physical bitrate but about the throughput which is 
expected for

things running on top of the wifi link. See
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cca674d47e59665630f3005291b61bb883015fc5
for more details

when I interpret your change correctly then your it doesn't get the
information about packet loss or aggregation and doesn't do anything 
convert
from raw physical rate to something the user could get see. It will 
just
overestimate the throughput for ath10k links and thus give wrong 
information
to routing algorithms. This could for example cause them to prefer 
links over

ath10k based hw when mt76 would actually provide a significant better
throughput.

Beside that - why is the ave_sta_txrate only filled when with new 
information

when someone requests the current expected_throughput via
get_expected_throughput. I would have expected that it is filled 
everytime you

get new information about the current rate from the firmware
(ath10k_sta_statistics).


Yes. ideally it should be doing the rate avg. of all the sent packets.

@@ -7686,6 +7686,22 @@ static void ath10k_sta_statistics(struct 
ieee80211_hw *hw,

}
sinfo->txrate.flags = arsta->txrate.flags;
sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_BITRATE;
+
+   sinfo->expected_throughput =
+   
ewma_sta_txrate_read(>ave_sta_txrate);

+   sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
+}


This brings me directly to the next point. Why are you changing these 
values
here? Isn't sta_set_sinfo is expected to do that? This is at least what 
we

expect how it works when we call cfg80211_get_station() in batman-adv.



Yes. This looks redundant, I will remove this line,
 sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);

I will make these changes and send v2.

Thanks,
Anil.

Re: [PATCHv4 1/3] cfg80211: enable setting cqm rssi config for AP mode

[Johannes Berg]

On Sun, 2018-02-25 at 13:19 +0530, Tamizh chelvam wrote:
> From: Tamizh chelvam 
> 
> This patch extend cqm rssi config and notifier feature to AP mode
> by introducing NL80211_EXT_FEATURE_AP_STA_CQM_RSSI_CONFIG ext
> feature bit. And this patch introduces NL80211_MCGRP_AP_STA_CQM
> for notifying station's low/high rssi event to userspace application.

So, I guess I can sort of see how this could be useful.

However, is it really best in this current form?

For example, it seems trivial to imagine that one might want to have
different thresholds for different stations, and nothing in the current
implementation would prevent that, just the CQM API isn't very suited
to that.

There was also an extension to CQM to support different levels - not
sure where that ended up, but we should take that into account I guess.


Overall, I'm still not really convinced CQM is the right approach here.

One thing I could even imagine would be to just not have this
capability at all, but build it into a little BPF program you install.
I had - and still want to revive - the code to insert a "programming
point" into the wireless stack, and one could then easily build a hash
table of TAs vs. signal strength in BPF code.

We may not want to go that far, but I think the current approach is too
short-sighted. This might solve a specific problem today, but I don't
think it'll serve us well into the future if we don't make it more
flexible.

johannes

Re: [PATCHv4 3/3] mac80211: implement cqm rssi check using rx data signal

[Johannes Berg]

> +/*
> + * How many frames need to have been used in average station's
> + * signal strength before checking against the threshold
> + */
> +#define IEEE80211_STA_SIGNAL_AVE_MIN_COUNT   4

This seems OK - you want something to start up from?

However, I don't think we do that in "normal" CQM, and building
different behaviour here seems a bit odd.

> + if (sig < thold && last_event == 0) {
> + sta->last_cqm_event_signal = sig;
> + cfg80211_ap_sta_cqm_rssi_notify(
> + rx->sdata->dev, sta->addr,
> + NL80211_CQM_RSSI_THRESHOLD_EVENT_LOW
> ,
> + sig, GFP_ATOMIC);
> + sta->count_rx_signal = 0;

In particular, resetting it all the time seems even stranger, since
then you can only react at a granularity of these 4 frames. EWMA
catches fluctuations already, so I don't think you should do it this
way.

johannes

Re: [PATCHv4 2/3] mac80211: enable setting cqm rssi config for AP mode

[Johannes Berg]

>  
> +static void ieee80211_update_rssi_config(struct
> ieee80211_sub_if_data *sdata)
> +{
> + if (!(sdata->vif.driver_flags &
> IEEE80211_VIF_SUPPORTS_CQM_RSSI))
> + return;
> +
> + /* tell the driver upon association, unless already
> associated */
> + if (sdata->vif.type == NL80211_IFTYPE_STATION &&
> + !sdata->u.mgd.associated)
> + return;
> +
> + /* if AP, always tell the driver by checking beacon status
> */
> + if (!sdata->vif.bss_conf.enable_beacon ||
> + !wiphy_ext_feature_isset(sdata->local->hw.wiphy,
> + NL80211_EXT_FEATURE_AP_STA_CQM_RSSI_
> CONFIG))
> + return;

This probably should check for AP mode as well - not sure we use
enable_beacon for e.g. IBSS but I guess we could.

johannes

Re: AP6335 with mainline kernel

[Vanessa Maegima]

Hi Arend,

On Sex, 2018-03-23 at 10:28 +0100, Arend van Spriel wrote:
> On 3/21/2018 4:38 PM, Vanessa Maegima wrote:
> > 
> > Hi Arend,
> > 
> > On Sex, 2018-01-19 at 10:02 +0100, Arend van Spriel wrote:
> > > 
> > > On 1/18/2018 12:47 PM, Vanessa Maegima wrote:
> > > > 
> > > > 
> > > > Hi Arend,
> > > > 
> > > > On Ter, 2018-01-16 at 21:21 +0100, Arend van Spriel wrote:
> > > > > 
> > > > > 
> > > > > On 1/15/2018 9:08 PM, Fabio Estevam wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi Arend,
> > > > > > 
> > > > > > On Tue, Dec 5, 2017 at 12:58 PM, Vanessa Maegima
> > > > > >  wrote:
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Hi Arend,
> > > > > > > 
> > > > > > > Sorry for this!
> > > > > > > 
> > > > > > > I updated the folder on https://emea01.safelinks.protecti
> > > > > > > on.outlook.com/?url=https%3A%2F%2Femea01.safelinks.protec
> > > > > > > tion.o=02%7C01%7Cvanessa.maegima%40nxp.com%7Cfa47ba5
> > > > > > > 219a940c482bc08d590a0808a%7C686ea1d3bc2b4c6fa92cd99c5c301
> > > > > > > 635%7C0%7C0%7C636573941383014734=Xszjp7jHoXyhFWUEl6
> > > > > > > LN4mcBhOgMRCjurMsWmE%2B5gZU%3D=0
> > > > > > > utlook.com/?url=https%3A%2F%2Femea01.safelinks.protection
> > > > > > > .out
> > > > > > > lo=02%7C01%7Cvanessa.maegima%40nxp.com%7C39040229475
> > > > > > > 441d
> > > > > > > 7b5aa08d55f1b6cd3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > > > > > > 7C1%
> > > > > > > 7C636519493755298348=Zws4AElm4La96Q4pjK152nH2lP6v4m
> > > > > > > PJJN
> > > > > > > xSGz7TLBA%3D=0
> > > > > > > ok.com/?url=https%3A%2F%2Fdrive.google.com%2Fdrive%2Ffold
> > > > > > > ers%
> > > > > > > 2F1f
> > > > > > > osahjL=02%7C01%7Cvanessa.maegima%40nxp.com%7Cf07cd1a
> > > > > > > 6ffb
> > > > > > > 34c0
> > > > > > > 961f608d55d1eb901%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> > > > > > > 7C0%
> > > > > > > 7C63
> > > > > > > 6517308901643244=6JAqSN%2BVPJ%2FCF7cbnBjm8geMKWydWk
> > > > > > > G9Jc
> > > > > > > UhGB
> > > > > > > Pj644%3D=0
> > > > > > > N1KI5NKS59_aPZdHLpENPFHtK
> > > > > > > 
> > > > > > > Thanks!
> > > > > > Any ideas, please?
> > > > > Well, the dumps confirm a crash early in the firmware boot.
> > > > > However,
> > > > > I
> > > > > could not obtain more information from it. To capture the
> > > > > failure
> > > > > I
> > > > > need
> > > > > to rework some firmware functionality which is not trivial
> > > > > and I
> > > > > can
> > > > > not
> > > > > claim time for it right now.
> > > > > 
> > > > > Regards,
> > > > > Arend
> > > > > 
> > > > Thanks for all your investigation here!
> > > > 
> > > > I just want to report one more thing that I noticed from my
> > > > tests.
> > > > 
> > > > I have tried to use an html file that I downloaded using wget
> > > > as
> > > > the
> > > > nvram file (https://emea01.safelinks.protection.outlook.com/?ur
> > > > l=ht
> > > > tps%3A%2F%2Fgithub.com%2FOpenELEC%2Fwlan-
> > > > firmware%2Fblob%2Fmaster%2Ffirmw=02%7C01%7Cvanessa.maegima
> > > > %40n
> > > > xp.com%7C39040229475441d7b5aa08d55f1b6cd3%7C686ea1d3bc2b4c6fa92
> > > > cd99
> > > > c5c301635%7C0%7C1%7C636519493755298348=EZFVV3qbStjH9Eqe6u
> > > > VVXJ
> > > > f7LmQlMLIURXHaQIMIpms%3D=0
> > > > are/brcm/nvram_ap6335.txt) and the wifi seems to work. I have
> > > > not
> > > > noticed the wrong format file until testing it.
> > > Interesting. In brcmfmac the file is parsed before sending it to
> > > the
> > > firmware so I am wondering what is effectively send to the
> > > device.
> > > 
> > > Can you dump the nvram that is sent to the device. Just add
> > > hexdump
> > > call
> > > of nvram in brcmf_fw_request_nvram_done() in firmware.c just
> > > before
> > > fwctx->done() is called.
> > > 
> > > Regards,
> > > Arend
> > Sorry for my delayed response, but I could not get the hexdump from
> > the
> > nvram. I have tried several hexdump functions I found on kernel and
> > on
> > the brcmfmac driver but none of them printed any output.
> > 
> > Is there any CONFIG I need to enable to get those working?
> CONFIG_BRCMDBG should be enabled. Or just add '#define DEBUG' in 
> firmware.c before the include statements.
> 
> Regards,
> Arend

Thanks, this worked!

Here's the hexdump: http://code.bulix.org/trv3o7-306254

Best Regards,
Vanessa

Re: [PATCH 01/13] ath10k: platform driver for WCN3990 SNOC WLAN module

[govinds]

On 2018-03-10 14:41, Kalle Valo wrote:

 writes:


>> Kbuild bot found an odd problem with this patch:
>>
>>  include/linux/dynamic_debug.h:77:14: error: 'KBUILD_MODNAME'
>>  undeclared (first use in this function); did you mean
'KBUILD_BASENAME'?
>>
>> Full report:
>>
>>
http://lists.infradead.org/pipermail/ath10k/2018-February/010907.html
>>
>> Any ideas? Is this is some unrelated issue or what? This patch is not
>> even touching hif.h or ce.c.
>
> I didn't encountered this issue as in my defconfig only
> CONFIG_ATH10K_SNOC was defined. This problem is coming when we define
> CONFIG_ATH10K_SNOC and CONFIG_ATH10K_PCI simultaneously in defconfig
> and this is known issue when multiple modules share objects(in this
> case ce.o). I saw similar reported problem and found
> https://patchwork.kernel.org/patch/10060825/.
>
> After picking the below change issue is not seen.

Let's ask the kbuild maintainer. Masahiro, any chances of getting 
this

patch applied anytime soon:

kbuild: define KBUILD_MODNAME even if multiple modules share objects

https://patchwork.kernel.org/patch/10060825/

In ath10k we would need it as otherwise we are not able to link ce.o
both to ath10k_pci.ko and ath10k_snoc.ko. What do you think?

Full discussion and the ath10k patch here:

https://patchwork.kernel.org/patch/10220657/



I plan to submit v2, but even if the undefined KBUILD_MODNAME is 
fixed,

I expect another problem from this patch.

If both CONFIG_ATH10K_PCI and CONFIG_ATH10_SNOC are 'y'
two instances of ce.o would be linked into vmliux,
then causes multiple definition error.


Oh, I didn't realise this. Thanks for pointing it out. Govind is 
looking

at other ways to fix this.


https://patchwork.kernel.org/patch/10298659/ is raised to address this 
problem.


Thanks,
Govind

[QUESTION] Mainline support for B43_PHY_AC wifi cards

[Juri Lelli]

Hi,

I've got a Dell XPS 13 9343/0TM99H (BIOS A15 01/23/2018) mounting a
BCM4352 802.11ac (rev 03) wireless card and so far I've been using it on
Fedora with broadcom-wl package (which I believe installs Broadcom's STA
driver?). It works good apart from occasional hiccups after suspend.

I'd like to get rid of that dependency (you can understand that it's
particularly annoying when testing mainline kernels), but I found out
that support for my card is BROKEN in mainline [1]. Just to see what
happens, I forcibly enabled it witnessing that it indeed crashes like
below as Kconfig warns. :)

 bcma: bus0: Found chip with id 0x4352, rev 0x03 and package 0x00
 bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x2B, class 
0x0)
 bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x2A, class 
0x0)
 bcma: bus0: Core 2 found: ARM CR4 (manuf 0x4BF, id 0x83E, rev 0x02, class 0x0)
 bcma: bus0: Core 3 found: PCIe Gen2 (manuf 0x4BF, id 0x83C, rev 0x01, class 
0x0)
 bcma: bus0: Core 4 found: USB 2.0 Device (manuf 0x4BF, id 0x81A, rev 0x11, 
class 0x0)
 bcma: Unsupported SPROM revision: 11
 bcma: bus0: Invalid SPROM read from the PCIe card, trying to use fallback SPROM
 bcma: bus0: Using fallback SPROM failed (err -2)
 bcma: bus0: No SPROM available
 bcma: bus0: Bus registered
 b43-phy0: Broadcom 4352 WLAN found (core revision 42)
 b43-phy0: Found PHY: Analog 12, Type 11 (AC), Revision 1
 b43-phy0: Found Radio: Manuf 0x17F, ID 0x2069, Revision 4, Version 0
 BUG: unable to handle kernel NULL pointer dereference at 

So, question: is replacing my card the only way I can get rid of this
downstream dependency? :(

Thanks a lot.

Best,

- Juri

[1] 
https://elixir.bootlin.com/linux/v4.16-rc6/source/drivers/net/wireless/broadcom/b43/Kconfig#L151

Re: [PATCH] brcmfmac: add support for BCM4366E chipset

[Arend van Spriel]

On 3/22/2018 4:58 PM, Dan Haab wrote:

From: Dan Haab 

BCM4366E is a wireless chipset with a BCM43664 ChipCommon. It's
supported by the same firmware as 4366c0.


Thanks, Dan

I have a patch for that queued up already. So let me push that instead.

Regards,
Arend

Re: AP6335 with mainline kernel

[Arend van Spriel]

On 3/21/2018 4:38 PM, Vanessa Maegima wrote:

Hi Arend,

On Sex, 2018-01-19 at 10:02 +0100, Arend van Spriel wrote:

On 1/18/2018 12:47 PM, Vanessa Maegima wrote:


Hi Arend,

On Ter, 2018-01-16 at 21:21 +0100, Arend van Spriel wrote:


On 1/15/2018 9:08 PM, Fabio Estevam wrote:



Hi Arend,

On Tue, Dec 5, 2017 at 12:58 PM, Vanessa Maegima
 wrote:




Hi Arend,

Sorry for this!

I updated the folder on https://emea01.safelinks.protection.o
utlook.com/?url=https%3A%2F%2Femea01.safelinks.protection.out
lo=02%7C01%7Cvanessa.maegima%40nxp.com%7C39040229475441d
7b5aa08d55f1b6cd3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%
7C636519493755298348=Zws4AElm4La96Q4pjK152nH2lP6v4mPJJN
xSGz7TLBA%3D=0
ok.com/?url=https%3A%2F%2Fdrive.google.com%2Fdrive%2Ffolders%
2F1f
osahjL=02%7C01%7Cvanessa.maegima%40nxp.com%7Cf07cd1a6ffb
34c0
961f608d55d1eb901%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
7C63
6517308901643244=6JAqSN%2BVPJ%2FCF7cbnBjm8geMKWydWkG9Jc
UhGB
Pj644%3D=0
N1KI5NKS59_aPZdHLpENPFHtK

Thanks!

Any ideas, please?

Well, the dumps confirm a crash early in the firmware boot.
However,
I
could not obtain more information from it. To capture the failure
I
need
to rework some firmware functionality which is not trivial and I
can
not
claim time for it right now.

Regards,
Arend


Thanks for all your investigation here!

I just want to report one more thing that I noticed from my tests.

I have tried to use an html file that I downloaded using wget as
the
nvram file (https://emea01.safelinks.protection.outlook.com/?url=ht
tps%3A%2F%2Fgithub.com%2FOpenELEC%2Fwlan-
firmware%2Fblob%2Fmaster%2Ffirmw=02%7C01%7Cvanessa.maegima%40n
xp.com%7C39040229475441d7b5aa08d55f1b6cd3%7C686ea1d3bc2b4c6fa92cd99
c5c301635%7C0%7C1%7C636519493755298348=EZFVV3qbStjH9Eqe6uVVXJ
f7LmQlMLIURXHaQIMIpms%3D=0
are/brcm/nvram_ap6335.txt) and the wifi seems to work. I have not
noticed the wrong format file until testing it.

Interesting. In brcmfmac the file is parsed before sending it to the
firmware so I am wondering what is effectively send to the device.

Can you dump the nvram that is sent to the device. Just add hexdump
call
of nvram in brcmf_fw_request_nvram_done() in firmware.c just before
fwctx->done() is called.

Regards,
Arend


Sorry for my delayed response, but I could not get the hexdump from the
nvram. I have tried several hexdump functions I found on kernel and on
the brcmfmac driver but none of them printed any output.

Is there any CONFIG I need to enable to get those working?


CONFIG_BRCMDBG should be enabled. Or just add '#define DEBUG' in 
firmware.c before the include statements.


Regards,
Arend

Re: iwlwifi intermittent beacon capture in monitor mode?

[Johannes Berg]

Hi,

>From a completely different angle than what James just said, are you
sure you're using the 7265 NIC for *only* monitor mode? This behaviour
would also be more or less consistent with the 7265 NIC being connected
to the AP that you're monitoring the beacons, since it would then
suppress beacon RX for powersaving purposes.

johannes

Re: [PATCH] ath10k: Implement get_expected_throughput callback

[Sven Eckelmann]

On Freitag, 23. März 2018 13:07:00 CET Anilkumar Kolli wrote:
[...]
> +static u32 ath10k_get_expected_throughput(struct ieee80211_hw *hw,
> + struct ieee80211_sta *sta)
> +{
> +   struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
> +   u32 tx_bitrate;
> +
> +   tx_bitrate = cfg80211_calculate_bitrate(>txrate);
> +   ewma_sta_txrate_add(>ave_sta_txrate, tx_bitrate);
> +
> +   return ewma_sta_txrate_read(>ave_sta_txrate);
>  }

Antonio and Felix, please correct me when this statement is incorrect.

The expected_throughput as initially implemented for minstrel(_ht) is not 
about the raw physical bitrate but about the throughput which is expected for 
things running on top of the wifi link. See 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cca674d47e59665630f3005291b61bb883015fc5
 
for more details

when I interpret your change correctly then your it doesn't get the 
information about packet loss or aggregation and doesn't do anything convert
from raw physical rate to something the user could get see. It will just 
overestimate the throughput for ath10k links and thus give wrong information 
to routing algorithms. This could for example cause them to prefer links over 
ath10k based hw when mt76 would actually provide a significant better 
throughput.

Beside that - why is the ave_sta_txrate only filled when with new information 
when someone requests the current expected_throughput via 
get_expected_throughput. I would have expected that it is filled everytime you 
get new information about the current rate from the firmware 
(ath10k_sta_statistics).

> @@ -7686,6 +7686,22 @@ static void ath10k_sta_statistics(struct ieee80211_hw 
> *hw,
> }
> sinfo->txrate.flags = arsta->txrate.flags;
> sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_BITRATE;
> +
> +   sinfo->expected_throughput =
> +   ewma_sta_txrate_read(>ave_sta_txrate);
> +   sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
> +}

This brings me directly to the next point. Why are you changing these values 
here? Isn't sta_set_sinfo is expected to do that? This is at least what we
expect how it works when we call cfg80211_get_station() in batman-adv.

Kind regards,
Sven

signature.asc
Description: This is a digitally signed message part.

Re: [RFC v5 0/9] EAPoL over NL80211

[Johannes Berg]

Hi,

> Okay, that makes things easier.  However, it does bring up a
> question. Should we be symmetric and remove AP_VLAN as a valid target
> of control  port frames?  E.g. drop NL80211_IFTYPE_AP_VLAN case in
> patch 2 of the  series.  In effect we'd require all control port
> frame traffic to go  over the master interface.

Yeah, I think that'd make sense.

> I'm the one confused now.  You wanted me to add IFTYPE_IBSS in 
> nl80211_tx_control_port in your earlier feedback :)

Hah. My memory is like a sieve...

> Let me try to restate what I said earlier in a different way and see
> if it makes things a bit clearer:
> 
> So in patch 9, we set sdata->control_port_over_nl80211 based on 
> parameters passed into start_ap or mgd_assoc.  The 
> control_port_over_nl80211 flag is passed in cfg80211_crypto_settings 
> structure that is part of the relevant parameters structure.  If 
> sdata->control_port_over_nl80211 is true, then we actually redirect
> the control port frames to nl80211.

Right.

> So my question is, if we want to support IBSS/MESH, should we:
> 1. add the whole cfg80211_crypto_settings to the IBSS/MESH
> parameters,
> 2. add the control_port_over_nl80211 flag directly to IBSS/MESH
> parameters
> 3. Pass the flag some other way?
> 4. Or drop IBSS/MESH from patch 2 (nl80211_tx_control_port)
> completely?

I'd say 2 or 4. Having all the crypto settings would be confusing,
since they aren't (and possibly cannot) be used.

4 is a bit annoying - not that I remember - because it eventually means
that when we do want to support it in IBSS/MESH, we'd have to add
another flag indicating that now it's supported, etc. But I think we
can live with that too, if it's too complex to add this for real.

johannes

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

[Mathias Kresin]

07.03.2018 13:29, Stanislaw Gruszka:

I forgot to attach the patches, do it now.

On Wed, Mar 07, 2018 at 01:27:01PM +0100, Stanislaw Gruszka wrote:

On Thu, Mar 01, 2018 at 04:30:10PM +0100, Daniel Golle wrote:

[forwarding to all other involved players]

On Thu, Mar 01, 2018 at 05:50:51PM +0300, Jamie Stuart wrote:

Hi Daniel,
The driver seems much improved after this fix.


it's about those two
[PATCH 1/2] rt2x00: pause almost full queue early
[PATCH 2/2] rt2x00: do not pause queue unconditionally on error path


Under very heavy load (30 clients downloading multi-GB files from SD card on 
the server concurrently), wifi dies with errors:


This is some testbed? Could you share how did you setup such
environment and what are client devices ?


[ 7794.230376] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame 
received with unrecognized signal, mode=0x0001, signal=0x010c, type=4


This is indicator that HW/FW has a problem. There could be various
reasons for that. One possible I can also observe in my setup,is strange
mishmash of seq  on frames which were not acked in BlockACK and
had to be resent. This can happen when many frames are wrongly decoded
(i.e. when there is bad radio condition or we have not correct low level
RF/BBP setup for a Ralink device). To mitigate that problem we can
limit length of agreggeted AMPDU frame.

I attached two patches which do that. One for RX side second for TX side.
Please check if they make a diffrent. You can also hardcode ba_size = 0
for those 30 clients setup.

Note the patches can cause (possibly small) perfromance degradation on
good setups.

Mathias, could you check them as well and see if they do not cause
performance regression on your device ? Lastly when I changed ba_size
setting, it was a problem on your setup.


Hey Stansilaw,

sorry for the delayed testing. I had to create a new test setup first, 
fought with buggy hardware and was busy with other stuff.


The two attached patches are causing a performance regression for me again:

OpenWrt head (forced HT40, 100Mbit wired interface)

wireless (iperf client) to wired (iperf server)
  Interval   Transfer Bitrate Retr
0.00-60.00  sec   584 MBytes  81.6 Mbits/sec  666   sender
0.00-60.00  sec   584 MBytes  81.6 Mbits/secreceiver

wired (iperf client) to wireless (iperf server)
  Interval   Transfer Bitrate Retr
0.00-60.00  sec   620 MBytes  86.7 Mbits/sec   33   sender
0.00-60.00  sec   617 MBytes  86.2 Mbits/secreceiver



OpenWrt head (forced HT40, 100Mbit wired interface)
  + rt2800_change_rx_ampdu_factor.patch
  + rt2800_change_ba_size.patch

wireless (iperf client) to wired (iperf server)
  Interval   Transfer Bitrate Retr
0.00-60.00  sec   356 MBytes  49.8 Mbits/sec6   sender
0.00-60.00  sec   356 MBytes  49.7 Mbits/secreceiver

wired (iperf client) to wireless (iperf server)
  Interval   Transfer Bitrate Retr
0.00-60.00  sec   627 MBytes  87.7 Mbits/sec5   sender
0.00-60.00  sec   626 MBytes  87.5 Mbits/secreceiver


Due to the regression I haven't tested your ampdu_density patch so far. 
Let me hear if you want to see more tests done.


Mathias

[PATCH] ath10k: Implement get_expected_throughput callback

[Anilkumar Kolli]

Enable support for 'drv_get_expected_throughput' callback.
Export expected throughput if available to cfg80211/nl80211.

Signed-off-by: Anilkumar Kolli 
Signed-off-by: Tamizh chelvam 
---
 drivers/net/wireless/ath/ath10k/core.h |5 +
 drivers/net/wireless/ath/ath10k/mac.c  |   17 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index fe6b30356d3b..8e10f7d83a79 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2005-2011 Atheros Communications Inc.
  * Copyright (c) 2011-2017 Qualcomm Atheros, Inc.
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -37,6 +38,7 @@
 #include "thermal.h"
 #include "wow.h"
 #include "swap.h"
+#include 
 
 #define MS(_v, _f) (((_v) & _f##_MASK) >> _f##_LSB)
 #define SM(_v, _f) (((_v) << _f##_LSB) & _f##_MASK)
@@ -354,6 +356,8 @@ struct ath10k_txq {
unsigned long num_push_allowed;
 };
 
+DECLARE_EWMA(sta_txrate, 4, 16)
+
 struct ath10k_sta {
struct ath10k_vif *arvif;
 
@@ -367,6 +371,7 @@ struct ath10k_sta {
 
struct work_struct update_wk;
u64 rx_duration;
+   struct ewma_sta_txrate ave_sta_txrate;
 
 #ifdef CONFIG_MAC80211_DEBUGFS
/* protected by conf_mutex */
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 7e02ca02b28e..e04fbe9ccfee 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7686,6 +7686,22 @@ static void ath10k_sta_statistics(struct ieee80211_hw 
*hw,
}
sinfo->txrate.flags = arsta->txrate.flags;
sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_BITRATE;
+
+   sinfo->expected_throughput =
+   ewma_sta_txrate_read(>ave_sta_txrate);
+   sinfo->filled |= BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT);
+}
+
+static u32 ath10k_get_expected_throughput(struct ieee80211_hw *hw,
+ struct ieee80211_sta *sta)
+{
+   struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+   u32 tx_bitrate;
+
+   tx_bitrate = cfg80211_calculate_bitrate(>txrate);
+   ewma_sta_txrate_add(>ave_sta_txrate, tx_bitrate);
+
+   return ewma_sta_txrate_read(>ave_sta_txrate);
 }
 
 static const struct ieee80211_ops ath10k_ops = {
@@ -7730,6 +7746,7 @@ static void ath10k_sta_statistics(struct ieee80211_hw *hw,
.switch_vif_chanctx = ath10k_mac_op_switch_vif_chanctx,
.sta_pre_rcu_remove = ath10k_mac_op_sta_pre_rcu_remove,
.sta_statistics = ath10k_sta_statistics,
+   .get_expected_throughput= ath10k_get_expected_throughput,
 
CFG80211_TESTMODE_CMD(ath10k_tm_cmd)
 
-- 
1.7.9.5