From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Anders Larsen <al@alarsen.net>,
Iwo Mergler <iwo@call-direct.com.au>,
linux-mtd@lists.infradead.org,
Artem Bityutskiy <Artem.Bityutskiy@nokia.com>,
Ian McDonnell <ian@brightstareng.com>,
Nicolas Pitre <nico@fluxnic.net>,
linux-kernel@vger.kernel.org,
Matthias Kaehlcke <matthias@kaehlcke.net>,
David Woodhouse <dwmw2@infradead.org>,
Haavard Skinnemoen <hskinnemoen@atmel.com>
Subject: Re: [PATCH] Fix Oops with Atmel SPI
Date: Fri, 28 May 2010 11:27:44 +0200 [thread overview]
Message-ID: <20100528112744.579dc556@hskinnemoen-d830> (raw)
In-Reply-To: <20100521120106.d955c78b.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 19 May 2010 13:05:00 +0200
> Anders Larsen <al@alarsen.net> wrote:
>
> > On 2010-04-22 00:24:10, Andrew Morton wrote:
> > > Finally.. Wouldn't it be better to just fix the atmel SPI driver so
> > > that it doesn't barf when handed vmalloc'ed memory? Who do we ridicule
> > > about that? <checks, adds cc>
> >
> > You mean something like this instead?
>
> That looks simple enough. How do we get it tested, changelogged and
> merged up? Haavard, can you please take a look?
Sure. Sorry for the late response; I've been traveling for the last two
weeks.
Did anyone check what other drivers do to handle this case? Surely this
isn't the only driver which supports DMA?
> > diff --git a/drivers/spi/atmel_spi.c b/drivers/spi/atmel_spi.c
> > index c4e0442..a9ad5e8 100644
> > --- a/drivers/spi/atmel_spi.c
> > +++ b/drivers/spi/atmel_spi.c
> > @@ -352,16 +352,30 @@ atmel_spi_dma_map_xfer(struct atmel_spi *as, struct spi_transfer *xfer)
> >
> > xfer->tx_dma = xfer->rx_dma = INVALID_DMA_ADDRESS;
> > if (xfer->tx_buf) {
> > - xfer->tx_dma = dma_map_single(dev,
> > - (void *) xfer->tx_buf, xfer->len,
> > - DMA_TO_DEVICE);
> > + if (is_vmalloc_addr(xfer->tx_buf))
> > + xfer->tx_dma = dma_map_page(dev,
> > + vmalloc_to_page(xfer->tx_buf),
> > + (unsigned long)xfer->tx_buf & (PAGE_SIZE-1),
> > + xfer->len,
> > + DMA_TO_DEVICE);
Ok, this should be fine for small transfers, but what happens if the
transfer crosses a page boundary? Are there any guarantees that this
will never happen? What callers are passing vmalloc'ed memory in the
first place?
Ditto for the rx path.
Haavard
next prev parent reply other threads:[~2010-05-28 9:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-13 11:31 Anders Larsen
2010-04-14 7:30 ` Iwo Mergler
2010-04-14 7:57 ` Anders Larsen
2010-04-14 18:13 ` Kevin Cernekee
2010-04-15 7:32 ` Iwo Mergler
2010-04-21 22:24 ` Andrew Morton
2010-05-19 11:05 ` Anders Larsen
2010-05-21 19:01 ` Andrew Morton
2010-05-24 15:09 ` Ian McDonnell
2010-05-28 9:27 ` Haavard Skinnemoen [this message]
2010-04-27 12:57 ` Artem Bityutskiy
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=20100528112744.579dc556@hskinnemoen-d830 \
--to=haavard.skinnemoen@atmel.com \
--cc=Artem.Bityutskiy@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=al@alarsen.net \
--cc=dwmw2@infradead.org \
--cc=hskinnemoen@atmel.com \
--cc=ian@brightstareng.com \
--cc=iwo@call-direct.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=matthias@kaehlcke.net \
--cc=nico@fluxnic.net \
/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
all inboxes | Powered by JetHome®