From: Felix Fietkau <nbd@openwrt.org>
To: Mark Mentovai <mark@moxienet.com>
Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com,
lrodriguez@atheros.com, vasanth@atheros.com
Subject: Re: [PATCH v2 3/4] ath9k: fix the .flush driver op implementation
Date: Thu, 10 Mar 2011 23:18:39 +0100 [thread overview]
Message-ID: <4D794E3F.2090309@openwrt.org> (raw)
In-Reply-To: <AANLkTim69R72cvpd=ACxfP8+xGNZoXRJa43=RAPzxiBv@mail.gmail.com>
On 2011-03-10 10:55 PM, Mark Mentovai wrote:
> Felix Fietkau wrote:
>> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
> [...]
>> static void ath9k_flush(struct ieee80211_hw *hw, bool drop)
>> {
>> struct ath_softc *sc = hw->priv;
>> + int timeout = 200; /* ms */
>> + int i, j;
>>
>> + ath9k_ps_wakeup(sc);
>> mutex_lock(&sc->mutex);
>>
>> cancel_delayed_work_sync(&sc->tx_complete_work);
>>
>> + if (drop)
>> + timeout = 1;
>>
>> + for (j = 0; j < timeout; j++) {
>> + int npend = 0;
>> + for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++) {
>> + if (!ATH_TXQ_SETUP(sc, i))
>> + continue;
>>
>> + npend += ath9k_has_pending_frames(sc, &sc->tx.txq[i]);
>> }
>> +
>> + if (!npend)
>> + goto out;
>> +
>> + usleep_range(1000, 2000);
>> }
>>
>> + if (!ath_drain_all_txq(sc, false))
>> ath_reset(sc, false);
>>
>> +out:
>> ieee80211_queue_delayed_work(hw, &sc->tx_complete_work, 0);
>> mutex_unlock(&sc->mutex);
>> + ath9k_ps_restore(sc);
>> }
>
> My only comment here is that you still hit the sleep even on the last
> pass through the loop when it isn’t strictly necessary. Practically,
> the only place this would be realized is the case where |drop| is set.
> In this scenario, the code formerly didn’t sleep at all, but now can
> sleep for 1-2ms. I couldn’t find any calls to drv_flush with |drop|
> set, though, so it might just be an academic concern.
>
> The delay loops in v2 patches 2/4 and 4/4 also share this
> characteristic (although with shorter timeouts, and delays instead of
> sleeps). Have you considered restructuring these loops to avoid the
> final waits?
>
> This is admittedly a pretty minor thing.
Makes sense, I'll send a v3.
- Felix
prev parent reply other threads:[~2011-03-10 22:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-10 13:41 [PATCH v2 1/4] ath9k_hw: fix REG_SET_BIT and REG_CLR_BIT for multiple bits Felix Fietkau
2011-03-10 13:41 ` [PATCH v2 2/4] ath9k: fix stopping tx dma on reset Felix Fietkau
2011-03-10 13:41 ` [PATCH v2 3/4] ath9k: fix the .flush driver op implementation Felix Fietkau
2011-03-10 13:41 ` [PATCH v2 4/4] ath9k: improve reliability of beacon transmission and stuck beacon handling Felix Fietkau
2011-03-10 21:55 ` Mark Mentovai
2011-03-10 22:13 ` Felix Fietkau
2011-03-10 22:36 ` Mark Mentovai
2011-03-10 21:55 ` [PATCH v2 3/4] ath9k: fix the .flush driver op implementation Mark Mentovai
2011-03-10 22:18 ` Felix Fietkau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D794E3F.2090309@openwrt.org \
--to=nbd@openwrt.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=lrodriguez@atheros.com \
--cc=mark@moxienet.com \
--cc=vasanth@atheros.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).