Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

On Sun, Jan 15, 2017 at 6:35 PM, Shawn Lin  wrote:
> On 2017/1/16 5:41, Matt Ranostay wrote:
>>
>> On Thu, Jan 12, 2017 at 11:16 PM, Shawn Lin 
>> wrote:
>>>
>>> On 2017/1/13 13:29, Matt Ranostay wrote:


 Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
 This can be abstracted to other chipsets if needed in the future.

 Cc: Tony Lindgren 
 Cc: Ulf Hansson 
 Signed-off-by: Matt Ranostay 
 ---
  drivers/mmc/core/Kconfig |  10 
  drivers/mmc/core/Makefile|   1 +
  drivers/mmc/core/pwrseq_sd8787.c | 117
 +++
  3 files changed, 128 insertions(+)
  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

 diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
 index cdfa8520a4b1..fc1ecdaaa9ca 100644
 --- a/drivers/mmc/core/Kconfig
 +++ b/drivers/mmc/core/Kconfig
 @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
   This driver can also be built as a module. If so, the module
   will be called pwrseq_emmc.

 +config PWRSEQ_SD8787
 +   tristate "HW reset support for SD8787 BT + Wifi module"
 +   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
 +   help
 + This selects hardware reset support for the SD8787 BT + Wifi
 + module. By default this option is set to n.
 +
 + This driver can also be built as a module. If so, the module
 + will be called pwrseq_sd8787.
 +
>>>
>>>
>>>
>>> I don't like this way, as we have a chance to list lots
>>> configure options here. wifi A,B,C,D...Z, all of them need a
>>> new section here if needed?
>>>
>>> Instead, could you just extent pwrseq_simple.c and add you
>>> .compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?
>>
>>
>> You mean all the chipset pwrseqs linked into the pwrseq-simple module?
>
>
> What I mean was if you just extent the pwrseq-simple a bit, you could
> just add your chipset pwrseqs linked into the pwrseq-simple. But if you
> need a different *pattern* of pwrseqs, you should need a new name, for
> instance, pwrseq-sdio.c etc... But please don't use the name of
> sd8787? So if I use a wifi named ABC but using the same pwrseq pattenr,
> should I include your "mmc-pwrseq- sd8787" for that or I need a new
> mmc-pwrseq-ABC.c?

Ah so pwrseq-sdio.c seems reasonable and having chipsets functions
defined in a structure. That could be abstracted out for other
chipsets that could needed in the future.

- Matt

>
>
>>
>> Ulf your thoughts on this?
>>
>>>
>>>
>>>
  config PWRSEQ_SIMPLE
 tristate "Simple HW reset support for MMC"
 default y
 diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
 index b2a257dc644f..0f81464fa824 100644
 --- a/drivers/mmc/core/Makefile
 +++ b/drivers/mmc/core/Makefile
 @@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
