[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181204142216.GB2618@lst.de>
Date: Tue, 4 Dec 2018 15:22:16 +0100
From: Christoph Hellwig <hch@....de>
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Christoph Hellwig <hch@....de>, iommu@...ts.linux-foundation.org,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
linux-kernel@...r.kernel.org, Guo Ren <ren_guo@...ky.com>,
Laura Abbott <labbott@...hat.com>,
Robin Murphy <robin.murphy@....com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 4/9] dma-mapping: move the arm64 ncoherent alloc/free
support to common code
> > +int __init dma_atomic_pool_init(gfp_t gfp, pgprot_t prot)
> > +{
> > + unsigned int pool_size_order = get_order(atomic_pool_size);
> > + unsigned long nr_pages = atomic_pool_size >> PAGE_SHIFT;
> > + struct page *page;
> > + void *addr;
> > + int ret;
> > +
> > + if (dev_get_cma_area(NULL))
> > + page = dma_alloc_from_contiguous(NULL, nr_pages,
> > + pool_size_order, false);
> > + else
> > + page = alloc_pages(gfp, pool_size_order);
> > + if (!page)
> > + goto out;
> > +
> > + memset(page_address(page), 0, atomic_pool_size);
>
> Note that this won't work if 'page' is a highmem page - should there
> be a check for that, or a check for the gfp flags?
>
> Also, is this memset() actually useful, or a waste of cycles - when we
> allocate from this pool (see dma_alloc_from_pool()), we always memset()
> the buffer.
Currently there is no user that supports highmem, but yes, the memset
should probably simply be removed.
Powered by blists - more mailing lists