[PATCH] dma: use %pa to print dma_addr_t

[PATCH] dma: use %pa to print dma_addr_t

[Olof Johansson]

This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
dma_addr_t might then be 64-bit:

  drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]

Signed-off-by: Olof Johansson <olof@lixom.net>
---
 drivers/dma/imx-dma.c       |   20 ++++++++++----------
 drivers/dma/imx-sdma.c      |    8 ++++----
 drivers/dma/ipu/ipu_idmac.c |    6 ++++--
 3 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 78f8ca5..fcc8a12 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -576,9 +576,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
 
 		imx_dmav1_writel(imxdma, d->len, DMA_CNTR(imxdmac->channel));
 
-		dev_dbg(imxdma->dev, "%s channel: %d dest=0x%08x src=0x%08x "
+		dev_dbg(imxdma->dev, "%s channel: %d dest=%pa src=%pa "
 			"dma_length=%d\n", __func__, imxdmac->channel,
-			d->dest, d->src, d->len);
+			&d->dest, &d->src, d->len);
 
 		break;
 	/* Cyclic transfer is the same as slave_sg with special sg configuration. */
@@ -591,9 +591,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
 					 DMA_CCR(imxdmac->channel));
 
 			dev_dbg(imxdma->dev, "%s channel: %d sg=%p sgcount=%d "
-				"total length=%d dev_addr=0x%08x (dev2mem)\n",
+				"total length=%d dev_addr=%pa (dev2mem)\n",
 				__func__, imxdmac->channel, d->sg, d->sgcount,
-				d->len, imxdmac->per_address);
+				d->len, &imxdmac->per_address);
 		} else if (d->direction == DMA_MEM_TO_DEV) {
 			imx_dmav1_writel(imxdma, imxdmac->per_address,
 					 DMA_DAR(imxdmac->channel));
@@ -601,9 +601,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
 					 DMA_CCR(imxdmac->channel));
 
 			dev_dbg(imxdma->dev, "%s channel: %d sg=%p sgcount=%d "
-				"total length=%d dev_addr=0x%08x (mem2dev)\n",
+				"total length=%d dev_addr=%pa (mem2dev)\n",
 				__func__, imxdmac->channel, d->sg, d->sgcount,
-				d->len, imxdmac->per_address);
+				d->len, &imxdmac->per_address);
 		} else {
 			dev_err(imxdma->dev, "%s channel: %d bad dma mode\n",
 				__func__, imxdmac->channel);
@@ -927,8 +927,8 @@ static struct dma_async_tx_descriptor *imxdma_prep_dma_memcpy(
 	struct imxdma_engine *imxdma = imxdmac->imxdma;
 	struct imxdma_desc *desc;
 
-	dev_dbg(imxdma->dev, "%s channel: %d src=0x%x dst=0x%x len=%d\n",
-			__func__, imxdmac->channel, src, dest, len);
+	dev_dbg(imxdma->dev, "%s channel: %d src=%pa dst=%pa len=%d\n",
+			__func__, imxdmac->channel, &src, &dest, len);
 
 	if (list_empty(&imxdmac->ld_free) ||
 	    imxdma_chan_is_doing_cyclic(imxdmac))
@@ -957,9 +957,9 @@ static struct dma_async_tx_descriptor *imxdma_prep_dma_interleaved(
 	struct imxdma_engine *imxdma = imxdmac->imxdma;
 	struct imxdma_desc *desc;
 
-	dev_dbg(imxdma->dev, "%s channel: %d src_start=0x%x dst_start=0x%x\n"
+	dev_dbg(imxdma->dev, "%s channel: %d src_start=%pa dst_start=%pa\n"
 		"   src_sgl=%s dst_sgl=%s numf=%d frame_size=%d\n", __func__,
-		imxdmac->channel, xt->src_start, xt->dst_start,
+		imxdmac->channel, &xt->src_start, &xt->dst_start,
 		xt->src_sgl ? "true" : "false", xt->dst_sgl ? "true" : "false",
 		xt->numf, xt->frame_size);
 
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index fc43603..b6946c5 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1089,8 +1089,8 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
 			param &= ~BD_CONT;
 		}
 
-		dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
-				i, count, sg->dma_address,
+		dev_dbg(sdma->dev, "entry %d: count: %d dma: %pa %s%s\n",
+				i, count, &sg->dma_address,
 				param & BD_WRAP ? "wrap" : "",
 				param & BD_INTR ? " intr" : "");
 
@@ -1163,8 +1163,8 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
 		if (i + 1 == num_periods)
 			param |= BD_WRAP;
 
-		dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
-				i, period_len, dma_addr,
+		dev_dbg(sdma->dev, "entry %d: count: %d dma: %pa %s%s\n",
+				i, period_len, &dma_addr,
 				param & BD_WRAP ? "wrap" : "",
 				param & BD_INTR ? " intr" : "");
 
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index cb9c0bc..7d893c0 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1232,8 +1232,10 @@ static irqreturn_t idmac_interrupt(int irq, void *dev_id)
 	desc = list_entry(ichan->queue.next, struct idmac_tx_desc, list);
 	descnew = desc;
 
-	dev_dbg(dev, "IDMAC irq %d, dma 0x%08x, next dma 0x%08x, current %d, curbuf 0x%08x\n",
-		irq, sg_dma_address(*sg), sgnext ? sg_dma_address(sgnext) : 0, ichan->active_buffer, curbuf);
+	dev_dbg(dev, "IDMAC irq %d, dma %pa, next dma %pa, current %d, curbuf 0x%08x\n",
+		irq, &sg_dma_address(*sg),
+		sgnext ? &sg_dma_address(sgnext) : NULL, ichan->active_buffer,
+		curbuf);
 
 	/* Find the descriptor of sgnext */
 	sgnew = idmac_sg_next(ichan, &descnew, *sg);
-- 
1.7.10.4

[PATCH] dma: use %pa to print dma_addr_t

[Olof Johansson]

This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
dma_addr_t might then be 64-bit:

  drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
  drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]

Signed-off-by: Olof Johansson <olof@lixom.net>
---
 drivers/dma/imx-dma.c       |   20 ++++++++++----------
 drivers/dma/imx-sdma.c      |    8 ++++----
 drivers/dma/ipu/ipu_idmac.c |    6 ++++--
 3 files changed, 18 insertions(+), 16 deletions(-)

diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 78f8ca5..fcc8a12 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -576,9 +576,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
 
 		imx_dmav1_writel(imxdma, d->len, DMA_CNTR(imxdmac->channel));
 
-		dev_dbg(imxdma->dev, "%s channel: %d dest=0x%08x src=0x%08x "
+		dev_dbg(imxdma->dev, "%s channel: %d dest=%pa src=%pa "
 			"dma_length=%d\n", __func__, imxdmac->channel,
-			d->dest, d->src, d->len);
+			&d->dest, &d->src, d->len);
 
 		break;
 	/* Cyclic transfer is the same as slave_sg with special sg configuration. */
@@ -591,9 +591,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
 					 DMA_CCR(imxdmac->channel));
 
 			dev_dbg(imxdma->dev, "%s channel: %d sg=%p sgcount=%d "
-				"total length=%d dev_addr=0x%08x (dev2mem)\n",
+				"total length=%d dev_addr=%pa (dev2mem)\n",
 				__func__, imxdmac->channel, d->sg, d->sgcount,
-				d->len, imxdmac->per_address);
+				d->len, &imxdmac->per_address);
 		} else if (d->direction == DMA_MEM_TO_DEV) {
 			imx_dmav1_writel(imxdma, imxdmac->per_address,
 					 DMA_DAR(imxdmac->channel));
@@ -601,9 +601,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
 					 DMA_CCR(imxdmac->channel));
 
 			dev_dbg(imxdma->dev, "%s channel: %d sg=%p sgcount=%d "
-				"total length=%d dev_addr=0x%08x (mem2dev)\n",
+				"total length=%d dev_addr=%pa (mem2dev)\n",
 				__func__, imxdmac->channel, d->sg, d->sgcount,
-				d->len, imxdmac->per_address);
+				d->len, &imxdmac->per_address);
 		} else {
 			dev_err(imxdma->dev, "%s channel: %d bad dma mode\n",
 				__func__, imxdmac->channel);
@@ -927,8 +927,8 @@ static struct dma_async_tx_descriptor *imxdma_prep_dma_memcpy(
 	struct imxdma_engine *imxdma = imxdmac->imxdma;
 	struct imxdma_desc *desc;
 
-	dev_dbg(imxdma->dev, "%s channel: %d src=0x%x dst=0x%x len=%d\n",
-			__func__, imxdmac->channel, src, dest, len);
+	dev_dbg(imxdma->dev, "%s channel: %d src=%pa dst=%pa len=%d\n",
+			__func__, imxdmac->channel, &src, &dest, len);
 
 	if (list_empty(&imxdmac->ld_free) ||
 	    imxdma_chan_is_doing_cyclic(imxdmac))
@@ -957,9 +957,9 @@ static struct dma_async_tx_descriptor *imxdma_prep_dma_interleaved(
 	struct imxdma_engine *imxdma = imxdmac->imxdma;
 	struct imxdma_desc *desc;
 
-	dev_dbg(imxdma->dev, "%s channel: %d src_start=0x%x dst_start=0x%x\n"
+	dev_dbg(imxdma->dev, "%s channel: %d src_start=%pa dst_start=%pa\n"
 		"   src_sgl=%s dst_sgl=%s numf=%d frame_size=%d\n", __func__,
-		imxdmac->channel, xt->src_start, xt->dst_start,
+		imxdmac->channel, &xt->src_start, &xt->dst_start,
 		xt->src_sgl ? "true" : "false", xt->dst_sgl ? "true" : "false",
 		xt->numf, xt->frame_size);
 
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index fc43603..b6946c5 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1089,8 +1089,8 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
 			param &= ~BD_CONT;
 		}
 
-		dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
-				i, count, sg->dma_address,
+		dev_dbg(sdma->dev, "entry %d: count: %d dma: %pa %s%s\n",
+				i, count, &sg->dma_address,
 				param & BD_WRAP ? "wrap" : "",
 				param & BD_INTR ? " intr" : "");
 
@@ -1163,8 +1163,8 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
 		if (i + 1 == num_periods)
 			param |= BD_WRAP;
 
-		dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
-				i, period_len, dma_addr,
+		dev_dbg(sdma->dev, "entry %d: count: %d dma: %pa %s%s\n",
+				i, period_len, &dma_addr,
 				param & BD_WRAP ? "wrap" : "",
 				param & BD_INTR ? " intr" : "");
 
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index cb9c0bc..7d893c0 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1232,8 +1232,10 @@ static irqreturn_t idmac_interrupt(int irq, void *dev_id)
 	desc = list_entry(ichan->queue.next, struct idmac_tx_desc, list);
 	descnew = desc;
 
-	dev_dbg(dev, "IDMAC irq %d, dma 0x%08x, next dma 0x%08x, current %d, curbuf 0x%08x\n",
-		irq, sg_dma_address(*sg), sgnext ? sg_dma_address(sgnext) : 0, ichan->active_buffer, curbuf);
+	dev_dbg(dev, "IDMAC irq %d, dma %pa, next dma %pa, current %d, curbuf 0x%08x\n",
+		irq, &sg_dma_address(*sg),
+		sgnext ? &sg_dma_address(sgnext) : NULL, ichan->active_buffer,
+		curbuf);
 
 	/* Find the descriptor of sgnext */
 	sgnew = idmac_sg_next(ichan, &descnew, *sg);
-- 
1.7.10.4

Re: [PATCH] dma: use %pa to print dma_addr_t

[Randy Dunlap]

On 09/11/13 21:38, Olof Johansson wrote:
> This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
> dma_addr_t might then be 64-bit:
> 
>   drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]


I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
and %pa is for physical addresses, not necessarily DMA addresses.

Am I confused?


-- 
~Randy

[PATCH] dma: use %pa to print dma_addr_t

[Randy Dunlap]

On 09/11/13 21:38, Olof Johansson wrote:
> This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
> dma_addr_t might then be 64-bit:
> 
>   drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>   drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]


I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
and %pa is for physical addresses, not necessarily DMA addresses.

Am I confused?


-- 
~Randy

Re: [PATCH] dma: use %pa to print dma_addr_t

[Olof Johansson]

On Thu, Sep 12, 2013 at 10:05 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 09/11/13 21:38, Olof Johansson wrote:
>> This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
>> dma_addr_t might then be 64-bit:
>>
>>   drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
>
>
> I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
> and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
> and %pa is for physical addresses, not necessarily DMA addresses.
>
> Am I confused?

So, I prepared just that (allocating %pA for dma_addr_t) last night,
but after looking around a bit more, it was unclear to me if it's ever
meaningful to separate the two of them at different word sizes.

Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
well. The only architecture that doesn't seem to set
ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
that should just be changed there as well.


-Olof

[PATCH] dma: use %pa to print dma_addr_t

[Olof Johansson]

On Thu, Sep 12, 2013 at 10:05 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 09/11/13 21:38, Olof Johansson wrote:
>> This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
>> dma_addr_t might then be 64-bit:
>>
>>   drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>   drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
>
>
> I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
> and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
> and %pa is for physical addresses, not necessarily DMA addresses.
>
> Am I confused?

So, I prepared just that (allocating %pA for dma_addr_t) last night,
but after looking around a bit more, it was unclear to me if it's ever
meaningful to separate the two of them at different word sizes.

Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
well. The only architecture that doesn't seem to set
ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
that should just be changed there as well.


-Olof

Re: [PATCH] dma: use %pa to print dma_addr_t

[Joe Perches]

On Thu, 2013-09-12 at 10:05 -0700, Randy Dunlap wrote:
> On 09/11/13 21:38, Olof Johansson wrote:
> > This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
> > dma_addr_t might then be 64-bit:
> > 
> >   drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
> 
> 
> I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
> and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
> and %pa is for physical addresses, not necessarily DMA addresses.
> 
> Am I confused?

No.

https://lkml.org/lkml/2013/6/1/202

No.  If a dma_addr_t is really needed, then maybe
something like this:

---

 Documentation/printk-formats.txt | 11 +++++++++--
 lib/vsprintf.c                   | 33 +++++++++++++++++++++++++++------
 2 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 445ad74..6f4eb32 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -55,14 +55,21 @@ Struct Resources:
 	For printing struct resources. The 'R' and 'r' specifiers result in a
 	printed resource with ('R') or without ('r') a decoded flags member.
 
-Physical addresses:
+Physical addresses types phys_addr_t:
 
-	%pa	0x01234567 or 0x0123456789abcdef
+	%pa[p]	0x01234567 or 0x0123456789abcdef
 
 	For printing a phys_addr_t type (and its derivatives, such as
 	resource_size_t) which can vary based on build options, regardless of
 	the width of the CPU data path. Passed by reference.
 
+DMA addresses types dma_addr_t:
+
+	%pad	0x01234567 or 0x0123456789abcdef
+
+	For printing a dma_addr_t type which can vary based on build options,
+	regardless of the width of the CPU data path. Passed by reference.
+
 Raw buffer as a hex string:
 	%*ph	00 01 02  ...  3f
 	%*phC	00:01:02: ... :3f
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 43c2ea0..4df18bc 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1154,6 +1154,30 @@ char *netdev_feature_string(char *buf, char *end, const u8 *addr,
 	return number(buf, end, *(const netdev_features_t *)addr, spec);
 }
 
+static noinline_for_stack
+char *address_val(char *buf, char *end, const void *addr,
+		  struct printf_spec spec, const char *fmt)
+{
+	unsigned long long num;
+
+	spec.flags |= SPECIAL | SMALL | ZEROPAD;
+	spec.base = 16;
+
+	switch (fmt[1]) {
+	case 'd':
+		num = *(const dma_addr_t *)addr;
+		spec.field_width = sizeof(dma_addr_t) * 2 + 2;
+		break;
+	case 'p':
+	default:
+		num = *(const phys_addr_t *)addr;
+		spec.field_width = sizeof(phys_addr_t) * 2 + 2;
+		break;
+	}
+
+	return number(buf, end, num, spec);
+}
+
 int kptr_restrict __read_mostly;
 
 /*
@@ -1217,7 +1241,8 @@ int kptr_restrict __read_mostly;
  *              N no separator
  *            The maximum supported length is 64 bytes of the input. Consider
  *            to use print_hex_dump() for the larger input.
- * - 'a' For a phys_addr_t type and its derivative types (passed by reference)
+ * - 'a[pd]' For address types phys_addr_t, dma_addr_t and derivatives
+ *           (default assumed to be phys_addr_t, passed by reference)
  *
  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
  * function pointers are really function descriptors, which contain a
@@ -1324,11 +1349,7 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
 		}
 		break;
 	case 'a':
-		spec.flags |= SPECIAL | SMALL | ZEROPAD;
-		spec.field_width = sizeof(phys_addr_t) * 2 + 2;
-		spec.base = 16;
-		return number(buf, end,
-			      (unsigned long long) *((phys_addr_t *)ptr), spec);
+		return address_val(buf, end, ptr, spec, fmt);
 	case 'd':
 		return dentry_name(buf, end, ptr, spec, fmt);
 	case 'D':

[PATCH] dma: use %pa to print dma_addr_t

[Joe Perches]

On Thu, 2013-09-12 at 10:05 -0700, Randy Dunlap wrote:
> On 09/11/13 21:38, Olof Johansson wrote:
> > This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
> > dma_addr_t might then be 64-bit:
> > 
> >   drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> >   drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
> 
> 
> I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
> and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
> and %pa is for physical addresses, not necessarily DMA addresses.
> 
> Am I confused?

No.

https://lkml.org/lkml/2013/6/1/202

No.  If a dma_addr_t is really needed, then maybe
something like this:

---

 Documentation/printk-formats.txt | 11 +++++++++--
 lib/vsprintf.c                   | 33 +++++++++++++++++++++++++++------
 2 files changed, 36 insertions(+), 8 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 445ad74..6f4eb32 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -55,14 +55,21 @@ Struct Resources:
 	For printing struct resources. The 'R' and 'r' specifiers result in a
 	printed resource with ('R') or without ('r') a decoded flags member.
 
-Physical addresses:
+Physical addresses types phys_addr_t:
 
-	%pa	0x01234567 or 0x0123456789abcdef
+	%pa[p]	0x01234567 or 0x0123456789abcdef
 
 	For printing a phys_addr_t type (and its derivatives, such as
 	resource_size_t) which can vary based on build options, regardless of
 	the width of the CPU data path. Passed by reference.
 
+DMA addresses types dma_addr_t:
+
+	%pad	0x01234567 or 0x0123456789abcdef
+
+	For printing a dma_addr_t type which can vary based on build options,
+	regardless of the width of the CPU data path. Passed by reference.
+
 Raw buffer as a hex string:
 	%*ph	00 01 02  ...  3f
 	%*phC	00:01:02: ... :3f
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 43c2ea0..4df18bc 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1154,6 +1154,30 @@ char *netdev_feature_string(char *buf, char *end, const u8 *addr,
 	return number(buf, end, *(const netdev_features_t *)addr, spec);
 }
 
+static noinline_for_stack
+char *address_val(char *buf, char *end, const void *addr,
+		  struct printf_spec spec, const char *fmt)
+{
+	unsigned long long num;
+
+	spec.flags |= SPECIAL | SMALL | ZEROPAD;
+	spec.base = 16;
+
+	switch (fmt[1]) {
+	case 'd':
+		num = *(const dma_addr_t *)addr;
+		spec.field_width = sizeof(dma_addr_t) * 2 + 2;
+		break;
+	case 'p':
+	default:
+		num = *(const phys_addr_t *)addr;
+		spec.field_width = sizeof(phys_addr_t) * 2 + 2;
+		break;
+	}
+
+	return number(buf, end, num, spec);
+}
+
 int kptr_restrict __read_mostly;
 
 /*
@@ -1217,7 +1241,8 @@ int kptr_restrict __read_mostly;
  *              N no separator
  *            The maximum supported length is 64 bytes of the input. Consider
  *            to use print_hex_dump() for the larger input.
- * - 'a' For a phys_addr_t type and its derivative types (passed by reference)
+ * - 'a[pd]' For address types phys_addr_t, dma_addr_t and derivatives
+ *           (default assumed to be phys_addr_t, passed by reference)
  *
  * Note: The difference between 'S' and 'F' is that on ia64 and ppc64
  * function pointers are really function descriptors, which contain a
@@ -1324,11 +1349,7 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
 		}
 		break;
 	case 'a':
-		spec.flags |= SPECIAL | SMALL | ZEROPAD;
-		spec.field_width = sizeof(phys_addr_t) * 2 + 2;
-		spec.base = 16;
-		return number(buf, end,
-			      (unsigned long long) *((phys_addr_t *)ptr), spec);
+		return address_val(buf, end, ptr, spec, fmt);
 	case 'd':
 		return dentry_name(buf, end, ptr, spec, fmt);
 	case 'D':

Re: [PATCH] dma: use %pa to print dma_addr_t

[Russell King - ARM Linux]

On Thu, Sep 12, 2013 at 10:11:44AM -0700, Olof Johansson wrote:
> Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
> well. The only architecture that doesn't seem to set
> ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
> that should just be changed there as well.

Do we actually have any 64-bit DMA controllers out there?  As far as
I'm aware, all our DMA controllers are all 32-bit address only.  That
makes a 64-bit dma_addr_t rather silly.

Remember that dma_addr_t is the value you program into the DMA
controller, and _not_ the actual physical address.

[PATCH] dma: use %pa to print dma_addr_t

[Russell King - ARM Linux]

On Thu, Sep 12, 2013 at 10:11:44AM -0700, Olof Johansson wrote:
> Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
> well. The only architecture that doesn't seem to set
> ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
> that should just be changed there as well.

Do we actually have any 64-bit DMA controllers out there?  As far as
I'm aware, all our DMA controllers are all 32-bit address only.  That
makes a 64-bit dma_addr_t rather silly.

Remember that dma_addr_t is the value you program into the DMA
controller, and _not_ the actual physical address.

Re: [PATCH] dma: use %pa to print dma_addr_t

[Dan Williams]

On Thu, Sep 12, 2013 at 10:11 AM, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Sep 12, 2013 at 10:05 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
>> On 09/11/13 21:38, Olof Johansson wrote:
>>> This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
>>> dma_addr_t might then be 64-bit:
>>>
>>>   drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
>>
>>
>> I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
>> and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
>> and %pa is for physical addresses, not necessarily DMA addresses.
>>
>> Am I confused?
>
> So, I prepared just that (allocating %pA for dma_addr_t) last night,
> but after looking around a bit more, it was unclear to me if it's ever
> meaningful to separate the two of them at different word sizes.
>
> Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
> well. The only architecture that doesn't seem to set
> ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
> that should just be changed there as well.
>

Xen also plays games here and has a 32-bit physical address with
64-bit dma.  So I think we need something like Joe's patch.

--
Dan

[PATCH] dma: use %pa to print dma_addr_t

[Dan Williams]

On Thu, Sep 12, 2013 at 10:11 AM, Olof Johansson <olof@lixom.net> wrote:
> On Thu, Sep 12, 2013 at 10:05 AM, Randy Dunlap <rdunlap@infradead.org> wrote:
>> On 09/11/13 21:38, Olof Johansson wrote:
>>> This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
>>> dma_addr_t might then be 64-bit:
>>>
>>>   drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>>   drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
>>
>>
>> I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
>> and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
>> and %pa is for physical addresses, not necessarily DMA addresses.
>>
>> Am I confused?
>
> So, I prepared just that (allocating %pA for dma_addr_t) last night,
> but after looking around a bit more, it was unclear to me if it's ever
> meaningful to separate the two of them at different word sizes.
>
> Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
> well. The only architecture that doesn't seem to set
> ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
> that should just be changed there as well.
>

Xen also plays games here and has a 32-bit physical address with
64-bit dma.  So I think we need something like Joe's patch.

--
Dan

Re: [PATCH] dma: use %pa to print dma_addr_t

[Olof Johansson]

On Thu, Sep 12, 2013 at 10:35 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Sep 12, 2013 at 10:11:44AM -0700, Olof Johansson wrote:
>> Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
>> well. The only architecture that doesn't seem to set
>> ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
>> that should just be changed there as well.

The thread Joe linked to refers to a comment that is now deleted;
sparc64 apparantly has 32-bit dma_addr_t at least, so there are
platforms where the two differ permanently. Adding a new printk format
is probably needed here after all.

> Do we actually have any 64-bit DMA controllers out there?  As far as
> I'm aware, all our DMA controllers are all 32-bit address only.  That
> makes a 64-bit dma_addr_t rather silly.

PCI/PCI-e is the large unknown here, I'm not actually sure if any of
the current implementation of host controllers support it, but it
would seem likely that server-class hardware does.


-Olof

[PATCH] dma: use %pa to print dma_addr_t

[Olof Johansson]

On Thu, Sep 12, 2013 at 10:35 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Sep 12, 2013 at 10:11:44AM -0700, Olof Johansson wrote:
>> Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
>> well. The only architecture that doesn't seem to set
>> ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
>> that should just be changed there as well.

The thread Joe linked to refers to a comment that is now deleted;
sparc64 apparantly has 32-bit dma_addr_t at least, so there are
platforms where the two differ permanently. Adding a new printk format
is probably needed here after all.

> Do we actually have any 64-bit DMA controllers out there?  As far as
> I'm aware, all our DMA controllers are all 32-bit address only.  That
> makes a 64-bit dma_addr_t rather silly.

PCI/PCI-e is the large unknown here, I'm not actually sure if any of
the current implementation of host controllers support it, but it
would seem likely that server-class hardware does.


-Olof