Re: ath10k firmware crashes in mesh mode on QCA9880

[Mohammed Shafi Shajakhan]

Hi,

On Tue, Nov 29, 2016 at 11:22:12AM -0800, Benjamin Morgan wrote:
> 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.

[shafi] Did you get a chance to try with the below firmware as well
https://github.com/kvalo/ath10k-firmware/blob/master/QCA988X/hw2.0/10.2.4.70/firmware-5.bin_10.2.4.70.58

> 
> 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]: 

Re: [PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

[Mohammed Shafi Shajakhan]

Hi Adrian,

On Wed, Nov 30, 2016 at 10:27:25AM -0800, Adrian Chadd wrote:
> Heh, I had to do something like this for freebsd too for my ath10k
> port. So thanks. :)

[shafi] thanks :):)

> 
> Suggestion - take a look at where tasklets, completions, locks, etc
> are all re-allocated multiple times, once upon initial VAP bringup. I
> had to also undo this in FreeBSD, as we don't allow re-init of tasks,
> completions, callouts and locks without first freeing/zero'ing them
> appropriately. :)
> 
>
[shafi] sure, I just added some basic debug prints

In ath10k_htt_tx_start and init tx_lock and pending_tx
In ath10k_htt_tx_start and tx mem allocated set to true

In ath10k_htt_tx_start and init tx_lock and pending_tx (initialized second time)
In ath10k_htt_tx_start and tx mem is already allocated
In ath10k_htt_tx_destroy and tx mem allocated set to false

But I see 'ath10k_htt_tx_stop' is called when the interface is brought down
and in that scenario we need to do 'idr_init(>pending_tx) ' ?
while doing a tx_lock might be a duplicate. Also if i understand correctly
the existing ath10k already calls tx buffer allocation twice via

4   2145  core.c <>
   ret = ath10k_core_start(ar, ATH10K_FIRMWARE_MODE_NORMAL,

5   4471  mac.c <>
   ret = ath10k_core_start(ar,
   ATH10K_FIRMWARE_MODE_NORMAL,

Also there is a suggestion to enhance this patch using DMA API's
(thanks Michal) and we will work on this once this goes fine
without any issues

regards,
shafi

> 
> 
> 
> On 30 November 2016 at 01:50, Mohammed Shafi Shajakhan
>  wrote:
> > From: Mohammed Shafi Shajakhan 
> >
> > With maximum number of vap's configured in a two radio supported
> > systems of ~256 Mb RAM, doing a continuous wifi down/up and
> > intermittent traffic streaming from the connected stations results
> > in failure to allocate contiguous memory for tx buffers. This results
> > in the disappearance of all VAP's and a manual reboot is needed as
> > this is not a crash (or) OOM(for OOM killer to be invoked). To address
> > this allocate contiguous memory for tx buffers one time and re-use them
> > until the modules are unloaded but this results in a slight increase in
> > memory footprint of ath10k when the wifi is down, but the modules are
> > still loaded. Also as of now we use a separate bool 'tx_mem_allocated'
> > to keep track of the one time memory allocation, as we cannot come up
> > with something like 'ath10k_tx_{register,unregister}' before
> > 'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc'
> > memory allocation is dependent on the hw_param 'continuous_frag_desc'
> >
> > a) memory footprint of ath10k without the change
> >
> > lsmod | grep ath10k
> > ath10k_core   414498  1 ath10k_pci
> > ath10k_pci 38236  0
> >
> > b) memory footprint of ath10k with the change
> >
> > ath10k_core   414980  1 ath10k_pci
> > ath10k_pci 38236  0
> >
> > Memory Failure Call trace:
> >
> > hostapd: page allocation failure: order:6, mode:0xd0
> >  [] (__dma_alloc_buffer.isra.23) from
> > [] (__alloc_remap_buffer.isra.26+0x14/0xb8)
> > [] (__alloc_remap_buffer.isra.26) from
> > [] (__dma_alloc+0x224/0x2b8)
> > [] (__dma_alloc) from []
> > (arm_dma_alloc+0x84/0x90)
> > [] (arm_dma_alloc) from []
> > (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
> > [] (ath10k_htt_tx_alloc [ath10k_core]) from
> > [] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
> > [] (ath10k_core_start [ath10k_core]) from
> > [] (ath10k_start+0xbc/0x56c [ath10k_core])
> > [] (ath10k_start [ath10k_core]) from
> > [] (drv_start+0x40/0x5c [mac80211])
> > [] (drv_start [mac80211]) from []
> > (ieee80211_do_open+0x170/0x82c [mac80211])
> > [] (ieee80211_do_open [mac80211]) from
> > [] (__dev_open+0xa0/0xf4)
> > [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR)
> > 126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB
> > 0*1024kB 0*2048kB 0*4096kB = 95276kB
> >
> > Signed-off-by: Mohammed Shafi Shajakhan 
> > ---
> >  drivers/net/wireless/ath/ath10k/core.c   |  5 +--
> >  drivers/net/wireless/ath/ath10k/htt.h|  6 +++-
> >  drivers/net/wireless/ath/ath10k/htt_tx.c | 54 
> > +---
> >  3 files changed, 51 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> > b/drivers/net/wireless/ath/ath10k/core.c
> > index 5bc6847..f7ea4de 100644
> > --- a/drivers/net/wireless/ath/ath10k/core.c
> > +++ b/drivers/net/wireless/ath/ath10k/core.c
> > @@ -1857,7 +1857,7 @@ int ath10k_core_start(struct ath10k *ar, enum 
> > ath10k_firmware_mode mode,
> > goto err_wmi_detach;
> > }
> >
> > -   status = ath10k_htt_tx_alloc(>htt);
> > +   status = ath10k_htt_tx_start(>htt);
> > if (status) {
> > ath10k_err(ar, "failed to alloc htt tx: %d\n", status);
> > goto err_wmi_detach;
> > @@ -2052,7 +2052,7 @@ void 

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

[Mohammed Shafi Shajakhan]

On Tue, Nov 29, 2016 at 10:16:50AM -0800, Ben Greear wrote:
> Is this something for stable?  And if so, how far back should it be applied?

@Kalle,

[shafi] kindly suggest. If i am not wrong this is only needed for 4.9

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

[shafi] thanks a lot 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
> 

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

[Kalle Valo]

David Miller  writes:

> From: Kalle Valo 
> Date: Tue, 29 Nov 2016 16:59:44 +0200
>
>> 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.
>
> Unless you are in a time-machine of some sort I assume you mean "4.9" not
> "3.9" :-)
>
> Pulled, thanks.

Hah, I have no idea where I came up with this "3.9" :) I was trying mean
"4.9" of course, thanks for pulling.

-- 
Kalle Valo

Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()

[Valo, Kalle]

Kalle Valo  writes:

