* [PATCH] ath10k: Fix Tx DMA alloc failure during continuous wifi down/up
From: Mohammed Shafi Shajakhan @ 2016-11-30 9:50 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
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
^ permalink raw reply related
* Re: [RFC V2 1/5] nl80211: allow reporting RTT information in scan results
From: Arend Van Spriel @ 2016-11-30 9:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1480494148.9990.33.camel@sipsolutions.net>
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
^ permalink raw reply
* Re: [RFC V2 1/5] nl80211: allow reporting RTT information in scan results
From: Johannes Berg @ 2016-11-30 8:22 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless
In-Reply-To: <6f75b940-d0b1-1e9c-f286-3923089d202d@broadcom.com>
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
^ permalink raw reply
* Re: ath10k: Fix soft lockup during firmware crash/hw-restart
From: Mohammed Shafi Shajakhan @ 2016-11-30 6:10 UTC (permalink / raw)
To: Ben Greear; +Cc: Mohammed Shafi Shajakhan, ath10k, linux-wireless
In-Reply-To: <ecb7e9d7-34c5-4ea8-62a9-b5b96409bb0b@candelatech.com>
On Tue, Nov 29, 2016 at 04:43:48PM -0800, Ben Greear wrote:
> I have not seen this hang since adding this patch, so
> hopefully it has resolved the problem.
thanks Ben ! I had updated the commit log with Fixes tag
https://patchwork.kernel.org/patch/9453609/
>
> On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:
> >From: Mohammed Shafi Shajakhan <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
* [PATCH v2] ath10k: Fix soft lockup during firmware crash/hw-restart
From: Mohammed Shafi Shajakhan @ 2016-11-30 5:29 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
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 ]
drivers/net/wireless/ath/ath10k/core.c | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 7005e2a..5bc6847 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1536,7 +1536,7 @@ static void ath10k_core_restart(struct work_struct *work)
switch (ar->state) {
case ATH10K_STATE_ON:
ar->state = ATH10K_STATE_RESTARTING;
- ath10k_hif_stop(ar);
+ ath10k_halt(ar);
ath10k_scan_finish(ar);
ieee80211_restart_hw(ar->hw);
break;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 717b2fa..481842b 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,7 +4449,6 @@ static int ath10k_start(struct ieee80211_hw *hw)
ar->state = ATH10K_STATE_ON;
break;
case ATH10K_STATE_RESTARTING:
- ath10k_halt(ar);
ar->state = ATH10K_STATE_RESTARTED;
break;
case ATH10K_STATE_ON:
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2016-11-30 1:20 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-wireless@vger.kernel.org, Linux Kernel,
devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
Tony Lindgren, Ulf Hansson, Mark Rutland, Srinivas Kandagatla
In-Reply-To: <CABxcv=nEih8xX4fM0eqjkqprdt1uGTEyx5tzK04GuSgsHc=Haw@mail.gmail.com>
On Tue, Nov 29, 2016 at 9:13 AM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
> Hello Matt,
>
> On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
> <matt@ranostay.consulting> wrote:
>> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
>> This can be abstracted to other chipsets if needed in the future.
>>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Ulf Hansson <ulf.hansson@linaro.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
>> ---
>> .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
>> .../bindings/net/wireless/marvell-sd8xxx.txt | 4 +
>> drivers/mmc/core/Kconfig | 10 ++
>> drivers/mmc/core/Makefile | 1 +
>> drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
>> 5 files changed, 146 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>
> According Documentation/devicetree/bindings/submitting-patches.txt,
> the DT bindings patches should posted as a separate patch.
Ok will do.
>
>> new file mode 100644
>> index 000000000000..1b658351629b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
>> @@ -0,0 +1,14 @@
>> +* Marvell SD8787 power sequence provider
>> +
>> +Required properties:
>> +- compatible: must be "mmc-pwrseq-sd8787".
>
> Since this is not a generic binding, the compatible string should have
> a vendor prefix.
>
Makes sense to me.
>> +- pwndn-gpio: contains a power down GPIO specifier.
>> +- reset-gpio: contains a reset GPIO specifier.
>> +
>
> I wonder if we really need a custom power sequence provider for just
> this SDIO WiFI chip though. AFAICT the only missing piece in
> mmc-pwrseq-simple is the power down GPIO property, so maybe
> mmc-pwrseq-simple could be extended instead to have an optional
> powerdown-gpios property and instead in the Marvell SD8787 DT binding
> can be mentioned which mmc-pwrseq-simple properties are required for
> the device.
>
The reason we didn't do that is we need delay between the two
assertions/desertions of GPIOs. It wouldn't seems good practice to
hack the pwrseq-simple for this...
>> +Example:
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-sd8787";
>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>> + }
>> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>
> Does this patch depend on a previous posted series? I don't see this
> file in today's linux-next...
Got renamed to ->
Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt it
seems very recently.
>
>> index c421aba0a5bc..08fd65d35725 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>> @@ -32,6 +32,9 @@ Optional properties:
>> so that the wifi chip can wakeup host platform under certain condition.
>> during system resume, the irq will be disabled to make sure
>> unnecessary interrupt is not received.
>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>> + - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
>> + for documentation of MMC power sequence bindings.
>>
>> Example:
>>
>> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side pin.
>> &mmc3 {
>> status = "okay";
>> vmmc-supply = <&wlan_en_reg>;
>> + mmc-pwrseq = <&wifi_pwrseq>;
>> bus-width = <4>;
>> cap-power-off-card;
>> keep-power-in-suspend;
>
> I think this change should be split in a separate patch as well.
>
> Best regards,
> Javier
^ permalink raw reply
* Re: ath10k: Fix soft lockup during firmware crash/hw-restart
From: Ben Greear @ 2016-11-30 0:43 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan, ath10k; +Cc: mohammed, linux-wireless
In-Reply-To: <1480430762-15995-1-git-send-email-mohammed@qca.qualcomm.com>
I have not seen this hang since adding this patch, so
hopefully it has resolved the problem.
Thanks,
Ben
On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan <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
* [PATCH] mac80211: Suppress NEW_PEER_CANDIDATE event if no room
From: Masashi Honma @ 2016-11-30 0:06 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, me, Masashi Honma
Previously, kernel sends NEW_PEER_CANDIDATE event to user land even if
the found peer does not have any room to accept other peer. This causes
continuous connection trials.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
net/mac80211/mesh_plink.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 7fcdcf6..fcba70e5 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -505,12 +505,14 @@ mesh_sta_info_alloc(struct ieee80211_sub_if_data *sdata, u8 *addr,
/* Userspace handles station allocation */
if (sdata->u.mesh.user_mpm ||
- sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED)
- cfg80211_notify_new_peer_candidate(sdata->dev, addr,
- elems->ie_start,
- elems->total_len,
- GFP_KERNEL);
- else
+ sdata->u.mesh.security & IEEE80211_MESH_SEC_AUTHED) {
+ if (mesh_peer_accepts_plinks(elems) &&
+ mesh_plink_availables(sdata))
+ cfg80211_notify_new_peer_candidate(sdata->dev, addr,
+ elems->ie_start,
+ elems->total_len,
+ GFP_KERNEL);
+ } else
sta = __mesh_sta_info_alloc(sdata, addr);
return sta;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/1] rtl8xxxu: Work around issue with 8192eu and 8723bu devices not reconnecting
From: Jes.Sorensen @ 2016-11-29 23:59 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, briselec
In-Reply-To: <20161129235902.11882-1-Jes.Sorensen@redhat.com>
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>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index a9137ab..3a86675 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -4372,6 +4372,13 @@ void rtl8xxxu_gen1_report_connect(struct rtl8xxxu_priv *priv,
void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
u8 macid, bool connect)
{
+#ifdef RTL8XXXU_GEN2_REPORT_CONNECT
+ /*
+ * Barry Day reports this causes issues with 8192eu and 8723bu
+ * devices reconnecting. The reason for this is unclear, but
+ * until it is better understood, leave the code in place but
+ * disabled, so it is not lost.
+ */
struct h2c_cmd h2c;
memset(&h2c, 0, sizeof(struct h2c_cmd));
@@ -4383,6 +4390,7 @@ void rtl8xxxu_gen2_report_connect(struct rtl8xxxu_priv *priv,
h2c.media_status_rpt.parm &= ~BIT(0);
rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.media_status_rpt));
+#endif
}
void rtl8xxxu_gen1_init_aggregation(struct rtl8xxxu_priv *priv)
--
2.7.4
^ permalink raw reply related
* [PATCH 0/1] rtl8xxxu: Workaround for 8192eu/8723bu not reconnecting
From: Jes.Sorensen @ 2016-11-29 23:59 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, briselec
From: Jes Sorensen <Jes.Sorensen@redhat.com>
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.
Cheers,
Jes
Jes Sorensen (1):
rtl8xxxu: Work around issue with 8192eu and 8723bu devices not
reconnecting
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 8 ++++++++
1 file changed, 8 insertions(+)
--
2.7.4
^ permalink raw reply
* ath10k: wmi-alloc-chunk should use DMA_BIDIRECTIONAL.
From: greearb @ 2016-11-29 22:00 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ben Greear
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;
^ permalink raw reply related
* ath10k firmware crashes in mesh mode on QCA9880
From: Benjamin Morgan @ 2016-11-29 19:22 UTC (permalink / raw)
To: linux-wireless, ath10k, lede-dev; +Cc: agreen
When we try to transmit traffic (ping) between two meshed ath10k devices
running latest lede we keep experiencing ath10k firmware crashes. This
seems to only happen when running in 802.11n/ac mode but not in
802.11a/g mode. Also, from the station dumps it appears that management
traffic is flowing between the devices, however when we try to send
unicast data traffic the firmware crashes immediately.
Platform: Archer C7 AC1750 v2
Software Image: LEDE (HEAD, r2299) Commit:
https://github.com/lede-project/source/commit/d596c21ebd5a3e6ce933eff3e51989031e4b1d58
Crypto: wpa_supplicant
wpa_supplicant-wlan0.conf
network={
ssid="bmorgan_lede_mesh"
key_mgmt=SAE
mode=5
frequency=5180
psk="meshpassword"
}
Backports Verstion:
[ 9.818007] Loading modules backported from Linux version
wt-2016-10-03-1-g6fcb1a6
[ 9.825736] Backport generated by backports.git
backports-20160324-9-g0e38f5c
Ath10k Initialization on Station A (dmesg)
[ 9.896715] PCI: Enabling device 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: ath10k: Fix soft lockup during firmware crash/hw-restart
From: Ben Greear @ 2016-11-29 18:16 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan, ath10k; +Cc: mohammed, linux-wireless
In-Reply-To: <1480430762-15995-1-git-send-email-mohammed@qca.qualcomm.com>
Is this something for stable? And if so, how far back should it be applied?
I'll add this patch to my 4.9 tree and test it...
Thanks,
Ben
On 11/29/2016 06:46 AM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan <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
* [PATCH] mac80211: Return avg sig, rx, tx values in ethtool stats.
From: greearb @ 2016-11-29 18:07 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Ben Greear
From: Ben Greear <greearb@candelatech.com>
For non-station devices. This gives at least some useful
summary in some cases (especially when we know AP has only one
station attached, for instance).
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
This is against 4.7.10+, applied to 4.4 and 4.9 for me as well.
net/mac80211/ethtool.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/net/mac80211/ethtool.c b/net/mac80211/ethtool.c
index 4e937c1..dc6f76f 100644
--- a/net/mac80211/ethtool.c
+++ b/net/mac80211/ethtool.c
@@ -12,6 +12,25 @@
#include "ieee80211_i.h"
#include "sta_info.h"
#include "driver-ops.h"
+#include <asm/div64.h>
+
+static inline __s64 mac_div(__s64 n, __u32 base)
+{
+ if (n < 0) {
+ __u64 tmp = -n;
+ do_div(tmp, base);
+ /* printk("pktgen: pg_div, n: %llu base: %d rv: %llu\n",
+ n, base, tmp); */
+ return -tmp;
+ }
+ else {
+ __u64 tmp = n;
+ do_div(tmp, base);
+ /* printk("pktgen: pg_div, n: %llu base: %d rv: %llu\n",
+ n, base, tmp); */
+ return tmp;
+ }
+}
static int ieee80211_set_ringparam(struct net_device *dev,
struct ethtool_ringparam *rp)
@@ -128,6 +147,12 @@ static void ieee80211_get_stats(struct net_device *dev,
data[i] = (u8)sinfo.signal_avg;
i++;
} else {
+ int amt_tx = 0;
+ int amt_rx = 0;
+ int amt_sig = 0;
+ s64 tx_accum = 0;
+ s64 rx_accum = 0;
+ s64 sig_accum = 0;
list_for_each_entry(sta, &local->sta_list, list) {
/* Make sure this station belongs to the proper dev */
if (sta->sdata->dev != dev)
@@ -137,6 +162,37 @@ static void ieee80211_get_stats(struct net_device *dev,
sta_set_sinfo(sta, &sinfo);
i = 0;
ADD_STA_STATS(sta);
+
+ i++; /* skip sta state */
+
+ if (sinfo.filled & BIT(NL80211_STA_INFO_TX_BITRATE)) {
+ tx_accum += 100000 *
+ cfg80211_calculate_bitrate(&sinfo.txrate);
+ amt_tx++;
+ data[i] = mac_div(tx_accum, amt_tx);
+ }
+ i++;
+
+ if (sinfo.filled & BIT(NL80211_STA_INFO_RX_BITRATE)) {
+ rx_accum += 100000 *
+ cfg80211_calculate_bitrate(&sinfo.rxrate);
+ amt_rx++;
+ data[i] = mac_div(rx_accum, amt_rx);
+ }
+ i++;
+
+ if (sinfo.filled & BIT(NL80211_STA_INFO_SIGNAL_AVG)) {
+ sig_accum += sinfo.signal_avg;
+ amt_sig++;
+ data[i] = (mac_div(sig_accum, amt_sig) & 0xFF);
+ }
+ i++;
+
+ /*pr_err("sta: %p (%s) sig_accum: %ld amt-sig: %d filled: 0x%x:%08x rpt-sig-avg: %d i: %d div: %d sinfo.signal_avg: %d\n",
+ sta, sta->sdata->name, (long)(sig_accum), amt_sig, (u32)(sinfo.filled >> 32),
+ (u32)(sinfo.filled), (u32)(data[i-1]), i-1, (u32)(mac_div(sig_accum, amt_sig)),
+ sinfo.signal_avg);*/
+
}
}
--
2.4.11
^ permalink raw reply related
* [PATCH 2/2] mac80211: put upper bound on txqi queue length.
From: greearb @ 2016-11-29 18:05 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Ben Greear
In-Reply-To: <1480442753-6830-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
This fixes OOM when using pktgen to drive a wifi station at more than
the station can transmit. pktgen uses ndo_start_xmit instead of going
through the queue layer, so it will not back off when the queues are
stopped, and would thus cause packets to be added to the txqi->queue
until the system goes OOM and crashes.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
This is against 4.7.10+, not sure if it is actually needed in latest kernel.
net/mac80211/tx.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index fbcb5fc..0573ab9 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1293,6 +1293,16 @@ static void ieee80211_drv_tx(struct ieee80211_local *local,
goto tx_normal;
ac = txq->ac;
+
+ if (atomic_read(&sdata->txqs_len[ac]) >=
+ (local->hw.txq_ac_max_pending * 2)) {
+ /* Must be that something is not paying attention to
+ * max-pending, like pktgen, so just drop this frame.
+ */
+ ieee80211_free_txskb(&local->hw, skb);
+ return;
+ }
+
txqi = to_txq_info(txq);
atomic_inc(&sdata->txqs_len[ac]);
if (atomic_read(&sdata->txqs_len[ac]) >= local->hw.txq_ac_max_pending)
--
2.4.11
^ permalink raw reply related
* [PATCH 1/2] mac80211: Show pending txqlen in debugfs.
From: greearb @ 2016-11-29 18:05 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Ben Greear
From: Ben Greear <greearb@candelatech.com>
Could be useful for debugging memory consumption issues,
and perhaps power-save as well.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
This is against 4.7.10+
net/mac80211/debugfs.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index b251b2f7..0b49b43 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -162,6 +162,30 @@ static ssize_t hwflags_read(struct file *file, char __user *user_buf,
return rv;
}
+static ssize_t misc_read(struct file *file, char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ieee80211_local *local = file->private_data;
+ size_t bufsz = 1000;
+ char *buf = kzalloc(bufsz, GFP_KERNEL);
+ char *pos = buf, *end = buf + bufsz - 1;
+ ssize_t rv;
+ int i;
+ int ln;
+
+ pos += scnprintf(pos, end - pos, "pending:\n");
+
+ for (i = 0; i < IEEE80211_MAX_QUEUES; i++) {
+ ln = skb_queue_len(&local->pending[i]);
+ pos += scnprintf(pos, end - pos, "[%i] %d\n",
+ i, ln);
+ }
+
+ rv = simple_read_from_buffer(user_buf, count, ppos, buf, strlen(buf));
+ kfree(buf);
+ return rv;
+}
+
static ssize_t queues_read(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
@@ -182,6 +206,7 @@ static ssize_t queues_read(struct file *file, char __user *user_buf,
DEBUGFS_READONLY_FILE_OPS(hwflags);
DEBUGFS_READONLY_FILE_OPS(queues);
+DEBUGFS_READONLY_FILE_OPS(misc);
/* statistics stuff */
@@ -250,6 +275,7 @@ void debugfs_hw_add(struct ieee80211_local *local)
DEBUGFS_ADD(total_ps_buffered);
DEBUGFS_ADD(wep_iv);
DEBUGFS_ADD(queues);
+ DEBUGFS_ADD(misc);
#ifdef CONFIG_PM
DEBUGFS_ADD_MODE(reset, 0200);
#endif
--
2.4.11
^ permalink raw reply related
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Javier Martinez Canillas @ 2016-11-29 17:13 UTC (permalink / raw)
To: Matt Ranostay
Cc: linux-wireless@vger.kernel.org, Linux Kernel,
devicetree@vger.kernel.org, linux-mmc@vger.kernel.org,
Tony Lindgren, Ulf Hansson, Mark Rutland, Srinivas Kandagatla
In-Reply-To: <1479434109-8745-1-git-send-email-matt@ranostay.consulting>
Hello Matt,
On Thu, Nov 17, 2016 at 10:55 PM, Matt Ranostay
<matt@ranostay.consulting> wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> ---
> .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
> .../bindings/net/wireless/marvell-sd8xxx.txt | 4 +
> drivers/mmc/core/Kconfig | 10 ++
> drivers/mmc/core/Makefile | 1 +
> drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
> 5 files changed, 146 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
According Documentation/devicetree/bindings/submitting-patches.txt,
the DT bindings patches should posted as a separate patch.
> new file mode 100644
> index 000000000000..1b658351629b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
> @@ -0,0 +1,14 @@
> +* Marvell SD8787 power sequence provider
> +
> +Required properties:
> +- compatible: must be "mmc-pwrseq-sd8787".
Since this is not a generic binding, the compatible string should have
a vendor prefix.
> +- pwndn-gpio: contains a power down GPIO specifier.
> +- reset-gpio: contains a reset GPIO specifier.
> +
I wonder if we really need a custom power sequence provider for just
this SDIO WiFI chip though. AFAICT the only missing piece in
mmc-pwrseq-simple is the power down GPIO property, so maybe
mmc-pwrseq-simple could be extended instead to have an optional
powerdown-gpios property and instead in the Marvell SD8787 DT binding
can be mentioned which mmc-pwrseq-simple properties are required for
the device.
> +Example:
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-sd8787";
> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
> + }
> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
Does this patch depend on a previous posted series? I don't see this
file in today's linux-next...
> index c421aba0a5bc..08fd65d35725 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> @@ -32,6 +32,9 @@ Optional properties:
> so that the wifi chip can wakeup host platform under certain condition.
> during system resume, the irq will be disabled to make sure
> unnecessary interrupt is not received.
> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
> + - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
> + for documentation of MMC power sequence bindings.
>
> Example:
>
> @@ -44,6 +47,7 @@ so that firmware can wakeup host using this device side pin.
> &mmc3 {
> status = "okay";
> vmmc-supply = <&wlan_en_reg>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> bus-width = <4>;
> cap-power-off-card;
> keep-power-in-suspend;
I think this change should be split in a separate patch as well.
Best regards,
Javier
^ permalink raw reply
* Re: [PATCH] mmc: pwrseq: add support for Marvell SD8787 chip
From: Ulf Hansson @ 2016-11-29 16:53 UTC (permalink / raw)
To: Rob Herring
Cc: Matt Ranostay, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-mmc@vger.kernel.org, Tony Lindgren, Mark Rutland,
Srinivas Kandagatla
In-Reply-To: <CAL_Jsq+80LAkCGEdP5T0AWFV2nRtZ8nrkBoNRB47CR9JN=9dog@mail.gmail.com>
On 29 November 2016 at 15:51, Rob Herring <robh@kernel.org> wrote:
> On Mon, Nov 28, 2016 at 9:54 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> [...]
>>
>>>> +
>>>> +Example:
>>>> +
>>>> + wifi_pwrseq: wifi_pwrseq {
>>>> + compatible = "mmc-pwrseq-sd8787";
>>>> + pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
>>>> + reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
>>>> + }
>>>> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>>> index c421aba0a5bc..08fd65d35725 100644
>>>> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>>> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
>>>> @@ -32,6 +32,9 @@ Optional properties:
>>>> so that the wifi chip can wakeup host platform under certain condition.
>>>> during system resume, the irq will be disabled to make sure
>>>> unnecessary interrupt is not received.
>>>> + - vmmc-supply: a phandle of a regulator, supplying VCC to the card
>>>
>>> This is why pwrseq is wrong. You have some properties in the card node
>>> and some in pwrseq node. Everything should be in the card node.
>>
>> Put "all" in the card node, just doesn't work for MMC. Particular in
>> cases when we have removable cards, as then it would be wrong to have
>> a card node.
>
> When is there a problem with removable cards? The connector is
> standard and everything needed (CD, VMMC, VDDIO, etc.) is defined in
> the host controller node. If that isn't sufficient, then we should
> start defining a connector node.
I probably didn't get your point. Anyway, let's try again.
I don't see any problems with removable cards and neither with
non-removable cards.
Normally, we don't need a connector node, but instead we put the
related properties/phandles in the host controller node. This works
fine!
For SDIO func devices, sometimes we need a child node of the host
controller node, as to be able to describe certain characteristics of
the SDIO func device. So this case is kind of a special type of card
node (because one can have several SDIO func devices attached, even if
this isn't used).
Now, to follow the current bindings, we must not put connector related
bindings in the card node, like the vmmc-supply, perhaps that is what
causes confusion here?
>
>> The mmc pwrseq DT bindings just follows the legacy approach for MMC
>> and that's why the pwrseq handle is at the controller node. Yes, would
>> could have done it differently, but this is the case now, so we will
>> have to accept that.
>
> We're stuck with supporting the existing cases. That doesn't mean
> we're stuck with the same thing for new cases.
Agree!
But I think there is nothing to improve in this case, or am I wrong?
Kind regards
Uffe
^ permalink raw reply
* Re: bcma: add Dell Inspiron 3148
From: Kalle Valo @ 2016-11-29 15:35 UTC (permalink / raw)
To: Jiri Slaby; +Cc: zajec5, linux-wireless, linux-kernel, Jiri Slaby
In-Reply-To: <20161128075712.10785-1-jslaby@suse.cz>
Jiri Slaby <jslaby@suse.cz> wrote:
> This is what is in the laptop:
> 01:00.0 Network controller [0280]: Broadcom Limited BCM43142 802.11b/g/n [14e4:4365] (rev 01)
> Subsystem: Dell Device [1028:0018]
> Flags: bus master, fast devsel, latency 0, IRQ 18
> Memory at b0400000 (64-bit, non-prefetchable) [size=32K]
> Capabilities: [40] Power Management version 3
> Capabilities: [58] Vendor Specific Information: Len=78 <?>
> Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [d0] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [13c] Virtual Channel
> Capabilities: [160] Device Serial Number 00-00-9a-ff-ff-f3-40-b8
> Capabilities: [16c] Power Budgeting <?>
>
> With the patch, I can see:
> bcma: bus0: Found chip with id 43142, rev 0x01 and package 0x08
> bcma: bus0: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x28, class 0x0)
> bcma: bus0: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x21, class 0x0)
> bcma: bus0: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x16, class 0x0)
> bcma: bus0: Core 3 found: UNKNOWN (manuf 0x43B, id 0x368, rev 0x00, class 0x0)
> bcma: bus0: Bus registered
>
> The wifi is not currently supported by brcmsmac yet:
> brcmsmac bcma1:1: mfg 4bf core 812 rev 33 class 0 irq 18
> brcmsmac: unknown device id 4365
>
> So don't expect a working wifi from this patch :).
>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Cc: Rafał Miłecki <zajec5@gmail.com>
> Cc: <linux-wireless@vger.kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
59391a96dc73 bcma: add Dell Inspiron 3148
--
https://patchwork.kernel.org/patch/9449165/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: Fix enter/exit power_save
From: Kalle Valo @ 2016-11-29 15:33 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Larry Finger, Stable
In-Reply-To: <20161126204335.12847-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In commit a5ffbe0a1993 ("rtlwifi: Fix scheduling while atomic bug") and
> commit a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter()
> to use work queue"), an error was introduced in the power-save routines
> due to the fact that leaving PS was delayed by the use of a work queue.
>
> This problem is fixed by detecting if the enter or leave routines are
> in interrupt mode. If so, the workqueue is used to place the request.
> If in normal mode, the enter or leave routines are called directly.
>
> Fixes: a269913c52ad ("rtlwifi: Rework rtl_lps_leave() and rtl_lps_enter() to use work queue")
> Reported-by: Ping-Ke Shih <pkshih@realtek.com>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
ba9f93f82aba rtlwifi: Fix enter/exit power_save
--
https://patchwork.kernel.org/patch/9448539/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mt7601u: wait for clear rxq when stopping mac
From: Kalle Valo @ 2016-11-29 15:32 UTC (permalink / raw)
To: Anthony Romano; +Cc: linux-wireless, kubakici
In-Reply-To: <20161125111334.31085-1-anthony.romano@coreos.com>
Anthony Romano <anthony.romano@coreos.com> wrote:
> mt7601u_mac_stop_hw should stop polling the rxq once it remains empty
> but instead continues polling after the rxq status stays clear; bringing
> down the interface takes about six seconds from this alone.
>
> Speed up path by exiting rxq loop once status repeatedly polls empty.
>
> Signed-off-by: Anthony Romano <anthony.romano@coreos.com>
> Reviewed-by: Jakub Kicinski <kubakici@wp.pl>
Patch applied to wireless-drivers-next.git, thanks.
05db221e30a9 mt7601u: wait for clear rxq when stopping mac
--
https://patchwork.kernel.org/patch/9447371/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: adm80211: Removed unused 'io_addr' 'mem_addr' variables
From: Kalle Valo @ 2016-11-29 15:32 UTC (permalink / raw)
To: Kirtika Ruchandani; +Cc: Arnd Bergmann, Johannes Berg, linux-wireless, netdev
In-Reply-To: <20161124064045.GA8836@google.com>
Kirtika Ruchandani <kirtika.ruchandani@gmail.com> wrote:
> Initial commit cc0b88cf5ecf ([PATCH] Add adm8211 802.11b wireless driver)
> introduced variables mem_addr and io_addr in adm80211_probe() that are
> set but not used. Compiling with W=1 gives the following warnings,
> fix them.
>
> drivers/net/wireless/admtek/adm8211.c: In function ‘adm8211_probe’:
> drivers/net/wireless/admtek/adm8211.c:1769:15: warning: variable ‘io_addr’ set but not used [-Wunused-but-set-variable]
> unsigned int io_addr, io_len;
> ^
> drivers/net/wireless/admtek/adm8211.c:1768:16: warning: variable ‘mem_addr’ set but not used [-Wunused-but-set-variable]
> unsigned long mem_addr, mem_len;
> ^
>
> These are harmless warnings and are only being fixed to reduce the
> noise with W=1 in the kernel. The calls to pci_resource_start do not
> have any side-effects and are safe to remove.
>
> Fixes: cc0b88cf5ecf ("[PATCH] Add adm8211 802.11b wireless driver")
> Cc: Michael Wu <flamingice@sourmilk.net>
> Cc: John W. Linville <linville@tuxdriver.com>
> Signed-off-by: Kirtika Ruchandani <kirtika@chromium.org>
The patch failed to apply:
fatal: corrupt patch at line 14
Applying: adm80211: Removed unused 'io_addr' 'mem_addr' variables
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 adm80211: Removed unused 'io_addr' 'mem_addr' variables
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9444901/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [01/12] brcmfmac: add pcie host dongle interface rev6 support
From: Kalle Valo @ 2016-11-29 15:30 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <1479896731-5091-2-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> From: Franky Lin <franky.lin@broadcom.com>
>
> In rev6 of pcie host dongle interface protocol, host needs to maximum
> supported ring number from dongle shared memory and set up ring buffer
> and ring indices offset accordingly.
>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
12 patches applied to wireless-drivers-next.git, thanks.
be4b092cab84 brcmfmac: add pcie host dongle interface rev6 support
dc630dc5c753 brcmfmac: add support for 43341 chip
ac55136f43d3 brcmfmac: move pno helper functions in separate source file
3e2e86ab19c2 brcmfmac: fix handling ssids in .sched_scan_start() callback
ab5981c83033 brcmfmac: change prototype for brcmf_do_escan()
fa85b30a9084 brcmfmac: make internal escan more generic
fca6cb2f059e brcmfmac: split up brcmf_pno_config() function
3e48611d31dd brcmfmac: move scheduled scan activation to pno source file
331e78944361 brcmfmac: use provided channels for scheduled scan
dfe5b0d52d58 brcmfmac: remove restriction from .sched_scan_start() callback
c6989fd55ceb brcmfmac: use requested scan interval in scheduled scan
53e3a80d80c8 brcmfmac: fix scheduled scan result handling for newer chips
--
https://patchwork.kernel.org/patch/9442895/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: pcie: implement timeout loop for FW programming doorbell
From: Kalle Valo @ 2016-11-29 15:28 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-kernel,
linux-wireless, Cathy Luo, Dmitry Torokhov, Brian Norris
In-Reply-To: <1479868785-16263-1-git-send-email-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> Marvell Wifi PCIe modules don't always behave nicely for PCIe power
> management when their firmware hasn't been loaded, particularly after
> suspending the PCIe link one or more times. When this happens, we might
> end up spinning forever in this status-polling tight loop. Let's make
> this less tight by adding a timeout and by sleeping a bit in between
> reads, as we do with the other similar loops.
>
> This prevents us from hogging a CPU even in such pathological cases, and
> allows the FW initialization to just fail gracefully instead.
>
> I chose the same polling parameters as the earlier loop in this
> function, and empirically, I found that this loop never makes it more
> than about 12 cycles in a sane FW init sequence. I had no official
> information on the actual intended latency for this portion of the
> download.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
Patch applied to wireless-drivers-next.git, thanks.
22dde1ed5a48 mwifiex: pcie: implement timeout loop for FW programming doorbell
--
https://patchwork.kernel.org/patch/9442499/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2, 1/7] mwifiex: Removed unused mwifiex_private* 'priv' variable
From: Kalle Valo @ 2016-11-29 15:28 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: Amitkumar Karwar, Arnd Bergmann, linux-wireless,
Nishant Sarmukadam, Zhaoyang Liu, Bing Zhao, Xinming Hu,
Avinash Patil
In-Reply-To: <fa8a77df4638cf21720d8c5094afb83475947843.1479950323.git.kirtika@google.com>
Kirtika Ruchandani <kirtika.ruchandani@gmail.com> wrote:
> Commit bec568ff5107 removed the last remaining usage of struct
> mwifiex_private* priv in mwifiex_fw_dpc(), by removing the call to
> mwifiex_del_virtual_intf().
> Compiling mwifiex/ with W=1 gives the following warning, fix it.
> mwifiex/main.c: In function ‘mwifiex_fw_dpc’:
> mwifiex/main.c:520:26: warning: variable ‘priv’ set but not used [-Wunused-but-set-variable]
>
> Fixes: bec568ff5107 ("mwifiex: failure path handling in mwifiex_add_virtual_intf()")
> Cc: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
7 patches applied to wireless-drivers-next.git, thanks.
70d740598713 mwifiex: Removed unused mwifiex_private* 'priv' variable
8ac9134161d9 mwifiex: Remove unused 'chan_num' variable
2c2bcabf02e1 mwifiex: Remove unused 'sta_ptr' variable
60261b266a84 mwifiex: Remove unused 'adapter'variable
e9f1db8b6859 mwifiex: Remove unused 'pm_flag' variable
67dd2a754906 mwifiex: Removed unused 'pkt_type' variable
4133828c76c3 mwifiex: Remove unused 'bcd_usb' variable
--
https://patchwork.kernel.org/patch/9444651/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ 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