quirks.o slot-gpio.o
  mmc_core-$(CONFIG_OF)  += pwrseq.o
  obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
 +obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
  obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
  mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
  obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
 diff --git a/drivers/mmc/core/pwrseq_sd8787.c
 b/drivers/mmc/core/pwrseq_sd8787.c
 new file mode 100644
 index ..f4080fe6439e
 --- /dev/null
 +++ b/drivers/mmc/core/pwrseq_sd8787.c
 @@ -0,0 +1,117 @@
 +/*
 + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT +
 Wifi
 chip
 + *
 + * Copyright (C) 2016 Matt Ranostay 
 + *
 + * Based on the original work pwrseq_simple.c
 + *  Copyright (C) 2014 Linaro Ltd
 + *  Author: Ulf Hansson 
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 + * GNU General Public License for more details.
 + *
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include 
 +
 +#include "pwrseq.h"
 +
 +struct mmc_pwrseq_sd8787 {
 +   struct mmc_pwrseq pwrseq;
 +   struct gpio_desc *reset_gpio;
 +   struct gpio_desc 

Re: [PATCH net-next v2] bridge: multicast to unicast

[kbuild test robot]

Hi Felix,

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/Linus-L-ssing/bridge-multicast-to-unicast/20170118-120345
config: x86_64-rhel-7.2 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   net/bridge/br_forward.c: In function 'br_multicast_flood':
>> net/bridge/br_forward.c:261:27: warning: 'port' may be used uninitialized in 
>> this function [-Wmaybe-uninitialized]
  struct net_bridge_port *port, *lport, *rport;
  ^~~~

vim +/port +261 net/bridge/br_forward.c

5cb5e947 Herbert Xu  2010-02-27  245  #ifdef CONFIG_BRIDGE_IGMP_SNOOPING
5cb5e947 Herbert Xu  2010-02-27  246  /* called with rcu_read_lock */
37b090e6 Nikolay Aleksandrov 2016-07-14  247  void br_multicast_flood(struct 
net_bridge_mdb_entry *mdst,
b35c5f63 Nikolay Aleksandrov 2016-07-14  248struct sk_buff 
*skb,
37b090e6 Nikolay Aleksandrov 2016-07-14  249bool local_rcv, 
bool local_orig)
5cb5e947 Herbert Xu  2010-02-27  250  {
5cb5e947 Herbert Xu  2010-02-27  251struct net_device *dev = 
BR_INPUT_SKB_CB(skb)->brdev;
1080ab95 Nikolay Aleksandrov 2016-06-28  252u8 igmp_type = 
br_multicast_igmp_type(skb);
5cb5e947 Herbert Xu  2010-02-27  253struct net_bridge *br = 
netdev_priv(dev);
afe0159d stephen hemminger   2010-04-27  254struct net_bridge_port *prev = 
NULL;
5cb5e947 Herbert Xu  2010-02-27  255struct net_bridge_port_group *p;
5cb5e947 Herbert Xu  2010-02-27  256struct hlist_node *rp;
5cb5e947 Herbert Xu  2010-02-27  257  
e8051688 Eric Dumazet2010-11-15  258rp = 
rcu_dereference(hlist_first_rcu(>router_list));
83f6a740 stephen hemminger   2010-04-27  259p = mdst ? 
rcu_dereference(mdst->ports) : NULL;
5cb5e947 Herbert Xu  2010-02-27  260while (p || rp) {
afe0159d stephen hemminger   2010-04-27 @261struct net_bridge_port 
*port, *lport, *rport;
afe0159d stephen hemminger   2010-04-27  262  
5cb5e947 Herbert Xu  2010-02-27  263lport = p ? p->port : 
NULL;
5cb5e947 Herbert Xu  2010-02-27  264rport = rp ? 
hlist_entry(rp, struct net_bridge_port, rlist) :
5cb5e947 Herbert Xu  2010-02-27  265 NULL;
5cb5e947 Herbert Xu  2010-02-27  266  
507962cd Felix Fietkau   2017-01-17  267if ((unsigned 
long)lport > (unsigned long)rport) {
507962cd Felix Fietkau   2017-01-17  268if (p->flags & 
MDB_PG_FLAGS_MCAST_TO_UCAST) {
507962cd Felix Fietkau   2017-01-17  269
maybe_deliver_addr(lport, skb, p->eth_addr,

:: The code at line 261 was first introduced by commit
:: afe0159d935ab731c682e811356914bb2be9470c bridge: multicast_flood cleanup

:: TO: stephen hemminger 
:: CC: David S. Miller 

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


.config.gz
Description: application/gzip

Re: [PATCH] brcmfmac: use wiphy_read_of_freq_limits to respect limits from DT

[kbuild test robot]

Hi Rafał,

[auto build test ERROR on wireless-drivers-next/master]
[cannot apply to v4.10-rc4 next-20170117]
[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/Rafa-Mi-ecki/brcmfmac-use-wiphy_read_of_freq_limits-to-respect-limits-from-DT/20170118-12
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
master
config: x86_64-randconfig-x013-201703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c: In function 
'brcmf_setup_wiphy':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:6484:2: error: 
>> implicit declaration of function 'wiphy_read_of_freq_limits' 
>> [-Werror=implicit-function-declaration]
 wiphy_read_of_freq_limits(wiphy);
 ^
   cc1: some warnings being treated as errors

vim +/wiphy_read_of_freq_limits +6484 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c

  6478  
  6479  band->n_channels = 
ARRAY_SIZE(__wl_5ghz_channels);
  6480  wiphy->bands[NL80211_BAND_5GHZ] = band;
  6481  }
  6482  }
  6483  
> 6484  wiphy_read_of_freq_limits(wiphy);
  6485  
  6486  return 0;
  6487  }

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


.config.gz
Description: application/gzip

Re: Clarifying rtl8188ee's channel wifi changing code

[Larry Finger]

On 01/17/2017 11:40 PM, Farhan Khan wrote:

Hi all,

I am having a bit of trouble understanding the rtl8188ee source,
specifically how its switch_channel function (rtl88e_phy_sw_chnl) works. I
gather that this function calls rtl88ee_phy_sw_chnl_callback, which in turn
calls _rtl88_phy_sw_chnl_step_by_step (
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c#L1253
).

This is where I get lost. Where is the 'channel' variable used, other than
to change the TX power? I presume it has something to do with case
CMDID_RF_WRITEREG, but I am not certain.

Please explain what is going on. Thank you!


I have no idea where you are getting those routine names, but my source does not 
have them, unless something has broken grep on my system.


Larry

Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry interrupt status checks

[Brian Norris]

On Tue, Jan 17, 2017 at 12:44:55PM -0800, Dmitry Torokhov wrote:
> On Tue, Jan 17, 2017 at 11:48:22AM -0800, Brian Norris wrote:
> > Also, FWIW, I did some fairly non-scientific tests of this on my
> > systems, and I didn't see much difference. I can run better tests, and
> > even collect data on how often we loop here vs. see new interrupts.
> 
> That would be great. Maybe packet aggregation takes care of interrupts
> arriving "too closely" together most of the time, I dunno.

OK, so I did some basic accounting of how many times this while loop
runs in a row. I don't know if they're highly illuminating, but here
goes. They're listed as a histogram, where the first column is number of
samples that exhibited the behavior and second column is number of times
going through the loop before exiting (i.e., seeing no more INT_STATUS):

Idle (just scanning for networks occasionally, and loading a web page or
two) for a minute or two:
  1 
265 1
  2 2

Downloading a Chrome .deb package via wget, in a loop:
857 0
  36406 1
  32386 2
   2230 3
153 4
 11 5

Running a perf client test (i.e., TX traffic) in a loop:
   1694 0
 247897 1
  25530 2
441 3
 18 4

So it seems like in some cases, it's at least *possible* to have a little bit
of potential savings on 10-50% of interrupts when under load. (i.e., see
that ~50% of interrupt checks take 2, 3, 4, or 5 loops in the second
example.)

Now, I also did some perf numbers with iperf between a Raspberry Pi iperf
server and an ARM64 system running mwifiex. On the whole, the TX side was
probably bottlenecked by the RPi, but the RX side was pretty good.

I'll attach full numbers, but the percentage delta is as follows:

   Mean Median
   --   --
% change, bi-direction (RX):   -0.3 -4.5
% change, bi-direction (TX):1.0344.45
% change, TX only: 12.9613.35
% change, RX only: -6.5 -3

I'm not sure I have a good explanation for the gain in TX performance.
Perhaps partly the reduction in complexity (e.g., unnecessary register
reads). Perhaps also because I had IEEE power-save enabled, so without
this patch, performance could (theoretically) be harmed by the issue
mentioned in the commit description (i.e., occasional slow PCIe reads)
-- though I guess we probably don't enter power-save often during iperf
tests.

So, there could definitely be some methodology mistakes or other
variables involved, but these don't seem to show any particularly bad
performance loss, and if we did, we might consider other approaches like
NAPI for tuning them.

Brian
,Mbit/s,,Min,Max,Mean,Median,Stddev
Before: Bidirectional RX,193,163,198,147,194,195,129,167,198,174,129,198,175.8,183.5,24.142171494
Before: Bidirectional TX,15.2,21.4,15.8,26.2,13.8,12.6,22.9,14.3,14.7,35.1,12.6,35.1,19.2,15.5,7.1870253466
Before: TX only,60.6,52.4,70,66,60.9,64.9,58.3,59.8,53.3,58.3,52.4,70,60.45,60.2,5.4530827163
Before: RX only,151,186,209,201,180,208,210,189,176,196,151,210,190.6,192.5,18.476411388
After: Bidirectional RX,171,194,187,165,167,197,163,199,192,120,120,199,175.5,179,24.0381641007
After: Bidirectional TX,30.4,19,19.8,20.2,20.7,20.1,27.3,18.8,19.3,6.74,6.74,30.4,20.234,19.95,6.1485322548
After: TX only,73.9,78.1,73.3,73.2,74.5,82.1,73.8,69.6,68.7,66.9,66.9,82.1,73.41,73.55,4.4500811478
After: RX only,160,163,179,195,203,187,192,202,207,153,153,207,184.1,189.5,19.4676369621
,,,
Delta: Bidirectional RX,-0.3,-4.5,
Delta: Bidirectional TX,1.034,4.45,
Delta: TX only,12.96,13.35,
Delta: RX only,-6.5,-3,
,,,
,-0.17%,-2.45%,
,5.39%,28.71%,
,21.44%,22.18%,
,-3.41%,-1.56%,

Clarifying rtl8188ee's channel wifi changing code

[Farhan Khan]

Hi all,

I am having a bit of trouble understanding the rtl8188ee source,
specifically how its switch_channel function (rtl88e_phy_sw_chnl) works. I
gather that this function calls rtl88ee_phy_sw_chnl_callback, which in turn
calls _rtl88_phy_sw_chnl_step_by_step (
https://github.com/torvalds/linux/blob/master/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/phy.c#L1253
).

This is where I get lost. Where is the 'channel' variable used, other than
to change the TX power? I presume it has something to do with case
CMDID_RF_WRITEREG, but I am not certain.

Please explain what is going on. Thank you!

[PATCH 1/5] rtl8xxxu: Mark 8192eu device 0x0bda:0x818b as tested

[Jes . Sorensen]

From: Jes Sorensen 

Device reported as working fine, so tell the driver not to warn about
it being untested.

Reported-by: Aex Aey 
Signed-off-by: Jes Sorensen 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 3a86675..99cfd2b 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6000,6 +6000,7 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
case 0x8176:
case 0x8178:
case 0x817f:
+   case 0x818b:
untested = 0;
break;
}
-- 
2.7.4

[PATCH 3/5] rtl8xxxu: Add USB ID for D-Link DWA-131 rev E1 (rtl8192eu)

[Jes . Sorensen]

From: Axel Köllhofer 

This was tested by David Patiño.

Reported-by: David Patiño 
Signed-off-by: Axel Köllhofer 
Signed-off-by: Jes Sorensen 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 016ea24..a8386f4 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6200,6 +6200,9 @@ static struct usb_device_id dev_table[] = {
 /* TP-Link TL-WN822N v4 */
 {USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0108, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
+/* D-Link DWA-131 rev E1, tested by David Patiño */
+{USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x3319, 0xff, 0xff, 0xff),
+   .driver_info = (unsigned long)_fops},
 /* Tested by Myckel Habets */
 {USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0109, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
-- 
2.7.4

[PATCH 5/5] rtl8xxxu: Update author/maintainer contact info

[Jes . Sorensen]

From: Jes Sorensen 

Update copyright year and email address.

Signed-off-by: Jes Sorensen 
---
 MAINTAINERS| 2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h   | 2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c | 2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c | 2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c  | 4 ++--
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h  | 2 +-
 8 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c8df0e1..0b5c80e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10584,7 +10584,7 @@ F:  drivers/net/wireless/realtek/rtlwifi/
 F: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/
 
 RTL8XXXU WIRELESS DRIVER (rtl8xxxu)
-M: Jes Sorensen 
+M: Jes Sorensen 
 L: linux-wireless@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git 
rtl8xxxu-devel
 S: Maintained
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index df551b2..95e3993 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014 - 2016 Jes Sorensen 
+ * Copyright (c) 2014 - 2017 Jes Sorensen 
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of version 2 of the GNU General Public License as
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
index f9e2050..a41a296 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c
@@ -1,7 +1,7 @@
 /*
  * RTL8XXXU mac80211 USB driver - 8188c/8188r/8192c specific subdriver
  *
- * Copyright (c) 2014 - 2016 Jes Sorensen 
+ * Copyright (c) 2014 - 2017 Jes Sorensen 
  *
  * Portions, notably calibration code:
  * Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index a1178c5..80fee69 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -1,7 +1,7 @@
 /*
  * RTL8XXXU mac80211 USB driver - 8192e specific subdriver
  *
- * Copyright (c) 2014 - 2016 Jes Sorensen 
+ * Copyright (c) 2014 - 2017 Jes Sorensen 
  *
  * Portions, notably calibration code:
  * Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c
index aef3730..1746311 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c
@@ -1,7 +1,7 @@
 /*
  * RTL8XXXU mac80211 USB driver - 8723a specific subdriver
  *
- * Copyright (c) 2014 - 2016 Jes Sorensen 
+ * Copyright (c) 2014 - 2017 Jes Sorensen 
  *
  * Portions, notably calibration code:
  * Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index 02b8ddd..c4b86a8 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1,7 +1,7 @@
 /*
  * RTL8XXXU mac80211 USB driver - 8723b specific subdriver
  *
- * Copyright (c) 2014 - 2016 Jes Sorensen 
+ * Copyright (c) 2014 - 2017 Jes Sorensen 
  *
  * Portions, notably calibration code:
  * Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 3585a04..e544dd1 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -1,7 +1,7 @@
 /*
  * RTL8XXXU mac80211 USB driver
  *
- * Copyright (c) 2014 - 2016 Jes Sorensen 
+ * Copyright (c) 2014 - 2017 Jes Sorensen 
  *
  * Portions, notably calibration code:
  * Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved.
@@ -48,7 +48,7 @@ static bool rtl8xxxu_dma_aggregation;
 static int rtl8xxxu_dma_agg_timeout = -1;
 static int rtl8xxxu_dma_agg_pages = -1;
 
-MODULE_AUTHOR("Jes Sorensen 

[PATCH 2/5] rtl8xxxu: Add another 8192eu device to the USB list

[Jes . Sorensen]

From: Jes Sorensen 

TP-Link TL-WN822N v4 (2357:0108)

Reported-by: Gregory Auzanneau 
Signed-off-by: Jes Sorensen 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 99cfd2b..016ea24 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6197,6 +6197,9 @@ static struct usb_device_id dev_table[] = {
.driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x818b, 0xff, 0xff, 
0xff),
.driver_info = (unsigned long)_fops},
+/* TP-Link TL-WN822N v4 */
+{USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0108, 0xff, 0xff, 0xff),
+   .driver_info = (unsigned long)_fops},
 /* Tested by Myckel Habets */
 {USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0109, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
-- 
2.7.4

[PATCH 4/5] rtl8xxxu: Add additional USB IDs for rtl8192eu devices

[Jes . Sorensen]

From: Axel Köllhofer 

These IDs originate from the vendor driver

Signed-off-by: Axel Köllhofer 
Signed-off-by: Jes Sorensen 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index a8386f4..3585a04 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6354,6 +6354,13 @@ static struct usb_device_id dev_table[] = {
.driver_info = (unsigned long)_fops},
 {USB_DEVICE_AND_INTERFACE_INFO(0x7392, 0x7822, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)_fops},
+/* found in rtl8192eu vendor driver */
+{USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0107, 0xff, 0xff, 0xff),
+   .driver_info = (unsigned long)_fops},
+{USB_DEVICE_AND_INTERFACE_INFO(0x2019, 0xab33, 0xff, 0xff, 0xff),
+   .driver_info = (unsigned long)_fops},
+{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x818c, 0xff, 0xff, 
0xff),
+   .driver_info = (unsigned long)_fops},
 #endif
 { }
 };
-- 
2.7.4

[PATCH 0/5] Update USB IDs and email adress

[Jes . Sorensen]

From: Jes Sorensen 

Hi,

This patchset adds some additional USB IDs for rtl8192eu devices, as
well as updates the email address and the copyright.

I've been preoccupied with some other stuff the last little while, so
I am a little out of touch with whether or not the patch window is
open at the moment. Please yell at me if you want me to resubmit these later.

Cheers,
Jes


Axel Köllhofer (2):
  rtl8xxxu: Add USB ID for D-Link DWA-131 rev E1 (rtl8192eu)
  rtl8xxxu: Add additional USB IDs for rtl8192eu devices

Jes Sorensen (3):
  rtl8xxxu: Mark 8192eu device 0x0bda:0x818b as tested
  rtl8xxxu: Add another 8192eu device to the USB list
  rtl8xxxu: Update author/maintainer contact info

 MAINTAINERS|  2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h   |  2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c |  2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c |  2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c |  2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c |  2 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c  | 18 --
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h  |  2 +-
 8 files changed, 23 insertions(+), 9 deletions(-)

-- 
2.7.4

[PATCH v3] brcmfmac: fix incorrect event channel deduction

[gavinli]

From: Gavin Li 

brcmf_sdio_fromevntchan() was being called on the the data frame
rather than the software header, causing some frames to be
mischaracterized as on the event channel rather than the data channel.

This fixes a major performance regression (due to dropped packets).

Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet")
Signed-off-by: Gavin Li 
Cc:  [4.7+]
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index dfb0658713d9..d2219885071f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -1661,7 +1661,7 @@ static u8 brcmf_sdio_rxglom(struct brcmf_sdio *bus, u8 
rxseq)
   pfirst->len, pfirst->next,
   pfirst->prev);
