Re: [v5] wlcore: add missing nvs file name info for wilink8

[Tony Lindgren]

* Reizer, Eyal  [170807 00:47]:
> Hi Tony,
> > 
> > * Reizer, Eyal  [170807 00:32]:
> > > The following commits:
> > > c815fde wlcore: spi: Populate config firmware data
> > > d776fc8 wlcore: sdio: Populate config firmware data
> > >
> > > Populated the nvs entry for wilink6 and wilink7 only while it is
> > > still needed for wilink8 as well.
> > > This broke user space backward compatibility when upgrading from older
> > > kernels, as the alternate mac address would not be read from the nvs that
> > is
> > > present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
> > > causing mac address change of the wlan interface.
> > >
> > > This patch fix this and update the structure field with the same default
> > > nvs file name that has been used before.
> > >
> > > In addition, some distros hold a default wl1271-nvs.bin in the file
> > > system with a bogus mac address (deadbeef...) that for a wl18xx device
> > > also overrides the mac address that is stored inside the device.
> > > Warn users about this bogus mac address and use a random mac instead
> > 
> > Hmm looks pretty good to me except for one more thing I just noticed.
> > 
> > Why don't you just use the hardware mac address instead of a random
> > mac address on wl18xx device when you see a bogus nvs file?
> > 
> 
> I agree that this would have been better but the problem is that hardware 
> mac address is available for wilink8 onlyWilink6/7 don't have one stored.
> The wlcore code responsible for handling mac address is common code 
> and there is method for detecting between them in this module.

Care to clarify a bit.. Are you saying wilink8 will use the hardware
mac address in case of bogus nvs file?

Regards,

Tony

[PATCH 1/2] wireless-regdb: Update regulatory document references for Taiwan (TW)

[Chen-Yu Tsai]

Taiwan's Ministry of Transportation and Communications updated its
frequency allocation rules again on 2017/02/22. The amended articles
are not related to this database, but the link should be kept up to
date, as the old one is no longer accessible.