> "Valo, Kalle"  writes:
>
>> Bjorn Andersson  writes:
>>
>>> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
>>>
 Bjorn Andersson  wrote:
 > The correct include file for getting errno constants and ERR_PTR() is
 > linux/err.h, rather than linux/errno.h, so fix the include.
 > 
 > Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled 
 > smem_state")
 > Acked-by: Andy Gross 
 > Signed-off-by: Bjorn Andersson 
 
 For some reason this fails to compile now. Can you take a look, please?
 
 ERROR: "qcom_wcnss_open_channel" 
 [drivers/net/wireless/ath/wcn36xx/wcn36xx.ko] undefined!
 make[1]: *** [__modpost] Error 1
 make: *** [modules] Error 2
 
 5 patches set to Changes Requested.
 
 9429045 [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
 9429047 [v5,2/5] wcn36xx: Transition driver to SMD client
>>>
>>> This patch was updated with the necessary depends in Kconfig to catch
>>> this exact issue and when I pull in your .config (which has QCOM_SMD=n,
>>> QCOM_WCNSS_CTRL=n and WCN36XX=y) I can build this just fine.
>>>
>>> I've tested the various combinations and it seems to work fine. Do you
>>> have any other patches in your tree?
>>
>> This was with the pending branch of my ath.git tree. There are other
>> wireless patches (ath10k etc) but I would guess they don't affect here.
>>
>>> Any stale objects?
>>
>> Not sure what you mean with this question, but I didn't run 'make clean'
>> if that's what you are asking.
>>
>>> Would you mind retesting this, before I invest more time in trying to
>>> reproduce the issue you're seeing?
>>
>> Sure, I'll take a look but that might take few days.
>
> I didn't find enough time to look at this in detail. I applied this to
> my ath.git pending branch, let's see what the kbuild bot finds.

It found the same problem. Interestingly I'm also building x86 with 32
bit, maybe it's related?

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
head:   1ea16a1c457939b4564643f7637d5cc639a8d3b7
commit: 5eb09c672b01460804fd49b1c9cc7d1072a102f0 [96/99] wcn36xx: Transition 
driver to SMD client
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 5eb09c672b01460804fd49b1c9cc7d1072a102f0
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "qcom_wcnss_open_channel" 
>> [drivers/net/wireless/ath/wcn36xx/wcn36xx.ko] undefined!

-- 
Kalle Valo

Package has been sent.

[Linda Guo]

Your shipment(s) is scheduled for delivery

Scheduled Delivery Date: 12/02/2016

Shipper: Chambers Group.

Kindly view the attached document for shipment/delivery details and
tracking procedure. You can also request a delivery change (e.g.
reschedule or reroute) from the tracking detail.

Approximate Delivery Time: between 3:00 PM and 7:00 PM DHL Service:
DHL 2nd Day Air.

We are pleased to provide you with delivery that fits your life.
--

© 2014 Parcel Service of the World. DHL, the DHL brandmark, and the
color brown are trademarks of DHL Service of America, Inc. All rights
reserved. All trademarks, trade names, or service marks that appear in
connection with DHL services are the property of their respective
owners. For more information on DHL's privacy practices, refer to the
DHL Privacy Notice. Please do not reply directly to this e-mail. DHL
will not receive any reply message. For questions or comments, contact
DHL.

Privacy Notice: This communication contains proprietary information
and may be confidential. If you are not the intended recipient, the
reading, copying, disclosure or other use of the contents of this
e-mail is strictly prohibited and you are instructed to please delete
this e-mail immediately.


DHL.pdf
Description: Adobe PDF document

[PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization

[Masashi Honma]

mesh_sync_offset_adjust_tbtt() implements Extensible synchronization
framework ([1] 13.13.2 Extensible synchronization framework). It shall
not operate the flag "TBTT Adjusting subfield" ([1] 8.4.2.100.8 Mesh
Capability), since it is used only for MBCA ([1] 13.13.4 Mesh beacon
collision avoidance, see 13.13.4.4.3 TBTT scanning and adjustment
procedures for detail). So this patch remove the flag operations.

[1] IEEE Std 802.11 2012

Signed-off-by: Masashi Honma 
---
 net/mac80211/mesh_sync.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/net/mac80211/mesh_sync.c b/net/mac80211/mesh_sync.c
index faca22c..836d791 100644
--- a/net/mac80211/mesh_sync.c
+++ b/net/mac80211/mesh_sync.c
@@ -172,11 +172,9 @@ static void mesh_sync_offset_adjust_tbtt(struct 
ieee80211_sub_if_data *sdata,
 struct beacon_data *beacon)
 {
struct ieee80211_if_mesh *ifmsh = >u.mesh;
-   u8 cap;
 
WARN_ON(ifmsh->mesh_sp_id != IEEE80211_SYNC_METHOD_NEIGHBOR_OFFSET);
WARN_ON(!rcu_read_lock_held());
-   cap = beacon->meshconf->meshconf_cap;
 
spin_lock_bh(>sync_offset_lock);
 
@@ -190,21 +188,13 @@ static void mesh_sync_offset_adjust_tbtt(struct 
ieee80211_sub_if_data *sdata,
  "TBTT : kicking off TBTT adjustment with 
clockdrift_max=%lld\n",
  ifmsh->sync_offset_clockdrift_max);
set_bit(MESH_WORK_DRIFT_ADJUST, >wrkq_flags);
-
-   ifmsh->adjusting_tbtt = true;
} else {
msync_dbg(sdata,
  "TBTT : max clockdrift=%lld; too small to adjust\n",
  (long long)ifmsh->sync_offset_clockdrift_max);
ifmsh->sync_offset_clockdrift_max = 0;
-
-   ifmsh->adjusting_tbtt = false;
}
spin_unlock_bh(>sync_offset_lock);
-
-   beacon->meshconf->meshconf_cap = ifmsh->adjusting_tbtt ?
-   IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING | cap :
-   ~IEEE80211_MESHCONF_CAPAB_TBTT_ADJUSTING & cap;
 }
 
 static const struct sync_method sync_methods[] = {
-- 
2.7.4

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

[David Miller]

From: Kalle Valo 
Date: Tue, 29 Nov 2016 16:59:44 +0200

> 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.

Unless you are in a time-machine of some sort I assume you mean "4.9" not
"3.9" :-)

Pulled, thanks.

[patch] mwifiex: clean up some messy indenting

[Dan Carpenter]

These lines were indented one tab extra.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c 
b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
index f5dffdf..fdc6cc2 100644
--- a/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/sta_cmd.c
@@ -1937,8 +1937,8 @@ int mwifiex_sta_prepare_cmd(struct mwifiex_private *priv, 
uint16_t cmd_no,
mwifiex_dbg(priv->adapter, ERROR,
"0x%x command not supported by firmware\n",
cmd_no);
-   return -EOPNOTSUPP;
-   }
+   return -EOPNOTSUPP;
+   }
 
