mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®