* Re: ath10k: Fix soft lockup during firmware crash/hw-restart
From: Mohammed Shafi Shajakhan @ 2016-12-01 6:06 UTC (permalink / raw)
To: Ben Greear; +Cc: Mohammed Shafi Shajakhan, ath10k, linux-wireless
In-Reply-To: <1a44a3e9-3d67-30a5-0325-a65003ebe1fc@candelatech.com>
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 <mohammed@qti.qualcomm.com>
> >
> >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 <mohammed@qti.qualcomm.com>
> >---
> >[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 <greearb@candelatech.com>
> Candela Technologies Inc http://www.candelatech.com
>
^ permalink raw reply
* Re: [PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up
From: Mohammed Shafi Shajakhan @ 2016-12-01 6:50 UTC (permalink / raw)
To: Adrian Chadd
Cc: Mohammed Shafi Shajakhan, ath10k@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <CAJ-VmokhmPy7Bb++wRb2h5H-_g3Vu2jqLqeoh9kiP0tGdC1_vA@mail.gmail.com>
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(&htt->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 <<ath10k_core_probe_fw>>
ret = ath10k_core_start(ar, ATH10K_FIRMWARE_MODE_NORMAL,
5 4471 mac.c <<ath10k_start>>
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
> <mohammed@qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >
> > 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
> > [<c021f150>] (__dma_alloc_buffer.isra.23) from
> > [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8)
> > [<c021f23c>] (__alloc_remap_buffer.isra.26) from
> > [<c021f664>] (__dma_alloc+0x224/0x2b8)
> > [<c021f664>] (__dma_alloc) from [<c021f810>]
> > (arm_dma_alloc+0x84/0x90)
> > [<c021f810>] (arm_dma_alloc) from [<bf954764>]
> > (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
> > [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from
> > [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
> > [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from
> > [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core])
> > [<bf947eec>] (ath10k_start [ath10k_core]) from
> > [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211])
> > [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>]
> > (ieee80211_do_open+0x170/0x82c [mac80211])
> > [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from
> > [<c056afc8>] (__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 <mohammed@qti.qualcomm.com>
> > ---
> > 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(&ar->htt);
> > + status = ath10k_htt_tx_start(&ar->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(&ar->htt);
> > + ath10k_htt_tx_stop(&ar->htt);
> > ath10k_htt_rx_free(&ar->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(&ar->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)
> > {
> > struct ath10k *ar = htt->ar;
> > int ret;
> >
> > - ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt tx max num pending tx %d\n",
> > - htt->max_num_pending_tx);
> > -
> > - spin_lock_init(&htt->tx_lock);
> > - idr_init(&htt->pending_tx);
> > -
> > ret = ath10k_htt_tx_alloc_cont_txbuf(htt);
> > if (ret) {
> > ath10k_err(ar, "failed to alloc cont tx buffer: %d\n", ret);
> > - goto free_idr_pending_tx;
> > + return ret;
> > }
> >
> > ret = ath10k_htt_tx_alloc_cont_frag_desc(htt);
> > @@ -396,6 +390,31 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
> > free_txbuf:
> > ath10k_htt_tx_free_cont_txbuf(htt);
> >
> > + return ret;
> > +}
> > +
> > +int ath10k_htt_tx_start(struct ath10k_htt *htt)
> > +{
> > + struct ath10k *ar = htt->ar;
> > + int ret;
> > +
> > + ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt tx max num pending tx %d\n",
> > + htt->max_num_pending_tx);
> > +
> > + spin_lock_init(&htt->tx_lock);
> > + idr_init(&htt->pending_tx);
> > +
> > + if (htt->tx_mem_allocated)
> > + return 0;
> > +
> > + ret = ath10k_htt_tx_alloc_buf(htt);
> > + if (ret)
> > + goto free_idr_pending_tx;
> > +
> > + htt->tx_mem_allocated = true;
> > +
> > + return 0;
> > +
> > free_idr_pending_tx:
> > idr_destroy(&htt->pending_tx);
> >
> > @@ -418,15 +437,28 @@ static int ath10k_htt_tx_clean_up_pending(int msdu_id, void *skb, void *ctx)
> > return 0;
> > }
> >
> > -void ath10k_htt_tx_free(struct ath10k_htt *htt)
> > +void ath10k_htt_tx_destroy(struct ath10k_htt *htt)
> > {
> > - idr_for_each(&htt->pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
> > - idr_destroy(&htt->pending_tx);
> > + if (!htt->tx_mem_allocated)
> > + return;
> >
> > ath10k_htt_tx_free_cont_txbuf(htt);
> > ath10k_htt_tx_free_txq(htt);
> > ath10k_htt_tx_free_cont_frag_desc(htt);
> > ath10k_htt_tx_free_txdone_fifo(htt);
> > + htt->tx_mem_allocated = false;
> > +}
> > +
> > +void ath10k_htt_tx_stop(struct ath10k_htt *htt)
> > +{
> > + idr_for_each(&htt->pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
> > + idr_destroy(&htt->pending_tx);
> > +}
> > +
> > +void ath10k_htt_tx_free(struct ath10k_htt *htt)
> > +{
> > + ath10k_htt_tx_stop(htt);
> > + ath10k_htt_tx_destroy(htt);
> > }
> >
> > void ath10k_htt_htc_tx_complete(struct ath10k *ar, struct sk_buff *skb)
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > ath10k mailing list
> > ath10k@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Mohammed Shafi Shajakhan @ 2016-12-01 7:09 UTC (permalink / raw)
To: Benjamin Morgan; +Cc: linux-wireless, ath10k, lede-dev, agreen
In-Reply-To: <583DD564.8040704@cococorp.com>
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 0000:01:00.0 (0000 -> 0002)
> [ 9.902622] ath10k_pci 0000:01:00.0: pci irq legacy oper_irq_mode
> 1 irq_mode 0 reset_mode 0
> [ 10.123734] ath10k_pci 0000:01:00.0: Direct firmware load for
> ath10k/pre-cal-pci-0000:01:00.0.bin failed with error -2
> [ 10.134620] ath10k_pci 0000:01:00.0: Falling back to user helper
> [ 10.287680] firmware ath10k!pre-cal-pci-0000:01:00.0.bin:
> firmware_loading_store: map pages failed
> [ 10.622789] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 10.632184] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [ 10.645231] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
> api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [ 10.655660] ath10k_pci 0000:01:00.0: Direct firmware load for
> ath10k/QCA988X/hw2.0/board-2.bin failed with error -2
> [ 10.666264] ath10k_pci 0000: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 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 12.155224] ath10k_pci 0000: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 0000:01:00.0: firmware crashed! (uuid
> 2bab5ee9-08ff-4a17-95b1-636d212acebc)
> [245.493020] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [245.502384] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [245.515436] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api
> 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [245.525812] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [245.533232] ath10k_pci 0000: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 0000:01:00.0: firmware register dump:
> [245.550633] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009A4577 0x00955B31
> [245.558676] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
> 0x00000002 0x00439E98
> [245.566715] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [245.574749] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x009A3518 0x009A3526
> [245.582793] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [245.590836] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [245.598882] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
> 0x00400000 0xC09A4577
> [245.606923] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
> 0x0044110C 0x00442074
> [245.614955] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> 0x0044110C 0x00407120
> [245.623000] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> 0x0040AC14 0x00001580
> [245.631043] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
> 0x009C643C 0x004436CC
> [245.639086] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
> 0x004208FC 0x00439E4C
> [245.647129] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
> 0x004208FC 0x00425404
> [245.655170] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
> 0x00424FE8 0x00000002
> [245.663198] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x00000004 0x004039D0
> [245.767023] ieee80211 phy0: Hardware restart was requested
> [245.772655] ath10k_pci 0000:01:00.0: failed to synchronize monitor
> vdev 1 stop: -143
> [245.780542] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
>
> With wpa_supplicant turned off:
>
> Station Dump on Station A before ping:
> Station 18:a6:f7:26:0f:21 (on wlan0)
> inactive time:60 ms
> rx bytes:3874
> rx packets:67
> tx bytes:707
> tx packets:7
> tx retries:0
> tx failed:1
> rx drop misc:3
> signal: -14 dBm
> signal avg:-14 dBm
> Toffset:18446744073684250999 us
> tx bitrate:6.0 MBit/s
> rx bitrate:6.0 MBit/s
> rx duration:1312 us
> mesh llid:24953
> mesh plid:59412
> 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:no
> TDLS peer:no
> DTIM period:2
> beacon interval:1000
> short slot time:yes
> connected time:33 seconds
>
> Firmware crash on Station A (10.230.5.41)
> [ 1040.984599] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
> 42d4f6dc-0e89-4505-aefb-58cbb70d0dce)
> [ 1040.993732] ath10k_pci 0000:01:00.0: qca988x hw2.0 target
> 0x4100016c chip_id 0x043202ff sub 0000:0000
> [ 1041.003100] ath10k_pci 0000:01:00.0: kconfig debug 0 debugfs 1
> tracing 0 dfs 1 testmode 1
> [ 1041.016144] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54
> api 5 features no-p2p,raw-mode,mfp crc32 9d340dd9
> [ 1041.026523] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
> crc32 bebc7c08
> [ 1041.033940] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op
> 2 cal file max-sta 128 raw 0 hwcrypto 1
> [ 1041.045593] ath10k_pci 0000:01:00.0: firmware register dump:
> [ 1041.051336] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
> 0x009A4577 0x00955B31
> [ 1041.059383] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
> 0x00000001 0x00435354
> [ 1041.067424] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
> 0x00407120 0x004436CC
> [ 1041.075463] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
> 0x009A43A0 0x009A43DE
> [ 1041.083490] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
> 0x00000000 0x00000000
> [ 1041.091535] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
> 0x0040AC60 0x0040AC09
> [ 1041.099579] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
> 0x00955A00 0xC09A4577
> [ 1041.107622] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
> 0x0044110C 0x00442074
> [ 1041.115661] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
> 0x0044110C 0x00407120
> [ 1041.123689] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
> 0x0040AC10 0x00001580
> [ 1041.131733] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
> 0x009C643C 0x004436CC
> [ 1041.139777] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
> 0x004208FC 0x00439E4C
> [ 1041.147820] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
> 0x004208FC 0x00425758
> [ 1041.155860] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
> 0x00424FE8 0x00000002
> [ 1041.163888] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
> 0x00000004 0x004039D0
> [ 1041.267025] ieee80211 phy0: Hardware restart was requested
> [ 1041.272656] ath10k_pci 0000:01:00.0: failed to synchronize
> monitor vdev 1 stop: -143
> [ 1041.280545] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
>
>
> Thanks in advance for your time and help,
>
> ~Benjamin
>
^ permalink raw reply
* Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
From: Valo, Kalle @ 2016-12-01 10:17 UTC (permalink / raw)
To: Bjorn Andersson
Cc: k.eugene.e@gmail.com, Andy Gross, wcn36xx@lists.infradead.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
In-Reply-To: <874m2otenv.fsf@kamboji.qca.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>
>> "Valo, Kalle" <kvalo@qca.qualcomm.com> writes:
>>
>>> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>>>
>>>> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
>>>>
>>>>> Bjorn Andersson <bjorn.andersson@linaro.org> 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.
>>>>> >=20
>>>>> > Fixes: e8b123e60084 ("soc: qcom: smem_state: Add stubs for disabled=
smem_state")
>>>>> > Acked-by: Andy Gross <andy.gross@linaro.org>
>>>>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>>>=20
>>>>> For some reason this fails to compile now. Can you take a look, pleas=
e?
>>>>>=20
>>>>> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wc=
n36xx.ko] undefined!
>>>>> make[1]: *** [__modpost] Error 1
>>>>> make: *** [modules] Error 2
>>>>>=20
>>>>> 5 patches set to Changes Requested.
>>>>>=20
>>>>> 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=
=3Dn,
>>>> QCOM_WCNSS_CTRL=3Dn and WCN36XX=3Dy) 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 pen=
ding
> head: 1ea16a1c457939b4564643f7637d5cc639a8d3b7
> commit: 5eb09c672b01460804fd49b1c9cc7d1072a102f0 [96/99] wcn36xx: Transit=
ion 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=3Di386=20
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn3=
6xx.ko] undefined!
Bjorn mentioned me on IRC that this is because of a missing commit in my
tree:
daa6e41ce2b5 soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API
When I pull the tag below (which contains the above commit) wcn36xx
builds fine for me:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-dr=
ivers-for-4.10
Andy, is it ok if I pull your tag also to my ath.git tree to solve the
wcn36xx build problem? My trees go to Linus via net-next and I don't
know when exactly Dave would send a pull request to Linus, before or
after the arm trees, but as the tag seems to contain only few patches I
hope it doesn't matter.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [1/1] rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting
From: Kalle Valo @ 2016-12-01 10:20 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless, briselec
In-Reply-To: <20161129235902.11882-2-Jes.Sorensen@redhat.com>
Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and
> 8723bu devices not being able to reconnect.
>
> Reported-by: Barry Day <briselec@gmail.com>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Like discussed I'll add:
Cc: <stable@vger.kernel.org> #4.8+
--
https://patchwork.kernel.org/patch/9453251/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k: feed only active spectral / dfs-detector
From: Kalle Valo @ 2016-12-01 10:29 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, michal.kazior, benjamin
In-Reply-To: <1479812709-18875-1-git-send-email-zefir.kurtisi@neratec.com>
Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> Radar pulse and spectral scan reports are provided by the HW
> with the ATH9K_RXERR_PHY flag set. Those are forwarded to
> the dfs-detector and spectral module for further processing.
>
> For some older chips, the pre-conditions checked in those
> modules are ambiguous, since ATH9K_PHYERR_RADAR is used to
> tag both types. As a result, spectral frames are fed into
> the dfs-detector and vice versa.
>
> This could lead to a false radar detection on a non-DFS
> channel (which is uncritical), but more relevant it causes
> useless CPU load for processing invalid frames.
>
> This commit ensures that the dfs-detector and spectral
> collector are only fed when they are active.
>
> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Patch applied to ath-next branch of ath.git, thanks.
87fedb974e0c ath9k: feed only active spectral / dfs-detector
--
https://patchwork.kernel.org/patch/9440817/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Fix soft lockup during firmware crash/hw-restart
From: Valo, Kalle @ 2016-12-01 10:34 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: Ben Greear, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org,
Shajakhan, Mohammed Shafi (Mohammed Shafi)
In-Reply-To: <20161201060612.GA8611@atheros-ThinkPad-T61>
Mohammed Shafi Shajakhan <mohammed@codeaurora.org> writes:
> 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 appl=
ied?
>
> @Kalle,
>
> [shafi] kindly suggest. If i am not wrong this is only needed for 4.9
Correct, commit 3c97f5de1f28 went to 4.9-rc1, it was not in 4.8. I'll
add CC stable to the commit log.
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart
From: Valo, Kalle @ 2016-12-01 10:35 UTC (permalink / raw)
To: Shajakhan, Mohammed Shafi (Mohammed Shafi)
Cc: ath10k@lists.infradead.org, mohammed@codeaurora.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1480483769-17693-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 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 <mohammed@qti.qualcomm.com>
> ---
> [v2 Added Fixes ]
I'll also add:
Cc: <stable@vger.kernel.org> # v4.9
--=20
Kalle Valo=
^ permalink raw reply
* Re: ath10k: fix TLV set regdomain command
From: Kalle Valo @ 2016-12-01 11:09 UTC (permalink / raw)
To: Erik Stromdahl; +Cc: linux-wireless, ath10k, Erik Stromdahl
In-Reply-To: <1480275440-9919-1-git-send-email-erik.stromdahl@gmail.com>
Erik Stromdahl <erik.stromdahl@gmail.com> wrote:
> There is a typo bug in the current implementation of
> ath10k_wmi_tlv_op_gen_pdev_set_rd.
> The conformance test limits are not set up properly.
>
> The two arguments ctl2g and ctl5g were not used at all.
> Instead, the regdomain arguments rd2g and rd5g were used
> for the ctl settings as well.
>
> Signed-off-by: Erik Stromdahl <erik.stromdahl@gmail.com>
Patch applied to ath-next branch of ath.git, thanks.
4e322f7db51a ath10k: fix TLV set regdomain command
--
https://patchwork.kernel.org/patch/9448885/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart
From: Mohammed Shafi Shajakhan @ 2016-12-01 11:12 UTC (permalink / raw)
To: Valo, Kalle
Cc: Shajakhan, Mohammed Shafi (Mohammed Shafi),
ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <87inr4rl6t.fsf@kamboji.qca.qualcomm.com>
On Thu, Dec 01, 2016 at 10:35:38AM +0000, Valo, Kalle wrote:
> Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> writes:
>
> > From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >
> > 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 <mohammed@qti.qualcomm.com>
> > ---
> > [v2 Added Fixes ]
>
> I'll also add:
>
> Cc: <stable@vger.kernel.org> # v4.9
>
thank you Kalle.
regards,
shafi
^ permalink raw reply
* Re: [v2] ath10k: Fix soft lockup during firmware crash/hw-restart
From: Kalle Valo @ 2016-12-01 11:13 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1480483769-17693-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 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 <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
c2cac2f74ab4 ath10k: fix soft lockup during firmware crash/hw-restart
--
https://patchwork.kernel.org/patch/9453609/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Fix Tx DMA alloc failure during continuous wifi down/up
From: Kalle Valo @ 2016-12-01 11:14 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1480499414-19543-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 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
> [<c021f150>] (__dma_alloc_buffer.isra.23) from
> [<c021f23c>] (__alloc_remap_buffer.isra.26+0x14/0xb8)
> [<c021f23c>] (__alloc_remap_buffer.isra.26) from
> [<c021f664>] (__dma_alloc+0x224/0x2b8)
> [<c021f664>] (__dma_alloc) from [<c021f810>]
> (arm_dma_alloc+0x84/0x90)
> [<c021f810>] (arm_dma_alloc) from [<bf954764>]
> (ath10k_htt_tx_alloc+0xe0/0x2e4 [ath10k_core])
> [<bf954764>] (ath10k_htt_tx_alloc [ath10k_core]) from
> [<bf94e6ac>] (ath10k_core_start+0x538/0xcf8 [ath10k_core])
> [<bf94e6ac>] (ath10k_core_start [ath10k_core]) from
> [<bf947eec>] (ath10k_start+0xbc/0x56c [ath10k_core])
> [<bf947eec>] (ath10k_start [ath10k_core]) from
> [<bf8a7a04>] (drv_start+0x40/0x5c [mac80211])
> [<bf8a7a04>] (drv_start [mac80211]) from [<bf8b7cf8>]
> (ieee80211_do_open+0x170/0x82c [mac80211])
> [<bf8b7cf8>] (ieee80211_do_open [mac80211]) from
> [<c056afc8>] (__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 <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
9ec34a86195a ath10k: fix Tx DMA alloc failure during continuous wifi down/up
--
https://patchwork.kernel.org/patch/9453947/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL.
From: Kalle Valo @ 2016-12-01 11:16 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k, Ben Greear, linux-wireless
In-Reply-To: <1480456828-13735-1-git-send-email-greearb@candelatech.com>
Ben Greear <greearb@candelatech.com> wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> These memory chunks are often used as 'swap' by the NIC,
> so it will be both reading and writing to these areas.
>
> This seems to fix errors like this on my x86-64 machine:
>
> kernel: DMAR: DMAR:[DMA Write] Request device [05:00.0] fault addr ff5de000
> DMAR:[fault reason 05] PTE Write access is not set
>
> Tested-by: Marek Behun <kabel@blackhole.sk>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> index 9fcb249..c68278a 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.c
> +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> @@ -4558,7 +4558,7 @@ static int ath10k_wmi_alloc_chunk(struct ath10k *ar, u32 req_id,
> if (!num_units)
> return -ENOMEM;
>
> - paddr = dma_map_single(ar->dev, vaddr, pool_size, DMA_TO_DEVICE);
> + paddr = dma_map_single(ar->dev, vaddr, pool_size, DMA_BIDIRECTIONAL);
> if (dma_mapping_error(ar->dev, paddr)) {
> kfree(vaddr);
> return -ENOMEM;
Patch applied to ath-next branch of ath.git, thanks.
43ca92d380a8 ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL
--
https://patchwork.kernel.org/patch/9453173/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wireless: ath: ath9k: constify ath_bus_ops structure
From: Kalle Valo @ 2016-12-01 11:18 UTC (permalink / raw)
To: Bhumika Goyal
Cc: julia.lawall, ath9k-devel, kvalo, linux-wireless, ath9k-devel,
netdev, linux-kernel, Bhumika Goyal
In-Reply-To: <1480266206-26732-1-git-send-email-bhumirks@gmail.com>
Bhumika Goyal <bhumirks@gmail.com> wrote:
> Declare the structure ath_bus_ops as const as it is only passed as an
> argument to the function ath9k_init_device. This argument is of type
> const struct ath_bus_ops *, so ath_bus_ops structures with this property
> can be declared as const.
> Done using Coccinelle:
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct ath_bus_ops i@p = {...};
>
> @ok1@
> identifier r1.i;
> position p;
> expression e1,e2;
> @@
> ath9k_init_device(e1,e2,&i@p)
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> static
> +const
> struct ath_bus_ops i={...};
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct ath_bus_ops i;
>
> File size before:
> text data bss dec hex filename
> 1295 232 0 1527 5f7 ath/ath9k/ahb.o
>
> File size after:
> text data bss dec hex filename
> 1359 176 0 1535 5ff ath/ath9k/ahb.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Patch applied to ath-next branch of ath.git, thanks.
8ca5a6078d6d ath9k: constify ath_bus_ops structure
--
https://patchwork.kernel.org/patch/9448851/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath9k_htc: don't use HZ for usb msg timeouts
From: Kalle Valo @ 2016-12-01 11:20 UTC (permalink / raw)
To: Anthony Romano; +Cc: linux-wireless, ath9k-devel, ath9k-devel
In-Reply-To: <20161128042757.8609-1-anthony.romano@coreos.com>
Anthony Romano <anthony.romano@coreos.com> wrote:
> 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.
>
> Signed-off-by: Anthony Romano <anthony.romano@coreos.com>
> Acked-by: Oleksij Rempel <linux@rempel-privat.de>
Patch applied to ath-next branch of ath.git, thanks.
982a6151f6f1 ath9k_htc: don't use HZ for usb msg timeouts
--
https://patchwork.kernel.org/patch/9449097/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/4] wil6210: delay remain on channel when scan is active
From: Kalle Valo @ 2016-12-01 11:21 UTC (permalink / raw)
To: Maya Erez; +Cc: Kalle Valo, Lior David, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1480333743-7306-2-git-send-email-qca_merez@qca.qualcomm.com>
Maya Erez <qca_merez@qca.qualcomm.com> wrote:
> From: Lior David <qca_liord@qca.qualcomm.com>
>
> Currently it was possible to call remain_on_channel(ROC)
> while scan was active and this caused a crash in the FW.
> In order to fix this problem and make the behavior
> consistent with other drivers, queue the ROC in case
> a scan is active and try it again when scan is done.
> As part of the fix, clean up some locking issues and
> return error if scan is called while ROC is active.
>
> Signed-off-by: Lior David <qca_liord@qca.qualcomm.com>
> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
4 patches applied to ath-next branch of ath.git, thanks.
bb6743f7c2ff wil6210: delay remain on channel when scan is active
1db226ffe1c2 wil6210: validate wil_pmc_alloc parameters
615788200557 wil6210: add debugfs blobs for UCODE code and data
8ae5d62c7eba wil6210: align to latest auto generated wmi.h
--
https://patchwork.kernel.org/patch/9449393/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath5k: drop duplicate header vmalloc.h
From: Kalle Valo @ 2016-12-01 11:23 UTC (permalink / raw)
To: Geliang Tang
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Kalle Valo,
Geliang Tang, linux-wireless, netdev, linux-kernel
In-Reply-To: <15299de49216a2360976ca37ff774cae9d27d88b.1479991297.git.geliangtang@gmail.com>
Geliang Tang <geliangtang@gmail.com> wrote:
> Drop duplicate header vmalloc.h from ath5k/debug.c.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Patch applied to ath-next branch of ath.git, thanks.
384abd33d5d5 ath5k: drop duplicate header vmalloc.h
--
https://patchwork.kernel.org/patch/9445537/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mac80211: fix Tx BA session stuck issue during sw scanning
From: Chris Chiu @ 2016-12-01 11:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux
In-Reply-To: <1480424369.10012.6.camel@sipsolutions.net>
On Tue, Nov 29, 2016 at 8:59 PM, Johannes Berg
<johannes@sipsolutions.net> 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 > 30000 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?
>
Actually it will finish scan eventually and back to SCAN_DECISION
state but almost 20~30 seconds elapsed. The local->scanning should be
cleared after all channels been scanned. However, from the debug
messages I added in ieee80211_iface_work(), it still returns when
check local->scanning and the DELBA still has no chance to be
transferred then stuck again at the next scan state machine. Supposed
to be another scan request issued but I don't know who's the killer.
Except to find who issue the next scan request, BA session have no
chance to reset in this long scan period (>20s) still need to be taken
care.
>> + test_and_clear_bit(SCAN_SUSPEND_SCANNING, &local->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, &local->scanning);
>
> Why are you using the non-atomic version here, vs. the atomic one
> above?
>
You're right. I just want to clear_bit and set_bit in this case, sorry
for that confusing. Or any better suggestion?
> johannes
^ permalink raw reply
* Re: [1/1] rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting
From: Kalle Valo @ 2016-12-01 12:24 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless, briselec
In-Reply-To: <20161129235902.11882-2-Jes.Sorensen@redhat.com>
Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> The H2C MEDIA_STATUS_RPT command for some reason causes 8192eu and
> 8723bu devices not being able to reconnect.
>
> Reported-by: Barry Day <briselec@gmail.com>
> Cc: <stable@vger.kernel.org> #4.8+
> Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
c59f13bbead4 rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting
--
https://patchwork.kernel.org/patch/9453251/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH 23/39] Annotate hardware config module parameters in drivers/net/wireless/
From: David Howells @ 2016-12-01 12:32 UTC (permalink / raw)
To: linux-kernel
Cc: gnomes, minyard, netdev, linux-wireless, dhowells,
linux-security-module, keyrings, Kalle Valo
In-Reply-To: <148059537897.31612.9461043954611464597.stgit@warthog.procyon.org.uk>
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/net/wireless/.
Suggested-by: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Kalle Valo <kvalo@codeaurora.org>
cc: linux-wireless@vger.kernel.org
cc: netdev@vger.kernel.org
---
drivers/net/wireless/cisco/airo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/cisco/airo.c b/drivers/net/wireless/cisco/airo.c
index 69b826d229c5..53d43c93a284 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -246,8 +246,8 @@ MODULE_DESCRIPTION("Support for Cisco/Aironet 802.11 wireless ethernet cards. "
"Direct support for ISA/PCI/MPI cards and support for PCMCIA when used with airo_cs.");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_SUPPORTED_DEVICE("Aironet 4500, 4800 and Cisco 340/350");
-module_param_array(io, int, NULL, 0);
-module_param_array(irq, int, NULL, 0);
+module_param_hw_array(io, int, ioport, NULL, 0);
+module_param_hw_array(irq, int, irq, NULL, 0);
module_param_array(rates, int, NULL, 0);
module_param_array(ssids, charp, NULL, 0);
module_param(auto_wep, int, 0);
^ permalink raw reply related
* mac802_hwsim: libnl does not detect genl hwsim protocol in default ns
From: Benjamin Beichler @ 2016-12-01 12:37 UTC (permalink / raw)
To: linux-wireless
Hi,
I got a strange problem with newer kernel (post 4.8 stable) with hwsim.
Our current code works like this:
modprobe mac80211_hwsim radios=10
./costum_wmediumd
This will create all hwsim_interfaces in the first hwsim "netgroup"
within the default network namespace. But the code to lookup the genl
"MAC80211_HWSIM" protocol fails. Moreover some calls fails, other not ...
//family = genl_ctrl_search_by_name(cache, "MAC80211_HWSIM"); -->
fails directly (return NULL)
int hwsim_netlink_id = genl_ctrl_resolve(sock,"MAC80211_HWSIM");
if (hwsim_netlink_id == 0)
{
printf("Family MAC80211_HWSIM ID not found\n");
exit(EXIT_FAILURE);
}
printf("Family ID found (%d), search for structure
\n\n",hwsim_netlink_id);
family = genl_ctrl_search(cache, hwsim_netlink_id);
if (family == NULL)
{
printf("Family MAC80211_HWSIM family not found\n");
exit(EXIT_FAILURE);
}
this will output:
"Family ID found (28), seatch for structure
Family MAC80211_HWSIM family not found"
But when I start the code in some network namespace, it works (but works
with no interfaces, as they stay in default network namespace). Of
course a workaround is easy, but it definitely breaks some legacy code,
working the same way. I reviewed the recent changes of hwsim regarding
namespaces, but I found no bug. The initial hwsim-devices are created in
netgroup 0 and the default namespace and I don't see any differentiation
of the netlink protocol registration, which depends on network
namespaces. Maybe there is a bug in libnl, but currently I have no Idea,
how to track down the issue.
Any suggestions ?
^ permalink raw reply
* [PATCH] mwifiex: use module_*_driver helper macros
From: Amitkumar Karwar @ 2016-12-01 13:08 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
After user_rmmod global flag removal, *_init_module() and
*_cleanup_module() have become just a wrapper functions.
We will get rid of them with the help of module_*_driver() macros.
For pcie, existing ".init_if" handler has same name as what
module_pcie_driver() macro will create. Let's rename it to
avoid conflict.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 47 ++++-------------------------
drivers/net/wireless/marvell/mwifiex/sdio.c | 29 +-----------------
drivers/net/wireless/marvell/mwifiex/usb.c | 35 +--------------------
3 files changed, 8 insertions(+), 103 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 079bb09..462f014 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -2754,7 +2754,7 @@ static void mwifiex_pcie_device_dump(struct mwifiex_adapter *adapter)
* - Allocate command response ring buffer
* - Allocate sleep cookie buffer
*/
-static int mwifiex_pcie_init(struct mwifiex_adapter *adapter)
+static int mwifiex_init_pcie(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
int ret;
@@ -2863,7 +2863,7 @@ static int mwifiex_pcie_init(struct mwifiex_adapter *adapter)
* - Command response ring buffer
* - Sleep cookie buffer
*/
-static void mwifiex_pcie_cleanup(struct mwifiex_adapter *adapter)
+static void mwifiex_cleanup_pcie(struct mwifiex_adapter *adapter)
{
struct pcie_service_card *card = adapter->card;
struct pci_dev *pdev = card->dev;
@@ -3063,7 +3063,7 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
* - Allocate event BD ring buffers
* - Allocate command response ring buffer
* - Allocate sleep cookie buffer
- * Part of mwifiex_pcie_init(), not reset the PCIE registers
+ * Part of mwifiex_init_pcie(), not reset the PCIE registers
*/
static void mwifiex_pcie_up_dev(struct mwifiex_adapter *adapter)
{
@@ -3146,8 +3146,8 @@ static void mwifiex_pcie_down_dev(struct mwifiex_adapter *adapter)
}
static struct mwifiex_if_ops pcie_ops = {
- .init_if = mwifiex_pcie_init,
- .cleanup_if = mwifiex_pcie_cleanup,
+ .init_if = mwifiex_init_pcie,
+ .cleanup_if = mwifiex_cleanup_pcie,
.check_fw_status = mwifiex_check_fw_status,
.check_winner_status = mwifiex_check_winner_status,
.prog_fw = mwifiex_prog_fw_w_helper,
@@ -3173,42 +3173,7 @@ static void mwifiex_pcie_down_dev(struct mwifiex_adapter *adapter)
.up_dev = mwifiex_pcie_up_dev,
};
-/*
- * This function initializes the PCIE driver module.
- *
- * This registers the device with PCIE bus.
- */
-static int mwifiex_pcie_init_module(void)
-{
- int ret;
-
- pr_debug("Marvell PCIe Driver\n");
-
- ret = pci_register_driver(&mwifiex_pcie);
- if (ret)
- pr_err("Driver register failed!\n");
- else
- pr_debug("info: Driver registered successfully!\n");
-
- return ret;
-}
-
-/*
- * This function cleans up the PCIE driver.
- *
- * The following major steps are followed for cleanup -
- * - Resume the device if its suspended
- * - Disconnect the device if connected
- * - Shutdown the firmware
- * - Unregister the device from PCIE bus.
- */
-static void mwifiex_pcie_cleanup_module(void)
-{
- pci_unregister_driver(&mwifiex_pcie);
-}
-
-module_init(mwifiex_pcie_init_module);
-module_exit(mwifiex_pcie_cleanup_module);
+module_pci_driver(mwifiex_pcie);
MODULE_AUTHOR("Marvell International Ltd.");
MODULE_DESCRIPTION("Marvell WiFi-Ex PCI-Express Driver version " PCIE_VERSION);
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 9a16e61..db01794 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2698,34 +2698,7 @@ static void mwifiex_sdio_device_dump(struct mwifiex_adapter *adapter)
.deaggr_pkt = mwifiex_deaggr_sdio_pkt,
};
-/*
- * This function initializes the SDIO driver.
- *
- * This registers the device with SDIO bus.
- */
-static int
-mwifiex_sdio_init_module(void)
-{
- return sdio_register_driver(&mwifiex_sdio);
-}
-
-/*
- * This function cleans up the SDIO driver.
- *
- * The following major steps are followed for cleanup -
- * - Resume the device if its suspended
- * - Disconnect the device if connected
- * - Shutdown the firmware
- * - Unregister the device from SDIO bus.
- */
-static void
-mwifiex_sdio_cleanup_module(void)
-{
- sdio_unregister_driver(&mwifiex_sdio);
-}
-
-module_init(mwifiex_sdio_init_module);
-module_exit(mwifiex_sdio_cleanup_module);
+module_driver(mwifiex_sdio, sdio_register_driver, sdio_unregister_driver);
MODULE_AUTHOR("Marvell International Ltd.");
MODULE_DESCRIPTION("Marvell WiFi-Ex SDIO Driver version " SDIO_VERSION);
diff --git a/drivers/net/wireless/marvell/mwifiex/usb.c b/drivers/net/wireless/marvell/mwifiex/usb.c
index 53881c4..9cf3334 100644
--- a/drivers/net/wireless/marvell/mwifiex/usb.c
+++ b/drivers/net/wireless/marvell/mwifiex/usb.c
@@ -1200,40 +1200,7 @@ static void mwifiex_usb_submit_rem_rx_urbs(struct mwifiex_adapter *adapter)
.is_port_ready = mwifiex_usb_is_port_ready,
};
-/* This function initializes the USB driver module.
- *
- * This registers the device with USB bus.
- */
-static int mwifiex_usb_init_module(void)
-{
- int ret;
-
- pr_debug("Marvell USB8797 Driver\n");
-
- ret = usb_register(&mwifiex_usb_driver);
- if (ret)
- pr_err("Driver register failed!\n");
- else
- pr_debug("info: Driver registered successfully!\n");
-
- return ret;
-}
-
-/* This function cleans up the USB driver.
- *
- * The following major steps are followed in .disconnect for cleanup:
- * - Resume the device if its suspended
- * - Disconnect the device if connected
- * - Shutdown the firmware
- * - Unregister the device from USB bus.
- */
-static void mwifiex_usb_cleanup_module(void)
-{
- usb_deregister(&mwifiex_usb_driver);
-}
-
-module_init(mwifiex_usb_init_module);
-module_exit(mwifiex_usb_cleanup_module);
+module_usb_driver(mwifiex_usb_driver);
MODULE_AUTHOR("Marvell International Ltd.");
MODULE_DESCRIPTION("Marvell WiFi-Ex USB Driver version" USB_VERSION);
--
1.9.1
^ permalink raw reply related
* RE: [PATCH 2/2] mwifiex: get rid of global user_rmmod flag
From: Amitkumar Karwar @ 2016-12-01 13:11 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, briannorris@google.com, Xinming Hu
In-Reply-To: <20161130183853.GD31934@dtor-ws>
Hi Dmitry,
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: Thursday, December 01, 2016 12:09 AM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> rajatja@google.com; briannorris@google.com; Xinming Hu
> Subject: Re: [PATCH 2/2] mwifiex: get rid of global user_rmmod flag
>
> Hi Amitkumar,
>
> On Wed, Nov 30, 2016 at 08:22:17PM +0530, Amitkumar Karwar wrote:
> > @@ -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(&mwifiex_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(&mwifiex_pcie);
> > }
>
> Now that your module init/exit code turns into wrapper around bus
> driver registration calls, please consider using module_pci_driver(),
> module_usb_driver(). Note that I do not see module_sdio_driver, but you
> could still use
>
> module_driver(mwifiex_sdio, sdio_register_driver,
> sdio_unregister_driver);
>
Thanks for review.
I just submitted a separate patch which handles this cleanup.
https://patchwork.kernel.org/patch/9456135/
Regards,
Amitkumar
^ permalink raw reply
* [PATCH] mwifiex: sdio: fix use after free issue for save_adapter
From: Amitkumar Karwar @ 2016-12-01 13:53 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris,
dmitry.torokhov, Amitkumar Karwar
If we have sdio work requests received when sdio card reset is
happening, we may end up accessing older save_adapter pointer
later which is already freed during card reset.
This patch solves the problem by cancelling those pending requests.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/sdio.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index db01794..44eb65a 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2229,6 +2229,12 @@ static void mwifiex_recreate_adapter(struct sdio_mmc_card *card)
mmc_hw_reset(func->card->host);
sdio_release_host(func);
+ /* Previous save_adapter won't be valid after this. We will cancel
+ * pending work requests.
+ */
+ clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, &iface_work_flags);
+ clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, &iface_work_flags);
+
mwifiex_sdio_probe(func, device_id);
}
--
1.9.1
^ permalink raw reply related
* Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
From: Andy Gross @ 2016-12-01 14:21 UTC (permalink / raw)
To: Valo, Kalle
Cc: Bjorn Andersson, k.eugene.e@gmail.com,
wcn36xx@lists.infradead.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org
In-Reply-To: <87r35srm0c.fsf@kamboji.qca.qualcomm.com>
On 1 December 2016 at 04:17, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>
>> Kalle Valo <kvalo@qca.qualcomm.com> writes:
>>
>>> "Valo, Kalle" <kvalo@qca.qualcomm.com> writes:
>>>
>>>> Bjorn Andersson <bjorn.andersson@linaro.org> writes:
>>>>
>>>>> On Wed 16 Nov 10:49 PST 2016, Kalle Valo wrote:
>>>>>
>>>>>> Bjorn Andersson <bjorn.andersson@linaro.org> 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 <andy.gross@linaro.org>
>>>>>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>>>>
>>>>>> 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!
>
> Bjorn mentioned me on IRC that this is because of a missing commit in my
> tree:
>
> daa6e41ce2b5 soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API
>
> When I pull the tag below (which contains the above commit) wcn36xx
> builds fine for me:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.10
>
> Andy, is it ok if I pull your tag also to my ath.git tree to solve the
> wcn36xx build problem? My trees go to Linus via net-next and I don't
> know when exactly Dave would send a pull request to Linus, before or
> after the arm trees, but as the tag seems to contain only few patches I
> hope it doesn't matter.
The qcom-drivers-for-4.10 tag was already merged into arm-soc. But
having you pull it as well won't cause issues so long as you are using
the tag (which you are). I don't see any issues with this approach.
Andy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox