Re: [PATCH 2/3] ath10k: Grab rcu_read_lock before the txqs spinlock.
On 09/09/2016 06:36 AM, Valo, Kalle wrote:
gree...@candelatech.com writes:
From: Ben Greear
I was seeing some spin-lock hangs in this area of the code,
and it seems more proper to do the rcu-read-lock outside of
the spin lock. I am not sure how much this matters, however.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
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)
int max;
int loop_max = 2000;
- spin_lock_bh(&ar->txqs_lock);
rcu_read_lock();
+ spin_lock_bh(&ar->txqs_lock);
last = list_last_entry(&ar->txqs, struct ath10k_txq, list);
while (!list_empty(&ar->txqs)) {
@@ -4342,8 +4342,8 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar)
break;
}
- rcu_read_unlock();
spin_unlock_bh(&ar->txqs_lock);
+ rcu_read_unlock();
I'm no RCU expert but this isn't making any sense. Maybe it changes
timings on your kernel so that it hides the real problem?
I'm not sure this fixed anything or not, it just seemed weird so I changed it.
I was hoping someone that understood rcu locking would comment...
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: support for QCA9377 SDIO (ath10k or ath6kl)
On Fri, Sep 9, 2016 at 2:35 PM, Valo, Kalle wrote: >> is there any support for the SDIO chips QCA9377 (and QCA9378) planned? >> Would these be supported by ath10k or ath6kl or is a completely new >> driver needed? > > I'm not familiar with the details of QCA9377 SDIO firmware but I assume > ath10k would be the best option for supporting it. We split from the > beginning the core code (ath10k_core.ko) and the PCI code > (ath10k_pci.ko) to make it easier to add new bus support. ath10k also gained AHB support some months ago, so it seems to allow for multiple bus types. however, that is only relevant if the QCA9377 SDIO firmware uses the same interface as supported by ath10k -> could we get a statement from the firmware team about this? is QCA planning to add SDIO support to ath10k or would this have to be done by a community developer? Regards, Martin ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[ath6kl:pending 62/62] drivers/net/wireless/ath/ath10k/hw.c:341:21: error: 'struct ath10k' has no member named 'debug'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git pending
head: bfa1319f2774dda9cb97301ac6a119fb206be7ed
commit: bfa1319f2774dda9cb97301ac6a119fb206be7ed [62/62] ath10k: allow setting
coverage class
config: i386-randconfig-s1-201636 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
git checkout bfa1319f2774dda9cb97301ac6a119fb206be7ed
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net/wireless/ath/ath10k/hw.c: In function
'ath10k_hw_qca988x_set_coverage_class':
>> drivers/net/wireless/ath/ath10k/hw.c:341:21: error: 'struct ath10k' has no
>> member named 'debug'
fw_dbglog_mask = ar->debug.fw_dbglog_mask;
^~
drivers/net/wireless/ath/ath10k/hw.c:342:22: error: 'struct ath10k' has no
member named 'debug'
fw_dbglog_level = ar->debug.fw_dbglog_level;
^~
vim +341 drivers/net/wireless/ath/ath10k/hw.c
335
336 /* Ensure we have a debug level of WARN set for the case that
the
337 * coverage class is larger than 0. This is important as we
need to
338 * set the registers again if the firmware does an internal
reset and
339 * this way we will be notified of the event.
340 */
> 341 fw_dbglog_mask = ar->debug.fw_dbglog_mask;
342 fw_dbglog_level = ar->debug.fw_dbglog_level;
343
344 if (value > 0) {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.
On 09/09/2016 10:25 AM, Felix Fietkau wrote:
On 2016-08-19 03:26, gree...@candelatech.com wrote:
From: Ben Greear
I was seeing kernel crashes due to accessing freed memory
while debugging a 9984 firmware that was crashing often.
This patch fixes the crashes. I am not certain if there
is a better way or not.
Signed-off-by: Ben Greear
---
drivers/net/wireless/ath/ath10k/mac.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 5659ef1..916119c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4172,8 +4172,10 @@ static void ath10k_mac_txq_init(struct ieee80211_txq
*txq)
static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq *txq)
{
struct ath10k_txq *artxq = (void *)txq->drv_priv;
+ struct ath10k_txq *tmp, *walker;
struct ath10k_skb_cb *cb;
struct sk_buff *msdu;
+ struct ieee80211_txq *txq_tmp;
int msdu_id;
if (!txq)
@@ -4182,6 +4184,14 @@ static void ath10k_mac_txq_unref(struct ath10k *ar,
struct ieee80211_txq *txq)
spin_lock_bh(&ar->txqs_lock);
if (!list_empty(&artxq->list))
list_del_init(&artxq->list);
+
+ /* Remove from ar->txqs in case it still exists there. */
+ list_for_each_entry_safe(walker, tmp, &ar->txqs, list) {
+ txq_tmp = container_of((void *)walker, struct ieee80211_txq,
+ drv_priv);
+ if (txq_tmp == txq)
+ list_del(&walker->list);
+ }
This makes no sense at all. From txq_tmp == txq we can deduce that
walker == artxq. In the context above, it already does a
list_del_init(&artxq->list).
This fixed my problem, so something about this matters.
Possibly it works around some other race, just possibly it
is because of some other regression/bug in my driver/kernel.
I thought maybe the issue was that flushing doesn't really work
for ath10k, so when the upper stack tried to flush and delete
a station there were still skbs in the driver that were referencing
the txqs up in mac80211.
Also, this bug was triggered by firmware that crashed very often on
transmit of an skb, so in general there were skbs that were not properly
transmitted and maybe that also triggers some other bug/race in the
driver.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: accessing ath10k calibration data
It's blocked by the code below which I tried to ifdef out, but then it
returns all 0's.
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 8b01e3e..bb8b7ec 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1433,12 +1433,13 @@ static int ath10k_debug_cal_data_open(struct
inode *inode, struct file *file)
int ret;
mutex_lock(&ar->conf_mutex);
-
+#if 0
if (ar->state != ATH10K_STATE_ON &&
ar->state != ATH10K_STATE_UTF) {
ret = -ENETDOWN;
goto err;
}
+#endif
On Fri, Sep 9, 2016 at 1:39 PM, Adrian Chadd wrote:
> Hi,
>
> It's just in OTP? You should be able to read the OTP data without
> needing a STA/AP up?
>
>
> -a
>
>
> On 9 September 2016 at 10:35, Marty Faltesek wrote:
>> Is there a way to access calibration data without having to start an
>> AP (or client)?
>>
>> Thanks,
>>
>> Marty
>>
>> ___
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: accessing ath10k calibration data
Hi, It's just in OTP? You should be able to read the OTP data without needing a STA/AP up? -a On 9 September 2016 at 10:35, Marty Faltesek wrote: > Is there a way to access calibration data without having to start an > AP (or client)? > > Thanks, > > Marty > > ___ > ath10k mailing list > ath10k@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
accessing ath10k calibration data
Is there a way to access calibration data without having to start an AP (or client)? Thanks, Marty ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 1/3] ath10k: Ensure there are no stale ar->txqs entries.
On 2016-08-19 03:26, gree...@candelatech.com wrote:
> From: Ben Greear
>
> I was seeing kernel crashes due to accessing freed memory
> while debugging a 9984 firmware that was crashing often.
>
> This patch fixes the crashes. I am not certain if there
> is a better way or not.
>
> Signed-off-by: Ben Greear
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c
> b/drivers/net/wireless/ath/ath10k/mac.c
> index 5659ef1..916119c 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -4172,8 +4172,10 @@ static void ath10k_mac_txq_init(struct ieee80211_txq
> *txq)
> static void ath10k_mac_txq_unref(struct ath10k *ar, struct ieee80211_txq
> *txq)
> {
> struct ath10k_txq *artxq = (void *)txq->drv_priv;
> + struct ath10k_txq *tmp, *walker;
> struct ath10k_skb_cb *cb;
> struct sk_buff *msdu;
> + struct ieee80211_txq *txq_tmp;
> int msdu_id;
>
> if (!txq)
> @@ -4182,6 +4184,14 @@ static void ath10k_mac_txq_unref(struct ath10k *ar,
> struct ieee80211_txq *txq)
> spin_lock_bh(&ar->txqs_lock);
> if (!list_empty(&artxq->list))
> list_del_init(&artxq->list);
> +
> + /* Remove from ar->txqs in case it still exists there. */
> + list_for_each_entry_safe(walker, tmp, &ar->txqs, list) {
> + txq_tmp = container_of((void *)walker, struct ieee80211_txq,
> +drv_priv);
> + if (txq_tmp == txq)
> + list_del(&walker->list);
> + }
This makes no sense at all. From txq_tmp == txq we can deduce that
walker == artxq. In the context above, it already does a
list_del_init(&artxq->list).
- Felix
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCHv3 0/5] ath10k: Allow setting coverage class and rx cleanups
Benjamin Berg writes: > OK, another revision adding the fast path as suggested by Ben Greear. Only > other change is that I am submitting it together with Vasanthakumar's cleanup > patches to allow merging both into ath-next in one go. > > Changes in v4: > * Only queue register setting work if coverage class is non-zero > * Add cleanup patches from Vasanthakumar into series > > Changes in v3: > * Only update register values if hardware is initialized > * Use the SM/MS macros instead of manual bitshifts and masks > * Use the hardware phyclk register instead of assuming a clock speed > * Force dbglog_mask of ~0 and dbglog_level of at least WARN if active > * Only call code for selected WMI events > > The last two items are a bit of a guess for me. In particular it looks like > the default log level is already WARN, but I suppose that this should be good > enough to get reports for internal chip resets. I have no way of verifying > this myself though. > > > Benjamin Berg (1): > ath10k: Allow setting coverage class > > Vasanthakumar Thiagarajan (4): > ath10k: Move ath10k_hw_params definition to hw.h > ath10k: Add provision for Rx descriptor abstraction > ath10k: Properly remove padding from the start of rx payload > ath10k: Remove 4-addr padding related hw_param configuration There were few conflicts, though easy. Please double check the pending branch that I didn't make any mistakes, I didn't test these yet. https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/log/?h=pending Also please CC linux-wireless when submitting ath10k patches, we get wider review that way. Added it to CC now. My log of the conflicts: Applying: ath10k: Move ath10k_hw_params definition to hw.h Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging drivers/net/wireless/ath/ath10k/core.h CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/core.h Failed to merge in the changes. Patch failed at 0001 ath10k: Move ath10k_hw_params definition to hw.h moved: bool sw_decrypt_mcast_mgmt; Applying: ath10k: Add provision for Rx descriptor abstraction Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging drivers/net/wireless/ath/ath10k/hw.h CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/hw.h Auto-merging drivers/net/wireless/ath/ath10k/core.c CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/core.c Failed to merge in the changes. Patch failed at 0002 ath10k: Add provision for Rx descriptor abstraction Applying: ath10k: Allow setting coverage class fatal: sha1 information is lacking or useless (drivers/net/wireless/ath/ath10k/core.c). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 ath10k: Allow setting coverage class CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/mac.c patching file drivers/net/wireless/ath/ath10k/core.c Hunk #1 succeeded at 1548 (offset 5 lines). Hunk #2 succeeded at 2333 with fuzz 2 (offset 73 lines). patching file drivers/net/wireless/ath/ath10k/core.h Hunk #1 succeeded at 911 with fuzz 2 (offset 21 lines). patching file drivers/net/wireless/ath/ath10k/hw.c patching file drivers/net/wireless/ath/ath10k/hw.h Hunk #2 succeeded at 416 (offset 5 lines). Hunk #3 succeeded at 613 (offset 5 lines). Hunk #4 succeeded at 813 (offset 5 lines). patching file drivers/net/wireless/ath/ath10k/mac.c Hunk #1 succeeded at 5410 (offset 38 lines). Hunk #2 succeeded at 7449 (offset 38 lines). Hunk #3 succeeded at 8027 (offset 38 lines). patching file drivers/net/wireless/ath/ath10k/wmi.c Hunk #1 succeeded at 4925 (offset 46 lines). Hunk #2 succeeded at 4962 (offset 46 lines). Hunk #3 succeeded at 4972 (offset 46 lines). Hunk #4 succeeded at 4999 (offset 46 lines). Hunk #5 succeeded at 5055 (offset 46 lines). Hunk #6 succeeded at 5099 (offset 46 lines). Hunk #7 succeeded at 5109 (offset 46 lines). Hunk #8 succeeded at 5136 (offset 46 lines). Hunk #9 succeeded at 5183 (offset 46 lines). Hunk #10 succeeded at 5230 (offset 59 lines). Hunk #11 succeeded at 5240 (offset 59 lines). Hunk #12 succeeded at 5267 (offset 59 lines). Hunk #13 succeeded at 5305 (offset 59 lines). Hunk #14 succeeded at 5379 (offset 72 lines). Hunk #15 succeeded at 5396 (offset 72 lines). Hunk #16 succeeded at 5413 (offset 72 lines). Hunk #17 succeeded at 6137 (offset 73 lines). -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 0/4] ath10k: Padding related clean ups in rx
Vasanthakumar Thiagarajan writes: > This patch set adds abstraction for rx_hw_desc processing so that > we can make use of newer desc fields notifying padding information > which is done on rx payload. "ath10k: Properly remove padding from > the start of rx payload" fixes padding related bug in ethernet decap > mode for QCA99X0, QCA9984 qnd QCA4019 but even fixing this bug will > not make ethernet decap mode work, there needs to be some more fix > wich would follow this patch series. > > Vasanthakumar Thiagarajan (4): > ath10k: Move ath10k_hw_params definition to hw.h > ath10k: Add provision for Rx descriptor abstraction > ath10k: Properly remove padding from the start of rx payload > ath10k: Remove 4-addr padding related hw_param configuration As Benjamin has these patches on his own set I'm dropping this one. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 2/3] ath10k: Grab rcu_read_lock before the txqs spinlock.
gree...@candelatech.com writes:
> From: Ben Greear
>
> I was seeing some spin-lock hangs in this area of the code,
> and it seems more proper to do the rcu-read-lock outside of
> the spin lock. I am not sure how much this matters, however.
>
> Signed-off-by: Ben Greear
> ---
> drivers/net/wireless/ath/ath10k/mac.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> 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)
> int max;
> int loop_max = 2000;
>
> - spin_lock_bh(&ar->txqs_lock);
> rcu_read_lock();
> + spin_lock_bh(&ar->txqs_lock);
>
> last = list_last_entry(&ar->txqs, struct ath10k_txq, list);
> while (!list_empty(&ar->txqs)) {
> @@ -4342,8 +4342,8 @@ void ath10k_mac_tx_push_pending(struct ath10k *ar)
> break;
> }
>
> - rcu_read_unlock();
> spin_unlock_bh(&ar->txqs_lock);
> + rcu_read_unlock();
I'm no RCU expert but this isn't making any sense. Maybe it changes
timings on your kernel so that it hides the real problem?
--
Kalle Valo
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 3/3] ath10k: Improve logging message.
Mohammed Shafi Shajakhan writes: > Hi Ben, > > On Thu, Aug 18, 2016 at 06:26:35PM -0700, gree...@candelatech.com wrote: >> From: Ben Greear >> >> Helps to know the sta pointer. >> >> Signed-off-by: Ben Greear >> --- >> drivers/net/wireless/ath/ath10k/mac.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/wireless/ath/ath10k/mac.c >> b/drivers/net/wireless/ath/ath10k/mac.c >> index d96c06e..82bc0da 100644 >> --- a/drivers/net/wireless/ath/ath10k/mac.c >> +++ b/drivers/net/wireless/ath/ath10k/mac.c >> @@ -6491,8 +6491,8 @@ static int ath10k_sta_state(struct ieee80211_hw *hw, >> * Existing station deletion. >> */ >> ath10k_dbg(ar, ATH10K_DBG_MAC, >> - "mac vdev %d peer delete %pM (sta gone)\n", >> - arvif->vdev_id, sta->addr); >> + "mac vdev %d peer delete %pM (sta gone) sta: %p\n", >> + arvif->vdev_id, sta->addr, sta); > > good to rebase over Maharaja's change (%p to %pK) > https://patchwork.kernel.org/patch/9263691/ I added that to the patch in the pending branch. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: support for QCA9377 SDIO (ath10k or ath6kl)
Martin Blumenstingl writes: > is there any support for the SDIO chips QCA9377 (and QCA9378) planned? > Would these be supported by ath10k or ath6kl or is a completely new > driver needed? I'm not familiar with the details of QCA9377 SDIO firmware but I assume ath10k would be the best option for supporting it. We split from the beginning the core code (ath10k_core.ko) and the PCI code (ath10k_pci.ko) to make it easier to add new bus support. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH] ath10k: advertize hardware packet loss mechanism
kbuild test robot writes: > Hi Rajkumar, > > [auto build test ERROR on ath6kl/ath-next] > [also build test ERROR on v4.8-rc5 next-20160906] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > [Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for > convenience) to record what (public, well-known) commit your patch series was > built on] > [Check https://git-scm.com/docs/git-format-patch for more information] > > url: > https://github.com/0day-ci/linux/commits/Rajkumar-Manoharan/ath10k-advertize-hardware-packet-loss-mechanism/20160906-151148 > base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next > config: i386-randconfig-x008-201636 (attached as .config) > compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705 > reproduce: > # save the attached .config to linux build tree > make ARCH=i386 > > All error/warnings (new ones prefixed by >>): > >In file included from drivers/net/wireless/ath/ath10k/mac.h:21:0, > from drivers/net/wireless/ath/ath10k/mac.c:18: >drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_mac_register': >>> include/net/mac80211.h:2206:57: error: 'IEEE80211_HW_REPORTS_LOW_ACK' >>> undeclared (first use in this function) > #define ieee80211_hw_set(hw, flg) _ieee80211_hw_set(hw, > IEEE80211_HW_##flg) > ^ >>> drivers/net/wireless/ath/ath10k/mac.c:7884:2: note: in expansion of macro >>> 'ieee80211_hw_set' > ieee80211_hw_set(ar->hw, REPORTS_LOW_ACK); > ^~~~ >include/net/mac80211.h:2206:57: note: each undeclared identifier is > reported only once for each function it appears in > #define ieee80211_hw_set(hw, flg) _ieee80211_hw_set(hw, > IEEE80211_HW_##flg) > ^ >>> drivers/net/wireless/ath/ath10k/mac.c:7884:2: note: in expansion of macro >>> 'ieee80211_hw_set' > ieee80211_hw_set(ar->hw, REPORTS_LOW_ACK); > ^~~~ This is expected as this depends on a mac80211 patch which is not applied yet. -- Kalle Valo ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [1/2] carl9170: Fix wrong completion usage
Daniel Wagner wrote: > From: Daniel Wagner > > carl9170_usb_stop() is used from several places to flush and cleanup any > pending work. The normal pattern is to send a request and wait for the > irq handler to call complete(). The completion is not reinitialized > during normal operation and as the old comment indicates it is important > to keep calls to wait_for_completion_timeout() and complete() balanced. > > Calling complete_all() brings this equilibirum out of balance and needs > to be fixed by a reinit_completion(). But that opens a small race > window. It is possible that the sequence of complete_all(), > reinit_completion() is faster than the wait_for_completion_timeout() can > do its work. The wake up is not lost but the done counter test is after > reinit_completion() has been executed. The only reason we don't see > carl9170_exec_cmd() hang forever is we use the timeout version of > wait_for_copletion(). > > Let's fix this by reinitializing the completion (that is just setting > done counter to 0) just before we send out an request. Now, > carl9170_usb_stop() can be sure a complete() call is enough to make > progess since there is only one waiter at max. This is a common pattern > also seen in various drivers which use completion. > > Signed-off-by: Daniel Wagner Thanks, 1 patch applied to ath-next branch of ath.git: 78a9e170388b carl9170: Fix wrong completion usage -- Sent by pwcli https://patchwork.kernel.org/patch/9287819/ ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: fix reporting channel survey data
Ashok Raj Nagarajan wrote:
> When user requests for survey dump data, driver is providing wrong survey
> information. This information we sent is the survey data that we have
> collected during previous user request.
>
> This issue occurs because we request survey dump for wrong channel. With
> this change, we correctly display the correct and current survey
> information to userspace.
>
> Fixes: fa7937e3d5c2 ("ath10k: update bss channel survey information")
> Signed-off-by: Ashok Raj Nagarajan
Thanks, 1 patch applied to ath-next branch of ath.git:
77eb3d693182 ath10k: fix reporting channel survey data
--
Sent by pwcli
https://patchwork.kernel.org/patch/9310467/
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: Remove unnecessary error code assignment
Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > The error assigned does not seems to be used anywhere, > fixes nothing just a small cleanup > > Signed-off-by: Mohammed Shafi Shajakhan Thanks, 1 patch applied to ath-next branch of ath.git: fe79f6314a71 ath10k: remove unnecessary error code assignment -- Sent by pwcli https://patchwork.kernel.org/patch/9309397/ ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: ath10k: fix throughput regression in multi client mode
Rajkumar Manoharan wrote:
> commit 7a0adc83f34d ("ath10k: improve tx scheduling") is causing
> severe throughput drop in multi client mode. This issue is originally
> reported in veriwave setup with 50 clients with TCP downlink traffic.
> While increasing number of clients, the average throughput drops
> gradually. With 50 clients, the combined peak throughput is decreased
> to 98 Mbps whereas reverting given commit restored it to 550 Mbps.
>
> Processing txqs for every tx completion is causing overhead. Ideally for
> management frame tx completion, pending txqs processing can be avoided.
> The change partly reverts the commit "ath10k: improve tx scheduling".
> Processing pending txqs after all skbs tx completion will yeild enough
> room to burst tx frames.
>
> Fixes: 7a0adc83f34d ("ath10k: improve tx scheduling")
> Signed-off-by: Rajkumar Manoharan
Thanks, 1 patch applied to ath-next branch of ath.git:
18f53fe0f303 ath10k: fix throughput regression in multi client mode
--
Sent by pwcli
https://patchwork.kernel.org/patch/9303279/
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [v3] ath10k: implement NAPI support
Rajkumar Manoharan wrote: > Add NAPI support for rx and tx completion. NAPI poll is scheduled > from interrupt handler. The design is as below > > - on interrupt > - schedule napi and mask interrupts > - on poll >- process all pipes (no actual Tx/Rx) >- process Rx within budget >- if quota exceeds budget reschedule napi poll by returning budget >- process Tx completions and update budget if necessary >- process Tx fetch indications (pull-push) >- push any other pending Tx (if possible) >- before resched or napi completion replenish htt rx ring buffer >- if work done < budget, complete napi poll and unmask interrupts > > This change also get rid of two tasklets (intr_tq and txrx_compl_task). > > Measured peak throughput with NAPI on IPQ4019 platform in controlled > environment. No noticeable reduction in throughput is seen and also > observed improvements in CPU usage. Approx. 15% CPU usage got reduced > in UDP uplink case. > > DL: AP DUT Tx > UL: AP DUT Rx > > IPQ4019 (avg. cpu usage %) > > > TOT +NAPI > === = > TCP DL 644 Mbps (42%)645 Mbps (36%) > TCP UL 673 Mbps (30%)675 Mbps (26%) > UDP DL 682 Mbps (49%)680 Mbps (49%) > UDP UL 720 Mbps (28%)717 Mbps (11%) > > Signed-off-by: Rajkumar Manoharan Thanks, 1 patch applied to ath-next branch of ath.git: 3c97f5de1f28 ath10k: implement NAPI support -- Sent by pwcli https://patchwork.kernel.org/patch/9301091/ ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
