Re: [PATCH] rtlwifi: rtl8723be: Fix loss of signal

[James Cameron]

On Thu, Feb 22, 2018 at 02:28:59PM -0600, Larry Finger wrote:
> In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem
> correctly") a problem in rtl8821ae that caused loss of signal was fixed.
> That same problem has now been reported for rtl8723be. Accordingly,
> the ASPM L1 latency has been increased from 0 to 7 to fix the instability.
> 
> Signed-off-by: Larry Finger 
> Cc: Stable 

Tested-by: James Cameron 

With both patches applied to v4.15 on OLPC NL3 with rtl8723be.

Nice catch, well done!  May explain some of our problems with
rtl8723be that made me withdraw it from production of laptops.

-- 
James Cameron
http://quozl.netrek.org/

Re: [PATCH v9] ath10k: add LED and GPIO controlling support for various chipsets

[Steve deRosier]

Hi Sebastian,

On Thu, Feb 22, 2018 at 6:09 PM, Sebastian Gottschall
 wrote:
> Am 22.02.2018 um 23:17 schrieb Steve deRosier:
>>
>> On Thu, Feb 22, 2018 at 3:15 AM,   wrote:
>>>
>>> From: Sebastian Gottschall 
>>>
>>> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
>>> chipsets with on chipset connected led's
>>> using WMI Firmware API.
>>> The LED device will get available named as "ath10k-phyX" at sysfs and can
>>> be controlled with various triggers.
>>> adds also debugfs interface for gpio control.
>>>
>>> Signed-off-by: Sebastian Gottschall 
>>>
>>> v2  add correct gpio count per chipset and remove IPQ4019 support since
>>> this chipset does not make use of specific gpios)
>>> v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error
>>> by kbuild test robot which does not occur in standard builds. curious
>>> v6  correct return values and fix comment style
>>> v7  fix ath10k_unregister_led for compiling without LED_CLASS
>>> v8  fix various code design issues reported by reviewers
>>> v9  move led and led code to separate sourcefile (gpio.c)
>>> ---
>>>   drivers/net/wireless/ath/ath10k/Kconfig   |   3 +
>>>   drivers/net/wireless/ath/ath10k/Makefile  |   1 +
>>>   drivers/net/wireless/ath/ath10k/core.c|  28 -
>>>   drivers/net/wireless/ath/ath10k/core.h|  33 -
>>>   drivers/net/wireless/ath/ath10k/debug.c   | 142 ++
>>>   drivers/net/wireless/ath/ath10k/gpio.c| 196
>>> ++
>>>   drivers/net/wireless/ath/ath10k/hw.h  |   2 +
>>>   drivers/net/wireless/ath/ath10k/mac.c |   5 +
>>>   drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
>>>   drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 ++
>>>   drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
>>>   drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
>>>   12 files changed, 590 insertions(+), 3 deletions(-)
>>>   create mode 100644 drivers/net/wireless/ath/ath10k/gpio.c
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/Kconfig
>>> b/drivers/net/wireless/ath/ath10k/Kconfig
>>> index deb5ae21a559..c46b7658a820 100644
>>> --- a/drivers/net/wireless/ath/ath10k/Kconfig
>>> +++ b/drivers/net/wireless/ath/ath10k/Kconfig
>>> @@ -2,6 +2,9 @@ config ATH10K
>>>   tristate "Atheros 802.11ac wireless cards support"
>>>   depends on MAC80211 && HAS_DMA
>>>  select ATH_COMMON
>>> +select MAC80211_LEDS
>>> +select LEDS_CLASS
>>> +select NEW_LEDS
>>>  select CRC32
>>>  select WANT_DEV_COREDUMP
>>>   ---help---
>>
>> Pure question: do we require LEDS, or is this an option? I assumed all
>> along it was an optional thing - ie if GPIOs and/or LEDs were
>> configured, we added this code. And if not optional, then what happens
>> if we are on a platform that can't support LEDS_CLASS or NEW_LEDS,
>> assuming there is such a thing?
>
> i took this behaviour from ath9k/ath5k, both driver auto select
> MAC80211_LEDS and LEDS_CLASS (by the way MAC80211_LEDS auto selects
> LEDS_CLASS too).  only chipsets which are known to have preconfigured leds
> are used
> and led will only turn on if you enable it in sysfs by assigning a trigger
> to the led.
> for sure this can be removed from the Kconfig. it will compile without it as
> well. so this is optional. i just added it since all other drivers behave in
> the same way.
> in addition. LEDS_CLASS  / NEW_LEDS is a kernel api, not a driver. so all
> platforms to support LEDS_CLASS. just enabling LEDS_CLASS will not cause any
> platform specific dependency.
>>
>>
>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/Makefile
>>> b/drivers/net/wireless/ath/ath10k/Makefile
>>> index 6739ac26fd29..bcb234f0b940 100644
>>> --- a/drivers/net/wireless/ath/ath10k/Makefile
>>> +++ b/drivers/net/wireless/ath/ath10k/Makefile
>>> @@ -20,6 +20,7 @@ ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o
>>>   ath10k_core-$(CONFIG_ATH10K_TRACING) += trace.o
>>>   ath10k_core-$(CONFIG_THERMAL) += thermal.o
>>>   ath10k_core-$(CONFIG_MAC80211_DEBUGFS) += debugfs_sta.o
>>> +ath10k_core-y += gpio.o
>>>   ath10k_core-$(CONFIG_PM) += wow.o
>>>   ath10k_core-$(CONFIG_DEV_COREDUMP) += coredump.o
>>>
>> I'd expect it would be something like `ath10k_core-$(CONFIG_GPIO) +=
>> gpoi.o`.  Maybe I'm mistaken.
>
> gpio.c contains the MAC80211_LEDS code and has a guard for GPIOLIB inside.
> it can be compiled even if GPIOLIB is disabled in system. (which is indeed
> platform specific)
> and leds are still supported without gpio support since it does contain a
> led only driver and a separate gpio driver.
> i suggest more somelike like
>
> ath10k_core-$(ATH10K_LEDS) += gpio.o
>
> if you want it totally optional which requires some other small changes as
> well (mainly renaming some ifdefs)
>
>> (Note, I didn't look up the actual config option name, I'm guessing.

Re: [PATCH v9] ath10k: add LED and GPIO controlling support for various chipsets

[Sebastian Gottschall]

Am 22.02.2018 um 23:17 schrieb Steve deRosier:

On Thu, Feb 22, 2018 at 3:15 AM,   wrote:

From: Sebastian Gottschall 

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall 

v2  add correct gpio count per chipset and remove IPQ4019 support since this 
chipset does not make use of specific gpios)
v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
kbuild test robot which does not occur in standard builds. curious
v6  correct return values and fix comment style
v7  fix ath10k_unregister_led for compiling without LED_CLASS
v8  fix various code design issues reported by reviewers
v9  move led and led code to separate sourcefile (gpio.c)
---
  drivers/net/wireless/ath/ath10k/Kconfig   |   3 +
  drivers/net/wireless/ath/ath10k/Makefile  |   1 +
  drivers/net/wireless/ath/ath10k/core.c|  28 -
  drivers/net/wireless/ath/ath10k/core.h|  33 -
  drivers/net/wireless/ath/ath10k/debug.c   | 142 ++
  drivers/net/wireless/ath/ath10k/gpio.c| 196 ++
  drivers/net/wireless/ath/ath10k/hw.h  |   2 +
  drivers/net/wireless/ath/ath10k/mac.c |   5 +
  drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
  drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 ++
  drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
  drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
  12 files changed, 590 insertions(+), 3 deletions(-)
  create mode 100644 drivers/net/wireless/ath/ath10k/gpio.c

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
b/drivers/net/wireless/ath/ath10k/Kconfig
index deb5ae21a559..c46b7658a820 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -2,6 +2,9 @@ config ATH10K
  tristate "Atheros 802.11ac wireless cards support"
  depends on MAC80211 && HAS_DMA
 select ATH_COMMON
+select MAC80211_LEDS
+select LEDS_CLASS
+select NEW_LEDS
 select CRC32
 select WANT_DEV_COREDUMP
  ---help---

Pure question: do we require LEDS, or is this an option? I assumed all
along it was an optional thing - ie if GPIOs and/or LEDs were
configured, we added this code. And if not optional, then what happens
if we are on a platform that can't support LEDS_CLASS or NEW_LEDS,
assuming there is such a thing?
i took this behaviour from ath9k/ath5k, both driver auto select 
MAC80211_LEDS and LEDS_CLASS (by the way MAC80211_LEDS auto selects 
LEDS_CLASS too).  only chipsets which are known to have preconfigured 
leds are used
and led will only turn on if you enable it in sysfs by assigning a 
trigger to the led.
for sure this can be removed from the Kconfig. it will compile without 
it as well. so this is optional. i just added it since all other drivers 
behave in the same way.
in addition. LEDS_CLASS  / NEW_LEDS is a kernel api, not a driver. so 
all platforms to support LEDS_CLASS. just enabling LEDS_CLASS will not 
cause any platform specific dependency.




diff --git a/drivers/net/wireless/ath/ath10k/Makefile 
b/drivers/net/wireless/ath/ath10k/Makefile
index 6739ac26fd29..bcb234f0b940 100644
--- a/drivers/net/wireless/ath/ath10k/Makefile
+++ b/drivers/net/wireless/ath/ath10k/Makefile
@@ -20,6 +20,7 @@ ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o
  ath10k_core-$(CONFIG_ATH10K_TRACING) += trace.o
  ath10k_core-$(CONFIG_THERMAL) += thermal.o
  ath10k_core-$(CONFIG_MAC80211_DEBUGFS) += debugfs_sta.o
+ath10k_core-y += gpio.o
  ath10k_core-$(CONFIG_PM) += wow.o
  ath10k_core-$(CONFIG_DEV_COREDUMP) += coredump.o


I'd expect it would be something like `ath10k_core-$(CONFIG_GPIO) +=
gpoi.o`.  Maybe I'm mistaken.
gpio.c contains the MAC80211_LEDS code and has a guard for GPIOLIB 
inside. it can be compiled even if GPIOLIB is disabled in system. (which 
is indeed platform specific)
and leds are still supported without gpio support since it does contain 
a led only driver and a separate gpio driver.

i suggest more somelike like

ath10k_core-$(ATH10K_LEDS) += gpio.o

if you want it totally optional which requires some other small changes as well 
(mainly renaming some ifdefs)


(Note, I didn't look up the actual config option name, I'm guessing.
Assume I wrote something reasonable for my example.)

I only ask the above two questions, not because I think it's wrong,
but because I don't quite know the intention and it makes me wonder.

Other than those questions, which are optional as the code looks
correct to me, the rest of it looks fine to me.
i fully understand your concerns, i just followed other drivers 
behaviour. for sure its more sane to make it 

Re: [PATCH v9] ath10k: add LED and GPIO controlling support for various chipsets

[Steve deRosier]

On Thu, Feb 22, 2018 at 3:15 AM,   wrote:
> From: Sebastian Gottschall 
>
> Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
> chipsets with on chipset connected led's
> using WMI Firmware API.
> The LED device will get available named as "ath10k-phyX" at sysfs and can be 
> controlled with various triggers.
> adds also debugfs interface for gpio control.
>
> Signed-off-by: Sebastian Gottschall 
>
> v2  add correct gpio count per chipset and remove IPQ4019 support since this 
> chipset does not make use of specific gpios)
> v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
> kbuild test robot which does not occur in standard builds. curious
> v6  correct return values and fix comment style
> v7  fix ath10k_unregister_led for compiling without LED_CLASS
> v8  fix various code design issues reported by reviewers
> v9  move led and led code to separate sourcefile (gpio.c)
> ---
>  drivers/net/wireless/ath/ath10k/Kconfig   |   3 +
>  drivers/net/wireless/ath/ath10k/Makefile  |   1 +
>  drivers/net/wireless/ath/ath10k/core.c|  28 -
>  drivers/net/wireless/ath/ath10k/core.h|  33 -
>  drivers/net/wireless/ath/ath10k/debug.c   | 142 ++
>  drivers/net/wireless/ath/ath10k/gpio.c| 196 
> ++
>  drivers/net/wireless/ath/ath10k/hw.h  |   2 +
>  drivers/net/wireless/ath/ath10k/mac.c |   5 +
>  drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
>  drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 ++
>  drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
>  drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
>  12 files changed, 590 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/net/wireless/ath/ath10k/gpio.c
>
> diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
> b/drivers/net/wireless/ath/ath10k/Kconfig
> index deb5ae21a559..c46b7658a820 100644
> --- a/drivers/net/wireless/ath/ath10k/Kconfig
> +++ b/drivers/net/wireless/ath/ath10k/Kconfig
> @@ -2,6 +2,9 @@ config ATH10K
>  tristate "Atheros 802.11ac wireless cards support"
>  depends on MAC80211 && HAS_DMA
> select ATH_COMMON
> +select MAC80211_LEDS
> +select LEDS_CLASS
> +select NEW_LEDS
> select CRC32
> select WANT_DEV_COREDUMP
>  ---help---

Pure question: do we require LEDS, or is this an option? I assumed all
along it was an optional thing - ie if GPIOs and/or LEDs were
configured, we added this code. And if not optional, then what happens
if we are on a platform that can't support LEDS_CLASS or NEW_LEDS,
assuming there is such a thing?


> diff --git a/drivers/net/wireless/ath/ath10k/Makefile 
> b/drivers/net/wireless/ath/ath10k/Makefile
> index 6739ac26fd29..bcb234f0b940 100644
> --- a/drivers/net/wireless/ath/ath10k/Makefile
> +++ b/drivers/net/wireless/ath/ath10k/Makefile
> @@ -20,6 +20,7 @@ ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o
>  ath10k_core-$(CONFIG_ATH10K_TRACING) += trace.o
>  ath10k_core-$(CONFIG_THERMAL) += thermal.o
>  ath10k_core-$(CONFIG_MAC80211_DEBUGFS) += debugfs_sta.o
> +ath10k_core-y += gpio.o
>  ath10k_core-$(CONFIG_PM) += wow.o
>  ath10k_core-$(CONFIG_DEV_COREDUMP) += coredump.o
>

I'd expect it would be something like `ath10k_core-$(CONFIG_GPIO) +=
gpoi.o`.  Maybe I'm mistaken.
(Note, I didn't look up the actual config option name, I'm guessing.
Assume I wrote something reasonable for my example.)

I only ask the above two questions, not because I think it's wrong,
but because I don't quite know the intention and it makes me wonder.

Other than those questions, which are optional as the code looks
correct to me, the rest of it looks fine to me.

Reviewed-by: Steve deRosier 

- Steve

[PATCH] rtlwifi: rtl8723be: Fix loss of signal

[Larry Finger]

In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem
correctly") a problem in rtl8821ae that caused loss of signal was fixed.
That same problem has now been reported for rtl8723be. Accordingly,
the ASPM L1 latency has been increased from 0 to 7 to fix the instability.

Signed-off-by: Larry Finger 
Cc: Stable 
---
Kalle,

This patch should be sent to 4.16.

Thanks,
Larry
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
index f9ccd13c79f9..e7bbbc95cdb1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c
@@ -1125,7 +1125,8 @@ static void _rtl8723be_enable_aspm_back_door(struct 
ieee80211_hw *hw)
 
/* Configuration Space offset 0x70f BIT7 is used to control L0S */
tmp8 = _rtl8723be_dbi_read(rtlpriv, 0x70f);
-   _rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7));
+   _rtl8723be_dbi_write(rtlpriv, 0x70f, tmp8 | BIT(7) |
+ASPM_L1_LATENCY << 3);
 
/* Configuration Space offset 0x719 Bit3 is for L1
 * BIT4 is for clock request
-- 
2.16.2

Re: pull-request: mac80211-next 2018-02-22

[Johannes Berg]

On Thu, 2018-02-22 at 15:19 -0500, David Miller wrote:
> From: Johannes Berg 
> Date: Thu, 22 Feb 2018 21:16:18 +0100
> 
> > Wireless is slow ... but we're preparing for HE (802.11ax),
> > so I guess soon we'll have a big chunk of work coming :-)
> 
> I wondered where you guys have been hiding :-)

Yeah, I don't like this development model much, but the spec isn't
finished yet and every time I look at an area I end up changing it
*again* which isn't fun to do upstream :-)

(Was just doing the HE sniffer stuff in radiotap these days ... uh,
yeah, I've more or less rewritten it twice already - hopefully no more)

johannes

Re: pull-request: mac80211-next 2018-02-22

[David Miller]

From: Johannes Berg 
Date: Thu, 22 Feb 2018 21:16:18 +0100

> Wireless is slow ... but we're preparing for HE (802.11ax),
> so I guess soon we'll have a big chunk of work coming :-)

I wondered where you guys have been hiding :-)

> Please pull and let me know if there's any problem.

Pulled, thank you!

Re: pull-request: mac80211 2018-02-22

[David Miller]

From: Johannes Berg 
Date: Thu, 22 Feb 2018 21:08:39 +0100

> A bunch of fixes, including the nla_put_string() issue
> just in from Kees. Otherwise nothing really super urgent
> or interesting.
> 
> Please pull and let me know if there's any problem.

Pulled.

Thanks for taking care of that NLA_STRING thing so fast.

pull-request: mac80211-next 2018-02-22

[Johannes Berg]

Hi Dave,

Wireless is slow ... but we're preparing for HE (802.11ax),
so I guess soon we'll have a big chunk of work coming :-)

Please pull and let me know if there's any problem.

Thanks,
johannes



The following changes since commit 91e6dd8284256ef62b43b78da6e7684e4f06ac2f:

  ipmr: Fix ptrdiff_t print formatting (2018-01-30 09:20:25 -0500)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
tags/mac80211-next-for-davem-2018-02-22

for you to fetch changes up to 94ba92713f8329c96e0a8e2880b3c1a785d1c95c:

  mac80211: Call mgd_prep_tx before transmitting deauthentication (2018-02-22 
21:13:04 +0100)


Various updates across wireless.

One thing to note: I've included a new ethertype
that wireless uses (ETH_P_PREAUTH) in if_ether.h.


Ben Greear (1):
  mac80211: Add txq flags to debugfs

Benjamin Beichler (3):
  mac80211_hwsim: add permanent mac address option for new radios
  mac80211_hwsim: add nl_err_msg in hwsim_new_radio in netlink case
  mac80211_hwsim: add generation count for netlink dump operation

Colin Ian King (1):
  mac80211: remove redundant initialization to pointer 'hdr'

Denis Kenzior (1):
  uapi: Add 802.11 Preauthentication to if_ether

Ilan Peer (1):
  mac80211: Call mgd_prep_tx before transmitting deauthentication

Johannes Berg (2):
  nl80211: remove unnecessary genlmsg_cancel() calls
  mac80211: support reporting A-MPDU EOF bit value/known

Sara Sharon (1):
  mac80211: add get TID helper

Srinivas Dasari (4):
  cfg80211/nl80211: Optional authentication offload to userspace
  nl80211: Allow SAE Authentication for NL80211_CMD_CONNECT
  nl80211: Fix external_auth check for offloaded authentication
  ieee80211: Increase PMK maximum length to 64 bytes

Sunil Dutt (1):
  nl80211: Introduce scan flags to emphasize requested scan behavior

Venkateswara Naralasetty (2):
  cfg80211: send ack_signal to user in probe client response
  mac80211: Add tx ack signal support in sta info

tami...@codeaurora.org (2):
  cfg80211: Add support to notify station's opmode change to userspace
  mac80211: Add support to notify ht/vht opmode modification.

 drivers/net/wireless/ath/wil6210/cfg80211.c |   3 +-
 drivers/net/wireless/mac80211_hwsim.c   |  81 ---
 drivers/net/wireless/mac80211_hwsim.h   |   9 +-
 include/linux/ieee80211.h   |  14 +-
 include/net/cfg80211.h  | 104 +-
 include/net/ieee80211_radiotap.h|   2 +
 include/net/mac80211.h  |  19 +++
 include/uapi/linux/if_ether.h   |   1 +
 include/uapi/linux/nl80211.h|  90 +++-
 net/mac80211/debugfs.c  |   1 +
 net/mac80211/debugfs_sta.c  |  10 +-
 net/mac80211/iface.c|   3 +-
 net/mac80211/michael.c  |   2 +-
 net/mac80211/mlme.c |  18 ++-
 net/mac80211/rc80211_minstrel_ht.c  |   2 +-
 net/mac80211/rx.c   |  24 +++-
 net/mac80211/sta_info.c |   6 +
 net/mac80211/sta_info.h |   2 +
 net/mac80211/status.c   |  11 +-
 net/mac80211/tx.c   |  11 +-
 net/mac80211/vht.c  |   9 ++
 net/mac80211/wpa.c  |   8 +-
 net/wireless/nl80211.c  | 203 +++-
 net/wireless/rdev-ops.h |  15 ++
 net/wireless/trace.h|  23 
 25 files changed, 584 insertions(+), 87 deletions(-)

pull-request: mac80211 2018-02-22

[Johannes Berg]

Hi Dave,

A bunch of fixes, including the nla_put_string() issue
just in from Kees. Otherwise nothing really super urgent
or interesting.

Please pull and let me know if there's any problem.

Thanks,
johannes



The following changes since commit ba804bb4b72e57374b5f567b783aa0298fba0ce6:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-01-26 
09:03:16 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2018-02-22

for you to fetch changes up to 657308f73e674e86b60509a430a46e569bf02846:

  regulatory: add NUL to request alpha2 (2018-02-22 20:57:48 +0100)


Various fixes across the tree, the shortlog basically says it all:

  cfg80211: fix cfg80211_beacon_dup
  -> old bug in this code

  cfg80211: clear wep keys after disconnection
  -> certain ways of disconnecting left the keys

  mac80211: round IEEE80211_TX_STATUS_HEADROOM up to multiple of 4
  -> alignment issues with using 14 bytes

  mac80211: Do not disconnect on invalid operating class
  -> if the AP has a bogus operating class, let it be

  mac80211: Fix sending ADDBA response for an ongoing session
  -> don't send the same frame twice

  cfg80211: use only 1Mbps for basic rates in mesh
  -> interop issue with old versions of our code

  mac80211_hwsim: don't use WQ_MEM_RECLAIM
  -> it causes splats because it flushes work on a non-reclaim WQ

  regulatory: add NUL to request alpha2
  -> nla_put_string() issue from Kees

  mac80211: mesh: fix wrong mesh TTL offset calculation
  -> protocol issue

  mac80211: fix a possible leak of station stats
  -> error path might leak memory

  mac80211: fix calling sleeping function in atomic context
  -> percpu allocations need to be made with gfp flags


Arnd Bergmann (1):
  cfg80211: fix cfg80211_beacon_dup

Avraham Stern (1):
  cfg80211: clear wep keys after disconnection

Felix Fietkau (1):
  mac80211: round IEEE80211_TX_STATUS_HEADROOM up to multiple of 4

Ilan Peer (2):
  mac80211: Do not disconnect on invalid operating class
  mac80211: Fix sending ADDBA response for an ongoing session

Johannes Berg (3):
  cfg80211: use only 1Mbps for basic rates in mesh
  mac80211_hwsim: don't use WQ_MEM_RECLAIM
  regulatory: add NUL to request alpha2

Peter Oh (1):
  mac80211: mesh: fix wrong mesh TTL offset calculation

Sara Sharon (2):
  mac80211: fix a possible leak of station stats
  mac80211: fix calling sleeping function in atomic context

 drivers/net/wireless/mac80211_hwsim.c |  2 +-
 include/net/mac80211.h|  2 +-
 include/net/regulatory.h  |  2 +-
 net/mac80211/agg-rx.c |  4 +---
 net/mac80211/cfg.c|  2 +-
 net/mac80211/ieee80211_i.h|  2 +-
 net/mac80211/mesh.c   | 17 ++---
 net/mac80211/spectmgmt.c  |  7 +++
 net/mac80211/sta_info.c   |  3 ++-
 net/wireless/mesh.c   | 25 ++---
 net/wireless/sme.c|  2 ++
 11 files changed, 41 insertions(+), 27 deletions(-)

[PATCH] regulatory: add NUL to request alpha2

[Johannes Berg]

From: Johannes Berg 

Similar to the ancient commit a5fe8e7695dc ("regulatory: add NUL
to alpha2"), add another byte to alpha2 in the request struct so
that when we use nla_put_string(), we don't overrun anything.

Fixes: 73d54c9e74c4 ("cfg80211: add regulatory netlink multicast group")
Reported-by: Kees Cook 
Signed-off-by: Johannes Berg 
---
 include/net/regulatory.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/regulatory.h b/include/net/regulatory.h
index ebc5a2ed8631..f83cacce3308 100644
--- a/include/net/regulatory.h
+++ b/include/net/regulatory.h
@@ -78,7 +78,7 @@ struct regulatory_request {
int wiphy_idx;
enum nl80211_reg_initiator initiator;
enum nl80211_user_reg_hint_type user_reg_hint_type;
-   char alpha2[2];
+   char alpha2[3];
enum nl80211_dfs_regions dfs_region;
bool intersect;
bool processed;
-- 
2.15.1

Re: [PATCH 2/3] mwifiex: support sysfs initiated device coredump

[Brian Norris]

Hi Arend,

On Thu, Feb 22, 2018 at 01:17:56PM +0100, Arend van Spriel wrote:
> On 2/21/2018 11:59 PM, Brian Norris wrote:
> > On Wed, Feb 21, 2018 at 11:50:19AM +0100, Arend van Spriel wrote:
> > > Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops")
> > > it is possible to initiate a device coredump from user-space. This
> > > patch adds support for it adding the .coredump() driver callback.
> > > As there is no longer a need to initiate it through debugfs remove
> > > that code.
> > > 
> > > Signed-off-by: Arend van Spriel 
> > > ---
> > >   drivers/net/wireless/marvell/mwifiex/debugfs.c | 31 
> > > +-
> > >   drivers/net/wireless/marvell/mwifiex/pcie.c| 19 ++--
> > >   drivers/net/wireless/marvell/mwifiex/sdio.c| 13 +++
> > >   drivers/net/wireless/marvell/mwifiex/usb.c | 14 
> > >   4 files changed, 45 insertions(+), 32 deletions(-)
> > 
> > The documentation doesn't really say [1], but is the coredump supposed
> > to happen synchronously? Because the mwifiex implementation is
> > asynchronous, whereas it looks like the brcmfmac one is synchronous.
> 
> Well, that depends on the eye of the beholder I guess. From user-space
> perspective it is asynchronous regardless. A write access to the coredump
> sysfs file eventually results in a uevent when the devcoredump entry is
> created, ie. after driver has made a dev_coredump API call. Whether the
> driver does that synchronously or asynchronously is irrelevant as far as
> user-space is concerned.

Is it really? The driver infrastructure seems to guarantee that the
entirety of a driver's ->coredump() will complete before returning from
the write. So it might be reasonable for some user to assume (based on
implementation details, e.g., of brcmfmac) that the devcoredump will be
ready by the time the write() syscall returns, absent documentation that
says otherwise. But then, that's not how mwifiex works right now, so
they might be surprised if they switch drivers.

Anyway, *I'm* already personally used to these dumps being asynchronous,
and writing tooling to listen for the uevent instead. But that doesn't
mean everyone will be.

Also, due to the differences in async/sync, mwifiex doesn't really
provide you much chance for error handling, because most errors would be
asynchronous. So brcmfmac's "coredump" has more chance for user programs
to error-check than mwifiex's (due to the asynchronous nature) [1].

BTW, I push on this mostly because this is migrating from a debugfs
feature (that is easy to hand-wave off as not really providing a
consistent/stable API, etc., etc.) to a documented sysfs feature. If it
were left to rot in debugfs, I probably wouldn't be as bothered ;)

> > Brian
> > 
> > [1] In fact, the ABI documentation really just describes kernel
> > internals, rather than documenting any user-facing details, from what I
> > can tell.
> 
> You are right. Clearly I did not reach the end my learning curve here. I
> assumed referring to the existing dev_coredump facility was sufficient, but
> maybe it is worth a patch to be more explicit and mention the uevent
> behavior. Also dev_coredump facility may be disabled upon which the trigger
> will have no effect in sysfs. In the kernel the data passed by the driver is
> simply freed by dev_coredump facility.

Is there any other documentation for the coredump feature? I don't
really see much.

Brian

[1] Oh wait, but I see that while ->coredump() has an integer return
code...the caller ignores it:

static ssize_t coredump_store(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
device_lock(dev);
if (dev->driver->coredump)
dev->driver->coredump(dev);
device_unlock(dev);

return count;
}
static DEVICE_ATTR_WO(coredump);

Is that a bug or a feature?

ath9k: AR9287 device with little endian eeprom doesn't work on powerpc

[Bas Vermeulen]

Hi all,

I have slotted a 300 Mbps Wireless N PCI Express Adapter into my 
PowerMac G5, and it failed

to initialize the driver with an error complaining about the EEPROM.

I disabled the line reading ah->ah_flags |= AH_NO_EEP_SWAP; in 
ath9k_of_init(), and this made my card show up and start working correctly.


Is there a better way of doing this? If not, what would be the best way 
to allow byte-swapping the eeprom on big endian machines?


Bas Vermeulen


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [PATCH 0/4] staging: wilc1000: modify functions by making use of GENMASK macro

[Ajay Singh]

Please ignore this patch series, I will work on review comments and submit
another version later.
 
Regards,
Ajay

Re: [PATCH 2/3] mwifiex: support sysfs initiated device coredump

[Arend van Spriel]

On 2/21/2018 11:59 PM, Brian Norris wrote:

On Wed, Feb 21, 2018 at 11:50:19AM +0100, Arend van Spriel wrote:

Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops")
it is possible to initiate a device coredump from user-space. This
patch adds support for it adding the .coredump() driver callback.
As there is no longer a need to initiate it through debugfs remove
that code.

Signed-off-by: Arend van Spriel 
---
  drivers/net/wireless/marvell/mwifiex/debugfs.c | 31 +-
  drivers/net/wireless/marvell/mwifiex/pcie.c| 19 ++--
  drivers/net/wireless/marvell/mwifiex/sdio.c| 13 +++
  drivers/net/wireless/marvell/mwifiex/usb.c | 14 
  4 files changed, 45 insertions(+), 32 deletions(-)


The documentation doesn't really say [1], but is the coredump supposed
to happen synchronously? Because the mwifiex implementation is
asynchronous, whereas it looks like the brcmfmac one is synchronous.


Well, that depends on the eye of the beholder I guess. From user-space 
perspective it is asynchronous regardless. A write access to the 
coredump sysfs file eventually results in a uevent when the devcoredump 
entry is created, ie. after driver has made a dev_coredump API call. 
Whether the driver does that synchronously or asynchronously is 
irrelevant as far as user-space is concerned.



Brian

[1] In fact, the ABI documentation really just describes kernel
internals, rather than documenting any user-facing details, from what I
can tell.


You are right. Clearly I did not reach the end my learning curve here. I 
assumed referring to the existing dev_coredump facility was sufficient, 
but maybe it is worth a patch to be more explicit and mention the uevent 
behavior. Also dev_coredump facility may be disabled upon which the 
trigger will have no effect in sysfs. In the kernel the data passed by 
the driver is simply freed by dev_coredump facility.


Regards,
Arend

Re: [PULL] ath10k firmware 20180219

[Josh Boyer]

On Thu, Feb 22, 2018 at 5:44 AM, Kalle Valo  wrote:
> Hi linux-firmware maintainers,
>
> here's a pull request for updating ath10k firmwares. Earlier I have been
> submitting these as patches but as the patches got pretty big I decided
> to try using pull requests instead.

Pull requests are easier to work with as well, so thanks.  Merged and
pushed out.

josh

> Please let me know if there are any problems.
>
> Kalle
>
> The following changes since commit 6d5131107f2ba67a13f469ac770a55f101ba654d:
>
>   rtl_bt: Add firmware and configuration files for the Bluetooth parts of 
> RTL8821C and RTL8723D (2018-02-13 13:09:19 -0500)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/linux-firmware.git 
> ath10k-20180219
>
> for you to fetch changes up to 9b3d016886a8e365f9493a724bf2945b97bcfe43:
>
>   ath10k: QCA9984 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053 
> (2018-02-19 12:03:36 +0200)
>
> 
> Kalle Valo (9):
>   ath10k: QCA4019 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053
>   ath10k: QCA4019 hw1.0: update board-2.bin
>   ath10k: QCA6174 hw3.0: update firmware-6.bin to 
> WLAN.RM.4.4.1-00079-QCARMSWPZ-1
>   ath10k: QCA6174 hw3.0: update board-2.bin
>   ath10k: QCA9377 hw1.0: update firmware-5.bin to 
> WLAN.TF.1.0-2-QCATFSWPZ-5
>   ath10k: QCA9887 hw1.0: update firmware-5.bin to 10.2.4-1.0-00037
>   ath10k: QCA9888 hw2.0: update firmware-5.bin to 10.4-3.5.3-00053
>   ath10k: QCA988X hw2.0: update firmware-5.bin to 10.2.4-1.0-00037
>   ath10k: QCA9984 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053
>
>  WHENCE|  14 ++--
>  ath10k/QCA4019/hw1.0/board-2.bin  | Bin 109172 -> 133452 
> bytes
>  ath10k/QCA4019/hw1.0/firmware-5.bin   | Bin 535412 -> 568636 
> bytes
>  ath10k/QCA6174/hw3.0/board-2.bin  | Bin 501748 -> 551128 
> bytes
>  ath10k/QCA6174/hw3.0/firmware-6.bin   | Bin 727776 -> 730788 
> bytes
>  ath10k/QCA9377/hw1.0/firmware-5.bin   | Bin 605908 -> 783336 
> bytes
>  ath10k/QCA9377/hw1.0/notice_ath10k_firmware-5.txt |   4 ++--
>  ath10k/QCA9887/hw1.0/firmware-5.bin   | Bin 235880 -> 237584 
> bytes
>  ath10k/QCA9888/hw2.0/firmware-5.bin   | Bin 647460 -> 659708 
> bytes
>  ath10k/QCA988X/hw2.0/firmware-5.bin   | Bin 248188 -> 248108 
> bytes
>  ath10k/QCA988X/hw2.0/notice_ath10k_firmware-5.txt |  25 
> ++
>  ath10k/QCA9984/hw1.0/firmware-5.bin   | Bin 622060 -> 647380 
> bytes
>  12 files changed, 20 insertions(+), 23 deletions(-)

[PATCH v9] ath10k: add LED and GPIO controlling support for various chipsets

[s . gottschall]

From: Sebastian Gottschall 

Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based 
chipsets with on chipset connected led's
using WMI Firmware API.
The LED device will get available named as "ath10k-phyX" at sysfs and can be 
controlled with various triggers.
adds also debugfs interface for gpio control.

Signed-off-by: Sebastian Gottschall 

v2  add correct gpio count per chipset and remove IPQ4019 support since this 
chipset does not make use of specific gpios)
v5  fix compiling without LED_CLASS and GPIOLIB support, fix also error by 
kbuild test robot which does not occur in standard builds. curious
v6  correct return values and fix comment style
v7  fix ath10k_unregister_led for compiling without LED_CLASS
v8  fix various code design issues reported by reviewers
v9  move led and led code to separate sourcefile (gpio.c)
---
 drivers/net/wireless/ath/ath10k/Kconfig   |   3 +
 drivers/net/wireless/ath/ath10k/Makefile  |   1 +
 drivers/net/wireless/ath/ath10k/core.c|  28 -
 drivers/net/wireless/ath/ath10k/core.h|  33 -
 drivers/net/wireless/ath/ath10k/debug.c   | 142 ++
 drivers/net/wireless/ath/ath10k/gpio.c| 196 ++
 drivers/net/wireless/ath/ath10k/hw.h  |   2 +
 drivers/net/wireless/ath/ath10k/mac.c |   5 +
 drivers/net/wireless/ath/ath10k/wmi-ops.h |  36 +-
 drivers/net/wireless/ath/ath10k/wmi-tlv.c |  65 ++
 drivers/net/wireless/ath/ath10k/wmi.c |  46 +++
 drivers/net/wireless/ath/ath10k/wmi.h |  36 ++
 12 files changed, 590 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/wireless/ath/ath10k/gpio.c

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
b/drivers/net/wireless/ath/ath10k/Kconfig
index deb5ae21a559..c46b7658a820 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -2,6 +2,9 @@ config ATH10K
 tristate "Atheros 802.11ac wireless cards support"
 depends on MAC80211 && HAS_DMA
select ATH_COMMON
+select MAC80211_LEDS
+select LEDS_CLASS
+select NEW_LEDS
select CRC32
select WANT_DEV_COREDUMP
 ---help---
diff --git a/drivers/net/wireless/ath/ath10k/Makefile 
b/drivers/net/wireless/ath/ath10k/Makefile
index 6739ac26fd29..bcb234f0b940 100644
--- a/drivers/net/wireless/ath/ath10k/Makefile
+++ b/drivers/net/wireless/ath/ath10k/Makefile
@@ -20,6 +20,7 @@ ath10k_core-$(CONFIG_NL80211_TESTMODE) += testmode.o
 ath10k_core-$(CONFIG_ATH10K_TRACING) += trace.o
 ath10k_core-$(CONFIG_THERMAL) += thermal.o
 ath10k_core-$(CONFIG_MAC80211_DEBUGFS) += debugfs_sta.o
+ath10k_core-y += gpio.o
 ath10k_core-$(CONFIG_PM) += wow.o
 ath10k_core-$(CONFIG_DEV_COREDUMP) += coredump.o
 
diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index f3ec13b80b20..d7f89ca98c2d 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -21,6 +21,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+
 
 #include "core.h"
 #include "mac.h"
@@ -65,6 +69,8 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID,
.name = "qca988x hw2.0",
+   .led_pin = 1,
+   .gpio_count = 24, 
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -94,6 +100,8 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] 
= {
.id = QCA988X_HW_2_0_VERSION,
.dev_id = QCA988X_2_0_DEVICE_ID_UBNT,
.name = "qca988x hw2.0 ubiquiti",
+   .led_pin = 1,
+   .gpio_count = 24, 
.patch_load_addr = QCA988X_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -123,6 +131,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA9887_HW_1_0_VERSION,
.dev_id = QCA9887_1_0_DEVICE_ID,
.name = "qca9887 hw1.0",
+   .led_pin = 1,
+   .gpio_count = 24, 
.patch_load_addr = QCA9887_HW_1_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.cc_wraparound_type = ATH10K_HW_CC_WRAP_SHIFTED_ALL,
@@ -267,6 +277,8 @@ static const struct ath10k_hw_params 
ath10k_hw_params_list[] = {
.id = QCA99X0_HW_2_0_DEV_VERSION,
.dev_id = QCA99X0_2_0_DEVICE_ID,
.name = "qca99x0 hw2.0",
+   .led_pin = 17,
+   .gpio_count = 35, 
.patch_load_addr = QCA99X0_HW_2_0_PATCH_LOAD_ADDR,
.uart_pin = 7,
.otp_exe_param = 0x0700,
@@ -301,6 

Re: [PULL] ath10k firmware 20180219

[Sebastian Gottschall]

on 9984 i see these messages with this firmware from time to time

[272972.950788] ath10k_pci :01:00.0: Unknown eventid: 36925
[272982.868922] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.123780] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.156332] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.158813] ath10k_pci :01:00.0: Unknown eventid: 36925
[335550.193144] ath10k_pci :01:00.0: Unknown eventid: 36925
[365157.869540] ath10k_pci :01:00.0: Unknown eventid: 36925
[365157.902452] ath10k_pci :01:00.0: Unknown eventid: 36925


according to the WMI header this maybe a critical internal error

Am 22.02.2018 um 11:44 schrieb Kalle Valo:

Hi linux-firmware maintainers,

here's a pull request for updating ath10k firmwares. Earlier I have been
submitting these as patches but as the patches got pretty big I decided
to try using pull requests instead.

Please let me know if there are any problems.

Kalle

The following changes since commit 6d5131107f2ba67a13f469ac770a55f101ba654d:

   rtl_bt: Add firmware and configuration files for the Bluetooth parts of 
RTL8821C and RTL8723D (2018-02-13 13:09:19 -0500)

are available in the git repository at:

   git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/linux-firmware.git 
ath10k-20180219

for you to fetch changes up to 9b3d016886a8e365f9493a724bf2945b97bcfe43:

   ath10k: QCA9984 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053 (2018-02-19 
12:03:36 +0200)


Kalle Valo (9):
   ath10k: QCA4019 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053
   ath10k: QCA4019 hw1.0: update board-2.bin
   ath10k: QCA6174 hw3.0: update firmware-6.bin to 
WLAN.RM.4.4.1-00079-QCARMSWPZ-1
   ath10k: QCA6174 hw3.0: update board-2.bin
   ath10k: QCA9377 hw1.0: update firmware-5.bin to 
WLAN.TF.1.0-2-QCATFSWPZ-5
   ath10k: QCA9887 hw1.0: update firmware-5.bin to 10.2.4-1.0-00037
   ath10k: QCA9888 hw2.0: update firmware-5.bin to 10.4-3.5.3-00053
   ath10k: QCA988X hw2.0: update firmware-5.bin to 10.2.4-1.0-00037
   ath10k: QCA9984 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053

  WHENCE|  14 ++--
  ath10k/QCA4019/hw1.0/board-2.bin  | Bin 109172 -> 133452 bytes
  ath10k/QCA4019/hw1.0/firmware-5.bin   | Bin 535412 -> 568636 bytes
  ath10k/QCA6174/hw3.0/board-2.bin  | Bin 501748 -> 551128 bytes
  ath10k/QCA6174/hw3.0/firmware-6.bin   | Bin 727776 -> 730788 bytes
  ath10k/QCA9377/hw1.0/firmware-5.bin   | Bin 605908 -> 783336 bytes
  ath10k/QCA9377/hw1.0/notice_ath10k_firmware-5.txt |   4 ++--
  ath10k/QCA9887/hw1.0/firmware-5.bin   | Bin 235880 -> 237584 bytes
  ath10k/QCA9888/hw2.0/firmware-5.bin   | Bin 647460 -> 659708 bytes
  ath10k/QCA988X/hw2.0/firmware-5.bin   | Bin 248188 -> 248108 bytes
  ath10k/QCA988X/hw2.0/notice_ath10k_firmware-5.txt |  25 ++
  ath10k/QCA9984/hw1.0/firmware-5.bin   | Bin 622060 -> 647380 bytes
  12 files changed, 20 insertions(+), 23 deletions(-)



--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

[PULL] ath10k firmware 20180219

[Kalle Valo]

Hi linux-firmware maintainers,

here's a pull request for updating ath10k firmwares. Earlier I have been
submitting these as patches but as the patches got pretty big I decided
to try using pull requests instead.

Please let me know if there are any problems.

Kalle

The following changes since commit 6d5131107f2ba67a13f469ac770a55f101ba654d:

  rtl_bt: Add firmware and configuration files for the Bluetooth parts of 
RTL8821C and RTL8723D (2018-02-13 13:09:19 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/linux-firmware.git 
ath10k-20180219

for you to fetch changes up to 9b3d016886a8e365f9493a724bf2945b97bcfe43:

  ath10k: QCA9984 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053 (2018-02-19 
12:03:36 +0200)


Kalle Valo (9):
  ath10k: QCA4019 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053
  ath10k: QCA4019 hw1.0: update board-2.bin
  ath10k: QCA6174 hw3.0: update firmware-6.bin to 
WLAN.RM.4.4.1-00079-QCARMSWPZ-1
  ath10k: QCA6174 hw3.0: update board-2.bin
  ath10k: QCA9377 hw1.0: update firmware-5.bin to 
WLAN.TF.1.0-2-QCATFSWPZ-5
  ath10k: QCA9887 hw1.0: update firmware-5.bin to 10.2.4-1.0-00037
  ath10k: QCA9888 hw2.0: update firmware-5.bin to 10.4-3.5.3-00053
  ath10k: QCA988X hw2.0: update firmware-5.bin to 10.2.4-1.0-00037
  ath10k: QCA9984 hw1.0: update firmware-5.bin to 10.4-3.5.3-00053

 WHENCE|  14 ++--
 ath10k/QCA4019/hw1.0/board-2.bin  | Bin 109172 -> 133452 bytes
 ath10k/QCA4019/hw1.0/firmware-5.bin   | Bin 535412 -> 568636 bytes
 ath10k/QCA6174/hw3.0/board-2.bin  | Bin 501748 -> 551128 bytes
 ath10k/QCA6174/hw3.0/firmware-6.bin   | Bin 727776 -> 730788 bytes
 ath10k/QCA9377/hw1.0/firmware-5.bin   | Bin 605908 -> 783336 bytes
 ath10k/QCA9377/hw1.0/notice_ath10k_firmware-5.txt |   4 ++--
 ath10k/QCA9887/hw1.0/firmware-5.bin   | Bin 235880 -> 237584 bytes
 ath10k/QCA9888/hw2.0/firmware-5.bin   | Bin 647460 -> 659708 bytes
 ath10k/QCA988X/hw2.0/firmware-5.bin   | Bin 248188 -> 248108 bytes
 ath10k/QCA988X/hw2.0/notice_ath10k_firmware-5.txt |  25 ++
 ath10k/QCA9984/hw1.0/firmware-5.bin   | Bin 622060 -> 647380 bytes
 12 files changed, 20 insertions(+), 23 deletions(-)

[PATCH v2] iw: Print TXQ statistics for stations and interfaces

[Toke Høiland-Jørgensen]

This adds printing of TXQ statistics for stations and interfaces when
supplied by the kernel. For stations, another section is added when verbose
mode is enabled; for interfaces, the multicast queue information is always
printed when available.

This is the information also available through debugfs in
/sys/kernel/debug/ieee80211/phyX/netdev:Y/aqm and
/sys/kernel/debug/ieee80211/phyX/netdev:Y/stations/*/aqm.

Sample output:

$ iw dev wlp2s0 station dump -v
Station xx:xx:xx:xx:xx:xx (on wlp2s0)
[...]
TXQs:
TID qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol 
tx-bytestx-packets
0   0   0   0   0   0   0   0   
0   0
1   0   0   0   0   0   0   0   
0   0
2   0   0   0   0   0   0   0   
0   0
3   0   0   0   0   0   0   0   
0   0
4   0   0   0   0   0   0   0   
0   0
5   0   0   0   0   0   0   0   
0   0
6   0   0   0   0   0   0   0   
0   0
7   0   0   0   0   0   0   0   
0   0
8   0   0   0   0   0   0   0   
0   0
9   0   0   0   0   0   0   0   
0   0
10  0   0   0   0   0   0   0   
0   0
11  0   0   0   0   0   0   0   
0   0
12  0   0   0   0   0   0   0   
0   0
13  0   0   0   0   0   0   0   
0   0
14  0   0   0   0   0   0   0   
0   0
15  0   0   0   0   0   0   0   
0   0
[...]

$ iw dev wlp2s0 info
Interface wlp2s0
ifindex 9
wdev 0x1
addr xx:xx:xx:xx:xx:xx
type AP
wiphy 0
channel 165 (5825 MHz), width: 20 MHz, center1: 5825 MHz
txpower 24.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol 
tx-bytestx-packets
0   0   72  0   0   0   0   7380
72

Signed-off-by: Toke Høiland-Jørgensen 
---
v2:
  - Correctly handle variable indent of 'iw dev' output

 interface.c |  6 +
 iw.h|  2 ++
 station.c   | 88 -
 3 files changed, 95 insertions(+), 1 deletion(-)

diff --git a/interface.c b/interface.c
index a19c83f..712bbdc 100644
--- a/interface.c
+++ b/interface.c
@@ -441,6 +441,12 @@ static int print_iface_handler(struct nl_msg *msg, void 
*arg)
   indent, txp / 100, txp % 100);
}
 
+   if (tb_msg[NL80211_ATTR_TXQ_STATS]) {
+   char buf[150];
+   parse_txq_stats(buf, sizeof(buf), 
tb_msg[NL80211_ATTR_TXQ_STATS], 1, -1, indent);
+   printf("%s\tmulticast TXQ:%s\n", indent, buf);
+   }
+
return NL_SKIP;
 }
 
diff --git a/iw.h b/iw.h
index ee7ca20..47aa27d 100644
--- a/iw.h
+++ b/iw.h
@@ -183,6 +183,8 @@ unsigned char *parse_hex(char *hex, size_t *outlen);
 int parse_keys(struct nl_msg *msg, char **argv, int argc);
 int parse_freqchan(struct chandef *chandef, bool chan, int argc, char **argv, 
int *parsed);
 enum nl80211_chan_width str_to_bw(const char *str);
+int parse_txq_stats(char *buf, int buflen, struct nlattr *tid_stats_attr, int 
header,
+   int tid, const char *indent);
 int put_chandef(struct nl_msg *msg, struct chandef *chandef);
 
 void print_ht_mcs(const __u8 *mcs);
diff --git a/station.c b/station.c
index f836d0a..0d2c1ba 100644
--- a/station.c
+++ b/station.c
@@ -43,6 +43,79 @@ static void print_power_mode(struct nlattr *a)
}
 }
 
+int parse_txq_stats(char *buf, int buflen, struct nlattr *tid_stats_attr, int 
header,
+   int tid, const char *indent)
+{
+   struct nlattr *txqstats_info[NL80211_TXQ_STATS_MAX + 1], *txqinfo;
+   static struct nla_policy txqstats_policy[NL80211_TXQ_STATS_MAX + 1] = {
+   [NL80211_TXQ_STATS_BACKLOG_BYTES] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_BACKLOG_PACKETS] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_FLOWS] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_DROPS] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_ECN_MARKS] = { .type = NLA_U32 },
+   [NL80211_TXQ_STATS_OVERLIMIT] = { .type = NLA_U32 },
+   

Re: [PATCH 0/3] Export TXQ parameters and statistics via nl80211

[Toke Høiland-Jørgensen]

Arend van Spriel  writes:

>>> So can we expect some manual in which is described what parameter
>>> should be tweaked based on the retrieved statistics.
>>
>> Heh, not sure I'll promise a whole manual, but I am happy to write a
>> blog post (or wiki page if that's better) explaining what these values
>> mean and what insight one might gain from them.
>
> My preference would be to have something on wireless.wiki.kernel.org. 
> Another option might be to add kerneldoc section for this.

Sure, I can add a page on the wiki about TXQs :)

-Toke

Re: [PATCH 2/4] staging: wilc1000: modified wilc_spi_read_int() by using GENMASK macro

[Claudiu Beznea]

On 22.02.2018 11:23, Claudiu Beznea wrote:
> Hi Dan,
Sorry, I intended to be address this to Ajay,
> 
> On 22.02.2018 09:37, Dan Carpenter wrote:
>> On Wed, Feb 21, 2018 at 09:42:10PM +0530, Ajay Singh wrote:
>>> Use existing macro GENMASK to get the bitmask value. Moved the code to
>>> get the bitmask value outside the loop, as its only required one time.
>>>
>>> Signed-off-by: Ajay Singh 
>>> ---
>>>  drivers/staging/wilc1000/wilc_spi.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/staging/wilc1000/wilc_spi.c 
>>> b/drivers/staging/wilc1000/wilc_spi.c
>>> index 131d2b7..c63f534 100644
>>> --- a/drivers/staging/wilc1000/wilc_spi.c
>>> +++ b/drivers/staging/wilc1000/wilc_spi.c
>>> @@ -955,6 +955,7 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 
>>> *int_status)
>>> tmp = (byte_cnt >> 2) & IRQ_DMA_WD_CNT_MASK;
>>>  
>>> j = 0;
>>> +   unknown_mask = GENMASK(g_spi.nint - 1, 0);
>>> do {
>>> wilc_spi_read_reg(wilc, 0x1a90, _flags);
>>> tmp |= ((irq_flags >> 27) << IRG_FLAGS_OFFSET);
>>> @@ -964,8 +965,6 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 
>>> *int_status)
>>> tmp |= (((irq_flags >> 0) & 0x7) << k);
>>> }
>>>  
>>> -   unknown_mask = ~((1ul << g_spi.nint) - 1);
>>> -
>>
>> This isn't right at all...  Say g_spi.nint is zero, then we're doing
>> GENMASK(-1, 0) which seems like it should be undefined.  If g_spi.nint
>> is 1 then "GENMASK(1 - 1, 0)" is 0x1 but "~((1 < 1) - 1)" is ~0x1.
>>
> 
> Even in this driver g_spi.nint is always constant and equal with NUM_INT_EXT
> (which is 3), it seems that enabling interrupts before initializing g_spi.nint
> may lead to the state where g_spi.nint = 0, as Dan pointed.
> 
> int wilc1000_wlan_init(struct net_device *dev, struct wilc_vif *vif)
> {
>   // ...
> if (wl->gpio >= 0 && init_irq(dev)) {
> ret = -EIO;
> goto _fail_locks_;
> }
> 
>   // ...
> ret = linux_wlan_start_firmware(dev); -> calls
> linux_wlan_start_firmware which in turn calls 
> wilc->hif_func->hif_sync_ext(wilc,
> NUM_INT_EXT);
> 
>   
> }
> 
> Thank you,
> Claudiu Beznea
> 
>> I'm done reviewing this patch series...  You need to be more careful.
>> Create a small test program to test your patches.  As a reviewer,
>> creating test programs is how I review your patches.
>>
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include "/home/dcarpenter/progs/smatch/devel/check_debug.h"
>> #include "kernel.h"
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>> #define BITS_PER_LONG 64
>> #define GENMASK(h, l) \
>> (((~0UL) - (1UL << (l)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (h
>>
>> int main(void)
>> {
>> int i;
>> u32 mask1, mask2;
>>
>> for (i = 0; i < 32; i++) {
>> mask1 = ~((1ul << i) - 1);
>> mask2 = GENMASK(i - 1, 0);
>> if (mask1 == mask2)
>> continue;
>> printf("ONE 0x%x %d\n", mask1, i);
>> printf("TWO 0x%x\n", mask2);
>> }
>> return 0;
>> }
>>
>> regards,
>> dan carpenter
>>
>>
>>
>> ___
>> devel mailing list
>> de...@linuxdriverproject.org
>> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>>
> 

Re: [PATCH 2/4] staging: wilc1000: modified wilc_spi_read_int() by using GENMASK macro

[Claudiu Beznea]

Hi Dan,

On 22.02.2018 09:37, Dan Carpenter wrote:
> On Wed, Feb 21, 2018 at 09:42:10PM +0530, Ajay Singh wrote:
>> Use existing macro GENMASK to get the bitmask value. Moved the code to
>> get the bitmask value outside the loop, as its only required one time.
>>
>> Signed-off-by: Ajay Singh 
>> ---
>>  drivers/staging/wilc1000/wilc_spi.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/wilc1000/wilc_spi.c 
>> b/drivers/staging/wilc1000/wilc_spi.c
>> index 131d2b7..c63f534 100644
>> --- a/drivers/staging/wilc1000/wilc_spi.c
>> +++ b/drivers/staging/wilc1000/wilc_spi.c
>> @@ -955,6 +955,7 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 
>> *int_status)
>>  tmp = (byte_cnt >> 2) & IRQ_DMA_WD_CNT_MASK;
>>  
>>  j = 0;
>> +unknown_mask = GENMASK(g_spi.nint - 1, 0);
>>  do {
>>  wilc_spi_read_reg(wilc, 0x1a90, _flags);
>>  tmp |= ((irq_flags >> 27) << IRG_FLAGS_OFFSET);
>> @@ -964,8 +965,6 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 
>> *int_status)
>>  tmp |= (((irq_flags >> 0) & 0x7) << k);
>>  }
>>  
>> -unknown_mask = ~((1ul << g_spi.nint) - 1);
>> -
> 
> This isn't right at all...  Say g_spi.nint is zero, then we're doing
> GENMASK(-1, 0) which seems like it should be undefined.  If g_spi.nint
> is 1 then "GENMASK(1 - 1, 0)" is 0x1 but "~((1 < 1) - 1)" is ~0x1.
> 

Even in this driver g_spi.nint is always constant and equal with NUM_INT_EXT
(which is 3), it seems that enabling interrupts before initializing g_spi.nint
may lead to the state where g_spi.nint = 0, as Dan pointed.

int wilc1000_wlan_init(struct net_device *dev, struct wilc_vif *vif)
{
// ...
if (wl->gpio >= 0 && init_irq(dev)) {
ret = -EIO;
goto _fail_locks_;
}

// ...
ret = linux_wlan_start_firmware(dev); -> calls
linux_wlan_start_firmware which in turn calls wilc->hif_func->hif_sync_ext(wilc,
NUM_INT_EXT);


}

Thank you,
Claudiu Beznea

> I'm done reviewing this patch series...  You need to be more careful.
> Create a small test program to test your patches.  As a reviewer,
> creating test programs is how I review your patches.
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include "/home/dcarpenter/progs/smatch/devel/check_debug.h"
> #include "kernel.h"
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> #define BITS_PER_LONG 64
> #define GENMASK(h, l) \
> (((~0UL) - (1UL << (l)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (h
> 
> int main(void)
> {
> int i;
> u32 mask1, mask2;
> 
> for (i = 0; i < 32; i++) {
> mask1 = ~((1ul << i) - 1);
> mask2 = GENMASK(i - 1, 0);
> if (mask1 == mask2)
> continue;
> printf("ONE 0x%x %d\n", mask1, i);
> printf("TWO 0x%x\n", mask2);
> }
> return 0;
> }
> 
> regards,
> dan carpenter
> 
> 
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
> 

[PATCH v2] cfg80211/nl80211: add DFS offload flag

[Sergey Matyukevich]

From: Dmitry Lebed 

Add wiphy EXT_FEATURE flag to indicate that HW or driver does
all DFS actions by itself.
User-space functionality already implemented in hostapd using
vendor-specific (QCA) OUI to advertise DFS offload support.
Need to introduce generic flag to inform about DFS offload support.
For deivces with DFS_OFFLOAD flag set user-space will no longer
need to issue CAC or do any actions in response to
"radar detected" events. HW will do everything by itself and send
events to user-space to indicate that CAC was started/finished, etc.

Signed-off-by: Dmitrii Lebed 
---
V1->V2 changes:
- moved from wiphy_flags to ext_features flags usage

include/uapi/linux/nl80211.h |  7 +++
 net/wireless/nl80211.c   | 12 
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 22cca373161d..811928ce4e1c 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4948,6 +4948,12 @@ enum nl80211_feature_flags {
  * probe request tx deferral and suppression
  * @NL80211_EXT_FEATURE_MFP_OPTIONAL: Driver supports the %NL80211_MFP_OPTIONAL
  * value in %NL80211_ATTR_USE_MFP.
+ * @NL80211_EXT_FEATURE_DFS_OFFLOAD: HW/driver will offload DFS actions.
+ * Device or driver will do all DFS-related actions by itself,
+ * informing user-space about CAC progress, radar detection event,
+ * channel change triggered by radar detection event.
+ * No need to start CAC from user-space, no need to react to
+ * "radar detected" event.
  *
  * @NUM_NL80211_EXT_FEATURES: number of extended features.
  * @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4975,6 +4981,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_OCE_PROBE_REQ_HIGH_TX_RATE,
NL80211_EXT_FEATURE_OCE_PROBE_REQ_DEFERRAL_SUPPRESSION,
NL80211_EXT_FEATURE_MFP_OPTIONAL,
+   NL80211_EXT_FEATURE_DFS_OFFLOAD,
 
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b5e613d14d6a..d57aba58a418 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7786,12 +7786,13 @@ static int nl80211_start_radar_detection(struct sk_buff 
*skb,
struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct net_device *dev = info->user_ptr[1];
struct wireless_dev *wdev = dev->ieee80211_ptr;
+   struct wiphy *wiphy = wdev->wiphy;
struct cfg80211_chan_def chandef;
enum nl80211_dfs_regions dfs_region;
unsigned int cac_time_ms;
int err;
 
-   dfs_region = reg_get_dfs_region(wdev->wiphy);
+   dfs_region = reg_get_dfs_region(wiphy);
if (dfs_region == NL80211_DFS_UNSET)
return -EINVAL;
 
@@ -7805,17 +7806,20 @@ static int nl80211_start_radar_detection(struct sk_buff 
*skb,
if (wdev->cac_started)
return -EBUSY;
 
-   err = cfg80211_chandef_dfs_required(wdev->wiphy, ,
-   wdev->iftype);
+   err = cfg80211_chandef_dfs_required(wiphy, , wdev->iftype);
if (err < 0)
return err;
 
if (err == 0)
return -EINVAL;
 
-   if (!cfg80211_chandef_dfs_usable(wdev->wiphy, ))
+   if (!cfg80211_chandef_dfs_usable(wiphy, ))
return -EINVAL;
 
+   /* CAC start is offloaded to HW and can't be started manually */
+   if (wiphy_ext_feature_isset(wiphy, NL80211_EXT_FEATURE_DFS_OFFLOAD))
+   return -EOPNOTSUPP;
+
if (!rdev->ops->start_radar_detection)
return -EOPNOTSUPP;
 
-- 
2.16.1

Re: [PATCH 1/4] staging: wilc1000: remove use of 'happened' variable in wilc_spi_read_int()

[Dan Carpenter]

On Thu, Feb 22, 2018 at 02:09:01PM +0530, Ajay Singh wrote:
> Hi Dan,
> 
> On Thu, 22 Feb 2018 10:20:58 +0300
> Dan Carpenter  wrote:
> 
> > On Wed, Feb 21, 2018 at 09:42:09PM +0530, Ajay Singh wrote:
> > > Modified wilc_spi_read_int() by removing unnecessary use of "happened"
> > > variable.
> > > 
> > > Signed-off-by: Ajay Singh 
> > > ---
> > >  drivers/staging/wilc1000/wilc_spi.c | 8 +++-
> > >  1 file changed, 3 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/staging/wilc1000/wilc_spi.c 
> > > b/drivers/staging/wilc1000/wilc_spi.c
> > > index 6b392c9..131d2b7 100644
> > > --- a/drivers/staging/wilc1000/wilc_spi.c
> > > +++ b/drivers/staging/wilc1000/wilc_spi.c
> > > @@ -936,7 +936,7 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 
> > > *int_status)
> > >   int ret;
> > >   u32 tmp;
> > >   u32 byte_cnt;
> > > - int happened, j;
> > > + int j;
> > >   u32 unknown_mask;
> > >   u32 irq_flags;
> > >   int k = IRG_FLAGS_OFFSET + 5;
> > > @@ -956,8 +956,6 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 
> > > *int_status)
> > >  
> > >   j = 0;
> > >   do {
> > > - happened = 0;
> > > -
> > >   wilc_spi_read_reg(wilc, 0x1a90, _flags);
> > >   tmp |= ((irq_flags >> 27) << IRG_FLAGS_OFFSET);
> > >  
> > > @@ -972,11 +970,11 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 
> > > *int_status)
> > >   dev_err(>dev,
> > >   "Unexpected interrupt(2):j=%d,tmp=%x,mask=%x\n",
> > >   j, tmp, unknown_mask);
> > > - happened = 1;
> > > + break;  
> > 
> > This is flipped around.  happened means don't break, but you've changed
> > it to be the opposite.
> 
> You are right. Thanks for pointing it out. It's was a mistake. I will
> change 'break' to 'continue' and while(1) to while(0) and resubmit the
> patch.
> 

Don't be in a hurry to resend.  I always wait over night before
resending so that I'm not stressed when I review it.  What you are
proposing still sounds wrong because the j++ is essential.  Anyway, I
can't really review your v2 patch until you send it.

regards,
dan carpenter

Re: [PATCH 1/4] staging: wilc1000: remove use of 'happened' variable in wilc_spi_read_int()

[Ajay Singh]

Hi Dan,

On Thu, 22 Feb 2018 10:20:58 +0300
Dan Carpenter  wrote:

> On Wed, Feb 21, 2018 at 09:42:09PM +0530, Ajay Singh wrote:
> > Modified wilc_spi_read_int() by removing unnecessary use of "happened"
> > variable.
> > 
> > Signed-off-by: Ajay Singh 
> > ---
> >  drivers/staging/wilc1000/wilc_spi.c | 8 +++-
> >  1 file changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/staging/wilc1000/wilc_spi.c 
> > b/drivers/staging/wilc1000/wilc_spi.c
> > index 6b392c9..131d2b7 100644
> > --- a/drivers/staging/wilc1000/wilc_spi.c
> > +++ b/drivers/staging/wilc1000/wilc_spi.c
> > @@ -936,7 +936,7 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 
> > *int_status)
> > int ret;
> > u32 tmp;
> > u32 byte_cnt;
> > -   int happened, j;
> > +   int j;
> > u32 unknown_mask;
> > u32 irq_flags;
> > int k = IRG_FLAGS_OFFSET + 5;
> > @@ -956,8 +956,6 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 
> > *int_status)
> >  
> > j = 0;
> > do {
> > -   happened = 0;
> > -
> > wilc_spi_read_reg(wilc, 0x1a90, _flags);
> > tmp |= ((irq_flags >> 27) << IRG_FLAGS_OFFSET);
> >  
> > @@ -972,11 +970,11 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 
> > *int_status)
> > dev_err(>dev,
> > "Unexpected interrupt(2):j=%d,tmp=%x,mask=%x\n",
> > j, tmp, unknown_mask);
> > -   happened = 1;
> > +   break;  
> 
> This is flipped around.  happened means don't break, but you've changed
> it to be the opposite.

You are right. Thanks for pointing it out. It's was a mistake. I will
change 'break' to 'continue' and while(1) to while(0) and resubmit the
patch.


Regards,
Ajay

> 
> regards,
> dan carpenter
> 
> > }
> >  
> > j++;
> > -   } while (happened);
> > +   } while (1);
> >
> 

Re: [PATCH] cfg80211/nl80211: add DFS offload flag

[Sergey Matyukevich]

Hello Kalle,

> > Friendly advice: you may want to avoid using this footer in emails on
> > the kernel.org mailing lists.
> 
> Indeed. Most of the time I don't even reply to mails with such
> disclaimers and patches containing that will be automatically dropped.

Based on our previous experience we already know that sending patches from
our 'normal' emails with disclaimer is being frowned upon. So all the
patches are being sent from 'oss' emails. But so far we had impression
that participating in further discussion was allowed even from email
addresses with disclaimer.

If this is a problem, we will do the following. Patches will be posted
from 'oss' emails, and authors will participate in discussions from
their personal emails for the time being. Meanwhile we will work with
our management to get 'oss' emails for all the engineers in the team.

Regards,
Sergey