skb_unlink(pfirst, >glom);
-   if (brcmf_sdio_fromevntchan(pfirst->data))
+   if (brcmf_sdio_fromevntchan([SDPCM_HWHDR_LEN]))
brcmf_rx_event(bus->sdiodev->dev, pfirst);
else
brcmf_rx_frame(bus->sdiodev->dev, pfirst,
-- 
2.11.0

iwlwifi: fix kernel crash when unregistering thermal zone

[Jens Axboe]

A recent firmware change seems to have enabled thermal zones on the
iwlwifi driver. Unfortunately, my device fails when registering the
thermal zone. This doesn't stop the driver from attempting to unregister
the thermal zone at unload time, triggering a NULL pointer deference in
strlen() off the thermal_zone_device_unregister() path.

Don't unregister if name is NULL, for that case we failed registering.
Do the same for the cooling zone.

Signed-off-by: Jens Axboe 

---

Would be great if this could go into the current series, as sometimes I
have to reload the driver. Right now I can't, since it crashes...

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
index 63a051be832e..bec7d9c46087 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
@@ -843,8 +843,10 @@ static void iwl_mvm_thermal_zone_unregister(struct iwl_mvm 
*mvm)
return;
 
IWL_DEBUG_TEMP(mvm, "Thermal zone device unregister\n");
-   thermal_zone_device_unregister(mvm->tz_device.tzone);
-   mvm->tz_device.tzone = NULL;
+   if (mvm->tz_device.tzone) {
+   thermal_zone_device_unregister(mvm->tz_device.tzone);
+   mvm->tz_device.tzone = NULL;
+   }
 }
 
 static void iwl_mvm_cooling_device_unregister(struct iwl_mvm *mvm)
@@ -853,8 +855,10 @@ static void iwl_mvm_cooling_device_unregister(struct 
iwl_mvm *mvm)
return;
 
IWL_DEBUG_TEMP(mvm, "Cooling device unregister\n");
-   thermal_cooling_device_unregister(mvm->cooling_dev.cdev);
-   mvm->cooling_dev.cdev = NULL;
+   if (mvm->cooling_dev.cdev) {
+   thermal_cooling_device_unregister(mvm->cooling_dev.cdev);
+   mvm->cooling_dev.cdev = NULL;
+   }
 }
 #endif /* CONFIG_THERMAL */

Re: [PATCH] brcmfmac: fix incorrect event channel deduction

[Rafał Miłecki]

On 17 January 2017 at 23:55,   wrote:
> From: Gavin Li 
>
> brcmf_sdio_fromevntchan() was being called on the the data frame
> rather than the software header, causing some frames to be
> mischaracterized as on the event channel rather than the data channel.
>
> This fixes a major performance regression (due to dropped packets).
>
> Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet")
> Signed-off-by: Gavin Li 
> Cc:  [4.6+]

Oh, that was supposed to be 4.7+, I gave you a wrong hint, sorry!

You may send V3, or maybe ask Kalle to fix it by hand when applying the patch.

-- 
Rafał

[PATCH] brcmfmac: fix incorrect event channel deduction

[gavinli]

From: Gavin Li 

brcmf_sdio_fromevntchan() was being called on the the data frame
rather than the software header, causing some frames to be
mischaracterized as on the event channel rather than the data channel.

This fixes a major performance regression (due to dropped packets).

Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet")
Signed-off-by: Gavin Li 
Cc:  [4.7+]
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index dfb0658713d9..d2219885071f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -1661,7 +1661,7 @@ static u8 brcmf_sdio_rxglom(struct brcmf_sdio *bus, u8 
rxseq)
   pfirst->len, pfirst->next,
   pfirst->prev);
skb_unlink(pfirst, >glom);
-   if (brcmf_sdio_fromevntchan(pfirst->data))
+   if (brcmf_sdio_fromevntchan([SDPCM_HWHDR_LEN]))
brcmf_rx_event(bus->sdiodev->dev, pfirst);
else
brcmf_rx_frame(bus->sdiodev->dev, pfirst,
-- 
2.11.0

[PATCH] brcmfmac: fix incorrect event channel deduction

[gavinli]

From: Gavin Li 

brcmf_sdio_fromevntchan() was being called on the the data frame
rather than the software header, causing some frames to be
mischaracterized as on the event channel rather than the data channel.

This fixes a major performance regression (due to dropped packets).

Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet")
Signed-off-by: Gavin Li 
Cc:  [4.6+]
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index dfb0658713d9..d2219885071f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -1661,7 +1661,7 @@ static u8 brcmf_sdio_rxglom(struct brcmf_sdio *bus, u8 
rxseq)
   pfirst->len, pfirst->next,
   pfirst->prev);
skb_unlink(pfirst, >glom);
-   if (brcmf_sdio_fromevntchan(pfirst->data))
+   if (brcmf_sdio_fromevntchan([SDPCM_HWHDR_LEN]))
brcmf_rx_event(bus->sdiodev->dev, pfirst);
else
brcmf_rx_frame(bus->sdiodev->dev, pfirst,
-- 
2.11.0

[PATCH] brcmfmac: fix incorrect event channel deduction

[gavinli]

From: Gavin Li 

brcmf_sdio_fromevntchan() was being called on the the data frame
rather than the software header, causing some frames to be
mischaracterized as on the event channel rather than the data channel.

This fixes a major performance regression (due to dropped packets).

Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet")
Signed-off-by: Gavin Li 
Cc:  [4.6+]
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index dfb0658713d9..d2219885071f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -1661,7 +1661,7 @@ static u8 brcmf_sdio_rxglom(struct brcmf_sdio *bus, u8 
rxseq)
   pfirst->len, pfirst->next,
   pfirst->prev);
