Commit b1da46d7 authored by Christoph Hellwig's avatar Christoph Hellwig
Browse files

dma-direct: simplify the use atomic pool logic in dma_direct_alloc



The logic in dma_direct_alloc when to use the atomic pool vs remapping
grew a bit unreadable.  Consolidate it into a single check, and clean
up the set_uncached vs remap logic a bit as well.

Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Reviewed-by: default avatarRobin Murphy <robin.murphy@arm.com>
Reviewed-by: default avatarGreg Ungerer <gerg@linux-m68k.org>
Tested-by: default avatarGreg Ungerer <gerg@linux-m68k.org>
parent 2c8ed1b9
Loading
Loading
Loading
Loading
+10 −15
Original line number Diff line number Diff line
@@ -234,27 +234,22 @@ void *dma_direct_alloc(struct device *dev, size_t size,
					dma_handle);

		/*
		 * Otherwise remap if the architecture is asking for it.  But
		 * given that remapping memory is a blocking operation we'll
		 * instead have to dip into the atomic pools.
		 * Otherwise we require the architecture to either be able to
		 * mark arbitrary parts of the kernel direct mapping uncached,
		 * or remapped it uncached.
		 */
		set_uncached = IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED);
		remap = IS_ENABLED(CONFIG_DMA_DIRECT_REMAP);
		if (remap) {
			if (dma_direct_use_pool(dev, gfp))
				return dma_direct_alloc_from_pool(dev, size,
						dma_handle, gfp);
		} else {
			if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED))
		if (!set_uncached && !remap)
			return NULL;
			set_uncached = true;
		}
	}

	/*
	 * Decrypting memory may block, so allocate the memory from the atomic
	 * pools if we can't block.
	 * Remapping or decrypting memory may block, allocate the memory from
	 * the atomic pools instead if we aren't allowed block.
	 */
	if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
	if ((remap || force_dma_unencrypted(dev)) &&
	    dma_direct_use_pool(dev, gfp))
		return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);

	/* we always manually zero the memory once we are done */