Re: [PATCH] Fix Oops with Atmel SPI

From: Artem Bityutskiy
Date: Tue Apr 27 2010 - 09:02:10 EST


On Tue, 2010-04-13 at 13:31 +0200, Anders Larsen wrote:
> Tweak MTD's cache allocation to make it work with the atmel DMA'ed SPI.
> Substitute kmalloc for vmalloc so the cache buffer is mappable as per
> the Atmel SPI driver's requirements, otherwise an Oops would occur.
>
> The original patch by Ian McDonnell <ian@xxxxxxxxxxxxxxxxx> was found here:
> http://lists.infradead.org/pipermail/linux-mtd/2007-December/020184.html
>
> Signed-off-by: Anders Larsen <al@xxxxxxxxxxx>
> Cc: Ian McDonnell <ian@xxxxxxxxxxxxxxxxx>
> Cc: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
> Cc: Matthias Kaehlcke <matthias@xxxxxxxxxxxx>
> Cc: Artem Bityutskiy <Artem.Bityutskiy@xxxxxxxxx>
> Cc: Nicolas Pitre <nico@xxxxxxxxxxx>
> ---
> drivers/mtd/mtdblock.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> Index: b/drivers/mtd/mtdblock.c
> ===================================================================
> --- a/drivers/mtd/mtdblock.c
> +++ b/drivers/mtd/mtdblock.c
> @@ -253,7 +253,11 @@ static int mtdblock_writesect(struct mtd
> {
> struct mtdblk_dev *mtdblk = mtdblks[dev->devnum];
> if (unlikely(!mtdblk->cache_data && mtdblk->cache_size)) {
> +#ifdef CONFIG_SPI_ATMEL
> + mtdblk->cache_data = kmalloc(mtdblk->mtd->erasesize, GFP_KERNEL);
> +#else
> mtdblk->cache_data = vmalloc(mtdblk->mtd->erasesize);
> +#endif
> if (!mtdblk->cache_data)
> return -EINTR;
> /* -EINTR is not really correct, but it is the best match
> @@ -322,7 +326,11 @@ static int mtdblock_release(struct mtd_b
> mtdblks[dev] = NULL;
> if (mtdblk->mtd->sync)
> mtdblk->mtd->sync(mtdblk->mtd);
> +#ifdef CONFIG_SPI_ATMEL
> + kfree(mtdblk->cache_data);
> +#else
> vfree(mtdblk->cache_data);
> +#endif
> kfree(mtdblk);
> }

This is an old problem. Instead of doing this dirty hack, change the
code and teach it to work with array of 1-4 pages , not with buffers.

--
Best Regards,
Artem Bityutskiy (ÐÑÑÑÐ ÐÐÑÑÑÐÐÐ)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/