[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110712095541.GA6236@rere.qmqm.pl>
Date: Tue, 12 Jul 2011 11:55:41 +0200
From: Michał Mirosław <mirq-linux@...e.qmqm.pl>
To: Felix Fietkau <nbd@...nwrt.org>
Cc: netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
Jouni Malinen <jmalinen@...eros.com>,
Senthil Balasubramanian <senthilkumar@...eros.com>,
ath9k-devel@...ts.ath9k.org,
Vasanthakumar Thiagarajan <vasanth@...eros.com>,
Ralf Baechle <ralf@...ux-mips.org>, linux-mips@...ux-mips.org
Subject: Re: [ath9k-devel] [PATCH v2 07/46] net/wireless: ath9k: fix DMA
API usage
On Tue, Jul 12, 2011 at 12:36:06PM +0800, Felix Fietkau wrote:
> On 2011-07-11 8:52 AM, Michał Mirosław wrote:
> >Also constify buf_addr for ath9k_hw_process_rxdesc_edma() to verify
> >assumptions --- dma_sync_single_for_device() call can be removed.
> >
> >Signed-off-by: Michał Mirosław<mirq-linux@...e.qmqm.pl>
> >---
> > drivers/net/wireless/ath/ath9k/ar9003_mac.c | 4 ++--
> > drivers/net/wireless/ath/ath9k/ar9003_mac.h | 2 +-
> > drivers/net/wireless/ath/ath9k/recv.c | 10 +++-------
> > 3 files changed, 6 insertions(+), 10 deletions(-)
> >
> >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.
You're suggesting a platform implementation bug then. If the platform is not
cache-coherent, it should invalidate relevant CPU cache lines for sync_to_cpu
and unmap cases. Do other devices show such symptoms on MIPS systems?
I'm not familiar with the platform internals, so we should ask MIPS people.
[added Cc: linux-mips]
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists