Re: [PATCH] mt76: fix debugfs_simple_attr.cocci warnings

[Fengguang Wu]

Hi Kalle,

On Thu, Dec 07, 2017 at 03:42:39PM +0200, Kalle Valo wrote:

kbuild test robot  writes:


drivers/net/wireless/mediatek/mt76/debugfs.c:36:0-23: WARNING: fops_regval 
should be defined with DEFINE_DEBUGFS_ATTRIBUTE

 Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
 for debugfs files.

Semantic patch information:
 Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
 imposes some significant overhead as compared to
 DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().

Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci

Fixes: a5f6039c8f9c ("mt76: add driver code for MT76x2e")
CC: Felix Fietkau 
Signed-off-by: Fengguang Wu 


I would like to apply this but the From field doesn't match the s-o-b
line. This patch is created automatically, right? I think the best is
that if you modify your script to add this to the beginning of the
commit log:

From: Fengguang Wu 

That way From and s-o-b match and you can continue to submit it from the
lkp address.


Good idea! I'll follow up with the change.

Thanks,
Fengguang

linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the wireless-drivers-next tree got a
conflict in:

  drivers/net/wireless/intel/iwlwifi/pcie/drv.c

between commit:

  567deca8e72d ("iwlwifi: add new cards for 9260 and 22000 series")

