Re: ath10k: Fix soft lockup during firmware crash/hw-restart

[Mohammed Shafi Shajakhan]

On Tue, Nov 29, 2016 at 04:43:48PM -0800, Ben Greear wrote:
> I have not seen this hang since adding this patch, so
> hopefully it has resolved the problem.

thanks Ben ! I had updated the commit log with Fixes tag
https://patchwork.kernel.org/patch/9453609/

> 
> On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:
> >From: Mohammed Shafi Shajakhan 
> >
> >During firmware crash (or) user requested manual restart
> >the system gets into a soft lock up state because of the
> >below root cause.
> >
> >During user requested hardware restart / firmware crash
> >the system goes into a soft lockup state as 'napi_synchronize'
> >is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
> >bit) and it sleeps into infinite loop as it waits for
> >'NAPI_STATE_SCHED' to be cleared. This condition is hit because
> >'ath10k_hif_stop' is called twice as below (resulting in calling
> >'napi_synchronize' after 'napi_disable')
> >
> >'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
> >-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
> >'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)
> >
> >Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
> >as it makes more sense before informing mac80211 to restart h/w
> >Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'
> >
> >Signed-off-by: Mohammed Shafi Shajakhan 
> >---
> >[thanks to Kalle and Michal for their inputs]
> >
> > drivers/net/wireless/ath/ath10k/core.c | 2 +-
> > drivers/net/wireless/ath/ath10k/mac.c  | 1 -
> > 2 files changed, 1 insertion(+), 2 deletions(-)
> >
> >diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> >b/drivers/net/wireless/ath/ath10k/core.c
> >index 7005e2a..5bc6847 100644
> >--- a/drivers/net/wireless/ath/ath10k/core.c
> >+++ b/drivers/net/wireless/ath/ath10k/core.c
> >@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct 
> >*work)
> > switch (ar->state) {
> > case ATH10K_STATE_ON:
> > ar->state = ATH10K_STATE_RESTARTING;
> >-ath10k_hif_stop(ar);
> >+ath10k_halt(ar);
> > ath10k_scan_finish(ar);
> > ieee80211_restart_hw(ar->hw);
> > break;
> >diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
> >b/drivers/net/wireless/ath/ath10k/mac.c
> >index 717b2fa..481842b 100644
> >--- a/drivers/net/wireless/ath/ath10k/mac.c
> >+++ b/drivers/net/wireless/ath/ath10k/mac.c
> >@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
> > ar->state = ATH10K_STATE_ON;
> > break;
> > case ATH10K_STATE_RESTARTING:
> >-ath10k_halt(ar);
> > ar->state = ATH10K_STATE_RESTARTED;
> > break;
> > case ATH10K_STATE_ON:
> >
> 
> 
> -- 
> Ben Greear 
> Candela Technologies Inc  http://www.candelatech.com
> 

[PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.

During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')

'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)

Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'

Fixes: 3c97f5de1f28 ("ath10k: implement NAPI support")
Signed-off-by: Mohammed Shafi Shajakhan 
---
[v2 Added Fixes ]

 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 7005e2a..5bc6847 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct *work)
switch (ar->state) {
case ATH10K_STATE_ON:
ar->state = ATH10K_STATE_RESTARTING;
-   ath10k_hif_stop(ar);
+   ath10k_halt(ar);
ath10k_scan_finish(ar);
ieee80211_restart_hw(ar->hw);
break;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 717b2fa..481842b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
ar->state = ATH10K_STATE_ON;
break;
case ATH10K_STATE_RESTARTING:
-   ath10k_halt(ar);
ar->state = ATH10K_STATE_RESTARTED;
break;
case ATH10K_STATE_ON:
-- 
1.9.1

Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
 wrote:
> Hello Matt,
>
> On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
>  wrote:
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren 
>> Cc: Ulf Hansson 
>> Cc: Mark Rutland 
>> Cc: Srinivas Kandagatla 
>> Signed-off-by: Matt Ranostay 
>> ---
>>  .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
>>  .../bindings/net/wireless/marvell-sd8xxx.txt   |   4 +
>>  drivers/mmc/core/Kconfig   |  10 ++
>>  drivers/mmc/core/Makefile  |   1 +
>>  drivers/mmc/core/pwrseq_sd8787.c   | 117 
>> +
>>  5 files changed, 146 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>>  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
>> b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>
> According Documentation/devicetree/bindings/submitting-patches.txt,
> the DT bindings patches should posted as a separate patch.

Ok will do.

>
>> new file mode 100644
>> index ..1b658351629b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> @@ -0,0 +1,14 @@
>> +* Marvell SD8787 power sequence provider
>> +
>> +Required properties:
>> +- compatible: must be "mmc-pwrseq-sd8787".
>
> Since this is not a generic binding, the compatible string should have
> a vendor prefix.
>

Makes sense to me.


>> +- pwndn-gpio: contains a power down GPIO specifier.
>> +- reset-gpio: contains a reset GPIO specifier.
>> +
>
> I wonder if we really need a custom power sequence provider for just
> this SDIO WiFI chip though. AFAICT the only missing piece in
> mmc-pwrseq-simple is the power down GPIO property, so maybe
> mmc-pwrseq-simple could be extended instead to have an optional
> powerdown-gpios property and instead in the Marvell SD8787 DT binding
> can be mentioned which mmc-pwrseq-simple properties are required for
> the device.
>

The reason we didn't do that is we need delay between the two
assertions/desertions of GPIOs. It wouldn't seems good practice to
hack the pwrseq-simple for this...

>> +Example:
>> +
>> +   wifi_pwrseq: wifi_pwrseq {
>> +   compatible = "mmc-pwrseq-sd8787";
>> +   pwrdn-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
>> +   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
>> +   }
>> diff --git 
>> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt 
>> b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>
> Does this patch depend on a previous posted series? I don't see this
> file in today's linux-next...

Got renamed to ->
Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt it
seems very recently.

>
>> index c421aba0a5bc..08fd65d35725 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> @@ -32,6 +32,9 @@ Optional properties:
>>  so that the wifi chip can wakeup host platform under 
>> certain condition.
>>  during system resume, the irq will be disabled to make sure
>>  unnecessary interrupt is not received.
>> +  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>> +  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
>> +for documentation of MMC power sequence bindings.
>>
>>  Example:
>>
>> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side 
>> pin.
>>   {
>> status = "okay";
>> vmmc-supply = <_en_reg>;
>> +   mmc-pwrseq = <_pwrseq>;
>> bus-width = <4>;
>> cap-power-off-card;
>> keep-power-in-suspend;
>
> I think this change should be split in a separate patch as well.
>
> Best regards,
> Javier

Re: ath10k: Fix soft lockup during firmware crash/hw-restart

[Ben Greear]

I have not seen this hang since adding this patch, so
hopefully it has resolved the problem.

Thanks,
Ben

On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:

From: Mohammed Shafi Shajakhan 

During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.

During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')

'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)

Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'

Signed-off-by: Mohammed Shafi Shajakhan 
---
[thanks to Kalle and Michal for their inputs]

 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 7005e2a..5bc6847 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct *work)
switch (ar->state) {
case ATH10K_STATE_ON:
ar->state = ATH10K_STATE_RESTARTING;
-   ath10k_hif_stop(ar);
+   ath10k_halt(ar);
ath10k_scan_finish(ar);
ieee80211_restart_hw(ar->hw);
break;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 717b2fa..481842b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
ar->state = ATH10K_STATE_ON;
break;
case ATH10K_STATE_RESTARTING:
-   ath10k_halt(ar);
ar->state = ATH10K_STATE_RESTARTED;
break;
case ATH10K_STATE_ON:




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

[PATCH] mac80211: Suppress NEW_PEER_CANDIDATE event if no room

[Masashi Honma]

Previously, kernel sends NEW_PEER_CANDIDATE event to user land even if
the found peer does not have any room to accept other peer. This causes
continuous connection trials.

Signed-off-by: Masashi Honma 
---
 net/mac80211/mesh_plink.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 7fcdcf6..fcba70e5 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -505,12 +505,14 @@ mesh_sta_info_alloc(struct ieee80211_sub_if_data *sdata, 
u8 *addr,
 
/* Userspace handles station allocation */
if (sdata->u.mesh.user_mpm ||
-   sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED)
-   cfg80211_notify_new_peer_candidate(sdata->dev, addr,
-  elems->ie_start,
-  elems->total_len,
-  GFP_KERNEL);
-   else
+   sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED) {
+   if (mesh_peer_accepts_plinks(elems) &&
+   mesh_plink_availables(sdata))
+   cfg80211_notify_new_peer_candidate(sdata->dev, addr,
+  elems->ie_start,
+  elems->total_len,
+  GFP_KERNEL);
+   } else
sta = __mesh_sta_info_alloc(sdata, addr);
 
return sta;
-- 
2.7.4

[PATCH 1/1] rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting

[Jes . Sorensen]

From: Jes Sorensen 

The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and
8723bu devices not being able to reconnect.

Reported-by: Barry Day 
Signed-off-by: Jes Sorensen 
---
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index a9137ab..3a86675 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4372,6 +4372,13 @@ void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv 
*priv,
 void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
  u8 macid, bool connect)
 {
+#ifdef RTL8XXXU_GEN2_REPORT_CONNECT
+   /*
+* Barry Day reports this causes issues with 8192eu and 8723bu
+* devices reconnecting. The reason for this is unclear, but
+* until it is better understood, leave the code in place but
+* disabled, so it is not lost.
+*/
struct h2c_cmd h2c;
 
memset(, 0, sizeof(struct h2c_cmd));
@@ -4383,6 +4390,7 @@ void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv 
*priv,
h2c.media_status_rpt.parm &= ~BIT(0);
 
rtl8xxxu_gen2_h2c_cmd(priv, , sizeof(h2c.media_status_rpt));
+#endif
 }
 
 void rtl8xxxu_gen1_init_aggregation(struct rtl8xxxu_priv *priv)
-- 
2.7.4

Donation

[Lopez Omar]

Hello, My name is Gloria C. Mackenzie, i have a Monetary Donation to make for 
less privilege and yourself and your organization, am writing you with a 
friend's email, please contact me on g_macken...@rogers.com

ath10k firmware crashes in mesh mode on QCA9880

[Benjamin Morgan]

When we try to transmit traffic (ping) between two meshed ath10k devices 
running latest lede we keep experiencing ath10k firmware crashes. This 
seems to only happen when running in 802.11n/ac mode but not in 
802.11a/g mode. Also, from the station dumps it appears that management 
traffic is flowing between the devices, however when we try to send 
unicast data traffic the firmware crashes immediately.


Platform: Archer C7 AC1750 v2
Software Image: LEDE (HEAD, r2299) Commit: 
https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58


Crypto: wpa_supplicant
wpa_supplicant-wlan0.conf
network={
ssid="bmorgan_lede_mesh"
key_mgmt=SAE
mode=5
frequency=5180
psk="meshpassword"
}

Backports Verstion:
[9.818007] Loading modules backported from Linux version 
wt-2016-10-03-1-g6fcb1a6
[9.825736] Backport generated by backports.git 
backports-20160324-9-g0e38f5c


​​Ath10k Initialization on Station A (dmesg)
[9.896715] PCI: Enabling device :01:00.0 ( -> 0002)
[9.902622] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode 1 
irq_mode 0 reset_mode 0
[   10.123734] ath10k_pci :01:00.0: Direct firmware load for 
ath10k/pre-cal-pci-:01:00.0.bin failed with error -2

[   10.134620] ath10k_pci :01:00.0: Falling back to user helper
[   10.287680] firmware ath10k!pre-cal-pci-:01:00.0.bin: 
firmware_loading_store: map pages failed
[   10.622789] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub :
[   10.632184] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1 
tracing 0 dfs 1 testmode 1
[   10.645231] ath10k_pci :01:00.0: firmware ver 10.2.4.70.54 api 5 
features no-p2p,raw-mode,mfp crc32 9d340dd9
[   10.655660] ath10k_pci :01:00.0: Direct firmware load for 
ath10k/QCA988X/hw2.0/board-2.bin failed with error -2

[   10.666264] ath10k_pci :01:00.0: Falling back to user helper
[   10.747925] firmware ath10k!QCA988X!hw2.0!board-2.bin: 
firmware_loading_store: map pages failed
[   11.011123] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[   12.155224] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1


Station A (wlan0):
18:A6:F7:23:6E:66
10.230.5.41

Station B (wlan0):
18:a6:f7:26:0f:21
10.230.5.42

Station Dump on Station A before ping:
Station 18:a6:f7:26:0f:21 (on wlan0)
inactive time:340 ms
rx bytes:2472
rx packets:28
tx bytes:1204
tx packets:9
tx retries:0
tx failed:0
rx drop misc:1
signal: -14 dBm
signal avg:-14 dBm
Toffset:18142530 us
tx bitrate:6.0 MBit/s
rx bitrate:6.0 MBit/s
rx duration:1524 us
mesh llid:0
mesh plid:0
mesh plink:ESTAB
mesh local PS mode:ACTIVE
mesh peer PS mode:UNKNOWN
mesh non-peer PS mode:ACTIVE
authorized:yes
authenticated:yes
associated:yes
preamble:long
WMM/WME:yes
MFP:yes
TDLS peer:no
DTIM period:2
beacon interval:1000
connected time:10 seconds

​Crash Log on Station B (10.230.5.42)
[245.483888] ath10k_pci :01:00.0: firmware crashed! (uuid 
2bab5ee9-08ff-4a17-95b1-636d212acebc)
[245.493020] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043202ff sub :
[245.502384] ath10k_pci :01:00.0: kconfig debug 0 debugfs 1 tracing 
0 dfs 1 testmode 1
[245.515436] ath10k_pci :01:00.0: firmware ver 10.2.4.70.54 api 5 
features no-p2p,raw-mode,mfp crc32 9d340dd9
[245.525812] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A crc32 
bebc7c08
[245.533232] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal 
file max-sta 128 raw 0 hwcrypto 1

[245.544876] ath10k_pci :01:00.0: firmware register dump:
[245.550633] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 
0x009A4577 0x00955B31
[245.558676] ath10k_pci :01:00.0: [04]: 0x009A4577 0x00060130 
0x0002 0x00439E98
[245.566715] ath10k_pci :01:00.0: [08]: 0x0044110C 0x00442074 
0x00407120 0x004436CC
[245.574749] ath10k_pci :01:00.0: [12]: 0x0009 0x 
0x009A3518 0x009A3526
[245.582793] ath10k_pci :01:00.0: [16]: 0x00958080 0x0094085D 
0x 0x
[245.590836] ath10k_pci :01:00.0: [20]: 0x409A4577 0x0040AAC4 
0x0040AC60 0x0040AC09
[245.598882] ath10k_pci :01:00.0: [24]: 0x809A44BA 0x0040AB24 
0x0040 0xC09A4577
[245.606923] ath10k_pci :01:00.0: [28]: 0x809A39DE 0x0040AB84 
0x0044110C 0x00442074
[245.614955] ath10k_pci :01:00.0: [32]: 0x809A5FE2 0x0040ABB4 
0x0044110C 0x00407120
[245.623000] ath10k_pci :01:00.0: [36]: 0x809A2E6C 0x0040ABF4 
0x0040AC14 0x1580
[245.631043] ath10k_pci :01:00.0: [40]: 0x80990F6F 0x0040AD04 
0x009C643C 0x004436CC
[245.639086] ath10k_pci :01:00.0: [44]: 0x80998510 0x0040AD64 
0x004208FC 0x00439E4C
[245.647129] ath10k_pci :01:00.0: [48]: 0x8099AE95 0x0040AD84 
0x004208FC 0x00425404
[245.655170] ath10k_pci :01:00.0: [52]: 0x809BFC55 0x0040AEE4 
0x00424FE8 0x0002
[245.663198] ath10k_pci :01:00.0: [56]: 0x80940F18 0x0040AF14 
0x0004 0x004039D0

[245.767023] ieee80211 phy0: Hardware restart was requested

Re: ath10k: Fix soft lockup during firmware crash/hw-restart

[Ben Greear]

Is this something for stable?  And if so, how far back should it be applied?

I'll add this patch to my 4.9 tree and test it...

Thanks,
Ben

On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:

From: Mohammed Shafi Shajakhan 

During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.

During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')

'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)

Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'

Signed-off-by: Mohammed Shafi Shajakhan 
---
[thanks to Kalle and Michal for their inputs]

 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 7005e2a..5bc6847 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct *work)
switch (ar->state) {
case ATH10K_STATE_ON:
ar->state = ATH10K_STATE_RESTARTING;
-   ath10k_hif_stop(ar);
+   ath10k_halt(ar);
ath10k_scan_finish(ar);
ieee80211_restart_hw(ar->hw);
break;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 717b2fa..481842b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
ar->state = ATH10K_STATE_ON;
break;
case ATH10K_STATE_RESTARTING:
-   ath10k_halt(ar);
ar->state = ATH10K_STATE_RESTARTED;
break;
case ATH10K_STATE_ON:




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

[PATCH] mac80211: Return avg sig, rx, tx values in ethtool stats.

[greearb]

From: Ben Greear 

For non-station devices.  This gives at least some useful
summary in some cases (especially when we know AP has only one
station attached, for instance).

Signed-off-by: Ben Greear 
---

This is against 4.7.10+, applied to 4.4 and 4.9 for me as well.

 net/mac80211/ethtool.c | 56 ++
 1 file changed, 56 insertions(+)

diff --git a/net/mac80211/ethtool.c b/net/mac80211/ethtool.c
index 4e937c1..dc6f76f 100644
--- a/net/mac80211/ethtool.c
+++ b/net/mac80211/ethtool.c
@@ -12,6 +12,25 @@
 #include "ieee80211_i.h"
 #include "sta_info.h"
 #include "driver-ops.h"
+#include 
+
+static inline __s64 mac_div(__s64 n, __u32 base)
+{
+   if (n < 0) {
+   __u64 tmp = -n;
+   do_div(tmp, base);
+   /* printk("pktgen: pg_div, n: %llu  base: %d  rv: %llu\n",
+  n, base, tmp); */
+   return -tmp;
+   }
+   else {
+   __u64 tmp = n;
+   do_div(tmp, base);
+   /* printk("pktgen: pg_div, n: %llu  base: %d  rv: %llu\n",
+  n, base, tmp); */
+   return tmp;
+   }
+}
 
 static int ieee80211_set_ringparam(struct net_device *dev,
   struct ethtool_ringparam *rp)
@@ -128,6 +147,12 @@ static void ieee80211_get_stats(struct net_device *dev,
data[i] = (u8)sinfo.signal_avg;
i++;
} else {
+   int amt_tx = 0;
+   int amt_rx = 0;
+   int amt_sig = 0;
+   s64 tx_accum = 0;
+   s64 rx_accum = 0;
+   s64 sig_accum = 0;
list_for_each_entry(sta, >sta_list, list) {
/* Make sure this station belongs to the proper dev */
if (sta->sdata->dev != dev)
@@ -137,6 +162,37 @@ static void ieee80211_get_stats(struct net_device *dev,
sta_set_sinfo(sta, );
i = 0;
ADD_STA_STATS(sta);
+
+   i++; /* skip sta state */
+
+   if (sinfo.filled & BIT(NL80211_STA_INFO_TX_BITRATE)) {
+   tx_accum += 10 *
+   
cfg80211_calculate_bitrate();
+   amt_tx++;
+   data[i] = mac_div(tx_accum, amt_tx);
+   }
+   i++;
+
+   if (sinfo.filled & BIT(NL80211_STA_INFO_RX_BITRATE)) {
+   rx_accum += 10 *
+   
cfg80211_calculate_bitrate();
+   amt_rx++;
+   data[i] = mac_div(rx_accum, amt_rx);
+   }
+   i++;
+
+   if (sinfo.filled & BIT(NL80211_STA_INFO_SIGNAL_AVG)) {
+   sig_accum += sinfo.signal_avg;
+   amt_sig++;
+   data[i] = (mac_div(sig_accum, amt_sig) & 0xFF);
+   }
+   i++;
+
+   /*pr_err("sta: %p (%s) sig_accum: %ld  amt-sig: %d 
filled: 0x%x:%08x rpt-sig-avg: %d  i: %d  div: %d sinfo.signal_avg: %d\n",
+  sta, sta->sdata->name, (long)(sig_accum), 
amt_sig, (u32)(sinfo.filled >> 32),
+  (u32)(sinfo.filled), (u32)(data[i-1]), i-1, 
(u32)(mac_div(sig_accum, amt_sig)),
+  sinfo.signal_avg);*/
+
}
}
 
-- 
2.4.11

[PATCH 1/2] mac80211: Show pending txqlen in debugfs.

[greearb]

From: Ben Greear 

Could be useful for debugging memory consumption issues,
and perhaps power-save as well.

Signed-off-by: Ben Greear 
---

This is against 4.7.10+

 net/mac80211/debugfs.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index b251b2f7..0b49b43 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -162,6 +162,30 @@ static ssize_t hwflags_read(struct file *file, char __user 
*user_buf,
return rv;
 }
 
+static ssize_t misc_read(struct file *file, char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct ieee80211_local *local = file->private_data;
+   size_t bufsz = 1000;
+   char *buf = kzalloc(bufsz, GFP_KERNEL);
+   char *pos = buf, *end = buf + bufsz - 1;
+   ssize_t rv;
+   int i;
+   int ln;
+
+   pos += scnprintf(pos, end - pos, "pending:\n");
+
+   for (i = 0; i < IEEE80211_MAX_QUEUES; i++) {
+   ln = skb_queue_len(>pending[i]);
+   pos += scnprintf(pos, end - pos, "[%i] %d\n",
+i, ln);
+   }
+
+   rv = simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf));
+   kfree(buf);
+   return rv;
+}
+
 static ssize_t queues_read(struct file *file, char __user *user_buf,
   size_t count, loff_t *ppos)
 {
@@ -182,6 +206,7 @@ static ssize_t queues_read(struct file *file, char __user 
*user_buf,
 
 DEBUGFS_READONLY_FILE_OPS(hwflags);
 DEBUGFS_READONLY_FILE_OPS(queues);
+DEBUGFS_READONLY_FILE_OPS(misc);
 
 /* statistics stuff */
 
@@ -250,6 +275,7 @@ void debugfs_hw_add(struct ieee80211_local *local)
DEBUGFS_ADD(total_ps_buffered);
DEBUGFS_ADD(wep_iv);
DEBUGFS_ADD(queues);
+   DEBUGFS_ADD(misc);
 #ifdef CONFIG_PM
DEBUGFS_ADD_MODE(reset, 0200);
 #endif
-- 
2.4.11

[PATCH 2/2] mac80211: put upper bound on txqi queue length.

[greearb]

From: Ben Greear 

This fixes OOM when using pktgen to drive a wifi station at more than
the station can transmit.  pktgen uses ndo_start_xmit instead of going
through the queue layer, so it will not back off when the queues are
stopped, and would thus cause packets to be added to the txqi->queue
until the system goes OOM and crashes.

Signed-off-by: Ben Greear 
---

This is against 4.7.10+, not sure if it is actually needed in latest kernel.

 net/mac80211/tx.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index fbcb5fc..0573ab9 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1293,6 +1293,16 @@ static void ieee80211_drv_tx(struct ieee80211_local 
*local,
goto tx_normal;
 
ac = txq->ac;
+
+   if (atomic_read(>txqs_len[ac]) >=
+   (local->hw.txq_ac_max_pending * 2)) {
+   /* Must be that something is not paying attention to
+* max-pending, like pktgen, so just drop this frame.
+*/
+   ieee80211_free_txskb(>hw, skb);
+   return;
+   }
+
txqi = to_txq_info(txq);
atomic_inc(>txqs_len[ac]);
if (atomic_read(>txqs_len[ac]) >= local->hw.txq_ac_max_pending)
-- 
2.4.11

Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip

[Javier Martinez Canillas]

Hello Matt,

On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
 wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
>
> Cc: Tony Lindgren 
> Cc: Ulf Hansson 
> Cc: Mark Rutland 
> Cc: Srinivas Kandagatla 
> Signed-off-by: Matt Ranostay 
> ---
>  .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
>  .../bindings/net/wireless/marvell-sd8xxx.txt   |   4 +
>  drivers/mmc/core/Kconfig   |  10 ++
>  drivers/mmc/core/Makefile  |   1 +
>  drivers/mmc/core/pwrseq_sd8787.c   | 117 
> +
>  5 files changed, 146 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>  create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
> b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt

According Documentation/devicetree/bindings/submitting-patches.txt,
the DT bindings patches should posted as a separate patch.

> new file mode 100644
> index ..1b658351629b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> @@ -0,0 +1,14 @@
> +* Marvell SD8787 power sequence provider
> +
> +Required properties:
> +- compatible: must be "mmc-pwrseq-sd8787".

Since this is not a generic binding, the compatible string should have
a vendor prefix.

> +- pwndn-gpio: contains a power down GPIO specifier.
> +- reset-gpio: contains a reset GPIO specifier.
> +

I wonder if we really need a custom power sequence provider for just
this SDIO WiFI chip though. AFAICT the only missing piece in
mmc-pwrseq-simple is the power down GPIO property, so maybe
mmc-pwrseq-simple could be extended instead to have an optional
powerdown-gpios property and instead in the Marvell SD8787 DT binding
can be mentioned which mmc-pwrseq-simple properties are required for
the device.

> +Example:
> +
> +   wifi_pwrseq: wifi_pwrseq {
> +   compatible = "mmc-pwrseq-sd8787";
> +   pwrdn-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
> +   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
> +   }
> diff --git 
> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt 
> b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt

Does this patch depend on a previous posted series? I don't see this
file in today's linux-next...

> index c421aba0a5bc..08fd65d35725 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> @@ -32,6 +32,9 @@ Optional properties:
>  so that the wifi chip can wakeup host platform under certain 
> condition.
>  during system resume, the irq will be disabled to make sure
>  unnecessary interrupt is not received.
> +  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
> +  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
> +for documentation of MMC power sequence bindings.
>
>  Example:
>
> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side pin.
>   {
> status = "okay";
> vmmc-supply = <_en_reg>;
> +   mmc-pwrseq = <_pwrseq>;
> bus-width = <4>;
> cap-power-off-card;
> keep-power-in-suspend;

I think this change should be split in a separate patch as well.

Best regards,
Javier

Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip

[Ulf Hansson]

On 29 November 2016 at 15:51, Rob Herring  wrote:
> On Mon, Nov 28, 2016 at 9:54 AM, Ulf Hansson  wrote:
>> [...]
>>
 +
 +Example:
 +
 + wifi_pwrseq: wifi_pwrseq {
 + compatible = "mmc-pwrseq-sd8787";
 + pwrdn-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
 + reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
 + }
 diff --git 
 a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt 
 b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
 index c421aba0a5bc..08fd65d35725 100644
 --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
 +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
 @@ -32,6 +32,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under 
 certain condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
 +  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>>>
>>> This is why pwrseq is wrong. You have some properties in the card node
>>> and some in pwrseq node. Everything should be in the card node.
>>
>> Put "all" in the card node, just doesn't work for MMC. Particular in
>> cases when we have removable cards, as then it would be wrong to have
>> a card node.
>
> When is there a problem with removable cards? The connector is
> standard and everything needed (CD, VMMC, VDDIO, etc.) is defined in
> the host controller node. If that isn't sufficient, then we should
> start defining a connector node.

I probably didn't get your point. Anyway, let's try again.

I don't see any problems with removable cards and neither with
non-removable cards.

Normally, we don't need a connector node, but instead we put the
related properties/phandles in the host controller node. This works
fine!

For SDIO func devices, sometimes we need a child node of the host
controller node, as to be able to describe certain characteristics of
the SDIO func device. So this case is kind of a special type of card
node (because one can have several SDIO func devices attached, even if
this isn't used).

Now, to follow the current bindings, we must not put connector related
bindings in the card node, like the vmmc-supply, perhaps that is what
causes confusion here?

>
>> The mmc pwrseq DT bindings just follows the legacy approach for MMC
>> and that's why the pwrseq handle is at the controller node. Yes, would
>> could have done it differently, but this is the case now, so we will
>> have to accept that.
>
> We're stuck with supporting the existing cases. That doesn't mean
> we're stuck with the same thing for new cases.

Agree!

But I think there is nothing to improve in this case, or am I wrong?

Kind regards
Uffe

Re: bcma: add Dell Inspiron 3148

[Kalle Valo]

Jiri Slaby  wrote:
> This is what is in the laptop:
> 01:00.0 Network controller [0280]: Broadcom Limited BCM43142 802.11b/g/n 
> [14e4:4365] (rev 01)
> Subsystem: Dell Device [1028:0018]
> Flags: bus master, fast devsel, latency 0, IRQ 18
> Memory at b040 (64-bit, non-prefetchable) [size=32K]
> Capabilities: [40] Power Management version 3
> Capabilities: [58] Vendor Specific Information: Len=78 
> Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [d0] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [13c] Virtual Channel
> Capabilities: [160] Device Serial Number 00-00-9a-ff-ff-f3-40-b8
> Capabilities: [16c] Power Budgeting 
> 
> With the patch, I can see:
> bcma: bus0: Found chip with id 43142, rev 0x01 and package 0x08
> bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x28, class 
> 0x0)
> bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x21, class 
> 0x0)
> bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x16, class 0x0)
> bcma: bus0: Core 3 found: UNKNOWN (manuf 0x43B, id 0x368, rev 0x00, class 0x0)
> bcma: bus0: Bus registered
> 
> The wifi is not currently supported by brcmsmac yet:
> brcmsmac bcma1:1: mfg 4bf core 812 rev 33 class 0 irq 18
> brcmsmac: unknown device id 4365
> 
> So don't expect a working wifi from this patch :).
> 
> Signed-off-by: Jiri Slaby 
> Cc: Rafał Miłecki 
> Cc: 

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

59391a96dc73 bcma: add Dell Inspiron 3148

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: rtlwifi: Fix enter/exit power_save

[Kalle Valo]

Larry Finger  wrote:
> In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and
> commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
> to use work queue"), an error was introduced in the power-save routines
> due to the fact that leaving PS was delayed by the use of a work queue.
> 
> This problem is fixed by detecting if the enter or leave routines are
> in interrupt mode. If so, the workqueue is used to place the request.
> If in normal mode, the enter or leave routines are called directly.
> 
> Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to 
> use work queue")
> Reported-by: Ping-Ke Shih 
> Signed-off-by: Larry Finger 
> Cc: Stable 

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

ba9f93f82aba rtlwifi: Fix enter/exit power_save

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: mt7601u: wait for clear rxq when stopping mac

[Kalle Valo]

Anthony Romano  wrote:
> mt7601u_mac_stop_hw should stop polling the rxq once it remains empty
> but instead continues polling after the rxq status stays clear; bringing
> down the interface takes about six seconds from this alone.
> 
> Speed up path by exiting rxq loop once status repeatedly polls empty.
> 
> Signed-off-by: Anthony Romano 
> Reviewed-by: Jakub Kicinski 

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

05db221e30a9 mt7601u: wait for clear rxq when stopping mac

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: adm80211: Removed unused 'io_addr' 'mem_addr' variables

[Kalle Valo]

Kirtika Ruchandani  wrote:
> Initial commit cc0b88cf5ecf ([PATCH] Add adm8211 802.11b wireless driver)
> introduced variables mem_addr and io_addr in adm80211_probe() that are
> set but not used. Compiling with W=1 gives the following warnings,
> fix them.
> 
> drivers/net/wireless/admtek/adm8211.c: In function ‘adm8211_probe’:
> drivers/net/wireless/admtek/adm8211.c:1769:15: warning: variable ‘io_addr’ 
> set but not used [-Wunused-but-set-variable]
>   unsigned int io_addr, io_len;
>^
> drivers/net/wireless/admtek/adm8211.c:1768:16: warning: variable ‘mem_addr’ 
> set but not used [-Wunused-but-set-variable]
>   unsigned long mem_addr, mem_len;
> ^
> 
> These are harmless warnings and are only being fixed to reduce the
> noise with W=1 in the kernel. The calls to pci_resource_start do not
> have any side-effects and are safe to remove.
> 
> Fixes: cc0b88cf5ecf ("[PATCH] Add adm8211 802.11b wireless driver")
> Cc: Michael Wu 
> Cc: John W. Linville 
> Signed-off-by: Kirtika Ruchandani 

The patch failed to apply:

fatal: corrupt patch at line 14
Applying: adm80211: Removed unused 'io_addr' 'mem_addr' variables
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 adm80211: Removed unused 'io_addr' 'mem_addr' variables

Patch set to Changes Requested.

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: [01/12] brcmfmac: add pcie host dongle interface rev6 support

[Kalle Valo]

Arend Van Spriel  wrote:
> From: Franky Lin 
> 
> In rev6 of pcie host dongle interface protocol, host needs to maximum
> supported ring number from dongle shared memory and set up ring buffer
> and ring indices offset accordingly.
> 
> Reviewed-by: Hante Meuleman 
> Reviewed-by: Pieter-Paul Giesberts 
> Reviewed-by: Arend van Spriel 
> Signed-off-by: Franky Lin 
> Signed-off-by: Arend van Spriel 

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

be4b092cab84 brcmfmac: add pcie host dongle interface rev6 support
dc630dc5c753 brcmfmac: add support for 43341 chip
ac55136f43d3 brcmfmac: move pno helper functions in separate source file
3e2e86ab19c2 brcmfmac: fix handling ssids in .sched_scan_start() callback
ab5981c83033 brcmfmac: change prototype for brcmf_do_escan()
fa85b30a9084 brcmfmac: make internal escan more generic
fca6cb2f059e brcmfmac: split up brcmf_pno_config() function
3e48611d31dd brcmfmac: move scheduled scan activation to pno source file
331e78944361 brcmfmac: use provided channels for scheduled scan
dfe5b0d52d58 brcmfmac: remove restriction from .sched_scan_start() callback
c6989fd55ceb brcmfmac: use requested scan interval in scheduled scan
53e3a80d80c8 brcmfmac: fix scheduled scan result handling for newer chips

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: mwifiex: pcie: implement timeout loop for FW programming doorbell

[Kalle Valo]

Brian Norris  wrote:
> Marvell Wifi PCIe modules don't always behave nicely for PCIe power
> management when their firmware hasn't been loaded, particularly after
> suspending the PCIe link one or more times. When this happens, we might
> end up spinning forever in this status-polling tight loop. Let's make
> this less tight by adding a timeout and by sleeping a bit in between
> reads, as we do with the other similar loops.
> 
> This prevents us from hogging a CPU even in such pathological cases, and
> allows the FW initialization to just fail gracefully instead.
> 
> I chose the same polling parameters as the earlier loop in this
> function, and empirically, I found that this loop never makes it more
> than about 12 cycles in a sane FW init sequence. I had no official
> information on the actual intended latency for this portion of the
> download.
> 
> Signed-off-by: Brian Norris 
> Acked-by: Amitkumar Karwar 

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

22dde1ed5a48 mwifiex: pcie: implement timeout loop for FW programming doorbell

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: [v2, 1/7] mwifiex: Removed unused mwifiex_private* 'priv' variable

[Kalle Valo]

Kirtika Ruchandani  wrote:
> Commit bec568ff5107 removed the last remaining usage of struct
> mwifiex_private* priv in mwifiex_fw_dpc(), by removing the call to
> mwifiex_del_virtual_intf().
> Compiling mwifiex/ with W=1 gives the following warning, fix it.
> mwifiex/main.c: In function ‘mwifiex_fw_dpc’:
> mwifiex/main.c:520:26: warning: variable ‘priv’ set but not used 
> [-Wunused-but-set-variable]
> 
> Fixes: bec568ff5107 ("mwifiex: failure path handling in 
> mwifiex_add_virtual_intf()")
> Cc: Amitkumar Karwar 
> Signed-off-by: Kirtika Ruchandani 

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

70d740598713 mwifiex: Removed unused mwifiex_private* 'priv' variable
8ac9134161d9 mwifiex: Remove unused 'chan_num' variable
2c2bcabf02e1 mwifiex: Remove unused 'sta_ptr' variable
60261b266a84 mwifiex: Remove unused 'adapter'variable
e9f1db8b6859 mwifiex: Remove unused 'pm_flag' variable
67dd2a754906 mwifiex: Removed unused 'pkt_type' variable
4133828c76c3 mwifiex: Remove unused 'bcd_usb' variable

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: [PATCH] ath9k_htc: don't use HZ for usb msg timeouts

[Oleksij Rempel]

Am 29.11.2016 um 10:45 schrieb Anthony Romano:
> Hi Oleksij,
> 
> I put 4 ar9271's on a 4 port hub into monitor mode for you and all
> interfaces are simultaneously collecting packets. My cheap USB power
> meter reads 4.37v@650mA between the hub and the host, so it's pushing
> the limit but appears stable.

Great work, thank you!

> On Mon, Nov 28, 2016 at 7:34 AM, Oleksij Rempel  wrote:
>> Hi Anthony,
>>
>> Am 28.11.2016 um 05:27 schrieb Anthony Romano:
>>> The usb_*_msg() functions expect a timeout in msecs but are given HZ,
>>> which is ticks per second. If HZ=100, firmware download often times out
>>> when there is modest USB utilization and the device fails to initialize.
>>
>>> Replaces HZ in usb_*_msg timeouts with 1000 msec since HZ is one second
>>> for timeouts in jiffies.
>>
>> wow..
>> This fix allow you use 4 adapter at same time?
>>> Signed-off-by: Anthony Romano 

Acked-by: Oleksij Rempel 



-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

pull-request: wireless-drivers 2016-11-29

[Kalle Valo]

Hi Dave,

if there's still time here's one more patch to 3.9. I think this is good
to have in 3.9 as it fixes an issue where we were printing uninitialised
memory in mwifiex. I had this in wireless-drivers already for some time
as I was waiting for other fixes and nothing serious actually came up.

If this doesn't make it to 3.9 that's not a problem, I'll just merge
this to wireless-drivers-next. Let me know what you prefer.

Kalle

The following changes since commit d3532ea6ce4ea501e421d130555e59edc2945f99:

  brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap 
(2016-10-27 18:04:54 +0300)

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-2016-11-29

for you to fetch changes up to fcd2042e8d36cf644bd2d69c26378d17158b17df:

  mwifiex: printk() overflow with 32-byte SSIDs (2016-11-17 13:16:52 +0200)


wireless-drivers fixes for 4.9

mwifiex

* properly terminate SSIDs so that uninitalised memory is not printed


Brian Norris (1):
  mwifiex: printk() overflow with 32-byte SSIDs

 drivers/net/wireless/marvell/mwifiex/cfg80211.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

Re: Deadlock in hacked 4.9.0-rc6+ kernel.

[Mohammed Shafi Shajakhan]

Hi Ben,

On Tue, Nov 29, 2016 at 06:50:33AM -0800, Ben Greear wrote:
> 
> 
> On 11/28/2016 11:34 PM, Mohammed Shafi Shajakhan wrote:
> >Hi Ben,
> >
> >On Mon, Nov 28, 2016 at 10:52:44AM -0800, Ben Greear wrote:
> >>I ported forward my patch set to the 4.9 kernel, and I am seeing lockups 
> >>fairly
> >>often.  As always, could be something I added locally, but in case someone 
> >>sees
> >>similar, then maybe I can reproduce it quicker and help track this down 
> >>since my
> >>test config uses many virtual stations and virtual APs.
> >
> >[shafi] does this happens with a firmware crash (or) hardware restart ?, 
> >please
> >let us know, we have a potential fix for the same and we will send the fix 
> >for
> >linux wireless review soon, else please ignore.
> 
> It does look like the FW restarted, but not sure if that was due to crash or
> because all vdevs were admin-down for some reason.

[shafi] the kernel crash that happens after firmware crash / assert shall be 
helped
by the patch
https://patchwork.kernel.org/patch/9452265/

You could easily trigger the same in ath10k debugfs (simulate assert/hw-restart)

> 
> Thanks,
> Ben
> 
> >
> >>
> >>And, if someone knows the magic trick to make dmesg output from lockdep
> >>not be so split up, please let me know.
> >>
> >>
> >>[81871.799595] ath10k_pci :05:00.0: boot warm reset complete
> >>[81873.983645] sta559: Failed to send nullfunc to AP 04:f0:21:0f:3c:3c 
> >>after 1000ms, disconnecting
> >>[81873.991198] ath10k_pci :05:00.0: mac ampdu vdev_id 49 sta 
> >>04:f0:21:0f:3c:3c tid 6 action 1
> >>[82195.484265] INFO: task mission-control:1506 blocked for more than 180 
> >>seconds.
> >>[82195.490228]   Tainted: GW   4.9.0-rc6+ #9
> >>[82195.494367] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> >>this message.
> >>[82195.500922] mission-control D0  1506  1 0x
> >>[82195.505152]  8801f1c3a300 2629 880214de2640 
> >>8801f2f38000
> >>[82195.511330]  88021e3198d8 c90003867c80 819322eb 
> >>0006
> >>[82195.518230]  8801f2f38828 03867c78 88021e3198d8 
> >>
> >>[82195.525121] Call Trace:
> >>[82195.526300]  [] ? __schedule+0x2fb/0xb30
> >>[82195.530862]  [] schedule+0x38/0x90
> >>[82195.534552]  [] schedule_preempt_disabled+0x10/0x20
> >>[82195.540073]  [] mutex_lock_nested+0x175/0x3f0
> >>[82195.544723]  [] ? rtnetlink_rcv+0x16/0x30
> >>[82195.549424]  [] rtnetlink_rcv+0x16/0x30
> >>[82195.553555]  [] netlink_unicast+0x1cd/0x2e0
> >>[82195.558414]  [] ? netlink_unicast+0x149/0x2e0
> >>[82195.563062]  [] netlink_sendmsg+0x2e2/0x390
> >>[82195.567889]  [] ? __fget+0x108/0x1f0
> >>[82195.571755]  [] sock_sendmsg+0x33/0x40
> >>[82195.575791]  [] SYSC_sendto+0x101/0x190
> >>[82195.580258]  [] ? security_file_permission+0x96/0xb0
> >>[82195.585521]  [] ? rw_verify_area+0x49/0xb0
> >>[82195.589909]  [] ? trace_hardirqs_on_caller+0x129/0x1b0
> >>[82195.595364]  [] ? trace_hardirqs_on_thunk+0x1a/0x1c
> >>[82195.600538]  [] SyS_sendto+0x9/0x10
> >>[82195.604319]  [] entry_SYSCALL_64_fastpath+0x23/0xc6
> >>[82195.609502]
> >>Showing all locks held in the system:
> >>[82195.613134] 2 locks held by khungtaskd/37:
> >>[82195.615958]  #0:
> >>[82195.616408]  (
> >>[82195.616802] rcu_read_lock
> >>[82195.617946] ){..}
> >>[82195.618983] , at:
> >>[82195.619522] [] watchdog+0x9c/0x600
> >>[82195.623219]  #1:
> >>[82195.623666]  (
> >>[82195.624060] tasklist_lock
> >>[82195.625208] ){.+.+..}
> >>[82195.626213] , at:
> >>[82195.626748] [] debug_show_all_locks+0x3d/0x1a0
> >>[82195.631513] 2 locks held by agetty/1149:
> >>[82195.634160]  #0:
> >>[82195.634610]  (
> >>[82195.635001] >ldisc_sem
> >>[82195.636320] ){.+}
> >>[82195.637323] , at:
> >>[82195.637859] [] ldsem_down_read+0x2d/0x40
> >>[82195.642077]  #1:
> >>[82195.642528]  (
> >>[82195.642922] >atomic_read_lock
> >>[82195.645027] ){+.+...}
> >>[82195.646030] , at:
> >>[82195.646569] [] n_tty_read+0xa9/0x910
> >>[82195.650442] 1 lock held by mission-control/1506:
> >>[82195.653800]  #0:
> >>[82195.654249]  (
> >>[82195.654645] rtnl_mutex
> >>[82195.655527] ){+.+.+.}
> >>[82195.656534] , at:
> >>[82195.657068] [] rtnetlink_rcv+0x16/0x30
> >>[82195.661113] 2 locks held by bash/1691:
> >>[82195.663586]  #0:
> >>[82195.664033]  (
> >>[82195.664433] >ldisc_sem
> >>[82195.665750] ){.+}
> >>[82195.666754] , at:
> >>[82195.667294] [] ldsem_down_read+0x2d/0x40
> >>[82195.671509]  #1:
> >>[82195.671954]  (
> >>[82195.672349] >atomic_read_lock
> >>[82195.674447] ){+.+...}
> >>[82195.675451] , at:
> >>[82195.675987] [] n_tty_read+0xa9/0x910
> >>[82195.679857] 1 lock held by evolution-calen/1768:
> >>[82195.683200]  #0:
> >>[82195.683649]  (
> >>[82195.684040] rtnl_mutex
> >>[82195.684925] ){+.+.+.}
> >>[82195.685930] , at:
> >>[82195.686467] [] rtnetlink_rcv+0x16/0x30
> >>[82195.690514] 2 locks held by hostapd/4100:
> >>[82195.693249]  #0:
> >>[82195.693694]  (
> >>[82195.694090] cb_lock
> 

Re: [PATCH 03/12] brcmfmac: move pno helper functions in separate source file

[Kalle Valo]

Rafał Miłecki  writes:

> On 29 November 2016 at 10:23, Arend Van Spriel
>  wrote:
>> On 29-11-2016 8:57, Johannes Berg wrote:
>>> On Tue, 2016-11-29 at 08:08 +0100, Rafał Miłecki wrote:
 On 23 November 2016 at 11:25, Arend van Spriel
  wrote:
>
> Introducing new source file for pno related functionality. Moving
> existing pno functions.

 Let me ask one basic question as I'm curious: what that PNO stands
 for? I couldn't find it explained in the code.
>>>
>>> It's an Android term - Preferred Network Offload(ing?)
>>
>> Yeah. The module is called pfn in our firmware, which stands for
>> preferred network. So not sure whether it was a BRCM term morphed into
>> Android term or vice versa.
>>
>> Kalle,
>>
>> If needed I could drop the use of the term and resubmit the series.
>
> I don't have anything against it, I was just trying to understand that
> part of driver (which makes more sense now, thanks).

I don't have any problems as these are already implemented, you are only
moving code around. But if you were adding a new feature to the driver
when an explanation for the acronym is very much preferred.

-- 
Kalle Valo

Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip

[Rob Herring]

On Mon, Nov 28, 2016 at 9:54 AM, Ulf Hansson  wrote:
> [...]
>
>>> +
>>> +Example:
>>> +
>>> + wifi_pwrseq: wifi_pwrseq {
>>> + compatible = "mmc-pwrseq-sd8787";
>>> + pwrdn-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
>>> + reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
>>> + }
>>> diff --git 
>>> a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt 
>>> b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> index c421aba0a5bc..08fd65d35725 100644
>>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>> @@ -32,6 +32,9 @@ Optional properties:
>>>so that the wifi chip can wakeup host platform under certain 
>>> condition.
>>>during system resume, the irq will be disabled to make sure
>>>unnecessary interrupt is not received.
>>> +  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>>
>> This is why pwrseq is wrong. You have some properties in the card node
>> and some in pwrseq node. Everything should be in the card node.
>
> Put "all" in the card node, just doesn't work for MMC. Particular in
> cases when we have removable cards, as then it would be wrong to have
> a card node.

When is there a problem with removable cards? The connector is
standard and everything needed (CD, VMMC, VDDIO, etc.) is defined in
the host controller node. If that isn't sufficient, then we should
start defining a connector node.

> The mmc pwrseq DT bindings just follows the legacy approach for MMC
> and that's why the pwrseq handle is at the controller node. Yes, would
> could have done it differently, but this is the case now, so we will
> have to accept that.

We're stuck with supporting the existing cases. That doesn't mean
we're stuck with the same thing for new cases.

Rob

ath10k: Fix soft lockup during firmware crash/hw-restart

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

During firmware crash (or) user requested manual restart
the system gets into a soft lock up state because of the
below root cause.

During user requested hardware restart / firmware crash
the system goes into a soft lockup state as 'napi_synchronize'
is called after 'napi_disable' (which sets 'NAPI_STATE_SCHED'
bit) and it sleeps into infinite loop as it waits for
'NAPI_STATE_SCHED' to be cleared. This condition is hit because
'ath10k_hif_stop' is called twice as below (resulting in calling
'napi_synchronize' after 'napi_disable')

'ath10k_core_restart' -> 'ath10k_hif_stop' (ATH10K_STATE_ON) ->
-> 'ieee80211_restart_hw' -> 'ath10k_start' -> 'ath10k_halt' ->
'ath10k_core_stop' -> 'ath10k_hif_stop' (ATH10K_STATE_RESTARTING)

Fix this by calling 'ath10k_halt' in ath10k_core_restart itself
as it makes more sense before informing mac80211 to restart h/w
Also remove 'ath10k_halt' in ath10k_start for the state of 'restarting'

Signed-off-by: Mohammed Shafi Shajakhan 
---
[thanks to Kalle and Michal for their inputs]

 drivers/net/wireless/ath/ath10k/core.c | 2 +-
 drivers/net/wireless/ath/ath10k/mac.c  | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 7005e2a..5bc6847 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct *work)
switch (ar->state) {
case ATH10K_STATE_ON:
ar->state = ATH10K_STATE_RESTARTING;
-   ath10k_hif_stop(ar);
+   ath10k_halt(ar);
ath10k_scan_finish(ar);
ieee80211_restart_hw(ar->hw);
break;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 717b2fa..481842b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
ar->state = ATH10K_STATE_ON;
break;
case ATH10K_STATE_RESTARTING:
-   ath10k_halt(ar);
ar->state = ATH10K_STATE_RESTARTED;
break;
case ATH10K_STATE_ON:
-- 
1.9.1

Re: [PATCH] mac80211: fix Tx BA session stuck issue during sw scanning

[Arend Van Spriel]

On 29-11-2016 13:59, Johannes Berg wrote:
> On Wed, 2016-11-23 at 15:59 +0800, Chris Chiu wrote:
>> ieee80211_iface_work() will check if sw scanning is in progress
>> before handling block ack session. In our case, the RTL8821AE
>> operate in station mode, when tx session expired, DELBA packet
>> stuck during sw scanning and so do other data packets.
>>
>> ieee80211_scan_state_decision() will take lots of time in
>> SCAN_SUSPEND/SCAN_RESUME state due to !tx_empty or bad_latency.
>> Then the sw scanning mostly take > 20 seconds to finish or even
>> worse in our case RTL8821AE have 37 channels for 2G+5G to scan
>> and tx stalls ~300 seconds. AP side still thinks the connection
>> is alive because it still receives the QoS NULL packet from STA.
>> So the link state will never change but actually no data tx/rx
>> during this long time.
>>
>> This commit tries to send out packet in SCAN_SUSPEND state so the
>> sw scanning can complete more efficiently and less affect on Block
>> Ack session handling. Verified on RTL8821AE for > 3 pings and
>> no Tx BA session stuck observed.
> 
> The premise seems fairly reasonable, although I'm a little worried that
> if so much new traffic is coming in we never finish the scan suspend?
> Actually, the queues are still stopped, so it's only management frames
> that can come in, so that should be ok?

So are pings a good way to verify block-ack session handling. How often
was a scan issued within those 3 pings or was that left to
wpa_supplicant/network-manager/whatever?

Regards,
Arend

>> +test_and_clear_bit(SCAN_SUSPEND_SCANNING, >scanning);
>>
> 
> That makes no sense, you're not checking the return value, just clear
> the bit without test.
>  
>> @@ -844,6 +846,8 @@ static void ieee80211_scan_state_suspend(struct
>> ieee80211_local *local,
>>  /* disable PS */
>>  ieee80211_offchannel_return(local);
>>  
>> +__set_bit(SCAN_SUSPEND_SCANNING, >scanning);
> 
> Why are you using the non-atomic version here, vs. the atomic one
> above?
> 
> johannes
> 

Re: [PATCH] mac80211: fix Tx BA session stuck issue during sw scanning

[Johannes Berg]

On Wed, 2016-11-23 at 15:59 +0800, Chris Chiu wrote:
> ieee80211_iface_work() will check if sw scanning is in progress
> before handling block ack session. In our case, the RTL8821AE
> operate in station mode, when tx session expired, DELBA packet
> stuck during sw scanning and so do other data packets.
> 
> ieee80211_scan_state_decision() will take lots of time in
> SCAN_SUSPEND/SCAN_RESUME state due to !tx_empty or bad_latency.
> Then the sw scanning mostly take > 20 seconds to finish or even
> worse in our case RTL8821AE have 37 channels for 2G+5G to scan
> and tx stalls ~300 seconds. AP side still thinks the connection
> is alive because it still receives the QoS NULL packet from STA.
> So the link state will never change but actually no data tx/rx
> during this long time.
> 
> This commit tries to send out packet in SCAN_SUSPEND state so the
> sw scanning can complete more efficiently and less affect on Block
> Ack session handling. Verified on RTL8821AE for > 3 pings and
> no Tx BA session stuck observed.

The premise seems fairly reasonable, although I'm a little worried that
if so much new traffic is coming in we never finish the scan suspend?
Actually, the queues are still stopped, so it's only management frames
that can come in, so that should be ok?

> + test_and_clear_bit(SCAN_SUSPEND_SCANNING, >scanning);
> 

That makes no sense, you're not checking the return value, just clear
the bit without test.
 
> @@ -844,6 +846,8 @@ static void ieee80211_scan_state_suspend(struct
> ieee80211_local *local,
>   /* disable PS */
>   ieee80211_offchannel_return(local);
>  
> + __set_bit(SCAN_SUSPEND_SCANNING, >scanning);

Why are you using the non-atomic version here, vs. the atomic one
above?

johannes

Re: [PATCH 00/12] brcmfmac: scheduled scan cleanup and chip support

[Rafał Miłecki]

On 29 November 2016 at 10:58, Arend Van Spriel
 wrote:
> On 29-11-2016 8:37, Rafał Miłecki wrote:
>> On 23 November 2016 at 11:25, Arend van Spriel
>>  wrote:
>>> This patch series contains:
>>> * cleanup of scheduled scan code.
>>> * fix handling schedules scan results for newer chips.
>>> * support for bcm43341 chipset with different chip id.
>>> * support rev6 of PCIe device interface.
>>>
>>> The series is intended for 4.10 and applies to the master branch
>>> of the wireless-drivers-next repository.
>>
>> Tested with BCM43602 on SR400ac router, it still initializes fine, I
>> can create multiple AP interfaces and use them.
>
> Thanks, Rafał
>
> Extra testing for the PCIe rev6 support is always appreciated. Although
> I am not sure what rev your 43602 device has. At least we know it is not
> broken ;-)

I guess it's not rev6, my testing was just against possible regressions :)

-- 
Rafał

Re: [PATCH 03/12] brcmfmac: move pno helper functions in separate source file

[Rafał Miłecki]

On 29 November 2016 at 10:23, Arend Van Spriel
 wrote:
> On 29-11-2016 8:57, Johannes Berg wrote:
>> On Tue, 2016-11-29 at 08:08 +0100, Rafał Miłecki wrote:
>>> On 23 November 2016 at 11:25, Arend van Spriel
>>>  wrote:

 Introducing new source file for pno related functionality. Moving
 existing pno functions.
>>>
>>> Let me ask one basic question as I'm curious: what that PNO stands
>>> for? I couldn't find it explained in the code.
>>
>> It's an Android term - Preferred Network Offload(ing?)
>
> Yeah. The module is called pfn in our firmware, which stands for
> preferred network. So not sure whether it was a BRCM term morphed into
> Android term or vice versa.
>
> Kalle,
>
> If needed I could drop the use of the term and resubmit the series.

I don't have anything against it, I was just trying to understand that
part of driver (which makes more sense now, thanks).

-- 
Rafał

Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device

[IgorMitsyanko]

On 11/29/2016 12:34 PM, Arend Van Spriel wrote:


On 29-11-2016 10:10, IgorMitsyanko wrote:

On 11/29/2016 06:49 AM, Oleksij Rempel wrote:

Am 28.11.2016 um 20:01 schrieb IgorMitsyanko:

On 11/28/2016 08:33 PM, Oleksij Rempel wrote:

Am 28.11.2016 um 18:10 schrieb Oleksij Rempel:

[...]


Oleksij, yes, that's correct, it includes entire Linux environment; the
reasoning is that it allows to hide all WiFi-related logic inside device
itself, and emulate simple Ethernet device for external system
(therefore, freeing external system resources).

This approach was working really well for us until recently, but now
that company is expanding, we want to have more flexible and standardize
interface available for external system to manage wireless connection,
and FullMAC driver seems to be the best solution here.

you mean, this driver will not use mac80211 framework provided by kernel?

Yes, this driver is FullMAC - converting Quantenna drivers codebase to
mac80211 framework will require significant effort from developers and
QA, but I think in the future it will have to be done anyway.

Why? The linux wireless subsystem supports both models, ie.
cfg80211-based drivers and mac80211-based drivers, so there is no
technical reason for making the effort. There are clearly benefits in
using a generic and freely available 802.11 stack like mac80211.


There is definitely a benefit if starting a new product development, 
however with existing products its not that simple due to highly 
conservative approach:
- for many years development was based on old MadWiFi driver and older 
kernel. Over time it was modified and rewritten to fit internal needs, 
and integrating it into mac80211 (to preserve the same behavior) would 
require significant effort.
- it takes a lot of resources to validate that system works as expected. 
Quantenna itself is doing QA testing and certification + engineering has 
to be sure there is no performance/feature regression + end product 
manufacturers has to do their own QA. Each change means a lot of time 
and money spend on validation, new potential bugs to fix etc


With FullMAC driver on the other hand, device firmware is a "black box" 
for external system and firmware changes can be kept to a minimum.
I'd like to clarify that I think that moving to mac80211 is inevitable 
in any case and will happen in the future.




Regards,
Arend

Re: [PATCH 00/12] brcmfmac: scheduled scan cleanup and chip support

[Arend Van Spriel]

On 29-11-2016 8:37, Rafał Miłecki wrote:
> On 23 November 2016 at 11:25, Arend van Spriel
>  wrote:
>> This patch series contains:
>> * cleanup of scheduled scan code.
>> * fix handling schedules scan results for newer chips.
>> * support for bcm43341 chipset with different chip id.
>> * support rev6 of PCIe device interface.
>>
>> The series is intended for 4.10 and applies to the master branch
>> of the wireless-drivers-next repository.
> 
> Tested with BCM43602 on SR400ac router, it still initializes fine, I
> can create multiple AP interfaces and use them.

Thanks, Rafał

Extra testing for the PCIe rev6 support is always appreciated. Although
I am not sure what rev your 43602 device has. At least we know it is not
broken ;-)

Regards,
Arend

Re: [PATCH] ath9k_htc: don't use HZ for usb msg timeouts

[Anthony Romano]

Hi Oleksij,

I put 4 ar9271's on a 4 port hub into monitor mode for you and all
interfaces are simultaneously collecting packets. My cheap USB power
meter reads 4.37v@650mA between the hub and the host, so it's pushing
the limit but appears stable.

On Mon, Nov 28, 2016 at 7:34 AM, Oleksij Rempel  wrote:
> Hi Anthony,
>
> Am 28.11.2016 um 05:27 schrieb Anthony Romano:
>> The usb_*_msg() functions expect a timeout in msecs but are given HZ,
>> which is ticks per second. If HZ=100, firmware download often times out
>> when there is modest USB utilization and the device fails to initialize.
>
>> Replaces HZ in usb_*_msg timeouts with 1000 msec since HZ is one second
>> for timeouts in jiffies.
>
> wow..
> This fix allow you use 4 adapter at same time?
>
>> Signed-off-by: Anthony Romano 
>> ---
>>  drivers/net/wireless/ath/ath9k/hif_usb.c | 9 +
>>  drivers/net/wireless/ath/ath9k/hif_usb.h | 2 ++
>>  2 files changed, 7 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c 
>> b/drivers/net/wireless/ath/ath9k/hif_usb.c
>> index e1c338cb9cb5..de2d212f39ec 100644
>> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
>> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
>> @@ -997,7 +997,8 @@ static int ath9k_hif_usb_download_fw(struct 
>> hif_device_usb *hif_dev)
>>   err = usb_control_msg(hif_dev->udev,
>> usb_sndctrlpipe(hif_dev->udev, 0),
>> FIRMWARE_DOWNLOAD, 0x40 | USB_DIR_OUT,
>> -   addr >> 8, 0, buf, transfer, HZ);
>> +   addr >> 8, 0, buf, transfer,
>> +   USB_MSG_TIMEOUT);
>>   if (err < 0) {
>>   kfree(buf);
>>   return err;
>> @@ -1020,7 +1021,7 @@ static int ath9k_hif_usb_download_fw(struct 
>> hif_device_usb *hif_dev)
>>   err = usb_control_msg(hif_dev->udev, usb_sndctrlpipe(hif_dev->udev, 0),
>> FIRMWARE_DOWNLOAD_COMP,
>> 0x40 | USB_DIR_OUT,
>> -   firm_offset >> 8, 0, NULL, 0, HZ);
>> +   firm_offset >> 8, 0, NULL, 0, USB_MSG_TIMEOUT);
>>   if (err)
>>   return -EIO;
>>
>> @@ -1249,7 +1250,7 @@ static int send_eject_command(struct usb_interface 
>> *interface)
>>
>>   dev_info(>dev, "Ejecting storage device...\n");
>>   r = usb_bulk_msg(udev, usb_sndbulkpipe(udev, bulk_out_ep),
>> - cmd, 31, NULL, 2000);
>> + cmd, 31, NULL, 2 * USB_MSG_TIMEOUT);
>>   kfree(cmd);
>>   if (r)
>>   return r;
>> @@ -1314,7 +1315,7 @@ static void ath9k_hif_usb_reboot(struct usb_device 
>> *udev)
>>   return;
>>
>>   ret = usb_interrupt_msg(udev, usb_sndintpipe(udev, USB_REG_OUT_PIPE),
>> -buf, 4, NULL, HZ);
>> +buf, 4, NULL, USB_MSG_TIMEOUT);
>>   if (ret)
>>   dev_err(>dev, "ath9k_htc: USB reboot failed\n");
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.h 
>> b/drivers/net/wireless/ath/ath9k/hif_usb.h
>> index 7c2ef7ecd98b..7846916aa01d 100644
>> --- a/drivers/net/wireless/ath/ath9k/hif_usb.h
>> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.h
>> @@ -71,6 +71,8 @@ extern int htc_use_dev_fw;
>>  #define USB_REG_IN_PIPE   3
>>  #define USB_REG_OUT_PIPE  4
>>
>> +#define USB_MSG_TIMEOUT 1000 /* (ms) */
>> +
>>  #define HIF_USB_MAX_RXPIPES 2
>>  #define HIF_USB_MAX_TXPIPES 4
>>
>>
>
>

Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device

[Arend Van Spriel]

On 29-11-2016 10:10, IgorMitsyanko wrote:
> On 11/29/2016 06:49 AM, Oleksij Rempel wrote:
>> Am 28.11.2016 um 20:01 schrieb IgorMitsyanko:
>>> On 11/28/2016 08:33 PM, Oleksij Rempel wrote:
 Am 28.11.2016 um 18:10 schrieb Oleksij Rempel:

[...]

>>> Oleksij, yes, that's correct, it includes entire Linux environment; the
>>> reasoning is that it allows to hide all WiFi-related logic inside device
>>> itself, and emulate simple Ethernet device for external system
>>> (therefore, freeing external system resources).
>>>
>>> This approach was working really well for us until recently, but now
>>> that company is expanding, we want to have more flexible and standardize
>>> interface available for external system to manage wireless connection,
>>> and FullMAC driver seems to be the best solution here.
>> you mean, this driver will not use mac80211 framework provided by kernel?
> 
> Yes, this driver is FullMAC - converting Quantenna drivers codebase to
> mac80211 framework will require significant effort from developers and
> QA, but I think in the future it will have to be done anyway.

Why? The linux wireless subsystem supports both models, ie.
cfg80211-based drivers and mac80211-based drivers, so there is no
technical reason for making the effort. There are clearly benefits in
using a generic and freely available 802.11 stack like mac80211.

Regards,
Arend

Re: [PATCH 03/12] brcmfmac: move pno helper functions in separate source file

[Arend Van Spriel]

On 29-11-2016 8:57, Johannes Berg wrote:
> On Tue, 2016-11-29 at 08:08 +0100, Rafał Miłecki wrote:
>> On 23 November 2016 at 11:25, Arend van Spriel
>>  wrote:
>>>
>>> Introducing new source file for pno related functionality. Moving
>>> existing pno functions.
>>
>> Let me ask one basic question as I'm curious: what that PNO stands
>> for? I couldn't find it explained in the code.
> 
> It's an Android term - Preferred Network Offload(ing?)

Yeah. The module is called pfn in our firmware, which stands for
preferred network. So not sure whether it was a BRCM term morphed into
Android term or vice versa.

Kalle,

If needed I could drop the use of the term and resubmit the series.

Regards,
Arend

Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device

[IgorMitsyanko]

On 11/29/2016 06:49 AM, Oleksij Rempel wrote:

Am 28.11.2016 um 20:01 schrieb IgorMitsyanko:

On 11/28/2016 08:33 PM, Oleksij Rempel wrote:

Am 28.11.2016 um 18:10 schrieb Oleksij Rempel:

Am 28.11.2016 um 17:34 schrieb Kyle McMartin:

On Tue, Nov 22, 2016 at 9:44 AM, IgorMitsyanko
 wrote:

Hi Ben, Kyle,
could you please share what is the position of linux-firmware
regarding
firmware binaries that include GPL components? Does it require
entire GPL
components codebase be present in linux-firmware tree, or maybe
having this
clause in license file is enough:
+Open Source Software. The Software may include components that are
licensed
+pursuant to open source software (“Open Source Components”).
Information
+regarding the Open Source Components included with the Software is
available
+upon request to osle...@quantenna.com. To the extent such Open Source
+Components are required to be licensed to you under the terms of a
separate
+license (such as an open source license) then such other terms
shall apply,
and
+nothing herein shall be deemed or interpreted to limit any rights
you may
have
+under any such applicable license.

  From technical perspective, size of the codebase used to build
Quantenna
firmware is a few hundred MBs, it seems too much to include into
linux-firmware tree.


I don't have strong feelings one way or another. I'd prefer not having
several hundred
MB of source that's unlikely to change included in the linux-firmware
git tree. I'm also not
a lawyer, so I can't help you decide what would satisfy the
distribution clause of the GPLv2.
We already have one GPL firmware (carl9170fw) which includes the
source, but just references
a seperate toolchain for downloading, so it's only approximately 1MB
in size in the tree.

Is your firmware source really that large, or is it just including the
entire build toolchain with it?

regards,
--Kyle

We also have open BSD licensed open-ath9k-htc-firmware. Which is locate
out of source too.
https://github.com/qca/open-ath9k-htc-firmware
and here is location of carl firmware:
https://github.com/chunkeey/carl9170fw

So, what is actual problem with Quantenna QSR10G FW?
I would be really interesting to take a look on it. Is it somewhere
available? Are there some devices to get hand on?

After seeing specs of this device i have strong feeling that "some open
source part" is actual linux kernel.



Oleksij, yes, that's correct, it includes entire Linux environment; the
reasoning is that it allows to hide all WiFi-related logic inside device
itself, and emulate simple Ethernet device for external system
(therefore, freeing external system resources).

This approach was working really well for us until recently, but now
that company is expanding, we want to have more flexible and standardize
interface available for external system to manage wireless connection,
and FullMAC driver seems to be the best solution here.

you mean, this driver will not use mac80211 framework provided by kernel?


Yes, this driver is FullMAC - converting Quantenna drivers codebase to 
mac80211 framework will require significant effort from developers and 
QA, but I think in the future it will have to be done anyway.





For the availability of FW sources, QSR10G-based products are still
under development at this moment (not in the market yet), but many
products based on previous generation chipset QSR1000 are available. For
example, Asus has a retail design with QSR1000 chipset, and has all GPL
sourcecode available on their website (including what Quantenna has
provided):

http://www.asus.com/Networking/RTAC87U/HelpDesk_Download/
Quantenna provided code is in, for example, "GPL of ASUS RT-AC87U for
firmware 3.0.0.4.378.7410" archive.
It's basically the same as used for QSR10G.

Will Quantenna provide documentation for at least old chipsats? Playing
fair with OSS developer community has some advantages :)


Will forward the request.
I agree with this, though this is more about protecting from other wifi 
vendors on a highly competitive market rather than hiding something from 
community) QSR1000 chipset that I mentioned is actually "current" 
chipset while QSR10G can be considered future chipset.