RE: ath10k firmware crashes in mesh mode on QCA9880

> Tested the 10.2.4.70.59-2 firmware and wpa_supplicant running WITHOUT > encryption and it still crashes. I suspect this means wpa_supplicant is > setting up > the interface incorrectly and/or transmitting a malformed packet that is > causing > the driver to crash. > Ben, IIRC mesh support

Re: [PATCH] ath10k: ensure pdev sta kickout threshold is set.

[...] > +int ath10k_mac_set_pdev_kickout(struct ath10k *ar) > +{ > + u32 param = ar->wmi.pdev_param->sta_kickout_th; > + int rv; > + > + rv = ath10k_wmi_pdev_set_param(ar, param, > + ar->sta_xretry_kickout_thresh); > + if (rv) { > +

Re: [PATCH 2/3] ath10k: Grab rcu_read_lock before the txqs spinlock.

> diff --git a/drivers/net/wireless/ath/ath10k/mac.c > b/drivers/net/wireless/ath/ath10k/mac.c > index 916119c..d96c06e 100644 > --- a/drivers/net/wireless/ath/ath10k/mac.c > +++ b/drivers/net/wireless/ath/ath10k/mac.c > @@ -4307,8 +4307,8 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar) >

Re: [PATCH] ath10k: fix system hang at qca99x0 probe on x86 platform

> from my point of view this patch is just shit. it trunkates the maximum > allocated memory to a certain value. > so firmware requests 800 kb memory but just gets 256kb. so out of bound > memory access is guaranteed at all. > Even with current logic, If the memory chunk allocation fails for

Re: ath10k + iw set bitrates is causing FW crash

[...] > >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am > >> seeing 0-9, so its > >> working. > >> > >> But i am seeing a weird issues, the moment i give bitrates command, > >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after > >> interface up/down > >>

Re: ath10k + iw set bitrates is causing FW crash

sta->addr); -Rajkumar From: Krishna Chaitanya <chaitanya.m...@gmail.com> Sent: Friday, July 8, 2016 5:26 PM To: Manoharan, Rajkumar Cc: linux-wireless; ath10k Subject: Re: ath10k + iw set bitrates is causing FW crash On

Re: ath10k + iw set bitrates is causing FW crash

>> I am using ath10k driver with qca988x hw2.0 and trying to limit it to use >> VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7). >> >> But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL >> no crash is observed but it still uses MCS9. >> >> tree: wireless-drivers-next:

Re: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system

On Thursday, June 2, 2016 8:51 PM, Ben Greear wrote: > On 06/02/2016 07:24 AM, Valo, Kalle wrote: >> Kalle Valo writes: >> >>> there's a regression in ath10k: >>> >>> https://bugzilla.kernel.org/show_bug.cgi?id=119151 >>> >>> Reporter bisected it

Re: [PATCH v2 5/5] ath10k: Fix deadlock when peer cannot be created.

> On Monday, May 9, 2016 10:49 PM, gree...@candelatech.com wrote: >> On 04/01/2016 02:12 PM, gree...@candelatech.com wrote: >> From: Ben Greear >> >> We must not attempt to send WMI packets while holding the data-lock, >> as it may deadlock: >> >> BUG: sleeping function

Re: [PATCH 1/9] ath10k: speedup htt rx descriptor processing for tx completion

[...] >> >> I see two new warnings on the kfifo_put() call: >> >> drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast to non-scalar >> drivers/net/wireless/ath/ath10k/htt_rx.c:1722:22: warning: cast from >> non-scalar >> >> But I suspect they are false warnings due to my old compiler:

Re: [PATCH 1/9] ath10k: speedup htt rx descriptor processing for tx completion

[...] > >> @@ -1712,7 +1710,20 @@ static void ath10k_htt_rx_frm_tx_compl(struct ath10k >> *ar, >> for (i = 0; i < resp->data_tx_completion.num_msdus; i++) { >> msdu_id = resp->data_tx_completion.msdus[i]; >> tx_done.msdu_id = __le16_to_cpu(msdu_id); >> -

Re: [PATCH 1/4] ath10k: remove supported chain mask

Removing supported chainmask fields as it can be always derived from num_rf_chains. Signed-off-by: Rajkumar Manoharan >>> >> Hello, >> >> This one break monitor mode for qca988x and 10.x firmware: >> After Revert "ath10k: remove supported chain mask"

Re: [PATCH 1/4] ath10k: remove supported chain mask

>>> Removing supported chainmask fields as it can be always derived >>> from num_rf_chains. >>> >>> Signed-off-by: Rajkumar Manoharan >> > Hello, > > This one break monitor mode for qca988x and 10.x firmware: > After Revert "ath10k: remove supported chain mask" - works

Re: [PATCH] ath10k: poll HTT send completion when CE 5 is unused

> > commit a70587b3389a ("ath10k: configure copy engine 5 for HTT messages") > > moved send completion polling under HTT Rx (CE 5) service routine. For > > QCA6174 based devices copy engine 1 (CE 1) is used for HTT Rx instead > > of CE 5. So send completion never be called. This is causing "failed

Re: [PATCH 0/7] ath10k: add copy engine fast path support

> > Below patchset adds fast path support for uplink traffic by bypassing > > HTC layer processing. This is enabled by making use of unused copy > > engine 5 to receive HTT messages directly from HIF layer. From initial > > validation in VHT80/5G mode TCP UL is improved to 900Mbps from ~840Mbps >