Re: Need support for Intel new wifi module 9462NGW

2017-11-16 Thread Luca Coelho 
On Fri, 2017-11-17 at 15:38 +0800, Chris Chiu wrote:
> On Fri, Nov 17, 2017 at 2:46 PM, Luca Coelho  wrote:
> > On Fri, 2017-11-17 at 14:39 +0800, Chris Chiu wrote:
> > > On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho 
> > > wrote:
> > > > Hi Chris,
> > > > 
> > > > On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
> > > > > Hi Luca,
> > > > > Any suggestion for the "Failed to start INIT ucode: -110"
> > > > > issue
> > > > > for the firmware?
> > > > 
> > > > There were a few problems which should now be fixed.  We
> > > > published
> > > > new
> > > > firmwares in our linux-firmware.git tree[1] and also made some
> > > > fixes in
> > > > the driver[2].  Please update your system accordingly and let
> > > > me
> > > > know
> > > > if it works for you.
> > > > 
> > > > Thanks!
> > > > 
> > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/lin
> > > > ux-f
> > > > irmware.git/
> > > > [2] https://patchwork.kernel.org/patch/10059871/
> > > > https://patchwork.kernel.org/patch/10059875/
> > > > https://patchwork.kernel.org/patch/10059873/
> > > > 
> > > > --
> > > > Cheers,
> > > > Luca.
> > > 
> > > Hi Luca,
> > 
> > Hi Chris,
> > 
> > 
> > > Thanks for your patch and updated firmware. The driver can
> > > initialize w/o error now. However, it always fails on ip-config
> > > after
> > > 4-way handshake complete. I have to mention that I removed the
> > > field
> > > ".soc_latency" in all new iwl_cfg you added in
> > > https://patchwork.kernel.org/patch/10059875/ to remove compile
> > > error
> > > based on the linux mainline 4.14.
> > > I don't know whether if this causes the problem. Do you need
> > > me
> > > to
> > > do anything for more information?
> > 
> > That was my fault, I forgot to include one file in my commit.  I
> > have
> > sent v2 of the two last patches to solve the problem.  Can you try
> > them?
> > 
> > The problem you're seeing could be related to that, because we use
> > a
> > bit longer wait period for HW stabilization with integrated
> > devices.
> > And if you remove it, you may encounter random problems...
> > 
> > --
> > Cheers,
> > Luca.
> 
> Hi Luca,
> Thanks for your quick response. I  tried your v2 patch but things
> remain the same. The signal strength and scan results seems nothing
> wrong but still fail to get ip from DHCP server. Please let me know
> what I can help here.

Can you provide the dmesg output and trace-cmd logs as explained here?

https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging


--
Cheers,
Luca.

Re: Need support for Intel new wifi module 9462NGW

2017-11-16 Thread Chris Chiu 
On Fri, Nov 17, 2017 at 2:46 PM, Luca Coelho  wrote:
> On Fri, 2017-11-17 at 14:39 +0800, Chris Chiu wrote:
>> On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho  wrote:
>> > Hi Chris,
>> >
>> > On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
>> > > Hi Luca,
>> > > Any suggestion for the "Failed to start INIT ucode: -110"
>> > > issue
>> > > for the firmware?
>> >
>> > There were a few problems which should now be fixed.  We published
>> > new
>> > firmwares in our linux-firmware.git tree[1] and also made some
>> > fixes in
>> > the driver[2].  Please update your system accordingly and let me
>> > know
>> > if it works for you.
>> >
>> > Thanks!
>> >
>> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-f
>> > irmware.git/
>> > [2] https://patchwork.kernel.org/patch/10059871/
>> > https://patchwork.kernel.org/patch/10059875/
>> > https://patchwork.kernel.org/patch/10059873/
>> >
>> > --
>> > Cheers,
>> > Luca.
>>
>> Hi Luca,
>
> Hi Chris,
>
>
>> Thanks for your patch and updated firmware. The driver can
>> initialize w/o error now. However, it always fails on ip-config after
>> 4-way handshake complete. I have to mention that I removed the field
>> ".soc_latency" in all new iwl_cfg you added in
>> https://patchwork.kernel.org/patch/10059875/ to remove compile error
>> based on the linux mainline 4.14.
>> I don't know whether if this causes the problem. Do you need me
>> to
>> do anything for more information?
>
> That was my fault, I forgot to include one file in my commit.  I have
> sent v2 of the two last patches to solve the problem.  Can you try
> them?
>
> The problem you're seeing could be related to that, because we use a
> bit longer wait period for HW stabilization with integrated devices.
> And if you remove it, you may encounter random problems...
>
> --
> Cheers,
> Luca.