Taiwan's regulatory body, NCC, published its updated technical
regulatory standard for low-power radio frequency devices, LP0002.
The URL has not changed. The new standard opens up more bandwidth
for 5g U-NII WiFi and 60g WiGig devices. Transmission power for
5.25 ~ 5.35 GHz is also increased, but this was already covered
in commit 9a618d9b5fb2 ("wireless-regdb: Update 5 GHz rules for
Taiwan (TW) to follow US").

This patch updates the link and comments for the rules and standards,
and also adds inline comments referencing the governing section of the
LP0002 standard for each band.

Signed-off-by: Chen-Yu Tsai 
---
 db.txt | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/db.txt b/db.txt
index 0bc068e..d96f00e 100644
--- a/db.txt
+++ b/db.txt
@@ -1174,15 +1174,16 @@ country TT: DFS-FCC
(5735 - 5835 @ 80), (30)
 
 # Source:
-# Table of Frequency Allocations of Republic of China (Taiwan) / Nov 2014:
-#   http://www.motc.gov.tw/websitedowndoc?file=post/201411171137330.doc; \
-#  filedisplay=Table+of+radio+frequency+allocation.doc
-# LP0002 Low-power Radio-frequency Devices Technical Regulations / 28 Jun 2011:
+# Table of Frequency Allocations of Republic of China (Taiwan) / Feb 2017:
+#   https://www.motc.gov.tw/websitedowndoc?file=post/201702221012200.doc; \
+#  filedisplay=Table%2Bof%2Bradio%2Bfrequency%2Ballocation.doc
+# LP0002 Low-power Radio-frequency Devices Technical Regulations / 23 Aug 2016:
 #   http://www.ncc.gov.tw/english/show_file.aspx?table_name=news_sn=681
-#   (section 3.10.1, 4.7)
 country TW: DFS-FCC
+   # 2.4g band, LP0002 section 3.10.1
(2400 - 2483.5 @ 40), (30)
-   # Follow US 5.15 ~ 5.25 GHz: 30 dBm for master mode, 23 dBm for clients
+   # 5g U-NII band, LP0002 section 4.7
+   # 5.15 ~ 5.25 GHz: 30 dBm for master mode, 23 dBm for clients
(5150 - 5250 @ 80), (23), AUTO-BW
(5250 - 5350 @ 80), (23), DFS, AUTO-BW
(5470 - 5725 @ 160), (23), DFS
-- 
2.13.3

[PATCH 2/2] wireless-regdb: Add 60 GHz rule for Taiwan (TW)

[Chen-Yu Tsai]

The latest low power radio frequency devices technical regulations [1]
released by Taiwan's regulatory body, NCC, opens up 57 GHz ~ 66 GHz to
most devices, including WiGig.

[1] LP0002 Low-power Radio-frequency Devices Technical Regulations 2016/8/23
http://www.ncc.gov.tw/english/show_file.aspx?table_name=news_sn=681

Signed-off-by: Chen-Yu Tsai 
---
 db.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/db.txt b/db.txt
index d96f00e..e48f9a6 100644
--- a/db.txt
+++ b/db.txt
@@ -1188,6 +1188,8 @@ country TW: DFS-FCC
(5250 - 5350 @ 80), (23), DFS, AUTO-BW
(5470 - 5725 @ 160), (23), DFS
(5725 - 5850 @ 80), (30)
+   # 60g band, LP0002 section 3.13.1.1 (3)(C), EIRP=40dBm(43dBm peak)
+   (57000 - 66000 @ 2160), (40)
  
 country TZ:
(2402 - 2482 @ 40), (20)
-- 
2.13.3

[PATCH v2 0/2] prism54: move to staging

[Luis R. Rodriguez]

Greg,

This v2 adds the TODO you requested to clarify prism54 will be removed in
two kernel releases from now, and so no further cleanup is needed other
than to ensure the driver compiles.

This is based on linux-next tag next-20170807.

  Luis

Luis R. Rodriguez (2):
  wireless: move prism54 out to staging
  MAINTAINERS: update email address for mcgrof for few straggling
drivers

  Luis

 MAINTAINERS  |  8 
 drivers/net/wireless/intersil/Kconfig| 20 
 drivers/net/wireless/intersil/Makefile   |  1 -
 drivers/staging/Kconfig  |  2 ++
 drivers/staging/Makefile |  1 +
 .../wireless/intersil => staging}/prism54/Makefile   |  0
 drivers/staging/prism54/TODO |  5 +
 .../wireless/intersil => staging}/prism54/isl_38xx.c |  0
 .../wireless/intersil => staging}/prism54/isl_38xx.h |  0
 .../intersil => staging}/prism54/isl_ioctl.c |  0
 .../intersil => staging}/prism54/isl_ioctl.h |  0
 .../wireless/intersil => staging}/prism54/isl_oid.h  |  0
 .../intersil => staging}/prism54/islpci_dev.c|  0
 .../intersil => staging}/prism54/islpci_dev.h|  0
 .../intersil => staging}/prism54/islpci_eth.c|  0
 .../intersil => staging}/prism54/islpci_eth.h|  0
 .../intersil => staging}/prism54/islpci_hotplug.c|  0
 .../intersil => staging}/prism54/islpci_mgt.c|  0
 .../intersil => staging}/prism54/islpci_mgt.h|  0
 .../wireless/intersil => staging}/prism54/oid_mgt.c  |  0
 .../wireless/intersil => staging}/prism54/oid_mgt.h  |  0
 .../intersil => staging}/prism54/prismcompat.h   |  0
 22 files changed, 12 insertions(+), 25 deletions(-)
 rename drivers/{net/wireless/intersil => staging}/prism54/Makefile (100%)
 create mode 100644 drivers/staging/prism54/TODO
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_oid.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_hotplug.c 
(100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/prismcompat.h (100%)

-- 
2.11.0

[PATCH v2 2/2] MAINTAINERS: update email address for mcgrof for few straggling drivers

[Luis R. Rodriguez]

This will ensure I get emails on my work and personal email address.

Signed-off-by: Luis R. Rodriguez 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3deaddc8c578..997b8062397a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2212,7 +2212,7 @@ F:drivers/gpio/gpio-ath79.c
 F: Documentation/devicetree/bindings/gpio/gpio-ath79.txt
 
 ATHEROS ATH GENERIC UTILITIES
-M: "Luis R. Rodriguez" 
+M: "Luis R. Rodriguez" 
 L: linux-wireless@vger.kernel.org
 S: Supported
 F: drivers/net/wireless/ath/*
@@ -2220,7 +2220,7 @@ F:drivers/net/wireless/ath/*
 ATHEROS ATH5K WIRELESS DRIVER
 M: Jiri Slaby 
 M: Nick Kossifidis 
-M: "Luis R. Rodriguez" 
+M: "Luis R. Rodriguez" 
 L: linux-wireless@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/ath5k
 S: Maintained
-- 
2.11.0

[PATCH v2 1/2] wireless: move prism54 out to staging

[Luis R. Rodriguez]

prism54 is deprecated in favor of the p54pci device driver. Although
only *one soul* had reported issues with it long ago Linux most Linux
distributions these days just disable the device driver given the
conflicts with the PCI IDs of p54pci and the *very* unlikely situation
of folks really need this driver anymore.

Before trying to due away with prism54 once more stuff it into staging,
which is our hospice for dying drivers.

Acked-by: Kalle Valo 
Signed-off-by: Luis R. Rodriguez 
---
 MAINTAINERS  |  4 ++--
 drivers/net/wireless/intersil/Kconfig| 20 
 drivers/net/wireless/intersil/Makefile   |  1 -
 drivers/staging/Kconfig  |  2 ++
 drivers/staging/Makefile |  1 +
 .../wireless/intersil => staging}/prism54/Makefile   |  0
 drivers/staging/prism54/TODO |  5 +
 .../wireless/intersil => staging}/prism54/isl_38xx.c |  0
 .../wireless/intersil => staging}/prism54/isl_38xx.h |  0
 .../intersil => staging}/prism54/isl_ioctl.c |  0
 .../intersil => staging}/prism54/isl_ioctl.h |  0
 .../wireless/intersil => staging}/prism54/isl_oid.h  |  0
 .../intersil => staging}/prism54/islpci_dev.c|  0
 .../intersil => staging}/prism54/islpci_dev.h|  0
 .../intersil => staging}/prism54/islpci_eth.c|  0
 .../intersil => staging}/prism54/islpci_eth.h|  0
 .../intersil => staging}/prism54/islpci_hotplug.c|  0
 .../intersil => staging}/prism54/islpci_mgt.c|  0
 .../intersil => staging}/prism54/islpci_mgt.h|  0
 .../wireless/intersil => staging}/prism54/oid_mgt.c  |  0
 .../wireless/intersil => staging}/prism54/oid_mgt.h  |  0
 .../intersil => staging}/prism54/prismcompat.h   |  0
 22 files changed, 10 insertions(+), 23 deletions(-)
 rename drivers/{net/wireless/intersil => staging}/prism54/Makefile (100%)
 create mode 100644 drivers/staging/prism54/TODO
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_38xx.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_ioctl.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/isl_oid.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_dev.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_eth.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_hotplug.c 
(100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/islpci_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.c (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/oid_mgt.h (100%)
 rename drivers/{net/wireless/intersil => staging}/prism54/prismcompat.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 672b5d5402f0..3deaddc8c578 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10674,11 +10674,11 @@ F:kernel/printk/
 F: include/linux/printk.h
 
 PRISM54 WIRELESS DRIVER
-M: "Luis R. Rodriguez" 
+M: "Luis R. Rodriguez" 
 L: linux-wireless@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/p54
 S: Obsolete
-F: drivers/net/wireless/intersil/prism54/
+F: drivers/staging/prism54/
 
 PROC SYSCTL
 M: "Luis R. Rodriguez" 
diff --git a/drivers/net/wireless/intersil/Kconfig 
b/drivers/net/wireless/intersil/Kconfig
index 9da136049955..2b056b6daef8 100644
--- a/drivers/net/wireless/intersil/Kconfig
+++ b/drivers/net/wireless/intersil/Kconfig
@@ -15,24 +15,4 @@ source "drivers/net/wireless/intersil/hostap/Kconfig"
 source "drivers/net/wireless/intersil/orinoco/Kconfig"
 source "drivers/net/wireless/intersil/p54/Kconfig"
 
-config PRISM54
-   tristate 'Intersil Prism GT/Duette/Indigo PCI/Cardbus (DEPRECATED)'
-   depends on PCI
-   select WIRELESS_EXT
-   select WEXT_SPY
-   select WEXT_PRIV
-   select FW_LOADER
-   ---help---
- This enables support for FullMAC PCI/Cardbus prism54 devices. This
- driver is now deprecated in favor for the SoftMAC driver, p54pci.
- p54pci supports FullMAC PCI/Cardbus devices as well.
-
- For more information refer to the p54 wiki:
-
- http://wireless.kernel.org/en/users/Drivers/p54
-
- Note: You need a motherboard with DMA support to use any of these 
cards
-
- When built as module you get the module prism54
-
 endif # WLAN_VENDOR_INTERSIL
diff --git a/drivers/net/wireless/intersil/Makefile 

Re: Problem with the wifi

[Arend van Spriel]

+ linux-wireless

On 07-08-17 21:38, Paolo Bettini wrote:
> Hi , i am Paolo and i installed Debian stretch on my ezbook2 . One
> problem is the wifi , the card a SDIO device , seems to be 02d0:a9a6
> linux id or Broadcom AP6212 for windowsi installed deb package
> firmware-brcm80211 and nvram sdio txt in /lib/firmware/brcm, reloaded
> bcrmfmac module but nothing the card seems invisible or dead i don't
> know if is a problem of firmware or my system cannot detect the sdio
> card ...do you know something about this problematic ?

As always a kernel log could help or output from dmesg command. Also can
you run following commands:

$ ls /sys/bus/sdio/devices
$ cat /sys/bus/sdio/devices/*/modalias

Regards,
Arend

Re: [PATCH 13/34] brcmfmac: Tidy register definitions a little

[Arend van Spriel]

On 26-07-17 22:25, Ian Molton wrote:
> Trivial tidy of register definitions.

Initially skipped this one, but it is indeed trivial.

Reviewed-by: Arend van Spriel 
> Signed-off-by: Ian Molton 

comment below...

> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
> index 4c81ea24d19c..fb4f24dfc99d 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
> @@ -51,17 +51,18 @@
>  
>  /* function 0 vendor specific CCCR registers */
>  
> -#define SDIO_CCCR_BRCM_CARDCAP   0xf0
> +#define SDIO_CCCR_BRCM_CARDCAP   0xf0
>  #define SDIO_CCCR_BRCM_CARDCAP_CMD14_SUPPORT 0x02
>  #define SDIO_CCCR_BRCM_CARDCAP_CMD14_EXT 0x04
>  #define SDIO_CCCR_BRCM_CARDCAP_CMD_NODEC 0x08
> +
>  #define SDIO_CCCR_BRCM_CARDCTRL  0xf1
>  #define SDIO_CCCR_BRCM_CARDCTRL_WLANRESET0x02
> -#define SDIO_CCCR_BRCM_SEPINT0xf2
>  
> -#define  SDIO_SEPINT_MASK0x01
> -#define  SDIO_SEPINT_OE  0x02
> -#define  SDIO_SEPINT_ACT_HI  0x04
> +#define SDIO_CCCR_BRCM_SEPINT0xf2
> +#define SDIO_SEPINT_MASK 0x01
> +#define SDIO_SEPINT_OE   0x02
> +#define SDIO_SEPINT_ACT_HI   0x04

So the SEPINT definitions are not consistent with the other ones. Maybe
drop the SDIO_CCCR from the other value definitions and for the SEPINT
replace 'SDIO_' with 'SEPINT_'.

Re: pull-request: wireless-drivers-next 2017-08-07

[David Miller]

From: Kalle Valo 
Date: Mon, 07 Aug 2017 17:55:40 +0300

> here's the first pull request to net-next for 4.14, more info in the
> signed tag below. This time there's a simple conflict in iwlwifi but
> you can fix it just like Stephen did:
> 
> https://lkml.kernel.org/r/20170804120408.0d147...@canb.auug.org.au
> 
> Please let me know if you have any problems.

Pulled, thanks Kalle.

Re: [PATCH 12/34] brcmfmac: Replace old IO functions with simpler ones.

[Ian Molton]

On 07/08/17 12:26, Arend van Spriel wrote:
> On 7/26/2017 10:25 PM, Ian Molton wrote:
>> Primarily this patch removes:
>>
>> brcmf_sdiod_f0_writeb()
>> brcmf_sdiod_reg_write()
>> brcmf_sdiod_reg_read()
> 
> Having [patch 30/34] "brcmfmac: Correctly handle accesses to SDIO func0"
> before this patch could make this look cleaner.

This is an artifact of how I came to the realisation the code was using
the obsoleted functions - it could be reordered, but it'd probably get
messy...

>> Since we no longer use the quirky method of deciding which function to
>> address via the address being accessed, take the opportunity to rename
>> some IO functions more in line with common kernel code.
> 
> As mentioned here this is more a rename than a replace so please use
> that in the subject as well.

Noted.

> Reviewed-by: Arend van Spriel 
>> Signed-off-by: Ian Molton 
>> ---
>>   .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 166
>> +++
>>   .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 182
>> ++---
>>   .../wireless/broadcom/brcm80211/brcmfmac/sdio.h|  28 +++-
>>   3 files changed, 132 insertions(+), 244 deletions(-)
> 

-Ian

Re: [PATCH 07/34] brcmfmac: Remove brcmf_sdiod_request_data()

[Ian Molton]

On 07/08/17 12:25, Arend van Spriel wrote:
>> Handling of -ENOMEDIUM is altered, but as that's pretty much broken
>> anyway
>> we can ignore that.
> 
> Please explain why you think it is broken.

Not got the code to hand right now, but from memory, theres a trapdoor
case where the state can wind up set to something that prevents it ever
being changed again. I'll dig it up when I get back from holiday (this
next few days).

-Ian

Re: [PATCH 03/34] brcmfmac: Split brcmf_sdiod_regrw_helper() up.

[Ian Molton]

On 07/08/17 12:25, Arend van Spriel wrote:
> On 26-07-17 22:25, Ian Molton wrote:
>> This large function is concealing a LOT of obscure logic about
>> how the hardware functions. Time to split it up.
>>
>> This first patch splits the function into two pieces - read and write,
>> doing away with the rw flag in the process.
> 
> I really don't this it is all that obscure, but alas. Everything is in
> the eye of the beholder. The reason for having the helper was to not
> duplicate code for read and write and different access sizes. So now you
> are duplicating it. In subsequent patches you throw away pieces of this
> helper so duplication is not as bad in the net result. It would have
> been easier if those patches were done before this one.

I agree, this is a big and unwieldy patchset - I've attempted to break
the thing down in such a way that all the steps leading to the end
result are at least sane. I initially did it all in one hit and it was
utterly illegible :-(


> Fix the indent and column align to opening bracket.

I guess a few of these got through. I blame git rebase :)

-Ian

Re: [PATCH v2] rt2x00: Fix MMIC Countermeasures.

[Michael Skeffington]

Sorry about that, I work on other projects that use spaces and I must have
missed that when double checking the patch.  I sent out a new patch with
the correct line length, removal of trailing '.' and indentation fix.

On Mon, Aug 7, 2017 at 2:31 AM, Stanislaw Gruszka  wrote:
> On Thu, Aug 03, 2017 at 11:31:21AM -0400, Michael Skeffingfon wrote:
>> @@ -136,10 +136,19 @@ void rt2800mmio_fill_rxdone(struct queue_entry *entry,
>>*/
>>   rxdesc->flags |= RX_FLAG_MMIC_STRIPPED;
>>
>> - if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS)
>> + if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) {
>>   rxdesc->flags |= RX_FLAG_DECRYPTED;
>> - else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC)
>> +} else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) {
>
> Not sure why this happened, but here and on some other places below,
> tab was replaced by spaces resulting in wrong indent.
>
> Stanislaw

[PATCH v3] rt2x00: Fix MMIC Countermeasures

[Michael Skeffingfon]

Set RX_FLAG_DECRYPTED in case of MMIC failure so that
ieee80211_rx_h_decrypt() doesnt drop the frame before getting to
ieee80211_rx_h_michael_mic_verify().

Signed-off-by: Michael Skeffington 

---
 drivers/net/wireless/ralink/rt2x00/rt2800mmio.c | 13 +++--
 drivers/net/wireless/ralink/rt2x00/rt2800usb.c  | 15 ---
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
index ee5276e233fa..1123e2bed803 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800mmio.c
@@ -136,10 +136,19 @@ void rt2800mmio_fill_rxdone(struct queue_entry *entry,
 */
rxdesc->flags |= RX_FLAG_MMIC_STRIPPED;
 
-   if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS)
+   if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) {
rxdesc->flags |= RX_FLAG_DECRYPTED;
-   else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC)
+   } else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) {
+   /*
+* In order to check the Michael Mic, the packet must 
have
+* been decrypted.  Mac80211 doesnt check the MMIC 
failure 
+* flag to initiate MMIC countermeasures if the decoded 
flag
+* has not been set.
+*/
+   rxdesc->flags |= RX_FLAG_DECRYPTED;
+
rxdesc->flags |= RX_FLAG_MMIC_ERROR;
+   }
}
 
if (rt2x00_get_field32(word, RXD_W3_MY_BSS))
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c 
b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
index 685b8e0cd67d..3e5d3a40d986 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800usb.c
@@ -697,11 +697,20 @@ static void rt2800usb_fill_rxdone(struct queue_entry 
*entry,
 * stripped it from the frame. Signal this to mac80211.
 */
rxdesc->flags |= RX_FLAG_MMIC_STRIPPED;
-
-   if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS)
+
+   if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) {
+   rxdesc->flags |= RX_FLAG_DECRYPTED;
+   } else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) {
+   /*
+* In order to check the Michael Mic, the packet must 
have
+* been decrypted.  Mac80211 doesnt check the MMIC 
failure 
+* flag to initiate MMIC countermeasures if the decoded 
flag
+* has not been set.
+*/
rxdesc->flags |= RX_FLAG_DECRYPTED;
-   else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC)
+
rxdesc->flags |= RX_FLAG_MMIC_ERROR;
+   }
}
 
if (rt2x00_get_field32(word, RXD_W0_MY_BSS))
-- 
2.11.0

pull-request: wireless-drivers-next 2017-08-07

[Kalle Valo]

Hi Dave,

here's the first pull request to net-next for 4.14, more info in the
signed tag below. This time there's a simple conflict in iwlwifi but
you can fix it just like Stephen did:

https://lkml.kernel.org/r/20170804120408.0d147...@canb.auug.org.au

Please let me know if you have any problems.

Kalle

The following changes since commit 53d56f79a0b2e4bc5bbc04988e5bfde768db604f:

  Merge branch 'qed-next' (2017-07-27 00:05:23 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git 
tags/wireless-drivers-next-for-davem-2017-08-07

for you to fetch changes up to 9d546198705a79630cb29b1cc47a43e75b8afb89:

  rtlwifi: Replace hardcode value with macro (2017-08-03 13:20:43 +0300)


wireless-drivers-next patches for 4.14

The first wireless-drivers-next pull request for 4.14. I'm submitting
this unusally late in the cycle as my vacation postponed this. But
even if this is late there's not still that much new features, mostly
cleanup or fixes.

Major changes:

ath10k

* preparation for wcn3990 support

iwlwifi

* Reorganization of the code into separate directories continues

qtnfmac

* regulatory support updates

* add get_channel, dump_survey and channel_switch cfg80211 handlers


Amitkumar Karwar (5):
  rsi: use BUILD_BUG_ON check for fsm_state
  rsi: correct the logic of deriving queue number
  rsi: use macro for allocating USB buffer
  rsi: check length before USB read/write register
  rsi: fix static checker warning

Arvind Yadav (9):
  brcmfmac: constify pci_device_id
  rtlwifi: rtl8192de: constify pci_device_id.
  rtlwifi: rtl8192se: constify pci_device_id.
  rtlwifi: rtl8821ae: constify pci_device_id.
  rtlwifi: rtl8723ae: constify pci_device_id.
  rtlwifi: rtl8723be: constify pci_device_id.
  rtlwifi: rtl8188ee: constify pci_device_id.
  rtlwifi: rtl8192ee: constify pci_device_id.
  net: qtnfmac: constify pci_device_id.

Brian Norris (21):
  mwifiex: correct channel stat buffer overflows
  mwifiex: reunite copy-and-pasted remove/reset code
  mwifiex: reset interrupt status across device reset
  mwifiex: pcie: don't allow cmd buffer reuse after reset
  mwifiex: re-register wiphy across reset
  mwifiex: unregister wiphy before freeing resources
  mwifiex: don't short-circuit netdev notifiers on interface deletion
  mwifiex: fixup init_channel_scan_gap error case
  mwifiex: ensure "disable auto DS" struct is initialized
  mwifiex: fix misnomers in mwifiex_free_lock_list()
  mwifiex: make mwifiex_free_cmd_buffer() return void
  mwifiex: utilize netif_tx_{wake,stop}_all_queues()
  mwifiex: don't open-code ARRAY_SIZE()
  mwifiex: drop 'add_tail' param from mwifiex_insert_cmd_to_pending_q()
  mwifiex: pcie: remove unnecessary masks
  mwifiex: pcie: unify MSI-X / non-MSI-X interrupt process
  mwifiex: debugfs: allow card_reset() to cancel things
  mwifiex: pcie: disable device DMA before unmapping/freeing buffers
  mwifiex: pcie: remove unnecessary 'pdev' check
  mwifiex: keep mwifiex_cancel_pending_ioctl() static
  mwifiex: drop num CPU notice

Colin Ian King (5):
  rtlwifi: kfree entry until after entry->bssid has been accessed
  mwifiex: usb: fix spelling mistake: "aggreataon"-> "aggregation"
  mwifiex: fix spelling mistake: "Insuffient" -> "Insufficient"
  zd1211rw: fix spelling mistake 'hybernate' -> 'hibernate'
  wl3501_cs: fix spelling mistake: "Insupported" -> "Unsupported"

Cong Wang (1):
  wl1251: add a missing spin_lock_init()

Dan Carpenter (2):
  mwifiex: usb: unlock on error in mwifiex_usb_tx_aggr_tmo()
  rtlwifi: rtl8821ae: Fix HW_VAR_NAV_UPPER operation

Dan Williams (1):
  ipw2100: don't return positive values to PCI probe on error

Emmanuel Grumbach (3):
  iwlwifi: mvm: fix the FIFO numbers in A000 devices
  iwlwifi: pcie: fix A-MSDU on gen2 devices
  iwlwifi: mvm: don't retake the pointer to skb's CB

Florian Fainelli (1):
  bcma: gpio: Correct number of GPIOs for BCM53573

Govind Singh (2):
  ath10k: make CE layer bus agnostic
  ath10k: add copy engine register MAP for wcn3990 target

Jeffy Chen (1):
  mwifiex: uninit wakeup info in the error handling

Johannes Berg (13):
  iwlwifi: refactor out paging code
  iwlwifi: refactor shared mem parsing
  iwlwifi: track current firmware image in common code
  iwlwifi: refactor firmware debug code
  iwlwifi: reorganize firmware API
  iwlwifi: fw api: fix various kernel-doc warnings
  iwlwifi: mvm: add and use iwl_mvm_has_unified_ucode()
  iwlwifi: mvm: check family instead of new TX API for workarounds
  iwlwifi: mvm: byte-swap constant instead of variable
  iwlwifi: pcie: rename iwl_trans_check_hw_rf_kill() to 

Re: [PATCH 1/3] iwlwifi: mvm: Fix a memory leak in an error handling path in 'iwl_mvm_sar_get_wgds_table()'

[Luca Coelho]

On Mon, 2017-08-07 at 16:37 +0300, Kalle Valo wrote:
> Luca Coelho  writes:
> 
> > On Mon, 2017-08-07 at 15:57 +0300, Kalle Valo wrote:
> > > Luca Coelho  writes:
> > > 
> > > > From: Christophe Jaillet 
> > > > 
> > > > We should free 'wgds.pointer' here as done a few lines above in another
> > > > error handling path.
> > > > It was allocated within 'acpi_evaluate_object()'.
> > > > 
> > > > Fixes: c52030a01ccc ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for 
> > > > geographic tx power table")
> > > > Signed-off-by: Christophe JAILLET 
> > > > Signed-off-by: Luca Coelho 
> > > > ---
> > > >  drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 --
> > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c 
> > > > b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> > > > index 79e7a7a285dc..82863e9273eb 100644
> > > > --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> > > > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> > > > @@ -1275,8 +1275,10 @@ static int iwl_mvm_sar_get_wgds_table(struct 
> > > > iwl_mvm *mvm)
> > > >  
> > > > entry = _pkg->package.elements[idx++];
> > > > if ((entry->type != ACPI_TYPE_INTEGER) ||
> > > > -   (entry->integer.value > U8_MAX))
> > > > -   return -EINVAL;
> > > > +   (entry->integer.value > U8_MAX)) {
> > > > +   ret = -EINVAL;
> > > > +   goto out_free;
> > > > +   }
> > > 
> > > How likely is this leak to happen in real world? To me it looks like
> > > more like a theoretical issue and could have easily waited for 4.14. But
> > > it's fine this time, just something to keep in mind in the future.
> > 
> > This is a one-liner fix and I consider memory leaks serious enough to
> > deserve a fix for rc5.  This bug can happen with broken ACPI tables and,
> > trust me, broken ACPI tables are not that hard to find.
> 
> Sure, anything's possible. But what I'm reading here this is still a
> theoretical issue, not a leak which we _know_ will happen to thousands
> of people.
> 
> > But you rule here, feel free to NACK my patches whenever you see fit! :)
> 
> I'm trying to minimise the numbers of patches going to wireless-drivers
> and striving for only fixes which really matter and keep the theoretical
> stuff for -next. The is mostly selfish reasons as wireless-drivers are a
> lot more work, especially if there are conflicts.

I totally understand.  It's a lot more work for me too, with all the
reordering I need to do and the conflicts these cause.


> But like I said in my previous mail, no need to drop this.

Okay, thanks!

--
Cheers,
Luca.

Re: [PATCH 1/3] iwlwifi: mvm: Fix a memory leak in an error handling path in 'iwl_mvm_sar_get_wgds_table()'

[Kalle Valo]

Luca Coelho  writes:

> On Mon, 2017-08-07 at 15:57 +0300, Kalle Valo wrote:
>> Luca Coelho  writes:
>> 
>> > From: Christophe Jaillet 
>> > 
>> > We should free 'wgds.pointer' here as done a few lines above in another
>> > error handling path.
>> > It was allocated within 'acpi_evaluate_object()'.
>> > 
>> > Fixes: c52030a01ccc ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for 
>> > geographic tx power table")
>> > Signed-off-by: Christophe JAILLET 
>> > Signed-off-by: Luca Coelho 
>> > ---
>> >  drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 --
>> >  1 file changed, 4 insertions(+), 2 deletions(-)
>> > 
>> > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c 
>> > b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
>> > index 79e7a7a285dc..82863e9273eb 100644
>> > --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
>> > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
>> > @@ -1275,8 +1275,10 @@ static int iwl_mvm_sar_get_wgds_table(struct 
>> > iwl_mvm *mvm)
>> >  
>> >entry = _pkg->package.elements[idx++];
>> >if ((entry->type != ACPI_TYPE_INTEGER) ||
>> > -  (entry->integer.value > U8_MAX))
>> > -  return -EINVAL;
>> > +  (entry->integer.value > U8_MAX)) {
>> > +  ret = -EINVAL;
>> > +  goto out_free;
>> > +  }
>> 
>> How likely is this leak to happen in real world? To me it looks like
>> more like a theoretical issue and could have easily waited for 4.14. But
>> it's fine this time, just something to keep in mind in the future.
>
> This is a one-liner fix and I consider memory leaks serious enough to
> deserve a fix for rc5.  This bug can happen with broken ACPI tables and,
> trust me, broken ACPI tables are not that hard to find.

Sure, anything's possible. But what I'm reading here this is still a
theoretical issue, not a leak which we _know_ will happen to thousands
of people.

> But you rule here, feel free to NACK my patches whenever you see fit! :)

I'm trying to minimise the numbers of patches going to wireless-drivers
and striving for only fixes which really matter and keep the theoretical
stuff for -next. The is mostly selfish reasons as wireless-drivers are a
lot more work, especially if there are conflicts.

But like I said in my previous mail, no need to drop this.

-- 
Kalle Valo

Re: [PATCH 04/19] iwlwifi: mvm: add debugfs to force CT-kill

[Kalle Valo]

Luca Coelho  writes:

> On Mon, 2017-08-07 at 16:11 +0300, Kalle Valo wrote:
>> Luca Coelho  writes:
>> 
>> > From: Chaya Rachel Ivgi 
>> > 
>> > In order to test the enter/exit CT-kill flow.
>> > 
>> > Signed-off-by: Chaya Rachel Ivgi 
>> > Signed-off-by: Luca Coelho 
>> 
>> The commit log doesn't explain what's CT-kill and how/where it could be
>> used. For example, I have no clue what this could be about.
>
> You're right, sorry for that.  I'll update the commit log and submit v2.
>
> Basically CT-kill is a thermal "RF-kill".  Whenever the NIC gets too
> hot, we shut it down to prevent further damage.  This is nothing new. 
> What this patch is adding is a fake way to simulate the NIC getting too
> hot by kicking off a debugfs entry, in the same way the FW would kick it
> off by sending a notification to the driver.
>
> This is mostly for R, but it's very useful for us and I we need it for
> our internal tests.  Not that useful for non-developers but I didn't
> want to carry this in internal driver to avoid unnecessary conflicts
> when syncing it with upstream.

Thanks, makes sense now.

-- 
Kalle Valo

Re: [PATCH 04/19] iwlwifi: mvm: add debugfs to force CT-kill

[Luca Coelho]

On Mon, 2017-08-07 at 16:11 +0300, Kalle Valo wrote:
> Luca Coelho  writes:
> 
> > From: Chaya Rachel Ivgi 
> > 
> > In order to test the enter/exit CT-kill flow.
> > 
> > Signed-off-by: Chaya Rachel Ivgi 
> > Signed-off-by: Luca Coelho 
> 
> The commit log doesn't explain what's CT-kill and how/where it could be
> used. For example, I have no clue what this could be about.

You're right, sorry for that.  I'll update the commit log and submit v2.

Basically CT-kill is a thermal "RF-kill".  Whenever the NIC gets too
hot, we shut it down to prevent further damage.  This is nothing new. 
What this patch is adding is a fake way to simulate the NIC getting too
hot by kicking off a debugfs entry, in the same way the FW would kick it
off by sending a notification to the driver.

This is mostly for R, but it's very useful for us and I we need it for
our internal tests.  Not that useful for non-developers but I didn't
want to carry this in internal driver to avoid unnecessary conflicts
when syncing it with upstream.

--
Luca.

Re: [PATCH 12/19] iwlwifi: mvm: support new beacon template command

[Kalle Valo]

Luca Coelho  writes:

> From: Haim Dreyfuss 
>
> Support new version of beacon template command. This rplaces v8 command

typo: "rplaces"

-- 
Kalle Valo

Re: [PATCH 1/3] iwlwifi: mvm: Fix a memory leak in an error handling path in 'iwl_mvm_sar_get_wgds_table()'

[Luca Coelho]

On Mon, 2017-08-07 at 15:57 +0300, Kalle Valo wrote:
> Luca Coelho  writes:
> 
> > From: Christophe Jaillet 
> > 
> > We should free 'wgds.pointer' here as done a few lines above in another
> > error handling path.
> > It was allocated within 'acpi_evaluate_object()'.
> > 
> > Fixes: c52030a01ccc ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for 
> > geographic tx power table")
> > Signed-off-by: Christophe JAILLET 
> > Signed-off-by: Luca Coelho 
> > ---
> >  drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c 
> > b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> > index 79e7a7a285dc..82863e9273eb 100644
> > --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> > @@ -1275,8 +1275,10 @@ static int iwl_mvm_sar_get_wgds_table(struct iwl_mvm 
> > *mvm)
> >  
> > entry = _pkg->package.elements[idx++];
> > if ((entry->type != ACPI_TYPE_INTEGER) ||
> > -   (entry->integer.value > U8_MAX))
> > -   return -EINVAL;
> > +   (entry->integer.value > U8_MAX)) {
> > +   ret = -EINVAL;
> > +   goto out_free;
> > +   }
> 
> How likely is this leak to happen in real world? To me it looks like
> more like a theoretical issue and could have easily waited for 4.14. But
> it's fine this time, just something to keep in mind in the future.

This is a one-liner fix and I consider memory leaks serious enough to
deserve a fix for rc5.  This bug can happen with broken ACPI tables and,
trust me, broken ACPI tables are not that hard to find.

But you rule here, feel free to NACK my patches whenever you see fit! :)

--
Cheers,
Luca.

Re: [PATCH 04/19] iwlwifi: mvm: add debugfs to force CT-kill

[Kalle Valo]

Luca Coelho  writes:

> From: Chaya Rachel Ivgi 
>
> In order to test the enter/exit CT-kill flow.
>
> Signed-off-by: Chaya Rachel Ivgi 
> Signed-off-by: Luca Coelho 

The commit log doesn't explain what's CT-kill and how/where it could be
used. For example, I have no clue what this could be about.

-- 
Kalle Valo

Re: [PATCH 00/10] mac80211 patches from our internal tree 2017-08-05

[Kalle Valo]

Luca Coelho  writes:

> On Mon, 2017-08-07 at 12:06 +0300, Kalle Valo wrote:
>> Luca Coelho  writes:
>> 
>> > Here are some pending mac80211 patches from our internal tree.
>> > 
>> > The "mac80211: add api to start ba session timer expired flow" patch
>> > is needed by an iwlwifi patch that I want to send for -fixes, so it
>> > would have to be applied to -fixes as well.
>> 
>> We are getting to the later stages of the release cycle and I'm raising
>> the bar for wireless-drivers even higher. How serious iwlwifi bug is
>> that fixing?
>
> The problem is a bad degradation in throughput with our new 9000 family
> of devices because when aggregation times out we stop the aggregation
> internally in the firmware but don't send a delba.  Then on the AP side,
>  also with our driver, we don't handle the timeout as we should, so
> aggregations the devices get out of sync and BA sessions are not
> possible anymore, limiting our throughput to ~30Mbps, in some specific
> internal tests.

Ok.

>> > Should I send a separate patchset with these two so they can be both
>> > applied at the same time (either in the mac80211 or in
>> > wireless-drivers tree)?
>> 
>> Now that Johannes is away and I'm taking any urgent mac80211 patches, I
>> think the best approach is that you include mac80211 patch in the same
>> patchset as the iwlwifi patches destined for wireless-drivers.
>
> Okay, if you think the (one-liner) iwlwifi driver fix is -rc'able, I'll
> resend this in a patchset including both changes.

If the iwlwifi patch is a oneliner it doesn't sound too bad, but I
reserve the right to change my mind :)

But try to submit the pull request in the next few days so that I can
submit the patches forward by end of this week. And I think it's easiest
that you apply the mac80211 patch directly to your tree and I just pull
from you.

-- 
Kalle Valo

Re: [PATCH 2/3] iwlwifi: mvm: start mac queues when deferred tx frames are purged

[Kalle Valo]

Luca Coelho  writes:

> From: Avraham Stern 
>
> Under DQA, when tx is deferred because a queue needs to be allocated,
> the mac queue for that TID is stopped until the new stream is added.
> If at this point the station that this stream belongs to is removed,
> all the deferred tx frames are purged, but the mac queue is not
> restarted. As a result, all following tx on this queue will not be
> transmitted.
>
> Fix this by starting the relevant mac queues when the deferred tx
> frames are purged.
>
> Fixes: 24afba7690e4 ("iwlwifi: mvm: support bss dynamic alloc/dealloc of 
> queues")
> Signed-off-by: Avraham Stern 
> Signed-off-by: Luca Coelho 

The commit log is not really explaining the bug from user's point of
view.

-- 
Kalle Valo

Re: [PATCH 1/3] iwlwifi: mvm: Fix a memory leak in an error handling path in 'iwl_mvm_sar_get_wgds_table()'

[Kalle Valo]

Luca Coelho  writes:

> From: Christophe Jaillet 
>
> We should free 'wgds.pointer' here as done a few lines above in another
> error handling path.
> It was allocated within 'acpi_evaluate_object()'.
>
> Fixes: c52030a01ccc ("iwlwifi: mvm: add GEO_TX_POWER_LIMIT cmd for geographic 
> tx power table")
> Signed-off-by: Christophe JAILLET 
> Signed-off-by: Luca Coelho 
> ---
>  drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c 
> b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> index 79e7a7a285dc..82863e9273eb 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> @@ -1275,8 +1275,10 @@ static int iwl_mvm_sar_get_wgds_table(struct iwl_mvm 
> *mvm)
>  
>   entry = _pkg->package.elements[idx++];
>   if ((entry->type != ACPI_TYPE_INTEGER) ||
> - (entry->integer.value > U8_MAX))
> - return -EINVAL;
> + (entry->integer.value > U8_MAX)) {
> + ret = -EINVAL;
> + goto out_free;
> + }

How likely is this leak to happen in real world? To me it looks like
more like a theoretical issue and could have easily waited for 4.14. But
it's fine this time, just something to keep in mind in the future.

-- 
Kalle Valo

Re: [PATCH] brcmfmac: add setting carrier state ON for successful roaming

[Arend van Spriel]

On 8/7/2017 10:16 AM, Wright Feng wrote:

From: Chung-Hsien Hsu 

After association, ping is not working when sweeping the channel at the
AP side. It is caused by having incorrect carrier state (OFF) for the STA
in successful roaming. This patch sets the carrier state ON for the case.


This seems a specific scenario where the initial connect attempt by the 
host actually results in the firmware roaming, ie. switching to another 
AP, before completing the connection. Still it is needed here so ...


Acked-by: Arend van Spriel 

Signed-off-by: Chung-Hsien Hsu 
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 617199c..71f18b9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5552,10 +5552,13 @@ static s32 brcmf_get_assoc_ies(struct 
brcmf_cfg80211_info *cfg,
u32 status = e->status;

if (event == BRCMF_E_ROAM && status == BRCMF_E_STATUS_SUCCESS) {
-   if (test_bit(BRCMF_VIF_STATUS_CONNECTED, >vif->sme_state))
+   if (test_bit(BRCMF_VIF_STATUS_CONNECTED,
+>vif->sme_state)) {
brcmf_bss_roaming_done(cfg, ifp->ndev, e);
-   else
+   } else {
brcmf_bss_connect_done(cfg, ifp->ndev, e, true);
+   brcmf_net_setcarrier(ifp, true);
+   }
}

return 0;

Re: [PATCH v2 09/12] qtnfmac: implement scan timeout

[Kalle Valo]

Sergey Matyukevich  writes:

>> > + if (timer_pending(>scan_timeout))
>> > + del_timer_sync(>scan_timeout);
>> 
>> What if the device is removed while the timer is pending, is that
>> handled?
>
> Good point. I took another look at this kind of corner cases. Timer is not 
> disabled
> explicitely. But ongoing scan request is explicitely aborted in relevant
> cfg80211 ops, e.g. on virtual interface change or removal. Though it looks 
> like
> some of AP usecases are not handled: e.g. when AP is stopped while scan is
> in progress. I will queue the fix into the next cleanup/bugfix patch series
> if it is needed to abort scan in such a case.

Good, thanks for checking.

-- 
Kalle Valo

Re: [v5] wlcore: add missing nvs file name info for wilink8

[Kalle Valo]

"Reizer, Eyal"  writes:

> The following commits:
> c815fde wlcore: spi: Populate config firmware data
> d776fc8 wlcore: sdio: Populate config firmware data

It's recommended to use 12 chars when abbreviating commit ids so the
format should be this:

c815fdebef44 wlcore: spi: Populate config firmware data
d776fc86b82f wlcore: sdio: Populate config firmware data

> Populated the nvs entry for wilink6 and wilink7 only while it is
> still needed for wilink8 as well.
> This broke user space backward compatibility when upgrading from older
> kernels, as the alternate mac address would not be read from the nvs that is
> present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
> causing mac address change of the wlan interface.
>
> This patch fix this and update the structure field with the same default
> nvs file name that has been used before.
>
> In addition, some distros hold a default wl1271-nvs.bin in the file
> system with a bogus mac address (deadbeef...) that for a wl18xx device
> also overrides the mac address that is stored inside the device.
> Warn users about this bogus mac address and use a random mac instead
>
> Cc: stable 
> Signed-off-by: Eyal Reizer 

It's always good to have a fixes line(s) and specify which stable
versions should have the fix. As the commit were first in v4.9-rc1
that's the first version we want this to be included:

Fixes: c815fdebef44 ("wlcore: spi: Populate config firmware data")
Fixes: d776fc86b82f ("wlcore: sdio: Populate config firmware data")
Cc:  # 4.9+

But if you don't submit a new version I can fix the commit log during
commit.

-- 
Kalle Valo

Re: [PATCH v2 3/3] brcmfmac: fix wrong num_different_channels when mchan feature enabled

[Arend van Spriel]

On 8/3/2017 11:37 AM, Wright Feng wrote:

brcmfmac: fix wrong num_different_channels when mchan feature enabled

When the device/firmware supports multi-channel, it can have P2P
connection and regular connection with AP simultaneous. In this case,
the num_different_channels in wiphy info was not correct when firmware
supports multi-channel (The iw wiphy# info showed "#channels <= 1" in
interface combinations). It caused association failed and error message
"CTRL-EVENT-FREQ-CONFLICT error" in wpa_supplicant when P2P GO interface
was running at the same time.
The root cause is that the num_different_channels was always overridden
to 1 in brcmf_setup_ifmodes even multi-channel was enabled.
We correct the logic by moving num_different_channels setting forward.


Acked-by: Arend van Spriel 

Signed-off-by: Wright Feng 
---
v2: Describe the motivation and reason for this patch in commit message
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

Re: [PATCH 29/34] brcmfmac: stabilise the value of ->sbwad in use for some xfer routines.

[Arend van Spriel]

So now I jump to this patch
On 7/26/2017 10:25 PM, Ian Molton wrote:

The IO functions operate within the Chipcommon IO window. Explicitly
set this, rather than relying on the last initialisation IO access to
leave it set to the right value by chance.



Signed-off-by: Ian Molton 
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8 
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c   | 5 +
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h   | 1 +
  3 files changed, 10 insertions(+), 4 deletions(-)



[...]


diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
index fb4f24dfc99d..1ab95011adb0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
@@ -178,6 +178,7 @@ struct brcmf_sdio_dev {
struct sdio_func *func[SDIO_MAX_FUNCS];
u8 num_funcs;   /* Supported funcs on client */
u32 sbwad;  /* Save backplane window address */
+   struct brcmf_core *cc_core; /* chipcommon core info struct */


We actually just need the chipcommon base address so why not have that 
here, ie.:

+   u32 cc_base;

Another option is to simple use SI_ENUM_BASE as the chipcommon base 
address will always be 0x1800 for the SDIO chips.



struct brcmf_sdio *bus;
struct device *dev;
struct brcmf_bus *bus_if;

Re: [PATCH v2 2/3] brcmfmac: Add support for CYW4373 SDIO/USB chipset

[Arend van Spriel]

On 8/3/2017 11:37 AM, Wright Feng wrote:

From: Chi-Hsien Lin 

Add support for CYW4373 SDIO/USB chipset.
CYW4373 is a 1x1 dual-band 11ac chipset with 20/40/80Mhz channel support.
It's a WiFi/BT combo device.


Reviewed-by: Arend van Spriel 

Signed-off-by: Chi-Hsien Lin 
---
v2: add new chip(4737) info in commit message


comment below...


---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c   | 2 ++
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c   | 4 +++-
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c| 9 -
  drivers/net/wireless/broadcom/brcm80211/include/brcm_hw_ids.h | 3 +++
  include/linux/mmc/sdio_ids.h  | 1 +
  6 files changed, 18 insertions(+), 2 deletions(-)



[...]


diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index b733eb4..abacd54 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -39,6 +39,7 @@
  #define SDIO_DEVICE_ID_BROADCOM_43455 0xa9bf
  #define SDIO_DEVICE_ID_BROADCOM_4354  0x4354
  #define SDIO_DEVICE_ID_BROADCOM_4356  0x4356
+#define SDIO_DEVICE_ID_CYPRESS_43730x4373


So is there no specific Cypress SDIO vendor ID?


  #define SDIO_VENDOR_ID_INTEL  0x0089
  #define SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX0x1402

Re: [PATCH v2 1/3] brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/OPEN security mode

[Arend van Spriel]

On 8/3/2017 11:37 AM, Wright Feng wrote:

brcmfmac: set wpa_auth to WPA_AUTH_DISABLED in AP/OPEN security mode

When setting wpa_auth to WPA_AUTH_NONE(1) in AP mode with WEP security,
firmware will set privacy bit and add WPA OUI in VENDOR IE in beacon and
probe response. The security type in softAP beacons confuse the
supplicant in client side, and the user client will see [WPA-?] in
supplicant scan result. So we set WPA_AUTH_DISABLED in softAP mode with
OPEN security.


Acked-by: Arend van Spriel 

Signed-off-by: Wright Feng 
---
v2: fix typo in commit message
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

Re: [PATCH 15/34] brcmfamc: remove unnecessary call to brcmf_sdiod_set_backplane_window()

[Arend van Spriel]

On 8/7/2017 1:11 PM, Arend van Spriel wrote:

On 7/26/2017 10:25 PM, Ian Molton wrote:

All functions that might require the window address changing call
brcmf_sdiod_set_backplane_window() prior to access. Thus resetting
the window is not required.


Actually noticed a minor nit. The subject says "brcmfamc".

Regards,
Arend


Acked-by: Arend van Spriel 

Signed-off-by: Ian Molton 
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 5 -
  1 file changed, 5 deletions(-)

Re: [PATCH 14/34] brcmfmac: Remove brcmf_sdiod_addrprep()

[Arend van Spriel]

On 7/26/2017 10:25 PM, Ian Molton wrote:

This function has become trivial enough that it may as well be pushed into
its callers, which has the side-benefit of clarifying what's going on.

Remove it, and rename brcmf_sdiod_set_sbaddr_window() to
brcmf_sdiod_set_backplane_window() as it's easier to understand.


Reviewed-by: Arend van Spriel 

Signed-off-by: Ian Molton 


comments below...


# Conflicts:
#   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
---
  .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 78 --
  1 file changed, 44 insertions(+), 34 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index b2945b463fd3..24775869aee4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -228,41 +228,25 @@ void brcmf_sdiod_change_state(struct brcmf_sdio_dev 
*sdiodev,
sdiodev->state = state;
  }

-static int brcmf_sdiod_set_sbaddr_window(struct brcmf_sdio_dev *sdiodev,
-u32 address)
+static int
+brcmf_sdiod_set_backplane_window(struct brcmf_sdio_dev *sdiodev, u32 addr)
  {
+   u32 v, bar0 = addr & SBSDIO_SBWINDOW_MASK;
int err = 0, i;
-   u32 addr;

-   if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
-   return -ENOMEDIUM;


So now you are dropping the state check here, which seems significant 
enough to mention in the commit log. We need to discuss that. The idea 
of it was to refrain from using IO function of the MMC stack when we no 
there is no longer a device, ie. when stack has previously returned a 
-ENOMEDIUM.



+   if (bar0 == sdiodev->sbwad)
+   return 0;

-   addr = (address & SBSDIO_SBWINDOW_MASK) >> 8;
+   v = bar0 >> 8;


why introducing a new variable on the stack. You actually don't need any 
and just mask and shift the addr variable passed to the function.



-   for (i = 0 ; i < 3 && !err ; i++, addr >>= 8)
+   for (i = 0 ; i < 3 && !err ; i++, v >>= 8)
brcmf_sdiod_writeb(sdiodev, SBSDIO_FUNC1_SBADDRLOW + i,
-  addr & 0xff, );
-
-   return err;
-}
-
-static int brcmf_sdiod_addrprep(struct brcmf_sdio_dev *sdiodev, u32 *addr)
-{
-   uint bar0 = *addr & ~SBSDIO_SB_OFT_ADDR_MASK;
-   int err = 0;
-
-   if (bar0 != sdiodev->sbwad) {
-   err = brcmf_sdiod_set_sbaddr_window(sdiodev, bar0);
-   if (err)
-   return err;
+  v & 0xff, );

+   if (!err)
sdiodev->sbwad = bar0;
-   }
-
-   *addr &= SBSDIO_SB_OFT_ADDR_MASK;
-   *addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;

-   return 0;
+   return err;
  }

  u32 brcmf_sdiod_readl(struct brcmf_sdio_dev *sdiodev, u32 addr, int *ret)
@@ -270,11 +254,17 @@ u32 brcmf_sdiod_readl(struct brcmf_sdio_dev *sdiodev, u32 
addr, int *ret)
u32 data = 0;
int retval;

-   retval = brcmf_sdiod_addrprep(sdiodev, );
+   retval = brcmf_sdiod_set_backplane_window(sdiodev, addr);
+   if (retval)
+   goto out;
+
+   addr &= SBSDIO_SB_OFT_ADDR_MASK;
+   addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;

if (!retval)
data = sdio_readl(sdiodev->func[1], addr, );


The if-statement is now redundant here...



+out:
if (ret)
*ret = retval;

@@ -286,11 +276,17 @@ void brcmf_sdiod_writel(struct brcmf_sdio_dev *sdiodev, 
u32 addr,
  {
int retval;

-   retval = brcmf_sdiod_addrprep(sdiodev, );
+   retval = brcmf_sdiod_set_backplane_window(sdiodev, addr);
+   if (retval)
+   goto out;
+
+   addr &= SBSDIO_SB_OFT_ADDR_MASK;
+   addr |= SBSDIO_SB_ACCESS_2_4B_FLAG;

if (!retval)
sdio_writel(sdiodev->func[1], data, addr, );


...and here.


+out:
if (ret)
*ret = retval;
  }

Re: [PATCH 11/34] brcmfmac: Split brcmf_sdiod_buffrw function up.

[Arend van Spriel]

On 7/26/2017 10:25 PM, Ian Molton wrote:

This function needs to be split up into separate read / write variants
for clarity.


Reviewed-by: Arend van Spriel 

Signed-off-by: Ian Molton 


more comments below...


# Conflicts:
#   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
---
  .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 69 +++---
  1 file changed, 47 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 9d5716d0ad73..858ad2d8706b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c


[...]


@@ -706,10 +725,10 @@ int brcmf_sdiod_send_buf(struct brcmf_sdio_dev *sdiodev, 
u8 *buf, uint nbytes)
err = brcmf_sdiod_addrprep(sdiodev, );

if (!err)
-   err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, true, addr,
-mypkt);
+   err = brcmf_sdiod_buff_write(sdiodev, SDIO_FUNC_2, addr, mypkt);

brcmu_pkt_buf_free_skb(mypkt);
+


You are keen on sprinkling whitespace here and there. Could you please 
use separate patches for that as much as possible. Not sure why you 
added this one...



return err;



...and kept this one.


  }

Re: [PATCH 12/34] brcmfmac: Replace old IO functions with simpler ones.

[Arend van Spriel]

On 7/26/2017 10:25 PM, Ian Molton wrote:

Primarily this patch removes:

brcmf_sdiod_f0_writeb()
brcmf_sdiod_reg_write()
brcmf_sdiod_reg_read()


Having [patch 30/34] "brcmfmac: Correctly handle accesses to SDIO func0" 
before this patch could make this look cleaner.



Since we no longer use the quirky method of deciding which function to
address via the address being accessed, take the opportunity to rename
some IO functions more in line with common kernel code.


As mentioned here this is more a rename than a replace so please use 
that in the subject as well.


Reviewed-by: Arend van Spriel 

Signed-off-by: Ian Molton 
---
  .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 166 +++
  .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 182 ++---
  .../wireless/broadcom/brcm80211/brcmfmac/sdio.h|  28 +++-
  3 files changed, 132 insertions(+), 244 deletions(-)

Re: [PATCH 09/34] brcmfmac: Remove noisy debugging.

[Arend van Spriel]

On 7/26/2017 10:25 PM, Ian Molton wrote:

If you need debugging this low level, you're doing something wrong.
Remove these noisy debug statements so the code is more readable.


Needing this debugging does not necessarily means you are doing 
something wrong. You may be dealing with hardware that is doing 
something wrong and when that happens this debug can be useful. I 
frankly hardly ever enable SDIO debug level unless I am in that 
scenario. Maybe adding a debug level for low-level access would be 
useful to reduce the noise for SDIO debug level.


Regards,
Arend


Signed-off-by: Ian Molton 
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)