skb_unlink(pfirst, >glom);
-   if (brcmf_sdio_fromevntchan(pfirst->data))
+   if (brcmf_sdio_fromevntchan([SDPCM_HWHDR_LEN]))
brcmf_rx_event(bus->sdiodev->dev, pfirst);
else
brcmf_rx_frame(bus->sdiodev->dev, pfirst,
-- 
2.11.0

[PATCH] brcmfmac: use wiphy_read_of_freq_limits to respect limits from DT

[Rafał Miłecki]

From: Rafał Miłecki 

This new helper reads extra frequency limits specified in DT and
disables unavailable chanels. This is useful for devices (like home
routers) with chipsets limited e.g. by board design.

In order to respect info read from DT we simply need to check for
IEEE80211_CHAN_DISABLED bit when constructing channel info.

Signed-off-by: Rafał Miłecki 
---
This patch requires e691ac2f75b6 ("cfg80211: support ieee80211-freq-limit DT
property") that is currently in net-next.

Kalle: feel free to postpone this until merging net-next one day.
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ec1171c..b96fc88 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct 
brcmf_cfg80211_info *cfg,
continue;
}
 
+   if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
+   continue;
+
/* assuming the chanspecs order is HT20,
 * HT40 upper, HT40 lower, and VHT80.
 */
@@ -6477,6 +6480,9 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct 
brcmf_if *ifp)
wiphy->bands[NL80211_BAND_5GHZ] = band;
}
}
+
+   wiphy_read_of_freq_limits(wiphy);
+
return 0;
 }
 
-- 
2.10.1

Re: [PATCH] brcmfmac: fix incorrect event channel deduction

[Rafał Miłecki]

On 17 January 2017 at 23:41, Rafał Miłecki  wrote:
> On 17 January 2017 at 23:29,   wrote:
>> From: Gavin Li 
>>
>> brcmf_sdio_fromevntchan() was being called on the the hardware header
>> rather than the software header, causing some frames to be
>> mischaracterized as on the event channel rather than the data channel.
>> This fixes the performance regression introduced in commit c56caa9d
>> where event processing is done separately.
>
> This should be:
> in commit c56caa9db8ab ("brcmfmac: screening firmware event packet") where 
> (...)
>
> You should also use
> Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet") where (...)

Oops, copy & paste mistake. Just:
Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet")

-- 
Rafał

Re: [PATCH] brcmfmac: fix incorrect event channel deduction

[Rafał Miłecki]

On 17 January 2017 at 23:29,   wrote:
> From: Gavin Li 
>
> brcmf_sdio_fromevntchan() was being called on the the hardware header
> rather than the software header, causing some frames to be
> mischaracterized as on the event channel rather than the data channel.
> This fixes the performance regression introduced in commit c56caa9d
> where event processing is done separately.

This should be:
in commit c56caa9db8ab ("brcmfmac: screening firmware event packet") where (...)

You should also use
Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet") where (...)


> Signed-off-by: Gavin Li 

Please add also:
Cc: sta...@vger.kernel.org # 4.6+

[PATCH] brcmfmac: fix incorrect event channel deduction

[gavinli]

From: Gavin Li 

brcmf_sdio_fromevntchan() was being called on the the hardware header
rather than the software header, causing some frames to be
mischaracterized as on the event channel rather than the data channel.
This fixes the performance regression introduced in commit c56caa9d
where event processing is done separately.

Signed-off-by: Gavin Li 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index dfb0658713d9..d2219885071f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -1661,7 +1661,7 @@ static u8 brcmf_sdio_rxglom(struct brcmf_sdio *bus, u8 
rxseq)
   pfirst->len, pfirst->next,
   pfirst->prev);