Hi Luca,
Thanks for your quick response. I  tried your v2 patch but things
remain the same. The signal strength and scan results seems nothing
wrong but still fail to get ip from DHCP server. Please let me know
what I can help here.

Chris

Re: Need support for Intel new wifi module 9462NGW

2017-11-16 Thread Luca Coelho 
Here are the links to v2 of the last two patches, please try with these
instead (keep the first one that you already have):

https://patchwork.kernel.org/patch/10060837/
https://patchwork.kernel.org/patch/10060839/

--
Cheers,
Luca.


On Fri, 2017-11-17 at 08:46 +0200, Luca Coelho wrote:
> On Fri, 2017-11-17 at 14:39 +0800, Chris Chiu wrote:
> > On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho 
> > wrote:
> > > Hi Chris,
> > > 
> > > On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
> > > > Hi Luca,
> > > > Any suggestion for the "Failed to start INIT ucode: -110"
> > > > issue
> > > > for the firmware?
> > > 
> > > There were a few problems which should now be fixed.  We
> > > published
> > > new
> > > firmwares in our linux-firmware.git tree[1] and also made some
> > > fixes in
> > > the driver[2].  Please update your system accordingly and let me
> > > know
> > > if it works for you.
> > > 
> > > Thanks!
> > > 
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux
> > > -f
> > > irmware.git/
> > > [2] https://patchwork.kernel.org/patch/10059871/
> > > https://patchwork.kernel.org/patch/10059875/
> > > https://patchwork.kernel.org/patch/10059873/
> > > 
> > > --
> > > Cheers,
> > > Luca.
> > 
> > Hi Luca,
> 
> Hi Chris,
> 
> 
> > Thanks for your patch and updated firmware. The driver can
> > initialize w/o error now. However, it always fails on ip-config
> > after
> > 4-way handshake complete. I have to mention that I removed the
> > field
> > ".soc_latency" in all new iwl_cfg you added in
> > https://patchwork.kernel.org/patch/10059875/ to remove compile
> > error
> > based on the linux mainline 4.14.
> > I don't know whether if this causes the problem. Do you need me
> > to
> > do anything for more information?
> 
> That was my fault, I forgot to include one file in my commit.  I have
> sent v2 of the two last patches to solve the problem.  Can you try
> them?
> 
> The problem you're seeing could be related to that, because we use a
> bit longer wait period for HW stabilization with integrated devices. 
> And if you remove it, you may encounter random problems...
> 
> --
> Cheers,
> Luca.

Re: Need support for Intel new wifi module 9462NGW

2017-11-16 Thread Luca Coelho 
On Fri, 2017-11-17 at 14:39 +0800, Chris Chiu wrote:
> On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho  wrote:
> > Hi Chris,
> > 
> > On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
> > > Hi Luca,
> > > Any suggestion for the "Failed to start INIT ucode: -110"
> > > issue
> > > for the firmware?
> > 
> > There were a few problems which should now be fixed.  We published
> > new
> > firmwares in our linux-firmware.git tree[1] and also made some
> > fixes in
> > the driver[2].  Please update your system accordingly and let me
> > know
> > if it works for you.
> > 
> > Thanks!
> > 
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-f
> > irmware.git/
> > [2] https://patchwork.kernel.org/patch/10059871/
> > https://patchwork.kernel.org/patch/10059875/
> > https://patchwork.kernel.org/patch/10059873/
> > 
> > --
> > Cheers,
> > Luca.
> 
> Hi Luca,

Hi Chris,


> Thanks for your patch and updated firmware. The driver can
> initialize w/o error now. However, it always fails on ip-config after
> 4-way handshake complete. I have to mention that I removed the field
> ".soc_latency" in all new iwl_cfg you added in
> https://patchwork.kernel.org/patch/10059875/ to remove compile error
> based on the linux mainline 4.14.
> I don't know whether if this causes the problem. Do you need me
> to
> do anything for more information?

That was my fault, I forgot to include one file in my commit.  I have
sent v2 of the two last patches to solve the problem.  Can you try
them?

