All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: "David S. Miller" <davem@davemloft.net>
Cc: linux-arm-kernel@lists.infradead.org,
	Arnd Bergmann <arnd@arndb.de>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 1/9] net: davinci_cpdma: use dma_addr_t for DMA address
Date: Wed, 27 Jan 2016 15:04:51 +0100	[thread overview]
Message-ID: <1453903507-3427225-2-git-send-email-arnd@arndb.de> (raw)
In-Reply-To: <1453903507-3427225-1-git-send-email-arnd@arndb.de>

The davinci_cpdma mixes up physical addresses as seen from the CPU
and DMA addresses as seen from a DMA master, since it can operate
on both normal memory or an on-chip buffer. If dma_addr_t is
different from phys_addr_t, this means we get a compile-time warning
about the type mismatch:

ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
ethernet/ti/davinci_cpdma.c:182:48: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
   pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
In file included from ethernet/ti/davinci_cpdma.c:21:0:
dma-mapping.h:398:21: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
 static inline void *dma_alloc_coherent(struct device *dev, size_t size,

This slightly restructures the code so the address we use for
mapping RAM into a DMA address is always a dma_addr_t, avoiding
the warning. The code is correct even if both types are 32-bit
because the DMA master in this device only supports 32-bit addressing
anyway, independent of the types that are used.

We still assign this value to pool->phys, and that is wrong if
the driver is ever used with an IOMMU, but that value appears to
be never used, so there is no problem really. I've added a couple
of comments about where we do things that are slightly violating
the API.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/ethernet/ti/davinci_cpdma.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 657b65bf5cac..18bf3a8fdc50 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -82,7 +82,7 @@ struct cpdma_desc {
 
 struct cpdma_desc_pool {
 	phys_addr_t		phys;
-	u32			hw_addr;
+	dma_addr_t		hw_addr;
 	void __iomem		*iomap;		/* ioremap map */
 	void			*cpumap;	/* dma_alloc map */
 	int			desc_size, mem_size;
@@ -152,7 +152,7 @@ struct cpdma_chan {
  * abstract out these details
  */
 static struct cpdma_desc_pool *
-cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,
+cpdma_desc_pool_create(struct device *dev, u32 phys, dma_addr_t hw_addr,
 				int size, int align)
 {
 	int bitmap_size;
@@ -176,13 +176,13 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,
 
 	if (phys) {
 		pool->phys  = phys;
-		pool->iomap = ioremap(phys, size);
+		pool->iomap = ioremap(phys, size); /* should be memremap? */
 		pool->hw_addr = hw_addr;
 	} else {
-		pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
+		pool->cpumap = dma_alloc_coherent(dev, size, &pool->hw_addr,
 						  GFP_KERNEL);
-		pool->iomap = pool->cpumap;
-		pool->hw_addr = pool->phys;
+		pool->iomap = (void __iomem __force *)pool->cpumap;
+		pool->phys = pool->hw_addr; /* assumes no IOMMU, don't use this value */
 	}
 
 	if (pool->iomap)
-- 
2.7.0

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/9] net: davinci_cpdma: use dma_addr_t for DMA address
Date: Wed, 27 Jan 2016 15:04:51 +0100	[thread overview]
Message-ID: <1453903507-3427225-2-git-send-email-arnd@arndb.de> (raw)
In-Reply-To: <1453903507-3427225-1-git-send-email-arnd@arndb.de>

The davinci_cpdma mixes up physical addresses as seen from the CPU
and DMA addresses as seen from a DMA master, since it can operate
on both normal memory or an on-chip buffer. If dma_addr_t is
different from phys_addr_t, this means we get a compile-time warning
about the type mismatch:

ethernet/ti/davinci_cpdma.c: In function 'cpdma_desc_pool_create':
ethernet/ti/davinci_cpdma.c:182:48: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types]
   pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
In file included from ethernet/ti/davinci_cpdma.c:21:0:
dma-mapping.h:398:21: note: expected 'dma_addr_t * {aka long long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned int *}'
 static inline void *dma_alloc_coherent(struct device *dev, size_t size,

This slightly restructures the code so the address we use for
mapping RAM into a DMA address is always a dma_addr_t, avoiding
the warning. The code is correct even if both types are 32-bit
because the DMA master in this device only supports 32-bit addressing
anyway, independent of the types that are used.

We still assign this value to pool->phys, and that is wrong if
the driver is ever used with an IOMMU, but that value appears to
be never used, so there is no problem really. I've added a couple
of comments about where we do things that are slightly violating
the API.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/ethernet/ti/davinci_cpdma.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 657b65bf5cac..18bf3a8fdc50 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -82,7 +82,7 @@ struct cpdma_desc {
 
 struct cpdma_desc_pool {
 	phys_addr_t		phys;
-	u32			hw_addr;
+	dma_addr_t		hw_addr;
 	void __iomem		*iomap;		/* ioremap map */
 	void			*cpumap;	/* dma_alloc map */
 	int			desc_size, mem_size;
@@ -152,7 +152,7 @@ struct cpdma_chan {
  * abstract out these details
  */
 static struct cpdma_desc_pool *
-cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,
+cpdma_desc_pool_create(struct device *dev, u32 phys, dma_addr_t hw_addr,
 				int size, int align)
 {
 	int bitmap_size;
@@ -176,13 +176,13 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, u32 hw_addr,
 
 	if (phys) {
 		pool->phys  = phys;
-		pool->iomap = ioremap(phys, size);
+		pool->iomap = ioremap(phys, size); /* should be memremap? */
 		pool->hw_addr = hw_addr;
 	} else {
-		pool->cpumap = dma_alloc_coherent(dev, size, &pool->phys,
+		pool->cpumap = dma_alloc_coherent(dev, size, &pool->hw_addr,
 						  GFP_KERNEL);
-		pool->iomap = pool->cpumap;
-		pool->hw_addr = pool->phys;
+		pool->iomap = (void __iomem __force *)pool->cpumap;
+		pool->phys = pool->hw_addr; /* assumes no IOMMU, don't use this value */
 	}
 
 	if (pool->iomap)
-- 
2.7.0

  reply	other threads:[~2016-01-27 14:06 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27 14:04 [PATCH 0/9] network driver fixes Arnd Bergmann
2016-01-27 14:04 ` Arnd Bergmann
2016-01-27 14:04 ` Arnd Bergmann [this message]
2016-01-27 14:04   ` [PATCH 1/9] net: davinci_cpdma: use dma_addr_t for DMA address Arnd Bergmann
2016-01-27 14:04 ` [PATCH 2/9] net: hp100: remove unnecessary #ifdefs Arnd Bergmann
2016-01-27 14:04   ` Arnd Bergmann
2016-01-27 14:04 ` [PATCH 3/9] net: bgmac: clarify CONFIG_BCMA dependency Arnd Bergmann
2016-01-27 14:04   ` Arnd Bergmann
2016-01-27 16:11   ` Paul Gortmaker
2016-01-27 16:11     ` Paul Gortmaker
2016-01-27 16:11     ` Paul Gortmaker
2016-01-28  8:49     ` Arnd Bergmann
2016-01-28  8:49       ` Arnd Bergmann
2016-01-27 14:04 ` [PATCH 4/9] net: moxart: use correct accessors for DMA memory Arnd Bergmann
2016-01-27 14:04   ` Arnd Bergmann
2016-01-28 12:36   ` David Laight
2016-01-28 12:36     ` David Laight
2016-01-28 16:53     ` Arnd Bergmann
2016-01-28 16:53       ` Arnd Bergmann
2016-01-28 16:58       ` Arnd Bergmann
2016-01-28 16:58         ` Arnd Bergmann
2016-01-27 14:04 ` [PATCH 5/9] net: fddi/defxx: avoid warning about uninitialized variable use Arnd Bergmann
2016-01-27 14:04   ` Arnd Bergmann
2016-01-27 15:15   ` Maciej W. Rozycki
2016-01-27 15:15     ` Maciej W. Rozycki
2016-01-27 14:04 ` [PATCH 6/9] net: vxge: avoid unused function warnings Arnd Bergmann
2016-01-27 14:04   ` Arnd Bergmann
2016-01-27 14:04 ` [PATCH 7/9] net: macb: avoid uninitialized variables Arnd Bergmann
2016-01-27 14:04   ` Arnd Bergmann
2016-01-27 15:51   ` Nicolas Ferre
2016-01-27 15:51     ` Nicolas Ferre
2016-01-27 16:04     ` Nicolas Ferre
2016-01-27 16:04       ` Nicolas Ferre
2016-01-28 16:32       ` Arnd Bergmann
2016-01-28 16:32         ` Arnd Bergmann
2016-01-28 13:27   ` Sergei Shtylyov
2016-01-28 13:27     ` Sergei Shtylyov
2016-01-27 14:04 ` [PATCH 8/9] net: nb8800: avoid uninitialized variable warning Arnd Bergmann
2016-01-27 14:04   ` Arnd Bergmann
2016-01-27 14:13   ` Måns Rullgård
2016-01-27 14:13     ` Måns Rullgård
2016-01-27 15:21     ` Arnd Bergmann
2016-01-27 15:21       ` Arnd Bergmann
2016-01-27 14:04 ` [PATCH 9/9] net: tg3: " Arnd Bergmann
2016-01-27 14:04   ` Arnd Bergmann
2016-01-29  0:14 ` [PATCH 0/9] network driver fixes David Miller
2016-01-29  0:14   ` David Miller
2016-01-29 12:56   ` Arnd Bergmann
2016-01-29 12:56     ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1453903507-3427225-2-git-send-email-arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.