From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:10
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes.
This series contains all easy conversions to pass a struct device,
besides that there also is some arch code that needs separate handling,
a driver that should not use the DMA API at all, and one that is
a complete basket case to be deal with separately.
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:16
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/dma/imx-sdma.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
@@ -677,7 +677,7 @@ static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,intret;unsignedlongflags;-buf_virt=dma_alloc_coherent(NULL,size,&buf_phys,GFP_KERNEL);+buf_virt=dma_alloc_coherent(sdma->dev,size,&buf_phys,GFP_KERNEL);if(!buf_virt){return-ENOMEM;}
@@ -696,7 +696,7 @@ static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,spin_unlock_irqrestore(&sdma->channel_0_lock,flags);-dma_free_coherent(NULL,size,buf_virt,buf_phys);+dma_free_coherent(sdma->dev,size,buf_virt,buf_phys);returnret;}
@@ -1182,8 +1182,8 @@ static int sdma_request_channel0(struct sdma_engine *sdma){intret=-EBUSY;-sdma->bd0=dma_alloc_coherent(NULL,PAGE_SIZE,&sdma->bd0_phys,-GFP_NOWAIT);+sdma->bd0=dma_alloc_coherent(sdma->dev,PAGE_SIZE,&sdma->bd0_phys,+GFP_NOWAIT);if(!sdma->bd0){ret=-ENOMEM;gotoout;
@@ -1842,7 +1842,7 @@ static int sdma_init(struct sdma_engine *sdma)/* Be sure SDMA has not started yet */writel_relaxed(0,sdma->regs+SDMA_H_C0PTR);-sdma->channel_control=dma_alloc_coherent(NULL,+sdma->channel_control=dma_alloc_coherent(sdma->dev,MAX_DMA_CHANNELS*sizeof(structsdma_channel_control)+sizeof(structsdma_context_data),&ccb_phys,GFP_KERNEL);
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:20
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 the proper Kconfig symbol to check for DMA API availability.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/caif/caif_spi.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:24
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/cadence/macb_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:31
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.
Note this driver seems to lack dma_unmap_* calls entirely, but fixing
that is left for another time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/lantiq_etop.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:34
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/sgi/meth.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
@@ -68,6 +68,8 @@ module_param(timeout, int, 0);*packetsinandout,sothereisplaceforapacket*/structmeth_private{+structplatform_device*pdev;+/* in-memory copy of MAC Control register */u64mac_ctrl;
@@ -236,7 +238,7 @@ static int meth_init_rx_ring(struct meth_private *priv)priv->rx_ring[i]=(rx_packet*)(priv->rx_skbs[i]->head);/* I'll need to re-sync it after each RX */priv->rx_ring_dmas[i]-dma_map_single(NULL,priv->rx_ring[i],+dma_map_single(&priv->pdev->dev,priv->rx_ring[i],METH_RX_BUFF_SIZE,DMA_FROM_DEVICE);mace->eth.rx_fifo=priv->rx_ring_dmas[i];}
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:38
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/smsc/smc911x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:44
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/parport/parport_ip32.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:49
gbefb uses managed resources, so it should do the same for DMA
allocations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/video/fbdev/gbefb.c | 24 ++++++++----------------
1 file changed, 8 insertions(+), 16 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:53
Just like we do for all other DMA operations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/video/fbdev/pxa3xx-gcu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:48:59
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_USER as the gfp_t for the memory
allocation, as we should treat this allocation as a normal kernel one.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
sound/mips/sgio2audio.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
@@ -805,7 +805,7 @@ static int snd_sgio2audio_free(struct snd_sgio2audio *chip)free_irq(snd_sgio2_isr_table[i].irq,&chip->channel[snd_sgio2_isr_table[i].idx]);-dma_free_coherent(NULL,MACEISA_RINGBUFFERS_SIZE,+dma_free_coherent(chip->card->dev,MACEISA_RINGBUFFERS_SIZE,chip->ring_base,chip->ring_base_dma);/* release card data */
@@ -843,8 +843,9 @@ static int snd_sgio2audio_create(struct snd_card *card,chip->card=card;-chip->ring_base=dma_alloc_coherent(NULL,MACEISA_RINGBUFFERS_SIZE,-&chip->ring_base_dma,GFP_USER);+chip->ring_base=dma_alloc_coherent(card->dev,+MACEISA_RINGBUFFERS_SIZE,+&chip->ring_base_dma,GFP_KERNEL);if(chip->ring_base=NULL){printk(KERN_ERR"sgio2audio: could not allocate ring buffers\n");
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:49:06
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
sound/mips/hal2.c | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:49:23
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/video/fbdev/da8xx-fb.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:49:37
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/usb/gadget/udc/fotg210-udc.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:50:16
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.
Note that this driver seems to entirely lack dma_map_single error
handling, but that is left for another time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/marvell/pxa168_eth.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
@@ -201,6 +201,7 @@ struct tx_desc {};structpxa168_eth_private{+structplatform_device*pdev;intport_num;/* User Ethernet port number */intphy_addr;intphy_speed;
@@ -743,7 +744,7 @@ static int txq_reclaim(struct net_device *dev, int force)netdev_err(dev,"Error in TX\n");dev->stats.tx_errors++;}-dma_unmap_single(NULL,addr,count,DMA_TO_DEVICE);+dma_unmap_single(&pep->pdev->dev,addr,count,DMA_TO_DEVICE);if(skb)dev_kfree_skb_irq(skb);released++;
@@ -805,7 +806,7 @@ static int rxq_process(struct net_device *dev, int budget)if(rx_next_curr_desc=rx_used_desc)pep->rx_resource_err=1;pep->rx_desc_count--;-dma_unmap_single(NULL,rx_desc->buf_ptr,+dma_unmap_single(&pep->pdev->dev,rx_desc->buf_ptr,rx_desc->buf_size,DMA_FROM_DEVICE);received_packets++;
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:50:27
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/moxa/moxart_ether.c | 11 +++++++----
drivers/net/ethernet/moxa/moxart_ether.h | 1 +
2 files changed, 8 insertions(+), 4 deletions(-)
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:50:44
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/ethernet/amd/au1000_eth.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
@@ -1167,7 +1167,7 @@ static int au1000_probe(struct platform_device *pdev)/* Allocate the data buffers*Snoopingworksfinewithethonallau1xxx*/-aup->vaddr=(u32)dma_alloc_attrs(NULL,MAX_BUF_SIZE*+aup->vaddr=(u32)dma_alloc_attrs(&pdev->dev,MAX_BUF_SIZE*(NUM_TX_BUFFS+NUM_RX_BUFFS),&aup->dma_addr,0,DMA_ATTR_NON_CONSISTENT);
@@ -1349,7 +1349,7 @@ static int au1000_probe(struct platform_device *pdev)err_remap2:iounmap(aup->mac);err_remap1:-dma_free_attrs(NULL,MAX_BUF_SIZE*(NUM_TX_BUFFS+NUM_RX_BUFFS),+dma_free_attrs(&pdev->dev,MAX_BUF_SIZE*(NUM_TX_BUFFS+NUM_RX_BUFFS),(void*)aup->vaddr,aup->dma_addr,DMA_ATTR_NON_CONSISTENT);err_vaddr:
@@ -1383,7 +1383,7 @@ static int au1000_remove(struct platform_device *pdev)if(aup->tx_db_inuse[i])au1000_ReleaseDB(aup,aup->tx_db_inuse[i]);-dma_free_attrs(NULL,MAX_BUF_SIZE*(NUM_TX_BUFFS+NUM_RX_BUFFS),+dma_free_attrs(&pdev->dev,MAX_BUF_SIZE*(NUM_TX_BUFFS+NUM_RX_BUFFS),(void*)aup->vaddr,aup->dma_addr,DMA_ATTR_NON_CONSISTENT);
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 08:51:16
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(-)
On Fri, 01 Feb 2019 09:48:00 +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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Looks good to me:
Reviewed-by: Takashi Iwai [off-list ref]
Shall I take this one through sound git tree or all through yours?
thanks,
Takashi
On Fri, 01 Feb 2019 09:48:01 +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_USER as the gfp_t for the memory
allocation, as we should treat this allocation as a normal kernel one.
Signed-off-by: Christoph Hellwig <hch@lst.de>
On Fri, 01 Feb 2019 09:47:43 +0100,
Christoph Hellwig wrote:
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes.
This series contains all easy conversions to pass a struct device,
besides that there also is some arch code that needs separate handling,
a driver that should not use the DMA API at all, and one that is
a complete basket case to be deal with separately.
Actually there are a bunch of ISA sound drivers that still call
allocators with NULL device.
The patch below should address it, although it's only compile-tested.
thanks,
Takashi
-- 8< --
From: Takashi Iwai <redacted>
Subject: [PATCH] ALSA: isa: Avoid passing NULL to memory allocators
We used to pass NULL to memory allocators for ISA devices due to
historical reasons. But we prefer rather a proper device object to be
assigned, so let's fix it by replacing snd_dma_isa_data() call with
card->dev reference, and kill snd_dma_isa_data() definition.
Signed-off-by: Takashi Iwai <redacted>
---
Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 10 +++++-----
include/sound/memalloc.h | 1 -
sound/isa/ad1816a/ad1816a_lib.c | 2 +-
sound/isa/cmi8330.c | 2 +-
sound/isa/es1688/es1688_lib.c | 2 +-
sound/isa/es18xx.c | 2 +-
sound/isa/gus/gus_pcm.c | 4 ++--
sound/isa/sb/sb16_main.c | 2 +-
sound/isa/sb/sb8_main.c | 2 +-
sound/isa/sscape.c | 7 ++++---
sound/isa/wss/wss_lib.c | 2 +-
11 files changed, 18 insertions(+), 18 deletions(-)
@@ -3520,14 +3520,14 @@ allocator will try to get an area as large as possible within the given size. The second argument (type) and the third argument (device pointer) are-dependent on the bus. In the case of the ISA bus, pass-:c:func:`snd_dma_isa_data()` as the third argument with+dependent on the bus. For normal devices, pass the device pointer+(typically identical as ``card->dev``) to the third argument with``SNDRV_DMA_TYPE_DEV`` type. For the continuous buffer unrelated to the bus can be pre-allocated with ``SNDRV_DMA_TYPE_CONTINUOUS`` type and the``snd_dma_continuous_data(GFP_KERNEL)`` device pointer, where-``GFP_KERNEL`` is the kernel allocation flag to use. For the PCI-scatter-gather buffers, use ``SNDRV_DMA_TYPE_DEV_SG`` with-``snd_dma_pci_data(pci)`` (see the `Non-Contiguous Buffers`_+``GFP_KERNEL`` is the kernel allocation flag to use. For the+scatter-gather buffers, use ``SNDRV_DMA_TYPE_DEV_SG`` with the device+pointer (see the `Non-Contiguous Buffers`_ section). Once the buffer is pre-allocated, you can use the allocator in the
@@ -693,7 +693,7 @@ int snd_ad1816a_pcm(struct snd_ad1816a *chip, int device)snd_ad1816a_init(chip);snd_pcm_lib_preallocate_pages_for_all(pcm,SNDRV_DMA_TYPE_DEV,-snd_dma_isa_data(),+chip->card->dev,64*1024,chip->dma1>3||chip->dma2>3?128*1024:64*1024);chip->pcm=pcm;
@@ -891,7 +891,7 @@ int snd_gf1_pcm_new(struct snd_gus_card *gus, int pcm_dev, int control_index)for(substream=pcm->streams[SNDRV_PCM_STREAM_PLAYBACK].substream;substream;substream=substream->next)snd_pcm_lib_preallocate_pages(substream,SNDRV_DMA_TYPE_DEV,-snd_dma_isa_data(),+card->dev,64*1024,gus->gf1.dma1>3?128*1024:64*1024);pcm->info_flags=0;
@@ -901,7 +901,7 @@ int snd_gf1_pcm_new(struct snd_gus_card *gus, int pcm_dev, int control_index)if(gus->gf1.dma2=gus->gf1.dma1)pcm->info_flags|=SNDRV_PCM_INFO_HALF_DUPLEX;snd_pcm_lib_preallocate_pages(pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream,-SNDRV_DMA_TYPE_DEV,snd_dma_isa_data(),+SNDRV_DMA_TYPE_DEV,card->dev,64*1024,gus->gf1.dma2>3?128*1024:64*1024);}strcpy(pcm->name,pcm->id);
@@ -889,7 +889,7 @@ int snd_sb16dsp_pcm(struct snd_sb *chip, int device)}snd_pcm_lib_preallocate_pages_for_all(pcm,SNDRV_DMA_TYPE_DEV,-snd_dma_isa_data(),+card->dev,64*1024,128*1024);return0;}
@@ -610,7 +610,7 @@ int snd_sb8dsp_pcm(struct snd_sb *chip, int device)if(chip->dma8>3||chip->dma16>=0)max_prealloc=128*1024;snd_pcm_lib_preallocate_pages_for_all(pcm,SNDRV_DMA_TYPE_DEV,-snd_dma_isa_data(),+card->dev,64*1024,max_prealloc);return0;
@@ -1942,7 +1942,7 @@ int snd_wss_pcm(struct snd_wss *chip, int device)strcpy(pcm->name,snd_wss_chip_id(chip));snd_pcm_lib_preallocate_pages_for_all(pcm,SNDRV_DMA_TYPE_DEV,-snd_dma_isa_data(),+chip->card->dev,64*1024,chip->dma1>3||chip->dma2>3?128*1024:64*1024);chip->pcm=pcm;
From: Felipe Balbi <balbi@kernel.org> Date: 2019-02-01 13:20:46
Christoph Hellwig [off-list ref] writes:
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.
Signed-off-by: Christoph Hellwig <hch@lst.de>
In case you're taking the entire series:
Acked-by: Felipe Balbi <redacted>
--
balbi
From: Robin Murphy <robin.murphy@arm.com> Date: 2019-02-01 13:53:20
On 01/02/2019 08:47, Christoph Hellwig wrote:
quoted hunk
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 the proper Kconfig symbol to check for DMA API availability.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/net/caif/caif_spi.c | 30 ++++++++++++++++--------------
1 file changed, 16 insertions(+), 14 deletions(-)
From: Robin Murphy <robin.murphy@arm.com> Date: 2019-02-01 14:14:40
On 01/02/2019 08:47, 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.
Hmm, as far as I'm aware these are PIO chips with external DMA
handshaking, rather than actual DMA masters...
And equivalently for rxdma here. However, given that this all seems only
relevant to antique ARCH_PXA platforms which are presumably managing to
work as-is, it's probably not worth tinkering too much. I'd just stick a
note in the commit message that we're still only making these
self-consistent with the existing dma_map_single() calls rather than
necessarily correct.
Robin.
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 16:10:01
On Fri, Feb 01, 2019 at 02:16:08PM +0100, Takashi Iwai wrote:
Actually there are a bunch of ISA sound drivers that still call
allocators with NULL device.
The patch below should address it, although it's only compile-tested.
Oh, I missed these "indirect" calls. This looks good to me:
Reviewed-by: Christoph Hellwig <hch@lst.de>
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-01 16:11:20
On Fri, Feb 01, 2019 at 02:14:34PM +0000, Robin Murphy wrote:
And equivalently for rxdma here. However, given that this all seems only
relevant to antique ARCH_PXA platforms which are presumably managing to
work as-is, it's probably not worth tinkering too much. I'd just stick a
note in the commit message that we're still only making these
self-consistent with the existing dma_map_single() calls rather than
necessarily correct.
On Fri, 01 Feb 2019 17:09:57 +0100,
Christoph Hellwig wrote:
On Fri, Feb 01, 2019 at 02:16:08PM +0100, Takashi Iwai wrote:
quoted
Actually there are a bunch of ISA sound drivers that still call
allocators with NULL device.
The patch below should address it, although it's only compile-tested.
Oh, I missed these "indirect" calls. This looks good to me:
Reviewed-by: Christoph Hellwig <hch@lst.de>
OK, merged this one to for-next branch now as well.
thanks,
Takashi
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.
This looks good to me but fails to apply. Can you please base it on
dmaengine-next or linux-next please and resend
Thanks
--
~Vinod
From: Christoph Hellwig <hch@lst.de> Date: 2019-02-02 17:21:25
On Sat, Feb 02, 2019 at 03:41:21PM +0530, Vinod Koul wrote:
On 01-02-19, 09:47, Christoph Hellwig wrote:
quoted
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.
This looks good to me but fails to apply. Can you please base it on
dmaengine-next or linux-next please and resend
commit ceaf52265148d3a5ca24237fd1c709caa5f46184
Author: Andy Duan [off-list ref]
Date: Fri Jan 11 14:29:49 2019 +0000
dmaengine: imx-sdma: pass ->dev to dma_alloc_coherent() API
in linux-next actually is equivalent to this patch, so we can drop
this one.
From: Paul Burton <hidden> Date: 2019-02-07 23:29:21
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 [off-list ref]
Thanks,
Paul
From: Paul Burton <hidden> Date: 2019-02-12 17:41:35
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. ]