The problem you're seeing could be related to that, because we use a
bit longer wait period for HW stabilization with integrated devices. 
And if you remove it, you may encounter random problems...

--
Cheers,
Luca.

Re: Need support for Intel new wifi module 9462NGW

2017-11-16 Thread Chris Chiu 
On Thu, Nov 16, 2017 at 5:49 PM, Luca Coelho  wrote:
> Hi Chris,
>
> On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
>> Hi Luca,
>> Any suggestion for the "Failed to start INIT ucode: -110" issue
>> for the firmware?
>
> There were a few problems which should now be fixed.  We published new
> firmwares in our linux-firmware.git tree[1] and also made some fixes in
> the driver[2].  Please update your system accordingly and let me know
> if it works for you.
>
> Thanks!
>
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/
> [2] https://patchwork.kernel.org/patch/10059871/
> https://patchwork.kernel.org/patch/10059875/
> https://patchwork.kernel.org/patch/10059873/
>
> --
> Cheers,
> Luca.

Hi Luca,
Thanks for your patch and updated firmware. The driver can
initialize w/o error now. However, it always fails on ip-config after
4-way handshake complete. I have to mention that I removed the field
".soc_latency" in all new iwl_cfg you added in
https://patchwork.kernel.org/patch/10059875/ to remove compile error
based on the linux mainline 4.14.
I don't know whether if this causes the problem. Do you need me to
do anything for more information?

Chris

wlcore: wl18xx: Trouble suspending caused by wifi being enabled?

2017-11-16 Thread John Stultz 
Hey Folks,
  So, for awhile recently, I've noticed my HiKey board (which uses the
TI WL1835MOD chip for wifi) has had trouble when it tries to suspend.
Basically it keeps on waking up while suspending, and then
re-suspending over and over until it lucks out in whatever race is
going on and manages to suspend before the wifi wakes it up.

Here's an example suspend-immediate-wake cycle:

[  241.975754] PM: suspend entry (deep)
[  241.979590] PM: Syncing filesystems ... done.
[  241.997363] Freezing user space processes ... (elapsed 0.003 seconds) done.
[  242.007903] OOM killer disabled.
[  242.011157] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[  242.020715] Suspending console(s) (use no_console_suspend to debug)
[  242.028155] wlan0: deauthenticating from 70:3a:cb:12:90:28 by local
choice (Reason: 3=DEAUTH_LEAVING)
[  242.029797] dwc2 f72c.usb: suspending usb gadget configfs-gadget
[  242.029885] dwc2 f72c.usb: dwc2_hsotg_ep_disable: called for ep0
[  242.029893] dwc2 f72c.usb: dwc2_hsotg_ep_disable: called for ep0
[  242.071475] wlcore: down
[  242.071795] queueing ieee80211 work while going to suspend
[  242.071808] wlcore: down
[  242.072120] queueing ieee80211 work while going to suspend
[  242.073796] PM: Wakeup pending, aborting suspend
[  242.073810] PM: Some devices failed to suspend, or early wake event detected
[  242.091277] mmc_host mmc2: Bus speed (slot 0) = 2480Hz (slot
req 40Hz, actual 40HZ div = 31)
[  242.128593] mmc_host mmc2: Bus speed (slot 0) = 2480Hz (slot
req 2500Hz, actual 2480HZ div = 0)
[  242.129197] dwc2 f72c.usb: resuming usb gadget configfs-gadget
[  242.337364] dwc2 f72c.usb: new device is high-speed
[  242.413119] dwc2 f72c.usb: new device is high-speed
[  242.452173] wlcore: PHY firmware version: Rev 8.2.0.0.237
[  242.484959] dwc2 f72c.usb: new address 8
[  242.499012] wlcore: firmware booted (Rev 8.9.0.0.70)
[  242.506240] configfs-gadget gadget: high-speed config #1: b
[  242.627752] OOM killer enabled.
[  242.630899] Restarting tasks ... done.
[  242.647180] PM: suspend exit

Eventually it will luck out and manage to suspend itself, but it can
take close to a minute.  If I disable wifi the system reliably
suspends every time.

This used to not be the case, but its been so long, I'm not really
sure when this issue cropped up.

I wanted to see if anyone else had similar trouble or maybe had ideas
how to chase this down?

thanks
-john

ath9k: Question regarding adaptivity and ETSI compliance

2017-11-16 Thread Florian Hercher 
Hi all,