Re: [PATCH 10/34] brcmfmac: Rename bcmerror to err

[Arend van Spriel]

On 7/26/2017 10:25 PM, Ian Molton wrote:

Trivial cleanup of nasty variable name


Did not look, but here is...

Acked-by: Arend van Spriel 

Signed-off-by: Ian Molton 
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

Re: [PATCH 08/34] brcmfmac: Fix uninitialised variable

[Arend van Spriel]

On 7/26/2017 10:25 PM, Ian Molton wrote:

Unlikely to be a problem, but brcmf_sdiod_regrb() is
not symmetric with brcmf_sdiod_regrl() in this regard.


You are pretty keen on symmetry, but you could also remove the 
initialization in brcmf_sdiod_regrl(). As long as no -Wunitialized pops 
up that would have my preference.


Reviewed-by: Arend van Spriel 

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

Re: [PATCH 03/34] brcmfmac: Split brcmf_sdiod_regrw_helper() up.

[Arend van Spriel]

On 26-07-17 22:25, Ian Molton wrote:

This large function is concealing a LOT of obscure logic about
how the hardware functions. Time to split it up.

This first patch splits the function into two pieces - read and write,
doing away with the rw flag in the process.


I really don't this it is all that obscure, but alas. Everything is in
the eye of the beholder. The reason for having the helper was to not
duplicate code for read and write and different access sizes. So now you
are duplicating it. In subsequent patches you throw away pieces of this
helper so duplication is not as bad in the net result. It would have
been easier if those patches were done before this one.

Reviewed-by: Arend van Spriel 

Signed-off-by: Ian Molton 


some minor comment below


---
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 94 +-
 1 file changed, 73 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 2b441ce91d5f..1ee0f91b6c50 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -302,8 +302,8 @@ static int brcmf_sdiod_request_data(struct brcmf_sdio_dev 
*sdiodev, u8 fn,
return ret;
 }

-static int brcmf_sdiod_regrw_helper(struct brcmf_sdio_dev *sdiodev, u32 addr,
-  u8 regsz, void *data, bool write)
+static int brcmf_sdiod_reg_write(struct brcmf_sdio_dev *sdiodev, u32 addr,
+u8 regsz, void *data)


Fix the indent and column align to opening bracket.

Regards,
Arend

Re: [PATCH 06/34] brcmfmac: Remove bandaid for SleepCSR

