[PATCH 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device
Christoph Hellwig
hch at lst.de
Thu Sep 3 04:42:26 EDT 2020
On Wed, Sep 02, 2020 at 11:38:09PM +0200, Thomas Bogendoerfer wrote:
> the patch below fixes the problem.
But is very wrong unfortunately.
> static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr)
> {
> - dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> - DMA_FROM_DEVICE);
> + struct sgiseeq_private *sp = netdev_priv(dev);
> +
> + dma_sync_single_for_device(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> + sizeof(struct sgiseeq_rx_desc), DMA_FROM_DEVICE);
> }
>
> static inline void dma_sync_desc_dev(struct net_device *dev, void *addr)
> {
> - dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> - DMA_TO_DEVICE);
> + struct sgiseeq_private *sp = netdev_priv(dev);
> +
> + dma_sync_single_for_device(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> + sizeof(struct sgiseeq_rx_desc), DMA_TO_DEVICE);
This is not how the DMA API works. You can only call
dma_sync_single_for_{device,cpu} with the direction that the memory
was mapped. It then transfer ownership to the device or the cpu,
and the ownership of the memory is a fundamental concept that allows
for reasoning about the caching interaction.
> }
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
> good idea. [ RFC1925, 2.3 ]
---end quoted text---
More information about the Linux-nvme
mailing list