Messages in this thread | | | From | Trent Piepho <> | Subject | Re: [PATCH 0/3] mtd: spi-nor: fix DMA-unsafe buffer issue between MTD and SPI | Date | Tue, 26 Dec 2017 18:45:28 +0000 |
| |
On Sun, 2017-12-24 at 05:36 +0100, Cyrille Pitchen wrote: > this series tries to solve a long time issue of compatibility between the > MTD and SPI sub-systems about whether we should use DMA-safe memory.
Can this should replace SoC specific fixes like:
c687c46e9e45 spi: spi-ti-qspi: Use bounce buffer if read buffer is not DMA'ble
7094576ccdc3 spi: atmel: fix corrupted data issue on SAM9 family SoCs
Or, since this only fixes instances of DMA-unsafe buffers used in access to SPI NOR flash chips, and since there are other SPI master interface users, those chip specific fixes in some/all spi master drivers are still needed to fix transfers not originated via spi-nor? Or are all the previous fixes necessary because of spi-nor flash (via ubifs or jffs2) and once that's fixed via this series there are no more originators of dma-unsafe buffers?
> The SPI sub-system has already implemented a work-around on its side, > based on the spi_map_buf() function. However this function has its own > limitation too. Especially, even if it builds a 'struct scatterlist' from > a vmalloc'ed buffer, calling dma_map_sg() is still not safe on all > architectures. Especially, on ARM cores using either VIPT or VIVT data > caches, dma_map_sg() doesn't take the cache aliases issue into account. > Then numerous crashes were reported for such architectures.
Could the above issue also be fixed via calls to flush_kernel_vmap_range() and invalidate_kernel_vmap_range() to keep the data cache valid? Or is there a reason that won't work? | |