/* Prepare command */
switch (cmd_no) {

Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()

[Valo, Kalle]

"Valo, Kalle"  writes:

> Bjorn Andersson  writes:
>
>> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
>>
>>> Bjorn Andersson  wrote:
>>> > The correct include file for getting errno constants and ERR_PTR() is
>>> > linux/err.h, rather than linux/errno.h, so fix the include.
>>> > 
>>> > Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled 
>>> > smem_state")
>>> > Acked-by: Andy Gross 
>>> > Signed-off-by: Bjorn Andersson 
>>> 
>>> For some reason this fails to compile now. Can you take a look, please?
>>> 
>>> ERROR: "qcom_wcnss_open_channel" 
>>> [drivers/net/wireless/ath/wcn36xx/wcn36xx.ko] undefined!
>>> make[1]: *** [__modpost] Error 1
>>> make: *** [modules] Error 2
>>> 
>>> 5 patches set to Changes Requested.
>>> 
>>> 9429045 [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
>>> 9429047 [v5,2/5] wcn36xx: Transition driver to SMD client
>>
>> This patch was updated with the necessary depends in Kconfig to catch
>> this exact issue and when I pull in your .config (which has QCOM_SMD=n,
>> QCOM_WCNSS_CTRL=n and WCN36XX=y) I can build this just fine.
>>
>> I've tested the various combinations and it seems to work fine. Do you
>> have any other patches in your tree?
>
> This was with the pending branch of my ath.git tree. There are other
> wireless patches (ath10k etc) but I would guess they don't affect here.
>
>> Any stale objects?
>
> Not sure what you mean with this question, but I didn't run 'make clean'
> if that's what you are asking.
>
>> Would you mind retesting this, before I invest more time in trying to
>> reproduce the issue you're seeing?
>
> Sure, I'll take a look but that might take few days.

I didn't find enough time to look at this in detail. I applied this to
my ath.git pending branch, let's see what the kbuild bot finds.

-- 
Kalle Valo

Re: [PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

[Adrian Chadd]

Heh, I had to do something like this for freebsd too for my ath10k
port. So thanks. :)

Suggestion - take a look at where tasklets, completions, locks, etc
are all re-allocated multiple times, once upon initial VAP bringup. I
had to also undo this in FreeBSD, as we don't allow re-init of tasks,
completions, callouts and locks without first freeing/zero'ing them
appropriately. :)



-adrian


On 30 November 2016 at 01:50, Mohammed Shafi Shajakhan
 wrote:
> From: Mohammed Shafi Shajakhan 
>
> With maximum number of vap's configured in a two radio supported
> systems of ~256 Mb RAM, doing a continuous wifi down/up and
> intermittent traffic streaming from the connected stations results
> in failure to allocate contiguous memory for tx buffers. This results
> in the disappearance of all VAP's and a manual reboot is needed as
> this is not a crash (or) OOM(for OOM killer to be invoked). To address
> this allocate contiguous memory for tx buffers one time and re-use them
> until the modules are unloaded but this results in a slight increase in
> memory footprint of ath10k when the wifi is down, but the modules are
> still loaded. Also as of now we use a separate bool 'tx_mem_allocated'
> to keep track of the one time memory allocation, as we cannot come up
> with something like 'ath10k_tx_{register,unregister}' before
> 'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc'
> memory allocation is dependent on the hw_param 'continuous_frag_desc'
>
> a) memory footprint of ath10k without the change
>
> lsmod | grep ath10k
> ath10k_core   414498  1 ath10k_pci
> ath10k_pci 38236  0
>
> b) memory footprint of ath10k with the change
>
> ath10k_core   414980  1 ath10k_pci
> ath10k_pci 38236  0
>
> Memory Failure Call trace:
>
> hostapd: page allocation failure: order:6, mode:0xd0
>  [] (__dma_alloc_buffer.isra.23) from
> [] (__alloc_remap_buffer.isra.26+0x14/0xb8)
> [] (__alloc_remap_buffer.isra.26) from
> [] (__dma_alloc+0x224/0x2b8)
> [] (__dma_alloc) from []
> (arm_dma_alloc+0x84/0x90)
> [] (arm_dma_alloc) from []
> (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
> [] (ath10k_htt_tx_alloc [ath10k_core]) from
> [] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
> [] (ath10k_core_start [ath10k_core]) from
> [] (ath10k_start+0xbc/0x56c [ath10k_core])
> [] (ath10k_start [ath10k_core]) from
> [] (drv_start+0x40/0x5c [mac80211])
> [] (drv_start [mac80211]) from []
> (ieee80211_do_open+0x170/0x82c [mac80211])
> [] (ieee80211_do_open [mac80211]) from
> [] (__dev_open+0xa0/0xf4)
> [21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR)
> 126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB
> 0*1024kB 0*2048kB 0*4096kB = 95276kB
>
> Signed-off-by: Mohammed Shafi Shajakhan 
> ---
>  drivers/net/wireless/ath/ath10k/core.c   |  5 +--
>  drivers/net/wireless/ath/ath10k/htt.h|  6 +++-
>  drivers/net/wireless/ath/ath10k/htt_tx.c | 54 
> +---
>  3 files changed, 51 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index 5bc6847..f7ea4de 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -1857,7 +1857,7 @@ int ath10k_core_start(struct ath10k *ar, enum 
> ath10k_firmware_mode mode,
> goto err_wmi_detach;
> }
>
> -   status = ath10k_htt_tx_alloc(>htt);
> +   status = ath10k_htt_tx_start(>htt);
> if (status) {
> ath10k_err(ar, "failed to alloc htt tx: %d\n", status);
> goto err_wmi_detach;
> @@ -2052,7 +2052,7 @@ void ath10k_core_stop(struct ath10k *ar)
> ath10k_wait_for_suspend(ar, 
> WMI_PDEV_SUSPEND_AND_DISABLE_INTR);
>
> ath10k_hif_stop(ar);
> -   ath10k_htt_tx_free(>htt);
> +   ath10k_htt_tx_stop(>htt);
> ath10k_htt_rx_free(>htt);
> ath10k_wmi_detach(ar);
>  }
> @@ -2385,6 +2385,7 @@ void ath10k_core_destroy(struct ath10k *ar)
> destroy_workqueue(ar->workqueue_aux);
>
> ath10k_debug_destroy(ar);
> +   ath10k_htt_tx_destroy(>htt);
> ath10k_wmi_free_host_mem(ar);
> ath10k_mac_destroy(ar);
>  }
> diff --git a/drivers/net/wireless/ath/ath10k/htt.h 
> b/drivers/net/wireless/ath/ath10k/htt.h
> index 0d2ed09..96bf7bf 100644
> --- a/drivers/net/wireless/ath/ath10k/htt.h
> +++ b/drivers/net/wireless/ath/ath10k/htt.h
> @@ -1692,6 +1692,8 @@ struct ath10k_htt {
> enum htt_tx_mode_switch_mode mode;
> enum htt_q_depth_type type;
> } tx_q_state;
> +
> +   bool tx_mem_allocated;
>  };
>
>  #define RX_HTT_HDR_STATUS_LEN 64
> @@ -1754,7 +1756,9 @@ struct htt_rx_desc {
>  int ath10k_htt_init(struct ath10k *ar);
>  int ath10k_htt_setup(struct ath10k_htt *htt);
>
> -int ath10k_htt_tx_alloc(struct ath10k_htt *htt);
> +int 

Re: [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting

[Jes Sorensen]

Kalle Valo  writes:
> Jes Sorensen  writes:
>
>> Luca Coelho  writes:
>>> On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote:
 jes.soren...@redhat.com writes:
 
 > From: Jes Sorensen 
 > 
 > Hi,
 > 
 > This patch works around the issue with 8192eu and 8723bu devices not
 > being able to reconnect. It is still not clear why this fails, and
 > looking at rtlwifi it does issue the command for 8192ee and 8723be
 > devices.
 > 
 > Until we have a better idea of what is going on, I have commented out
 > the offending code. I prefer not deleting it until we have a better
 > understanding of why this is causing issues.
 > 
 > Credits to Barry Day for tracking down and isolating the issue.
 > 
 > Kalle, not sure if this can make it to 4.9, but if it's possible it
 > would be ideal since this is causing real issues in the field.
 
 For 4.9 this is too late, sorry. I'll queue this to 4.10.
>>>
>>> You should then CC stable so it gets into 4.9.x when it reaches 4.10.
>>
>> Yeah good idea - Kalle do you want me to repost it with the CC line or
>> are you happy to add it?
>
> I can add it. To which stable releases should this go to?

Lets target 4.8 and 4.9 - I just verified it applies against 4.8.

Thanks,
Jes

Re: [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting

[Kalle Valo]

Jes Sorensen  writes:

> Luca Coelho  writes:
>> On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote:
>>> jes.soren...@redhat.com writes:
>>> 
>>> > From: Jes Sorensen 
>>> > 
>>> > Hi,
>>> > 
>>> > This patch works around the issue with 8192eu and 8723bu devices not
>>> > being able to reconnect. It is still not clear why this fails, and
>>> > looking at rtlwifi it does issue the command for 8192ee and 8723be
>>> > devices.
>>> > 
>>> > Until we have a better idea of what is going on, I have commented out
>>> > the offending code. I prefer not deleting it until we have a better
>>> > understanding of why this is causing issues.
>>> > 
>>> > Credits to Barry Day for tracking down and isolating the issue.
>>> > 
>>> > Kalle, not sure if this can make it to 4.9, but if it's possible it
>>> > would be ideal since this is causing real issues in the field.
>>> 
>>> For 4.9 this is too late, sorry. I'll queue this to 4.10.
>>
>> You should then CC stable so it gets into 4.9.x when it reaches 4.10.
>
> Yeah good idea - Kalle do you want me to repost it with the CC line or
> are you happy to add it?

I can add it. To which stable releases should this go to?

-- 
Kalle Valo

Re: [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting

[Jes Sorensen]

Luca Coelho  writes:
> On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote:
>> jes.soren...@redhat.com writes:
>> 
>> > From: Jes Sorensen 
>> > 
>> > Hi,
>> > 
>> > This patch works around the issue with 8192eu and 8723bu devices not
>> > being able to reconnect. It is still not clear why this fails, and
>> > looking at rtlwifi it does issue the command for 8192ee and 8723be
>> > devices.
>> > 
>> > Until we have a better idea of what is going on, I have commented out
>> > the offending code. I prefer not deleting it until we have a better
>> > understanding of why this is causing issues.
>> > 
>> > Credits to Barry Day for tracking down and isolating the issue.
>> > 
>> > Kalle, not sure if this can make it to 4.9, but if it's possible it
>> > would be ideal since this is causing real issues in the field.
>> 
>> For 4.9 this is too late, sorry. I'll queue this to 4.10.
>
> You should then CC stable so it gets into 4.9.x when it reaches 4.10.

Yeah good idea - Kalle do you want me to repost it with the CC line or
are you happy to add it?

Cheers,
Jes

[PATCH 1/2] mwifiex: code rearrangement in pcie.c and sdio.c

[Amitkumar Karwar]

From: Xinming Hu 

Next patch in this series is going to use mwifiex_read_reg() in remove
handlers. The changes here are prerequisites to avoid forward
declarations.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c |  73 +++---
 drivers/net/wireless/marvell/mwifiex/sdio.c | 336 ++--
 2 files changed, 201 insertions(+), 208 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 32fa4ed..7aa16a5 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -81,6 +81,42 @@ static void mwifiex_unmap_pci_memory(struct mwifiex_adapter 
*adapter,
 }
 
 /*
+ * This function writes data into PCIE card register.
+ */
+static int mwifiex_write_reg(struct mwifiex_adapter *adapter, int reg, u32 
data)
+{
+   struct pcie_service_card *card = adapter->card;
+
+   iowrite32(data, card->pci_mmap1 + reg);
+
+   return 0;
+}
+
+/* This function reads data from PCIE card register.
+ */
+static int mwifiex_read_reg(struct mwifiex_adapter *adapter, int reg, u32 
*data)
+{
+   struct pcie_service_card *card = adapter->card;
+
+   *data = ioread32(card->pci_mmap1 + reg);
+   if (*data == 0x)
+   return 0x;
+
+   return 0;
+}
+
+/* This function reads u8 data from PCIE card register. */
+static int mwifiex_read_reg_byte(struct mwifiex_adapter *adapter,
+int reg, u8 *data)
+{
+   struct pcie_service_card *card = adapter->card;
+
+   *data = ioread8(card->pci_mmap1 + reg);
+
+   return 0;
+}
+
+/*
  * This function reads sleep cookie and checks if FW is ready
  */
 static bool mwifiex_pcie_ok_to_access_hw(struct mwifiex_adapter *adapter)
@@ -374,43 +410,6 @@ static SIMPLE_DEV_PM_OPS(mwifiex_pcie_pm_ops, 
mwifiex_pcie_suspend,
 };
 
 /*
- * This function writes data into PCIE card register.
- */
-static int mwifiex_write_reg(struct mwifiex_adapter *adapter, int reg, u32 
data)
-{
-   struct pcie_service_card *card = adapter->card;
-
-   iowrite32(data, card->pci_mmap1 + reg);
-
-   return 0;
-}
-
-/*
- * This function reads data from PCIE card register.
- */
-static int mwifiex_read_reg(struct mwifiex_adapter *adapter, int reg, u32 
*data)
-{
-   struct pcie_service_card *card = adapter->card;
-
-   *data = ioread32(card->pci_mmap1 + reg);
-   if (*data == 0x)
-   return 0x;
-
-   return 0;
-}
-
-/* This function reads u8 data from PCIE card register. */
-static int mwifiex_read_reg_byte(struct mwifiex_adapter *adapter,
-int reg, u8 *data)
-{
-   struct pcie_service_card *card = adapter->card;
-
-   *data = ioread8(card->pci_mmap1 + reg);
-
-   return 0;
-}
-
-/*
  * This function adds delay loop to ensure FW is awake before proceeding.
  */
 static void mwifiex_pcie_dev_wakeup_delay(struct mwifiex_adapter *adapter)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 66d0dd6..6fcaf26 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -215,6 +215,171 @@ static int mwifiex_sdio_resume(struct device *dev)
return 0;
 }
 
+/* Write data into SDIO card register. Caller claims SDIO device. */
+static int
+mwifiex_write_reg_locked(struct sdio_func *func, u32 reg, u8 data)
+{
+   int ret = -1;
+
+   sdio_writeb(func, data, reg, );
+   return ret;
+}
+
+/* This function writes data into SDIO card register.
+ */
+static int
+mwifiex_write_reg(struct mwifiex_adapter *adapter, u32 reg, u8 data)
+{
+   struct sdio_mmc_card *card = adapter->card;
+   int ret;
+
+   sdio_claim_host(card->func);
+   ret = mwifiex_write_reg_locked(card->func, reg, data);
+   sdio_release_host(card->func);
+
+   return ret;
+}
+
+/* This function reads data from SDIO card register.
+ */
+static int
+mwifiex_read_reg(struct mwifiex_adapter *adapter, u32 reg, u8 *data)
+{
+   struct sdio_mmc_card *card = adapter->card;
+   int ret = -1;
+   u8 val;
+
+   sdio_claim_host(card->func);
+   val = sdio_readb(card->func, reg, );
+   sdio_release_host(card->func);
+
+   *data = val;
+
+   return ret;
+}
+
+/* This function writes multiple data into SDIO card memory.
+ *
+ * This does not work in suspended mode.
+ */
+static int
+mwifiex_write_data_sync(struct mwifiex_adapter *adapter,
+   u8 *buffer, u32 pkt_len, u32 port)
+{
+   struct sdio_mmc_card *card = adapter->card;
+   int ret;
+   u8 blk_mode =
+   (port & MWIFIEX_SDIO_BYTE_MODE_MASK) ? BYTE_MODE : BLOCK_MODE;
+   u32 blk_size = (blk_mode == BLOCK_MODE) ? MWIFIEX_SDIO_BLOCK_SIZE : 1;
+   u32 blk_cnt =
+   (blk_mode 

[PATCH 2/2] mwifiex: get rid of global user_rmmod flag

[Amitkumar Karwar]

From: Xinming Hu 

bus.remove() callback function is called when user removes this module
from kernel space or ejects the card from the slot. The driver handles
these 2 cases differently. Few commands (FUNC_SHUTDOWN etc.) are sent to
the firmware only for module unload case.

The variable 'user_rmmod' is used to distinguish between these two
scenarios.

This patch checks hardware status and get rid of global variable
user_rmmod.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 23 ---
 drivers/net/wireless/marvell/mwifiex/sdio.c | 27 ---
 drivers/net/wireless/marvell/mwifiex/usb.c  |  6 +-
 3 files changed, 17 insertions(+), 39 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 7aa16a5..079bb09 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -31,8 +31,6 @@
 #define PCIE_VERSION   "1.0"
 #define DRV_NAME"Marvell mwifiex PCIe"
 
-static u8 user_rmmod;
-
 static struct mwifiex_if_ops pcie_ops;
 
 static const struct of_device_id mwifiex_pcie_of_match_table[] = {
@@ -284,6 +282,9 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
struct pcie_service_card *card;
struct mwifiex_adapter *adapter;
struct mwifiex_private *priv;
+   const struct mwifiex_pcie_card_reg *reg;
+   u32 fw_status;
+   int ret;
 
card = pci_get_drvdata(pdev);
 
@@ -295,7 +296,11 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
 
cancel_work_sync(>work);
 
-   if (user_rmmod && !adapter->mfg_mode) {
+   reg = card->pcie.reg;
+   if (reg)
+   ret = mwifiex_read_reg(adapter, reg->fw_status, _status);
+
+   if (fw_status == FIRMWARE_READY_PCIE && !adapter->mfg_mode) {
mwifiex_deauthenticate_all(adapter);
 
priv = mwifiex_get_priv(adapter, MWIFIEX_BSS_ROLE_ANY);
@@ -310,7 +315,6 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
 
 static void mwifiex_pcie_shutdown(struct pci_dev *pdev)
 {
-   user_rmmod = 1;
mwifiex_pcie_remove(pdev);
 
return;
@@ -2864,8 +2868,11 @@ static void mwifiex_pcie_cleanup(struct mwifiex_adapter 
*adapter)
struct pcie_service_card *card = adapter->card;
struct pci_dev *pdev = card->dev;
const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
+   int ret;
+   u32 fw_status;
 
-   if (user_rmmod) {
+   ret = mwifiex_read_reg(adapter, reg->fw_status, _status);
+   if (fw_status == FIRMWARE_READY_PCIE) {
mwifiex_dbg(adapter, INFO,
"Clearing driver ready signature\n");
if (mwifiex_write_reg(adapter, reg->drv_rdy, 0x))
@@ -3177,9 +3184,6 @@ static int mwifiex_pcie_init_module(void)
 
pr_debug("Marvell PCIe Driver\n");
 
-   /* Clear the flag in case user removes the card. */
-   user_rmmod = 0;
-
ret = pci_register_driver(_pcie);
if (ret)
pr_err("Driver register failed!\n");
@@ -3200,9 +3204,6 @@ static int mwifiex_pcie_init_module(void)
  */
 static void mwifiex_pcie_cleanup_module(void)
 {
-   /* Set the flag as user is removing this module. */
-   user_rmmod = 1;
-
pci_unregister_driver(_pcie);
 }
 
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 6fcaf26..9a16e61 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -31,21 +31,6 @@
 
 #define SDIO_VERSION   "1.0"
 
-/* The mwifiex_sdio_remove() callback function is called when
- * user removes this module from kernel space or ejects
- * the card from the slot. The driver handles these 2 cases
- * differently.
- * If the user is removing the module, the few commands (FUNC_SHUTDOWN,
- * HS_CANCEL etc.) are sent to the firmware.
- * If the card is removed, there is no need to send these command.
- *
- * The variable 'user_rmmod' is used to distinguish these two
- * scenarios. This flag is initialized as FALSE in case the card
- * is removed, and will be set to TRUE for module removal when
- * module_exit function is called.
- */
-static u8 user_rmmod;
-
 static void mwifiex_sdio_work(struct work_struct *work);
 static DECLARE_WORK(sdio_work, mwifiex_sdio_work);
 
@@ -391,6 +376,8 @@ static int mwifiex_check_winner_status(struct 
mwifiex_adapter *adapter)
struct sdio_mmc_card *card;
struct mwifiex_adapter *adapter;
struct mwifiex_private *priv;
+   int ret = 0;
+   u16 firmware_stat;
 
card = sdio_get_drvdata(func);
if (!card)
@@ -404,7 +391,8 @@ static int mwifiex_check_winner_status(struct 
mwifiex_adapter *adapter)
 
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", 

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

[Ulf Hansson]

On 30 November 2016 at 14:11, Javier Martinez Canillas
 wrote:
> Hello Matt,
>
> On Tue, Nov 29, 2016 at 10:20 PM, Matt Ranostay
>  wrote:
>> On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
>
> [snip]
>
>>
>>
 +- 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...
>>
>
> Yes, I noticed that. I wouldn't say that it would be a hack for the
> pwrseq-simple since it already has a "post-power-on-delay-ms" DT
> property, so AFAICT it would just be adding a "pre-power-on-delay-ms"
> property for your use case.
>
> It would also be more consistent since it would support a delay for
> pre and post power callbacks. It would also make you avoid hardcoding
> the 300 msec wait, in case other device has a similar need but with a
> different wait time.
>
> In summary, I think that devices having a power (or power down) and
> enable GPIO, and needing to wait between the GPIO toggling are common.
> So I would prefer to make pwrseq-simple usable for these instead of
> adding device specific power sequence providers. But it's just my
> opinion and not my call :-)

This is a good idea. Please try out this approach.

[...]

Kind regards
Uffe

Re: [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting

[Luca Coelho]

On Wed, 2016-11-30 at 10:46 +0200, Kalle Valo wrote:
> jes.soren...@redhat.com writes:
> 
> > From: Jes Sorensen 
> > 
> > Hi,
> > 
> > This patch works around the issue with 8192eu and 8723bu devices not
> > being able to reconnect. It is still not clear why this fails, and
> > looking at rtlwifi it does issue the command for 8192ee and 8723be
> > devices.
> > 
> > Until we have a better idea of what is going on, I have commented out
> > the offending code. I prefer not deleting it until we have a better
> > understanding of why this is causing issues.
> > 
> > Credits to Barry Day for tracking down and isolating the issue.
> > 
> > Kalle, not sure if this can make it to 4.9, but if it's possible it
> > would be ideal since this is causing real issues in the field.
> 
> For 4.9 this is too late, sorry. I'll queue this to 4.10.

You should then CC stable so it gets into 4.9.x when it reaches 4.10.

--
Luca.

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

[Javier Martinez Canillas]

Hello Matt,

On Tue, Nov 29, 2016 at 10:20 PM, Matt Ranostay
 wrote:
> On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas

[snip]

>
>
>>> +- 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...
>

Yes, I noticed that. I wouldn't say that it would be a hack for the
pwrseq-simple since it already has a "post-power-on-delay-ms" DT
property, so AFAICT it would just be adding a "pre-power-on-delay-ms"
property for your use case.

It would also be more consistent since it would support a delay for
pre and post power callbacks. It would also make you avoid hardcoding
the 300 msec wait, in case other device has a similar need but with a
different wait time.

In summary, I think that devices having a power (or power down) and
enable GPIO, and needing to wait between the GPIO toggling are common.
So I would prefer to make pwrseq-simple usable for these instead of
adding device specific power sequence providers. But it's just my
opinion and not my call :-)

>>> +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.
>

I see, that's what I thought but I wasn't able to find the commit /
patch that did it.

>>
>>> 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.
>>

You didn't answer about this, but I guess you agree it should be in a
separate patch.

Best regards,
Javier

RE: [PATCH v3 4/5] mwifiex: wait firmware dump complete during card remove process

[Amitkumar Karwar]

Hi Brian,

> > > >   *
> > > > @@ -2227,7 +2237,7 @@ static void mwifiex_recreate_adapter(struct
> > > sdio_mmc_card *card)
> > > >  * discovered and initializes them from scratch.
> > > >  */
> > > >
> > > > -   mwifiex_sdio_remove(func);
> > > > +   __mwifiex_sdio_remove(func);
> > >
> > > ^^ So here, you're trying to avoid syncing with the card-reset work
> > > event, except that function will free up all your resources
> > > (including the static save_adapter). Thus, you're explicitly
> > > allowing a use-after- free error here. That seems unwise.
> >
> > Even if firmware dump is triggered after card reset is started, it
> > will execute after card reset is completed as discussed above. Only
> > problem I can see is with "save_adapter". We can put new_adapter
> > pointer in "save_adapter" at the end of mwifiex_recreate_adapter() to
> > solve the issue.
> 
> Ugh, yet another band-aid? You might do better to still cancel any
> pending work, just don't do it synchronously. i.e., do cancel_work()
> after you've removed the card. It doesn't make sense to do a FW dump on
> the "new" adapter when it was requested for the old one.

I could not find async version of cancel_work().
We can fix this problem with below change at the end of mwifiex_sdio_work(). 
All pending work requests would be ignored.


@ -2571,6 +2571,8 @@ static void mwifiex_sdio_work(struct work_struct *work)
if (test_and_clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET,
   _work_flags))
mwifiex_sdio_card_reset_work(save_adapter);
+   clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, _work_flags);
+   clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, _work_flags);
 }
--

> 
> > > Instead, you should actually retain the invariant that you're doing
> > > a full remove/reinitialize here, which includes doing the *same*
> > > cancel_work_sync() here in mwifiex_recreate_adapter() as you would
> > > in any other remove().
> >
> > We are executing mwifiex_recreate_adapter() as a part of sdio_work().
> > Calling
> > cancel_work_sync() here would cause deadlock. The API is supposed to
> > waits until sdio_work() is finished.
> 
> You are correct. So using the _sync() version would be wrong.
> 
> > >
> > > IOW, kill the __mwifiex_sdio_remove() and just call
> > > mwifiex_sdio_remove() as you were.
> > >
> > > That also means that you can do the same per-adapter cleanup in the
> > > following patch as you do for PCIe.
> >
> > Currently as sdio_work recreates "card", the work structure can't be
> moved inside card structure.
> > Let me know your suggestions.
> 
> If you address the TODO in mwifiex_create_adapter() instead, you can
> get past this problem:
> 
> /* TODO mmc_hw_reset does not require destroying and re-probing
> the
>  * whole adapter. Hence there was no need to for this rube-
> goldberg
>  * design to reload the fw from an external workqueue. If we
> don't
>  * destroy the adapter we could reload the fw from
>  * mwifiex_main_work_queue directly.
> 
> The "save_adapter" is an abomination that should be terminated swiftly,
> but it is perpetuated in part by the hacks noted in the TODO.
> 
> So I'd recommend addressing the TODO ASAP, but in the meantime, a hack
> like my suggestion (cancel the FW dump work w/o synchronizing) or --
> less preferably -- yours (manually set 'save_adapter' again) might be
> OK.
> 
> I think I've asked elsewhere but didn't receive an answer: why is
> SDIO's mwifiex_recreate_adapter() so much different from PCIe's
> mwifiex_do_flr()? It seems like the latter should be refactored to
> remove some of the PCIe-specific cruft from main.c and then reused for
> SDIO.

Our initial SDIO card reset implementation was based on MMC APIs where remove() 
and probe() would automatically get called by MMC subsystem after power cycle.
https://www.spinics.net/lists/linux-wireless/msg98435.html
Later it was improved by Andreas Fenkart by replacing those power cycle APIs 
with mmc_hw_reset().

For PCIe, function level reset is standard feature. We implemented 
".reset_notify" handler which gets called after and before FLR.

You are right. We can have SDIO's handling similar to PCIe and avoid 
destroying+recreating adapter/card.
We have started working on this. We will get rid of global save_adapter, 
sdio_work etc. Meanwhile I will post above mentioned change if it looks good to 
you.

Regards,
Amitkumar

[PATCH 1/2] net: rfkill: Cleanup error handling in rfkill_init()

[Michał Kępień]

Use a separate label per error condition in rfkill_init() to make it a
bit cleaner and easier to extend.

Signed-off-by: Michał Kępień 
---
 net/rfkill/core.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 884027f..f28e441 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1266,24 +1266,25 @@ static int __init rfkill_init(void)
 
error = class_register(_class);
if (error)
-   goto out;
+   goto error_class;
 
error = misc_register(_miscdev);
-   if (error) {
-   class_unregister(_class);
-   goto out;
-   }
+   if (error)
+   goto error_misc;
 
 #ifdef CONFIG_RFKILL_INPUT
error = rfkill_handler_init();
-   if (error) {
-   misc_deregister(_miscdev);
-   class_unregister(_class);
-   goto out;
-   }
+   if (error)
+   goto error_input;
 #endif
 
- out:
+   return 0;
+
+error_input:
+   misc_deregister(_miscdev);
+error_misc:
+   class_unregister(_class);
+error_class:
return error;
 }
 subsys_initcall(rfkill_init);
-- 
2.10.2

[PATCH 2/2] net: rfkill: Add rfkill-any LED trigger

[Michał Kępień]

This patch adds a new "global" (i.e. not per-rfkill device) LED trigger,
rfkill-any, which may be useful for laptops with a single "radio LED"
and multiple radio transmitters.  The trigger is meant to turn a LED on
whenever there is at least one radio transmitter active and turn it off
otherwise.

Signed-off-by: Michał Kępień 
---
Note that the search for any active radio will have quadratic complexity
whenever __rfkill_switch_all() is used (as it calls rfkill_set_block()
for every affected rfkill device), but I intentionally refrained from
implementing rfkill_any_led_trigger_event() using struct work_struct to
keep things simple, given the average number of rfkill devices in
hardware these days.  Please let me know in case this should be
reworked.

 net/rfkill/core.c | 73 +++
 1 file changed, 73 insertions(+)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index f28e441..5275f2f 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -176,6 +176,47 @@ static void rfkill_led_trigger_unregister(struct rfkill 
*rfkill)
 {
led_trigger_unregister(>led_trigger);
 }
+
+static struct led_trigger rfkill_any_led_trigger;
+
+static void __rfkill_any_led_trigger_event(void)
+{
+   enum led_brightness brightness = LED_OFF;
+   struct rfkill *rfkill;
+
+   list_for_each_entry(rfkill, _list, node) {
+   if (!(rfkill->state & RFKILL_BLOCK_ANY)) {
+   brightness = LED_FULL;
+   break;
+   }
+   }
+
+   led_trigger_event(_any_led_trigger, brightness);
+}
+
+static void rfkill_any_led_trigger_event(void)
+{
+   mutex_lock(_global_mutex);
+   __rfkill_any_led_trigger_event();
+   mutex_unlock(_global_mutex);
+}
+
+static void rfkill_any_led_trigger_activate(struct led_classdev *led_cdev)
+{
+   rfkill_any_led_trigger_event();
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+   rfkill_any_led_trigger.name = "rfkill-any";
+   rfkill_any_led_trigger.activate = rfkill_any_led_trigger_activate;
+   return led_trigger_register(_any_led_trigger);
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+   led_trigger_unregister(_any_led_trigger);
+}
 #else
 static void rfkill_led_trigger_event(struct rfkill *rfkill)
 {
@@ -189,6 +230,19 @@ static inline int rfkill_led_trigger_register(struct 
rfkill *rfkill)
 static inline void rfkill_led_trigger_unregister(struct rfkill *rfkill)
 {
 }
+
+static void rfkill_any_led_trigger_event(void)
+{
+}
+
+static int rfkill_any_led_trigger_register(void)
+{
+   return 0;
+}
+
+static void rfkill_any_led_trigger_unregister(void)
+{
+}
 #endif /* CONFIG_RFKILL_LEDS */
 
 static void rfkill_fill_event(struct rfkill_event *ev, struct rfkill *rfkill,
@@ -297,6 +351,7 @@ static void rfkill_set_block(struct rfkill *rfkill, bool 
blocked)
spin_unlock_irqrestore(>lock, flags);
 
rfkill_led_trigger_event(rfkill);
+   __rfkill_any_led_trigger_event();
 
if (prev != curr)
rfkill_event(rfkill);
@@ -477,6 +532,7 @@ bool rfkill_set_hw_state(struct rfkill *rfkill, bool 
blocked)
spin_unlock_irqrestore(>lock, flags);
 
rfkill_led_trigger_event(rfkill);
+   rfkill_any_led_trigger_event();
 
if (!rfkill->registered)
return ret;
@@ -523,6 +579,7 @@ bool rfkill_set_sw_state(struct rfkill *rfkill, bool 
blocked)
schedule_work(>uevent_work);
 
rfkill_led_trigger_event(rfkill);
+   rfkill_any_led_trigger_event();
 
return blocked;
 }
@@ -572,6 +629,7 @@ void rfkill_set_states(struct rfkill *rfkill, bool sw, bool 
hw)
schedule_work(>uevent_work);
 
rfkill_led_trigger_event(rfkill);
+   rfkill_any_led_trigger_event();
}
 }
 EXPORT_SYMBOL(rfkill_set_states);
@@ -988,6 +1046,7 @@ int __must_check rfkill_register(struct rfkill *rfkill)
 #endif
}
 
+   __rfkill_any_led_trigger_event();
rfkill_send_events(rfkill, RFKILL_OP_ADD);
 
mutex_unlock(_global_mutex);
@@ -1020,6 +1079,7 @@ void rfkill_unregister(struct rfkill *rfkill)
mutex_lock(_global_mutex);
rfkill_send_events(rfkill, RFKILL_OP_DEL);
list_del_init(>node);
+   __rfkill_any_led_trigger_event();
mutex_unlock(_global_mutex);
 
rfkill_led_trigger_unregister(rfkill);
@@ -1278,8 +1338,18 @@ static int __init rfkill_init(void)
goto error_input;
 #endif
 
+#ifdef CONFIG_RFKILL_LEDS
+   error = rfkill_any_led_trigger_register();
+   if (error)
+   goto error_led_trigger;
+#endif
+
return 0;
 
+error_led_trigger:
+#ifdef CONFIG_RFKILL_INPUT
+   rfkill_handler_exit();
+#endif
 error_input:
misc_deregister(_miscdev);
 error_misc:
@@ -1291,6 +1361,9 @@ subsys_initcall(rfkill_init);
 
 static void __exit rfkill_exit(void)
 {
+#ifdef CONFIG_RFKILL_LEDS
+

Re: Atheros ETSI DFS pattern

[Zefir Kurtisi]

On 11/30/2016 11:19 AM, voncken wrote:
> In the file drivers/net/wireless/ath/dfs_pattern_detector.c we can found the
> ETSI pattern definition.
> 
> In this definition we can found 7 patterns (0 to 6).
> 
> The ETSI standard EN 301893 Annex D only specifies 6 patterns. Only the
> pattern 1 to 6 defined in the ath dfs pattern match with the ETSI standard.
> 
> Why the pattern 0 is defined?
> 
> Is it possible to remove this pattern and keep compliant with the ETSI
> standard?
> 
> Thanks for your help.
> 
> Cedric.
> 
Hi,

pattern 0 is the 'reference DFS test signal', the 700Hz pattern with 18 pulses
each 1us wide.

At implementation time, EN301893 v1.5 was the current revision and the reference
pattern is defined in Table D.3. I double checked that v1.8.1 has this one still
defined, so it remains required.

Given that most basic DFS features in certification labs are tested with this
pattern, I don't expect it to be obsoleted any time.

Out of curiosity: why would you like it removed? From the false-detection
probability, pattern 0 is uncritical (the tricky one is pattern 1).


Cheers,
Zefir

Atheros ETSI DFS pattern

[voncken]

In the file drivers/net/wireless/ath/dfs_pattern_detector.c we can found the
ETSI pattern definition.

In this definition we can found 7 patterns (0 to 6).

The ETSI standard EN 301893 Annex D only specifies 6 patterns. Only the
pattern 1 to 6 defined in the ath dfs pattern match with the ETSI standard.

Why the pattern 0 is defined?

Is it possible to remove this pattern and keep compliant with the ETSI
standard?

Thanks for your help.

Cedric.

Re: [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting

[Kalle Valo]

jes.soren...@redhat.com writes:

> From: Jes Sorensen 
>
> Hi,
>
> This patch works around the issue with 8192eu and 8723bu devices not
> being able to reconnect. It is still not clear why this fails, and
> looking at rtlwifi it does issue the command for 8192ee and 8723be
> devices.
>
> Until we have a better idea of what is going on, I have commented out
> the offending code. I prefer not deleting it until we have a better
> understanding of why this is causing issues.
>
> Credits to Barry Day for tracking down and isolating the issue.
>
> Kalle, not sure if this can make it to 4.9, but if it's possible it
> would be ideal since this is causing real issues in the field.

For 4.9 this is too late, sorry. I'll queue this to 4.10.

-- 
Kalle Valo

[PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up

[Mohammed Shafi Shajakhan]

From: Mohammed Shafi Shajakhan 

With maximum number of vap's configured in a two radio supported
systems of ~256 Mb RAM, doing a continuous wifi down/up and
intermittent traffic streaming from the connected stations results
in failure to allocate contiguous memory for tx buffers. This results
in the disappearance of all VAP's and a manual reboot is needed as
this is not a crash (or) OOM(for OOM killer to be invoked). To address
this allocate contiguous memory for tx buffers one time and re-use them
until the modules are unloaded but this results in a slight increase in
memory footprint of ath10k when the wifi is down, but the modules are
still loaded. Also as of now we use a separate bool 'tx_mem_allocated'
to keep track of the one time memory allocation, as we cannot come up
with something like 'ath10k_tx_{register,unregister}' before
'ath10k_probe_fw' is called as 'ath10k_htt_tx_alloc_cont_frag_desc'
memory allocation is dependent on the hw_param 'continuous_frag_desc'

a) memory footprint of ath10k without the change

lsmod | grep ath10k
ath10k_core   414498  1 ath10k_pci
ath10k_pci 38236  0

b) memory footprint of ath10k with the change

ath10k_core   414980  1 ath10k_pci
ath10k_pci 38236  0

Memory Failure Call trace:

hostapd: page allocation failure: order:6, mode:0xd0
 [] (__dma_alloc_buffer.isra.23) from
[] (__alloc_remap_buffer.isra.26+0x14/0xb8)
[] (__alloc_remap_buffer.isra.26) from
[] (__dma_alloc+0x224/0x2b8)
[] (__dma_alloc) from []
(arm_dma_alloc+0x84/0x90)
[] (arm_dma_alloc) from []
(ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
[] (ath10k_htt_tx_alloc [ath10k_core]) from
[] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
[] (ath10k_core_start [ath10k_core]) from
[] (ath10k_start+0xbc/0x56c [ath10k_core])
[] (ath10k_start [ath10k_core]) from
[] (drv_start+0x40/0x5c [mac80211])
[] (drv_start [mac80211]) from []
(ieee80211_do_open+0x170/0x82c [mac80211])
[] (ieee80211_do_open [mac80211]) from
[] (__dev_open+0xa0/0xf4)
[21053.491752] Normal: 641*4kB (UEMR) 505*8kB (UEMR) 330*16kB (UEMR)
126*32kB (UEMR) 762*64kB (UEMR) 237*128kB (UEMR) 1*256kB (M) 0*512kB
0*1024kB 0*2048kB 0*4096kB = 95276kB

Signed-off-by: Mohammed Shafi Shajakhan 
---
 drivers/net/wireless/ath/ath10k/core.c   |  5 +--
 drivers/net/wireless/ath/ath10k/htt.h|  6 +++-
 drivers/net/wireless/ath/ath10k/htt_tx.c | 54 +---
 3 files changed, 51 insertions(+), 14 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index 5bc6847..f7ea4de 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1857,7 +1857,7 @@ int ath10k_core_start(struct ath10k *ar, enum 
ath10k_firmware_mode mode,
goto err_wmi_detach;
}
 
-   status = ath10k_htt_tx_alloc(>htt);
+   status = ath10k_htt_tx_start(>htt);
if (status) {
ath10k_err(ar, "failed to alloc htt tx: %d\n", status);
goto err_wmi_detach;
@@ -2052,7 +2052,7 @@ void ath10k_core_stop(struct ath10k *ar)
ath10k_wait_for_suspend(ar, WMI_PDEV_SUSPEND_AND_DISABLE_INTR);
 
ath10k_hif_stop(ar);
-   ath10k_htt_tx_free(>htt);
+   ath10k_htt_tx_stop(>htt);
ath10k_htt_rx_free(>htt);
ath10k_wmi_detach(ar);
 }
@@ -2385,6 +2385,7 @@ void ath10k_core_destroy(struct ath10k *ar)
destroy_workqueue(ar->workqueue_aux);
 
ath10k_debug_destroy(ar);
+   ath10k_htt_tx_destroy(>htt);
ath10k_wmi_free_host_mem(ar);
ath10k_mac_destroy(ar);
 }
diff --git a/drivers/net/wireless/ath/ath10k/htt.h 
b/drivers/net/wireless/ath/ath10k/htt.h
index 0d2ed09..96bf7bf 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1692,6 +1692,8 @@ struct ath10k_htt {
enum htt_tx_mode_switch_mode mode;
enum htt_q_depth_type type;
} tx_q_state;
+
+   bool tx_mem_allocated;
 };
 
 #define RX_HTT_HDR_STATUS_LEN 64
@@ -1754,7 +1756,9 @@ struct htt_rx_desc {
 int ath10k_htt_init(struct ath10k *ar);
 int ath10k_htt_setup(struct ath10k_htt *htt);
 
-int ath10k_htt_tx_alloc(struct ath10k_htt *htt);
+int ath10k_htt_tx_start(struct ath10k_htt *htt);
+void ath10k_htt_tx_stop(struct ath10k_htt *htt);
+void ath10k_htt_tx_destroy(struct ath10k_htt *htt);
 void ath10k_htt_tx_free(struct ath10k_htt *htt);
 
 int ath10k_htt_rx_alloc(struct ath10k_htt *htt);
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c 
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index ccbc8c03..27e49db 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -350,21 +350,15 @@ static int ath10k_htt_tx_alloc_txdone_fifo(struct 
ath10k_htt *htt)
return ret;
 }
 
-int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
+static int ath10k_htt_tx_alloc_buf(struct ath10k_htt *htt)
 {
  

Re: [RFC V2 1/5] nl80211: allow reporting RTT information in scan results

[Arend Van Spriel]

On 30-11-2016 9:22, Johannes Berg wrote:
> On Mon, 2016-11-28 at 21:07 +0100, Arend Van Spriel wrote:
>>  
>> I was wondering about the meaning of the term "parent_bssid". Given
>> your remark it means something else than my guess. I actually meant
>> the distance to the AP indicated by this BSS. Our gscan code obtains
>> the gscan results from firmware and in that API it has RTT info. 
> 
> Oh, ok. Right, that's unrelated to the parent_bssid.
> 
> I do wonder how it'd even be possible to *determine* this though?
> Perhaps by the ACK timing, assuming it's precise on the AP?

There is 11v, 11mc, and some proprietary flavor we call 1-way TOF.
However, I do not expect those measurements to be done during the scan
procedure as it would affect duration of the whole scan exercise.

>> However, recent testing revealed those fields are always coming up
>> with zero values :-(
> 
> Heh :-)
> 
>> So right now I am not sure if we need this extension.
> 
> FWIW, we don't seem to have it.

I will drop this in next RFC round.

Regards,
Arend

Re: [RFC V2 1/5] nl80211: allow reporting RTT information in scan results

[Johannes Berg]

On Mon, 2016-11-28 at 21:07 +0100, Arend Van Spriel wrote:
> 
> I was wondering about the meaning of the term "parent_bssid". Given
> your remark it means something else than my guess. I actually meant
> the distance to the AP indicated by this BSS. Our gscan code obtains
> the gscan results from firmware and in that API it has RTT info. 

Oh, ok. Right, that's unrelated to the parent_bssid.

I do wonder how it'd even be possible to *determine* this though?
Perhaps by the ACK timing, assuming it's precise on the AP?

> However, recent testing revealed those fields are always coming up
> with zero values :-(

Heh :-)

> So right now I am not sure if we need this extension.

FWIW, we don't seem to have it.

johannes