From: Jan Weitzel <J.Weitzel@phytec.de>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] net: cpsw: invalidate complete buffer
Date: Mon, 2 Mar 2015 08:35:47 +0100 [thread overview]
Message-ID: <20150302073547.GA2844@lws-weitzel2@phytec.de> (raw)
In-Reply-To: <1425044718.2673.8.camel@pengutronix.de>
On Fri, Feb 27, 2015 at 02:45:18PM +0100, Lucas Stach wrote:
> Am Freitag, den 27.02.2015, 14:39 +0100 schrieb Lucas Stach:
> > Am Freitag, den 27.02.2015, 14:14 +0100 schrieb Jan Weitzel:
> > > On Fri, Feb 27, 2015 at 12:47:24PM +0100, Lucas Stach wrote:
> > > > Am Freitag, den 27.02.2015, 10:56 +0100 schrieb Jan Weitzel:
> > > > > Without invalidating the complete buffer before giving it to
> > > > > dma_inv_range, we got strange packets.
> > > > >
> > > >
> > > > This is most likely not the correct fix. If this helps then our
> > > > dma_inv_range functions aren't working properly, which would be really
> > > > bad. How do those "strange packets" look like?
> > > >
> > > We saw the problem with tftp transfers of a 76 byte image. Debug print in
> > > tftp_handler
> > >
> > > good:
> > > tftp_handler: len:76 blocksize:1432 to fifo
> > > 00000000: 06 08 ba de 7d 27 e1 2c 52 2f cf 77 e0 d3 23 da ....}'.,R/.w..#.
> > > 00000010: 62 d4 42 3e 03 20 3a c2 51 aa 51 15 73 be 9e 21 b.B>. :.Q.Q.s..!
> > > 00000020: 03 ac 78 a9 e3 4f cd 4d 6d ba 93 fe 83 dc fe 82 ..x..O.Mm.......
> > > 00000030: bb f8 24 29 6e 6f 53 1c 91 52 4b 77 1b 72 ff a0 ..$)noS..RKw.r..
> > > 00000040: 5b 98 1c 20 28 09 0f 4c 93 3c 22 08 [.. (..L.<".
> > >
> > > bad:
> > > tftp_handler: len:76 blocksize:1432 to fifo:
> > > 00000000: 06 08 ba de 7d 27 e1 2c 52 2f cf 77 e0 d3 23 da ....}'.,R/.w..#.
> > > 00000010: 62 d4 6b 73 69 7a 65 00 31 34 33 32 00 b0 1b d1 b.ksize.1432....
> > > 00000020: 5b d4 78 a9 e3 4f cd 4d 6d ba 93 fe 83 dc fe 82 [.x..O.Mm.......
> > > 00000030: bb f8 24 29 6e 6f 53 1c 91 52 4b 77 1b 72 ff a0 ..$)noS..RKw.r..
> > > 00000040: 5b 98 1c 20 28 09 0f 4c 93 3c 22 08 [.. (..L.<".
> > >
> > >
> > > The ethernet package has 122 Bytes and the error in the received file is on
> > > offset 18. The data "b.ksize.1432" comes also from tftp packets.
> > >
> > This doesn't look like a problem to invalidate the cache, but more like
> > writeback of old cachelines while the hardware owns the buffer. Can you
> > try the series "Phasing out direct usage of asm/mmu.h on ARM" and see if
> > this still happens there? If I'm correct this series should fix this
> > problem.
> >
> > I'll send an updated version of this series in the evening, but you
> > should be able to correct the typo in cpsw.c yourself for testing. :)
>
> Or try this patch, which should do the same as the new cache handling,
> but may be acceptable for master.
Your patch works and invalidating after reading makes sense ;)
Can we take this for master? I'll test the series.
Tested-by: Jan Weitzel <j.weitzel@phytec.de>
>
> ------------------------>8--------------------------------------------
> From f96aec8bd87ac29247617bdcfab41048b942e899 Mon Sep 17 00:00:00 2001
> From: Lucas Stach <l.stach@pengutronix.de>
> Date: Fri, 27 Feb 2015 14:41:46 +0100
> Subject: [PATCH] net: cpsw: prevent stray cache writeback
>
> The cache should be invalidated when transfering ownership of a buffer
> to the device. Otherwise the writeback of dirty cache lines can
> corrupt the hardware written data.
>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> drivers/net/cpsw.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
> index 799fac89a2f3..301b8a9dfde5 100644
> --- a/drivers/net/cpsw.c
> +++ b/drivers/net/cpsw.c
> @@ -888,6 +888,7 @@ static int cpsw_recv(struct eth_device *edev)
> while (cpdma_process(priv, &priv->rx_chan, &buffer, &len) >= 0) {
> dma_inv_range((ulong)buffer, (ulong)buffer + len);
> net_receive(edev, buffer, len);
> + dma_inv_range((ulong)buffer, (ulong)buffer + len);
> cpdma_submit(priv, &priv->rx_chan, buffer, PKTSIZE);
> }
>
> --
> 2.1.4
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2015-03-02 7:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 9:56 [PATCH] net: cpsw: invalidate complete buffer Jan Weitzel
2015-02-27 11:47 ` Lucas Stach
2015-02-27 13:14 ` Jan Weitzel
2015-02-27 13:39 ` Lucas Stach
2015-02-27 13:45 ` Lucas Stach
2015-03-02 7:35 ` Jan Weitzel [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=20150302073547.GA2844@lws-weitzel2@phytec.de \
--to=j.weitzel@phytec.de \
--cc=barebox@lists.infradead.org \
--cc=l.stach@pengutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.