linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* don't pass a NULL struct device to DMA API functions
@ 2019-02-01  8:47 Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 01/18] MIPS: lantiq: pass " Christoph Hellwig
                   ` (18 more replies)
  0 siblings, 19 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-07 23:29   ` Paul Burton
  2019-02-12 17:41   ` Paul Burton
  2019-02-01  8:47 ` [PATCH 02/18] dmaengine: imx-sdma: " Christoph Hellwig
                   ` (17 subsequent siblings)
  18 siblings, 2 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

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


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 02/18] dmaengine: imx-sdma: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 01/18] MIPS: lantiq: pass " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-02 10:11   ` Vinod Koul
  2019-02-01  8:47 ` [PATCH 03/18] net: caif: " Christoph Hellwig
                   ` (16 subsequent siblings)
  18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 86708fb9bda1..0b6bba0b9f38 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -677,7 +677,7 @@ static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
 	int ret;
 	unsigned long flags;
 
-	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);
 
 	return ret;
 }
@@ -1182,8 +1182,8 @@ static int sdma_request_channel0(struct sdma_engine *sdma)
 {
 	int ret = -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;
 		goto out;
@@ -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 (struct sdma_channel_control) +
 			sizeof(struct sdma_context_data),
 			&ccb_phys, GFP_KERNEL);
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 03/18] net: caif: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 01/18] MIPS: lantiq: pass " Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 02/18] dmaengine: imx-sdma: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01 13:53   ` Robin Murphy
  2019-02-01  8:47 ` [PATCH 04/18] au1000_eth: " Christoph Hellwig
                   ` (15 subsequent siblings)
  18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
index d28a1398c091..b7f3e263b57c 100644
--- a/drivers/net/caif/caif_spi.c
+++ b/drivers/net/caif/caif_spi.c
@@ -73,35 +73,37 @@ MODULE_PARM_DESC(spi_down_tail_align, "SPI downlink tail alignment.");
 #define LOW_WATER_MARK   100
 #define HIGH_WATER_MARK  (LOW_WATER_MARK*5)
 
-#ifdef CONFIG_UML
+#ifdef CONFIG_HAS_DMA
 
 /*
  * We sometimes use UML for debugging, but it cannot handle
  * dma_alloc_coherent so we have to wrap it.
  */
-static inline void *dma_alloc(dma_addr_t *daddr)
+static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
 {
 	return kmalloc(SPI_DMA_BUF_LEN, GFP_KERNEL);
 }
 
-static inline void dma_free(void *cpu_addr, dma_addr_t handle)
+static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
+		dma_addr_t handle)
 {
 	kfree(cpu_addr);
 }
 
 #else
 
-static inline void *dma_alloc(dma_addr_t *daddr)
+static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
 {
-	return dma_alloc_coherent(NULL, SPI_DMA_BUF_LEN, daddr,
+	return dma_alloc_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, daddr,
 				GFP_KERNEL);
 }
 
-static inline void dma_free(void *cpu_addr, dma_addr_t handle)
+static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
+		dma_addr_t handle)
 {
-	dma_free_coherent(NULL, SPI_DMA_BUF_LEN, cpu_addr, handle);
+	dma_free_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, cpu_addr, handle);
 }
-#endif	/* CONFIG_UML */
+#endif	/* CONFIG_HAS_DMA */
 
 #ifdef CONFIG_DEBUG_FS
 
@@ -610,13 +612,13 @@ static int cfspi_init(struct net_device *dev)
 	}
 
 	/* Allocate DMA buffers. */
-	cfspi->xfer.va_tx[0] = dma_alloc(&cfspi->xfer.pa_tx[0]);
+	cfspi->xfer.va_tx[0] = dma_alloc(cfspi, &cfspi->xfer.pa_tx[0]);
 	if (!cfspi->xfer.va_tx[0]) {
 		res = -ENODEV;
 		goto err_dma_alloc_tx_0;
 	}
 
-	cfspi->xfer.va_rx = dma_alloc(&cfspi->xfer.pa_rx);
+	cfspi->xfer.va_rx = dma_alloc(cfspi, &cfspi->xfer.pa_rx);
 
 	if (!cfspi->xfer.va_rx) {
 		res = -ENODEV;
@@ -665,9 +667,9 @@ static int cfspi_init(struct net_device *dev)
 	return 0;
 
  err_create_wq:
-	dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
+	dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
  err_dma_alloc_rx:
-	dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
+	dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
  err_dma_alloc_tx_0:
 	return res;
 }
@@ -683,8 +685,8 @@ static void cfspi_uninit(struct net_device *dev)
 
 	cfspi->ndev = NULL;
 	/* Free DMA buffers. */
-	dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
-	dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
+	dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
+	dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
 	set_bit(SPI_TERMINATE, &cfspi->state);
 	wake_up_interruptible(&cfspi->wait);
 	destroy_workqueue(cfspi->wq);
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 04/18] au1000_eth: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (2 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 03/18] net: caif: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 05/18] macb_main: " Christoph Hellwig
                   ` (14 subsequent siblings)
  18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/net/ethernet/amd/au1000_eth.c b/drivers/net/ethernet/amd/au1000_eth.c
index e833d1b3fe18..e5073aeea06a 100644
--- a/drivers/net/ethernet/amd/au1000_eth.c
+++ b/drivers/net/ethernet/amd/au1000_eth.c
@@ -1167,7 +1167,7 @@ static int au1000_probe(struct platform_device *pdev)
 	/* Allocate the data buffers
 	 * Snooping works fine with eth on all au1xxx
 	 */
-	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);
 
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 05/18] macb_main: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (3 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 04/18] au1000_eth: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01 13:34   ` Nicolas.Ferre
  2019-02-01  8:47 ` [PATCH 06/18] lantiq_etop: " Christoph Hellwig
                   ` (13 subsequent siblings)
  18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 2b2882615e8b..61a27963f1d1 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -3673,9 +3673,9 @@ static netdev_tx_t at91ether_start_xmit(struct sk_buff *skb,
 		/* Store packet information (to free when Tx completed) */
 		lp->skb = skb;
 		lp->skb_length = skb->len;
-		lp->skb_physaddr = dma_map_single(NULL, skb->data, skb->len,
-							DMA_TO_DEVICE);
-		if (dma_mapping_error(NULL, lp->skb_physaddr)) {
+		lp->skb_physaddr = dma_map_single(&lp->pdev->dev, skb->data,
+						  skb->len, DMA_TO_DEVICE);
+		if (dma_mapping_error(&lp->pdev->dev, lp->skb_physaddr)) {
 			dev_kfree_skb_any(skb);
 			dev->stats.tx_dropped++;
 			netdev_err(dev, "%s: DMA mapping error\n", __func__);
@@ -3765,7 +3765,7 @@ static irqreturn_t at91ether_interrupt(int irq, void *dev_id)
 		if (lp->skb) {
 			dev_kfree_skb_irq(lp->skb);
 			lp->skb = NULL;
-			dma_unmap_single(NULL, lp->skb_physaddr,
+			dma_unmap_single(&lp->pdev->dev, lp->skb_physaddr,
 					 lp->skb_length, DMA_TO_DEVICE);
 			dev->stats.tx_packets++;
 			dev->stats.tx_bytes += lp->skb_length;
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 06/18] lantiq_etop: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (4 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 05/18] macb_main: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 07/18] pxa168_eth: " Christoph Hellwig
                   ` (12 subsequent siblings)
  18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/net/ethernet/lantiq_etop.c b/drivers/net/ethernet/lantiq_etop.c
index 32ac9045cdae..f9bb890733b5 100644
--- a/drivers/net/ethernet/lantiq_etop.c
+++ b/drivers/net/ethernet/lantiq_etop.c
@@ -112,10 +112,12 @@ struct ltq_etop_priv {
 static int
 ltq_etop_alloc_skb(struct ltq_etop_chan *ch)
 {
+	struct ltq_etop_priv *priv = netdev_priv(ch->netdev);
+
 	ch->skb[ch->dma.desc] = netdev_alloc_skb(ch->netdev, MAX_DMA_DATA_LEN);
 	if (!ch->skb[ch->dma.desc])
 		return -ENOMEM;
-	ch->dma.desc_base[ch->dma.desc].addr = dma_map_single(NULL,
+	ch->dma.desc_base[ch->dma.desc].addr = dma_map_single(&priv->pdev->dev,
 		ch->skb[ch->dma.desc]->data, MAX_DMA_DATA_LEN,
 		DMA_FROM_DEVICE);
 	ch->dma.desc_base[ch->dma.desc].addr =
@@ -487,7 +489,7 @@ ltq_etop_tx(struct sk_buff *skb, struct net_device *dev)
 	netif_trans_update(dev);
 
 	spin_lock_irqsave(&priv->lock, flags);
-	desc->addr = ((unsigned int) dma_map_single(NULL, skb->data, len,
+	desc->addr = ((unsigned int) dma_map_single(&priv->pdev->dev, skb->data, len,
 						DMA_TO_DEVICE)) - byte_offset;
 	wmb();
 	desc->ctl = LTQ_DMA_OWN | LTQ_DMA_SOP | LTQ_DMA_EOP |
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 07/18] pxa168_eth: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (5 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 06/18] lantiq_etop: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 08/18] moxart_ether: " Christoph Hellwig
                   ` (11 subsequent siblings)
  18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/net/ethernet/marvell/pxa168_eth.c b/drivers/net/ethernet/marvell/pxa168_eth.c
index f8a6d6e3cb7a..35f2142aac5e 100644
--- a/drivers/net/ethernet/marvell/pxa168_eth.c
+++ b/drivers/net/ethernet/marvell/pxa168_eth.c
@@ -201,6 +201,7 @@ struct tx_desc {
 };
 
 struct pxa168_eth_private {
+	struct platform_device *pdev;
 	int port_num;		/* User Ethernet port number    */
 	int phy_addr;
 	int phy_speed;
@@ -331,7 +332,7 @@ static void rxq_refill(struct net_device *dev)
 		used_rx_desc = pep->rx_used_desc_q;
 		p_used_rx_desc = &pep->p_rx_desc_area[used_rx_desc];
 		size = skb_end_pointer(skb) - skb->data;
-		p_used_rx_desc->buf_ptr = dma_map_single(NULL,
+		p_used_rx_desc->buf_ptr = dma_map_single(&pep->pdev->dev,
 							 skb->data,
 							 size,
 							 DMA_FROM_DEVICE);
@@ -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++;
@@ -1274,7 +1275,8 @@ pxa168_eth_start_xmit(struct sk_buff *skb, struct net_device *dev)
 	length = skb->len;
 	pep->tx_skb[tx_index] = skb;
 	desc->byte_cnt = length;
-	desc->buf_ptr = dma_map_single(NULL, skb->data, length, DMA_TO_DEVICE);
+	desc->buf_ptr = dma_map_single(&pep->pdev->dev, skb->data, length,
+					DMA_TO_DEVICE);
 
 	skb_tx_timestamp(skb);
 
@@ -1528,6 +1530,7 @@ static int pxa168_eth_probe(struct platform_device *pdev)
 	if (err)
 		goto err_free_mdio;
 
+	pep->pdev = pdev;
 	SET_NETDEV_DEV(dev, &pdev->dev);
 	pxa168_init_hw(pep);
 	err = register_netdev(dev);
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 08/18] moxart_ether: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (6 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 07/18] pxa168_eth: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 09/18] meth: " Christoph Hellwig
                   ` (10 subsequent siblings)
  18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index b34055ac476f..00dec0ffb11b 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -81,11 +81,13 @@ static void moxart_mac_free_memory(struct net_device *ndev)
 				 priv->rx_buf_size, DMA_FROM_DEVICE);
 
 	if (priv->tx_desc_base)
-		dma_free_coherent(NULL, TX_REG_DESC_SIZE * TX_DESC_NUM,
+		dma_free_coherent(&priv->pdev->dev,
+				  TX_REG_DESC_SIZE * TX_DESC_NUM,
 				  priv->tx_desc_base, priv->tx_base);
 
 	if (priv->rx_desc_base)
-		dma_free_coherent(NULL, RX_REG_DESC_SIZE * RX_DESC_NUM,
+		dma_free_coherent(&priv->pdev->dev,
+				  RX_REG_DESC_SIZE * RX_DESC_NUM,
 				  priv->rx_desc_base, priv->rx_base);
 
 	kfree(priv->tx_buf_base);
@@ -476,6 +478,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
 
 	priv = netdev_priv(ndev);
 	priv->ndev = ndev;
+	priv->pdev = pdev;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	ndev->base_addr = res->start;
@@ -491,7 +494,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
 	priv->tx_buf_size = TX_BUF_SIZE;
 	priv->rx_buf_size = RX_BUF_SIZE;
 
-	priv->tx_desc_base = dma_alloc_coherent(NULL, TX_REG_DESC_SIZE *
+	priv->tx_desc_base = dma_alloc_coherent(&pdev->dev, TX_REG_DESC_SIZE *
 						TX_DESC_NUM, &priv->tx_base,
 						GFP_DMA | GFP_KERNEL);
 	if (!priv->tx_desc_base) {
@@ -499,7 +502,7 @@ static int moxart_mac_probe(struct platform_device *pdev)
 		goto init_fail;
 	}
 
-	priv->rx_desc_base = dma_alloc_coherent(NULL, RX_REG_DESC_SIZE *
+	priv->rx_desc_base = dma_alloc_coherent(&pdev->dev, RX_REG_DESC_SIZE *
 						RX_DESC_NUM, &priv->rx_base,
 						GFP_DMA | GFP_KERNEL);
 	if (!priv->rx_desc_base) {
diff --git a/drivers/net/ethernet/moxa/moxart_ether.h b/drivers/net/ethernet/moxa/moxart_ether.h
index bee608b547d1..bf4c3029cd0c 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.h
+++ b/drivers/net/ethernet/moxa/moxart_ether.h
@@ -292,6 +292,7 @@
 #define LINK_STATUS		0x4
 
 struct moxart_mac_priv_t {
+	struct platform_device *pdev;
 	void __iomem *base;
 	unsigned int reg_maccr;
 	unsigned int reg_imr;
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 09/18] meth: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (7 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 08/18] moxart_ether: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 10/18] smc911x: " Christoph Hellwig
                   ` (9 subsequent siblings)
  18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/net/ethernet/sgi/meth.c b/drivers/net/ethernet/sgi/meth.c
index 0e1b7e960b98..67954a9e3675 100644
--- a/drivers/net/ethernet/sgi/meth.c
+++ b/drivers/net/ethernet/sgi/meth.c
@@ -68,6 +68,8 @@ module_param(timeout, int, 0);
  * packets in and out, so there is place for a packet
  */
 struct meth_private {
+	struct platform_device *pdev;
+
 	/* in-memory copy of MAC Control register */
 	u64 mac_ctrl;
 
@@ -211,8 +213,8 @@ static void meth_check_link(struct net_device *dev)
 static int meth_init_tx_ring(struct meth_private *priv)
 {
 	/* Init TX ring */
-	priv->tx_ring = dma_alloc_coherent(NULL, TX_RING_BUFFER_SIZE,
-					   &priv->tx_ring_dma, GFP_ATOMIC);
+	priv->tx_ring = dma_alloc_coherent(&priv->pdev->dev,
+			TX_RING_BUFFER_SIZE, &priv->tx_ring_dma, GFP_KERNEL);
 	if (!priv->tx_ring)
 		return -ENOMEM;
 
@@ -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];
 	}
@@ -253,7 +255,7 @@ static void meth_free_tx_ring(struct meth_private *priv)
 			dev_kfree_skb(priv->tx_skbs[i]);
 		priv->tx_skbs[i] = NULL;
 	}
-	dma_free_coherent(NULL, TX_RING_BUFFER_SIZE, priv->tx_ring,
+	dma_free_coherent(&priv->pdev->dev, TX_RING_BUFFER_SIZE, priv->tx_ring,
 	                  priv->tx_ring_dma);
 }
 
@@ -263,7 +265,7 @@ static void meth_free_rx_ring(struct meth_private *priv)
 	int i;
 
 	for (i = 0; i < RX_RING_ENTRIES; i++) {
-		dma_unmap_single(NULL, priv->rx_ring_dmas[i],
+		dma_unmap_single(&priv->pdev->dev, priv->rx_ring_dmas[i],
 				 METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
 		priv->rx_ring[i] = 0;
 		priv->rx_ring_dmas[i] = 0;
@@ -393,7 +395,8 @@ static void meth_rx(struct net_device* dev, unsigned long int_status)
 		fifo_rptr = (fifo_rptr - 1) & 0x0f;
 	}
 	while (priv->rx_write != fifo_rptr) {
-		dma_unmap_single(NULL, priv->rx_ring_dmas[priv->rx_write],
+		dma_unmap_single(&priv->pdev->dev,
+				 priv->rx_ring_dmas[priv->rx_write],
 				 METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
 		status = priv->rx_ring[priv->rx_write]->status.raw;
 #if MFE_DEBUG
@@ -454,7 +457,8 @@ static void meth_rx(struct net_device* dev, unsigned long int_status)
 		priv->rx_ring[priv->rx_write] = (rx_packet*)skb->head;
 		priv->rx_ring[priv->rx_write]->status.raw = 0;
 		priv->rx_ring_dmas[priv->rx_write] =
-			dma_map_single(NULL, priv->rx_ring[priv->rx_write],
+			dma_map_single(&priv->pdev->dev,
+				       priv->rx_ring[priv->rx_write],
 				       METH_RX_BUFF_SIZE, DMA_FROM_DEVICE);
 		mace->eth.rx_fifo = priv->rx_ring_dmas[priv->rx_write];
 		ADVANCE_RX_PTR(priv->rx_write);
@@ -637,7 +641,7 @@ static void meth_tx_1page_prepare(struct meth_private *priv,
 	}
 
 	/* first page */
-	catbuf = dma_map_single(NULL, buffer_data, buffer_len,
+	catbuf = dma_map_single(&priv->pdev->dev, buffer_data, buffer_len,
 				DMA_TO_DEVICE);
 	desc->data.cat_buf[0].form.start_addr = catbuf >> 3;
 	desc->data.cat_buf[0].form.len = buffer_len - 1;
@@ -663,12 +667,12 @@ static void meth_tx_2page_prepare(struct meth_private *priv,
 	}
 
 	/* first page */
-	catbuf1 = dma_map_single(NULL, buffer1_data, buffer1_len,
+	catbuf1 = dma_map_single(&priv->pdev->dev, buffer1_data, buffer1_len,
 				 DMA_TO_DEVICE);
 	desc->data.cat_buf[0].form.start_addr = catbuf1 >> 3;
 	desc->data.cat_buf[0].form.len = buffer1_len - 1;
 	/* second page */
-	catbuf2 = dma_map_single(NULL, buffer2_data, buffer2_len,
+	catbuf2 = dma_map_single(&priv->pdev->dev, buffer2_data, buffer2_len,
 				 DMA_TO_DEVICE);
 	desc->data.cat_buf[1].form.start_addr = catbuf2 >> 3;
 	desc->data.cat_buf[1].form.len = buffer2_len - 1;
@@ -840,6 +844,7 @@ static int meth_probe(struct platform_device *pdev)
 	memcpy(dev->dev_addr, o2meth_eaddr, ETH_ALEN);
 
 	priv = netdev_priv(dev);
+	priv->pdev = pdev;
 	spin_lock_init(&priv->meth_lock);
 	SET_NETDEV_DEV(dev, &pdev->dev);
 
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 10/18] smc911x: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (8 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 09/18] meth: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01 14:14   ` Robin Murphy
  2019-02-01  8:47 ` [PATCH 11/18] parport_ip32: " Christoph Hellwig
                   ` (8 subsequent siblings)
  18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
index 8355dfbb8ec3..b550e624500d 100644
--- a/drivers/net/ethernet/smsc/smc911x.c
+++ b/drivers/net/ethernet/smsc/smc911x.c
@@ -1188,7 +1188,7 @@ smc911x_tx_dma_irq(void *data)
 
 	DBG(SMC_DEBUG_TX | SMC_DEBUG_DMA, dev, "TX DMA irq handler\n");
 	BUG_ON(skb == NULL);
-	dma_unmap_single(NULL, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
+	dma_unmap_single(lp->dev, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
 	netif_trans_update(dev);
 	dev_kfree_skb_irq(skb);
 	lp->current_tx_skb = NULL;
@@ -1219,7 +1219,7 @@ smc911x_rx_dma_irq(void *data)
 
 	DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
 	DBG(SMC_DEBUG_RX | SMC_DEBUG_DMA, dev, "RX DMA irq handler\n");
-	dma_unmap_single(NULL, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
+	dma_unmap_single(lp->dev, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
 	BUG_ON(skb == NULL);
 	lp->current_rx_skb = NULL;
 	PRINT_PKT(skb->data, skb->len);
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 11/18] parport_ip32: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (9 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 10/18] smc911x: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call Christoph Hellwig
                   ` (7 subsequent siblings)
  18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/parport/parport_ip32.c b/drivers/parport/parport_ip32.c
index 62873070f988..b7a892791c3e 100644
--- a/drivers/parport/parport_ip32.c
+++ b/drivers/parport/parport_ip32.c
@@ -568,6 +568,7 @@ static irqreturn_t parport_ip32_merr_interrupt(int irq, void *dev_id)
 
 /**
  * parport_ip32_dma_start - begins a DMA transfer
+ * @p:		partport to work on
  * @dir:	DMA direction: DMA_TO_DEVICE or DMA_FROM_DEVICE
  * @addr:	pointer to data buffer
  * @count:	buffer size
@@ -575,8 +576,8 @@ static irqreturn_t parport_ip32_merr_interrupt(int irq, void *dev_id)
  * Calls to parport_ip32_dma_start() and parport_ip32_dma_stop() must be
  * correctly balanced.
  */
-static int parport_ip32_dma_start(enum dma_data_direction dir,
-				  void *addr, size_t count)
+static int parport_ip32_dma_start(struct parport *p,
+		enum dma_data_direction dir, void *addr, size_t count)
 {
 	unsigned int limit;
 	u64 ctrl;
@@ -601,7 +602,7 @@ static int parport_ip32_dma_start(enum dma_data_direction dir,
 
 	/* Prepare DMA pointers */
 	parport_ip32_dma.dir = dir;
-	parport_ip32_dma.buf = dma_map_single(NULL, addr, count, dir);
+	parport_ip32_dma.buf = dma_map_single(&p->bus_dev, addr, count, dir);
 	parport_ip32_dma.len = count;
 	parport_ip32_dma.next = parport_ip32_dma.buf;
 	parport_ip32_dma.left = parport_ip32_dma.len;
@@ -625,11 +626,12 @@ static int parport_ip32_dma_start(enum dma_data_direction dir,
 
 /**
  * parport_ip32_dma_stop - ends a running DMA transfer
+ * @p:		partport to work on
  *
  * Calls to parport_ip32_dma_start() and parport_ip32_dma_stop() must be
  * correctly balanced.
  */
-static void parport_ip32_dma_stop(void)
+static void parport_ip32_dma_stop(struct parport *p)
 {
 	u64 ctx_a;
 	u64 ctx_b;
@@ -685,8 +687,8 @@ static void parport_ip32_dma_stop(void)
 	enable_irq(MACEISA_PAR_CTXB_IRQ);
 	parport_ip32_dma.irq_on = 1;
 
-	dma_unmap_single(NULL, parport_ip32_dma.buf, parport_ip32_dma.len,
-			 parport_ip32_dma.dir);
+	dma_unmap_single(&p->bus_dev, parport_ip32_dma.buf,
+			 parport_ip32_dma.len, parport_ip32_dma.dir);
 }
 
 /**
@@ -1445,7 +1447,7 @@ static size_t parport_ip32_fifo_write_block_dma(struct parport *p,
 
 	priv->irq_mode = PARPORT_IP32_IRQ_HERE;
 
-	parport_ip32_dma_start(DMA_TO_DEVICE, (void *)buf, len);
+	parport_ip32_dma_start(p, DMA_TO_DEVICE, (void *)buf, len);
 	reinit_completion(&priv->irq_complete);
 	parport_ip32_frob_econtrol(p, ECR_DMAEN | ECR_SERVINTR, ECR_DMAEN);
 
@@ -1461,7 +1463,7 @@ static size_t parport_ip32_fifo_write_block_dma(struct parport *p,
 		if (ecr & ECR_SERVINTR)
 			break;	/* DMA transfer just finished */
 	}
-	parport_ip32_dma_stop();
+	parport_ip32_dma_stop(p);
 	written = len - parport_ip32_dma_get_residue();
 
 	priv->irq_mode = PARPORT_IP32_IRQ_FWD;
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (10 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 11/18] parport_ip32: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01 13:19   ` Felipe Balbi
  2019-02-01  8:47 ` [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions Christoph Hellwig
                   ` (6 subsequent siblings)
  18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

dma_map_single already transfers ownership to the device.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 drivers/usb/gadget/udc/fotg210-udc.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/gadget/udc/fotg210-udc.c b/drivers/usb/gadget/udc/fotg210-udc.c
index bc6abaea907d..fe9cf415f2f1 100644
--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -356,10 +356,6 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
 		return;
 	}
 
-	dma_sync_single_for_device(NULL, d, length,
-				   ep->dir_in ? DMA_TO_DEVICE :
-					DMA_FROM_DEVICE);
-
 	fotg210_enable_dma(ep, d, length);
 
 	/* check if dma is done */
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (11 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01 13:20   ` Felipe Balbi
  2019-02-01  8:47 ` [PATCH 14/18] da8xx-fb: " Christoph Hellwig
                   ` (5 subsequent siblings)
  18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/usb/gadget/udc/fotg210-udc.c b/drivers/usb/gadget/udc/fotg210-udc.c
index fe9cf415f2f1..cec49294bac6 100644
--- a/drivers/usb/gadget/udc/fotg210-udc.c
+++ b/drivers/usb/gadget/udc/fotg210-udc.c
@@ -326,6 +326,7 @@ static void fotg210_wait_dma_done(struct fotg210_ep *ep)
 static void fotg210_start_dma(struct fotg210_ep *ep,
 			struct fotg210_request *req)
 {
+	struct device *dev = &ep->fotg210->gadget.dev;
 	dma_addr_t d;
 	u8 *buffer;
 	u32 length;
@@ -348,10 +349,10 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
 			length = req->req.length;
 	}
 
-	d = dma_map_single(NULL, buffer, length,
+	d = dma_map_single(dev, buffer, length,
 			ep->dir_in ? DMA_TO_DEVICE : DMA_FROM_DEVICE);
 
-	if (dma_mapping_error(NULL, d)) {
+	if (dma_mapping_error(dev, d)) {
 		pr_err("dma_mapping_error\n");
 		return;
 	}
@@ -366,7 +367,7 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
 	/* update actual transfer length */
 	req->req.actual += length;
 
-	dma_unmap_single(NULL, d, length, DMA_TO_DEVICE);
+	dma_unmap_single(dev, d, length, DMA_TO_DEVICE);
 }
 
 static void fotg210_ep0_queue(struct fotg210_ep *ep,
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 14/18] da8xx-fb: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (12 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 15/18] gbefb: switch to managed version of the DMA allocator Christoph Hellwig
                   ` (4 subsequent siblings)
  18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/video/fbdev/da8xx-fb.c
index 43f2a4816860..ec62274b914b 100644
--- a/drivers/video/fbdev/da8xx-fb.c
+++ b/drivers/video/fbdev/da8xx-fb.c
@@ -1097,9 +1097,9 @@ static int fb_remove(struct platform_device *dev)
 
 		unregister_framebuffer(info);
 		fb_dealloc_cmap(&info->cmap);
-		dma_free_coherent(NULL, PALETTE_SIZE, par->v_palette_base,
+		dma_free_coherent(par->dev, PALETTE_SIZE, par->v_palette_base,
 				  par->p_palette_base);
-		dma_free_coherent(NULL, par->vram_size, par->vram_virt,
+		dma_free_coherent(par->dev, par->vram_size, par->vram_virt,
 				  par->vram_phys);
 		pm_runtime_put_sync(&dev->dev);
 		pm_runtime_disable(&dev->dev);
@@ -1425,7 +1425,7 @@ static int fb_probe(struct platform_device *device)
 	par->vram_size = roundup(par->vram_size/8, ulcm);
 	par->vram_size = par->vram_size * LCD_NUM_BUFFERS;
 
-	par->vram_virt = dma_alloc_coherent(NULL,
+	par->vram_virt = dma_alloc_coherent(par->dev,
 					    par->vram_size,
 					    &par->vram_phys,
 					    GFP_KERNEL | GFP_DMA);
@@ -1446,7 +1446,7 @@ static int fb_probe(struct platform_device *device)
 		da8xx_fb_fix.line_length - 1;
 
 	/* allocate palette buffer */
-	par->v_palette_base = dma_alloc_coherent(NULL, PALETTE_SIZE,
+	par->v_palette_base = dma_alloc_coherent(par->dev, PALETTE_SIZE,
 						 &par->p_palette_base,
 						 GFP_KERNEL | GFP_DMA);
 	if (!par->v_palette_base) {
@@ -1532,11 +1532,12 @@ static int fb_probe(struct platform_device *device)
 	fb_dealloc_cmap(&da8xx_fb_info->cmap);
 
 err_release_pl_mem:
-	dma_free_coherent(NULL, PALETTE_SIZE, par->v_palette_base,
+	dma_free_coherent(par->dev, PALETTE_SIZE, par->v_palette_base,
 			  par->p_palette_base);
 
 err_release_fb_mem:
-	dma_free_coherent(NULL, par->vram_size, par->vram_virt, par->vram_phys);
+	dma_free_coherent(par->dev, par->vram_size, par->vram_virt,
+		          par->vram_phys);
 
 err_release_fb:
 	framebuffer_release(da8xx_fb_info);
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 15/18] gbefb: switch to managed version of the DMA allocator
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (13 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 14/18] da8xx-fb: " Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01  8:47 ` [PATCH 16/18] pxa3xx-gcu: pass struct device to dma_mmap_coherent Christoph Hellwig
                   ` (3 subsequent siblings)
  18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 1a242b1338e9..3fcb33232ba3 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -1162,9 +1162,9 @@ static int gbefb_probe(struct platform_device *p_dev)
 	}
 	gbe_revision = gbe->ctrlstat & 15;
 
-	gbe_tiles.cpu =
-		dma_alloc_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
-				   &gbe_tiles.dma, GFP_KERNEL);
+	gbe_tiles.cpu = dmam_alloc_coherent(&p_dev->dev,
+				GBE_TLB_SIZE * sizeof(uint16_t),
+				&gbe_tiles.dma, GFP_KERNEL);
 	if (!gbe_tiles.cpu) {
 		printk(KERN_ERR "gbefb: couldn't allocate tiles table\n");
 		ret = -ENOMEM;
@@ -1178,19 +1178,20 @@ static int gbefb_probe(struct platform_device *p_dev)
 		if (!gbe_mem) {
 			printk(KERN_ERR "gbefb: couldn't map framebuffer\n");
 			ret = -ENOMEM;
-			goto out_tiles_free;
+			goto out_release_mem_region;
 		}
 
 		gbe_dma_addr = 0;
 	} else {
 		/* try to allocate memory with the classical allocator
 		 * this has high chance to fail on low memory machines */
-		gbe_mem = dma_alloc_wc(NULL, gbe_mem_size, &gbe_dma_addr,
-				       GFP_KERNEL);
+		gbe_mem = dmam_alloc_attrs(&p_dev->dev, gbe_mem_size,
+				&gbe_dma_addr, GFP_KERNEL,
+				DMA_ATTR_WRITE_COMBINE);
 		if (!gbe_mem) {
 			printk(KERN_ERR "gbefb: couldn't allocate framebuffer memory\n");
 			ret = -ENOMEM;
-			goto out_tiles_free;
+			goto out_release_mem_region;
 		}
 
 		gbe_mem_phys = (unsigned long) gbe_dma_addr;
@@ -1237,11 +1238,6 @@ static int gbefb_probe(struct platform_device *p_dev)
 
 out_gbe_unmap:
 	arch_phys_wc_del(par->wc_cookie);
-	if (gbe_dma_addr)
-		dma_free_wc(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
-out_tiles_free:
-	dma_free_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
-			  (void *)gbe_tiles.cpu, gbe_tiles.dma);
 out_release_mem_region:
 	release_mem_region(GBE_BASE, sizeof(struct sgi_gbe));
 out_release_framebuffer:
@@ -1258,10 +1254,6 @@ static int gbefb_remove(struct platform_device* p_dev)
 	unregister_framebuffer(info);
 	gbe_turn_off();
 	arch_phys_wc_del(par->wc_cookie);
-	if (gbe_dma_addr)
-		dma_free_wc(NULL, gbe_mem_size, gbe_mem, gbe_mem_phys);
-	dma_free_coherent(NULL, GBE_TLB_SIZE * sizeof(uint16_t),
-			  (void *)gbe_tiles.cpu, gbe_tiles.dma);
 	release_mem_region(GBE_BASE, sizeof(struct sgi_gbe));
 	gbefb_remove_sysfs(&p_dev->dev);
 	framebuffer_release(info);
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 16/18] pxa3xx-gcu: pass struct device to dma_mmap_coherent
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (14 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 15/18] gbefb: switch to managed version of the DMA allocator Christoph Hellwig
@ 2019-02-01  8:47 ` Christoph Hellwig
  2019-02-01  8:48 ` [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions Christoph Hellwig
                   ` (2 subsequent siblings)
  18 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:47 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 69cfb337c857..047a2fa4b87e 100644
--- a/drivers/video/fbdev/pxa3xx-gcu.c
+++ b/drivers/video/fbdev/pxa3xx-gcu.c
@@ -96,6 +96,7 @@ struct pxa3xx_gcu_batch {
 };
 
 struct pxa3xx_gcu_priv {
+	struct device		 *dev;
 	void __iomem		 *mmio_base;
 	struct clk		 *clk;
 	struct pxa3xx_gcu_shared *shared;
@@ -493,7 +494,7 @@ pxa3xx_gcu_mmap(struct file *file, struct vm_area_struct *vma)
 		if (size != SHARED_SIZE)
 			return -EINVAL;
 
-		return dma_mmap_coherent(NULL, vma,
+		return dma_mmap_coherent(priv->dev, vma,
 			priv->shared, priv->shared_phys, size);
 
 	case SHARED_SIZE >> PAGE_SHIFT:
@@ -670,6 +671,7 @@ static int pxa3xx_gcu_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, priv);
 	priv->resource_mem = r;
+	priv->dev = dev;
 	pxa3xx_gcu_reset(priv);
 	pxa3xx_gcu_init_debug_timer(priv);
 
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (15 preceding siblings ...)
  2019-02-01  8:47 ` [PATCH 16/18] pxa3xx-gcu: pass struct device to dma_mmap_coherent Christoph Hellwig
@ 2019-02-01  8:48 ` Christoph Hellwig
  2019-02-01 13:12   ` [alsa-devel] " Takashi Iwai
  2019-02-01  8:48 ` [PATCH 18/18] ALSA: " Christoph Hellwig
  2019-02-01 13:16 ` [alsa-devel] don't pass a NULL " Takashi Iwai
  18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:48 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/sound/mips/hal2.c b/sound/mips/hal2.c
index a4ed54aeaf1d..d63e1565b62b 100644
--- a/sound/mips/hal2.c
+++ b/sound/mips/hal2.c
@@ -454,21 +454,22 @@ static inline void hal2_stop_adc(struct snd_hal2 *hal2)
 	hal2->adc.pbus.pbus->pbdma_ctrl = HPC3_PDMACTRL_LD;
 }
 
-static int hal2_alloc_dmabuf(struct hal2_codec *codec)
+static int hal2_alloc_dmabuf(struct snd_hal2 *hal2, struct hal2_codec *codec)
 {
+	struct device *dev = hal2->card->dev;
 	struct hal2_desc *desc;
 	dma_addr_t desc_dma, buffer_dma;
 	int count = H2_BUF_SIZE / H2_BLOCK_SIZE;
 	int i;
 
-	codec->buffer = dma_alloc_attrs(NULL, H2_BUF_SIZE, &buffer_dma,
+	codec->buffer = dma_alloc_attrs(dev, H2_BUF_SIZE, &buffer_dma,
 					GFP_KERNEL, DMA_ATTR_NON_CONSISTENT);
 	if (!codec->buffer)
 		return -ENOMEM;
-	desc = dma_alloc_attrs(NULL, count * sizeof(struct hal2_desc),
+	desc = dma_alloc_attrs(dev, count * sizeof(struct hal2_desc),
 			       &desc_dma, GFP_KERNEL, DMA_ATTR_NON_CONSISTENT);
 	if (!desc) {
-		dma_free_attrs(NULL, H2_BUF_SIZE, codec->buffer, buffer_dma,
+		dma_free_attrs(dev, H2_BUF_SIZE, codec->buffer, buffer_dma,
 			       DMA_ATTR_NON_CONSISTENT);
 		return -ENOMEM;
 	}
@@ -482,17 +483,19 @@ static int hal2_alloc_dmabuf(struct hal2_codec *codec)
 		      desc_dma : desc_dma + (i + 1) * sizeof(struct hal2_desc);
 		desc++;
 	}
-	dma_cache_sync(NULL, codec->desc, count * sizeof(struct hal2_desc),
+	dma_cache_sync(dev, codec->desc, count * sizeof(struct hal2_desc),
 		       DMA_TO_DEVICE);
 	codec->desc_count = count;
 	return 0;
 }
 
-static void hal2_free_dmabuf(struct hal2_codec *codec)
+static void hal2_free_dmabuf(struct snd_hal2 *hal2, struct hal2_codec *codec)
 {
-	dma_free_attrs(NULL, codec->desc_count * sizeof(struct hal2_desc),
+	struct device *dev = hal2->card->dev;
+
+	dma_free_attrs(dev, codec->desc_count * sizeof(struct hal2_desc),
 		       codec->desc, codec->desc_dma, DMA_ATTR_NON_CONSISTENT);
-	dma_free_attrs(NULL, H2_BUF_SIZE, codec->buffer, codec->buffer_dma,
+	dma_free_attrs(dev, H2_BUF_SIZE, codec->buffer, codec->buffer_dma,
 		       DMA_ATTR_NON_CONSISTENT);
 }
 
@@ -540,7 +543,7 @@ static int hal2_playback_open(struct snd_pcm_substream *substream)
 
 	runtime->hw = hal2_pcm_hw;
 
-	err = hal2_alloc_dmabuf(&hal2->dac);
+	err = hal2_alloc_dmabuf(hal2, &hal2->dac);
 	if (err)
 		return err;
 	return 0;
@@ -550,7 +553,7 @@ static int hal2_playback_close(struct snd_pcm_substream *substream)
 {
 	struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
 
-	hal2_free_dmabuf(&hal2->dac);
+	hal2_free_dmabuf(hal2, &hal2->dac);
 	return 0;
 }
 
@@ -606,7 +609,7 @@ static void hal2_playback_transfer(struct snd_pcm_substream *substream,
 	unsigned char *buf = hal2->dac.buffer + rec->hw_data;
 
 	memcpy(buf, substream->runtime->dma_area + rec->sw_data, bytes);
-	dma_cache_sync(NULL, buf, bytes, DMA_TO_DEVICE);
+	dma_cache_sync(hal2->card->dev, buf, bytes, DMA_TO_DEVICE);
 
 }
 
@@ -629,7 +632,7 @@ static int hal2_capture_open(struct snd_pcm_substream *substream)
 
 	runtime->hw = hal2_pcm_hw;
 
-	err = hal2_alloc_dmabuf(adc);
+	err = hal2_alloc_dmabuf(hal2, adc);
 	if (err)
 		return err;
 	return 0;
@@ -639,7 +642,7 @@ static int hal2_capture_close(struct snd_pcm_substream *substream)
 {
 	struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
 
-	hal2_free_dmabuf(&hal2->adc);
+	hal2_free_dmabuf(hal2, &hal2->adc);
 	return 0;
 }
 
@@ -694,7 +697,7 @@ static void hal2_capture_transfer(struct snd_pcm_substream *substream,
 	struct snd_hal2 *hal2 = snd_pcm_substream_chip(substream);
 	unsigned char *buf = hal2->adc.buffer + rec->hw_data;
 
-	dma_cache_sync(NULL, buf, bytes, DMA_FROM_DEVICE);
+	dma_cache_sync(hal2->card->dev, buf, bytes, DMA_FROM_DEVICE);
 	memcpy(substream->runtime->dma_area + rec->sw_data, buf, bytes);
 }
 
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* [PATCH 18/18] ALSA: pass struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (16 preceding siblings ...)
  2019-02-01  8:48 ` [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions Christoph Hellwig
@ 2019-02-01  8:48 ` Christoph Hellwig
  2019-02-01 13:13   ` [alsa-devel] " Takashi Iwai
  2019-02-01 13:16 ` [alsa-devel] don't pass a NULL " Takashi Iwai
  18 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01  8:48 UTC (permalink / raw)
  To: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

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

diff --git a/sound/mips/sgio2audio.c b/sound/mips/sgio2audio.c
index 3ec9391a4736..53a4ee01c522 100644
--- a/sound/mips/sgio2audio.c
+++ b/sound/mips/sgio2audio.c
@@ -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");
-- 
2.20.1


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* Re: [alsa-devel] [PATCH 17/18] ALSA: hal2: pass struct device to DMA   API functions
  2019-02-01  8:48 ` [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions Christoph Hellwig
@ 2019-02-01 13:12   ` Takashi Iwai
  2019-02-01 16:09     ` Christoph Hellwig
  0 siblings, 1 reply; 41+ messages in thread
From: Takashi Iwai @ 2019-02-01 13:12 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu

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 <tiwai@suse.de>

Shall I take this one through sound git tree or all through yours?


thanks,

Takashi

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [alsa-devel] [PATCH 18/18] ALSA: pass struct device to DMA API     functions
  2019-02-01  8:48 ` [PATCH 18/18] ALSA: " Christoph Hellwig
@ 2019-02-01 13:13   ` Takashi Iwai
  0 siblings, 0 replies; 41+ messages in thread
From: Takashi Iwai @ 2019-02-01 13:13 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu

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>

Reviewed-by: Takashi Iwai <tiwai@suse.de>


thanks,

Takashi

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [alsa-devel] don't pass a NULL struct device to DMA API functions
  2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
                   ` (17 preceding siblings ...)
  2019-02-01  8:48 ` [PATCH 18/18] ALSA: " Christoph Hellwig
@ 2019-02-01 13:16 ` Takashi Iwai
  2019-02-01 16:09   ` Christoph Hellwig
  18 siblings, 1 reply; 41+ messages in thread
From: Takashi Iwai @ 2019-02-01 13:16 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu

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 <tiwai@suse.de>
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 <tiwai@suse.de>
---
 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(-)

diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
index 7c2f2032d30a..6b154dbb02cc 100644
--- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
+++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst
@@ -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
diff --git a/include/sound/memalloc.h b/include/sound/memalloc.h
index af3fa577fa06..1ac0dd82a916 100644
--- a/include/sound/memalloc.h
+++ b/include/sound/memalloc.h
@@ -37,7 +37,6 @@ struct snd_dma_device {
 };
 
 #define snd_dma_pci_data(pci)	(&(pci)->dev)
-#define snd_dma_isa_data()	NULL
 #define snd_dma_continuous_data(x)	((struct device *)(__force unsigned long)(x))
 
 
diff --git a/sound/isa/ad1816a/ad1816a_lib.c b/sound/isa/ad1816a/ad1816a_lib.c
index 61e8c7e524db..94b381a78e9e 100644
--- a/sound/isa/ad1816a/ad1816a_lib.c
+++ b/sound/isa/ad1816a/ad1816a_lib.c
@@ -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;
diff --git a/sound/isa/cmi8330.c b/sound/isa/cmi8330.c
index 7e5aa06414c4..1868b73aa49c 100644
--- a/sound/isa/cmi8330.c
+++ b/sound/isa/cmi8330.c
@@ -470,7 +470,7 @@ static int snd_cmi8330_pcm(struct snd_card *card, struct snd_cmi8330 *chip)
 	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &chip->streams[SNDRV_PCM_STREAM_CAPTURE].ops);
 
 	snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
-					      snd_dma_isa_data(),
+					      card->dev,
 					      64*1024, 128*1024);
 	chip->pcm = pcm;
 
diff --git a/sound/isa/es1688/es1688_lib.c b/sound/isa/es1688/es1688_lib.c
index 50cdce0e8946..da341969e650 100644
--- a/sound/isa/es1688/es1688_lib.c
+++ b/sound/isa/es1688/es1688_lib.c
@@ -746,7 +746,7 @@ int snd_es1688_pcm(struct snd_card *card, struct snd_es1688 *chip, int device)
 	chip->pcm = pcm;
 
 	snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
-					      snd_dma_isa_data(),
+					      card->dev,
 					      64*1024, 64*1024);
 	return 0;
 }
diff --git a/sound/isa/es18xx.c b/sound/isa/es18xx.c
index 77aa9a27fb3b..07abc7f7840c 100644
--- a/sound/isa/es18xx.c
+++ b/sound/isa/es18xx.c
@@ -1717,7 +1717,7 @@ static int snd_es18xx_pcm(struct snd_card *card, int device)
         chip->pcm = pcm;
 
 	snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
-					      snd_dma_isa_data(),
+					      card->dev,
 					      64*1024,
 					      chip->dma1 > 3 || chip->dma2 > 3 ? 128*1024 : 64*1024);
 	return 0;
diff --git a/sound/isa/gus/gus_pcm.c b/sound/isa/gus/gus_pcm.c
index 131b28997e1d..b9efc6dff45d 100644
--- a/sound/isa/gus/gus_pcm.c
+++ b/sound/isa/gus/gus_pcm.c
@@ -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);
diff --git a/sound/isa/sb/sb16_main.c b/sound/isa/sb/sb16_main.c
index 981d65d122b6..473ec74ae48c 100644
--- a/sound/isa/sb/sb16_main.c
+++ b/sound/isa/sb/sb16_main.c
@@ -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);
 	return 0;
 }
diff --git a/sound/isa/sb/sb8_main.c b/sound/isa/sb/sb8_main.c
index 8288fae90085..97645a732a71 100644
--- a/sound/isa/sb/sb8_main.c
+++ b/sound/isa/sb/sb8_main.c
@@ -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);
 
 	return 0;
diff --git a/sound/isa/sscape.c b/sound/isa/sscape.c
index 733adee5afbf..8181db4db019 100644
--- a/sound/isa/sscape.c
+++ b/sound/isa/sscape.c
@@ -167,12 +167,13 @@ static inline struct soundscape *get_card_soundscape(struct snd_card *c)
  * I think this means that the memory has to map to
  * contiguous pages of physical memory.
  */
-static struct snd_dma_buffer *get_dmabuf(struct snd_dma_buffer *buf,
+static struct snd_dma_buffer *get_dmabuf(struct soundscape *s,
+					 struct snd_dma_buffer *buf,
 					 unsigned long size)
 {
 	if (buf) {
 		if (snd_dma_alloc_pages_fallback(SNDRV_DMA_TYPE_DEV,
-						 snd_dma_isa_data(),
+						 s->chip->card->dev,
 						 size, buf) < 0) {
 			snd_printk(KERN_ERR "sscape: Failed to allocate "
 					    "%lu bytes for DMA\n",
@@ -443,7 +444,7 @@ static int upload_dma_data(struct soundscape *s, const unsigned char *data,
 	int ret;
 	unsigned char val;
 
-	if (!get_dmabuf(&dma, PAGE_ALIGN(32 * 1024)))
+	if (!get_dmabuf(s, &dma, PAGE_ALIGN(32 * 1024)))
 		return -ENOMEM;
 
 	spin_lock_irqsave(&s->lock, flags);
diff --git a/sound/isa/wss/wss_lib.c b/sound/isa/wss/wss_lib.c
index b11ef97bce1b..0dfb8065b403 100644
--- a/sound/isa/wss/wss_lib.c
+++ b/sound/isa/wss/wss_lib.c
@@ -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;
-- 
2.16.4


^ permalink raw reply related	[flat|nested] 41+ messages in thread

* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
  2019-02-01  8:47 ` [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call Christoph Hellwig
@ 2019-02-01 13:19   ` Felipe Balbi
  2019-02-01 16:10     ` Christoph Hellwig
  0 siblings, 1 reply; 41+ messages in thread
From: Felipe Balbi @ 2019-02-01 13:19 UTC (permalink / raw)
  To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

Christoph Hellwig <hch@lst.de> writes:

> dma_map_single already transfers ownership to the device.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Do you want me to take the USB bits or will you take the entire series?
In case you're taking the entire series:

Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>

> ---
>  drivers/usb/gadget/udc/fotg210-udc.c | 4 ----
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/fotg210-udc.c b/drivers/usb/gadget/udc/fotg210-udc.c
> index bc6abaea907d..fe9cf415f2f1 100644
> --- a/drivers/usb/gadget/udc/fotg210-udc.c
> +++ b/drivers/usb/gadget/udc/fotg210-udc.c
> @@ -356,10 +356,6 @@ static void fotg210_start_dma(struct fotg210_ep *ep,
>  		return;
>  	}
>  
> -	dma_sync_single_for_device(NULL, d, length,
> -				   ep->dir_in ? DMA_TO_DEVICE :
> -					DMA_FROM_DEVICE);
> -
>  	fotg210_enable_dma(ep, d, length);
>  
>  	/* check if dma is done */
> -- 
> 2.20.1
>

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions
  2019-02-01  8:47 ` [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions Christoph Hellwig
@ 2019-02-01 13:20   ` Felipe Balbi
  0 siblings, 0 replies; 41+ messages in thread
From: Felipe Balbi @ 2019-02-01 13:20 UTC (permalink / raw)
  To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel
  Cc: iommu

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

Christoph Hellwig <hch@lst.de> 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 <felipe.balbi@linux.intel.com>

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 05/18] macb_main: pass struct device to DMA API functions
  2019-02-01  8:47 ` [PATCH 05/18] macb_main: " Christoph Hellwig
@ 2019-02-01 13:34   ` Nicolas.Ferre
  0 siblings, 0 replies; 41+ messages in thread
From: Nicolas.Ferre @ 2019-02-01 13:34 UTC (permalink / raw)
  To: hch, john, vkoul, dmitry.tarnyagin, sudipm.mukherjee, balbi,
	linux-mips, linux-kernel, dmaengine, netdev, linux-usb,
	linux-fbdev, alsa-devel
  Cc: iommu

On 01/02/2019 at 09: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.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>

> ---
>   drivers/net/ethernet/cadence/macb_main.c | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index 2b2882615e8b..61a27963f1d1 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -3673,9 +3673,9 @@ static netdev_tx_t at91ether_start_xmit(struct sk_buff *skb,
>   		/* Store packet information (to free when Tx completed) */
>   		lp->skb = skb;
>   		lp->skb_length = skb->len;
> -		lp->skb_physaddr = dma_map_single(NULL, skb->data, skb->len,
> -							DMA_TO_DEVICE);
> -		if (dma_mapping_error(NULL, lp->skb_physaddr)) {
> +		lp->skb_physaddr = dma_map_single(&lp->pdev->dev, skb->data,
> +						  skb->len, DMA_TO_DEVICE);
> +		if (dma_mapping_error(&lp->pdev->dev, lp->skb_physaddr)) {
>   			dev_kfree_skb_any(skb);
>   			dev->stats.tx_dropped++;
>   			netdev_err(dev, "%s: DMA mapping error\n", __func__);
> @@ -3765,7 +3765,7 @@ static irqreturn_t at91ether_interrupt(int irq, void *dev_id)
>   		if (lp->skb) {
>   			dev_kfree_skb_irq(lp->skb);
>   			lp->skb = NULL;
> -			dma_unmap_single(NULL, lp->skb_physaddr,
> +			dma_unmap_single(&lp->pdev->dev, lp->skb_physaddr,
>   					 lp->skb_length, DMA_TO_DEVICE);
>   			dev->stats.tx_packets++;
>   			dev->stats.tx_bytes += lp->skb_length;
> 


-- 
Nicolas Ferre

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 03/18] net: caif: pass struct device to DMA API functions
  2019-02-01  8:47 ` [PATCH 03/18] net: caif: " Christoph Hellwig
@ 2019-02-01 13:53   ` Robin Murphy
  2019-02-01 16:10     ` Christoph Hellwig
  0 siblings, 1 reply; 41+ messages in thread
From: Robin Murphy @ 2019-02-01 13:53 UTC (permalink / raw)
  To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
	linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
	alsa-devel
  Cc: iommu

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.
> 
> 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(-)
> 
> diff --git a/drivers/net/caif/caif_spi.c b/drivers/net/caif/caif_spi.c
> index d28a1398c091..b7f3e263b57c 100644
> --- a/drivers/net/caif/caif_spi.c
> +++ b/drivers/net/caif/caif_spi.c
> @@ -73,35 +73,37 @@ MODULE_PARM_DESC(spi_down_tail_align, "SPI downlink tail alignment.");
>   #define LOW_WATER_MARK   100
>   #define HIGH_WATER_MARK  (LOW_WATER_MARK*5)
>   
> -#ifdef CONFIG_UML
> +#ifdef CONFIG_HAS_DMA

#ifndef, surely?

Robin.

>   
>   /*
>    * We sometimes use UML for debugging, but it cannot handle
>    * dma_alloc_coherent so we have to wrap it.
>    */
> -static inline void *dma_alloc(dma_addr_t *daddr)
> +static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
>   {
>   	return kmalloc(SPI_DMA_BUF_LEN, GFP_KERNEL);
>   }
>   
> -static inline void dma_free(void *cpu_addr, dma_addr_t handle)
> +static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
> +		dma_addr_t handle)
>   {
>   	kfree(cpu_addr);
>   }
>   
>   #else
>   
> -static inline void *dma_alloc(dma_addr_t *daddr)
> +static inline void *dma_alloc(struct cfspi *cfspi, dma_addr_t *daddr)
>   {
> -	return dma_alloc_coherent(NULL, SPI_DMA_BUF_LEN, daddr,
> +	return dma_alloc_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, daddr,
>   				GFP_KERNEL);
>   }
>   
> -static inline void dma_free(void *cpu_addr, dma_addr_t handle)
> +static inline void dma_free(struct cfspi *cfspi, void *cpu_addr,
> +		dma_addr_t handle)
>   {
> -	dma_free_coherent(NULL, SPI_DMA_BUF_LEN, cpu_addr, handle);
> +	dma_free_coherent(&cfspi->pdev->dev, SPI_DMA_BUF_LEN, cpu_addr, handle);
>   }
> -#endif	/* CONFIG_UML */
> +#endif	/* CONFIG_HAS_DMA */
>   
>   #ifdef CONFIG_DEBUG_FS
>   
> @@ -610,13 +612,13 @@ static int cfspi_init(struct net_device *dev)
>   	}
>   
>   	/* Allocate DMA buffers. */
> -	cfspi->xfer.va_tx[0] = dma_alloc(&cfspi->xfer.pa_tx[0]);
> +	cfspi->xfer.va_tx[0] = dma_alloc(cfspi, &cfspi->xfer.pa_tx[0]);
>   	if (!cfspi->xfer.va_tx[0]) {
>   		res = -ENODEV;
>   		goto err_dma_alloc_tx_0;
>   	}
>   
> -	cfspi->xfer.va_rx = dma_alloc(&cfspi->xfer.pa_rx);
> +	cfspi->xfer.va_rx = dma_alloc(cfspi, &cfspi->xfer.pa_rx);
>   
>   	if (!cfspi->xfer.va_rx) {
>   		res = -ENODEV;
> @@ -665,9 +667,9 @@ static int cfspi_init(struct net_device *dev)
>   	return 0;
>   
>    err_create_wq:
> -	dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> +	dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
>    err_dma_alloc_rx:
> -	dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
> +	dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
>    err_dma_alloc_tx_0:
>   	return res;
>   }
> @@ -683,8 +685,8 @@ static void cfspi_uninit(struct net_device *dev)
>   
>   	cfspi->ndev = NULL;
>   	/* Free DMA buffers. */
> -	dma_free(cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> -	dma_free(cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
> +	dma_free(cfspi, cfspi->xfer.va_rx, cfspi->xfer.pa_rx);
> +	dma_free(cfspi, cfspi->xfer.va_tx[0], cfspi->xfer.pa_tx[0]);
>   	set_bit(SPI_TERMINATE, &cfspi->state);
>   	wake_up_interruptible(&cfspi->wait);
>   	destroy_workqueue(cfspi->wq);
> 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 10/18] smc911x: pass struct device to DMA API functions
  2019-02-01  8:47 ` [PATCH 10/18] smc911x: " Christoph Hellwig
@ 2019-02-01 14:14   ` Robin Murphy
  2019-02-01 16:11     ` Christoph Hellwig
  0 siblings, 1 reply; 41+ messages in thread
From: Robin Murphy @ 2019-02-01 14:14 UTC (permalink / raw)
  To: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
	linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
	alsa-devel
  Cc: iommu

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...

> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
>   drivers/net/ethernet/smsc/smc911x.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/smsc/smc911x.c b/drivers/net/ethernet/smsc/smc911x.c
> index 8355dfbb8ec3..b550e624500d 100644
> --- a/drivers/net/ethernet/smsc/smc911x.c
> +++ b/drivers/net/ethernet/smsc/smc911x.c
> @@ -1188,7 +1188,7 @@ smc911x_tx_dma_irq(void *data)
>   
>   	DBG(SMC_DEBUG_TX | SMC_DEBUG_DMA, dev, "TX DMA irq handler\n");
>   	BUG_ON(skb == NULL);
> -	dma_unmap_single(NULL, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);
> +	dma_unmap_single(lp->dev, tx_dmabuf, tx_dmalen, DMA_TO_DEVICE);

..so while the wrong device is still better than no device at all, this 
probably wants lp->txdma->device->dev.

>   	netif_trans_update(dev);
>   	dev_kfree_skb_irq(skb);
>   	lp->current_tx_skb = NULL;
> @@ -1219,7 +1219,7 @@ smc911x_rx_dma_irq(void *data)
>   
>   	DBG(SMC_DEBUG_FUNC, dev, "--> %s\n", __func__);
>   	DBG(SMC_DEBUG_RX | SMC_DEBUG_DMA, dev, "RX DMA irq handler\n");
> -	dma_unmap_single(NULL, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);
> +	dma_unmap_single(lp->dev, rx_dmabuf, rx_dmalen, DMA_FROM_DEVICE);

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.

>   	BUG_ON(skb == NULL);
>   	lp->current_rx_skb = NULL;
>   	PRINT_PKT(skb->data, skb->len);
> 

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [alsa-devel] [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions
  2019-02-01 13:12   ` [alsa-devel] " Takashi Iwai
@ 2019-02-01 16:09     ` Christoph Hellwig
  2019-02-01 16:17       ` Takashi Iwai
  0 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 16:09 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
	linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
	alsa-devel, iommu

On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> Shall I take this one through sound git tree or all through yours?

Feel free to merge the sound bits through your tree!

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [alsa-devel] don't pass a NULL struct device to DMA API functions
  2019-02-01 13:16 ` [alsa-devel] don't pass a NULL " Takashi Iwai
@ 2019-02-01 16:09   ` Christoph Hellwig
  2019-02-01 16:18     ` Takashi Iwai
  0 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 16:09 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
	linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
	alsa-devel, iommu

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>

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
  2019-02-01 13:19   ` Felipe Balbi
@ 2019-02-01 16:10     ` Christoph Hellwig
  2019-02-11 13:12       ` Christoph Hellwig
  0 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 16:10 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu

On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> Christoph Hellwig <hch@lst.de> writes:
> 
> > dma_map_single already transfers ownership to the device.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Do you want me to take the USB bits or will you take the entire series?
> In case you're taking the entire series:

If you want to take the USB feel free.  I just want most of this in
this merge window if possible.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 03/18] net: caif: pass struct device to DMA API functions
  2019-02-01 13:53   ` Robin Murphy
@ 2019-02-01 16:10     ` Christoph Hellwig
  0 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 16:10 UTC (permalink / raw)
  To: Robin Murphy
  Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
	linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
	alsa-devel, iommu

On Fri, Feb 01, 2019 at 01:53:09PM +0000, Robin Murphy wrote:
>>   #define LOW_WATER_MARK   100
>>   #define HIGH_WATER_MARK  (LOW_WATER_MARK*5)
>>   -#ifdef CONFIG_UML
>> +#ifdef CONFIG_HAS_DMA
>
> #ifndef, surely?

Indeed.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 10/18] smc911x: pass struct device to DMA API functions
  2019-02-01 14:14   ` Robin Murphy
@ 2019-02-01 16:11     ` Christoph Hellwig
  0 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-01 16:11 UTC (permalink / raw)
  To: Robin Murphy
  Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
	linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
	alsa-devel, iommu

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.

Sounds good.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [alsa-devel] [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions
  2019-02-01 16:09     ` Christoph Hellwig
@ 2019-02-01 16:17       ` Takashi Iwai
  0 siblings, 0 replies; 41+ messages in thread
From: Takashi Iwai @ 2019-02-01 16:17 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu

On Fri, 01 Feb 2019 17:09:06 +0100,
Christoph Hellwig wrote:
> 
> On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> > Shall I take this one through sound git tree or all through yours?
> 
> Feel free to merge the sound bits through your tree!

Alright, merged both patches 17 and 18 now.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [alsa-devel] don't pass a NULL struct device to DMA API functions
  2019-02-01 16:09   ` Christoph Hellwig
@ 2019-02-01 16:18     ` Takashi Iwai
  0 siblings, 0 replies; 41+ messages in thread
From: Takashi Iwai @ 2019-02-01 16:18 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu

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:
> > 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


^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 02/18] dmaengine: imx-sdma: pass struct device to DMA API functions
  2019-02-01  8:47 ` [PATCH 02/18] dmaengine: imx-sdma: " Christoph Hellwig
@ 2019-02-02 10:11   ` Vinod Koul
  2019-02-02 17:21     ` Christoph Hellwig
  0 siblings, 1 reply; 41+ messages in thread
From: Vinod Koul @ 2019-02-02 10:11 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: John Crispin, Dmitry Tarnyagin, Nicolas Ferre, Sudip Mukherjee,
	Felipe Balbi, linux-mips, linux-kernel, dmaengine, netdev,
	linux-usb, linux-fbdev, alsa-devel, iommu

On 01-02-19, 09: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.

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

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 02/18] dmaengine: imx-sdma: pass struct device to DMA API functions
  2019-02-02 10:11   ` Vinod Koul
@ 2019-02-02 17:21     ` Christoph Hellwig
  0 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-02 17:21 UTC (permalink / raw)
  To: Vinod Koul
  Cc: Christoph Hellwig, John Crispin, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu

On Sat, Feb 02, 2019 at 03:41:21PM +0530, Vinod Koul wrote:
> On 01-02-19, 09: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.
> 
> 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 <fugang.duan@nxp.com>
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.

> 
> Thanks
> -- 
> ~Vinod
---end quoted text---

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions
  2019-02-01  8:47 ` [PATCH 01/18] MIPS: lantiq: pass " Christoph Hellwig
@ 2019-02-07 23:29   ` Paul Burton
  2019-02-12  7:45     ` Christoph Hellwig
  2019-02-12 17:41   ` Paul Burton
  1 sibling, 1 reply; 41+ messages in thread
From: Paul Burton @ 2019-02-07 23:29 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu

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

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
  2019-02-01 16:10     ` Christoph Hellwig
@ 2019-02-11 13:12       ` Christoph Hellwig
  2019-02-11 13:30         ` Felipe Balbi
  0 siblings, 1 reply; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-11 13:12 UTC (permalink / raw)
  To: Felipe Balbi
  Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu

On Fri, Feb 01, 2019 at 05:10:26PM +0100, Christoph Hellwig wrote:
> On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> > Christoph Hellwig <hch@lst.de> writes:
> > 
> > > dma_map_single already transfers ownership to the device.
> > >
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > 
> > Do you want me to take the USB bits or will you take the entire series?
> > In case you're taking the entire series:
> 
> If you want to take the USB feel free.  I just want most of this in
> this merge window if possible.

I didn't see in the USB tree yet, so please let me know if you want to
take it.

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call
  2019-02-11 13:12       ` Christoph Hellwig
@ 2019-02-11 13:30         ` Felipe Balbi
  0 siblings, 0 replies; 41+ messages in thread
From: Felipe Balbi @ 2019-02-11 13:30 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]


Hi,

Christoph Hellwig <hch@lst.de> writes:
> On Fri, Feb 01, 2019 at 05:10:26PM +0100, Christoph Hellwig wrote:
>> On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
>> > Christoph Hellwig <hch@lst.de> writes:
>> > 
>> > > dma_map_single already transfers ownership to the device.
>> > >
>> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
>> > 
>> > Do you want me to take the USB bits or will you take the entire series?
>> > In case you're taking the entire series:
>> 
>> If you want to take the USB feel free.  I just want most of this in
>> this merge window if possible.
>
> I didn't see in the USB tree yet, so please let me know if you want to
> take it.

sorry for the delay, just took it to my tree.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions
  2019-02-07 23:29   ` Paul Burton
@ 2019-02-12  7:45     ` Christoph Hellwig
  0 siblings, 0 replies; 41+ messages in thread
From: Christoph Hellwig @ 2019-02-12  7:45 UTC (permalink / raw)
  To: Paul Burton
  Cc: Christoph Hellwig, John Crispin, Vinod Koul, Dmitry Tarnyagin,
	Nicolas Ferre, Sudip Mukherjee, Felipe Balbi, linux-mips,
	linux-kernel, dmaengine, netdev, linux-usb, linux-fbdev,
	alsa-devel, iommu

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!

^ permalink raw reply	[flat|nested] 41+ messages in thread

* Re: [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions
  2019-02-01  8:47 ` [PATCH 01/18] MIPS: lantiq: pass " Christoph Hellwig
  2019-02-07 23:29   ` Paul Burton
@ 2019-02-12 17:41   ` Paul Burton
  1 sibling, 0 replies; 41+ messages in thread
From: Paul Burton @ 2019-02-12 17:41 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: John Crispin, Vinod Koul, Dmitry Tarnyagin, Nicolas Ferre,
	Sudip Mukherjee, Felipe Balbi, linux-mips, linux-kernel,
	dmaengine, netdev, linux-usb, linux-fbdev, alsa-devel, iommu,
	linux-mips

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. ]

^ permalink raw reply	[flat|nested] 41+ messages in thread

end of thread, other threads:[~2019-02-12 17:41 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-01  8:47 don't pass a NULL struct device to DMA API functions Christoph Hellwig
2019-02-01  8:47 ` [PATCH 01/18] MIPS: lantiq: pass " Christoph Hellwig
2019-02-07 23:29   ` Paul Burton
2019-02-12  7:45     ` Christoph Hellwig
2019-02-12 17:41   ` Paul Burton
2019-02-01  8:47 ` [PATCH 02/18] dmaengine: imx-sdma: " Christoph Hellwig
2019-02-02 10:11   ` Vinod Koul
2019-02-02 17:21     ` Christoph Hellwig
2019-02-01  8:47 ` [PATCH 03/18] net: caif: " Christoph Hellwig
2019-02-01 13:53   ` Robin Murphy
2019-02-01 16:10     ` Christoph Hellwig
2019-02-01  8:47 ` [PATCH 04/18] au1000_eth: " Christoph Hellwig
2019-02-01  8:47 ` [PATCH 05/18] macb_main: " Christoph Hellwig
2019-02-01 13:34   ` Nicolas.Ferre
2019-02-01  8:47 ` [PATCH 06/18] lantiq_etop: " Christoph Hellwig
2019-02-01  8:47 ` [PATCH 07/18] pxa168_eth: " Christoph Hellwig
2019-02-01  8:47 ` [PATCH 08/18] moxart_ether: " Christoph Hellwig
2019-02-01  8:47 ` [PATCH 09/18] meth: " Christoph Hellwig
2019-02-01  8:47 ` [PATCH 10/18] smc911x: " Christoph Hellwig
2019-02-01 14:14   ` Robin Murphy
2019-02-01 16:11     ` Christoph Hellwig
2019-02-01  8:47 ` [PATCH 11/18] parport_ip32: " Christoph Hellwig
2019-02-01  8:47 ` [PATCH 12/18] fotg210-udc: remove a bogus dma_sync_single_for_device call Christoph Hellwig
2019-02-01 13:19   ` Felipe Balbi
2019-02-01 16:10     ` Christoph Hellwig
2019-02-11 13:12       ` Christoph Hellwig
2019-02-11 13:30         ` Felipe Balbi
2019-02-01  8:47 ` [PATCH 13/18] fotg210-udc: pass struct device to DMA API functions Christoph Hellwig
2019-02-01 13:20   ` Felipe Balbi
2019-02-01  8:47 ` [PATCH 14/18] da8xx-fb: " Christoph Hellwig
2019-02-01  8:47 ` [PATCH 15/18] gbefb: switch to managed version of the DMA allocator Christoph Hellwig
2019-02-01  8:47 ` [PATCH 16/18] pxa3xx-gcu: pass struct device to dma_mmap_coherent Christoph Hellwig
2019-02-01  8:48 ` [PATCH 17/18] ALSA: hal2: pass struct device to DMA API functions Christoph Hellwig
2019-02-01 13:12   ` [alsa-devel] " Takashi Iwai
2019-02-01 16:09     ` Christoph Hellwig
2019-02-01 16:17       ` Takashi Iwai
2019-02-01  8:48 ` [PATCH 18/18] ALSA: " Christoph Hellwig
2019-02-01 13:13   ` [alsa-devel] " Takashi Iwai
2019-02-01 13:16 ` [alsa-devel] don't pass a NULL " Takashi Iwai
2019-02-01 16:09   ` Christoph Hellwig
2019-02-01 16:18     ` Takashi Iwai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).