[Arend van Spriel]

On 26-07-17 22:25, Ian Molton wrote:

Register access code is not the place for band-aid fixes like this.
If this is a genuine problem, it should be fixed further up in the driver
stack.


So lets make it a SDIO debug message for all register accesses getting
rid of the error message.

Reviewed-by: Arend van Spriel 

Signed-off-by: Ian Molton 

# Conflicts:
#   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
---
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 28 +-
 1 file changed, 1 insertion(+), 27 deletions(-)

Re: [PATCH 07/34] brcmfmac: Remove brcmf_sdiod_request_data()

[Arend van Spriel]

On 26-07-17 22:25, Ian Molton wrote:

This function is obfuscating how IO works on this chip. Remove it
and push its logic into brcmf_sdiod_reg_{read,write}().

Handling of -ENOMEDIUM is altered, but as that's pretty much broken anyway
we can ignore that.


Please explain why you think it is broken.

Reviewed-by: Arend van Spriel 

Signed-off-by: Ian Molton 


more comments below.


# Conflicts:
#   drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
---
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 239 -
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.h|   2 +-
 2 files changed, 87 insertions(+), 154 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index d217b1281e0d..f703d7be6a85 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c


[...]


 static int brcmf_sdiod_reg_write(struct brcmf_sdio_dev *sdiodev, u32 addr,
 u8 regsz, void *data)
 {
-   u8 func;
-   s32 retry = 0;
int ret;

-   if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
-   return -ENOMEDIUM;
-
/*
 * figure out how to read the register based on address range
 * 0x00 ~ 0x7FF: function 0 CCCR and FBR
 * 0x1 ~ 0x1: function 1 miscellaneous registers
 * The rest: function 1 silicon backplane core registers
+* f0 writes must be bytewise
 */
-   if ((addr & ~REG_F0_REG_MASK) == 0)
-   func = SDIO_FUNC_0;
-   else
-   func = SDIO_FUNC_1;
-
-   do {
-   /* for retry wait for 1 ms till bus get settled down */
-   if (retry)
-   usleep_range(1000, 2000);

-   ret = brcmf_sdiod_request_data(sdiodev, func, addr, regsz,
-  data, true);
-
-   } while (ret != 0 && ret != -ENOMEDIUM &&
-retry++ < SDIOH_API_ACCESS_RETRY_LIMIT);
+   if ((addr & ~REG_F0_REG_MASK) == 0) {
+   if (WARN_ON(regsz > 1))
+   return -EINVAL;
+   ret = brcmf_sdiod_f0_writeb(sdiodev->func[0], *(u8 *)data, 
addr);
+   } else {
+   switch (regsz) {
+   case 1:
+   sdio_writeb(sdiodev->func[1], *(u8 *)data, addr, );
+   break;
+   case 4:
+   ret = brcmf_sdiod_addrprep(sdiodev, );
+   if (ret)
+   goto done;

-   if (ret == -ENOMEDIUM)
-   brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM);
+   sdio_writel(sdiodev->func[1], *(u32 *)data, addr, );
+   break;
+   default:
+   BUG();


Please do not use BUG() as it simply crashes the system. You may argue 
that we never reach this unless a coding mistake is made, but still we 
prefer WARN() over BUG() in such cases.



+   ret = -EINVAL;
+   break;
+   }
+   }

+done:
return ret;
 }

 static int brcmf_sdiod_reg_read(struct brcmf_sdio_dev *sdiodev, u32 addr,
u8 regsz, void *data)
 {
-   u8 func;
-   s32 retry = 0;
int ret;

-   if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
-   return -ENOMEDIUM;
-
/*
 * figure out how to read the register based on address range
 * 0x00 ~ 0x7FF: function 0 CCCR and FBR
 * 0x1 ~ 0x1: function 1 miscellaneous registers
 * The rest: function 1 silicon backplane core registers
+* f0 reads must be bytewise
 */
-   if ((addr & ~REG_F0_REG_MASK) == 0)
-   func = SDIO_FUNC_0;
-   else
-   func = SDIO_FUNC_1;
-
-   do {
-   memset(data, 0, regsz);
-
-   /* for retry wait for 1 ms till bus get settled down */
-   if (retry)
-   usleep_range(1000, 2000);
-
-   ret = brcmf_sdiod_request_data(sdiodev, func, addr, regsz,
-  data, false);
-
-   } while (ret != 0 && ret != -ENOMEDIUM &&
-retry++ < SDIOH_API_ACCESS_RETRY_LIMIT);
-
-   if (ret == -ENOMEDIUM)
-   brcmf_sdiod_change_state(sdiodev, BRCMF_SDIOD_NOMEDIUM);
-
-   return ret;
-}
-
-static int
-brcmf_sdiod_set_sbaddr_window(struct brcmf_sdio_dev *sdiodev, u32 address)
-{
-   int err = 0, i;
-   u32 addr;
-
-   if (sdiodev->state == BRCMF_SDIOD_NOMEDIUM)
-   return -ENOMEDIUM;
-
-   addr = (address & SBSDIO_SBWINDOW_MASK) >> 8;
-
-   for (i = 0 ; i < 3 && !err ; i++, addr >>= 8)
-   brcmf_sdiod_regwb(sdiodev, 

Re: [PATCH 01/34] brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()

[Arend van Spriel]

Hi Ian,

So it took me a while to get to this patch series. It is indeed way to 
big and not well structured making it difficult to review the patches on 
a per-patch basis.


I decided to limit myself to looking at the patches involving bcmsdh.c 
doing a 'git log bcmsdh.c' on the applied patches. Still twenty patches 
to review. I reviewed the first 15 patches of the series and skipped 
patch [13/34] as it did not touch bcmsdh.c. A few response already 
slipped to the mailing list so I will post the rest shortly. Here is the 
first one.


On 26-07-17 22:25, Ian Molton wrote:

All the other IO functions are the other way round in this
driver. Make this one match.


Core SDIO functions are indeed the other way around, but the IO
functions in this file use (addr, data) pattern. So should we aim to get 
it all consistent with core SDIO or just consistent on its own.



Signed-off-by: Ian Molton 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index 984c1d0560b1..f585dfd89453 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -230,8 +230,8 @@ void brcmf_sdiod_change_state(struct brcmf_sdio_dev 
*sdiodev,
sdiodev->state = state;
 }

-static inline int brcmf_sdiod_f0_writeb(struct sdio_func *func,
-   uint regaddr, u8 byte)
+static inline int brcmf_sdiod_f0_writeb(struct sdio_func *func, u8 byte,
+   uint regaddr)


The second line needs to be aligned on same column as the opening bracket.

Regards,
Arend

Re: [PATCH 02/34] brcmfmac: Register sizes on hardware are not dependent on compiler types

[Arend van Spriel]

On 26-07-17 22:25, Ian Molton wrote:

The 4 IO functions in this patch are incorrect as they use compiler types
to determine how many bytes to send to the hardware.


I see no incorrectness here. It is validating the regsz value and those
compiler types are pretty well defined I would say. Anyway, I find the
use of sizeof() here pretty useless so thanks for the change.

Reviewed-by: Arend van Spriel 

Signed-off-by: Ian Molton 
---
 .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c  | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

Re: [PATCH 15/34] brcmfamc: remove unnecessary call to brcmf_sdiod_set_backplane_window()

[Arend van Spriel]

On 7/26/2017 10:25 PM, Ian Molton wrote:

All functions that might require the window address changing call
brcmf_sdiod_set_backplane_window() prior to access. Thus resetting
the window is not required.


Acked-by: Arend van Spriel 

Signed-off-by: Ian Molton 
---
  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 5 -
  1 file changed, 5 deletions(-)

Assalamualikum.

[Mr Abdul Karim]

Greetings from Mr. Abdul Karim.

 Assalamu`Alaikum.

My Name is Mr. Abdul Karim I am a banker by profession. I'm  from
Ouagadougou, Burkina Faso, West Africa. My reason for contacting you
is to transfer an abandoned $15.5M to your account.

The owner of this fund died since 2004  with his Next Of Kin. I want
to present you to the bank as the Next of  Kin/beneficiary of this
fund.

Further details of the transaction shall be forwarded to you as soon
as I receive your return mail  indicating your interest.

 1) YOUR FULL  NAME...
 (2) YOUR AGE AND  SEX
 (3) YOUR CONTACT  ADDRESS..
 (4) YOUR PRIVATE PHONE N0..
 (5) FAX NUMBER..
 (6) YOUR COUNTRY OF ORIGIN..
 (7) YOUR  OCCUPATION.

Have a great day,
Mr. Abdul Karim

Re: [PATCH 00/10] mac80211 patches from our internal tree 2017-08-05

[Luca Coelho]

On Mon, 2017-08-07 at 12:06 +0300, Kalle Valo wrote:
> Luca Coelho  writes:
> 
> > Here are some pending mac80211 patches from our internal tree.
> > 
> > The "mac80211: add api to start ba session timer expired flow" patch
> > is needed by an iwlwifi patch that I want to send for -fixes, so it
> > would have to be applied to -fixes as well.
> 
> We are getting to the later stages of the release cycle and I'm raising
> the bar for wireless-drivers even higher. How serious iwlwifi bug is
> that fixing?

The problem is a bad degradation in throughput with our new 9000 family
of devices because when aggregation times out we stop the aggregation
internally in the firmware but don't send a delba.  Then on the AP side,
 also with our driver, we don't handle the timeout as we should, so
aggregations the devices get out of sync and BA sessions are not
possible anymore, limiting our throughput to ~30Mbps, in some specific
internal tests.


> > Should I send a separate patchset with these two so they can be both
> > applied at the same time (either in the mac80211 or in
> > wireless-drivers tree)?
> 
> Now that Johannes is away and I'm taking any urgent mac80211 patches, I
> think the best approach is that you include mac80211 patch in the same
> patchset as the iwlwifi patches destined for wireless-drivers.

Okay, if you think the (one-liner) iwlwifi driver fix is -rc'able, I'll
resend this in a patchset including both changes.


--
Cheers,
Luca.

Re: [PATCH 00/10] mac80211 patches from our internal tree 2017-08-05

[Kalle Valo]

Luca Coelho  writes:

> Here are some pending mac80211 patches from our internal tree.
>
> The "mac80211: add api to start ba session timer expired flow" patch
> is needed by an iwlwifi patch that I want to send for -fixes, so it
> would have to be applied to -fixes as well.

We are getting to the later stages of the release cycle and I'm raising
the bar for wireless-drivers even higher. How serious iwlwifi bug is
that fixing?

> Should I send a separate patchset with these two so they can be both
> applied at the same time (either in the mac80211 or in
> wireless-drivers tree)?

Now that Johannes is away and I'm taking any urgent mac80211 patches, I
think the best approach is that you include mac80211 patch in the same
patchset as the iwlwifi patches destined for wireless-drivers.

-- 
Kalle Valo

[PATCH] wireless-regdb: Update regulatory rules for Singapore (SG)

[Sven Eckelmann]

2.4GHz and the lower 5GHz band can now be use with up to 23dBm. But the DFS
channels in general require TPC to be usable. Only 5150 - 5250 has an
exception which allows the use of it without TPC when reducing the power to
20 dBm.

Signed-off-by: Sven Eckelmann 
---
Please check this twice because this is my first attempt in converting an
official regulatory document to an wireless-regdb entry.

 db.txt | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/db.txt b/db.txt
index 0bc068e..df30f37 100644
--- a/db.txt
+++ b/db.txt
@@ -1078,12 +1078,17 @@ country SE: DFS-ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
 
+# Source
+# 
https://www.imda.gov.sg/~/media/imda/files/regulation%20licensing%20and%20consultations/ict%20standards/telecommunication%20standards/radio-comms/imdatssrd.pdf?la=en
+# page 12-14
+# The EIRP for 5250 – 5350 can be increased by 3dB if TPC is implemented.
 country SG: DFS-FCC
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (17), AUTO-BW
-   (5250 - 5330 @ 80), (24), DFS, AUTO-BW
-   (5490 - 5730 @ 160), (24), DFS
-   (5735 - 5835 @ 80), (30)
+   (2400 - 2483.5 @ 40), (23)
+   (5150 - 5250 @ 80), (23), AUTO-BW
+   (5250 - 5350 @ 80), (20), DFS, AUTO-BW
+   # 5470 - 5725 is only allowed when TPC is implemented
+   # (5470 - 5725 @ 160), (30), DFS
+   (5725 - 5850 @ 80), (30)
 
 country SI: DFS-ETSI
(2402 - 2482 @ 40), (20)
-- 
2.11.0

[PATCH] brcmfmac: add setting carrier state ON for successful roaming

[Wright Feng]

From: Chung-Hsien Hsu 

After association, ping is not working when sweeping the channel at the
AP side. It is caused by having incorrect carrier state (OFF) for the STA
in successful roaming. This patch sets the carrier state ON for the case.

Signed-off-by: Chung-Hsien Hsu 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 617199c..71f18b9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5552,10 +5552,13 @@ static s32 brcmf_get_assoc_ies(struct 
brcmf_cfg80211_info *cfg,
u32 status = e->status;
 
if (event == BRCMF_E_ROAM && status == BRCMF_E_STATUS_SUCCESS) {
-   if (test_bit(BRCMF_VIF_STATUS_CONNECTED, >vif->sme_state))
+   if (test_bit(BRCMF_VIF_STATUS_CONNECTED,
+>vif->sme_state)) {
brcmf_bss_roaming_done(cfg, ifp->ndev, e);
-   else
+   } else {
brcmf_bss_connect_done(cfg, ifp->ndev, e, true);
+   brcmf_net_setcarrier(ifp, true);
+   }
}
 
return 0;
-- 
1.9.1

RE: [v5] wlcore: add missing nvs file name info for wilink8

[Reizer, Eyal]

Hi Tony,
> 
> * Reizer, Eyal  [170807 00:32]:
> > The following commits:
> > c815fde wlcore: spi: Populate config firmware data
> > d776fc8 wlcore: sdio: Populate config firmware data
> >
> > Populated the nvs entry for wilink6 and wilink7 only while it is
> > still needed for wilink8 as well.
> > This broke user space backward compatibility when upgrading from older
> > kernels, as the alternate mac address would not be read from the nvs that
> is
> > present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
> > causing mac address change of the wlan interface.
> >
> > This patch fix this and update the structure field with the same default
> > nvs file name that has been used before.
> >
> > In addition, some distros hold a default wl1271-nvs.bin in the file
> > system with a bogus mac address (deadbeef...) that for a wl18xx device
> > also overrides the mac address that is stored inside the device.
> > Warn users about this bogus mac address and use a random mac instead
> 
> Hmm looks pretty good to me except for one more thing I just noticed.
> 
> Why don't you just use the hardware mac address instead of a random
> mac address on wl18xx device when you see a bogus nvs file?
> 

I agree that this would have been better but the problem is that hardware 
mac address is available for wilink8 onlyWilink6/7 don't have one stored.
The wlcore code responsible for handling mac address is common code 
and there is method for detecting between them in this module.

Best Regards,
Eyal

Re: [v5] wlcore: add missing nvs file name info for wilink8

[Tony Lindgren]

* Reizer, Eyal  [170807 00:32]:
> The following commits:
> c815fde wlcore: spi: Populate config firmware data
> d776fc8 wlcore: sdio: Populate config firmware data
> 
> Populated the nvs entry for wilink6 and wilink7 only while it is
> still needed for wilink8 as well.
> This broke user space backward compatibility when upgrading from older
> kernels, as the alternate mac address would not be read from the nvs that is
> present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
> causing mac address change of the wlan interface.
> 
> This patch fix this and update the structure field with the same default
> nvs file name that has been used before.
> 
> In addition, some distros hold a default wl1271-nvs.bin in the file
> system with a bogus mac address (deadbeef...) that for a wl18xx device
> also overrides the mac address that is stored inside the device.
> Warn users about this bogus mac address and use a random mac instead

Hmm looks pretty good to me except for one more thing I just noticed.

Why don't you just use the hardware mac address instead of a random
mac address on wl18xx device when you see a bogus nvs file?

Regards,

Tony

RE: [v4] wlcore: add missing nvs file name info for wilink8

[Reizer, Eyal]

> -Original Message-
> From: Julian Calaby [mailto:julian.cal...@gmail.com]
> Sent: Saturday, August 5, 2017 8:51 AM
> To: Reizer, Eyal
> Cc: Kalle Valo; ,Tony Lindgren; linux-wireless@vger.kernel.org; linux-
> ker...@vger.kernel.org; sebastian.reic...@collabora.co.uk
> Subject: Re: [v4] wlcore: add missing nvs file name info for wilink8
> 
> Hi Eyal,
> 
> On Mon, Jul 31, 2017 at 6:45 PM, Reizer, Eyal  wrote:
> > The following commits:
> > c815fde wlcore: spi: Populate config firmware data
> > d776fc8 wlcore: sdio: Populate config firmware data
> >
> > Populated the nvs entry for wilink6 and wilink7 only while it is
> > still needed for wilink8 as well.
> > This broke user space backward compatibility when upgrading from older
> > kernels, as the alternate mac address would not be read from the nvs that
> > is present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin)
> > causing mac address change of the wlan interface.
> >
> > This patch fix this and update the structure field with the same default
> > nvs file name that has been used before.
> >
> > In addition, some distros hold a default wl1271-nvs.bin in the file
> > system with a bogus mac address (deadbeef...) that for a wl18xx device
> > also overrides the mac address that is stored inside the device.
> > Warn users about this bogus mac address and use a random mac instead
> >
> > Cc: stable 
> > Signed-off-by: Eyal Reizer 
> > ---
> >
> > diff --git a/drivers/net/wireless/ti/wlcore/main.c
> b/drivers/net/wireless/ti/wlcore/main.c
> > index 60aaa85..7ce4221 100644
> > --- a/drivers/net/wireless/ti/wlcore/main.c
> > +++ b/drivers/net/wireless/ti/wlcore/main.c
> > @@ -5961,6 +5961,22 @@ static void wl12xx_derive_mac_addresses(struct
> wl1271 *wl, u32 oui, u32 nic)
> > if (nic + WLCORE_NUM_MAC_ADDRESSES - wl->num_mac_addr >
> 0xff)
> > wl1271_warning("NIC part of the MAC address wraps around!");
> >
> > +   if (oui == 0xdeadbe && nic == 0xef) {
> > +   wl1271_warning("Detected unconfigured mac address in nvs.\n"
> > +   "Using a random TI mac address instead.\n"
> > +   "in case of using a wl12xx device, your "
> > +   "device performance may not be optimized.\n"
> > +   "Please use the calibrator tool to 
> > configure "
> > +   "your device.\n"
> > +   "When using a wl18xx device the nvs file 
> > can "
> > +   "be removed as a default mac address is "
> > +   "stored internally.\n");
> > +
> > +   /* Use TI oui and a random nic */
> > +   oui = 0x080028;
> 
> Is there (or should there be) a constant for this?

Thanks for the comment. Submitting v5 fixing this.

Best Regards,
Eyal

Re: [PATCH v2] rt2x00: Fix MMIC Countermeasures.

[Stanislaw Gruszka]

On Thu, Aug 03, 2017 at 11:31:21AM -0400, Michael Skeffingfon wrote:
> @@ -136,10 +136,19 @@ void rt2800mmio_fill_rxdone(struct queue_entry *entry,
>*/
>   rxdesc->flags |= RX_FLAG_MMIC_STRIPPED;
>  
> - if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS)
> + if (rxdesc->cipher_status == RX_CRYPTO_SUCCESS) {
>   rxdesc->flags |= RX_FLAG_DECRYPTED;
> - else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC)
> +} else if (rxdesc->cipher_status == RX_CRYPTO_FAIL_MIC) {

Not sure why this happened, but here and on some other places below,
tab was replaced by spaces resulting in wrong indent.

Stanislaw