| Message ID | 20190201084801.10983-2-hch@lst.de (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | [01/18] MIPS: lantiq: pass struct device to DMA API functions | expand |
Hi Christoph, On Fri, Feb 01, 2019 at 09:47:44AM +0100, Christoph Hellwig wrote: > The DMA API generally relies on a struct device to work properly, and > only barely works without one for legacy reasons. Pass the easily > available struct device from the platform_device to remedy this. > > Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory > allocation, as we aren't in interrupt context or under a lock. > > Note that this whole function looks somewhat bogus given that we never > even look at the returned dma address, and the CPHYSADDR magic on > a returned noncached mapping looks "interesting". But I'll leave > that to people more familiar with the code to sort out. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > arch/mips/lantiq/xway/vmmc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Would you like this to go through the MIPS tree or elsewhere? If the latter: Acked-by: Paul Burton <paul.burton@mips.com> Thanks, Paul
On Thu, Feb 07, 2019 at 11:29:14PM +0000, Paul Burton wrote: > Would you like this to go through the MIPS tree or elsewhere? If the > latter: > > Acked-by: Paul Burton <paul.burton@mips.com> Please pick it up through the mips tree!
Hello, Christoph Hellwig wrote: > The DMA API generally relies on a struct device to work properly, and > only barely works without one for legacy reasons. Pass the easily > available struct device from the platform_device to remedy this. > > Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory > allocation, as we aren't in interrupt context or under a lock. > > Note that this whole function looks somewhat bogus given that we never > even look at the returned dma address, and the CPHYSADDR magic on > a returned noncached mapping looks "interesting". But I'll leave > that to people more familiar with the code to sort out. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Applied to mips-fixes. Thanks, Paul [ This message was auto-generated; if you believe anything is incorrect then please email paul.burton@mips.com to report it. ]
diff --git a/arch/mips/lantiq/xway/vmmc.c b/arch/mips/lantiq/xway/vmmc.c index 577ec81b557d..3deab9a77718 100644 --- a/arch/mips/lantiq/xway/vmmc.c +++ b/arch/mips/lantiq/xway/vmmc.c @@ -31,8 +31,8 @@ static int vmmc_probe(struct platform_device *pdev) dma_addr_t dma; cp1_base = - (void *) CPHYSADDR(dma_alloc_coherent(NULL, CP1_SIZE, - &dma, GFP_ATOMIC)); + (void *) CPHYSADDR(dma_alloc_coherent(&pdev->dev, CP1_SIZE, + &dma, GFP_KERNEL)); gpio_count = of_gpio_count(pdev->dev.of_node); while (gpio_count > 0) {
The DMA API generally relies on a struct device to work properly, and only barely works without one for legacy reasons. Pass the easily available struct device from the platform_device to remedy this. Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory allocation, as we aren't in interrupt context or under a lock. Note that this whole function looks somewhat bogus given that we never even look at the returned dma address, and the CPHYSADDR magic on a returned noncached mapping looks "interesting". But I'll leave that to people more familiar with the code to sort out. Signed-off-by: Christoph Hellwig <hch@lst.de> --- arch/mips/lantiq/xway/vmmc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)