kernel/git/stable/linux-stable.git/lib/dma-direct.c, branch master

dma-mapping: move all DMA mapping code to kernel/dma

2018-06-14T06:50:37+00:00

Currently the code is split over various files with dma- prefixes in the lib/ and drives/base directories, and the number of files keeps growing. Move them into a single directory to keep the code together and remove the file name prefixes. To match the irq infrastructure this directory is placed under the kernel/ directory. Signed-off-by: Christoph Hellwig

dma-direct: don't crash on device without dma_mask

2018-05-31T16:35:36+00:00

Print a useful warning instead. Reported-by: Finn Thain Tested-by: Finn Thain Signed-off-by: Christoph Hellwig

core, dma-direct: add a flag 32-bit dma limits

2018-05-28T10:46:54+00:00

Various PCI bridges (VIA PCI, Xilinx PCIe) limit DMA to only 32-bits even if the device itself supports more. Add a single bit flag to struct device (to be moved into the dma extension once we get to it) to flag such devices and reject larger DMA to them. Signed-off-by: Christoph Hellwig Reviewed-by: Greg Kroah-Hartman

dma-mapping: provide a generic dma-noncoherent implementation

2018-05-19T06:46:12+00:00

Add a new dma_map_ops implementation that uses dma-direct for the address mapping of streaming mappings, and which requires arch-specific implemenations of coherent allocate/free. Architectures have to provide flushing helpers to ownership trasnfers to the device and/or CPU, and can provide optional implementations of the coherent mmap functionality, and the cache_flush routines for non-coherent long term allocations. Signed-off-by: Christoph Hellwig Tested-by: Alexey Brodkin Acked-by: Vineet Gupta

PCI: remove PCI_DMA_BUS_IS_PHYS

2018-05-07T05:15:41+00:00

This was used by the ide, scsi and networking code in the past to determine if they should bounce payloads. Now that the dma mapping always have to support dma to all physical memory (thanks to swiotlb for non-iommu systems) there is no need to this crude hack any more. Signed-off-by: Christoph Hellwig Acked-by: Palmer Dabbelt (for riscv) Reviewed-by: Jens Axboe

dma-direct: try reallocation with GFP_DMA32 if possible

2018-05-07T05:15:41+00:00

As the recent swiotlb bug revealed, we seem to have given up the direct DMA allocation too early and felt back to swiotlb allocation. The reason is that swiotlb allocator expected that dma_direct_alloc() would try harder to get pages even below 64bit DMA mask with GFP_DMA32, but the function doesn't do that but only deals with GFP_DMA case. This patch adds a similar fallback reallocation with GFP_DMA32 as we've done with GFP_DMA. The condition is that the coherent mask is smaller than 64bit (i.e. some address limitation), and neither GFP_DMA nor GFP_DMA32 is set beforehand. Signed-off-by: Takashi Iwai Signed-off-by: Christoph Hellwig

dma-direct: don't retry allocation for no-op GFP_DMA

2018-04-23T12:43:27+00:00

When an allocation with lower dma_coherent mask fails, dma_direct_alloc() retries the allocation with GFP_DMA. But, this is useless for architectures that hav no ZONE_DMA. Fix it by adding the check of CONFIG_ZONE_DMA before retrying the allocation. Fixes: 95f183916d4b ("dma-direct: retry allocations using GFP_DMA for small masks") Signed-off-by: Takashi Iwai Signed-off-by: Christoph Hellwig

dma-mapping: Don't clear GFP_ZERO in dma_alloc_attrs

2018-03-28T15:34:23+00:00

Revert the clearing of __GFP_ZERO in dma_alloc_attrs and move it to dma_direct_alloc for now. While most common architectures always zero dma cohereny allocations (and x86 did so since day one) this is not documented and at least arc and s390 do not zero without the explicit __GFP_ZERO argument. Fixes: 57bf5a8963f8 ("dma-mapping: clear harmful GFP_* flags in common code") Reported-by: Evgeniy Didin Reported-by: Sebastian Ott Signed-off-by: Christoph Hellwig Signed-off-by: Thomas Gleixner Tested-by: Evgeniy Didin Cc: iommu@lists.linux-foundation.org Link: https://lkml.kernel.org/r/20180328133535.17302-2-hch@lst.de

dma/direct: Handle force decryption for DMA coherent buffers in common code

2018-03-20T09:01:59+00:00

With that in place the generic DMA-direct routines can be used to allocate non-encrypted bounce buffers, and the x86 SEV case can use the generic swiotlb ops including nice features such as using CMA allocations. Note that I'm not too happy about using sev_active() in DMA-direct, but I couldn't come up with a good enough name for a wrapper to make it worth adding. Tested-by: Tom Lendacky Signed-off-by: Christoph Hellwig Reviewed-by: Thomas Gleixner Cc: David Woodhouse Cc: Joerg Roedel Cc: Jon Mason Cc: Konrad Rzeszutek Wilk Cc: Linus Torvalds Cc: Muli Ben-Yehuda Cc: Peter Zijlstra Cc: iommu@lists.linux-foundation.org Link: http://lkml.kernel.org/r/20180319103826.12853-14-hch@lst.de Signed-off-by: Ingo Molnar

dma-direct: comment the dma_direct_free calling convention

2018-02-12T15:59:07+00:00

Signed-off-by: Christoph Hellwig