ETSI EN-300-328 in version 2.1.1 (2016-11) requires an "adaptive" behaviour of 
Wi-Fi Access Points, see clause 4.3.2.6.1 and annex B.7. As far as I 
understand this adaptive behavior requires the Wi-Fi card to stop transmitting 
whenever an (non Wi-Fi) interference signal with a power level of more than 
-70dBm/Mhz is present.

Does ath9k comply with this requirement? Or more specifically: Does ath9k 
running on a AR9331 (MAC version: AR9330, MAC revision: 1) comply?

Right now I'm trying to understand the "clear channel assessment" (CCA) 
related settings in the driver and I would like to ask for some clarification:

The CCA related definitions in ar9003_phy.h e.g. 
"AR_PHY_CCA_MAX_GOOD_VAL_9300_2GHZ" - are they part of the "higher" CCA 
function, where still decodable Wi-FI signals are handled?
Where is the energy detection threshold defined, is it "thres62" in "struct 
ar9300_eeprom"?

I'm quite confused about this and any help is highly appreciated!

best regards
Florian

---
http://www.etsi.org/deliver/etsi_en/300300_300399/300328/02.01.01_60/
en_300328v020101p.pdf

Re: [PATCH v4] wcn36xx: Set default BTLE coexistence config

2017-11-16 Thread Bjorn Andersson 
On Thu 16 Nov 00:01 PST 2017, Ramon Fried wrote:

> From: Eyal Ilsar 
> 
> If the value for the firmware configuration parameters
> BTC_STATIC_LEN_LE_BT and BTC_STATIC_LEN_LE_WLAN are not set the duty
> cycle between BT and WLAN is such that if BT (including BLE) is active
> WLAN gets 0 bandwidth. When tuning these parameters having a too high
> value for WLAN means that BLE performance degrades.
> The "sweet" point of roughly half of the maximal values was empirically
> found to achieve a balance between BLE and Wi-Fi coexistence
> performance.
> 
> Signed-off-by: Eyal Ilsar 
> Signed-off-by: Ramon Fried 

Looks good,

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/net/wireless/ath/wcn36xx/smd.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
> b/drivers/net/wireless/ath/wcn36xx/smd.c
> index 9c6590d5348a..6f1e741acf3e 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -73,6 +73,8 @@ static struct wcn36xx_cfg_val wcn36xx_cfg_vals[] = {
>   WCN36XX_CFG_VAL(TX_PWR_CTRL_ENABLE, 1),
>   WCN36XX_CFG_VAL(ENABLE_CLOSE_LOOP, 1),
>   WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
> + WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_BT, 12),
> + WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_WLAN, 3),
>   WCN36XX_CFG_VAL(MAX_ASSOC_LIMIT, 10),
>   WCN36XX_CFG_VAL(ENABLE_MCC_ADAPTIVE_SCHEDULER, 0),
>  };
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>

[PATCH] rsi: fix memory leak on buf and usb_reg_buf

2017-11-16 Thread Colin King 
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 
---
 drivers/net/wireless/rsi/rsi_91x_usb.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c 
b/drivers/net/wireless/rsi/rsi_91x_usb.c
index 08730227cd18..8f8443833348 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
@@ -162,13 +162,13 @@ static int rsi_usb_reg_read(struct usb_device *usbdev,
u8 *buf;
int status = -ENOMEM;
 
+   if (len > RSI_USB_CTRL_BUF_SIZE)
+   return -EINVAL;
+
buf  = kmalloc(RSI_USB_CTRL_BUF_SIZE, GFP_KERNEL);
if (!buf)
return status;
 
-   if (len > RSI_USB_CTRL_BUF_SIZE)
-   return -EINVAL;
-
status = usb_control_msg(usbdev,
 usb_rcvctrlpipe(usbdev, 0),
 USB_VENDOR_REGISTER_READ,
@@ -207,13 +207,13 @@ static int rsi_usb_reg_write(struct usb_device *usbdev,
u8 *usb_reg_buf;
int status = -ENOMEM;
 
+   if (len > RSI_USB_CTRL_BUF_SIZE)
+   return -EINVAL;
+
usb_reg_buf  = kmalloc(RSI_USB_CTRL_BUF_SIZE, GFP_KERNEL);
if (!usb_reg_buf)
return status;
 
-   if (len > RSI_USB_CTRL_BUF_SIZE)
-   return -EINVAL;
-
usb_reg_buf[0] = (value & 0x00ff);
usb_reg_buf[1] = (value & 0xff00) >> 8;
usb_reg_buf[2] = 0x0;
-- 
2.14.1

Re: [PATCH] staging: wilc1000: Fix bssid buffer offset in Txq

2017-11-16 Thread Claudiu Beznea 
Hi Aditya,

My problem is fixed with this patch. WILC1000 connects to AP,
IP is retrieved from DHCP server and ping works. You can add my

Tested-by: Claudiu Beznea 

Thanks,
Claudiu

On 03.11.2017 10:56, Aditya Shankar wrote:
> Commit 46949b48568b ("staging: wilc1000: New cfg packet
> format in handle_set_wfi_drv_handler") updated the frame
> format sent from host to the firmware. The code to update
> the bssid offset in the new frame was part of a second
> patch in the series which did not make it in and thus
> causes connection problems after associating to an AP.
> 
> This fix adds the proper offset of the bssid value in the
> Tx queue buffer to fix the connection issues.
> 
> Fixes: Commit 46949b48568b ("staging: wilc1000: New cfg packet format in 
> handle_set_wfi_drv_handler")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Aditya Shankar 
> ---
>  drivers/staging/wilc1000/wilc_wlan.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
> b/drivers/staging/wilc1000/wilc_wlan.c
> index 9addef1..f49dfa8 100644
> --- a/drivers/staging/wilc1000/wilc_wlan.c
> +++ b/drivers/staging/wilc1000/wilc_wlan.c
> @@ -714,7 +714,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 
> *txq_count)
>   char *bssid = ((struct tx_complete_data 
> *)(tqe->priv))->bssid;
>  
>   buffer_offset = ETH_ETHERNET_HDR_OFFSET;
> - memcpy([offset + 4], bssid, 6);
> + memcpy([offset + 8], bssid, 6);
>   } else {
>   buffer_offset = HOST_HDR_OFFSET;
>   }
>

Re: Need support for Intel new wifi module 9462NGW

2017-11-16 Thread Luca Coelho 
Hi Chris,

On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
> Hi Luca,
> Any suggestion for the "Failed to start INIT ucode: -110" issue
> for the firmware?

There were a few problems which should now be fixed.  We published new
firmwares in our linux-firmware.git tree[1] and also made some fixes in
the driver[2].  Please update your system accordingly and let me know
if it works for you.

Thanks!

[1] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/
[2] https://patchwork.kernel.org/patch/10059871/
https://patchwork.kernel.org/patch/10059875/
https://patchwork.kernel.org/patch/10059873/

--
Cheers,
Luca.

[PATCH v2 3/3] iwlwifi: fix firmware names for 9000 and A000 series hw

2017-11-16 Thread Luca Coelho 
From: Thomas Backlund 

iwlwifi 9000 and a series hw contains an extra dash in firmware
file name as seeen in modinfo output for kernel 4.14:

firmware:   iwlwifi-9260-th-b0-jf-b0--34.ucode
firmware:   iwlwifi-9260-th-a0-jf-a0--34.ucode
firmware:   iwlwifi-9000-pu-a0-jf-b0--34.ucode
firmware:   iwlwifi-9000-pu-a0-jf-a0--34.ucode
firmware:   iwlwifi-QuQnj-a0-hr-a0--34.ucode
firmware:   iwlwifi-QuQnj-a0-jf-b0--34.ucode
firmware:   iwlwifi-QuQnj-f0-hr-a0--34.ucode
firmware:   iwlwifi-Qu-a0-jf-b0--34.ucode
firmware:   iwlwifi-Qu-a0-hr-a0--34.ucode

Fix that by dropping the extra adding of '"-"'.

Signed-off-by: Thomas Backlund 
Cc: sta...@vger.kernel.org # 4.13
Signed-off-by: Luca Coelho 
---

In v2:

   * fix rebasing damage;

drivers/net/wireless/intel/iwlwifi/cfg/9000.c |  6 +++---
 drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 10 +-
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/cfg/9000.c 
b/drivers/net/wireless/intel/iwlwifi/cfg/9000.c
index b6990400042f..e7e75b458005 100644
--- a/drivers/net/wireless/intel/iwlwifi/cfg/9000.c
+++ b/drivers/net/wireless/intel/iwlwifi/cfg/9000.c
@@ -82,11 +82,11 @@
 #define IWL9000B_MODULE_FIRMWARE(api) \
IWL9000B_FW_PRE __stringify(api) ".ucode"
 #define IWL9000RFB_MODULE_FIRMWARE(api) \
-   IWL9000RFB_FW_PRE "-" __stringify(api) ".ucode"
+   IWL9000RFB_FW_PRE __stringify(api) ".ucode"
 #define IWL9260A_MODULE_FIRMWARE(api) \
-   IWL9260A_FW_PRE "-" __stringify(api) ".ucode"
+   IWL9260A_FW_PRE __stringify(api) ".ucode"
 #define IWL9260B_MODULE_FIRMWARE(api) \
-   IWL9260B_FW_PRE "-" __stringify(api) ".ucode"
+   IWL9260B_FW_PRE __stringify(api) ".ucode"
 
 #define NVM_HW_SECTION_NUM_FAMILY_9000 10
 
diff --git a/drivers/net/wireless/intel/iwlwifi/cfg/a000.c 
b/drivers/net/wireless/intel/iwlwifi/cfg/a000.c
index ea8206515171..705f83b02e13 100644
--- a/drivers/net/wireless/intel/iwlwifi/cfg/a000.c
+++ b/drivers/net/wireless/intel/iwlwifi/cfg/a000.c
@@ -80,15 +80,15 @@
 #define IWL_A000_HR_A0_FW_PRE  "iwlwifi-QuQnj-a0-hr-a0-"
 
 #define IWL_A000_HR_MODULE_FIRMWARE(api) \
-   IWL_A000_HR_FW_PRE "-" __stringify(api) ".ucode"
+   IWL_A000_HR_FW_PRE __stringify(api) ".ucode"
 #define IWL_A000_JF_MODULE_FIRMWARE(api) \
-   IWL_A000_JF_FW_PRE "-" __stringify(api) ".ucode"
+   IWL_A000_JF_FW_PRE __stringify(api) ".ucode"
 #define IWL_A000_HR_F0_QNJ_MODULE_FIRMWARE(api) \
-   IWL_A000_HR_F0_FW_PRE "-" __stringify(api) ".ucode"
+   IWL_A000_HR_F0_FW_PRE __stringify(api) ".ucode"
 #define IWL_A000_JF_B0_QNJ_MODULE_FIRMWARE(api) \
-   IWL_A000_JF_B0_FW_PRE "-" __stringify(api) ".ucode"
+   IWL_A000_JF_B0_FW_PRE __stringify(api) ".ucode"
 #define IWL_A000_HR_A0_QNJ_MODULE_FIRMWARE(api) \
-   IWL_A000_HR_A0_FW_PRE "-" __stringify(api) ".ucode"
+   IWL_A000_HR_A0_FW_PRE __stringify(api) ".ucode"
 
 #define NVM_HW_SECTION_NUM_FAMILY_A000 10
 
-- 
2.15.0

[PATCH v2 2/3] iwlwifi: fix PCI IDs and configuration mapping for 9000 series

2017-11-16 Thread Luca Coelho 
From: Luca Coelho 

A lot of PCI IDs were missing and there were some problems with the
configuration and firmware selection for devices on the 9000 series.
Fix the firmware selection by adding files for the B-steps; add
configuration for some integrated devices; and add a bunch of PCI IDs
(mostly for integrated devices) that were missing from the driver's
list.

Without this patch, a lot of devices will not be recognized or will
try to load the wrong firmware file.

Cc: sta...@vger.kernel.org # 4.13
Signed-off-by: Luca Coelho 
---

In v2:
  * include the changes to iwl-config.h that were missing.


drivers/net/wireless/intel/iwlwifi/cfg/9000.c   |  67 +++-
 drivers/net/wireless/intel/iwlwifi/iwl-config.h |   5 +
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c   | 132 ++--
 3 files changed, 170 insertions(+), 34 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/cfg/9000.c 
b/drivers/net/wireless/intel/iwlwifi/cfg/9000.c
index af7c4f36b66f..b6990400042f 100644
--- a/drivers/net/wireless/intel/iwlwifi/cfg/9000.c
+++ b/drivers/net/wireless/intel/iwlwifi/cfg/9000.c
@@ -72,12 +72,15 @@
 #define IWL9000_SMEM_OFFSET0x40
 #define IWL9000_SMEM_LEN   0x68000
 
-#define  IWL9000_FW_PRE "iwlwifi-9000-pu-a0-jf-a0-"
+#define  IWL9000A_FW_PRE "iwlwifi-9000-pu-a0-jf-a0-"
+#define  IWL9000B_FW_PRE "iwlwifi-9000-pu-b0-jf-b0-"
 #define  IWL9000RFB_FW_PRE "iwlwifi-9000-pu-a0-jf-b0-"
 #define  IWL9260A_FW_PRE "iwlwifi-9260-th-a0-jf-a0-"
 #define  IWL9260B_FW_PRE "iwlwifi-9260-th-b0-jf-b0-"
-#define IWL9000_MODULE_FIRMWARE(api) \
-   IWL9000_FW_PRE "-" __stringify(api) ".ucode"
+#define IWL9000A_MODULE_FIRMWARE(api) \
+   IWL9000A_FW_PRE __stringify(api) ".ucode"
+#define IWL9000B_MODULE_FIRMWARE(api) \
+   IWL9000B_FW_PRE __stringify(api) ".ucode"
 #define IWL9000RFB_MODULE_FIRMWARE(api) \
IWL9000RFB_FW_PRE "-" __stringify(api) ".ucode"
 #define IWL9260A_MODULE_FIRMWARE(api) \
@@ -194,7 +197,48 @@ const struct iwl_cfg iwl9460_2ac_cfg = {
.nvm_ver = IWL9000_NVM_VERSION,
.nvm_calib_ver = IWL9000_TX_POWER_VERSION,
.max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K,
+};
+
+const struct iwl_cfg iwl9460_2ac_cfg_soc = {
+   .name = "Intel(R) Dual Band Wireless AC 9460",
+   .fw_name_pre = IWL9000A_FW_PRE,
+   .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE,
+   .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE,
+   IWL_DEVICE_9000,
+   .ht_params = _ht_params,
+   .nvm_ver = IWL9000_NVM_VERSION,
+   .nvm_calib_ver = IWL9000_TX_POWER_VERSION,
+   .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K,
.integrated = true,
+   .soc_latency = 5000,
+};
+
+const struct iwl_cfg iwl9461_2ac_cfg_soc = {
+   .name = "Intel(R) Dual Band Wireless AC 9461",
+   .fw_name_pre = IWL9000A_FW_PRE,
+   .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE,
+   .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE,
+   IWL_DEVICE_9000,
+   .ht_params = _ht_params,
+   .nvm_ver = IWL9000_NVM_VERSION,
+   .nvm_calib_ver = IWL9000_TX_POWER_VERSION,
+   .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K,
+   .integrated = true,
+   .soc_latency = 5000,
+};
+
+const struct iwl_cfg iwl9462_2ac_cfg_soc = {
+   .name = "Intel(R) Dual Band Wireless AC 9462",
+   .fw_name_pre = IWL9000A_FW_PRE,
+   .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE,
+   .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE,
+   IWL_DEVICE_9000,
+   .ht_params = _ht_params,
+   .nvm_ver = IWL9000_NVM_VERSION,
+   .nvm_calib_ver = IWL9000_TX_POWER_VERSION,
+   .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K,
+   .integrated = true,
+   .soc_latency = 5000,
 };
 
 const struct iwl_cfg iwl9560_2ac_cfg = {
@@ -206,10 +250,23 @@ const struct iwl_cfg iwl9560_2ac_cfg = {
.nvm_ver = IWL9000_NVM_VERSION,
.nvm_calib_ver = IWL9000_TX_POWER_VERSION,
.max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K,
-   .integrated = true,
 };
 
-MODULE_FIRMWARE(IWL9000_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX));
+const struct iwl_cfg iwl9560_2ac_cfg_soc = {
+   .name = "Intel(R) Dual Band Wireless AC 9560",
+   .fw_name_pre = IWL9000A_FW_PRE,
+   .fw_name_pre_b_or_c_step = IWL9000B_FW_PRE,
+   .fw_name_pre_rf_next_step = IWL9000RFB_FW_PRE,
+   IWL_DEVICE_9000,
+   .ht_params = _ht_params,
+   .nvm_ver = IWL9000_NVM_VERSION,
+   .nvm_calib_ver = IWL9000_TX_POWER_VERSION,
+   .max_ht_ampdu_exponent = IEEE80211_HT_MAX_AMPDU_64K,
+   .integrated = true,
+   .soc_latency = 5000,
+};
+MODULE_FIRMWARE(IWL9000A_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX));
+MODULE_FIRMWARE(IWL9000B_MODULE_FIRMWARE(IWL9000_UCODE_API_MAX));

[PATCH v4] wcn36xx: Set default BTLE coexistence config

2017-11-16 Thread Ramon Fried 
From: Eyal Ilsar 

If the value for the firmware configuration parameters
BTC_STATIC_LEN_LE_BT and BTC_STATIC_LEN_LE_WLAN are not set the duty
cycle between BT and WLAN is such that if BT (including BLE) is active
WLAN gets 0 bandwidth. When tuning these parameters having a too high
value for WLAN means that BLE performance degrades.
The "sweet" point of roughly half of the maximal values was empirically
found to achieve a balance between BLE and Wi-Fi coexistence
performance.

Signed-off-by: Eyal Ilsar 
Signed-off-by: Ramon Fried 
---
 drivers/net/wireless/ath/wcn36xx/smd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 9c6590d5348a..6f1e741acf3e 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -73,6 +73,8 @@ static struct wcn36xx_cfg_val wcn36xx_cfg_vals[] = {
WCN36XX_CFG_VAL(TX_PWR_CTRL_ENABLE, 1),
WCN36XX_CFG_VAL(ENABLE_CLOSE_LOOP, 1),
WCN36XX_CFG_VAL(ENABLE_LPWR_IMG_TRANSITION, 0),
+   WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_BT, 12),
+   WCN36XX_CFG_VAL(BTC_STATIC_LEN_LE_WLAN, 3),
WCN36XX_CFG_VAL(MAX_ASSOC_LIMIT, 10),
WCN36XX_CFG_VAL(ENABLE_MCC_ADAPTIVE_SCHEDULER, 0),
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

2017-11-16 Thread Weixiao Zhang 
Add non-DFS 5G upper channels (149-165) besides existed 4 lower channels
(36, 40, 44, 48).
{ .band = NL80211_BAND_5GHZ, .center_freq = 5745, .hw_value = 149, },
{ .band = NL80211_BAND_5GHZ, .center_freq = 5765, .hw_value = 153, },
{ .band = NL80211_BAND_5GHZ, .center_freq = 5785, .hw_value = 157, },
{ .band = NL80211_BAND_5GHZ, .center_freq = 5805, .hw_value = 161, },
{ .band = NL80211_BAND_5GHZ, .center_freq = 5825, .hw_value = 165, },

Signed-off-by: Weixiao Zhang 
---
 drivers/net/wireless/marvell/mwl8k.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwl8k.c 
b/drivers/net/wireless/marvell/mwl8k.c
index e813b2ca740c..8e4e9b6919e0 100644
--- a/drivers/net/wireless/marvell/mwl8k.c
+++ b/drivers/net/wireless/marvell/mwl8k.c
@@ -199,7 +199,7 @@ struct mwl8k_priv {
struct ieee80211_channel channels_24[14];
struct ieee80211_rate rates_24[13];
struct ieee80211_supported_band band_50;
-   struct ieee80211_channel channels_50[4];
+   struct ieee80211_channel channels_50[9];
struct ieee80211_rate rates_50[8];
u32 ap_macids_supported;
u32 sta_macids_supported;
@@ -383,6 +383,11 @@ static const struct ieee80211_channel mwl8k_channels_50[] 
= {
{ .band = NL80211_BAND_5GHZ, .center_freq = 5200, .hw_value = 40, },
{ .band = NL80211_BAND_5GHZ, .center_freq = 5220, .hw_value = 44, },
{ .band = NL80211_BAND_5GHZ, .center_freq = 5240, .hw_value = 48, },
+   { .band = NL80211_BAND_5GHZ, .center_freq = 5745, .hw_value = 149, },
+   { .band = NL80211_BAND_5GHZ, .center_freq = 5765, .hw_value = 153, },
+   { .band = NL80211_BAND_5GHZ, .center_freq = 5785, .hw_value = 157, },
+   { .band = NL80211_BAND_5GHZ, .center_freq = 5805, .hw_value = 161, },
+   { .band = NL80211_BAND_5GHZ, .center_freq = 5825, .hw_value = 165, },
 };
 
 static const struct ieee80211_rate mwl8k_rates_50[] = {
-- 
2.11.0