On Mon, Dec 12, 2011 at 09:06:25PM +0100, Felix Fietkau wrote:
> Instead of releasing and taking back the lock over and over again in the
> tx path, hold the lock a bit longer, requiring much fewer lock/unlock pairs.
> This makes locking much easier to review and should not have any noticeable
> performance/latency impact.
>
> Signed-off-by: Felix Fietkau <nbd@xxxxxxxxxxx>
> @@ -2259,6 +2230,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
> struct list_head bf_head;
> int status;
>
> + spin_lock_bh(&txq->axq_lock);
> for (;;) {
> if (work_pending(&sc->hw_reset_work))
> break;
Pretty sure this is wrong -- gcc seems to agree:
CC [M] drivers/net/wireless/ath/ath9k/xmit.o
drivers/net/wireless/ath/ath9k/xmit.c: In function ‘ath_tx_edma_tasklet’:
drivers/net/wireless/ath/ath9k/xmit.c:2249:18: warning: ‘txq’ may be used uninitialized in this function
> @@ -2278,12 +2250,8 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
>
> txq = &sc->tx.txq[ts.qid];
>
> - spin_lock_bh(&txq->axq_lock);
> -
> - if (list_empty(&txq->txq_fifo[txq->txq_tailidx])) {
> - spin_unlock_bh(&txq->axq_lock);
> - return;
> - }
> + if (list_empty(&txq->txq_fifo[txq->txq_tailidx]))
> + break;
>
> bf = list_first_entry(&txq->txq_fifo[txq->txq_tailidx],
> struct ath_buf, list);
Looks like txq doesn't get initialized until this loop?
--
John W. Linville Someday the world will need a hero, and you
linville@xxxxxxxxxxxxx might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
