From: David Gibson <david@gibson.dropbear.id.au>
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Workaround for USB DMA bugs
Date: Thu, 4 Apr 2002 16:30:51 +1000 [thread overview]
Message-ID: <20020404063051.GP21034@zax> (raw)
In-Reply-To: <3CABEDE9.5020404@embeddededge.com>
On Thu, Apr 04, 2002 at 01:08:41AM -0500, Dan Malek wrote:
>
> David Gibson wrote:
>
> >Possibly a better approach would be to make the consistent_sync()
> >function be more careful and flush rather than invalidate cachelines
>
> That's basically what this patch does, with the overhead of always
> writing instead of just invalidating. We just went the whole circle
> here, as this isn't a logically correct solution :-).
No, it's not, but:
a) It reduces the impact of DMA bugs - this way code which fails to
properly align its DMA buffers runs the risk of corrupting its DMA
transfers, but it won't corrupt other random data structures. In
particular DMA buffers on the stack won't cause evil stack corruption
which is a complete PITA to debug (I spent a full day of extreme
frustration tracking this one down).
b) It means that consistent_sync() itself has a safe interface - it
won't damage data outside the region specified. Which means it can be
used by code which does use non-aligned DMA buffers safely -
i.e. where it knows the surrounding memory won't be touched near the
transfer itself (between the consistent_sync() and the completion of
DMA). That could have an application in a driver which allocated a
bunch of DMA buffers each with some attached bookeeping information.
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong. -- H.L. Mencken
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-04-04 6:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-03 2:43 Workaround for USB DMA bugs David Gibson
2002-04-03 8:17 ` Armin
2002-04-03 17:39 ` Frank Rowand
2002-04-03 17:49 ` Dan Malek
2002-04-03 20:43 ` David Blythe
2002-04-03 23:34 ` David Gibson
2002-04-03 9:45 ` "David Müller (ELSOFT AG)"
2002-04-03 23:35 ` David Gibson
2002-04-03 17:42 ` Dan Malek
2002-04-03 23:40 ` David Gibson
2002-04-04 2:54 ` Dan Malek
2002-04-04 3:48 ` David Gibson
2002-04-04 4:09 ` Dan Malek
2002-04-04 5:23 ` David Gibson
2002-04-04 6:08 ` Dan Malek
2002-04-04 6:30 ` David Gibson [this message]
2002-04-04 20:21 ` David Blythe
2002-04-04 12:35 ` Brad Parker
2002-04-04 14:12 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
2002-04-04 4:19 Jeremy Rosen
2002-04-04 6:16 ` Dan Malek
2002-04-04 6:32 ` David Gibson
2002-04-04 6:40 Rosen Jeremy
2002-04-04 6:52 ` David Gibson
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=20020404063051.GP21034@zax \
--to=david@gibson.dropbear.id.au \
--cc=linuxppc-embedded@lists.linuxppc.org \
/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).