from the wireless-drivers tree and commit:

  2f7a3863191a ("iwlwifi: rename the temporary name of A000 to the official 
22000")

from the wireless-drivers-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index ccd7c33c4c28,5ed89d7ac4b2..
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@@ -652,20 -651,19 +652,20 @@@ static const struct pci_device_id iwl_h
{IWL_PCI_DEVICE(0xA370, 0x4034, iwl9560_2ac_cfg_soc)},
{IWL_PCI_DEVICE(0xA370, 0x40A4, iwl9462_2ac_cfg_soc)},
  
- /* a000 Series */
-   {IWL_PCI_DEVICE(0x2720, 0x0A10, iwla000_2ac_cfg_hr_cdb)},
-   {IWL_PCI_DEVICE(0x34F0, 0x0310, iwla000_2ac_cfg_jf)},
-   {IWL_PCI_DEVICE(0x2720, 0x, iwla000_2ax_cfg_hr)},
-   {IWL_PCI_DEVICE(0x34F0, 0x0070, iwla000_2ax_cfg_hr)},
-   {IWL_PCI_DEVICE(0x2720, 0x0078, iwla000_2ax_cfg_hr)},
-   {IWL_PCI_DEVICE(0x2720, 0x0070, iwla000_2ac_cfg_hr_cdb)},
-   {IWL_PCI_DEVICE(0x2720, 0x0030, iwla000_2ac_cfg_hr_cdb)},
-   {IWL_PCI_DEVICE(0x2720, 0x1080, iwla000_2ax_cfg_hr)},
-   {IWL_PCI_DEVICE(0x2720, 0x0090, iwla000_2ac_cfg_hr_cdb)},
-   {IWL_PCI_DEVICE(0x2720, 0x0310, iwla000_2ac_cfg_hr_cdb)},
-   {IWL_PCI_DEVICE(0x40C0, 0x, iwla000_2ax_cfg_hr)},
-   {IWL_PCI_DEVICE(0x40C0, 0x0A10, iwla000_2ax_cfg_hr)},
-   {IWL_PCI_DEVICE(0xA0F0, 0x, iwla000_2ax_cfg_hr)},
+ /* 22000 Series */
+   {IWL_PCI_DEVICE(0x2720, 0x0A10, iwl22000_2ac_cfg_hr_cdb)},
+   {IWL_PCI_DEVICE(0x34F0, 0x0310, iwl22000_2ac_cfg_jf)},
+   {IWL_PCI_DEVICE(0x2720, 0x, iwl22000_2ax_cfg_hr)},
+   {IWL_PCI_DEVICE(0x34F0, 0x0070, iwl22000_2ax_cfg_hr)},
+   {IWL_PCI_DEVICE(0x2720, 0x0078, iwl22000_2ax_cfg_hr)},
+   {IWL_PCI_DEVICE(0x2720, 0x0070, iwl22000_2ac_cfg_hr_cdb)},
+   {IWL_PCI_DEVICE(0x2720, 0x0030, iwl22000_2ac_cfg_hr_cdb)},
+   {IWL_PCI_DEVICE(0x2720, 0x1080, iwl22000_2ax_cfg_hr)},
+   {IWL_PCI_DEVICE(0x2720, 0x0090, iwl22000_2ac_cfg_hr_cdb)},
+   {IWL_PCI_DEVICE(0x2720, 0x0310, iwl22000_2ac_cfg_hr_cdb)},
+   {IWL_PCI_DEVICE(0x40C0, 0x, iwl22000_2ax_cfg_hr)},
+   {IWL_PCI_DEVICE(0x40C0, 0x0A10, iwl22000_2ax_cfg_hr)},
++  {IWL_PCI_DEVICE(0xA0F0, 0x, iwl22000_2ax_cfg_hr)},
  
  #endif /* CONFIG_IWLMVM */
  

Re: Where does rtlwifi/rtl8188ee identifies interrupt type?

[Larry Finger]

On 12/06/2017 11:01 PM, Farhan Khan wrote:

Hi all,

I am reading through the rtlwifi code, specifically rtl8188ee code. I
am trying to find the driver handles interrupts, reads from the card
and identifies what type of interrupt it receives.

I believe it will utilize the REG_HISR and REG_HIMR registers, but
only see writes to those register values, not reads which I was
expecting.


Keep in mind that all of the rtlwifi family of drivers actually use the routines 
in rtlwifi, and either rtl_pci or rtl_usb. They employ a lot more code than is 
found in their specific directory.


I will not be answering every question like this, but in this case look at 
_rtl_pci_interrupt().


Larry

Re: [PATCH v2 4/4] ath10k: WMI: add hw params entry for wcn3990

[Kalle Valo]

Rakesh Pillai  writes:

> Add hw params entry for wcn3990 and populate various
> target specific values for wcn3990.
>
> Signed-off-by: Rakesh Pillai 
> Signed-off-by: Govind Singh 

New warning:

drivers/net/wireless/ath/ath10k/hw.c:935:43: warning: Using plain integer as 
NULL pointer

-- 
Kalle Valo

Re: [PATCH v2 2/4] ath10k: WMI: Add management tx by reference support over wmi

[Kalle Valo]

Rakesh Pillai  writes:

> HL1.0 firmware branch, used in wcn3990, transmits management
> frames by reference over WMI.
>
> Add support for management tx by reference over WMI.
>
> Signed-off-by: Rakesh Pillai 
> Signed-off-by: Govind Singh 

This one has an endian problem:

drivers/net/wireless/ath/ath10k/wmi-tlv.c:2537:22: warning: incorrect type in 
assignment (different base types)
drivers/net/wireless/ath/ath10k/wmi-tlv.c:2537:22:expected restricted 
__le32 [usertype] vdev_id
drivers/net/wireless/ath/ath10k/wmi-tlv.c:2537:22:got unsigned int 
[unsigned] [assigned] [usertype] vdev_id

I recommend running ath10k-check before submission:

https://wireless.wiki.kernel.org/en/users/drivers/ath10k/codingstyle#checking_code

-- 
Kalle Valo

Re: [PATCH v2 1/4] ath10k: WMI: modify svc bitmap parsing for wcn3990

[Kalle Valo]

Rakesh Pillai  writes:

> Due to the limitation of wmi tlv parsing logic, if there are
> two parameters in a wmi event with same tlv tag, we can get only
> the last value, as it overwrites the prev value of the same tlv tag.
>
> The service ready event in wcn3990 contains two parameters of the
> same tag UINT32, due to which the svc bitmap is overwritten with the
> DBS support parameter.
>
> Refactor the service ready event parsing to allow parsing two tlv
> of the same tag UINT32 for wcn3990.
>
> Signed-off-by: Rakesh Pillai 
> Signed-off-by: Govind Singh 

ath10k-check found a warning in this patch:

drivers/net/wireless/ath/ath10k/wmi-tlv.c:981: braces {} are not necessary for 
single statement blocks

-- 
Kalle Valo

Re: ath10k: Fix invalid STS_CAP_OFFSET_MASK.

[Kalle Valo]

Ben Greear  wrote:

> The 10.4 firmware defines this as a 3-bit field, as does the
> mac80211 stack.  The 4th bit is defined as CONF_IMPLICIT_BF
> at least in the firmware header I have seen.  This patch
> fixes the ath10k wmi header to match the firmware.
> 
> Signed-off-by: Ben Greear 
> Signed-off-by: Kalle Valo 

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

8cec57f5277e ath10k: fix invalid STS_CAP_OFFSET_MASK

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

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

Re: ath6kl: improve endianness handling

[Kalle Valo]

Kenneth Lu  wrote:

> Replace ntohs with be16_to_cpu to do endian conversions for ethhdr
> h_proto assignment.
> 
> Signed-off-by: Kenneth Lu 
> Signed-off-by: Kalle Valo 

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

5d24bcd56dc7 ath6kl: improve endianness handling

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

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

Re: [2/3] ath9k: move spectral scan support under a separate config symbol

[Kalle Valo]

Matthias Schiffer  wrote:

> At the moment, spectral scan support, and with it RELAY, is always enabled
> with ATH9K[_HTC]_DEBUGFS. Spectral scan support is currently the only user
> of RELAY in ath9k, and it unconditionally reserves a relay channel.
> 
> Having debugfs support in ath9k is often useful even on very small embedded
> routers, where we'd rather like to avoid the code size and RAM usage of the
> relay support.
> 
> Signed-off-by: Matthias Schiffer 
> Signed-off-by: Kalle Valo 

2 patches applied to ath-next branch of ath.git, thanks.

9df7ddc3ed25 ath9k: move spectral scan support under a separate config symbol
42e01cb9cb10 ath10k: move spectral scan support under a separate config symbol

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

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

Re: [PATCH 1/3] ath9k: remove stray backslash in Makefile

[Kalle Valo]

Jakub Kicinski  writes:

> On Mon, 27 Nov 2017 18:56:21 +0100, Matthias Schiffer wrote:
>> Signed-off-by: Matthias Schiffer 
>> ---
>>  drivers/net/wireless/ath/ath9k/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/net/wireless/ath/ath9k/Makefile 
>> b/drivers/net/wireless/ath/ath9k/Makefile
>> index 36a40ffdce15..90e4a341076c 100644
>> --- a/drivers/net/wireless/ath/ath9k/Makefile
>> +++ b/drivers/net/wireless/ath/ath9k/Makefile
>> @@ -59,7 +59,7 @@ obj-$(CONFIG_ATH9K_HW) += ath9k_hw.o
>>  obj-$(CONFIG_ATH9K_COMMON) += ath9k_common.o
>>  ath9k_common-y:=common.o \
>>  common-init.o \
>> -common-beacon.o \
>> +common-beacon.o
>>  
>
> It's not necessarily stray, there is nothing on the next line so it's
> OK, and if you add \ at the end of all lines, you don't have to touch
> the last line every time you add/remove something.  Sort of like
> putting a , after last enum value.

I agree with Jakub, I think the backslash is there on purpose so I
dropped this patch.

-- 
Kalle Valo

Re: ath10k: use 64-bit crash dump timestamps

[Kalle Valo]

Arnd Bergmann  wrote:

> The dump format uses 64-bit timestamps already, but calling
> getnstimeofday() only returns a 32-bit number on 32-bit architectures,
> so that will overflow in y2038.
> 
> This changes it to use ktime_get_real_ts64() instead.
> 
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Kalle Valo 

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

dafa42036012 ath10k: use 64-bit crash dump timestamps

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

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

Re: ath6kl: remove redundant variable ies_len

[Kalle Valo]

Kenneth Lu  wrote:

> To get rid of W=1 warning: variable ‘ies_len’ set but not used.
> Variable ies_len is being assigned but never read.
> 
> Signed-off-by: Kenneth Lu 
> Reviewed-by: Steve deRosier 
> Signed-off-by: Kalle Valo 

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

d786ebb2f59b ath6kl: remove redundant variable ies_len

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

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

Re: pull-request: iwlwifi 2017-12-05

[Kalle Valo]

Luca Coelho  writes:

> Here is my third set of fixes for 4.15.  The most important fixes are
> for the new 9000 series where we were not handling some offloads
> correctly and secure connections were totally broken.  There is also 4
> new PCI IDs and an ROC fix on P2P.  More details in the tag
> description.
>
> I have sent this out before and kbuildbot didn't find any issues. 
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit 5c3de777bdaf48bd0cfb43097c0d0fb85056cab7:
>
>   brcmfmac: change driver unbind order of the sdio function devices 
> (2017-12-02 17:22:47 +0200)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
> tags/iwlwifi-for-kalle-2017-12-05
>
> for you to fetch changes up to bf19037074e770aad74b3b90f37b8b98db3f3748:
>
>   iwlwifi: mvm: mark MIC stripped MPDUs (2017-12-05 16:23:30 +0200)
>
> 
> Third batch of iwlwifi patches intended for 4.15.
>
> * Tell mac80211 when the MAC has been stripped (9000 series);
> * Tell mac80211 when the IVC has been stripped (9000 series);
> * Add 2 new PCI IDs, one for 9000 and one for 22000;
> * Fix a queue hang due during ROC.
>
> 

Pulled, thanks.

-- 
Kalle Valo

Re: [v1] brcmfmac: Avoid build error with make W=1

[Kalle Valo]

Andy Shevchenko  wrote:

> When I run make W=1 on gcc (Debian 7.2.0-16) 7.2.0 I got an error for
> the first run, all next ones are okay.
> 
>   CC [M]  drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot 
> parse struct or union!
> scripts/Makefile.build:310: recipe for target 
> 'drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o' failed
> 
> Seems like something happened with W=1 and wrong kernel doc format.
> As a quick fix remove dubious /** in the code.
> 
> Signed-off-by: Andy Shevchenko 
> Acked-by: Arend van Spriel 

Patch applied to wireless-drivers.git, thanks.

51ef7925e106 brcmfmac: Avoid build error with make W=1

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

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

Re: ssb: make SSB a menuconfig to ease disabling it all

[Kalle Valo]

Vincent Legoll  wrote:

> No need to get into the submenu to disable all SSB-related
> config entries.
> 
> This makes it easier to disable all SSB config options
> without entering the submenu. It will also enable one
> to see that en/dis-abled state from the outside menu.
> 
> This is only intended to change menuconfig UI, not change
> the config dependencies.
> 
> Signed-off-by: Vincent Legoll 

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

8c9fdd7687d9 ssb: make SSB a menuconfig to ease disabling it all

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

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

Re: [PATCH] mt76: fix returnvar.cocci warnings

[Kalle Valo]

kbuild test robot  writes:

> drivers/net/wireless/mediatek/mt76/mt76x2_main.c:86:5-8: Unneeded variable: 
> "ret". Return "0" on line 112
>
>
>  Remove unneeded variable used to store return value.
>
> Generated by: scripts/coccinelle/misc/returnvar.cocci
>
> Fixes: a5f6039c8f9c ("mt76: add driver code for MT76x2e")
> CC: Felix Fietkau 
> Signed-off-by: Fengguang Wu 

Here als the same problem with mismatching From and s-o-b lines.

-- 
Kalle Valo

Re: [PATCH] mt76: fix debugfs_simple_attr.cocci warnings

[Kalle Valo]

kbuild test robot  writes:

> drivers/net/wireless/mediatek/mt76/debugfs.c:36:0-23: WARNING: fops_regval 
> should be defined with DEFINE_DEBUGFS_ATTRIBUTE
>
>  Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
>  for debugfs files.
>
> Semantic patch information:
>  Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
>  imposes some significant overhead as compared to
>  DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
>
> Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Fixes: a5f6039c8f9c ("mt76: add driver code for MT76x2e")
> CC: Felix Fietkau 
> Signed-off-by: Fengguang Wu 

I would like to apply this but the From field doesn't match the s-o-b
line. This patch is created automatically, right? I think the best is
that if you modify your script to add this to the beginning of the
commit log:

From: Fengguang Wu 

That way From and s-o-b match and you can continue to submit it from the
lkp address.

-- 
Kalle Valo

Re: [v8,1/3] dt-bindings: net: add mt76 wireless device binding

[Kalle Valo]

Felix Fietkau  wrote:

> Add documentation describing how device tree can be used to configure
> wireless chips supported by the mt76 driver.
> 
> Signed-off-by: Felix Fietkau 

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

9402f8eb9bed dt-bindings: net: add mt76 wireless device binding
17f1de56df05 mt76: add common code shared between multiple chipsets
7bc04215a66b mt76: add driver code for MT76x2e

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

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

Re: [v3] bcma: Adjust block comment

[Kalle Valo]

Ashish Kalra  wrote:

> use * for block comments in multiple lines according to kernel coding
> style
> 
> Reported by: checkpatch.pl
> 
> Signed-off-by: Ashish Kalra 
> Reviewed-by: Himanshu Jha 

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

a765c8fdc869 bcma: Adjust block comment

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

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

Re: mwifiex: cfg80211: do not change virtual interface during scan processing

[Kalle Valo]

Xinming Hu  wrote:

> From: Limin Zhu 
> 
> (1) Change virtual interface operation in cfg80211 process reset and
> reinitilize private data structure.
> (2) Scan result event processed in main process will dereference private
> data structure concurrently, ocassionly crash the kernel.
> 
> The cornel case could be trigger by below steps:
> (1) wpa_cli mlan0 scan
> (2) ./hostapd mlan0.conf
> 
> Cfg80211 asynchronous scan procedure is not all the time operated
> under rtnl lock, here we add the protect to serialize the cfg80211
> scan and change_virtual interface operation.
> 
> Signed-off-by: Limin Zhu 
> Signed-off-by: Xinming Hu 

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

c61cfe49f0f0 mwifiex: cfg80211: do not change virtual interface during scan 
processing

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

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

Re: [v3] mwifiex: do not support change AP interface to station mode

[Kalle Valo]

Xinming Hu  wrote:

> Firmware do not support change interface from micro-ap mode
> to station mode, forbid this operation
> 
> Signed-off-by: Cathy Luo 
> Signed-off-by: Xinming Hu 

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

71121e420d75 mwifiex: do not support change AP interface to station mode

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

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

Re: rsi: fix memory leak on buf and usb_reg_buf

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> In the cases where len is too long, the error return path fails to
> kfree allocated buffers buf and usb_reg_buf.  The simplest fix is to
> perform the sanity check on len before the allocations to avoid having
> to do the kfree'ing in the first place.
> 
> Detected by CoverityScan, CID#1452258,1452259 ("Resource Leak")
> 
> Fixes: 59f73e2ae185 ("rsi: check length before USB read/write register")
> Signed-off-by: Colin Ian King 

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

c4ee30a280b1 wlcore, wl1251: fix spelling: "Couldnt" -> "Couldn't" and remove 
error on -ENOMEM

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

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

Re: [V2] wlcore, wl1251: fix spelling: "Couldnt" -> "Couldn't" and remove error on -ENOMEM

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in error message text.  Also remove the
> error message on an kzalloc failure as this is redundant.
> 
> Signed-off-by: Colin Ian King 

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

c4ee30a280b1 wlcore, wl1251: fix spelling: "Couldnt" -> "Couldn't" and remove 
error on -ENOMEM

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

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

Re: wlcore: allow elp during wowlan suspend

[Kalle Valo]

"Reizer, Eyal"  wrote:

> when enabling wowlan and entering suspend the last write to the firmware
> allowing it to go into elp mode was not completing before suspend, leaving
> the firmware running in full active mode consuming high power.
> Use an immediate call instead of a work queue for this last access
> allowing the firmware to go into power save during wowlan uspend.
> 
> Signed-off-by: Eyal Reizer 

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

37bf241b8e7b wlcore: allow elp during wowlan suspend

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

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

Re: wlcore: use boottime for fw time sync

[Kalle Valo]

Arnd Bergmann  wrote:

> Using getnstimeofday()/timespec_to_ns() causes an overflow on 32-bit
> architectures in 2038, and may suffer from time jumps due to
> settimeofday() or leap seconds.
> 
> I don't see a reason why this needs to be UTC, so either monotonic
> or boot time would be better here. Assuming that the fw time keeps
> running during suspend, boottime is better than monotonic, and
> ktime_get_boot_ns() will also save the additional conversion to
> nanoseconds.
> 
> Signed-off-by: Arnd Bergmann 

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

99f6996d4cba wlcore: use boottime for fw time sync

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

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

Re: [v2] mwl8k: Expand non-DFS 5G channels

[Kalle Valo]

Weixiao Zhang  wrote:

> Add non-DFS 5G upper channels (149-165) besides existed 4 lower channels
> (36, 40, 44, 48).
> 
> Signed-off-by: Weixiao Zhang 

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

4628257bf300 mwl8k: Expand non-DFS 5G channels

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

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

Re: rtlwifi: rtl818x: remove redundant check for cck_power > 15

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> cck_poweri cannot be greated than 15 as is derived from the bottom 4 bits
> from riv->channels[channel - 1].hw_value & 0xf.  Hence the check for it
> being greater than 15 is redundant and can be removed.
> 
> Detected by CoverityScan, CID#744303 ("Logically dead code")
> 
> Signed-off-by: Colin Ian King 

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

45d9d1a12efa rtlwifi: rtl818x: remove redundant check for cck_power > 15

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

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

Re: [1/3] rtlwifi: Reduce IO in RX interrupt to boost throughput

[Kalle Valo]

Ping-Ke Shih  wrote:

> From: Ping-Ke Shih 
> 
> Check remaining count of RX packets cost a lot of CPU time, so only update
> when the counter decreases to zero. In old flow, the counter was updated
> once a RX packet is received.
> 
> Signed-off-by: Steven Ting 
> Signed-off-by: Ping-Ke Shih 

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

fb9829e90dcd rtlwifi: Reduce IO in RX interrupt to boost throughput
dc9682a0cca5 rtlwifi: fix the wrong size to calculate fifo space
cf54622c8076 rtlwifi: cleanup the code that check whether TX ring is available

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

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

Re: rtlwifi: Convert individual interrupt results to struct

[Kalle Valo]

Larry Finger  wrote:

> With the RTL8822BE and later devices, the number of interrupt vectors
> has grown from 2 to 4. At this point, saving and passing those vectors
> in a struct makes more sense than using individual scaler variables.
> 
> In two of the drivers, code to process the second of the interrupt
> registers was included, but commented out. This patch removes those
> useless sections.
> 
> Signed-off-by: Larry Finger 
> Cc: Ping-Ke Shih 

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

78aa6012033f rtlwifi: Convert individual interrupt results to struct

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

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

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

[Kalle Valo]

Arend Van Spriel  wrote:

> From: Ian Molton 
> 
> All the other IO functions are the other way round in this
> driver. Make this one match.
> 
> Signed-off-by: Ian Molton 
> Signed-off-by: Arend van Spriel 

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

1fd3ae124d5e brcmfmac: Fix parameter order in brcmf_sdiod_f0_writeb()
1e6f676f43aa brcmfmac: Register sizes on hardware are not dependent on compiler 
types
0fcc9fe00484 brcmfmac: Split brcmf_sdiod_regrw_helper() up.
b9b0d290bc0c brcmfmac: Clean up brcmf_sdiod_set_sbaddr_window()
ea243e9077b3 brcmfmac: Remove dead IO code
4a3338ba2a74 brcmfmac: Remove bandaid for SleepCSR
993a98a42e6e brcmfmac: Remove brcmf_sdiod_request_data()
3508a056a1f4 brcmfmac: Fix asymmetric IO functions.
12e3e74e2820 brcmfmac: Remove noisy debugging.
dd8a2d49e4ed brcmfmac: Rename bcmerror to err

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

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

RE: ICT Service Desk

[Diaz Rivera, Richard P]

Dear Outlook User,

We received your request to delete your Outlook email Account,
We will process your request within 24 hours.

All features associated with your Outlook email account will be lost.

To retain your Account, kindly Cancel Request to continue using our services.

CANCEL REQUEST

© 2017 Outlook. Support.
All Rights Reserved.

Re: [PATCH 00/10] brcmfmac: restructuring sdio access functions

[Kalle Valo]

Arend van Spriel  writes:

> On 12/7/2017 9:49 AM, Kalle Valo wrote:
>> Arend van Spriel  writes:
>>
>>> On 11/13/2017 9:35 PM, Arend van Spriel wrote:
 These patches were originally submitted by Ian Molton a while ago so 
 decided
 to resubmit them. This is a first series of 10 patches. Tested using 
 BCM4354
 device which showed no regression.

 It is intended for 4.16 (no rush ;-) ) and applies to the master branch of
 the wireless-drivers-next repository.
>>>
>>> Hi Kalle,
>>>
>>> I have follow-up series on this one. If you plan to take it today or
>>> tomorrow, I can hold the follow-up a bit more.
>>
>> I'm hoping to apply these today.
>>
>
> btw. my neighbors put out the Finnish flag.

Cool!

> Was that about your independence? Not a yearly event, or is it?

December 6th is the independence day in Finland and that's a yearly
event, a public holiday etc. But this year was special as it was 100
years from gaining our independence.

So yesterday, instead of applying patches, I was looking at people
shaking hands[1] on TV. Yes, we are weird ;)

[1] https://en.wikipedia.org/wiki/Independence_Day_Reception_(in_Finland)

-- 
Kalle Valo

Re: [PATCH] brcmsmac: use ARRAY_SIZE on rfseq_updategainu_events

[Arend van Spriel]

On 12/7/2017 11:20 AM, Colin King wrote:

From: Colin Ian King 

Use the ARRAY_SIZE macro on rfseq_updategainu_events to determine
size of the array. Improvement suggested by coccinelle.


Acked-by: Arend van Spriel 

Signed-off-by: Colin Ian King 
---
  drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

RE: [EXT] Re: [PATCH 1/3] mwifiex: cleanup rx_pkt_lock usage in 11n_rxreorder.c

[Ganapathi Bhat]

Hi Doug/Brian

> -Original Message-
> From: diand...@google.com [mailto:diand...@google.com] On Behalf Of
> Doug Anderson
> Sent: Wednesday, November 08, 2017 2:45 AM
> To: Ganapathi Bhat
> Cc: Brian Norris; linux-wireless@vger.kernel.org; Cathy Luo; Xinming Hu;
> Zhiyuan Yang; James Cao; Mangesh Malusare; Karthik Doddayennegere
> Ananthapadmanabha
> Subject: Re: [EXT] Re: [PATCH 1/3] mwifiex: cleanup rx_pkt_lock usage in
> 11n_rxreorder.c
>
> Hi,
>
> On Tue, Nov 7, 2017 at 8:25 AM, Ganapathi Bhat 
> wrote:
> > Hi Doug/Brian,
> >
> > Thanks a lot for the comments and the discussion. First of all we will abort
> the change added by this patch as we don't need rx_pkt_lock acquired to
> protect the deleted item.  Next, we will prepare below changes to address
> the concerns discussed:
> > 1. Move rx_pkt_lock from mwifiex_private to rx_reorder_tbl
>
> ...or, possibly, remove rx_pkt_lock completely.  See my other response...
After checking the flow, I am thinking of removing below 3 spin locks:
rx_reorder_tbl_lock
rx_pkt_lock
tx_ba_stream_tbl_lock
As you both have pointed earlier, they used by main thread and occasionally by 
cfg80211 (for TDLS configuration).
Can you please comment on this change? Is it OK to ignore cfg80211 here.
>
> -Doug

Regards,
Ganapathi

[PATCH] brcmsmac: use ARRAY_SIZE on rfseq_updategainu_events

[Colin King]

From: Colin Ian King 

Use the ARRAY_SIZE macro on rfseq_updategainu_events to determine
size of the array. Improvement suggested by coccinelle.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
index 763e8ba6b178..7e01981bc5c8 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c
@@ -16049,8 +16049,7 @@ static void wlc_phy_workarounds_nphy_gainctrl(struct 
brcms_phy *pi)
wlc_phy_set_rfseq_nphy(pi, NPHY_RFSEQ_UPDATEGAINU,
   rfseq_updategainu_events,
   rfseq_updategainu_dlys,
-  sizeof(rfseq_updategainu_events) /
-  sizeof(rfseq_updategainu_events[0]));
+  ARRAY_SIZE(rfseq_updategainu_events));
 
mod_phy_reg(pi, 0x153, (0xff << 8), (90 << 8));
 
-- 
2.14.1

[PATCH] brcmfmac: Support 43455 save-restore (SR) feature if FW include -sr

[Wright Feng]

From: Double Lo 

This patch will add 43455 into the save-restore(SR) capable chip list, so
the SR engine will be enabled with 43455 FW which built-in the -sr
function.

Signed-off-by: Double Lo 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index c5d1a1c..f7b30ce 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -1338,6 +1338,7 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
switch (pub->chip) {
case BRCM_CC_4354_CHIP_ID:
case BRCM_CC_4356_CHIP_ID:
+   case BRCM_CC_4345_CHIP_ID:
/* explicitly check SR engine enable bit */
pmu_cc3_mask = BIT(2);
/* fall-through */
-- 
1.9.1

Re: [v4 5/8] Bluetooth: btrsi: add new rsi bluetooth driver

[Marcel Holtmann]

Hi Amitkumar,

> Redpine bluetooth driver is a thin driver which depends on
> 'rsi_91x' driver for transmitting and receiving packets
> to/from device. It creates hci interface when attach() is
> called from 'rsi_91x' module.
> 
> Signed-off-by: Prameela Rani Garnepudi 
> Signed-off-by: Siva Rebbagondla 
> Signed-off-by: Amitkumar Karwar 
> ---
> v4: Removed rsi_hci.h file. Made the functions static(Marcel)
> v3: Made BT_RSI module by default off(Marcel)
>Removed redundant exported function rsi_get_hci_ops()(Marcel)
> v2: Addressed review comments from Marcel
>Removed unnecessary 'depends on BT && BT_RFOMM' line in Kconfig
>Removed redundant BT_INFO messages
>h_adapter initialization and declaration in a single line.
>Removed unnecessary error checks for HCI_RUNNING and fsm_state
>Allocated new skb with skb_realloc_headroom() API if headroom is not 
> sufficient
>Used get_unaligned_le16 helpers
>Moved a structure and union from header file to btrsi.c file
> ---
> drivers/bluetooth/Kconfig  |  11 +++
> drivers/bluetooth/Makefile |   2 +
> drivers/bluetooth/btrsi.c  | 224 +
> include/linux/rsi_header.h |   2 +
> 4 files changed, 239 insertions(+)
> create mode 100644 drivers/bluetooth/btrsi.c
> 
> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
> index 60e1c7d..33d7514 100644
> --- a/drivers/bluetooth/Kconfig
> +++ b/drivers/bluetooth/Kconfig
> @@ -378,4 +378,15 @@ config BT_QCOMSMD
> Say Y here to compile support for HCI over Qualcomm SMD into the
> kernel or say M to compile as a module.
> 
> +config BT_RSI
> + tristate "Redpine HCI support"
> + default n
> + help
> +   Redpine BT driver.
> +   This driver handles BT traffic from upper layers and pass
> +   to the RSI_91x coex module for further scheduling to device
> +
> +   Say Y here to compile support for HCI over Redpine into the
> +   kernel or say M to compile as a module.
> +
> endmenu
> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
> index 4e4e44d..712af83a 100644
> --- a/drivers/bluetooth/Makefile
> +++ b/drivers/bluetooth/Makefile
> @@ -28,6 +28,8 @@ obj-$(CONFIG_BT_QCA)+= btqca.o
> 
> obj-$(CONFIG_BT_HCIUART_NOKIA)+= hci_nokia.o
> 
> +obj-$(CONFIG_BT_RSI) += btrsi.o
> +
> btmrvl-y  := btmrvl_main.o
> btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
> 
> diff --git a/drivers/bluetooth/btrsi.c b/drivers/bluetooth/btrsi.c
> new file mode 100644
> index 000..f76ae4d
> --- /dev/null
> +++ b/drivers/bluetooth/btrsi.c
> @@ -0,0 +1,224 @@
> +/**
> + * Copyright (c) 2017 Redpine Signals Inc.
> + *
> + * Permission to use, copy, modify, and/or distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* RX frame types */
> +#define RSI_RESULT_CONFIRM   0x80
> +#define RSI_BT_PER   0x10
> +#define RSI_BT_BER   0x11
> +#define RSI_BT_CW0x12
> +
> +#define RSI_HEADROOM_FOR_BT_HAL  16
> +#define RSI_FRAME_DESC_SIZE  16
> +
> +static struct rsi_hci_adapter {
> + void *priv;
> + struct rsi_proto_ops *proto_ops;
> + struct hci_dev *hdev;
> +};
> +
> +static int rsi_hci_open(struct hci_dev *hdev)
> +{
> + return 0;
> +}
> +
> +static int rsi_hci_close(struct hci_dev *hdev)
> +{
> + return 0;
> +}
> +
> +static int rsi_hci_flush(struct hci_dev *hdev)
> +{
> + return 0;
> +}
> +
> +static int rsi_hci_send_pkt(struct hci_dev *hdev, struct sk_buff *skb)
> +{
> + struct rsi_hci_adapter *h_adapter = hci_get_drvdata(hdev);
> + struct sk_buff *new_skb = NULL;
> +
> + switch (bt_cb(skb)->pkt_type) {
> + case HCI_COMMAND_PKT:
> + hdev->stat.cmd_tx++;
> + break;
> +
> + case HCI_ACLDATA_PKT:
> + hdev->stat.acl_tx++;
> + break;
> +
> + case HCI_SCODATA_PKT:
> + hdev->stat.sco_tx++;
> + break;
> + }

Scrab these empty lines before the break. No need to bloat this up.

> +
> + if (skb_headroom(skb) < RSI_HEADROOM_FOR_BT_HAL) {
> + /* Insufficient skb headroom - all

Re: [PATCH 00/10] brcmfmac: restructuring sdio access functions

[Arend van Spriel]

On 12/7/2017 9:49 AM, Kalle Valo wrote:

Arend van Spriel  writes:


On 11/13/2017 9:35 PM, Arend van Spriel wrote:

These patches were originally submitted by Ian Molton a while ago so decided
to resubmit them. This is a first series of 10 patches. Tested using BCM4354
device which showed no regression.

It is intended for 4.16 (no rush ;-) ) and applies to the master branch of
the wireless-drivers-next repository.


Hi Kalle,

I have follow-up series on this one. If you plan to take it today or
tomorrow, I can hold the follow-up a bit more.


I'm hoping to apply these today.



btw. my neighbors put out the Finnish flag. Was that about your 
independence? Not a yearly event, or is it?


Gr. AvS

Re: [PATCH 00/10] brcmfmac: restructuring sdio access functions

[Kalle Valo]

Arend van Spriel  writes:

> On 11/13/2017 9:35 PM, Arend van Spriel wrote:
>> These patches were originally submitted by Ian Molton a while ago so decided
>> to resubmit them. This is a first series of 10 patches. Tested using BCM4354
>> device which showed no regression.
>>
>> It is intended for 4.16 (no rush ;-) ) and applies to the master branch of
>> the wireless-drivers-next repository.
>
> Hi Kalle,
>
> I have follow-up series on this one. If you plan to take it today or
> tomorrow, I can hold the follow-up a bit more.

I'm hoping to apply these today.

-- 
Kalle Valo

Re: [PATCH 00/10] brcmfmac: restructuring sdio access functions

[Arend van Spriel]

On 11/13/2017 9:35 PM, Arend van Spriel wrote:

These patches were originally submitted by Ian Molton a while ago so decided
to resubmit them. This is a first series of 10 patches. Tested using BCM4354
device which showed no regression.

It is intended for 4.16 (no rush ;-) ) and applies to the master branch of
the wireless-drivers-next repository.


Hi Kalle,

I have follow-up series on this one. If you plan to take it today or 
tomorrow, I can hold the follow-up a bit more.


Regards,
Arend