skb_unlink(pfirst, >glom);
-   if (brcmf_sdio_fromevntchan(pfirst->data))
+   if (brcmf_sdio_fromevntchan([SDPCM_HWHDR_LEN]))
brcmf_rx_event(bus->sdiodev->dev, pfirst);
else
brcmf_rx_frame(bus->sdiodev->dev, pfirst,
-- 
2.11.0

Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry interrupt status checks

[Dmitry Torokhov]

On Tue, Jan 17, 2017 at 11:48:22AM -0800, Brian Norris wrote:
> On Sun, Jan 15, 2017 at 04:54:52PM -0800, Dmitry Torokhov wrote:
> > On Fri, Jan 13, 2017 at 03:35:37PM -0800, Brian Norris wrote:
> > > The following sequence occurs when using IEEE power-save on 8997:
> > > (a) driver sees SLEEP event
> > > (b) driver issues SLEEP CONFIRM
> > > (c) driver recevies CMD interrupt; within the interrupt processing loop,
> > > we do (d) and (e):
> > > (d) wait for FW sleep cookie (and often time out; it takes a while), FW
> > > is putting card into low power mode
> > > (e) re-check PCIE_HOST_INT_STATUS register; quit loop with 0 value
> > > 
> > > But at (e), no one actually signaled an interrupt (i.e., we didn't check
> > > adapter->int_status). And what's more, because the card is going to
> > > sleep, this register read appears to take a very long time in some cases
> > > -- 3 milliseconds in my case!
> > > 
> > > Now, I propose that (e) is completely unnecessary. If there were any
> > > additional interrupts signaled after the start of this loop, then the
> > > interrupt handler would have set adapter->int_status to non-zero and
> > > queued more work for the main loop -- and we'd catch it on the next
> > > iteration of the main loop.
> > > 
> > > So this patch drops all the looping/re-reading of PCIE_HOST_INT_STATUS,
> > > which avoids the problematic (and slow) register read in step (e).
> > > 
> > > Incidentally, this is a very similar issue to the one fixed in commit
> > > ec815dd2a5f1 ("mwifiex: prevent register accesses after host is
> > > sleeping"), except that the register read is just very slow instead of
> > > fatal in this case.
> > > 
> > > Tested on 8997 in both MSI and (though not technically supported at the
> > > moment) MSI-X mode.
> > 
> > Well, that kills interrupt mitigation and with PCIE that might be
> > somewhat important (SDIO is too slow to be important I think) and might
> > cost you throughput.
> 
> Hmm, well I don't see us disabling interrupts in here, at least for MSI
> mode, so it doesn't actually look like a mitigation mechanism. More like
> a redundancy. But I'm not an expert on MSI, and definitely not on
> network performance.

Well, right, maybe not mitigation, but at least you have a chance to
avoid scheduling latency at times.

> 
> Also, FWIW, I did some fairly non-scientific tests of this on my
> systems, and I didn't see much difference. I can run better tests, and
> even collect data on how often we loop here vs. see new interrupts.

That would be great. Maybe packet aggregation takes care of interrupts
arriving "too closely" together most of the time, I dunno.

> 
> > OTOH maybe Marvell should convert PICE to NAPI to make this more
> > obvious and probably more correct.
> 
> From my brief reading, that sounds like a better way to make this
> configurable.
> 
> So I'm not sure which way you'd suggest then; take a patch like this,
> which makes the driver more clear and less buggy? Or write some
> different patch that isolates just the power-save related condition, so
> we break out of this look [1]?

I think it really depends on the test results. If we do not see
degradation in both throughput and latency then I think we can take this
patch and then see if switching to NAPI would be the ultimate solution.

> 
> I'm also interested in any opinions from the Marvell side -- potentially
> testing results, rationale behind this code structure, or even a better
> alternative patch.
> 
> Brian
> 
> [1] i.e., along the lines of commit ec815dd2a5f1 ("mwifiex: prevent
> register accesses after host is sleeping").

Thanks.

-- 
Dmitry

[PATCH net-next v2] bridge: multicast to unicast

[Linus Lüssing]

From: Felix Fietkau 

Implements an optional, per bridge port flag and feature to deliver
multicast packets to any host on the according port via unicast
individually. This is done by copying the packet per host and
changing the multicast destination MAC to a unicast one accordingly.

multicast-to-unicast works on top of the multicast snooping feature of
the bridge. Which means unicast copies are only delivered to hosts which
are interested in it and signalized this via IGMP/MLD reports
previously.

This feature is intended for interface types which have a more reliable
and/or efficient way to deliver unicast packets than broadcast ones
(e.g. wifi).

However, it should only be enabled on interfaces where no IGMPv2/MLDv1
report suppression takes place. This feature is disabled by default.

The initial patch and idea is from Felix Fietkau.

Signed-off-by: Felix Fietkau 
[linus.luess...@c0d3.blue: various bug + style fixes, commit message]
Signed-off-by: Linus Lüssing 

---

This feature is used and enabled by default in OpenWRT and LEDE for AP
interfaces for more than a year now to allow both a more robust multicast
delivery and multicast at higher rates (e.g. multicast streaming).

In OpenWRT/LEDE the IGMP/MLD report suppression issue is overcome by
the network daemon enabling AP isolation and by that separating all STAs.
Delivery of STA-to-STA IP mulitcast is made possible again by
enabling and utilizing the bridge hairpin mode, which considers the
incoming port as a potential outgoing port, too.

Hairpin-mode is performed after multicast snooping, therefore leading to
only deliver reports to STAs running a multicast router.

Changes in v2:
* netlink support (thanks Nik!)
* fixed switching between multicast_to_unicast on/off
  -> even after toggling an already existing entry would
 stale in its mode and would never be replaced
  -> new extra check in br_port_group_equal)
* reduced checks in br_multicast_flood() from two to one
  to address fast-path concerns (thanks Nik!)
* rev-christmas tree ordering (thanks Nik!)
* removed "net_bridge_port_group::unicast", using
  ::flags instead (thanks Nik!)
* BR_MULTICAST_TO_UCAST -> BR_MULTICAST_TO_UNICAST
  (BR_MULTICAST_FLAST_LEAVE has the same length anyway)
* simplified maybe_deliver_addr()
  (no return, no "prev" paramater -> was a NOP anyway)
* added "From: Felix Fietkau [...]"
* added "Signed-off-by: Felix Fietkau [...]"
---
 include/linux/if_bridge.h|  1 +
 include/uapi/linux/if_link.h |  1 +
 net/bridge/br_forward.c  | 37 -
 net/bridge/br_mdb.c  |  2 +-
 net/bridge/br_multicast.c| 96 
 net/bridge/br_netlink.c  |  5 +++
 net/bridge/br_private.h  |  8 ++--
 net/bridge/br_sysfs_if.c |  2 +
 8 files changed, 121 insertions(+), 31 deletions(-)

diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index c6587c0..debc9d5 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -46,6 +46,7 @@ struct br_ip_list {
 #define BR_LEARNING_SYNC   BIT(9)
 #define BR_PROXYARP_WIFI   BIT(10)
 #define BR_MCAST_FLOOD BIT(11)
+#define BR_MULTICAST_TO_UNICASTBIT(12)
 
 #define BR_DEFAULT_AGEING_TIME (300 * HZ)
 
diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
index 6b13e59..4e59565 100644
--- a/include/uapi/linux/if_link.h
+++ b/include/uapi/linux/if_link.h
@@ -321,6 +321,7 @@ enum {
IFLA_BRPORT_MULTICAST_ROUTER,
IFLA_BRPORT_PAD,
IFLA_BRPORT_MCAST_FLOOD,
+   IFLA_BRPORT_MCAST_TO_UCAST,
__IFLA_BRPORT_MAX
 };
 #define IFLA_BRPORT_MAX (__IFLA_BRPORT_MAX - 1)
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index 7cb41ae..75d041e 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -174,6 +174,29 @@ static struct net_bridge_port *maybe_deliver(
return p;
 }
 
+static void maybe_deliver_addr(struct net_bridge_port *p, struct sk_buff *skb,
+  const unsigned char *addr, bool local_orig)
+{
+   struct net_device *dev = BR_INPUT_SKB_CB(skb)->brdev;
+   const unsigned char *src = eth_hdr(skb)->h_source;
+
+   if (!should_deliver(p, skb))
+   return;
+
+   /* Even with hairpin, no soliloquies - prevent breaking IPv6 DAD */
+   if (skb->dev == p->dev && ether_addr_equal(src, addr))
+   return;
+
+   skb = skb_copy(skb, GFP_ATOMIC);
+   if (!skb) {
+   dev->stats.tx_dropped++;
+   return;
+   }
+
+   memcpy(eth_hdr(skb)->h_dest, addr, ETH_ALEN);
+   __br_forward(p, skb, local_orig);
+}
+
 /* called under rcu_read_lock */
 void br_flood(struct net_bridge *br, struct sk_buff *skb,
  enum br_pkt_type pkt_type, bool local_rcv, bool local_orig)
@@ -241,10 +264,20 @@ void br_multicast_flood(struct net_bridge_mdb_entry *mdst,
rport = rp ? hlist_entry(rp, 

Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry interrupt status checks

[Brian Norris]

On Sun, Jan 15, 2017 at 04:54:52PM -0800, Dmitry Torokhov wrote:
> On Fri, Jan 13, 2017 at 03:35:37PM -0800, Brian Norris wrote:
> > The following sequence occurs when using IEEE power-save on 8997:
> > (a) driver sees SLEEP event
> > (b) driver issues SLEEP CONFIRM
> > (c) driver recevies CMD interrupt; within the interrupt processing loop,
> > we do (d) and (e):
> > (d) wait for FW sleep cookie (and often time out; it takes a while), FW
> > is putting card into low power mode
> > (e) re-check PCIE_HOST_INT_STATUS register; quit loop with 0 value
> > 
> > But at (e), no one actually signaled an interrupt (i.e., we didn't check
> > adapter->int_status). And what's more, because the card is going to
> > sleep, this register read appears to take a very long time in some cases
> > -- 3 milliseconds in my case!
> > 
> > Now, I propose that (e) is completely unnecessary. If there were any
> > additional interrupts signaled after the start of this loop, then the
> > interrupt handler would have set adapter->int_status to non-zero and
> > queued more work for the main loop -- and we'd catch it on the next
> > iteration of the main loop.
> > 
> > So this patch drops all the looping/re-reading of PCIE_HOST_INT_STATUS,
> > which avoids the problematic (and slow) register read in step (e).
> > 
> > Incidentally, this is a very similar issue to the one fixed in commit
> > ec815dd2a5f1 ("mwifiex: prevent register accesses after host is
> > sleeping"), except that the register read is just very slow instead of
> > fatal in this case.
> > 
> > Tested on 8997 in both MSI and (though not technically supported at the
> > moment) MSI-X mode.
> 
> Well, that kills interrupt mitigation and with PCIE that might be
> somewhat important (SDIO is too slow to be important I think) and might
> cost you throughput.

Hmm, well I don't see us disabling interrupts in here, at least for MSI
mode, so it doesn't actually look like a mitigation mechanism. More like
a redundancy. But I'm not an expert on MSI, and definitely not on
network performance.

Also, FWIW, I did some fairly non-scientific tests of this on my
systems, and I didn't see much difference. I can run better tests, and
even collect data on how often we loop here vs. see new interrupts.

> OTOH maybe Marvell should convert PICE to NAPI to make this more
> obvious and probably more correct.

>From my brief reading, that sounds like a better way to make this
configurable.

So I'm not sure which way you'd suggest then; take a patch like this,
which makes the driver more clear and less buggy? Or write some
different patch that isolates just the power-save related condition, so
we break out of this look [1]?

I'm also interested in any opinions from the Marvell side -- potentially
testing results, rationale behind this code structure, or even a better
alternative patch.

Brian

[1] i.e., along the lines of commit ec815dd2a5f1 ("mwifiex: prevent
register accesses after host is sleeping").

[PATCH 1/2] brcmfmac: rename brcmf_bus_start function to brcmf_attach_phase2

[Rafał Miłecki]

From: Rafał Miłecki 

This change intends to make init/attach process easier to follow.

What driver were doing in brcmf_bus_start wasn't bus specific at all and
function brcmf_bus_stop wasn't undoing things done there. It seems
brcmf_detach was actually undoing things done in both: brcmf_attach and
brcmf_bus_start.

To me it makes more sense to call these two function in a similar way as
they both handle some part of attaching process. It also makes
brcmf_detach more meaningful.

Signed-off-by: Rafał Miłecki 
---
This patchset is based on top of
[PATCH 2/2] brcmfmac: move function declarations to proper headers
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c | 2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c   | 4 ++--
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h   | 4 ++--
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c   | 6 +++---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c   | 6 +++---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c| 6 +++---
 6 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 3e15d64..6fb7d12 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -74,7 +74,7 @@ module_param_named(roamoff, brcmf_roamoff, int, S_IRUSR);
 MODULE_PARM_DESC(roamoff, "Do not use internal roaming engine");
 
 #ifdef DEBUG
-/* always succeed brcmf_bus_start() */
+/* always succeed brcmf_attach_phase2() */
 static int brcmf_ignore_probe_fail;
 module_param_named(ignore_probe_fail, brcmf_ignore_probe_fail, int, 0);
 MODULE_PARM_DESC(ignore_probe_fail, "always succeed probe for debugging");
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index 9e6f60a..adf8eb1 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -893,7 +893,7 @@ static int brcmf_inet6addr_changed(struct notifier_block 
*nb,
 }
 #endif
 
-int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings)
+int brcmf_attach_phase1(struct device *dev, struct brcmf_mp_device *settings)
 {
struct brcmf_pub *drvr = NULL;
int ret = 0;
@@ -966,7 +966,7 @@ static int brcmf_revinfo_read(struct seq_file *s, void 
*data)
return 0;
 }
 
-int brcmf_bus_start(struct device *dev)
+int brcmf_attach_phase2(struct device *dev)
 {
int ret = -1;
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
index d92beca..df4189e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
@@ -226,8 +226,8 @@ void brcmf_rx_event(struct device *dev, struct sk_buff 
*rxp);
 void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
 void brcmf_net_setcarrier(struct brcmf_if *ifp, bool on);
 /* Indication from bus module regarding presence/insertion of dongle. */
-int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings);
-int brcmf_bus_start(struct device *dev);
+int brcmf_attach_phase1(struct device *dev, struct brcmf_mp_device *settings);
+int brcmf_attach_phase2(struct device *dev);
 void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
 /* Indication from bus module that dongle should be reset */
 void brcmf_dev_reset(struct device *dev);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 048027f..bbc3ded 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1568,11 +1568,11 @@ static int brcmf_pcie_attach_bus(struct 
brcmf_pciedev_info *devinfo)
int ret;
 
/* Attach to the common driver interface */
-   ret = brcmf_attach(>pdev->dev, devinfo->settings);
+   ret = brcmf_attach_phase1(>pdev->dev, devinfo->settings);
if (ret) {
-   brcmf_err("brcmf_attach failed\n");
+   brcmf_err("brcmf_attach_phase1 failed\n");
} else {
-   ret = brcmf_bus_start(>pdev->dev);
+   ret = brcmf_attach_phase2(>pdev->dev);
if (ret)
brcmf_err("dongle is not responding\n");
}
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index dfb0658..5307223 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -4065,7 +4065,7 @@ static void brcmf_sdio_firmware_callback(struct device 
*dev,
 

[PATCH 2/2] brcmfmac: drop brcmf_bus_detach and inline its code

[Rafał Miłecki]

From: Rafał Miłecki 

Driver used to call brcmf_bus_detach only from one place and it already
contained a check for drvr not being NULL. We can get rid of this extra
function, call brcmf_bus_stop directly and simplify the code.
There also isn't brcmf_bus_attach function which one could expect so it
looks more consistent this way.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
index adf8eb1..122c79d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
@@ -1075,16 +1075,6 @@ void brcmf_bus_add_txhdrlen(struct device *dev, uint len)
}
 }
 
-static void brcmf_bus_detach(struct brcmf_pub *drvr)
-{
-   brcmf_dbg(TRACE, "Enter\n");
-
-   if (drvr) {
-   /* Stop the bus module */
-   brcmf_bus_stop(drvr->bus_if);
-   }
-}
-
 void brcmf_dev_reset(struct device *dev)
 {
struct brcmf_bus *bus_if = dev_get_drvdata(dev);
@@ -1131,7 +1121,7 @@ void brcmf_detach(struct device *dev)
 
brcmf_fws_deinit(drvr);
 
-   brcmf_bus_detach(drvr);
+   brcmf_bus_stop(drvr->bus_if);
 
brcmf_proto_detach(drvr);
 
-- 
2.10.1

[PATCH 2/2] brcmfmac: move function declarations to proper headers

[Rafał Miłecki]

From: Rafał Miłecki 

Function brcmf_c_set_joinpref_default is in common.c, so move it to the
related header. All other (touched) ones are in core.c so take them out
of the bus.h.
I just needed to include bus.h to have enum brcmf_bus_state defined.

Signed-off-by: Rafał Miłecki 
---
 .../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 28 --
 .../wireless/broadcom/brcm80211/brcmfmac/common.h  |  2 ++
 .../wireless/broadcom/brcm80211/brcmfmac/core.h| 21 +++-
 3 files changed, 22 insertions(+), 29 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
index b5bb971..58a3de6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
@@ -214,34 +214,6 @@ int brcmf_bus_get_memdump(struct brcmf_bus *bus, void 
*data, size_t len)
return bus->ops->get_memdump(bus->dev, data, len);
 }
 
-/*
- * interface functions from common layer
- */
-
-/* Receive frame for delivery to OS.  Callee disposes of rxp. */
-void brcmf_rx_frame(struct device *dev, struct sk_buff *rxp, bool 
handle_event);
-/* Receive async event packet from firmware. Callee disposes of rxp. */
-void brcmf_rx_event(struct device *dev, struct sk_buff *rxp);
-
-/* Indication from bus module regarding presence/insertion of dongle. */
-int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings);
-/* Indication from bus module regarding removal/absence of dongle */
-void brcmf_detach(struct device *dev);
-/* Indication from bus module that dongle should be reset */
-void brcmf_dev_reset(struct device *dev);
-/* Indication from bus module to change flow-control state */
-void brcmf_txflowblock(struct device *dev, bool state);
-
-/* Notify the bus has transferred the tx packet to firmware */
-void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
-
-/* Configure the "global" bus state used by upper layers */
-void brcmf_bus_change_state(struct brcmf_bus *bus, enum brcmf_bus_state state);
-
-int brcmf_bus_start(struct device *dev);
-s32 brcmf_iovar_data_set(struct device *dev, char *name, void *data, u32 len);
-void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
-
 #ifdef CONFIG_BRCMFMAC_SDIO
 void brcmf_sdio_exit(void);
 void brcmf_sdio_register(void);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
index bd095ab..a62f8e7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h
@@ -65,6 +65,8 @@ struct brcmf_mp_device {
} bus;
 };
 
+void brcmf_c_set_joinpref_default(struct brcmf_if *ifp);
+
 struct brcmf_mp_device *brcmf_get_module_param(struct device *dev,
   enum brcmf_bus_type bus_type,
   u32 chip, u32 chiprev);
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
index c94dcab..d92beca 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.h
@@ -22,6 +22,7 @@
 #define BRCMFMAC_CORE_H
 
 #include 
+#include "bus.h"
 #include "fweh.h"
 
 #define TOE_TX_CSUM_OL 0x0001
@@ -213,10 +214,28 @@ struct brcmf_if *brcmf_add_if(struct brcmf_pub *drvr, s32 
bsscfgidx, s32 ifidx,
 void brcmf_remove_interface(struct brcmf_if *ifp, bool rtnl_locked);
 void brcmf_txflowblock_if(struct brcmf_if *ifp,
  enum brcmf_netif_stop_reason reason, bool state);
+/* Indication from bus module to change flow-control state */
+void brcmf_txflowblock(struct device *dev, bool state);
 void brcmf_txfinalize(struct brcmf_if *ifp, struct sk_buff *txp, bool success);
 void brcmf_netif_rx(struct brcmf_if *ifp, struct sk_buff *skb);
+/* Receive frame for delivery to OS.  Callee disposes of rxp. */
+void brcmf_rx_frame(struct device *dev, struct sk_buff *rxp, bool 
handle_event);
+/* Receive async event packet from firmware. Callee disposes of rxp. */
+void brcmf_rx_event(struct device *dev, struct sk_buff *rxp);
+/* Notify the bus has transferred the tx packet to firmware */
+void brcmf_txcomplete(struct device *dev, struct sk_buff *txp, bool success);
 void brcmf_net_setcarrier(struct brcmf_if *ifp, bool on);
-void brcmf_c_set_joinpref_default(struct brcmf_if *ifp);
+/* Indication from bus module regarding presence/insertion of dongle. */
+int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings);
+int brcmf_bus_start(struct device *dev);
+void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
+/* Indication from bus module that dongle should be reset */
+void brcmf_dev_reset(struct device *dev);
+/* Indication from bus module regarding removal/absence of dongle */

[PATCH 1/2] brcmfmac: drop unneeded function declarations from headers

[Rafał Miłecki]

From: Rafał Miłecki 

Functions brcmf_c_prec_enq and brcmf_sdio_init don't exist so we
really don't need their declarations. Function brcmf_parse_tlvs is used
in cfg80211.c only so make it static and drop from header as well.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h  | 4 
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h | 2 --
 3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
index e21f760..b5bb971 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bus.h
@@ -218,9 +218,6 @@ int brcmf_bus_get_memdump(struct brcmf_bus *bus, void 
*data, size_t len)
  * interface functions from common layer
  */
 
-bool brcmf_c_prec_enq(struct device *dev, struct pktq *q, struct sk_buff *pkt,
- int prec);
-
 /* Receive frame for delivery to OS.  Callee disposes of rxp. */
 void brcmf_rx_frame(struct device *dev, struct sk_buff *rxp, bool 
handle_event);
 /* Receive async event packet from firmware. Callee disposes of rxp. */
@@ -247,7 +244,6 @@ void brcmf_bus_add_txhdrlen(struct device *dev, uint len);
 
 #ifdef CONFIG_BRCMFMAC_SDIO
 void brcmf_sdio_exit(void);
-void brcmf_sdio_init(void);
 void brcmf_sdio_register(void);
 #endif
 #ifdef CONFIG_BRCMFMAC_USB
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 729bf33..ec1171c 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -326,7 +326,7 @@ u16 channel_to_chanspec(struct brcmu_d11inf *d11inf,
  * triples, returning a pointer to the substring whose first element
  * matches tag
  */
-const struct brcmf_tlv *
+static const struct brcmf_tlv *
 brcmf_parse_tlvs(const void *buf, int buflen, uint key)
 {
const struct brcmf_tlv *elt = buf;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
index 0c9a708..8f19d95 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.h
@@ -396,8 +396,6 @@ void brcmf_free_vif(struct brcmf_cfg80211_vif *vif);
 s32 brcmf_vif_set_mgmt_ie(struct brcmf_cfg80211_vif *vif, s32 pktflag,
  const u8 *vndr_ie_buf, u32 vndr_ie_len);
 s32 brcmf_vif_clear_mgmt_ies(struct brcmf_cfg80211_vif *vif);
-const struct brcmf_tlv *
-brcmf_parse_tlvs(const void *buf, int buflen, uint key);
 u16 channel_to_chanspec(struct brcmu_d11inf *d11inf,
struct ieee80211_channel *ch);
 bool brcmf_get_vif_state_any(struct brcmf_cfg80211_info *cfg,
-- 
2.10.1

[PATCH v2] ath10k: Search SMBIOS for OEM board file extension

[Waldemar Rymarkiewicz]

Board Data File (BDF) is loaded upon driver boot-up procedure. The right
board data file is identified, among others, by device and sybsystem ids.

The problem, however, can occur when the (default) board data file cannot
fulfill with the vendor requirements and it is necessary to use a different
board data file.

To solve the issue QCA uses SMBIOS type 0xF8 to store Board Data File Name
Extension to specify the extension/variant name. The driver will take the
extension suffix into consideration and will load the right (non-default)
board data file if necessary.

If it is unnecessary to use extension board data file, please leave the
SMBIOS field blank and default configuration will be used.

Example:
If a default board data file for a specific board is identified by a string
  "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
   subsystem-device=0310"
then the OEM specific data file, if used, could be identified by variant
suffix:
  "bus=pci,vendor=168c,device=003e,subsystem-vendor=1028,
   subsystem-device=0310,variant=DE_1AB"

Signed-off-by: Waldemar Rymarkiewicz 
---
 drivers/net/wireless/ath/ath10k/core.c | 84 --
 drivers/net/wireless/ath/ath10k/core.h | 19 
 2 files changed, 100 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 874c2a755c66..c2afcca6fd60 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include "core.h"
@@ -707,6 +709,72 @@ static int ath10k_core_get_board_id_from_otp(struct ath10k 
*ar)
return 0;
 }
 
+static void ath10k_core_check_bdfext(const struct dmi_header *hdr, void *data)
+{
+   struct ath10k *ar = data;
+   const char *bdf_ext;
+   const char *magic = ATH10K_SMBIOS_BDF_EXT_MAGIC;
+   u8 bdf_enabled;
+   int i;
+
+   if (hdr->type != ATH10K_SMBIOS_BDF_EXT_TYPE)
+   return;
+
+   if (hdr->length != ATH10K_SMBIOS_BDF_EXT_LENGTH) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "wrong smbios bdf ext type length (%d).\n",
+  hdr->length);
+   return;
+   }
+
+   bdf_enabled = *((u8 *)hdr + ATH10K_SMBIOS_BDF_EXT_OFFSET);
+   if (!bdf_enabled) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT, "bdf variant name not 
found.\n");
+   return;
+   }
+
+   /* Only one string exists (per spec) */
+   bdf_ext = (char *)hdr + hdr->length;
+
+   if (memcmp(bdf_ext, magic, strlen(magic)) != 0) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "bdf variant magic does not match.\n");
+   return;
+   }
+
+   for (i = 0; i < strlen(bdf_ext); i++) {
+   if (!isascii(bdf_ext[i]) || !isprint(bdf_ext[i])) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "bdf variant name contains non ascii 
chars.\n");
+   return;
+   }
+   }
+
+   /* Copy extension name without magic suffix */
+   if (strscpy(ar->id.bdf_ext, bdf_ext + strlen(magic),
+   sizeof(ar->id.bdf_ext)) < 0) {
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "bdf variant string is longer than the buffer can 
accommodate (variant: %s)\n",
+   bdf_ext);
+   return;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_BOOT,
+  "found and validated bdf variant smbios_type 0x%x bdf %s\n",
+  ATH10K_SMBIOS_BDF_EXT_TYPE, bdf_ext);
+}
+
+static int ath10k_core_check_smbios(struct ath10k *ar)
+{
+   ar->id.bdf_ext[0] = '\0';
+   dmi_walk(ath10k_core_check_bdfext, ar);
+
+   if (ar->id.bdf_ext[0] == '\0')
+   return -ENODATA;
+
+   return 0;
+}
+
 static int ath10k_download_and_run_otp(struct ath10k *ar)
 {
u32 result, address = ar->hw_params.patch_load_addr;
@@ -1053,6 +1121,9 @@ static int ath10k_core_fetch_board_data_api_n(struct 
ath10k *ar,
 static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
 size_t name_len)
 {
+   /* strlen(',variant=') + strlen(ar->id.bdf_ext) */
+   char variant[9 + ATH10K_SMBIOS_BDF_EXT_STR_LENGTH];
+
if (ar->id.bmi_ids_valid) {
scnprintf(name, name_len,
  "bus=%s,bmi-chip-id=%d,bmi-board-id=%d",
@@ -1062,12 +1133,15 @@ static int ath10k_core_create_board_name(struct ath10k 
*ar, char *name,
goto out;
}
 
+   if (ar->id.bdf_ext[0] != '\0')
+   scnprintf(variant, sizeof(variant), ",variant=%s",
+ ar->id.bdf_ext);
+
scnprintf(name, name_len,
- 

Re: [4.10, fix, V2] Revert "bcma: init serial console directly from ChipCommon code"

[Kalle Valo]

Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> This reverts commit 4c81acab3816 ("bcma: init serial console directly
> from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
> bcma_core_irq helper on SoC requires MIPS core to be set. It happens
> *after* ChipCommon initialization so we can't do this so early.
> 
> This fixes a user reported regression. It wasn't critical as serial was
> still somehow working but lack of IRQs was making in unreliable.
> 
> Fixes: 4c81acab3816 ("bcma: init serial console directly from ChipCommon 
> code")
> Reported-by: Felix Fietkau 
> Cc: sta...@vger.kernel.org # 4.6+
> Signed-off-by: Rafał Miłecki 

Patch applied to wireless-drivers.git, thanks.

7195439d1d71 Revert "bcma: init serial console directly from ChipCommon code"

-- 
https://patchwork.kernel.org/patch/9515267/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: rtlwifi: rtl8192de: Remove a pointless goto

[Kalle Valo]

Larry Finger  wrote:
> In commit c93ac39da0064 ("rtlwifi: Remove some redundant code), a goto
> statement was inadvertently left in the code.
> 
> Fixes: c93ac39da0064 ("rtlwifi: Remove some redundant code)
> Reported-by: kbuild test robot 
> Signed-off-by: Larry Finger 

Patch applied to wireless-drivers-next.git, thanks.

7f2f61377bca rtlwifi: rtl8192de: Remove a pointless goto

-- 
https://patchwork.kernel.org/patch/9508121/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: mwifiex: debugfs: Fix (sometimes) off-by-1 SSID print

[Kalle Valo]

Brian Norris  wrote:
> Similar to commit fcd2042e8d36 ("mwifiex: printk() overflow with 32-byte
> SSIDs"), we failed to account for the existence of 32-char SSIDs in our
> debugfs code. Unlike in that case though, we zeroed out the containing
> struct first, and I'm pretty sure we're guaranteed to have some padding
> after the 'ssid.ssid' and 'ssid.ssid_len' fields (the struct is 33 bytes
> long).
> 
> So, this is the difference between:
> 
>   # cat /sys/kernel/debug/mwifiex/mlan0/info
>   ...
>   essid="0123456789abcdef0123456789abcdef "
>   ...
> 
> and the correct output:
> 
>   # cat /sys/kernel/debug/mwifiex/mlan0/info
>   ...
>   essid="0123456789abcdef0123456789abcdef"
>   ...
> 
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex 
> driver")
> Signed-off-by: Brian Norris 

Patch applied to wireless-drivers-next.git, thanks.

6183468a23fc mwifiex: debugfs: Fix (sometimes) off-by-1 SSID print

-- 
https://patchwork.kernel.org/patch/9506069/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [V3] brcmfmac: avoid writing channel out of allocated array

[Kalle Valo]

Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Our code was assigning number of channels to the index variable by
> default. If firmware reported channel we didn't predict this would
> result in using that initial index value and writing out of array. This
> never happened so far (we got a complete list of supported channels) but
> it means possible memory corruption so we should handle it anyway.
> 
> This patch simply detects unexpected channel and ignores it.
> 
> As we don't try to create new entry now, it's also safe to drop hw_value
> and center_freq assignment. For known channels we have these set anyway.
> 
> I decided to fix this issue by assigning NULL or a target channel to the
> channel variable. This was one of possible ways, I prefefred this one as
> it also avoids using channel[index] over and over.
> 
> Fixes: 58de92d2f95e ("brcmfmac: use static superset of channels for wiphy 
> bands")
> Signed-off-by: Rafał Miłecki 
> Acked-by: Arend van Spriel 

Patch applied to wireless-drivers-next.git, thanks.

77c0d0cd10e7 brcmfmac: avoid writing channel out of allocated array

-- 
https://patchwork.kernel.org/patch/9496471/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [1/2] brcmfmac: don't preset all channels as disabled

[Kalle Valo]

Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> During init we take care of regulatory stuff by disabling all
> unavailable channels (see brcmf_construct_chaninfo) so this predisabling
> them is not really required (and this patch won't change any behavior).
> It will on the other hand allow more detailed runtime control over
> channels which is the main reason for this change.
> 
> Signed-off-by: Rafał Miłecki 

2 patches applied to wireless-drivers-next.git, thanks.

9ea0c307609f brcmfmac: don't preset all channels as disabled
ab99063f8737 brcmfmac: setup wiphy bands after registering it first

-- 
https://patchwork.kernel.org/patch/9503277/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [1/9] rt2800usb: remove watchdog

[Kalle Valo]

Stanislaw Gruszka  wrote:
> On rt2800usb, if we do not get TX status from HW, we assume frames were
> posted and after entry->last_action timeout, we forcibly provide TX
> status to mac80211. So it's not possible to detect hardware TX hung
> based on the timeout. Additionally TXRQ_PCNT tells on number of frames
> in the Packet Buffer (buffer between bus interface and chip MAC
> subsystem), which can be non zero on normal conditions. To check HW hung
> we will need provide some different mechanism, for now remove watchdog
> as current implementation is wrong and not useful.
> 
> Signed-off-by: Stanislaw Gruszka 

8 patches applied to wireless-drivers-next.git, thanks.

480b468625da rt2800usb: remove watchdog
cfe82fbd8423 rt2800: increase TX timeout
15ec51b25e05 rt2x00: save conf settings before reset tuner
01d97ef4b25f rt2800: change default retry settings
e4019e7f9530 rt2800: tune TX_RTS_CFG config
170122169676 rt2800usb: mark tx failure on timeout
51583248187c rt2x00: do not flush empty queue
66ecec02e851 rt2800: set max_psdu to 3 on usb devices

-- 
https://patchwork.kernel.org/patch/9500917/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: mwifiex: fix uninitialized variable access in pcie_remove

[Kalle Valo]

Arnd Bergmann  wrote:
> Checking the firmware status from PCIe register only works
> if the register is available, otherwise we end up with
> random behavior:
> 
> drivers/net/wireless/marvell/mwifiex/pcie.c: In function 
> 'mwifiex_pcie_remove':
> drivers/net/wireless/marvell/mwifiex/pcie.c:585:5: error: 'fw_status' may be 
> used uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This makes sure we treat the absence of the register as a failure.
> 
> Fixes: 045f0c1b5e26 ("mwifiex: get rid of global user_rmmod flag")
> Signed-off-by: Arnd Bergmann 

Patch applied to wireless-drivers-next.git, thanks.

0e8edb9aed03 mwifiex: fix uninitialized variable access in pcie_remove

-- 
https://patchwork.kernel.org/patch/9515899/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: linux-next: build warning after merge of the wireless-drivers-next tree

[Kalle Valo]

Kalle Valo  writes:

> Stephen Rothwell  writes:
>
>> Hi all,
>>
>> After merging the wireless-drivers-next tree, today's linux-next build
>> (x86_64 allmodconfig) produced this warning:
>>
>> drivers/net/wireless/marvell/mwifiex/pcie.c: In function 
>> 'mwifiex_pcie_remove':
>> drivers/net/wireless/marvell/mwifiex/pcie.c:303:5: warning: 'fw_status' may 
>> be used uninitialized in this function [-Wmaybe-uninitialized]
>>   if (fw_status == FIRMWARE_READY_PCIE && !adapter->mfg_mode) {
>>  ^
>>
>> Introduced by commit
>>
>>   045f0c1b5e26 ("mwifiex: get rid of global user_rmmod flag")
>>
>> This is not a false positive since "reg" could be NULL just above
>> (otherwise it would be tested for).
>
> Thanks, I noticed this myself yesterday (after I had applied the patch)
> and I have asked Marvell to send a fix.

I missed that Arnd had already sent a fix, I'll apply that one:

mwifiex: fix uninitialized variable access in pcie_remove

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

-- 
Kalle Valo

Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c

[Kalle Valo]

Amitkumar Karwar  writes:

> Hi Kalle,
>
>> From: Kalle Valo [mailto:kv...@codeaurora.org]
>> Sent: Thursday, January 12, 2017 8:25 PM
>> To: Amitkumar Karwar
>> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
>> raja...@google.com; briannor...@google.com; dmitry.torok...@gmail.com;
>> Xinming Hu
>> Subject: Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
>> 
>> Amitkumar Karwar  writes:
>> 
>> >> But these didn't. Can you please rebase these and resubmit in one
>> >> patchset? Less conflicts that way.
>> >>
>> >
>> > The problem here is you tried to apply the patches in reverse order.
>> Sorry for the confusion.
>> > Please apply pending patches in below order.
>> >
>> > [v3,1/5] mwifiex: don't wait for main_process in shutdown_drv ---
>> Apply this patch first.
>> > [v3,2/5] mwifiex: do not free firmware dump memory in shutdown_drv
>> > [v3,3/5] mwifiex: get rid of drv_info* adapter variables [v3,4/5]
>> > mwifiex: wait firmware dump complete during card remove process
>> > [v3,5/5] mwifiex: move pcie_work and related variables inside card
>> >
>> > [1/2] mwifiex: code rearrangement in pcie.c and sdio.c [2/2] mwifiex:
>> > get rid of global user_rmmod flag
>> >
>> > mwifiex: use module_*_driver helper macros
>> >
>> > [1/5] mwifiex: get rid of mwifiex_do_flr wrapper [2/5] mwifiex:
>> > cleanup in PCIe flr code path [3/5] mwifiex: sdio card reset
>> > enhancement [4/5] mwifiex: get rid of __mwifiex_sdio_remove helper
>> > [5/5] mwifiex: get rid of global save_adapter and sdio_work
>> 
>> Thanks, now I was able to apply these but please do double check the
>> result in wireless-drivers-next.
>> 
>> I also noticed a new warning:
>> 
>> drivers/net/wireless/marvell/mwifiex/pcie.c: In function
>> 'mwifiex_pcie_remove':
>> drivers/net/wireless/marvell/mwifiex/pcie.c:303:5: warning: 'fw_status'
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>>   if (fw_status == FIRMWARE_READY_PCIE && !adapter->mfg_mode) {
>> 
>> Actually I'm not sure if this warning was caused by these patches as I
>> have recently updated my ancient gcc to a newer one (5.4.0), but please
>> take a look and send a fix if it's a valid warning.
>> 
>
> Below CL fixes this warning.
>
> https://patchwork.kernel.org/patch/9515899/

Good, thanks. I'll apply that shortly.

-- 
Kalle Valo

Re: [PATCH V2] mtd: bcm47xxsflash: use platform_(set|get)_drvdata

[Kalle Valo]

Rafał Miłecki  writes:

> From: Rafał Miłecki 
>
> We have generic place & helpers for storing platform driver data so
> there is no reason for using custom priv pointer.
>
> This allows cleaning up struct bcma_sflash from unneeded fields.
>
> Signed-off-by: Rafał Miłecki 
> ---
> Kalle: This is mtd focused patch, so I guess it should go through mtd tree. Do
>you find bcma change important enough to care to Ack it? :)

Sure :)

Feel free to take the patch via mtd tree, I'm not expecting to see any
conflicts with this patch. For the bcma part:

Acked-by: Kalle Valo 

-- 
Kalle Valo

RE: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c

[Amitkumar Karwar]

Hi Kalle,

> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Thursday, January 12, 2017 8:25 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> raja...@google.com; briannor...@google.com; dmitry.torok...@gmail.com;
> Xinming Hu
> Subject: Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
> 
> Amitkumar Karwar  writes:
> 
> >> But these didn't. Can you please rebase these and resubmit in one
> >> patchset? Less conflicts that way.
> >>
> >
> > The problem here is you tried to apply the patches in reverse order.
> Sorry for the confusion.
> > Please apply pending patches in below order.
> >
> > [v3,1/5] mwifiex: don't wait for main_process in shutdown_drv ---
> Apply this patch first.
> > [v3,2/5] mwifiex: do not free firmware dump memory in shutdown_drv
> > [v3,3/5] mwifiex: get rid of drv_info* adapter variables [v3,4/5]
> > mwifiex: wait firmware dump complete during card remove process
> > [v3,5/5] mwifiex: move pcie_work and related variables inside card
> >
> > [1/2] mwifiex: code rearrangement in pcie.c and sdio.c [2/2] mwifiex:
> > get rid of global user_rmmod flag
> >
> > mwifiex: use module_*_driver helper macros
> >
> > [1/5] mwifiex: get rid of mwifiex_do_flr wrapper [2/5] mwifiex:
> > cleanup in PCIe flr code path [3/5] mwifiex: sdio card reset
> > enhancement [4/5] mwifiex: get rid of __mwifiex_sdio_remove helper
> > [5/5] mwifiex: get rid of global save_adapter and sdio_work
> 
> Thanks, now I was able to apply these but please do double check the
> result in wireless-drivers-next.
> 
> I also noticed a new warning:
> 
> drivers/net/wireless/marvell/mwifiex/pcie.c: In function
> 'mwifiex_pcie_remove':
> drivers/net/wireless/marvell/mwifiex/pcie.c:303:5: warning: 'fw_status'
> may be used uninitialized in this function [-Wmaybe-uninitialized]
>   if (fw_status == FIRMWARE_READY_PCIE && !adapter->mfg_mode) {
> 
> Actually I'm not sure if this warning was caused by these patches as I
> have recently updated my ancient gcc to a newer one (5.4.0), but please
> take a look and send a fix if it's a valid warning.
> 

Below CL fixes this warning.

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

Regards,
Amitkumar