From: Ralf Baechle <ralf@linux-mips.org>
To: Felix Fietkau <nbd@openwrt.org>
Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
"Jouni Malinen" <jmalinen@atheros.com>,
"Senthil Balasubramanian" <senthilkumar@atheros.com>,
ath9k-devel@venema.h4ckr.net,
"Vasanthakumar Thiagarajan" <vasanth@atheros.com>
Subject: Re: [ath9k-devel] [PATCH v2 07/46] net/wireless: ath9k: fix DMA API usage
Date: Tue, 12 Jul 2011 20:32:04 +0100 [thread overview]
Message-ID: <20110712193204.GB13413@linux-mips.org> (raw)
In-Reply-To: <4E1BCF36.2010506@openwrt.org>
On Tue, Jul 12, 2011 at 12:36:06PM +0800, Felix Fietkau wrote:
> >diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
> >index 70dc8ec..c5f46d5 100644
> >--- a/drivers/net/wireless/ath/ath9k/recv.c
> >+++ b/drivers/net/wireless/ath/ath9k/recv.c
> >@@ -684,15 +684,11 @@ static bool ath_edma_get_buffers(struct ath_softc *sc,
> > BUG_ON(!bf);
> >
> > dma_sync_single_for_cpu(sc->dev, bf->bf_buf_addr,
> >- common->rx_bufsize, DMA_FROM_DEVICE);
> >+ common->rx_bufsize, DMA_BIDIRECTIONAL);
> >
> > ret = ath9k_hw_process_rxdesc_edma(ah, NULL, skb->data);
> >- if (ret == -EINPROGRESS) {
> >- /*let device gain the buffer again*/
> >- dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
> >- common->rx_bufsize, DMA_FROM_DEVICE);
> >+ if (ret == -EINPROGRESS)
> > return false;
> >- }
> >
> > __skb_unlink(skb,&rx_edma->rx_fifo);
> > if (ret == -EINVAL) {
> I have strong doubts about this change. On most MIPS devices,
> dma_sync_single_for_cpu is a no-op, whereas
> dma_sync_single_for_device flushes the cache range. With this
> change, the CPU could cache the DMA status part behind skb->data and
> that cache entry would not be flushed inbetween calls to this
> functions on the same buffer, likely leading to rx stalls.
The code was already broken before. By the time dma_sync_single_for_cpu
and ath9k_hw_process_rxdesc_edma are called, the DMA engine may still be
active in the buffer, yet the driver is looking at it.
dma_sync_single_for_cpu() is part of changing the buffer ownership from
the device to the CPU. When it is being called, DMA into the buffer should
already have been completed ... or else the shit may hit the jet engine.
Imagine what would happen on a hypothetic cache architecture which does not
have a dirty bit, that is which would have to write back every cache line -
even clean lines - to memory in order to evict it. Corruption.
And don't argue with what the actual MIPS implementation of dma_sync_single_-
for-{cpu,device} is doing. It's meant to bee treated as a black box; that
abstraction is the whole point of the ABI. And it seems the driver is also
being used on other architectures than MIPS …
Ralf
next prev parent reply other threads:[~2011-07-12 19:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1310339688.git.mirq-linux@rere.qmqm.pl>
2011-07-11 0:52 ` [PATCH v2 04/46] net/wireless: p54: remove useless dma_sync_single_for_device(DMA_FROM_DEVICE) Michał Mirosław
2011-07-11 15:15 ` Pavel Roskin
2011-07-12 4:50 ` Felix Fietkau
2011-07-11 0:52 ` [PATCH v2 07/46] net/wireless: ath9k: fix DMA API usage Michał Mirosław
2011-07-12 4:36 ` [ath9k-devel] " Felix Fietkau
2011-07-12 5:30 ` Ben Greear
2011-07-12 9:55 ` Michał Mirosław
2011-07-12 12:54 ` Felix Fietkau
2011-07-12 13:03 ` Michał Mirosław
2011-07-12 14:21 ` Felix Fietkau
2011-07-12 15:58 ` Michał Mirosław
2011-07-12 16:04 ` Felix Fietkau
2011-07-12 19:13 ` Michał Mirosław
2011-07-12 19:32 ` Ralf Baechle [this message]
2011-07-12 20:53 ` Michał Mirosław
2011-07-12 20:59 ` Michał Mirosław
2011-07-11 0:52 ` [PATCH v2 08/46] net/wireless: b43: fix DMA direction for RX buffers Michał Mirosław
2011-07-11 0:52 ` [PATCH v2 15/46] net/wireless: b43: use kfree_skb() for untouched skbs Michał Mirosław
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=20110712193204.GB13413@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=ath9k-devel@venema.h4ckr.net \
--cc=jmalinen@atheros.com \
--cc=linux-wireless@vger.kernel.org \
--cc=mirq-linux@rere.qmqm.pl \
--cc=nbd@openwrt.org \
--cc=netdev@vger.kernel.org \
--cc=senthilkumar@atheros.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).