Re: [PATCH][next] ath10k: fix out of bound read on array ath10k_rates

[Kalle Valo]

Colin King  wrote:

> From: Colin Ian King 
> 
> An out-of-bounds read on array ath10k_rates is occurring because
> the maximum number of elements is currently based on the size of
> the array and not the number of elements in the array. Fix this
> by using ARRAY_SIZE instead of sizeof.
> 
> Detected by CoverityScan, CID#1473918 ("Out-of-bounds read")
> 
> Fixes: f279294e9ee2 ("ath10k: add support for configuring management packet 
> rate")
> Signed-off-by: Colin Ian King 

This is already fixed in ath-next.

error: patch failed: drivers/net/wireless/ath/ath10k/mac.c:164
error: drivers/net/wireless/ath/ath10k/mac.c: patch does not apply
stg import: Diff does not apply cleanly

Patch set to Rejected.

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

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

Re: [PATCH] qtnfmac: avoid uninitialized variable access

[Kalle Valo]

Sergey Matyukevich  writes:

>> > When qtnf_trans_send_cmd_with_resp() fails, we have not yet initialized
>> > 'resp', as pointed out by a valid gcc warning:
>> >
>> > drivers/net/wireless/quantenna/qtnfmac/commands.c: In function
>> > 'qtnf_cmd_send_with_reply':
>> > drivers/net/wireless/quantenna/qtnfmac/commands.c:133:54: error:
>> > 'resp' may be used uninitialized in this function
>> > [-Werror=maybe-uninitialized]
>> >
>> > Since 'resp_skb' is also not set here, we can skip all further
>> > processing and just print the warning and return the failure code.
>> >
>> > Fixes: c6ed298ffe09 ("qtnfmac: cleanup and unify command error handling")
>> > Signed-off-by: Arnd Bergmann 
>> 
>> Thanks for the patch! And for reminding me that I forgot to enable
>> gcc warnings in CI builds in addition to sparse checks.
>> 
>> Reviewed-by: Sergey Matyukevich 
>
> Hi Kalle,
>
> Could you please hold back applying this patch for now. We have got
> another report for the same function, this time static analysis tool
> warning. It looks like the patch from Arnd does not cover both cases.
> So we will take a closer look and send a combined fix later.

Ok, I'll drop this from my queue. Please resend whatever patch I need to
apply.

-- 
Kalle Valo

Re: [PATCH] net: wireless: ath: Convert to using %pOFn instead of device_node.name

[Kalle Valo]

Rob Herring  writes:

> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
>
> Cc: Kalle Valo 
> Cc: "David S. Miller" 
> Cc: linux-wirel...@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  drivers/net/wireless/ath/ath6kl/init.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

The correct prefix is "ath6kl:" but I can fix that.

-- 
Kalle Valo

Re: [PATCH] drivers: net: wlcore: remove duplicate \n for some warnings

[Kalle Valo]

"H. Nikolaus Schaller"  writes:

>> Am 25.07.2018 um 08:40 schrieb Kalle Valo :
>> 
>> "H. Nikolaus Schaller"  writes:
>> 
>>> wl1271_warning() already appends a \n to the format,
>>> so adding one to the warning string gives empty lines in the log.
>>> 
>>> Signed-off-by: H. Nikolaus Schaller 
>> 
>> "drivers: net:" in the title is unnecessary, but I can remove that.
>
> Ok, thanks! I wasn't aware of the precise subsystem tagging style here.

Yeah, subsystems can do it a bit differently. But you can easily check
with git log the preferred style:

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

-- 
Kalle Valo

Re: [PATCH] drivers: net: wlcore: remove duplicate \n for some warnings

[Kalle Valo]

"H. Nikolaus Schaller"  writes:

> wl1271_warning() already appends a \n to the format,
> so adding one to the warning string gives empty lines in the log.
>
> Signed-off-by: H. Nikolaus Schaller 

"drivers: net:" in the title is unnecessary, but I can remove that.

-- 
Kalle Valo

Re: [PATCH] wcn36xx: Remove Unicode Byte Order Mark from testcode

[Kalle Valo]

Geert Uytterhoeven  writes:

> Older gcc (< 4.4) doesn't like files starting with a Unicode BOM:
>
> drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\357’ in 
> program
> drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\273’ in 
> program
> drivers/net/wireless/ath/wcn36xx/testmode.c:1: error: stray ‘\277’ in 
> program
>
> Remove the BOM, the rest of the file is plain ASCII anyway.
>
> Output of "file drivers/net/wireless/ath/wcn36xx/testmode.c" before:
>
> drivers/net/wireless/ath/wcn36xx/testmode.c: C source, UTF-8 Unicode 
> (with BOM) text
>
> and after:
>
> drivers/net/wireless/ath/wcn36xx/testmode.c: C source, ASCII text
>
> Fixes: 87f825e6e246cee0 ("wcn36xx: Add support for Factory Test Mode (FTM)")
> Signed-off-by: Geert Uytterhoeven 

I'll queue this for 4.18.

-- 
Kalle Valo

Re: [PATCH] ath6kl: mark expected switch fall-throughs

[Kalle Valo]

"Gustavo A. R. Silva" <gust...@embeddedor.com> writes:

> On 05/25/2018 08:30 AM, Kalle Valo wrote:
>> Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> writes:
>>
>>> On 5/25/2018 2:13 AM, Gustavo A. R. Silva wrote:
>>>
>>>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>>>> where we are expecting to fall through.
>>>>
>>>> Signed-off-by: Gustavo A. R. Silva <gust...@embeddedor.com>
>>>> ---
>>>>drivers/net/wireless/ath/ath6kl/cfg80211.c | 6 +++---
>>>>1 file changed, 3 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
>>>> b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>>>> index 2ba8cf3..29e32cd 100644
>>>> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
>>>> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>>>> @@ -3898,17 +3898,17 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
>>>>wiphy->max_scan_ie_len = 1000; /* FIX: what is correct limit? */
>>>>switch (ar->hw.cap) {
>>>>case WMI_11AN_CAP:
>>>> -  ht = true;
>>>> +  ht = true; /* fall through */
>>>>case WMI_11A_CAP:
>>>>band_5gig = true;
>>>>break;
>>>>case WMI_11GN_CAP:
>>>> -  ht = true;
>>>> +  ht = true; /* fall through */
>>>>case WMI_11G_CAP:
>>>>band_2gig = true;
>>>>break;
>>>>case WMI_11AGN_CAP:
>>>> -  ht = true;
>>>> +  ht = true; /* fall through */
>>>>case WMI_11AG_CAP:
>>>>    band_2gig = true;
>>>>band_5gig = true;
>>>
>>> Hm, typically such comments are done on a line of their own, have
>>> never seen this style...
>>
>> Yeah, I was wondering the same. Was there a particular reason for this?
>>
>
> Sometimes people use this style for a one-line code block.
>
> I can change it to the traditional style. No problem.

I would prefer that. So if you can send v2 that would be great.

-- 
Kalle Valo

Re: [PATCH] ath6kl: mark expected switch fall-throughs

[Kalle Valo]

Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> writes:

> On 5/25/2018 2:13 AM, Gustavo A. R. Silva wrote:
>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Signed-off-by: Gustavo A. R. Silva <gust...@embeddedor.com>
>> ---
>>   drivers/net/wireless/ath/ath6kl/cfg80211.c | 6 +++---
>>   1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c 
>> b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> index 2ba8cf3..29e32cd 100644
>> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> @@ -3898,17 +3898,17 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
>>  wiphy->max_scan_ie_len = 1000; /* FIX: what is correct limit? */
>>  switch (ar->hw.cap) {
>>  case WMI_11AN_CAP:
>> -ht = true;
>> +ht = true; /* fall through */
>>  case WMI_11A_CAP:
>>  band_5gig = true;
>>  break;
>>  case WMI_11GN_CAP:
>> -ht = true;
>> +ht = true; /* fall through */
>>  case WMI_11G_CAP:
>>  band_2gig = true;
>>  break;
>>  case WMI_11AGN_CAP:
>> -ht = true;
>> +ht = true; /* fall through */
>>  case WMI_11AG_CAP:
>>  band_2gig = true;
>>  band_5gig = true;
>
>Hm, typically such comments are done on a line of their own, have
> never seen this style...

Yeah, I was wondering the same. Was there a particular reason for this?

-- 
Kalle Valo

Re: [v8, bpf-next, 4/9] net/wireless/iwlwifi: fix iwlwifi_dev_ucode_error tracepoint

[Kalle Valo]

Alexei Starovoitov <alexei.starovoi...@gmail.com> writes:

> On Wed, May 23, 2018 at 01:03:08PM +0200, Johannes Berg wrote:
>> On Wed, 2018-03-28 at 12:05 -0700, Alexei Starovoitov wrote:
>> > fix iwlwifi_dev_ucode_error tracepoint to pass pointer to a table
>> > instead of all 17 arguments by value.
>> > dvm/main.c and mvm/utils.c have 'struct iwl_error_event_table'
>> > defined with very similar yet subtly different fields and offsets.
>> > tracepoint is still common and using definition of 'struct 
>> > iwl_error_event_table'
>> > from dvm/commands.h while copying fields.
>> > Long term this tracepoint probably should be split into two.
>> 
>> It would've been nice to CC the wireless list for wireless related
>> patches ...
>
> Ohh. I didn't realize that networking wireless doesn't fall under netdev.
> I thought wireless folks are silent because they are embarrassed
> by a function with 17 arguments.

Really, this is the level of discussion now? You don't even bother to CC
the driver maintainers and your first reaction is that they are just too
embarrassed to answer? Oh man...

But if you continue doing these kind of "drive-by cleanups" to a
subsystem you are not familiar with, at least don't assume anything and
instead use get_maintainer script to find the maintainers so that the
patches get reviewed and applied to the correct tree:

$ scripts/get_maintainer.pl --no-rolestats --no-git -f 
drivers/net/wireless/intel/iwlwifi/dvm/main.c
Johannes Berg <johannes.b...@intel.com>
Emmanuel Grumbach <emmanuel.grumb...@intel.com>
Luca Coelho <luciano.coe...@intel.com>
Intel Linux Wireless <linuxw...@intel.com>
Kalle Valo <kv...@codeaurora.org>
"David S. Miller" <da...@davemloft.net>
Daniel Borkmann <dan...@iogearbox.net>
Alexei Starovoitov <a...@kernel.org>
Kees Cook <keesc...@chromium.org>
linux-wirel...@vger.kernel.org
netdev@vger.kernel.org
linux-ker...@vger.kernel.org

-- 
Kalle Valo

Re: [v3] wcn36xx: Add support for Factory Test Mode (FTM)

[Kalle Valo]

Ramon Fried <ramon.fr...@gmail.com> wrote:

> Introduce infrastructure for supporting Factory Test Mode (FTM) of the
> wireless LAN subsystem. In order for the user space to access the
> firmware in test mode the relevant netlink channel needs to be exposed
> from the kernel driver.
> 
> The above is achieved as follows:
> 1) Register wcn36xx driver to testmode callback from netlink
> 2) Add testmode callback implementation to handle incoming FTM commands
> 3) Add FTM command packet structure
> 4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
> 5) Add generic handling for all PTT_MSG packets
> 
> Signed-off-by: Eyal Ilsar <eil...@codeaurora.org>
> Signed-off-by: Ramon Fried <ramon.fr...@linaro.org>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

87f825e6e246 wcn36xx: Add support for Factory Test Mode (FTM)

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

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

Re: [net-next] ath10k: Remove useless test before clk_disable_unprepare

[Kalle Valo]

YueHaibing <yuehaib...@huawei.com> wrote:

> clk_disable_unprepare() already checks that the clock pointer is valid.
> No need to test it before calling it.
> 
> Signed-off-by: YueHaibing <yuehaib...@huawei.com>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

cf3c0ae6a32b ath10k: remove useless test before clk_disable_unprepare

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

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

pull-request: wireless-drivers 2018-05-22

[Kalle Valo]

Hi Dave,

here's a pull request to net tree for 4.17. Please let me know if you
have any problems.

Kalle

The following changes since commit a8d7aa17bbc970971ccdf71988ea19230ab368b1:

  dccp: fix tasklet usage (2018-05-03 15:14:57 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2018-05-22

for you to fetch changes up to 813477aa49aac5deba04eb4956360dde58a0e807:

  MAINTAINERS: change Kalle as wcn36xx maintainer (2018-05-22 15:36:41 +0300)


wireless-drivers fixes for 4.17

Hopefully the last fixes for 4.17. ssb is again causing problems so we
had to revert a commit and fix it better. Also a small fix to bcma and
some MAINTAINERS file updates.

ssb

* fix regression with all module PCI cards, for example using b43 and
  b44 drivers

* try again fixing a MIPS linker error

bcma

* fix truncated info log messages


Kalle Valo (3):
  MAINTAINERS: update Kalle's email address
  MAINTAINERS: change Kalle as ath.ko maintainer
  MAINTAINERS: change Kalle as wcn36xx maintainer

Rafał Miłecki (3):
  bcma: fix buffer size caused crash in bcma_core_mips_print_irq()
  Revert "ssb: Prevent build of PCI host features in module"
  ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

 MAINTAINERS| 8 
 drivers/bcma/driver_mips.c | 2 +-
 drivers/ssb/Kconfig| 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

Re: [PATCH v2] wcn36xx: Add support for Factory Test Mode (FTM)

[Kalle Valo]

Ramon Fried <ramon.fr...@gmail.com> writes:

> From: Eyal Ilsar <eil...@codeaurora.org>
>
> Introduce infrastructure for supporting Factory Test Mode (FTM) of the
> wireless LAN subsystem. In order for the user space to access the
> firmware in test mode the relevant netlink channel needs to be exposed
> from the kernel driver.
>
> The above is achieved as follows:
> 1) Register wcn36xx driver to testmode callback from netlink
> 2) Add testmode callback implementation to handle incoming FTM commands
> 3) Add FTM command packet structure
> 4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
> 5) Add generic handling for all PTT_MSG packets
>
> Signed-off-by: Eyal Ilsar <eil...@codeaurora.org>
> Signed-off-by: Ramon Fried <ramon.fr...@linaro.org>

kbuild bot reported a warning:

drivers/net/wireless/ath/wcn36xx/testmode.c:122:5: warning: 'msg' may be used 
uninitialized in this function [-Wmaybe-uninitialized]

-- 
Kalle Valo

pull-request: wireless-drivers-next 2018-05-17

[Kalle Valo]

the driver callback instead of common code
  mt76: add missing VHT maximum A-MPDU length capability
  mt76: toggle driver station powersave bit before notifying mac80211
  mt76: rework tx power handling
  mt76: fix potential sleep in atomic context
  mt76: set RX_FLAG_DUP_VALIDATED for A-MPDU reordered packets
  mt76: check qos ack policy before reordering packets
  mt76: fix concurrent rx calls on A-MPDU release
  mt76: add rcu locking in tid reorder function
  mt76: add rcu locking around tx scheduling
  mt76: check for pending reset before attempting to schedule tx

Franky Lin (5):
  brcmfmac: reports boottime_ns while informing bss
  brcmfmac: use nl80211_band directly to get ieee80211 channel
  brcmfmac: add hostready indication
  brcmfmac: coarse support for PCIe shared structure rev7
  brcmfmac: fix initialization of struct cfg80211_inform_bss variable

Ganapathi Bhat (1):
  mwifiex: increase TX threashold to avoid TX timeout during ED MAC test

Golan Ben Ami (2):
  iwlwifi: allow different csr flags for different device families
  iwlwifi: support new csr addresses for hw address

Golan Ben-Ami (1):
  iwlwifi: introduce Image Loader (IML) - new firmware image

Govind Singh (15):
  ath10k: build ce layer in ath10k core module
  ath10k: platform driver for WCN3990 SNOC WLAN module
  ath10k: add resource init and deinit for WCN3990
  ath10k: add hif start/stop methods for wcn3990 snoc layer
  ath10k: add HTC services for WCN3990
  ath10k: map HTC services to tx/rx pipes for wcn3990
  ath10k: add hif power-up/power-down methods
  ath10k: add hif tx methods for wcn3990
  ath10k: add hif rx methods for wcn3990
  ath10k: modify hif tx paddr to dma_addr_t type
  ath10k: vote for hardware resources for WCN3990
  dt: bindings: add bindings for wcn3990 wifi block
  ath10k: fix fw path name for WCN3990 target
  ath10k: enable SRRI/DRRI support on ddr for WCN3990
  ath10k: enable sta idle power save

Gregory Greenman (1):
  iwlwifi: mvm: support offload of AMSDU rate control

Gustavo A. R. Silva (6):
  ath9k: dfs: remove accidental use of stack VLA
  mt7601u: phy: mark expected switch fall-through
  brcmsmac: phy_lcn: remove duplicate code
  qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler
  rsi_91x: fix structurally dead code
  rsi_91x: fix uninitialized variable

Haim Dreyfuss (1):
  iwlwifi: move timestamp functions from debugfs.h to dbg.h

Jia-Ju Bai (1):
  net: wireless: b43legacy: Replace GFP_ATOMIC with GFP_KERNEL in 
dma_tx_fragment

Johannes Berg (3):
  iwlwifi: mvm: detect U-APSD breaking aggregation
  iwlwifi: mvm: clean up scan capability checks
  iwlwifi: mvm: move skb padding reservation earlier

Julia Lawall (1):
  mwifiex: delete unneeded include

Kalle Valo (4):
  Merge tag 'iwlwifi-next-for-kalle-2018-04-20' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-next
  Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
  Merge git://git.kernel.org/.../kvalo/wireless-drivers.git
  Merge tag 'iwlwifi-next-for-kalle-2018-04-26' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-next

Liad Kaufman (2):
  iwlwifi: support api ver2 of NVM_GET_INFO resp
  iwlwifi: mvm: support 22000 HW opening agg before traffic

Loic Poulain (2):
  wcn36xx: Add missing fall through comment in smd.c
  wcn36xx: Remove useless skb spinlock

Lorenzo Bianconi (10):
  mt76x2: fix tssi initialization for 5GHz band
  mt76x2: make mt76x2_mac_reset routine static
  mt76x2: remove unnecessary MT_TX_ALC_CFG_4 configuration
  mt76x2: fix tx_alc_enabled check
  mt76x2: set default values in TX_ALC_CFG_{1, 2} for tempetaure 
compensation
  mt76x2: fix TXD_INFO bitmask definition
  mt76x2: fix is_mt7612 routine
  mt76x2: remove unnecessary break in mt76x2_mac_process_tx_rate()
  mt76x2: fix avg_rssi estimation
  mt76x2: add a polling delay in mt76x2_mac_stop routine

Luc Van Oostenryck (2):
  mwifiex: fix mwifiex_hard_start_xmit()'s return type
  qtnfmac: fix qtnf_netdev_hard_start_xmit()'s return type

Luca Coelho (10):
  iwlwifi: mvm: add traffic condition monitoring (TCM)
  iwlwifi: mvm: use TCM data to decide scan priority
  iwlwifi: mvm: fix OOC priority in scans
  iwlwifi: use flags to denote modifiers for the channel maps
  iwlwifi: remove upper case letters in sku_capa_band_*_enable
  iwlwifi: cfg: remove unnecessary cfg data in non-dvm devices
  iwlwifi: fw: harden page loading code
  iwlwifi: fw: combine loading of last page block into main copy loop
  iwlwifi: pcie: remove non-responsive device
  iwlwifi: make bitfield a u32 instead of u16

Maharaja Kennadyrajan (1):
  ath10k: fix a typo in ath10k_wmi_set_wmm_param()

Manikanta Pubbisetty (1):
  ath10k: correct target assert problem due to CE5 stuck

Marc

Re: [PATCH net-next] ath10k: Remove useless test before clk_disable_unprepare

[Kalle Valo]

YueHaibing <yuehaib...@huawei.com> writes:

> clk_disable_unprepare() already checks that the clock pointer is valid.
> No need to test it before calling it.
>
> Signed-off-by: YueHaibing <yuehaib...@huawei.com>

Just a note that ath10k patches are applied to my ath.git tree, not to
net-next. So adding net-next to the subject is wrong, but no need to
resend just because of that.

-- 
Kalle Valo

Re: rsi: fix spelling mistake: "thead" -> "thread"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in rsi_dbg debug message text
> 
> Signed-off-by: Colin Ian King 

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

b41c39367669 rsi: fix spelling mistake: "thead" -> "thread"

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

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

Re: mwifiex: delete unneeded include

[Kalle Valo]

Julia Lawall  wrote:

> Nothing that is defined in 11ac.h is referenced in cmdevt.c.
> 
> Signed-off-by: Julia Lawall 

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

4793e5a954fa mwifiex: delete unneeded include

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

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

Re: [PATCH] net: wireless: ath: ath9k: Fix a possible data race in ath_chanctx_set_next

[Kalle Valo]

Jia-Ju Bai <baijiaju1...@gmail.com> writes:

> The write operation to "sc->next_chan" is protected by
> the lock on line 1287, but the read operation to
> this data on line 1262 is not protected by the lock.
> Thus, there may exist a data race for "sc->next_chan".
>
> To fix this data race, the read operation to "sc->next_chan" 
> should be also protected by the lock.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com>

I need this reviewed by someone else before I'm willing to take it.

-- 
Kalle Valo

Re: [PATCH 09/18] net: mac80211.h: fix a bad comment line

[Kalle Valo]

Mauro Carvalho Chehab <mchehab+sams...@kernel.org> writes:

> Sphinx produces a lot of errors like this:
>   ./include/net/mac80211.h:2083: warning: bad line:  >
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@kernel.org>

Randy already submitted a similar patch:

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

But it seems Johannes has not applied that yet.

-- 
Kalle Valo

Re: ipw2200: fix spelling mistake: "functionalitis" -> "functionalities"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in module parameter description text
> 
> Signed-off-by: Colin Ian King 

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

7e7939e80e3c ipw2200: fix spelling mistake: "functionalitis" -> 
"functionalities"

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

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

Re: rtlwifi: fix spelling mistake: "dismatch" -> "mismatch"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in RT_TRACE message text.
> 
> Signed-off-by: Colin Ian King 

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

070fc356e21a rtlwifi: fix spelling mistake: "dismatch" -> "mismatch"

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

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

Re: ipw2100: fix spelling mistake: "decsribed" -> "described"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in comment and in the ord_data text
> 
> Signed-off-by: Colin Ian King 

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

3ea0a58cf9cf ipw2100: fix spelling mistake: "decsribed" -> "described"

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

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

Re: rt2x00: fix spelling mistake in various macros, UKNOWN -> UNKNOWN

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Rename several macros that contain mispellings of UNKNOWN
> 
> Signed-off-by: Colin Ian King 
> Acked-by: Stanislaw Gruszka 

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

cc282a0c5f08 rt2x00: fix spelling mistake in various macros, UKNOWN -> UNKNOWN

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

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

Re: rsi_91x: fix uninitialized variable

[Kalle Valo]

"Gustavo A. R. Silva"  wrote:

> There is a potential execution path in which variable ret is returned
> without being properly initialized previously.
> 
> Fix this by storing the value returned by function
> rsi_usb_master_reg_write into _ret_.
> 
> Addresses-Coverity-ID: 1468407 ("Uninitialized scalar variable")
> Fixes: 16d3bb7b2f37 ("rsi: disable fw watchdog timer during reset")
> Signed-off-by: Gustavo A. R. Silva 

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

48c6b5c9c118 rsi_91x: fix uninitialized variable

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

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

Re: rsi_91x: fix structurally dead code

[Kalle Valo]

"Gustavo A. R. Silva"  wrote:

> Function rsi_hal_key_config returns before reaching code at line
> 922 if (status), hence this code is structurally dead.
> 
> Fix this by storing the value returned by rsi_hal_load_key
> into _status_ for its further evaluation and use.
> 
> Addresses-Coverity-ID: 1468409 ("Structurally dead code")
> Fixes: 4fd6c4762f37 ("rsi: roaming enhancements")
> Signed-off-by: Gustavo A. R. Silva 

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

e1fd7ceec194 rsi_91x: fix structurally dead code

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

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

Re: qtnfmac: fix qtnf_netdev_hard_start_xmit()'s return type

[Kalle Valo]

Luc Van Oostenryck  wrote:

> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
> 
> Fix this by returning 'netdev_tx_t' in this driver too.
> 
> Signed-off-by: Luc Van Oostenryck 
> Reviewed-by: Sergey Matyukevich 

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

3ff6ee28535f qtnfmac: fix qtnf_netdev_hard_start_xmit()'s return type

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

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

Re: net: wireless: b43legacy: Replace GFP_ATOMIC with GFP_KERNEL in dma_tx_fragment

[Kalle Valo]

Jia-Ju Bai  wrote:

> dma_tx_fragment() is never called in atomic context.
> 
> dma_tx_fragment() is only called by b43legacy_dma_tx(), which is 
> only called by b43legacy_tx_work().
> b43legacy_tx_work() is only set a parameter of INIT_WORK() in 
> b43legacy_wireless_init().
> 
> Despite never getting called from atomic context,
> dma_tx_fragment() calls alloc_skb() with GFP_ATOMIC,
> which does not sleep for allocation.
> GFP_ATOMIC is not necessary and can be replaced with GFP_KERNEL,
> which can sleep and improve the possibility of sucessful allocation.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 

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

6e1d8d1470b2 net: wireless: b43legacy: Replace GFP_ATOMIC with GFP_KERNEL in 
dma_tx_fragment

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

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

Re: mwifiex: fix spelling mistake: "capabilties" -> "capabilities"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in function names and text strings
> 
> Signed-off-by: Colin Ian King 

Failed to apply:

error: patch failed: drivers/net/wireless/marvell/mwifiex/sta_event.c:933
error: drivers/net/wireless/marvell/mwifiex/sta_event.c: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Applying: mwifiex: fix spelling mistake: "capabilties" -> "capabilities"
Using index info to reconstruct a base tree...
Patch failed at 0001 mwifiex: fix spelling mistake: "capabilties" -> 
"capabilities"
The copy of the patch that failed is found in: .git/rebase-apply/patch

Patch set to Changes Requested.

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

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

Re: mwifiex: fix mwifiex_hard_start_xmit()'s return type

[Kalle Valo]

Luc Van Oostenryck  wrote:

> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
> 
> Fix this by returning 'netdev_tx_t' in this driver too.
> 
> Signed-off-by: Luc Van Oostenryck 

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

c126e1995f79 mwifiex: fix mwifiex_hard_start_xmit()'s return type

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

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

Re: ath10k: sdio: jump to correct label in error handling path

[Kalle Valo]

Niklas Cassel <niklas.cas...@linaro.org> wrote:

> Jump to the correct label in error handling path.
> At this point of execution create_singlethread_workqueue() has succeeded,
> so it should be properly destroyed.
> 
> Jump label was renamed in commit ec2c64e20257 ("ath10k: sdio: fix memory
> leak for probe allocations").
> However, the bug was originally introduced in commit d96db25d2025
> ("ath10k: add initial SDIO support").
> 
> Fixes: d96db25d2025 ("ath10k: add initial SDIO support")
> Signed-off-by: Niklas Cassel <niklas.cas...@linaro.org>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

e60a92590187 ath10k: sdio: jump to correct label in error handling path

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

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

Re: [next] ath10k: fix spelling mistake: "servive" -> "service"

[Kalle Valo]

Colin Ian King <colin.k...@canonical.com> wrote:

> Trivial fix to spelling mistake in ath10k_warn warning message text
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

785281342d0c ath10k: fix spelling mistake: "servive" -> "service"

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

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

Re: ath6kl: fix ath6kl_data_tx()'s return type

[Kalle Valo]

Luc Van Oostenryck <luc.vanoostenr...@gmail.com> wrote:

> The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
> which is a typedef for an enum type, but the implementation in this
> driver returns an 'int'.
> 
> Fix this by returning 'netdev_tx_t' in this driver too.
> 
> Signed-off-by: Luc Van Oostenryck <luc.vanoostenr...@gmail.com>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

378b1d65070f ath6kl: fix ath6kl_data_tx()'s return type

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

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

pull-request: wireless-drivers 2018-04-26

[Kalle Valo]

Hi Dave,

here's a pull request to net tree, more info below. Please let me know
if you have any problems.

Kalle

The following changes since commit 4608f064532c28c0ea3c03fe26a3a5909852811a:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next 
(2018-04-03 14:08:58 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2018-04-26

for you to fetch changes up to af8a41cccf8f469165c6debc8fe07c5fd2ca501a:

  rtlwifi: cleanup 8723be ant_sel definition (2018-04-24 13:15:08 +0300)


wireless-drivers fixes for 4.17

A few fixes for 4.17 but nothing really special. The new ETSI WMM
parameter support for iwlwifi is not technically a bugfix but
important for regulatory compliance.

iwlwifi

* use new ETSI WMM parameters from regulatory database

* fix a regression with the older firmware API 31 (eg. 31.560484.0)

brcmfmac

* fix a double free in nvmam loading fails

rtlwifi

* yet another fix for ant_sel module parameter


Arend Van Spriel (1):
  brcmfmac: fix firmware request processing if nvram load fails

Haim Dreyfuss (1):
  iwlwifi: mvm: query regdb for wmm rule if needed

Luca Coelho (1):
  iwlwifi: mvm: fix old scan version sizes

Ping-Ke Shih (1):
  rtlwifi: cleanup 8723be ant_sel definition

 .../broadcom/brcm80211/brcmfmac/firmware.c |  36 ---
 drivers/net/wireless/intel/iwlwifi/fw/api/scan.h   |  13 +--
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 111 ++---
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h |   6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |   3 +-
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   |  15 ---
 .../net/wireless/realtek/rtlwifi/rtl8723be/hw.c|  11 +-
 drivers/net/wireless/realtek/rtlwifi/wifi.h|   5 +
 8 files changed, 138 insertions(+), 62 deletions(-)

Re: qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler

[Kalle Valo]

"Gustavo A. R. Silva"  wrote:

> In case memory resources for fw were succesfully allocated, release
> them before jumping to fw_load_fail.
> 
> Addresses-Coverity-ID: 1466092 ("Resource leak")
> Fixes: c3b2f7ca4186 ("qtnfmac: implement asynchronous firmware loading")
> Signed-off-by: Gustavo A. R. Silva 
> Reviewed-by: Sergey Matyukevich 

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

376377004464 qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler

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

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

Re: brcmsmac: phy_lcn: remove duplicate code

[Kalle Valo]

"Gustavo A. R. Silva"  wrote:

> Remove and refactor some code in order to avoid having identical code
> for different branches.
> 
> Notice that this piece of code hasn't been modified since 2011.
> 
> Addresses-Coverity-ID: 1226756 ("Identical code for different branches")
> Signed-off-by: Gustavo A. R. Silva 

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

863683cfbbfc brcmsmac: phy_lcn: remove duplicate code

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

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

Re: [1/2] net: wireless: zydas: Replace mdelay with msleep in zd1201_probe

[Kalle Valo]

Jia-Ju Bai  wrote:

> zd1201_probe() is never called in atomic context.
> 
> zd1201_probe() is only set as ".probe" in struct usb_driver.
> 
> Despite never getting called from atomic context, zd1201_probe()
> calls mdelay() to busily wait.
> This is not necessary and can be replaced with msleep() to
> avoid busy waiting.
> 
> This is found by a static analysis tool named DCNS written by myself.
> And I also manually check it.
> 
> Signed-off-by: Jia-Ju Bai 

I need a review from someone else before I'm willing to take this.

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

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

Re: [PATCH v3] ath9k: dfs: Remove VLA usage

[Kalle Valo]

Kees Cook <keesc...@chromium.org> writes:

> In the quest to remove all stack VLA usage from the kernel[1], this
> redefines FFT_NUM_SAMPLES as a #define instead of const int, which still
> triggers gcc's VLA checking pass.
>
> [1] https://lkml.org/lkml/2018/3/7/621
>
> Co-developed-by: Andreas Christoforou <andreaschrist...@gmail.com>
> Signed-off-by: Kees Cook <keesc...@chromium.org>
> ---
> v3: replace FFT_NUM_SAMPLES as a #define (Joe)
> ---
>  drivers/net/wireless/ath/ath9k/dfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/dfs.c
> b/drivers/net/wireless/ath/ath9k/dfs.c
> index 6fee9a464cce..e6e56a925121 100644
> --- a/drivers/net/wireless/ath/ath9k/dfs.c
> +++ b/drivers/net/wireless/ath/ath9k/dfs.c
> @@ -40,8 +40,8 @@ static const int BIN_DELTA_MIN  = 1;
>  static const int BIN_DELTA_MAX   = 10;
>  
>  /* we need at least 3 deltas / 4 samples for a reliable chirp detection */
> -#define NUM_DIFFS 3
> -static const int FFT_NUM_SAMPLES = (NUM_DIFFS + 1);
> +#define NUM_DIFFS3
> +#define FFT_NUM_SAMPLES  (NUM_DIFFS + 1)

I have already applied an almost identical patch:

ath9k: dfs: remove accidental use of stack VLA

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next=9c27489a34548913baaaf3b2776e05d4a9389e3e

-- 
Kalle Valo

Re: mt7601u: phy: mark expected switch fall-through

[Kalle Valo]

"Gustavo A. R. Silva"  wrote:

> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva 
> Acked-by: Jakub Kicinski 

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

5156b054bcda mt7601u: phy: mark expected switch fall-through

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

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

Re: cw1200: fix spelling mistake: "Mailformed" -> "Malformed"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in wiphy_warn warning message text
> 
> Signed-off-by: Colin Ian King 

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

0fb1abc3a0b8 cw1200: fix spelling mistake: "Mailformed" -> "Malformed"

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

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

Re: ath6kl: fix spelling mistake: "chache" -> "cache"

[Kalle Valo]

Colin Ian King <colin.k...@canonical.com> wrote:

> Trivial fix to spelling mistake in message text
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

5072d87426bb ath6kl: fix spelling mistake: "chache" -> "cache"

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

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

Re: ath9k: dfs: remove accidental use of stack VLA

[Kalle Valo]

"Gustavo A. R. Silva" <gust...@embeddedor.com> wrote:

> In preparation to enabling -Wvla, remove accidental use of stack VLA.
> 
> This avoids an accidental stack VLA (since the compiler thinks
> the value of FFT_NUM_SAMPLES can change, even when marked
> "const"). This just replaces it with a #define.
> 
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
> 
> Signed-off-by: Gustavo A. R. Silva <gust...@embeddedor.com>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

9c27489a3454 ath9k: dfs: remove accidental use of stack VLA

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

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

Re: ath10k: fix spelling mistake: "tiggers" -> "triggers"

[Kalle Valo]

Colin Ian King <colin.k...@canonical.com> wrote:

> Trivial fix to spelling mistake in message text
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

6ce36faeac35 ath10k: fix spelling mistake: "tiggers" -> "triggers"

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

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

Re: [next] wil6210: fix potential null dereference of ndev before null check

[Kalle Valo]

Colin Ian King <colin.k...@canonical.com> wrote:

> The pointer ndev is being dereferenced before it is being null checked,
> hence there is a potential null pointer deference. Fix this by only
> dereferencing ndev after it has been null checked
> 
> Detected by CoverityScan, CID#1467010 ("Dereference before null check")
> 
> Fixes: e00243fab84b ("wil6210: infrastructure for multiple virtual 
> interfaces")
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> Reviewed-by: Maya Erez <me...@codeaurora.org>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

db5a4d5e1073 wil6210: fix potential null dereference of ndev before null check

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

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

Re: ath10k: avoid possible string overflow

[Kalle Valo]

Arnd Bergmann <a...@arndb.de> wrote:

> The way that 'strncat' is used here raised a warning in gcc-8:
> 
> drivers/net/wireless/ath/ath10k/wmi.c: In function 
> 'ath10k_wmi_tpc_stats_final_disp_tables':
> drivers/net/wireless/ath/ath10k/wmi.c:4649:4: error: 'strncat' output 
> truncated before terminating nul copying as many bytes from a string as its 
> length [-Werror=stringop-truncation]
> 
> Effectively, this is simply a strcat() but the use of strncat() suggests
> some form of overflow check. Regardless of whether this might actually
> overflow, using strlcat() instead of strncat() avoids the warning and
> makes the code more robust.
> 
> Fixes: bc64d05220f3 ("ath10k: debugfs support to get final TPC stats for 10.4 
> variants")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

6707ba0105a2 ath10k: avoid possible string overflow

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

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

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

[Kalle Valo]

Ulf Hansson <ulf.hans...@linaro.org> writes:

> On 20 March 2018 at 10:55, Kalle Valo <kv...@codeaurora.org> wrote:
>> Arend van Spriel <arend.vanspr...@broadcom.com> writes:
>>
>>>>> If I get it right, you mean something like this:
>>>>>
>>>>> mmc3: mmc@1c12000 {
>>>>> ...
>>>>>  broken-sg-support;
>>>>>  sd-head-align = 4;
>>>>>  sd-sgentry-align = 512;
>>>>>
>>>>>  brcmf: wifi@1 {
>>>>>  ...
>>>>>  };
>>>>> };
>>>>>
>>>>> Where dt: bindings documentation for these entries should reside?
>>>>> In generic MMC bindings? Well, this is the very special case and
>>>>> mmc-linux maintainer will unlikely to accept these changes.
>>>>> Also, extra kernel code modification might be required. It could make
>>>>> quite trivial change much more complex.
>>>>
>>>> If the MMC maintainers are not copied on this patch series, it will
>>>> likely be hard for them to identify this patch series and chime in...
>>>
>>> The main question is whether this is indeed a "very special case" as
>>> Alexey claims it to be or that it is likely to be applicable to other
>>> device and host combinations as you are suggesting.
>>>
>>> If these properties are imposed by the host or host controller it
>>> would make sense to have these in the mmc bindings.
>>
>> BTW, last year we were discussing something similar (I mean related to
>> alignment requirements) with ath10k SDIO patches and at the time the
>> patch submitter was proposing to have a bounce buffer in ath10k to
>> workaround that. I don't remember the details anymore, they are on the
>> ath10k mailing list archive if anyone is curious to know, but I would
>> not be surprised if they are similar as here. So there might be a need
>> to solve this in a generic way (but not sure of course as I haven't
>> checked the details).
>
> I re-call something about these as well, here are the patches. Perhaps
> I should pick some of them up...
>
> https://patchwork.kernel.org/patch/10123137/
> https://patchwork.kernel.org/patch/10123139/
> https://patchwork.kernel.org/patch/10123141/
> https://patchwork.kernel.org/patch/10123143/

Actually I was talking about a different patch, found it now:

ath10k_sdio: DMA bounce buffers for read write

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

-- 
Kalle Valo

Re: [PATCH 06/12] wireless: Convert simple uses of a static const Ethernet broadcast address

[Kalle Valo]

Kalle Valo <kv...@codeaurora.org> writes:

> Joe Perches <j...@perches.com> writes:
>
>> Use the new ether_broadcast_addr global instead to save some object code.
>>
>> Signed-off-by: Joe Perches <j...@perches.com>
>> ---
>>  drivers/net/wireless/admtek/adm8211.c   | 3 +--
>>  drivers/net/wireless/ath/carl9170/mac.c | 4 +---
>>  drivers/net/wireless/broadcom/b43/main.c| 3 +--
>>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 3 +--
>>  drivers/net/wireless/realtek/rtlwifi/core.c | 5 ++---
>>  drivers/net/wireless/rndis_wlan.c   | 6 +-
>>  drivers/net/wireless/ti/wl1251/main.c   | 5 +
>>  drivers/net/wireless/ti/wlcore/main.c   | 5 +
>>  8 files changed, 9 insertions(+), 25 deletions(-)
>
> It would be really helpful if you could CLEARLY document in the patches
> (or in the cover letter but then you need to cc all parties) to what
> tree the patches are meant for. Otherwise I, and other maintainers as
> well, need to waste time trying to guess what's your plan.

Forgot to mention that for me the best approach is to have the tree name
in subject, just like Dave and Linus both recommend:

[PATCH 06/12 wireless-drivers-next] wireless: Convert simple uses of a static 
const Ethernet broadcast address

This way I can immeaditely see from patchwork to which tree the patch
should go which helps tremendously. And if the tree name is too long you
can always shorten it to w-d and w-d-next.

-- 
Kalle Valo

Re: [PATCH 06/12] wireless: Convert simple uses of a static const Ethernet broadcast address

[Kalle Valo]

Joe Perches <j...@perches.com> writes:

> Use the new ether_broadcast_addr global instead to save some object code.
>
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
>  drivers/net/wireless/admtek/adm8211.c   | 3 +--
>  drivers/net/wireless/ath/carl9170/mac.c | 4 +---
>  drivers/net/wireless/broadcom/b43/main.c| 3 +--
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 3 +--
>  drivers/net/wireless/realtek/rtlwifi/core.c | 5 ++---
>  drivers/net/wireless/rndis_wlan.c   | 6 +-
>  drivers/net/wireless/ti/wl1251/main.c   | 5 +
>  drivers/net/wireless/ti/wlcore/main.c   | 5 +
>  8 files changed, 9 insertions(+), 25 deletions(-)

It would be really helpful if you could CLEARLY document in the patches
(or in the cover letter but then you need to cc all parties) to what
tree the patches are meant for. Otherwise I, and other maintainers as
well, need to waste time trying to guess what's your plan.

I will now drop the four wireless patches from my queue. So if you want
to me to take them please resubmit.

-- 
Kalle Valo

pull-request: wireless-drivers-next 2018-03-29

[Kalle Valo]

Hi Dave,

here's a pull request to net-next for 4.17. If the merge window starts
on Sunday this will be the last pull request. Do note that I pulled
wireless-drivers into wireless-drivers-next as iwlwifi needed some
patches.

Please let me know if you have any problems.

Kalle

The following changes since commit 996bfed118748c128ad4b6c05c09fd2f5fdfa1b4:

  Merge tag 'wireless-drivers-next-for-davem-2018-03-24' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next 
(2018-03-25 21:27:38 -0400)

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-2018-03-29

for you to fetch changes up to 14c99949a3398a655c47b262ca8e2e83edfae7fd:

  Merge ath-next from 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2018-03-29 
15:55:28 +0300)


wireless-drivers-next patches for 4.17

Smaller new features to various drivers but nothing really out of
ordinary.

Major changes:

ath10k

* enable chip temperature measurement for QCA6174/QCA9377

* add firmware memory dump for QCA9984

* enable buffer STA on TDLS link for QCA6174

* support different beacon internals in multiple interface scenario
  for QCA988X/QCA99X0/QCA9984/QCA4019

iwlwifi

* support for new PCI IDs for the 9000 family

* support for a new firmware API version

* support for advanced dwell and Optimized Connectivity Experience
  (OCE) in scanning

btrsi

* fix kconfig dependencies

wil6210

* support multiple virtual interfaces


Amitkumar Karwar (2):
  rsi: fix error path handling in SDIO probe
  rsi: fix kernel panic observed on 64bit machine

Andrei Otcheretianski (2):
  iwlwifi: mvm: Increase session protection time after CS
  iwlwifi: mvm: Move unused phy's to a default channel

Anilkumar Kolli (2):
  ath10k: add memory dump support QCA9984
  ath10k: advertize beacon_int_min_gcd

Arend Van Spriel (12):
  brcmfmac: do not convert linux error to firmware error string
  brcmfmac: use brcmf_chip_name() to store name in revinfo
  brcmfmac: use brcmf_chip_name() for consistency
  brcmfmac: allocate struct brcmf_pub instance using wiphy_new()
  brcmfmac: use wiphy debugfs dir entry
  brcmfmac: derive firmware filenames from basename mapping
  brcmfmac: pass struct in brcmf_fw_get_firmwares()
  brcmfmac: introduce brcmf_fw_alloc_request() function
  brcmfmac: add extension to .get_fwname() callbacks
  brcmfmac: get rid of brcmf_fw_map_chip_to_name()
  brcmfmac: get rid of brcmf_fw_get_full_name()
  brcmfmac: add kerneldoc for struct brcmf_bus::msgbuf

Arnd Bergmann (1):
  Bluetooth: btrsi: rework dependencies

Avraham Stern (3):
  iwlwifi: mvm: clear tx queue id when unreserving aggregation queue
  iwlwifi: mvm: make sure internal station has a valid id
  iwlwifi: mvm: fix array out of bounds reference

Ayala Beker (1):
  iwlwifi: fw api: support the new scan request FW API version

Beni Lev (1):
  iwlwifi: mvm: Correctly set IGTK for AP

Carl Huang (1):
  ath10k: fix use-after-free in ath10k_wmi_cmd_send_nowait

Christian Lamparter (1):
  ath10k: fix recent bandwidth conversion bug

Colin Ian King (4):
  wil6210: fix spelling mistake: "preperation"-> "preparation"
  ath5k: remove duplicated re-assignment to pointer 'tq'
  rsi: remove redundant duplicate assignment of buffer_size
  rtlwifi: rtl8821ae: fix spelling mistake: "Aboslute" -> "Absolute"

Daniel Mack (1):
  wcn36xx: dequeue all pending indicator messages

Emmanuel Grumbach (2):
  iwlwifi: mvm: set the correct tid when we flush the MCAST sta
  iwlwifi: bump the max API version for 9000 and 22000 devices

Ganapathi Bhat (1):
  mwifiex: remove warnings in mwifiex_cmd_append_11n_tlv()

Govind Singh (1):
  ath10k: fix log message for hif power on failure

Haim Dreyfuss (1):
  iwlwifi: api: Add geographic profile information to MCC_UPDATE_CMD

Ignacio Nunez Hernanz (1):
  ath10k: make ath10k report discarded packets to mac80211

Ilan Peer (1):
  iwlwifi: mvm: Allow iwl_mvm_mac_mgd_prepare_tx() when associated

Joe Perches (2):
  wireless: Use octal not symbolic permissions
  ath: Remove unnecessary ath_bcast_mac and use eth_broadcast_addr

Johannes Berg (1):
  iwlwifi: mvm: fix error checking for multi/broadcast sta

Kalle Valo (7):
  Merge tag 'iwlwifi-for-kalle-2018-03-16' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge tag 'iwlwifi-for-kalle-2018-03-19' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
  Merge git://git.kernel.org/.../kvalo/wireless-drivers.git
  Merge tag 'iwlwifi-next-for-kalle-2018-03-28' of 
git://git.kernel.org/.

Re: ath: Remove unnecessary ath_bcast_mac and use eth_broadcast_addr

[Kalle Valo]

Joe Perches <j...@perches.com> wrote:

> Remove the static array and use the generic routine to set the
> Ethernet broadcast address.
> 
> Signed-off-by: Joe Perches <j...@perches.com>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

a72c92629108 ath: Remove unnecessary ath_bcast_mac and use eth_broadcast_addr

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

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

Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610

[Kalle Valo]

(really adding Bjorn)

Ramon Fried <rfr...@codeaurora.org> writes:

> (adding Bjorn Andersson)
>
>
> On 3/29/2018 10:15 AM, Kalle Valo wrote:
>> (adding devicetree list)
>>
>> Ramon Fried <rfr...@codeaurora.org> writes:
>>
>>> wcn3610 can only operate on 2.4GHz band due to RF limitation.
>>> If wcn36xx digital block is associated with an external IRIS
>>> RF module, retrieve the id and disable 5GHz band in case of
>>> wcn3610 id.
>>>
>>> Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
>>> ---
>>> v2: fixed wrong assignment, which is logically introduces the 
>>> same behaviour, but for correctness.
>>>
>>>  drivers/net/wireless/ath/wcn36xx/main.c| 4 +++-
>>>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
>>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
>>> b/drivers/net/wireless/ath/wcn36xx/main.c
>>> index ab5be6d2c691..833531a68c95 100644
>>> --- a/drivers/net/wireless/ath/wcn36xx/main.c
>>> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
>>> @@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>>> BIT(NL80211_IFTYPE_MESH_POINT);
>>>  
>>> wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = _band_2ghz;
>>> -   if (wcn->rf_id != RF_IRIS_WCN3620)
>>> +   if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
>>> wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = _band_5ghz;
>>>  
>>> wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
>>> @@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct 
>>> wcn36xx *wcn,
>>> if (iris_node) {
>>> if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
>>> wcn->rf_id = RF_IRIS_WCN3620;
>>> +   else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
>>> +   wcn->rf_id = RF_IRIS_WCN3610;
>>> of_node_put(iris_node);
>>> }
>> Should we document qcom,wcn3610 just like wcn3620 is:
>>
>> Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt:
>> "qcom,wcn3620",
>
> IMHO the mentioned bindings is related to the PIL (peripheral image
> loaded) which is just the firmware part and has
> nothing to do with wifi frontend(IRIS).

Should we then have a bindings document for wcn36xx or is it ok to use
compatible strings like this without any docs? I'm not very familiar
with the devicetree stuff.

-- 
Kalle Valo

Re: [PATCH v2] wcn36xx: Disable 5GHz for wcn3610

[Kalle Valo]

(adding devicetree list)

Ramon Fried <rfr...@codeaurora.org> writes:

> wcn3610 can only operate on 2.4GHz band due to RF limitation.
> If wcn36xx digital block is associated with an external IRIS
> RF module, retrieve the id and disable 5GHz band in case of
> wcn3610 id.
>
> Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
> ---
> v2: fixed wrong assignment, which is logically introduces the 
>   same behaviour, but for correctness.
>
>  drivers/net/wireless/ath/wcn36xx/main.c| 4 +++-
>  drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 1 +
>  2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
> b/drivers/net/wireless/ath/wcn36xx/main.c
> index ab5be6d2c691..833531a68c95 100644
> --- a/drivers/net/wireless/ath/wcn36xx/main.c
> +++ b/drivers/net/wireless/ath/wcn36xx/main.c
> @@ -1146,7 +1146,7 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
>   BIT(NL80211_IFTYPE_MESH_POINT);
>  
>   wcn->hw->wiphy->bands[NL80211_BAND_2GHZ] = _band_2ghz;
> - if (wcn->rf_id != RF_IRIS_WCN3620)
> + if (wcn->rf_id != RF_IRIS_WCN3610 && wcn->rf_id != RF_IRIS_WCN3620)
>   wcn->hw->wiphy->bands[NL80211_BAND_5GHZ] = _band_5ghz;
>  
>   wcn->hw->wiphy->max_scan_ssids = WCN36XX_MAX_SCAN_SSIDS;
> @@ -1248,6 +1248,8 @@ static int wcn36xx_platform_get_resources(struct 
> wcn36xx *wcn,
>   if (iris_node) {
>   if (of_device_is_compatible(iris_node, "qcom,wcn3620"))
>   wcn->rf_id = RF_IRIS_WCN3620;
> + else if (of_device_is_compatible(iris_node, "qcom,wcn3610"))
> + wcn->rf_id = RF_IRIS_WCN3610;
>   of_node_put(iris_node);
>   }

Should we document qcom,wcn3610 just like wcn3620 is:

Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt:
"qcom,wcn3620",

-- 
Kalle Valo

Re: [PATCH][next] wil6210: fix potential null dereference of ndev before null check

[Kalle Valo]

me...@codeaurora.org writes:

> On 2018-03-28 20:40, Colin King wrote:
>> From: Colin Ian King <colin.k...@canonical.com>
>>
>> The pointer ndev is being dereferenced before it is being null checked,
>> hence there is a potential null pointer deference. Fix this by only
>> dereferencing ndev after it has been null checked
>>
>> Detected by CoverityScan, CID#1467010 ("Dereference before null check")
>>
>> Fixes: e00243fab84b ("wil6210: infrastructure for multiple virtual
>> interfaces")
>> Signed-off-by: Colin Ian King <colin.k...@canonical.com>

[...]

> Reviewed-by: Maya Erez <me...@codeaurora.org>

Maya, as you are the wil6210 maintainer you can actually use Acked-by
instead of Reviewed-by. Not that it really matters which one you use,
both of them indicate me that you have checked and agree the patch, but
wanted to point out this anyway :)

-- 
Kalle Valo

Re: rtlwifi: rtl8821ae: fix spelling mistake: "Aboslute" -> "Absolute"

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in RT_TRACE message text.
> 
> Signed-off-by: Colin Ian King 
> Acked-by: Larry Finger  "Absolute"

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

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

Re: [next] rsi: remove redundant duplicate assignment of buffer_size

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Variable buffer_size is re-assigned the same value, this duplicated
> assignment is redundant and can be removed.
> 
> Cleans up clang warning:
> drivers/net/wireless/rsi/rsi_91x_usb.c:140:4: warning: Value stored
> to 'buffer_size' is never read
> 
> Signed-off-by: Colin Ian King 

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

a31f9314114c rsi: remove redundant duplicate assignment of buffer_size

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

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

Re: [v2] rsi: Remove stack VLA usage

[Kalle Valo]

"Tobin C. Harding"  wrote:

> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> (kernel Oops) or a security flaw (overwriting memory beyond the
> stack). Also, in general, as code evolves it is easy to lose track of
> how big a VLA can get. Thus, we can end up having runtime failures
> that are hard to debug. As part of the directive[1] to remove all VLAs
> from the kernel, and build with -Wvla.
> 
> Currently rsi code uses a VLA based on a function argument to
> `rsi_sdio_load_data_master_write()`.  The function call chain is
> 
> Both these functions
> 
>   rsi_sdio_reinit_device()
>   rsi_probe()
> 
> start the call chain:
> 
>   rsi_hal_device_init()
>   rsi_load_fw()
>   auto_fw_upgrade()
>   ping_pong_write()
>   rsi_sdio_load_data_master_write()
> 
> [Without familiarity with the code] it appears that none of the 4 locks
> 
>   mutex
>   rx_mutex
>   tx_mutex
>   tx_bus_mutex
> 
> are held when `rsi_sdio_load_data_master_write()` is called.  It is therefore
> safe to use kmalloc with GFP_KERNEL.
> 
> We can avoid using the VLA by using `kmalloc()` and free'ing the memory on all
> exit paths.
> 
> Change buffer from 'u8 array' to 'u8 *'.  Call `kmalloc()` to allocate memory 
> for
> the buffer.  Using goto statement to call `kfree()` on all return paths.
> 
> It can be expected that this patch will result in a small increase in overhead
> due to the use of `kmalloc()` however this code is only called on 
> initialization
> (and re-initialization) so this overhead should not degrade performance.
> 
> [1] https://lkml.org/lkml/2018/3/7/621
> 
> Signed-off-by: Tobin C. Harding 

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

44f98a9332e4 rsi: Remove stack VLA usage

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

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

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

[Kalle Valo]

Joe Perches  wrote:

> Prefer the direct use of octal for permissions.
> 
> Done with checkpatch -f --types=SYMBOLIC_PERMS --fix-inplace
> and some typing.
> 
> Miscellanea:
> 
> o Whitespace neatening around these conversions.
> 
> Signed-off-by: Joe Perches 

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

2ef00c53049b wireless: Use octal not symbolic permissions

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

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

Re: [v3] Bluetooth: btrsi: rework dependencies

[Kalle Valo]

Arnd Bergmann  wrote:

> The linkage between the bluetooth driver and the wireless
> driver is not defined properly, leading to build problems
> such as:
> 
> warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct dependencies 
> (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI && RSI_91X)
> drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt':
> (.text+0x205): undefined reference to `rsi_bt_ops'
> 
> As the dependency is actually the reverse (RSI_91X uses
> the BT_RSI driver, not the other way round), this changes
> the dependency to match, and enables the bluetooth driver
> from the RSI_COEX symbol.
> 
> Fixes: 38aa4da50483 ("Bluetooth: btrsi: add new rsi bluetooth driver")
> Acked-by; Marcel Holtmann 
> Signed-off-by: Arnd Bergmann 

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

255dd5b79d54 Bluetooth: btrsi: rework dependencies

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

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

pull-request: wireless-drivers-next 2018-03-24

[Kalle Valo]

Hi Dave,

here's the first pull request to net-next for 4.17. What's special here
is the addition of a new bluetooth driver, but that's been acked by
Marcel. Also we add a new include file to include/net because of that.

Please let me know if you have any problems.

Kalle

The following changes since commit f74290fdb363665538743d14c4f00aeacdb68d87:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2018-02-24 
00:04:20 -0500)

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-2018-03-24

for you to fetch changes up to 28bf8312a983a7873997bf3faf4c2b4e62e4abc0:

  mwifiex: get_channel from firmware (2018-03-13 18:53:47 +0200)


wireless-drivers-next patches for 4.17

The biggest changes are the bluetooth related patches to the rsi
driver. It adds a new bluetooth driver which communicates directly
with the wireless driver and the interface is defined in
include/net/rsi_91x.h.

Major changes:

wl1251

* read the MAC address from the NVS file

rtlwifi

* enable mac80211 fast-tx support

mt76

* add capability to select tx/rx antennas

mt7601

* let mac80211 validate rx CCMP Packet Number (PN)

rsi

* bluetooth: add new btrsi driver

* btcoex support with the new btrsi driver


Arend Van Spriel (8):
  brcmfmac: move brcmf_bus_preinit() call just after changing bus state
  brcmfmac: move allocation of control rx buffer to brcmf_sdio_bus_preinit()
  brcmfmac: call brcmf_attach() just before calling brcmf_bus_started()
  brcmfmac: usb: call brcmf_usb_up() during brcmf_bus_preinit()
  brcmfmac: move brcmf_attach() function in core.c
  brcmfmac: remove brcmf_bus_started() from bus api
  brcmfmac: change log level for some low-level sdio functions
  brcmfmac: remove duplicate pointer variable from 
brcmf_sdio_firmware_callback()

Arnd Bergmann (1):
  rtlwifi: rtl8192cu: remove pointless memcpy

Arvind Yadav (1):
  ssb: use put_device() if device_register fail

Colin Ian King (2):
  wireless: zd1211rw: remove redundant assignment of pointer 'q'
  brcmsmac: remove duplicated bit-wise or of IEEE80211_CHAN_NO_IR

Denis 'GNUtoo' Carikli (1):
  bcma: add HP Stream Notebook

Ganapathi Bhat (3):
  Revert "mwifiex: fix incorrect ht capability problem"
  mwifiex: fix incorrect ht capability problem
  mwifiex: get_channel from firmware

Gustavo A. R. Silva (1):
  ssb: return boolean instead of integer in ssb_dma_translation_special_bit

Jia-Ju Bai (1):
  bcma: Replace mdelay with usleep_range in bcma_pmu_resources_init

Johannes Berg (1):
  brcmfmac: reject too long PSK

Lorenzo Bianconi (11):
  mt76x2: remove warnings in mt76x2_mac_write_txwi()
  mt7601u: move mt7601u_set_macaddr in mac related code
  mt7601u: set device mac address in mt7601u_add_interface()
  mt7601u: make write with mask access atomic
  mt76: initialize available_antennas_{tx,rx} info
  mt76: add mt76_init_stream_cap routine
  mt76x2: add mac80211 {set,get}_antenna callbacks
  mt7601u: remove a warning in mt7601u_efuse_physical_size_check()
  mt76x2: remove unnecessary len variable in mt76x2_eeprom_load()
  mt7601u: simplify mt7601u_mcu_msg_alloc signature
  mt7601u: let mac80211 validate rx CCMP PN

Matt Redfearn (2):
  ssb: Prevent build of PCI host features in module
  bcma: Prevent build of PCI host features in module

Matthias Kaehlcke (1):
  rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

Pali Rohár (4):
  wl1251: Update wl->nvs_len after wl->nvs is valid
  wl1251: Generate random MAC address only if driver does not have valid
  wl1251: Parse and use MAC address from supplied NVS data
  wl1251: Set generated MAC address back to NVS data

Ping-Ke Shih (11):
  rtlwifi: enable mac80211 fast-tx support
  rtlwifi: Add Support VHT to spec_ver
  rtlwifi: Use 6 bits as sequence number of TX report
  rtlwifi: Extend tx_power_by_rate_offset size for newer IC
  rtlwifi: Add rate section and its related definition and comment
  rtlwifi: Fix VHT NSS in RC
  rtlwifi: add definition radio_mask for RF and maximum bandwidth
  rtlwifi: add efuse ops for other components
  rtlwifi: btcoex: add routine to set default port id
  rtlwifi: btcoex: Add 8822be btcoex supported files for wifi only
  rtlwifi: btcoex: fix argument typo of if-statement found by Coccinelle

Prameela Rani Garnepudi (9):
  rsi: add rx control block to handle rx packets in USB
  rsi: add header file rsi_91x
  rsi: add coex support
  Bluetooth: btrsi: add new rsi bluetooth driver
  rsi: add module parameter operating mode
  rsi: sdio changes to support BT
  rsi: improve RX handling in SDIO interface
  rsi: use dynamic RX 

pull-request: wireless-drivers 2018-03-24

[Kalle Valo]

Hi Dave,

This is a pull request to the net tree for 4.16. I'm not planning to
send anything more in this cycle for 4.16, unless something really major
comes up.

Please let me know if you have any problems.

Kalle

The following changes since commit 87de1201ddaa39d4f3fafa9f35ac143e582517e6:

  Merge branch 'erspan-fixes' (2018-03-09 13:03:57 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2018-03-24

for you to fetch changes up to 9b9322db5c5a1917a66c71fe47c3848a9a31227e:

  brcmfmac: Fix check for ISO3166 code (2018-03-20 12:07:58 +0200)


wireless-drivers fixes for 4.16

Some fixes for 4.16, only for iwlwifi and brcmfmac this time. All
pretty small.

iwlwifi

* fix an issue with the multicast queue

* fix IGTK handling

* fix some missing return value checks

* add support for a HW workaround for issues on some platforms

* a couple of fixes for channel-switch

* a few fixes for the aggregation handling code

brcmfmac

* drop Inter-Access Point Protocol packets by default

* fix check for ISO3166 regulatory code


Andrei Otcheretianski (2):
  iwlwifi: mvm: Increase session protection time after CS
  iwlwifi: mvm: Move unused phy's to a default channel

Avraham Stern (3):
  iwlwifi: mvm: clear tx queue id when unreserving aggregation queue
  iwlwifi: mvm: make sure internal station has a valid id
  iwlwifi: mvm: fix array out of bounds reference

Beni Lev (1):
  iwlwifi: mvm: Correctly set IGTK for AP

Emmanuel Grumbach (1):
  iwlwifi: mvm: set the correct tid when we flush the MCAST sta

Johannes Berg (1):
  iwlwifi: mvm: fix error checking for multi/broadcast sta

Kalle Valo (2):
  Merge tag 'iwlwifi-for-kalle-2018-03-16' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge tag 'iwlwifi-for-kalle-2018-03-19' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes

Luca Coelho (1):
  iwlwifi: add shared clock PHY config flag for some devices

Rafał Miłecki (1):
  brcmfmac: drop Inter-Access Point Protocol packets by default

Stefan Wahren (1):
  brcmfmac: Fix check for ISO3166 code

 .../broadcom/brcm80211/brcmfmac/cfg80211.c |  2 +-
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  |  5 ++
 .../wireless/broadcom/brcm80211/brcmfmac/common.h  |  1 +
 .../wireless/broadcom/brcm80211/brcmfmac/core.c| 57 +
 drivers/net/wireless/intel/iwlwifi/cfg/9000.c  | 62 ++
 drivers/net/wireless/intel/iwlwifi/fw/file.h   |  1 +
 drivers/net/wireless/intel/iwlwifi/iwl-config.h|  5 ++
 drivers/net/wireless/intel/iwlwifi/mvm/fw.c|  4 ++
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |  9 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   |  3 +
 drivers/net/wireless/intel/iwlwifi/mvm/phy-ctxt.c  | 21 --
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   | 74 ++
 .../net/wireless/intel/iwlwifi/mvm/time-event.c| 15 +++--
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c| 10 ++-
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c  | 38 +--
 15 files changed, 225 insertions(+), 82 deletions(-)

Re: [PATCH net-next v2 2/2] dt: bindings: add new dt entries for brcmfmac

[Kalle Valo]

Arend van Spriel <arend.vanspr...@broadcom.com> writes:

>>> If I get it right, you mean something like this:
>>>
>>> mmc3: mmc@1c12000 {
>>> ...
>>>  broken-sg-support;
>>>  sd-head-align = 4;
>>>  sd-sgentry-align = 512;
>>>
>>>  brcmf: wifi@1 {
>>>  ...
>>>  };
>>> };
>>>
>>> Where dt: bindings documentation for these entries should reside?
>>> In generic MMC bindings? Well, this is the very special case and
>>> mmc-linux maintainer will unlikely to accept these changes.
>>> Also, extra kernel code modification might be required. It could make
>>> quite trivial change much more complex.
>>
>> If the MMC maintainers are not copied on this patch series, it will
>> likely be hard for them to identify this patch series and chime in...
>
> The main question is whether this is indeed a "very special case" as
> Alexey claims it to be or that it is likely to be applicable to other
> device and host combinations as you are suggesting.
>
> If these properties are imposed by the host or host controller it
> would make sense to have these in the mmc bindings.

BTW, last year we were discussing something similar (I mean related to
alignment requirements) with ath10k SDIO patches and at the time the
patch submitter was proposing to have a bounce buffer in ath10k to
workaround that. I don't remember the details anymore, they are on the
ath10k mailing list archive if anyone is curious to know, but I would
not be surprised if they are similar as here. So there might be a need
to solve this in a generic way (but not sure of course as I haven't
checked the details).

-- 
Kalle Valo

Re: [PATCH net-next v2 1/2] brcmfmac: add new dt entries for SG SDIO settings

[Kalle Valo]

Alexey Roslyakov <alexey.roslya...@gmail.com> writes:

> There are 3 fields in SDIO settings (quirks) to workaround some of the
> SG SDIO host particularities, i.e higher align requirements for SG
> items. All coding is done the long time ago, but there is no way to
> change the driver behavior without patching the kernel. Add missing
> devicetree entries.
>
> Signed-off-by: Alexey Roslyakov <alexey.roslya...@gmail.com>

The commit log is not clear for me, what does "all coding is done long
time ago" exactly mean? What code and where?

>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)

Why net-next? To me it looks like this should go to
wireless-drivers-next.

-- 
Kalle Valo

Re: [V2] brcmfmac: drop Inter-Access Point Protocol packets by default

[Kalle Valo]

Rafał Miłecki wrote:

> From: Rafał Miłecki 
> 
> Testing brcmfmac with more recent firmwares resulted in AP interfaces
> not working in some specific setups. Debugging resulted in discovering
> support for IAPP in Broadcom's firmwares.
> 
> Older firmwares were only generating 802.11f frames. Newer ones like:
> 1) 10.10 (TOB) (r663589)
> 2) 10.10.122.20 (r683106)
> for 4366b1 and 4366c0 respectively seem to also /respect/ 802.11f frames
> in the Tx path by performing a STA disassociation.
> 
> This obsoleted standard and its implementation is something that:
> 1) Most people don't need / want to use
> 2) Can allow local DoS attacks
> 3) Breaks AP interfaces in some specific bridge setups
> 
> To solve issues it can cause this commit modifies brcmfmac to drop IAPP
> packets. If affects:
> 1) Rx path: driver won't be sending these unwanted packets up.
> 2) Tx path: driver will reject packets that would trigger STA
>disassociation perfromed by a firmware (possible local DoS attack).
> 
> It appears there are some Broadcom's clients/users who care about this
> feature despite the drawbacks. They can switch it on using a new module
> param.
> 
> This change results in only two more comparisons (check for module param
> and check for Ethernet packet length) for 99.9% of packets. Its overhead
> should be very minimal.
> 
> Signed-off-by: Rafał Miłecki 
> Acked-by: Arend van Spriel 

Patch applied to wireless-drivers.git, thanks.

125905517028 brcmfmac: drop Inter-Access Point Protocol packets by default

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

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

Re: [PATCH] [v2] Bluetooth: btrsi: rework dependencies

[Kalle Valo]

Arnd Bergmann <a...@arndb.de> writes:

> On Thu, Mar 15, 2018 at 7:30 PM, Marcel Holtmann <mar...@holtmann.org> wrote:
>> Hi Arnd,
>>
>>> The linkage between the bluetooth driver and the wireless
>>> driver is not defined properly, leading to build problems
>>> such as:
>>>
>>> warning: (BT_HCIRSI) selects RSI_COEX which has unmet direct
>>> dependencies (NETDEVICES && WLAN && WLAN_VENDOR_RSI && BT_HCIRSI &&
>>> RSI_91X)
>>> drivers/net/wireless/rsi/rsi_91x_main.o: In function `rsi_read_pkt':
>>> (.text+0x205): undefined reference to `rsi_bt_ops'
>>>
>>> As the dependency is actually the reverse (RSI_91X uses
>>> the BT_RSI driver, not the other way round), this changes
>>> the dependency to match, and enables the bluetooth driver
>>> from the RSI_COEX symbol.
>>>
>>> Fixes: 38aa4da50483 ("Bluetooth: btrsi: add new rsi bluetooth driver")
>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>>> ---
>>> v2: Pick a different from v1
>>> ---
>>> drivers/bluetooth/Kconfig| 4 +---
>>> drivers/net/wireless/rsi/Kconfig | 4 +++-
>>> 2 files changed, 4 insertions(+), 4 deletions(-)
>>
>> Acked-by: Marcel Holtmann <mar...@holtmann.org>
>>
>> Since I think Kalle still has to take it through his tree until the
>> btrsi driver makes it into net-next.

Yes, I have to take this as I haven't sent the original patch to Dave
yet.

> Kalle, please wait for v3 though, I just ran into another build
> failure caused by a typo in v2.

Ok, I saw it.

-- 
Kalle Valo

Re: [PATCH 11/16] treewide: simplify Kconfig dependencies for removed archs

[Kalle Valo]

Arnd Bergmann <a...@arndb.de> writes:

> A lot of Kconfig symbols have architecture specific dependencies.
> In those cases that depend on architectures we have already removed,
> they can be omitted.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

[...]

>  drivers/net/wireless/cisco/Kconfig   |  2 +-

Acked-by: Kalle Valo <kv...@codeaurora.org>

-- 
Kalle Valo

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

[Kalle Valo]

Arend van Spriel <arend.vanspr...@broadcom.com> writes:

> On 3/14/2018 5:10 PM, Kalle Valo wrote:
>> Rafał Miłecki <ra...@milecki.pl> writes:
>>
>>>>> + unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN;
>>>>> +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
>>>>
>>>> #ifndef?
>>>
>>> I followed what is used in the include/linux/etherdevice.h. Is that a
>>> good exceuse? Could it be there any some good reason for #if defined()?
>>
>> Don't know, maybe just a matter of taste? But it would be nice to know
>> the background behind #ifdef vs #if defined(), never figured it out why
>> two different forms.
>
> Well. In this case you could use either one, but if you have more
> conditions #if defined() is bit more efficient:
>
> #ifdef A
> #ifdef B
> #endif
> #endif
>
> vs.
>
> #if defined(A) && defined(B)

Oh yeah, here defined() definitely helps.

-- 
Kalle Valo

Re: [RESEND] rsi: Remove stack VLA usage

[Kalle Valo]

"Tobin C. Harding" <m...@tobin.cc> writes:

> On Wed, Mar 14, 2018 at 11:19:53AM +0200, Kalle Valo wrote:
>> "Tobin C. Harding" <m...@tobin.cc> writes:
>> 
>> > Added Konstantin in case he is in charge of administering 
>> > patchwork.kernel.org?
>> >
>> > On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote:
>> >> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding <m...@tobin.cc> wrote:
>> >> > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote:
>> >> >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding <m...@tobin.cc> wrote:
>> >> >> > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote:
>> >> >> >> tcharding <m...@tobin.cc> wrote:
>> >> >>
>> >> >> I'm pretty much sure it depends on the original email headers, like
>> >> >> above ^^^ — no name.
>> >> >> Perhaps git config on your side should be done.
>> >> >
>> >> > Thanks for the suggestion Andy but the 'tcharding' as the name was
>> >> > munged by either Kalle or patchwork.  I'm guessing patchwork.
>> >> 
>> >> Something you're sending from is using "tcharding" (see the email Andy
>> >> quotes). I see the headers as:
>> >> 
>> >> Date: Wed, 14 Mar 2018 07:17:57 +1100
>> >> From: tcharding <m...@tobin.cc>
>> >> ...
>> >> Message-ID: <20180313201757.GK8631@eros>
>> >> X-Mailer: Mutt 1.5.24 (2015-08-30)
>> >> User-Agent: Mutt/1.5.24 (2015-08-30)
>> >> 
>> >> Your most recently email shows "Tobin C. Harding" though, and also
>> >> sent with Mutt...
>> >>
>> >> Do you have multiple Mutt configurations? Is something lacking a
>> >> "From" header insertion and your MTA is filling it in for you from
>> >> your username?
>> >
>> > Thanks for taking the time to respond Kees (and Tycho).  I have mutt
>> > configured to reply from whichever email address I receive from so if
>> > patchwork sent an email to 'tcharding <m...@tobin.cc>' (which is the
>> > details it has) and I hit reply it would have come from 'tcharding',
>> > hence Andy's reply.  I wouldn't bet my life on it but I'm kinda
>> > confident that I cannot initiate an email from 'tcharding' with my
>> > current set up.
>> >
>> > Super bad form to blame someone (or something else) but I think this is
>> > a problem with how my patchwork account is configured.  Either way, that
>> > is still my fault I should have added my real name to patchwork when I
>> > signed up (not just username 'tcharding').
>> >
>> > Is patchwork.kernel.org administered by Konstantin Ryabitsev? Added
>> > Konstantin to CC's.
>> 
>> Like I said earlier, just send a request to helpd...@kernel.org and
>> admins should fix your name.
>
> thanks Kalle, I'm on it.

Thanks. Looks to be fixed, now patchwork gives me:

From: Tobin C. Harding <m...@tobin.cc>

-- 
Kalle Valo

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

[Kalle Valo]

Rafał Miłecki <ra...@milecki.pl> writes:

>>> +   unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN;
>>> +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)
>>
>> #ifndef?
>
> I followed what is used in the include/linux/etherdevice.h. Is that a
> good exceuse? Could it be there any some good reason for #if defined()?

Don't know, maybe just a matter of taste? But it would be nice to know
the background behind #ifdef vs #if defined(), never figured it out why
two different forms.

-- 
Kalle Valo

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

[Kalle Valo]

Arend van Spriel <arend.vanspr...@broadcom.com> writes:

> On 3/14/2018 3:24 PM, Kalle Valo wrote:
>>> +config BRCMFMAC_IAPP
>>> >+  bool "Partial support for obsoleted Inter-Access Point Protocol"
>>> >+  depends on BRCMFMAC
>>> >+  ---help---
>>> >+Most of Broadcom's firmwares can send 802.11f ADD frame every
>>> >+time new STA connects to the AP interface. Some recent ones
>>> >+can also disassociate STA when they receive such a frame.
>>> >+
>>> >+It's important to understand this behavior can lead to a local
>>> >+DoS security issue. Attacker may trigger disassociation of any
>>> >+STA by sending a proper Ethernet frame to the wireless
>>> >+interface.
>>> >+
>>> >+Moreover this feature may break AP interfaces in some specific
>>> >+setups. This applies e.g. to the bridge with hairpin mode
>>> >+enabled and IFLA_BRPORT_MCAST_TO_UCAST set. IAPP packet
>>> >+generated by a firmware will get passed back to the wireless
>>> >+interface and cause immediate disassociation of just-connected
>>> >+STA.
>> Sorry for jumping late, but does it really make sense to have a Kconfig
>> option for this? I don't think we should add a Kconfig option for every
>> strange feature, there should be stronger reasons (size savings etc)
>> before adding a Kconfig option.
>>
>> And in this case the size savings can't be much. Wouldn't a module
>> parameter be simpler for a functionality change like this?
>
> Hi Kalle,
>
> Good to be wary about Kconfig option.

I think Linus doesn't like pointless Kconfig options, me neither for
that matter, so I try to make sure the justifications are really there
before adding anything new.

> So my reason for asking a Kconfig option is that this is directly in
> the datapaths (tx and rx) so I prefer to disable/enable it compile
> time rather then runtime.

I'm no cpu profile expert but is really one (or two?) if checks of a
cached variable in the datapath really measurable? My guess is that it's
just noise in the results.

But I'm not going to argue about it, if you think it's still needed I'm
fine with that. Just mention in the commit log the justification the new
Kconfig option.

-- 
Kalle Valo

Re: [PATCH] brcmfmac: drop Inter-Access Point Protocol packets by default

[Kalle Valo]

Rafał Miłecki <zaj...@gmail.com> writes:

> From: Rafał Miłecki <ra...@milecki.pl>
>
> Testing brcmfmac with more recent firmwares resulted in AP interfaces
> not working in some specific setups. Debugging resulted in discovering
> support for IAPP in Broadcom's firmwares. This is an obsoleted standard
> and its implementation is something that:
> 1) Most people don't need / want to use
> 2) Can allow local DoS attacks
> 3) Breaks AP interfaces in some specific bridge setups
>
> To solve issues it can cause this commit modifies brcmfmac to drop IAPP
> packets. If affects:
> 1) Rx path: driver won't be sending these unwanted packets up.
> 2) Tx path: driver will reject packets that would trigger STA
>disassociation perfromed by a firmware (possible local DoS attack).
>
> It appears there are some Broadcom's clients/users who care about this
> feature despite the drawbacks. They can switch it on by a newly added
> Kconfig option.
>
> Signed-off-by: Rafał Miłecki <ra...@milecki.pl>

[...]

> --- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
> +++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
> @@ -68,6 +68,26 @@ config BRCMFMAC_PCIE
> IEEE802.11ac embedded FullMAC WLAN driver. Say Y if you want to
> use the driver for an PCIE wireless card.
>  
> +config BRCMFMAC_IAPP
> + bool "Partial support for obsoleted Inter-Access Point Protocol"
> + depends on BRCMFMAC
> + ---help---
> +   Most of Broadcom's firmwares can send 802.11f ADD frame every
> +   time new STA connects to the AP interface. Some recent ones
> +   can also disassociate STA when they receive such a frame.
> +
> +   It's important to understand this behavior can lead to a local
> +   DoS security issue. Attacker may trigger disassociation of any
> +   STA by sending a proper Ethernet frame to the wireless
> +   interface.
> +
> +   Moreover this feature may break AP interfaces in some specific
> +   setups. This applies e.g. to the bridge with hairpin mode
> +   enabled and IFLA_BRPORT_MCAST_TO_UCAST set. IAPP packet
> +   generated by a firmware will get passed back to the wireless
> +   interface and cause immediate disassociation of just-connected
> +   STA.

Sorry for jumping late, but does it really make sense to have a Kconfig
option for this? I don't think we should add a Kconfig option for every
strange feature, there should be stronger reasons (size savings etc)
before adding a Kconfig option.

And in this case the size savings can't be much. Wouldn't a module
parameter be simpler for a functionality change like this?

> +/**
> + * brcmf_skb_is_iapp - checks if skb is an IAPP packet
> + *
> + * @skb: skb to check
> + */
> +static bool brcmf_skb_is_iapp(struct sk_buff *skb)
> +{
> + const u8 iapp_l2_update_packet[6] __aligned(2) = {
> + 0x00, 0x01, 0xaf, 0x81, 0x01, 0x00,
> + };

static?

> + unsigned char *eth_data = skb_mac_header(skb) + ETH_HLEN;
> +#if !defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)

#ifndef?

> + const u16 *a = (const u16 *)eth_data;
> + const u16 *b = (const u16 *)iapp_l2_update_packet;
> +#endif
> +
> + if (skb->len - skb->mac_len != 6 ||
> + !is_multicast_ether_addr(eth_hdr(skb)->h_dest))
> + return false;
> +
> +#if defined(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS)

#ifdef?

-- 
Kalle Valo

Re: [RESEND] rsi: Remove stack VLA usage

[Kalle Valo]

"Tobin C. Harding" <m...@tobin.cc> writes:

> Added Konstantin in case he is in charge of administering 
> patchwork.kernel.org?
>
> On Tue, Mar 13, 2018 at 07:53:34PM -0700, Kees Cook wrote:
>> On Tue, Mar 13, 2018 at 7:11 PM, Tobin C. Harding <m...@tobin.cc> wrote:
>> > On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote:
>> >> On Tue, Mar 13, 2018 at 10:17 PM, tcharding <m...@tobin.cc> wrote:
>> >> > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote:
>> >> >> tcharding <m...@tobin.cc> wrote:
>> >>
>> >> I'm pretty much sure it depends on the original email headers, like
>> >> above ^^^ — no name.
>> >> Perhaps git config on your side should be done.
>> >
>> > Thanks for the suggestion Andy but the 'tcharding' as the name was
>> > munged by either Kalle or patchwork.  I'm guessing patchwork.
>> 
>> Something you're sending from is using "tcharding" (see the email Andy
>> quotes). I see the headers as:
>> 
>> Date: Wed, 14 Mar 2018 07:17:57 +1100
>> From: tcharding <m...@tobin.cc>
>> ...
>> Message-ID: <20180313201757.GK8631@eros>
>> X-Mailer: Mutt 1.5.24 (2015-08-30)
>> User-Agent: Mutt/1.5.24 (2015-08-30)
>> 
>> Your most recently email shows "Tobin C. Harding" though, and also
>> sent with Mutt...
>>
>> Do you have multiple Mutt configurations? Is something lacking a
>> "From" header insertion and your MTA is filling it in for you from
>> your username?
>
> Thanks for taking the time to respond Kees (and Tycho).  I have mutt
> configured to reply from whichever email address I receive from so if
> patchwork sent an email to 'tcharding <m...@tobin.cc>' (which is the
> details it has) and I hit reply it would have come from 'tcharding',
> hence Andy's reply.  I wouldn't bet my life on it but I'm kinda
> confident that I cannot initiate an email from 'tcharding' with my
> current set up.
>
> Super bad form to blame someone (or something else) but I think this is
> a problem with how my patchwork account is configured.  Either way, that
> is still my fault I should have added my real name to patchwork when I
> signed up (not just username 'tcharding').
>
> Is patchwork.kernel.org administered by Konstantin Ryabitsev? Added
> Konstantin to CC's.

Like I said earlier, just send a request to helpd...@kernel.org and
admins should fix your name.

-- 
Kalle Valo

Re: [RESEND] rsi: Remove stack VLA usage

[Kalle Valo]

"Tobin C. Harding" <m...@tobin.cc> writes:

> On Tue, Mar 13, 2018 at 11:00:47PM +0200, Andy Shevchenko wrote:
>> On Tue, Mar 13, 2018 at 10:17 PM, tcharding <m...@tobin.cc> wrote:
>> > On Mon, Mar 12, 2018 at 09:46:06AM +, Kalle Valo wrote:
>> >> tcharding <m...@tobin.cc> wrote:
>> 
>> I'm pretty much sure it depends on the original email headers, like
>> above ^^^ — no name.
>> Perhaps git config on your side should be done.
>
> Thanks for the suggestion Andy but the 'tcharding' as the name was
> munged by either Kalle or patchwork.  I'm guessing patchwork.

You guessed corretly, patchwork is here to blame. I sent my "please
rebase" mail earlier in this thread using my custom patchwork client
script (pwcli) which takes the name and address from patchwork.

Andy, this is definitely a bug in patchwork and I have seen this issue
multiple times already. I have understood that it has been fixed in a
recent version but patchwork.kernel.org is still running an old version.
In the original mail Tobin did have the correct From header which can be
checked from the headers in patch page[1]:

From: "Tobin C. Harding" <m...@tobin.cc>

[1] https://patchwork.kernel.org/patch/10274983/

-- 
Kalle Valo

Re: [RESEND] rsi: Remove stack VLA usage

[Kalle Valo]

tcharding <m...@tobin.cc> writes:

> On Mon, Mar 12, 2018 at 09:46:06AM +0000, Kalle Valo wrote:
>> tcharding <m...@tobin.cc> wrote:
>> 
>> > The kernel would like to have all stack VLA usage removed[1].  rsi uses
>> > a VLA based on 'blksize'.  Elsewhere in the SDIO code maximum block size
>> > is defined using a magic number.  We can use a pre-processor defined
>> > constant and declare the array to maximum size.  We add a check before
>> > accessing the array in case of programmer error.
>> > 
>> > [1]: https://lkml.org/lkml/2018/3/7/621
>> > 
>> > Signed-off-by: Tobin C. Harding <m...@tobin.cc>
>> 
>> Tobin, your name in patchwork.kernel.org is just "tcharding" then it should 
>> be
>> "Tobin C. Harding". Patchwork is braindead in a way as it takes the name from
>> it's database instead of the From header of the patch in question.
>> 
>> I can fix that manually but it would be helpful if you could register to
>> patchwork and fix your name during registration. You have only one chance to
>> fix your name (another braindead feature!) so be careful :)
>
> Hi Kalle,
>
> I logged into my patchwork account but I don't see any way to set the
> name.  Within 'profile' there is only 'change password' and 'link
> email'.  I thought I could unregister then re-register but I can't see
> how to do that either.

Ok, maybe you have registered (=logged on for the first time) already
earlier so it's not possible to change the name anymore.

> Is there a maintainer of patchwork.kernel.org who I can email to
> manually remove me from the system?

helpd...@kernel.org should be able to fix your name in patchwork, at
least they have done it in the past. This is not the first time this has
happened.

-- 
Kalle Valo

Re: [RESEND] rsi: Remove stack VLA usage

[Kalle Valo]

"Tobin C. Harding"  wrote:

> The kernel would like to have all stack VLA usage removed[1].  rsi uses
> a VLA based on 'blksize'.  Elsewhere in the SDIO code maximum block size
> is defined using a magic number.  We can use a pre-processor defined
> constant and declare the array to maximum size.  We add a check before
> accessing the array in case of programmer error.
> 
> [1]: https://lkml.org/lkml/2018/3/7/621
> 
> Signed-off-by: Tobin C. Harding 

There were conflicts. Can you rebase on top of wireless-drivers-next and
resend, please?

Recorded preimage for 'drivers/net/wireless/rsi/rsi_91x_sdio.c'
error: Failed to merge in the changes.
Applying: rsi: Remove stack VLA usage
Using index info to reconstruct a base tree...
M   drivers/net/wireless/rsi/rsi_91x_hal.c
M   drivers/net/wireless/rsi/rsi_91x_sdio.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/rsi/rsi_91x_sdio.c
CONFLICT (content): Merge conflict in drivers/net/wireless/rsi/rsi_91x_sdio.c
Auto-merging drivers/net/wireless/rsi/rsi_91x_hal.c
Patch failed at 0001 rsi: Remove stack VLA usage
The copy of the patch that failed is found in: .git/rebase-apply/patch

Patch set to Changes Requested.

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

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

Re: net/wireless: fix spaces and grammar copy/paste in vendor Kconfig help text

[Kalle Valo]

Randy Dunlap <rdun...@infradead.org> wrote:

> From: Randy Dunlap <rdun...@infradead.org>
> 
> Lots of the wireless driver vendor Kconfig symol help text says
> "questions about  cards." (2 spaces between "about" and "cards")
> 
> Besides dropping one of those spaces, it also needs some other word
> inserted there. Instead of putting each vendor's name there, I chose
> to say "these" cards in all of the Kconfig help text.
> 
> Cc: Kalle Valo <kv...@codeaurora.org>
> Signed-off-by: Randy Dunlap <rdun...@infradead.org>

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

a6cf02e6485a net/wireless: fix spaces and grammar copy/paste in vendor Kconfig 
help text

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

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

Re: [RESEND] rsi: Remove stack VLA usage

[Kalle Valo]

tcharding  wrote:

> The kernel would like to have all stack VLA usage removed[1].  rsi uses
> a VLA based on 'blksize'.  Elsewhere in the SDIO code maximum block size
> is defined using a magic number.  We can use a pre-processor defined
> constant and declare the array to maximum size.  We add a check before
> accessing the array in case of programmer error.
> 
> [1]: https://lkml.org/lkml/2018/3/7/621
> 
> Signed-off-by: Tobin C. Harding 

Tobin, your name in patchwork.kernel.org is just "tcharding" then it should be
"Tobin C. Harding". Patchwork is braindead in a way as it takes the name from
it's database instead of the From header of the patch in question.

I can fix that manually but it would be helpful if you could register to
patchwork and fix your name during registration. You have only one chance to
fix your name (another braindead feature!) so be careful :)

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

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

Re: [PATCH] drivers: net: wireless: ath: ath9k: dfs: remove VLA usage

[Kalle Valo]

Andreas Christoforou <andreaschrist...@gmail.com> writes:

> The kernel would like to have all stack VLA usage removed.
>
> This is the correct patch.
>
> Signed-off-by: Andreas Christoforou <andreaschrist...@gmail.com>

Please use versioning in the patches:

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

-- 
Kalle Valo

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

[Kalle Valo]

Himanshu Jha <morganfreeman6...@gmail.com> writes:

> On Fri, Mar 09, 2018 at 02:30:12PM +0200, Andreas Christoforou wrote:
>> The kernel would like to have all stack VLA usage removed.
>> 
>> Signed-off-by: Andreas Christoforou <andreaschrist...@gmail.com>
>> ---
>>  drivers/net/wireless/ath/ath9k/dfs.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/drivers/net/wireless/ath/ath9k/dfs.c
>> b/drivers/net/wireless/ath/ath9k/dfs.c
>> index 6fee9a4..cfb0f84 100644
>> --- a/drivers/net/wireless/ath/ath9k/dfs.c
>> +++ b/drivers/net/wireless/ath/ath9k/dfs.c
>> @@ -41,7 +41,6 @@ static const int BIN_DELTA_MAX = 10;
>>  
>>  /* we need at least 3 deltas / 4 samples for a reliable chirp detection */
>>  #define NUM_DIFFS 3
>> -static const int FFT_NUM_SAMPLES= (NUM_DIFFS + 1);
>
> Are you sure it is correct ?
> Look for other users of "FFT_NUM_SAMPLES".
>
>>  /* Threshold for difference of delta peaks */
>>  static const int MAX_DIFF   = 2;
>> @@ -101,7 +100,7 @@ static bool ath9k_check_chirping(struct ath_softc *sc, 
>> u8 *data,
>>   int datalen, bool is_ctl, bool is_ext)
>>  {
>>  int i;
>> -int max_bin[FFT_NUM_SAMPLES];
>> +int max_bin[NUM_DIFFS + 1];
>>  struct ath_hw *ah = sc->sc_ah;
>>  struct ath_common *common = ath9k_hw_common(ah);
>>  int prev_delta;
>
> Always compile test the driver before sending a patch.
> Also, patch title seems incorrect *ath9k*
>
> himanshu@himanshu-Vostro-3559:~/linux-next$ git log --oneline
> drivers/net/wireless/ath/ath9k/dfs.c
> 626ab67 ath9k: dfs: use swap macro in ath9k_check_chirping
> 50c8cd4 ath9k: remove cast to void pointer
> 8fc2b61 ath9k: DFS - add pulse chirp detection for FCC
> 

Yeah, just "ath9k:" is enough as the prefix, no need to have full
directory path in the title.

-- 
Kalle Valo

Re: [PATCH] rsi: Remove stack VLA usage

[Kalle Valo]

"Tobin C. Harding" <m...@tobin.cc> writes:

> The kernel would like to have all stack VLA usage removed[1].  rsi uses
> a VLA based on 'blksize'.  Elsewhere in the SDIO code maximum block size
> is defined using a magic number.  We can use a pre-processor defined
> constant and declare the array to maximum size.  We add a check before
> accessing the array in case of programmer error.
>
> [1]: https://lkml.org/lkml/2018/3/7/621
>
> Signed-off-by: Tobin C. Harding <m...@tobin.cc>

Please CC linux-wireless list, otherwise patchwork won't see the patch
and I can't apply it.

-- 
Kalle Valo

pull-request: wireless-drivers 2018-03-08

[Kalle Valo]

Hi Dave,

here's a pull requsest to net tree for 4.16. Since the merge window I
have had some clannges to keep up with some patches but catching up now.

There should be nothing special here but please let me know if you have
any problems.

Kalle

The following changes since commit 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3:

  mvpp2: fix multicast address filter (2018-02-11 22:37:04 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2018-03-08

for you to fetch changes up to 455f3e76cfc0d893585a5f358b9ddbe9c1e1e53b:

  brcmfmac: fix P2P_DEVICE ethernet address generation (2018-03-07 16:36:41 
+0200)


wireless-drivers fixes for 4.16

Quote a few fixes as I have not been able to send a pull request
earlier. Most of the fixes for iwlwifi but also few others, nothing
really standing out though.

iwlwifi

* fix a bogus warning when freeing a TFD

* fix severe throughput problem with 9000 series

* fix for a bug that caused queue hangs in certain situations

* fix for an issue with IBSS

* fix an issue with rate-scaling in AP-mode

* fix Channel Switch Announcement (CSA) issues with count 0 and 1

* some firmware debugging fixes

* remov a wrong error message when removing keys

* fix a firmware sysassert most usually triggered in IBSS

* a couple of fixes on multicast queues

* a fix with CCMP 256

rtlwifi

* fix loss of signal for rtl8723be

brcmfmac

* add possibility to obtain firmware error

* fix P2P_DEVICE ethernet address generation


Andrei Otcheretianski (1):
  iwlwifi: mvm: Fix channel switch for count 0 and 1

Arend Van Spriel (2):
  brcmfmac: add possibility to obtain firmware error
  brcmfmac: fix P2P_DEVICE ethernet address generation

Emmanuel Grumbach (1):
  iwlwifi: pcie: don't warn if we use all the transmit pointers

Haim Dreyfuss (1):
  iwlwifi: Cancel and set MARKER_CMD timer during suspend-resume

Ilan Peer (2):
  iwlwifi: mvm: Direct multicast frames to the correct station
  iwlwifi: mvm: Correctly set the tid for mcast queue

Kalle Valo (2):
  Merge tag 'iwlwifi-for-kalle-2018-02-16-2' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge tag 'iwlwifi-for-kalle-2018-03-02' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes

Larry Finger (1):
  rtlwifi: rtl8723be: Fix loss of signal

Naftali Goldstein (1):
  iwlwifi: mvm: always init rs with 20mhz bandwidth rates

Sara Sharon (5):
  iwlwifi: mvm: fix security bug in PN checking
  iwlwifi: mvm: fix IBSS for devices that support station type API
  iwlwifi: mvm: fix TX of CCMP 256
  iwlwifi: mvm: fix assert 0x2B00 on older FWs
  iwlwifi: mvm: fix "failed to remove key" message

Shaul Triebitz (2):
  iwlwifi: align timestamp cancel with timestamp start
  iwlwifi: avoid collecting firmware dump if not loaded

Ulf Magnusson (1):
  iwlwifi: fix malformed CONFIG_IWLWIFI_PCIE_RTPM default

 .../wireless/broadcom/brcm80211/brcmfmac/core.h|  2 +
 .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 10 +
 .../wireless/broadcom/brcm80211/brcmfmac/fwil.c|  3 ++
 .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 24 +--
 drivers/net/wireless/intel/iwlwifi/Kconfig |  1 -
 .../net/wireless/intel/iwlwifi/fw/api/time-event.h |  4 +-
 drivers/net/wireless/intel/iwlwifi/fw/dbg.c| 13 +-
 drivers/net/wireless/intel/iwlwifi/fw/dbg.h|  3 ++
 drivers/net/wireless/intel/iwlwifi/fw/debugfs.h| 18 
 drivers/net/wireless/intel/iwlwifi/fw/init.c   | 12 --
 drivers/net/wireless/intel/iwlwifi/fw/runtime.h|  7 
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c|  8 
 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c   |  5 +--
 drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c  |  3 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  | 49 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mvm.h   |  2 +
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c   | 10 -
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c| 28 +
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  | 39 -
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   | 33 ---
 .../net/wireless/intel/iwlwifi/mvm/time-event.c|  6 ++-
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c| 13 --
 drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c  |  2 +-
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c   |  2 +-
 .../net/wireless/realtek/rtlwifi/rtl8723be/hw.c|  3 +-
 25 files changed, 212 insertions(+), 88 deletions(-)

Re: rtl8187: Fix NULL pointer dereference in priv->conf_mutex

[Kalle Valo]

Sudhir Sreedharan  wrote:

> This can be reproduced by bind/unbind the driver multiple times
> in AM3517 board.
> 
> Analysis revealed that rtl8187_start() was invoked before probe
> finishes(ie. before the mutex is initialized).
> 
>  INFO: trying to register non-static key.
>  the code is fine but needs lockdep annotation.
>  turning off the locking correctness validator.
>  CPU: 0 PID: 821 Comm: wpa_supplicant Not tainted 4.9.80-dirty #250
>  Hardware name: Generic AM3517 (Flattened Device Tree)
>  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>  [] (show_stack) from [] (register_lock_class+0x4f4/0x55c)
>  [] (register_lock_class) from [] 
> (__lock_acquire+0x74/0x1938)
>  [] (__lock_acquire) from [] (lock_acquire+0xfc/0x23c)
>  [] (lock_acquire) from [] (mutex_lock_nested+0x50/0x3b0)
>  [] (mutex_lock_nested) from [] (rtl8187_start+0x2c/0xd54)
>  [] (rtl8187_start) from [] (drv_start+0xa8/0x320)
>  [] (drv_start) from [] (ieee80211_do_open+0x2bc/0x8e4)
>  [] (ieee80211_do_open) from [] (__dev_open+0xb8/0x120)
>  [] (__dev_open) from [] (__dev_change_flags+0x88/0x14c)
>  [] (__dev_change_flags) from [] 
> (dev_change_flags+0x18/0x48)
>  [] (dev_change_flags) from [] (devinet_ioctl+0x738/0x840)
>  [] (devinet_ioctl) from [] (sock_ioctl+0x164/0x2f4)
>  [] (sock_ioctl) from [] (do_vfs_ioctl+0x8c/0x9d0)
>  [] (do_vfs_ioctl) from [] (SyS_ioctl+0x6c/0x7c)
>  [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x1c)
>  Unable to handle kernel NULL pointer dereference at virtual address 
>  pgd = cd1ec000
>  [] *pgd=8d1de831, *pte=, *ppte=
>  Internal error: Oops: 817 [#1] PREEMPT ARM
>  Modules linked in:
>  CPU: 0 PID: 821 Comm: wpa_supplicant Not tainted 4.9.80-dirty #250
>  Hardware name: Generic AM3517 (Flattened Device Tree)
>  task: ce73eec0 task.stack: cd1ea000
>  PC is at mutex_lock_nested+0xe8/0x3b0
>  LR is at mutex_lock_nested+0xd0/0x3b0
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Sudhir Sreedharan 

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

7972326a26b5 rtl8187: Fix NULL pointer dereference in priv->conf_mutex

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

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

Re: ath5k: remove duplicated re-assignment to pointer 'tq'

[Kalle Valo]

Colin Ian King <colin.k...@canonical.com> wrote:

> Pointer tq is initialized with >ah_txq[queue] and then a few
> lines later is re-assigned the same value, hence this duplicate
> assignment is redundant and can be removed.
> 
> Cleans up clang warning:
> drivers/net/wireless/ath/ath5k/qcu.c:326:25: warning: Value stored
> to 'tq' during its initialization is never read
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

2571c081cb43 ath5k: remove duplicated re-assignment to pointer 'tq'

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

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

Re: brcmsmac: remove duplicated bit-wise or of IEEE80211_CHAN_NO_IR

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Bit pattern IEEE80211_CHAN_NO_IR is being bit-wise or'd twice;
> remove the redundant 2nd IEEE80211_CHAN_NO_IR
> 
> Signed-off-by: Colin Ian King 

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

47c8a3956a60 brcmsmac: remove duplicated bit-wise or of IEEE80211_CHAN_NO_IR

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

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

Re: rtlwifi: rtl8192cu: remove pointless memcpy

[Kalle Valo]

Arnd Bergmann  wrote:

> gcc-8 points out that source and destination of the memcpy() are
> always the same pointer, so the effect of memcpy() is undefined
> here (its arguments must not overlap):
> 
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c: In function 
> '_rtl_rx_process':
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:430:2: error: 'memcpy' 
> source argument is the same as destination [-Werror=restrict]
> 
> Most likely this is harmless, but it's easy to just remove the
> line and get rid of the warning.
> 
> Signed-off-by: Arnd Bergmann 
> Acked-by: Larry Finger 

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

dcdd54c2bcae rtlwifi: rtl8192cu: remove pointless memcpy

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

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

Re: [v2] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

[Kalle Valo]

Matthias Kaehlcke  wrote:

> In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal
> is assigned to itself in an if ... else statement, apparently only to
> document that the branch condition is handled and that a previously read
> value should be returned unmodified. The self-assignment causes clang to
> raise the following warning:
> 
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13:
>   error: explicitly assigning value of variable of type 'u32'
> (aka 'unsigned int') to itself [-Werror,-Wself-assign]
>   writeVal = writeVal;
> 
> Delete the branch with the self-assignment.
> 
> Signed-off-by: Matthias Kaehlcke 
> Acked-by: Larry Finger 
> Reviewed-by: Guenter Roeck 

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

fb239c1209bb rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

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

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

Re: wireless: zd1211rw: remove redundant assignment of pointer 'q'

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Pointer q is initialized and then almost immediately afterwards being
> re-assigned the same value. Remove the second redundant assignment.
> 
> Cleans up clang warning:
> drivers/net/wireless/zydas/zd1211rw/zd_mac.c:503:23: warning: Value
> stored to 'q' during its initialization is never read
> 
> Signed-off-by: Colin Ian King 

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

76d1f95983a0 wireless: zd1211rw: remove redundant assignment of pointer 'q'

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

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

Re: brcm80211: remove duplicated bit-wise or of IEEE80211_CHAN_NO_IR

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Bit pattern IEEE80211_CHAN_NO_IR is being bit-wise or'd twice;
> remove the redundant 2nd IEEE80211_CHAN_NO_IR
> 
> Signed-off-by: Colin Ian King 

The prefix should be "brcmsmac:", I'll fix that.

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

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

Re: [v2,1/6] wl1251: Update wl->nvs_len after wl->nvs is valid

[Kalle Valo]

Pali Rohár wrote:

> If kmemdup fails, then wl->nvs_len will contain invalid non-zero size.
> 
> Signed-off-by: Pali Rohár 
> Acked-by: Pavel Machek 

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

f63b4c971f5f wl1251: Update wl->nvs_len after wl->nvs is valid
562da3a39cb7 wl1251: Generate random MAC address only if driver does not have 
valid
4f507d588d08 wl1251: Parse and use MAC address from supplied NVS data
3142467fc15b wl1251: Set generated MAC address back to NVS data

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

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

Re: [next] wil6210: fix spelling mistake: "preperation"-> "preparation"

[Kalle Valo]

Colin Ian King <colin.k...@canonical.com> wrote:

> Trivial fix to spelling mistake in debug error message text.
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

77b83829ebf6 wil6210: fix spelling mistake: "preperation"-> "preparation"

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

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

Re: [PATCH v2] qrtr: add MODULE_ALIAS macro to smd

[Kalle Valo]

Ramon Fried <rfr...@codeaurora.org> writes:

> Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
> when IPCRTR channel is detected.
>
> Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
>
> V2: Corrected subject line, this is not a part of a patchset.
> ---
>  net/qrtr/smd.c | 1 +
>  1 file changed, 1 insertion(+)

The change log should be after "---" line so that git-am can discard it
automatically. Now the changelog would be part of git commit log and we
don't want that.

So please submit v3.

-- 
Kalle Valo

Re: [PATCH v2 0/6] wl1251: Fix MAC address for Nokia N900

[Kalle Valo]

Pali Rohár <pali.ro...@gmail.com> writes:

> On Friday 05 January 2018 02:45:10 Luis R. Rodriguez wrote:
>> On Tue, Jan 02, 2018 at 08:23:45PM +0100, Pali Rohár wrote:
>> > On Friday 10 November 2017 00:38:22 Pali Rohár wrote:
>> > > This patch series fix processing MAC address for wl1251 chip found in 
>> > > Nokia N900.
>> > > 
>> > > Changes since v1:
>> > > * Added Acked-by for Pavel Machek
>> > > * Fixed grammar
>> > > * Magic numbers for NVS offsets are replaced by defines
>> > > * Check for validity of mac address NVS data is moved into function
>> > > * Changed order of patches as Pavel requested
>> > > 
>> > > Pali Rohár (6):
>> > >   wl1251: Update wl->nvs_len after wl->nvs is valid
>> > >   wl1251: Generate random MAC address only if driver does not have
>> > > valid
>> > >   wl1251: Parse and use MAC address from supplied NVS data
>> > >   wl1251: Set generated MAC address back to NVS data
>> > >   firmware: Add request_firmware_prefer_user() function
>> > >   wl1251: Use request_firmware_prefer_user() for loading NVS
>> > > calibration data
>> > > 
>> > >  drivers/base/firmware_class.c  |   45 +-
>> > >  drivers/net/wireless/ti/wl1251/Kconfig |1 +
>> > >  drivers/net/wireless/ti/wl1251/main.c  |  104 
>> > > ++--
>> > >  include/linux/firmware.h   |9 +++
>> > >  4 files changed, 138 insertions(+), 21 deletions(-)
>> > 
>> > Hi! Are there any comments for first 4 patches? If not, could they be
>> > accepted and merged?
>> 
>> Since the first 4 patches do not touch the firmware API they seem fine to me 
>> so
>> long as the maintainer accepts them. Maybe resend and clarify you have 
>> dropped
>> the other ones and amend with the new tags.
>
> According to get_maintainer.pl, Kalle Valo is maintainer.
>
> Kalle Valo, if you do not have any other comments, can you accept first
> 4 patches? Or do you really need to resent first 4 patches again?

The first 4 patches are now in my queue, I should get to them in the
next few days.

-- 
Kalle Valo

Re: [PATCH] ath9k: turn on btcoex_enable as default

[Kalle Valo]

Kai Heng Feng <kai.heng.f...@canonical.com> writes:

> Hi Felix,
>
>> On Feb 8, 2018, at 7:02 PM, Felix Fietkau <n...@nbd.name> wrote:
>>
>> On 2018-02-08 06:28, Kai-Heng Feng wrote:
>>> Without btcoex_enable, WiFi activies make both WiFi and Bluetooth
>>> unstable if there's a bluetooth connection.
>>>
>>> Enable this option when bt_ant_diversity is disabled.
>>>
>>> BugLink: https://bugs.launchpad.net/bugs/1746164
>>> Signed-off-by: Kai-Heng Feng <kai.heng.f...@canonical.com>
>> I think this might cause regressions on devices that don't have
>> bluetooth. This probably either needs more EEPROM checks, or something
>> to selectively enable it only on affected platforms.
>
> I think it’s better not to use dmi_match. This issue should affect
> more ath9k. And bluetooth peripherals are more than ever now, so it
> would be great to use BT out of the box.

Sure, but we have to make sure that we don't create regressions on
existing systems. For example, did you test this with any system which
don't support btcoex? (just asking, haven't tested this myself)

-- 
Kalle Valo

pull-request: wireless-drivers-next 2018-02-08

[Kalle Valo]

Hi Dave,

first set of fixes for 4.16, unusually many when the merge window hasn't
even closed yet. Especially the ssb fix is important so I hope there's
still time to get this to 4.16-rc1. As you can see from the diffstat
there's one PCI id addition but that has been acked by Bjorn.

Please let me know if you have any problems.

Kalle

The following changes since commit f813614f531114db796ad66ced75c5dc8db7aa3a:

  ibmvnic: Wait for device response when changing MAC (2018-01-29 18:03:24 
-0500)

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-2018-02-08

for you to fetch changes up to 99ffd198f07f46f3a8e64399249a8333c09063df:

  Merge ath-current from 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2018-02-08 
19:28:49 +0200)


wireless-drivers-next patches for 4.16

The most important here is the ssb fix, it has been reported by the
users frequently and the fix just missed the final v4.15. Also
numerous other fixes, mt76 had multiple problems with aggregation and
a long standing unaligned access bug in rtlwifi is finally fixed.

Major changes:

ath10k

* correct firmware RAM dump length for QCA6174/QCA9377

* add new QCA988X device id

* fix a kernel panic during pci probe

* revert a recent commit which broke ath10k firmware metadata parsing

ath9k

* fix a noise floor regression introduced during the merge window

* add new device id

rtlwifi

* fix unaligned access seen on ARM architecture

mt76

* various aggregation fixes which fix connection stalls

ssb

* fix b43 and b44 on non-MIPS which broke in v4.15-rc9


Felix Fietkau (4):
  mt76: implement AP_LINK_PS
  mt76: implement processing of BlockAckReq frames
  mt76: avoid re-queueing A-MPDU rx reorder work if no frames are pending
  mt76: do not set status->aggr for NULL data frames

Kalle Valo (2):
  Merge git://git.kernel.org/.../kvalo/wireless-drivers.git
  Merge ath-current from git://git.kernel.org/.../kvalo/ath.git

Larry Finger (1):
  rtlwifi: rtl8821ae: Fix connection lost problem correctly

Oleksij Rempel (1):
  ath9k_htc: add Altai WA1011N-GU

Ryan Hsu (1):
  Revert "ath10k: add sanity check to ie_len before parsing fw/board ie"

Sven Joachim (1):
  ssb: Do not disable PCI host on non-Mips

Tobias Schramm (2):
  PCI: Add Ubiquiti Networks vendor ID
  ath10k: add support for Ubiquiti rebranded QCA988X v2

Wojciech Dubowik (1):
  ath9k: Fix get channel default noise floor

Yu Wang (2):
  ath10k: correct the length of DRAM dump for QCA6174 hw3.x/QCA9377 hw1.1
  ath10k: fix kernel panic issue during pci probe

 drivers/net/wireless/ath/ath10k/core.c | 43 +++---
 drivers/net/wireless/ath/ath10k/coredump.c |  3 +-
 drivers/net/wireless/ath/ath10k/debug.c| 12 -
 drivers/net/wireless/ath/ath10k/hw.h   |  1 +
 drivers/net/wireless/ath/ath10k/pci.c  |  6 +++
 drivers/net/wireless/ath/ath9k/calib.c |  2 +-
 drivers/net/wireless/ath/ath9k/hif_usb.c   |  1 +
 drivers/net/wireless/mediatek/mt76/agg-rx.c| 40 -
 drivers/net/wireless/mediatek/mt76/mac80211.c  | 52 +-
 drivers/net/wireless/mediatek/mt76/mt76.h  | 10 +
 drivers/net/wireless/mediatek/mt76/mt76x2.h|  2 +
 drivers/net/wireless/mediatek/mt76/mt76x2_init.c   |  1 +
 drivers/net/wireless/mediatek/mt76/mt76x2_mac.c|  2 +-
 drivers/net/wireless/mediatek/mt76/mt76x2_main.c   | 28 ++--
 .../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c|  5 ++-
 drivers/net/wireless/realtek/rtlwifi/wifi.h|  1 +
 drivers/ssb/Kconfig|  2 +-
 include/linux/pci_ids.h|  2 +
 18 files changed, 181 insertions(+), 32 deletions(-)

pull-request: wireless-drivers-next 2018-01-26

[Kalle Valo]

Hi Dave,

this is a pull request to net-next for 4.16, more info in the signed tag
below. Please let me know if you have any problems.

Kalle

The following changes since commit ebdd7b491b8a65d65936e07004caabca4a3c94a0:

  Merge branch 'mlxsw-Add-support-for-mirror-action-with-flower' (2018-01-21 
18:21:31 -0500)

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-2018-01-26

for you to fetch changes up to 30ce7f4456ae40e970d9e82fe63c5e55147af0c0:

  mt76: validate rx CCMP PN (2018-01-26 11:20:52 +0200)


wireless-drivers-next patches for 4.16

Major changes:

wil6210

* add PCI device id for Talyn

* support flashless device

ath9k

* improve RSSI/signal accuracy on AR9003 series

mt76

* validate CCMP PN from received frames to avoid replay attacks

qtnfmac

* support 64-bit network stats

* report more hardware information to kernel log and some via ethtool


Arend Van Spriel (2):
  brcmfmac: assure bcdc dcmd api does not return value > 0
  brcmfmac: separate firmware errors from i/o errors

Dedy Lansky (1):
  wil6210: support flashless device

Felix Fietkau (10):
  mt76: fix transmission of encrypted management frames
  ath9k: discard undersized packets
  mt76: retry rx polling as long as there is budget left
  mt76: fix TSF value in probe responses
  mt76: add an intermediate struct for rx status information
  mt76: get station pointer by wcid and pass it to mac80211
  mt76: implement A-MPDU rx reordering in the driver code
  mt76: split mt76_rx_complete
  mt76: pass the per-vif wcid to the core for multicast rx
  mt76: validate rx CCMP PN

Igor Mitsyanko (2):
  qtnfmac: do not use mutexes in timer context
  qtnfmac: do not use bus mutex for events processing

Kalle Valo (1):
  Merge ath-next from git://git.kernel.org/.../kvalo/ath.git

Lior David (2):
  wil6210: fix random failure to bring network interface up
  wil6210: enlarge FW mac_rgf_ext section for Sparrow D0

Lorenzo Bianconi (5):
  mt76x2: fix WMM parameter configuration
  mt76x2: dfs: avoid tasklet scheduling during mt76x2_dfs_init_params()
  mt76x2: dfs: add set_domain handler
  mt76x2: dfs: take into account dfs region in mt76x2_dfs_init_params()
  mt76x2: init: disable all pending tasklets during device removal

Luis de Bethencourt (1):
  rtl8xxxu: Fix trailing semicolon

Maya Erez (5):
  wil6210: add Talyn PCIe device ID
  wil6210: recognize Talyn JTAG ID
  wil6210: add support for Talyn AHB address map
  wil6210: configure OTP HW vectors in SW reset flow
  wil6210: support parsing brd file address from fw file

Ping-Ke Shih (10):
  rtlwifi: btcoex: extend get_wifi_bw to support bandwidth 80M
  rtlwifi: btcoex: Add switch band notify for btc
  rtlwifi: btcoex: Add variable ant_div_cfg to support antenna diversity
  rtlwifi: btcoex: add scan_notify within ips_notify if RFON
  rtlwifi: btcoex: Add wifi_only series ops to control solo card
  rtlwifi: btcoex: add boolean variables dbg_mode
  rtlwifi: 8822be has to report vht capability to mac80211
  rtlwifi: Add ratr_table for newer IC
  rtlwifi: Add spec_ver to check whether use new rate-id or not
  rtlwifi: btcoex: Fix some static warnings from Sparse

Ramon Fried (1):
  wcn36xx: release DMA memory in case of error

Sergey Matyukevich (4):
  qtnfmac: modify supported interface combinations
  qtnfmac: validate interface combinations on changes
  qtnfmac: fix STA disconnect procedure
  qtnfmac: remove redundant 'unlikely' checks

Vasily Ulyanov (5):
  qtnfmac: remove struct qlink_cmd_set_mac_acl
  qtnfmac: fix warnings when mBSS setup is stopped
  qtnfmac: support 64-bit network interface stats
  qtnfmac: get more hardware info from card
  qtnfmac: report hardware/firmware information via ethtool

Wojciech Dubowik (4):
  ath9k: Alternative EEPROM size for AR9003
  ath9k: Read noise floor calibration data from eeprom
  ath9k: Use calibrated noise floor value when available
  ath9k: Display calibration data piers in debugfs

 drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 133 ++-
 drivers/net/wireless/ath/ath9k/ar9003_eeprom.h |  10 +
 drivers/net/wireless/ath/ath9k/calib.c |  38 +--
 drivers/net/wireless/ath/ath9k/hw.h|   2 +
 drivers/net/wireless/ath/ath9k/recv.c  |   4 +-
 drivers/net/wireless/ath/wcn36xx/dxe.c |  46 +++-
 drivers/net/wireless/ath/wil6210/boot_loader.h |   9 +-
 drivers/net/wireless/ath/wil6210/fw.h  |  18 +-
 drivers/net/wireless/ath/wil6210/fw_inc.c  | 167 -
 drivers/net/wireless/ath/wil6210/interrupt.c   |   6 +-
 driv

Re: pull-request: wireless-drivers 2018-01-26

[Kalle Valo]

David Miller <da...@davemloft.net> writes:

> From: Kalle Valo <kv...@codeaurora.org>
> Date: Fri, 26 Jan 2018 18:33:33 +0200
>
>> this is a pull request to the net tree for 4.15. I hate to do late pull
>> requests like this but today Sven Joachim found a serious regression in
>> one of ssb patches, I hope there's still enough time to get this to
>> 4.15.
>> 
>> But if it's too late, just let me know and I'll queue this for 4.16.
>
> I think this is going to have to wait for 4.16, I just sent what I hope
> is my last pull to Linus for this cycle.

Yeah, I guessed that when I noticed you sent your pull request just 3
minutes after mine :)

I'll send this to you next week in another pull request, please drop
this one.

-- 
Kalle Valo

pull-request: wireless-drivers 2018-01-26

[Kalle Valo]

Hi Dave,

this is a pull request to the net tree for 4.15. I hate to do late pull
requests like this but today Sven Joachim found a serious regression in
one of ssb patches, I hope there's still enough time to get this to
4.15.

But if it's too late, just let me know and I'll queue this for 4.16.

Kalle

The following changes since commit 1e19c4d689dc1e95bafd23ef68fbc0c6b9e05180:

  net: vrf: Add support for sends to local broadcast address (2018-01-25 
21:51:03 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2018-01-26

for you to fetch changes up to a9e6d44ddeccd3522670e641f1ed9b068e746ff7:

  ssb: Do not disable PCI host on non-Mips (2018-01-26 16:55:34 +0200)


wireless-drivers fixes for 4.15

ssb

* last minute patch to fix b43 and b44 drivers on non-mips platforms,
  a regression from v4.15-rc9


Sven Joachim (1):
  ssb: Do not disable PCI host on non-Mips

 drivers/ssb/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [v2] wcn36xx: release resources in case of error

[Kalle Valo]

Ramon Fried <rfr...@codeaurora.org> wrote:

> wcn36xx_dxe_init() doesn't check for the return value of
> wcn36xx_dxe_init_descs(), release the resources in case an error ocurred.
> 
> Signed-off-by: Ramon Fried <rfr...@codeaurora.org>
> Signed-off-by: Kalle Valo <kv...@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

d0bb950b9f5f wcn36xx: release DMA memory in case of error

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

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

Re: rtl8xxxu: Fix trailing semicolon

[Kalle Valo]

Luis de Bethencourt  wrote:

> The trailing semicolon is an empty statement that does no operation.
> Removing it since it doesn't do anything.
> 
> Signed-off-by: Luis de Bethencourt 
> Acked-by: Jes Sorensen 

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

8054a275de08 rtl8xxxu: Fix trailing semicolon

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

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

Re: [PATCH v2] wcn36xx: release resources in case of error

[Kalle Valo]

Ramon Fried <rfr...@codeaurora.org> writes:

> wcn36xx_dxe_init() doesn't check for the return value
> of wcn36xx_dxe_init_descs().
> This patch releases the resources in case an error ocurred.
>
> Change-Id: I924bd7489b60243c0a0cbaa716caf924f11d7587
> Signed-off-by: Ramon Fried <rfr...@codeaurora.org>

This compiled now, thanks. But I did some minor changes in the commit
log and in indentation on the pending branch:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=master-pending=e5ff4344eab68c86e00036e937847ce89dfaeef6

> @@ -819,11 +847,19 @@ int wcn36xx_dxe_init(struct wcn36xx *wcn)
>  
>   ret = wcn36xx_dxe_request_irqs(wcn);
>   if (ret < 0)
> - goto out_err;
> + goto out_err_irq;

The recommended style is to label the err_ based what the target does,
not from where they are called from. It's easier to manage the labels
that way. But as this is a style issue I didn't change it.

-- 
Kalle Valo

Re: wcn36xx: release resources in case of error

[Kalle Valo]

Ramon Fried  wrote:

> wcn36xx_dxe_init() doesn't check for the return value
> of wcn36xx_dxe_init_descs().
> This patch releases the resources in case an error ocurred.
> 
> Signed-off-by: Ramon Fried 

This is a duplicate.

Patch set to Superseded.

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

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

Re: wcn36xx: release resources in case of error

[Kalle Valo]

Ramon Fried  wrote:

> wcn36xx_dxe_init() doesn't check for the return value
> of wcn36xx_dxe_init_descs().
> This patch releases the resources in case an error ocurred.
> 
> Signed-off-by: Ramon Fried 

This is a duplicate.

Patch set to Superseded.

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

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