Hi Arnd, On Wednesday, April 11, 2012 2:19 PM Arnd Bergmann wrote: > On Wednesday 11 April 2012, Marek Szyprowski wrote: > > Well, range sync functions are available from the early days of the dma > > mapping api (at least that's what I've found reading the change log and > > old patches). They are the correct way of doing a partial syncs on the > > buffer (usually used by the network device drivers). This patch changes > > only the internal implementation of the dma bounce functions to let > > them tunnel through dma_map_ops structure. The driver api stays > > unchanged, so driver are obliged to call dma_*_range_* functions to > > keep code clean and easy to understand. > > > > The only drawback I can see from this patch is reduced detection of > > the dma api abuse. Let us consider the following code: > > > > dma_addr = dma_map_single(dev, ptr, 64, DMA_TO_DEVICE); > > dma_sync_single_range_for_cpu(dev, dma_addr+16, 0, 32, DMA_TO_DEVICE); > > > > Without the patch such code fails, because dma bounce code is unable > > to find the bounce buffer for the given dma_address. After the patch > > the sync call will be equivalent to: > > > > dma_sync_single_range_for_cpu(dev, dma_addr, 16, 32, DMA_TO_DEVICE); > > > > which succeeds. > > > > I don't consider this as a real problem. DMA API abuse should be caught > > by debug_dma_* function family, so we can simplify the internal low-level > > implementation without losing anything. > > > > Ok, fair enough. Can you put the above text into the changelog? Yes, I will update it in the next release. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
