diff mbox series

[01/18] MIPS: lantiq: pass struct device to DMA API functions

Message ID 20190201084801.10983-2-hch@lst.de (mailing list archive)
State New, archived
Headers show
Series [01/18] MIPS: lantiq: pass struct device to DMA API functions | expand

Commit Message

Christoph Hellwig Feb. 1, 2019, 8:47 a.m. UTC
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(-)

Comments

Paul Burton Feb. 7, 2019, 11:29 p.m. UTC | #1
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
Christoph Hellwig Feb. 12, 2019, 7:45 a.m. UTC | #2
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!
Paul Burton Feb. 12, 2019, 5:41 p.m. UTC | #3
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 mbox series

Patch

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) {