[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

As the driver is now passing platform device to the DMA mapping functions,
we should give it valid DMA masks.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
Changes to previous version are:
	- moved this patch to be first
	- added Russell's acks

 arch/arm/mach-ep93xx/core.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 8207954..1d4b65f 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -402,11 +402,15 @@ static struct resource ep93xx_eth_resource[] = {
 	}
 };
 
+static u64 ep93xx_eth_dma_mask = DMA_BIT_MASK(32);
+
 static struct platform_device ep93xx_eth_device = {
 	.name		= "ep93xx-eth",
 	.id		= -1,
 	.dev		= {
-		.platform_data	= &ep93xx_eth_data,
+		.platform_data		= &ep93xx_eth_data,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.dma_mask		= &ep93xx_eth_dma_mask,
 	},
 	.num_resources	= ARRAY_SIZE(ep93xx_eth_resource),
 	.resource	= ep93xx_eth_resource,
-- 
1.7.4.4

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

As the driver is now passing platform device to the DMA mapping functions,
we should give it valid DMA masks.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
Changes to previous version are:
	- moved this patch to be first
	- added Russell's acks

 arch/arm/mach-ep93xx/core.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 8207954..1d4b65f 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -402,11 +402,15 @@ static struct resource ep93xx_eth_resource[] = {
 	}
 };
 
+static u64 ep93xx_eth_dma_mask = DMA_BIT_MASK(32);
+
 static struct platform_device ep93xx_eth_device = {
 	.name		= "ep93xx-eth",
 	.id		= -1,
 	.dev		= {
-		.platform_data	= &ep93xx_eth_data,
+		.platform_data		= &ep93xx_eth_data,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.dma_mask		= &ep93xx_eth_dma_mask,
 	},
 	.num_resources	= ARRAY_SIZE(ep93xx_eth_resource),
 	.resource	= ep93xx_eth_resource,
-- 
1.7.4.4

[PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions

[Mika Westerberg]

We shouldn't use NULL for any DMA API functions, unless we are dealing with
ISA or EISA device. So pass correct struct dev pointer to these functions.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/net/arm/ep93xx_eth.c |   26 ++++++++++++++++----------
 1 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 5a77001..8779d3b 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -159,6 +159,8 @@ struct ep93xx_priv
 	void __iomem		*base_addr;
 	int			irq;
 
+	struct device		*dma_dev;
+
 	struct ep93xx_descs	*descs;
 	dma_addr_t		descs_dma_addr;
 
@@ -284,7 +286,8 @@ static int ep93xx_rx(struct net_device *dev, int processed, int budget)
 		skb = dev_alloc_skb(length + 2);
 		if (likely(skb != NULL)) {
 			skb_reserve(skb, 2);
-			dma_sync_single_for_cpu(NULL, ep->descs->rdesc[entry].buf_addr,
+			dma_sync_single_for_cpu(ep->dma_dev,
+						ep->descs->rdesc[entry].buf_addr,
 						length, DMA_FROM_DEVICE);
 			skb_copy_to_linear_data(skb, ep->rx_buf[entry], length);
 			skb_put(skb, length);
@@ -362,7 +365,7 @@ static int ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
 	ep->descs->tdesc[entry].tdesc1 =
 		TDESC1_EOF | (entry << 16) | (skb->len & 0xfff);
 	skb_copy_and_csum_dev(skb, ep->tx_buf[entry]);
-	dma_sync_single_for_cpu(NULL, ep->descs->tdesc[entry].buf_addr,
+	dma_sync_single_for_cpu(ep->dma_dev, ep->descs->tdesc[entry].buf_addr,
 				skb->len, DMA_TO_DEVICE);
 	dev_kfree_skb(skb);
 
@@ -457,6 +460,7 @@ static irqreturn_t ep93xx_irq(int irq, void *dev_id)
 
 static void ep93xx_free_buffers(struct ep93xx_priv *ep)
 {
+	struct device *dev = ep->dma_dev;
 	int i;
 
 	for (i = 0; i < RX_QUEUE_ENTRIES; i += 2) {
@@ -464,7 +468,7 @@ static void ep93xx_free_buffers(struct ep93xx_priv *ep)
 
 		d = ep->descs->rdesc[i].buf_addr;
 		if (d)
-			dma_unmap_single(NULL, d, PAGE_SIZE, DMA_FROM_DEVICE);
+			dma_unmap_single(dev, d, PAGE_SIZE, DMA_FROM_DEVICE);
 
 		if (ep->rx_buf[i] != NULL)
 			free_page((unsigned long)ep->rx_buf[i]);
@@ -475,13 +479,13 @@ static void ep93xx_free_buffers(struct ep93xx_priv *ep)
 
 		d = ep->descs->tdesc[i].buf_addr;
 		if (d)
-			dma_unmap_single(NULL, d, PAGE_SIZE, DMA_TO_DEVICE);
+			dma_unmap_single(dev, d, PAGE_SIZE, DMA_TO_DEVICE);
 
 		if (ep->tx_buf[i] != NULL)
 			free_page((unsigned long)ep->tx_buf[i]);
 	}
 
-	dma_free_coherent(NULL, sizeof(struct ep93xx_descs), ep->descs,
+	dma_free_coherent(dev, sizeof(struct ep93xx_descs), ep->descs,
 							ep->descs_dma_addr);
 }
 
@@ -491,9 +495,10 @@ static void ep93xx_free_buffers(struct ep93xx_priv *ep)
  */
 static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 {
+	struct device *dev = ep->dma_dev;
 	int i;
 
-	ep->descs = dma_alloc_coherent(NULL, sizeof(struct ep93xx_descs),
+	ep->descs = dma_alloc_coherent(dev, sizeof(struct ep93xx_descs),
 				&ep->descs_dma_addr, GFP_KERNEL | GFP_DMA);
 	if (ep->descs == NULL)
 		return 1;
@@ -506,8 +511,8 @@ static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 		if (page == NULL)
 			goto err;
 
-		d = dma_map_single(NULL, page, PAGE_SIZE, DMA_FROM_DEVICE);
-		if (dma_mapping_error(NULL, d)) {
+		d = dma_map_single(dev, page, PAGE_SIZE, DMA_FROM_DEVICE);
+		if (dma_mapping_error(dev, d)) {
 			free_page((unsigned long)page);
 			goto err;
 		}
@@ -529,8 +534,8 @@ static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 		if (page == NULL)
 			goto err;
 
-		d = dma_map_single(NULL, page, PAGE_SIZE, DMA_TO_DEVICE);
-		if (dma_mapping_error(NULL, d)) {
+		d = dma_map_single(dev, page, PAGE_SIZE, DMA_TO_DEVICE);
+		if (dma_mapping_error(dev, d)) {
 			free_page((unsigned long)page);
 			goto err;
 		}
@@ -829,6 +834,7 @@ static int ep93xx_eth_probe(struct platform_device *pdev)
 	}
 	ep = netdev_priv(dev);
 	ep->dev = dev;
+	ep->dma_dev = &pdev->dev;
 	netif_napi_add(dev, &ep->napi, ep93xx_poll, 64);
 
 	platform_set_drvdata(pdev, dev);
-- 
1.7.4.4

[PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions

[Mika Westerberg]

We shouldn't use NULL for any DMA API functions, unless we are dealing with
ISA or EISA device. So pass correct struct dev pointer to these functions.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/net/arm/ep93xx_eth.c |   26 ++++++++++++++++----------
 1 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 5a77001..8779d3b 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -159,6 +159,8 @@ struct ep93xx_priv
 	void __iomem		*base_addr;
 	int			irq;
 
+	struct device		*dma_dev;
+
 	struct ep93xx_descs	*descs;
 	dma_addr_t		descs_dma_addr;
 
@@ -284,7 +286,8 @@ static int ep93xx_rx(struct net_device *dev, int processed, int budget)
 		skb = dev_alloc_skb(length + 2);
 		if (likely(skb != NULL)) {
 			skb_reserve(skb, 2);
-			dma_sync_single_for_cpu(NULL, ep->descs->rdesc[entry].buf_addr,
+			dma_sync_single_for_cpu(ep->dma_dev,
+						ep->descs->rdesc[entry].buf_addr,
 						length, DMA_FROM_DEVICE);
 			skb_copy_to_linear_data(skb, ep->rx_buf[entry], length);
 			skb_put(skb, length);
@@ -362,7 +365,7 @@ static int ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
 	ep->descs->tdesc[entry].tdesc1 =
 		TDESC1_EOF | (entry << 16) | (skb->len & 0xfff);
 	skb_copy_and_csum_dev(skb, ep->tx_buf[entry]);
-	dma_sync_single_for_cpu(NULL, ep->descs->tdesc[entry].buf_addr,
+	dma_sync_single_for_cpu(ep->dma_dev, ep->descs->tdesc[entry].buf_addr,
 				skb->len, DMA_TO_DEVICE);
 	dev_kfree_skb(skb);
 
@@ -457,6 +460,7 @@ static irqreturn_t ep93xx_irq(int irq, void *dev_id)
 
 static void ep93xx_free_buffers(struct ep93xx_priv *ep)
 {
+	struct device *dev = ep->dma_dev;
 	int i;
 
 	for (i = 0; i < RX_QUEUE_ENTRIES; i += 2) {
@@ -464,7 +468,7 @@ static void ep93xx_free_buffers(struct ep93xx_priv *ep)
 
 		d = ep->descs->rdesc[i].buf_addr;
 		if (d)
-			dma_unmap_single(NULL, d, PAGE_SIZE, DMA_FROM_DEVICE);
+			dma_unmap_single(dev, d, PAGE_SIZE, DMA_FROM_DEVICE);
 
 		if (ep->rx_buf[i] != NULL)
 			free_page((unsigned long)ep->rx_buf[i]);
@@ -475,13 +479,13 @@ static void ep93xx_free_buffers(struct ep93xx_priv *ep)
 
 		d = ep->descs->tdesc[i].buf_addr;
 		if (d)
-			dma_unmap_single(NULL, d, PAGE_SIZE, DMA_TO_DEVICE);
+			dma_unmap_single(dev, d, PAGE_SIZE, DMA_TO_DEVICE);
 
 		if (ep->tx_buf[i] != NULL)
 			free_page((unsigned long)ep->tx_buf[i]);
 	}
 
-	dma_free_coherent(NULL, sizeof(struct ep93xx_descs), ep->descs,
+	dma_free_coherent(dev, sizeof(struct ep93xx_descs), ep->descs,
 							ep->descs_dma_addr);
 }
 
@@ -491,9 +495,10 @@ static void ep93xx_free_buffers(struct ep93xx_priv *ep)
  */
 static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 {
+	struct device *dev = ep->dma_dev;
 	int i;
 
-	ep->descs = dma_alloc_coherent(NULL, sizeof(struct ep93xx_descs),
+	ep->descs = dma_alloc_coherent(dev, sizeof(struct ep93xx_descs),
 				&ep->descs_dma_addr, GFP_KERNEL | GFP_DMA);
 	if (ep->descs == NULL)
 		return 1;
@@ -506,8 +511,8 @@ static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 		if (page == NULL)
 			goto err;
 
-		d = dma_map_single(NULL, page, PAGE_SIZE, DMA_FROM_DEVICE);
-		if (dma_mapping_error(NULL, d)) {
+		d = dma_map_single(dev, page, PAGE_SIZE, DMA_FROM_DEVICE);
+		if (dma_mapping_error(dev, d)) {
 			free_page((unsigned long)page);
 			goto err;
 		}
@@ -529,8 +534,8 @@ static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 		if (page == NULL)
 			goto err;
 
-		d = dma_map_single(NULL, page, PAGE_SIZE, DMA_TO_DEVICE);
-		if (dma_mapping_error(NULL, d)) {
+		d = dma_map_single(dev, page, PAGE_SIZE, DMA_TO_DEVICE);
+		if (dma_mapping_error(dev, d)) {
 			free_page((unsigned long)page);
 			goto err;
 		}
@@ -829,6 +834,7 @@ static int ep93xx_eth_probe(struct platform_device *pdev)
 	}
 	ep = netdev_priv(dev);
 	ep->dev = dev;
+	ep->dma_dev = &pdev->dev;
 	netif_napi_add(dev, &ep->napi, ep93xx_poll, 64);
 
 	platform_set_drvdata(pdev, dev);
-- 
1.7.4.4

[PATCH v2 3/5] net: ep93xx_eth: allocate buffers using kmalloc()

[Mika Westerberg]

We can use simply kmalloc() to allocate the buffers. This also simplifies the
code and allows us to perform DMA sync operations more easily.

Memory is allocated with only GFP_KERNEL since there are no DMA allocation
restrictions on this platform.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/net/arm/ep93xx_eth.c |   51 ++++++++++++++++-------------------------
 1 files changed, 20 insertions(+), 31 deletions(-)

diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 8779d3b..0c9df11 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -463,36 +463,32 @@ static void ep93xx_free_buffers(struct ep93xx_priv *ep)
 	struct device *dev = ep->dma_dev;
 	int i;
 
-	for (i = 0; i < RX_QUEUE_ENTRIES; i += 2) {
+	for (i = 0; i < RX_QUEUE_ENTRIES; i++) {
 		dma_addr_t d;
 
 		d = ep->descs->rdesc[i].buf_addr;
 		if (d)
-			dma_unmap_single(dev, d, PAGE_SIZE, DMA_FROM_DEVICE);
+			dma_unmap_single(dev, d, PKT_BUF_SIZE, DMA_FROM_DEVICE);
 
 		if (ep->rx_buf[i] != NULL)
-			free_page((unsigned long)ep->rx_buf[i]);
+			kfree(ep->rx_buf[i]);
 	}
 
-	for (i = 0; i < TX_QUEUE_ENTRIES; i += 2) {
+	for (i = 0; i < TX_QUEUE_ENTRIES; i++) {
 		dma_addr_t d;
 
 		d = ep->descs->tdesc[i].buf_addr;
 		if (d)
-			dma_unmap_single(dev, d, PAGE_SIZE, DMA_TO_DEVICE);
+			dma_unmap_single(dev, d, PKT_BUF_SIZE, DMA_TO_DEVICE);
 
 		if (ep->tx_buf[i] != NULL)
-			free_page((unsigned long)ep->tx_buf[i]);
+			kfree(ep->tx_buf[i]);
 	}
 
 	dma_free_coherent(dev, sizeof(struct ep93xx_descs), ep->descs,
 							ep->descs_dma_addr);
 }
 
-/*
- * The hardware enforces a sub-2K maximum packet size, so we put
- * two buffers on every hardware page.
- */
 static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 {
 	struct device *dev = ep->dma_dev;
@@ -503,48 +499,41 @@ static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 	if (ep->descs == NULL)
 		return 1;
 
-	for (i = 0; i < RX_QUEUE_ENTRIES; i += 2) {
-		void *page;
+	for (i = 0; i < RX_QUEUE_ENTRIES; i++) {
+		void *buf;
 		dma_addr_t d;
 
-		page = (void *)__get_free_page(GFP_KERNEL | GFP_DMA);
-		if (page == NULL)
+		buf = kmalloc(PKT_BUF_SIZE, GFP_KERNEL);
+		if (buf == NULL)
 			goto err;
 
-		d = dma_map_single(dev, page, PAGE_SIZE, DMA_FROM_DEVICE);
+		d = dma_map_single(dev, buf, PKT_BUF_SIZE, DMA_FROM_DEVICE);
 		if (dma_mapping_error(dev, d)) {
-			free_page((unsigned long)page);
+			kfree(buf);
 			goto err;
 		}
 
-		ep->rx_buf[i] = page;
+		ep->rx_buf[i] = buf;
 		ep->descs->rdesc[i].buf_addr = d;
 		ep->descs->rdesc[i].rdesc1 = (i << 16) | PKT_BUF_SIZE;
-
-		ep->rx_buf[i + 1] = page + PKT_BUF_SIZE;
-		ep->descs->rdesc[i + 1].buf_addr = d + PKT_BUF_SIZE;
-		ep->descs->rdesc[i + 1].rdesc1 = ((i + 1) << 16) | PKT_BUF_SIZE;
 	}
 
-	for (i = 0; i < TX_QUEUE_ENTRIES; i += 2) {
-		void *page;
+	for (i = 0; i < TX_QUEUE_ENTRIES; i++) {
+		void *buf;
 		dma_addr_t d;
 
-		page = (void *)__get_free_page(GFP_KERNEL | GFP_DMA);
-		if (page == NULL)
+		buf = kmalloc(PKT_BUF_SIZE, GFP_KERNEL);
+		if (buf == NULL)
 			goto err;
 
-		d = dma_map_single(dev, page, PAGE_SIZE, DMA_TO_DEVICE);
+		d = dma_map_single(dev, buf, PKT_BUF_SIZE, DMA_TO_DEVICE);
 		if (dma_mapping_error(dev, d)) {
-			free_page((unsigned long)page);
+			kfree(buf);
 			goto err;
 		}
 
-		ep->tx_buf[i] = page;
+		ep->tx_buf[i] = buf;
 		ep->descs->tdesc[i].buf_addr = d;
-
-		ep->tx_buf[i + 1] = page + PKT_BUF_SIZE;
-		ep->descs->tdesc[i + 1].buf_addr = d + PKT_BUF_SIZE;
 	}
 
 	return 0;
-- 
1.7.4.4

[PATCH v2 3/5] net: ep93xx_eth: allocate buffers using kmalloc()

[Mika Westerberg]

We can use simply kmalloc() to allocate the buffers. This also simplifies the
code and allows us to perform DMA sync operations more easily.

Memory is allocated with only GFP_KERNEL since there are no DMA allocation
restrictions on this platform.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/net/arm/ep93xx_eth.c |   51 ++++++++++++++++-------------------------
 1 files changed, 20 insertions(+), 31 deletions(-)

diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 8779d3b..0c9df11 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -463,36 +463,32 @@ static void ep93xx_free_buffers(struct ep93xx_priv *ep)
 	struct device *dev = ep->dma_dev;
 	int i;
 
-	for (i = 0; i < RX_QUEUE_ENTRIES; i += 2) {
+	for (i = 0; i < RX_QUEUE_ENTRIES; i++) {
 		dma_addr_t d;
 
 		d = ep->descs->rdesc[i].buf_addr;
 		if (d)
-			dma_unmap_single(dev, d, PAGE_SIZE, DMA_FROM_DEVICE);
+			dma_unmap_single(dev, d, PKT_BUF_SIZE, DMA_FROM_DEVICE);
 
 		if (ep->rx_buf[i] != NULL)
-			free_page((unsigned long)ep->rx_buf[i]);
+			kfree(ep->rx_buf[i]);
 	}
 
-	for (i = 0; i < TX_QUEUE_ENTRIES; i += 2) {
+	for (i = 0; i < TX_QUEUE_ENTRIES; i++) {
 		dma_addr_t d;
 
 		d = ep->descs->tdesc[i].buf_addr;
 		if (d)
-			dma_unmap_single(dev, d, PAGE_SIZE, DMA_TO_DEVICE);
+			dma_unmap_single(dev, d, PKT_BUF_SIZE, DMA_TO_DEVICE);
 
 		if (ep->tx_buf[i] != NULL)
-			free_page((unsigned long)ep->tx_buf[i]);
+			kfree(ep->tx_buf[i]);
 	}
 
 	dma_free_coherent(dev, sizeof(struct ep93xx_descs), ep->descs,
 							ep->descs_dma_addr);
 }
 
-/*
- * The hardware enforces a sub-2K maximum packet size, so we put
- * two buffers on every hardware page.
- */
 static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 {
 	struct device *dev = ep->dma_dev;
@@ -503,48 +499,41 @@ static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 	if (ep->descs == NULL)
 		return 1;
 
-	for (i = 0; i < RX_QUEUE_ENTRIES; i += 2) {
-		void *page;
+	for (i = 0; i < RX_QUEUE_ENTRIES; i++) {
+		void *buf;
 		dma_addr_t d;
 
-		page = (void *)__get_free_page(GFP_KERNEL | GFP_DMA);
-		if (page == NULL)
+		buf = kmalloc(PKT_BUF_SIZE, GFP_KERNEL);
+		if (buf == NULL)
 			goto err;
 
-		d = dma_map_single(dev, page, PAGE_SIZE, DMA_FROM_DEVICE);
+		d = dma_map_single(dev, buf, PKT_BUF_SIZE, DMA_FROM_DEVICE);
 		if (dma_mapping_error(dev, d)) {
-			free_page((unsigned long)page);
+			kfree(buf);
 			goto err;
 		}
 
-		ep->rx_buf[i] = page;
+		ep->rx_buf[i] = buf;
 		ep->descs->rdesc[i].buf_addr = d;
 		ep->descs->rdesc[i].rdesc1 = (i << 16) | PKT_BUF_SIZE;
-
-		ep->rx_buf[i + 1] = page + PKT_BUF_SIZE;
-		ep->descs->rdesc[i + 1].buf_addr = d + PKT_BUF_SIZE;
-		ep->descs->rdesc[i + 1].rdesc1 = ((i + 1) << 16) | PKT_BUF_SIZE;
 	}
 
-	for (i = 0; i < TX_QUEUE_ENTRIES; i += 2) {
-		void *page;
+	for (i = 0; i < TX_QUEUE_ENTRIES; i++) {
+		void *buf;
 		dma_addr_t d;
 
-		page = (void *)__get_free_page(GFP_KERNEL | GFP_DMA);
-		if (page == NULL)
+		buf = kmalloc(PKT_BUF_SIZE, GFP_KERNEL);
+		if (buf == NULL)
 			goto err;
 
-		d = dma_map_single(dev, page, PAGE_SIZE, DMA_TO_DEVICE);
+		d = dma_map_single(dev, buf, PKT_BUF_SIZE, DMA_TO_DEVICE);
 		if (dma_mapping_error(dev, d)) {
-			free_page((unsigned long)page);
+			kfree(buf);
 			goto err;
 		}
 
-		ep->tx_buf[i] = page;
+		ep->tx_buf[i] = buf;
 		ep->descs->tdesc[i].buf_addr = d;
-
-		ep->tx_buf[i + 1] = page + PKT_BUF_SIZE;
-		ep->descs->tdesc[i + 1].buf_addr = d + PKT_BUF_SIZE;
 	}
 
 	return 0;
-- 
1.7.4.4

[PATCH v2 4/5] net: ep93xx_eth: drop GFP_DMA from call to dma_alloc_coherent()

[Mika Westerberg]

Commit a197b59ae6e8 (mm: fail GFP_DMA allocations when ZONE_DMA is not
configured) made page allocator to return NULL if GFP_DMA is set but
CONFIG_ZONE_DMA is disabled.

This causes ep93xx_eth to fail:

 WARNING: at mm/page_alloc.c:2251 __alloc_pages_nodemask+0x11c/0x638()
 Modules linked in:
 [<c0035498>] (unwind_backtrace+0x0/0xf4) from [<c0043da4>] (warn_slowpath_common+0x48/0x60)
 [<c0043da4>] (warn_slowpath_common+0x48/0x60) from [<c0043dd8>] (warn_slowpath_null+0x1c/0x24)
 [<c0043dd8>] (warn_slowpath_null+0x1c/0x24) from [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638)
 [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) from [<c00366fc>] (__dma_alloc+0x8c/0x3ec)
 [<c00366fc>] (__dma_alloc+0x8c/0x3ec) from [<c0036adc>] (dma_alloc_coherent+0x54/0x60)
 [<c0036adc>] (dma_alloc_coherent+0x54/0x60) from [<c0227808>] (ep93xx_open+0x20/0x864)
 [<c0227808>] (ep93xx_open+0x20/0x864) from [<c0283144>] (__dev_open+0xb8/0x108)
 [<c0283144>] (__dev_open+0xb8/0x108) from [<c0280528>] (__dev_change_flags+0x70/0x128)
 [<c0280528>] (__dev_change_flags+0x70/0x128) from [<c0283054>] (dev_change_flags+0x10/0x48)
 [<c0283054>] (dev_change_flags+0x10/0x48) from [<c001a720>] (ip_auto_config+0x190/0xf68)
 [<c001a720>] (ip_auto_config+0x190/0xf68) from [<c00233b0>] (do_one_initcall+0x34/0x18c)
 [<c00233b0>] (do_one_initcall+0x34/0x18c) from [<c0008400>] (kernel_init+0x94/0x134)
 [<c0008400>] (kernel_init+0x94/0x134) from [<c0030858>] (kernel_thread_exit+0x0/0x8)

Since there is no restrictions for DMA on ep93xx, we can fix this by just
removing the GFP_DMA flag from the call.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/net/arm/ep93xx_eth.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 0c9df11..56b51a1 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -495,7 +495,7 @@ static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 	int i;
 
 	ep->descs = dma_alloc_coherent(dev, sizeof(struct ep93xx_descs),
-				&ep->descs_dma_addr, GFP_KERNEL | GFP_DMA);
+				&ep->descs_dma_addr, GFP_KERNEL);
 	if (ep->descs == NULL)
 		return 1;
 
-- 
1.7.4.4

[PATCH v2 4/5] net: ep93xx_eth: drop GFP_DMA from call to dma_alloc_coherent()

[Mika Westerberg]

Commit a197b59ae6e8 (mm: fail GFP_DMA allocations when ZONE_DMA is not
configured) made page allocator to return NULL if GFP_DMA is set but
CONFIG_ZONE_DMA is disabled.

This causes ep93xx_eth to fail:

 WARNING: at mm/page_alloc.c:2251 __alloc_pages_nodemask+0x11c/0x638()
 Modules linked in:
 [<c0035498>] (unwind_backtrace+0x0/0xf4) from [<c0043da4>] (warn_slowpath_common+0x48/0x60)
 [<c0043da4>] (warn_slowpath_common+0x48/0x60) from [<c0043dd8>] (warn_slowpath_null+0x1c/0x24)
 [<c0043dd8>] (warn_slowpath_null+0x1c/0x24) from [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638)
 [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) from [<c00366fc>] (__dma_alloc+0x8c/0x3ec)
 [<c00366fc>] (__dma_alloc+0x8c/0x3ec) from [<c0036adc>] (dma_alloc_coherent+0x54/0x60)
 [<c0036adc>] (dma_alloc_coherent+0x54/0x60) from [<c0227808>] (ep93xx_open+0x20/0x864)
 [<c0227808>] (ep93xx_open+0x20/0x864) from [<c0283144>] (__dev_open+0xb8/0x108)
 [<c0283144>] (__dev_open+0xb8/0x108) from [<c0280528>] (__dev_change_flags+0x70/0x128)
 [<c0280528>] (__dev_change_flags+0x70/0x128) from [<c0283054>] (dev_change_flags+0x10/0x48)
 [<c0283054>] (dev_change_flags+0x10/0x48) from [<c001a720>] (ip_auto_config+0x190/0xf68)
 [<c001a720>] (ip_auto_config+0x190/0xf68) from [<c00233b0>] (do_one_initcall+0x34/0x18c)
 [<c00233b0>] (do_one_initcall+0x34/0x18c) from [<c0008400>] (kernel_init+0x94/0x134)
 [<c0008400>] (kernel_init+0x94/0x134) from [<c0030858>] (kernel_thread_exit+0x0/0x8)

Since there is no restrictions for DMA on ep93xx, we can fix this by just
removing the GFP_DMA flag from the call.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/net/arm/ep93xx_eth.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 0c9df11..56b51a1 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -495,7 +495,7 @@ static int ep93xx_alloc_buffers(struct ep93xx_priv *ep)
 	int i;
 
 	ep->descs = dma_alloc_coherent(dev, sizeof(struct ep93xx_descs),
-				&ep->descs_dma_addr, GFP_KERNEL | GFP_DMA);
+				&ep->descs_dma_addr, GFP_KERNEL);
 	if (ep->descs == NULL)
 		return 1;
 
-- 
1.7.4.4

[PATCH v2 5/5] net: ep93xx_eth: fix DMA API violations

[Mika Westerberg]

Russell King said:
>
> So, to summarize what its doing:
>
> 1. It allocates buffers for rx and tx.
> 2. It maps them with dma_map_single().
>       This transfers ownership of the buffer to the DMA device.
> 3. In ep93xx_xmit,
> 3a. It copies the data into the buffer with skb_copy_and_csum_dev()
>       This violates the DMA buffer ownership rules - the CPU should
>       not be writing to this buffer while it is (in principle) owned
>       by the DMA device.
> 3b. It then calls dma_sync_single_for_cpu() for the buffer.
>       This transfers ownership of the buffer to the CPU, which surely
>       is the wrong direction.
> 4. In ep93xx_rx,
> 4a. It calls dma_sync_single_for_cpu() for the buffer.
>       This at least transfers the DMA buffer ownership to the CPU
>       before the CPU reads the buffer
> 4b. It then uses skb_copy_to_linear_data() to copy the data out.
>       At no point does it transfer ownership back to the DMA device.
> 5. When the driver is removed, it dma_unmap_single()'s the buffer.
>       This transfers ownership of the buffer to the CPU.
> 6. It frees the buffer.
>
> While it may work on ep93xx, it's not respecting the DMA API rules,
> and with DMA debugging enabled it will probably encounter quite a few
> warnings.

This patch fixes these violations.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/net/arm/ep93xx_eth.c |   19 +++++++++++++------
 1 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 56b51a1..c2a7847 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -285,11 +285,14 @@ static int ep93xx_rx(struct net_device *dev, int processed, int budget)
 
 		skb = dev_alloc_skb(length + 2);
 		if (likely(skb != NULL)) {
+			struct ep93xx_rdesc *rxd = &ep->descs->rdesc[entry];
 			skb_reserve(skb, 2);
-			dma_sync_single_for_cpu(ep->dma_dev,
-						ep->descs->rdesc[entry].buf_addr,
+
+			dma_sync_single_for_cpu(ep->dma_dev, rxd->buf_addr,
 						length, DMA_FROM_DEVICE);
 			skb_copy_to_linear_data(skb, ep->rx_buf[entry], length);
+			dma_sync_single_for_device(ep->dma_dev, rxd->buf_addr,
+						length, DMA_FROM_DEVICE);
 			skb_put(skb, length);
 			skb->protocol = eth_type_trans(skb, dev);
 
@@ -351,6 +354,7 @@ poll_some_more:
 static int ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct ep93xx_priv *ep = netdev_priv(dev);
+	struct ep93xx_tdesc *txd;
 	int entry;
 
 	if (unlikely(skb->len > MAX_PKT_SIZE)) {
@@ -362,11 +366,14 @@ static int ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
 	entry = ep->tx_pointer;
 	ep->tx_pointer = (ep->tx_pointer + 1) & (TX_QUEUE_ENTRIES - 1);
 
-	ep->descs->tdesc[entry].tdesc1 =
-		TDESC1_EOF | (entry << 16) | (skb->len & 0xfff);
+	txd = &ep->descs->tdesc[entry];
+
+	txd->tdesc1 = TDESC1_EOF | (entry << 16) | (skb->len & 0xfff);
+	dma_sync_single_for_cpu(ep->dma_dev, txd->buf_addr, skb->len,
+				DMA_TO_DEVICE);
 	skb_copy_and_csum_dev(skb, ep->tx_buf[entry]);
-	dma_sync_single_for_cpu(ep->dma_dev, ep->descs->tdesc[entry].buf_addr,
-				skb->len, DMA_TO_DEVICE);
+	dma_sync_single_for_device(ep->dma_dev, txd->buf_addr, skb->len,
+				   DMA_TO_DEVICE);
 	dev_kfree_skb(skb);
 
 	spin_lock_irq(&ep->tx_pending_lock);
-- 
1.7.4.4

[PATCH v2 5/5] net: ep93xx_eth: fix DMA API violations

[Mika Westerberg]

Russell King said:
>
> So, to summarize what its doing:
>
> 1. It allocates buffers for rx and tx.
> 2. It maps them with dma_map_single().
>       This transfers ownership of the buffer to the DMA device.
> 3. In ep93xx_xmit,
> 3a. It copies the data into the buffer with skb_copy_and_csum_dev()
>       This violates the DMA buffer ownership rules - the CPU should
>       not be writing to this buffer while it is (in principle) owned
>       by the DMA device.
> 3b. It then calls dma_sync_single_for_cpu() for the buffer.
>       This transfers ownership of the buffer to the CPU, which surely
>       is the wrong direction.
> 4. In ep93xx_rx,
> 4a. It calls dma_sync_single_for_cpu() for the buffer.
>       This at least transfers the DMA buffer ownership to the CPU
>       before the CPU reads the buffer
> 4b. It then uses skb_copy_to_linear_data() to copy the data out.
>       At no point does it transfer ownership back to the DMA device.
> 5. When the driver is removed, it dma_unmap_single()'s the buffer.
>       This transfers ownership of the buffer to the CPU.
> 6. It frees the buffer.
>
> While it may work on ep93xx, it's not respecting the DMA API rules,
> and with DMA debugging enabled it will probably encounter quite a few
> warnings.

This patch fixes these violations.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/net/arm/ep93xx_eth.c |   19 +++++++++++++------
 1 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
index 56b51a1..c2a7847 100644
--- a/drivers/net/arm/ep93xx_eth.c
+++ b/drivers/net/arm/ep93xx_eth.c
@@ -285,11 +285,14 @@ static int ep93xx_rx(struct net_device *dev, int processed, int budget)
 
 		skb = dev_alloc_skb(length + 2);
 		if (likely(skb != NULL)) {
+			struct ep93xx_rdesc *rxd = &ep->descs->rdesc[entry];
 			skb_reserve(skb, 2);
-			dma_sync_single_for_cpu(ep->dma_dev,
-						ep->descs->rdesc[entry].buf_addr,
+
+			dma_sync_single_for_cpu(ep->dma_dev, rxd->buf_addr,
 						length, DMA_FROM_DEVICE);
 			skb_copy_to_linear_data(skb, ep->rx_buf[entry], length);
+			dma_sync_single_for_device(ep->dma_dev, rxd->buf_addr,
+						length, DMA_FROM_DEVICE);
 			skb_put(skb, length);
 			skb->protocol = eth_type_trans(skb, dev);
 
@@ -351,6 +354,7 @@ poll_some_more:
 static int ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
 {
 	struct ep93xx_priv *ep = netdev_priv(dev);
+	struct ep93xx_tdesc *txd;
 	int entry;
 
 	if (unlikely(skb->len > MAX_PKT_SIZE)) {
@@ -362,11 +366,14 @@ static int ep93xx_xmit(struct sk_buff *skb, struct net_device *dev)
 	entry = ep->tx_pointer;
 	ep->tx_pointer = (ep->tx_pointer + 1) & (TX_QUEUE_ENTRIES - 1);
 
-	ep->descs->tdesc[entry].tdesc1 =
-		TDESC1_EOF | (entry << 16) | (skb->len & 0xfff);
+	txd = &ep->descs->tdesc[entry];
+
+	txd->tdesc1 = TDESC1_EOF | (entry << 16) | (skb->len & 0xfff);
+	dma_sync_single_for_cpu(ep->dma_dev, txd->buf_addr, skb->len,
+				DMA_TO_DEVICE);
 	skb_copy_and_csum_dev(skb, ep->tx_buf[entry]);
-	dma_sync_single_for_cpu(ep->dma_dev, ep->descs->tdesc[entry].buf_addr,
-				skb->len, DMA_TO_DEVICE);
+	dma_sync_single_for_device(ep->dma_dev, txd->buf_addr, skb->len,
+				   DMA_TO_DEVICE);
 	dev_kfree_skb(skb);
 
 	spin_lock_irq(&ep->tx_pending_lock);
-- 
1.7.4.4

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Petr Štetiar]

Mika Westerberg <mika.westerberg@iki.fi> [2011-06-02 21:59:34]:

> As the driver is now passing platform device to the DMA mapping functions,
> we should give it valid DMA masks.

Hi Mika,

do you have the series available somewhere for pull? I would like to test the
changes for you on my ts7250/ts7300, but I'm quite lazy and would like to just
cherry-pick the changes if possible :-)

I also wonder, why this patch[1] from Herbert Valerio Riedel has never made it
upstream, this email[2] is the last trace of the patch I could find. Looks
like Herbert did few fixes to the driver and thanks to Matthieu, I'm using
this forward ported patch[3] since today, without any problems.

Do you personaly use the ethernet on the ep93xx/ts72xx heavily?

1. http://ynezz.ibawizard.net/ts72xx/linux-kernel/2.6.24.y/ep93xx-eth-phylib-framework.patch
2. http://www.mail-archive.com/netdev@vger.kernel.org/msg62550.html
3. https://github.com/ynezz/linux-2.6/commit/1dcf7aeb7ca4d7e441be2467926b606b46060a44

-- ynezz

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Petr Štetiar]

Mika Westerberg <mika.westerberg@iki.fi> [2011-06-02 21:59:34]:

> As the driver is now passing platform device to the DMA mapping functions,
> we should give it valid DMA masks.

Hi Mika,

do you have the series available somewhere for pull? I would like to test the
changes for you on my ts7250/ts7300, but I'm quite lazy and would like to just
cherry-pick the changes if possible :-)

I also wonder, why this patch[1] from Herbert Valerio Riedel has never made it
upstream, this email[2] is the last trace of the patch I could find. Looks
like Herbert did few fixes to the driver and thanks to Matthieu, I'm using
this forward ported patch[3] since today, without any problems.

Do you personaly use the ethernet on the ep93xx/ts72xx heavily?

1. http://ynezz.ibawizard.net/ts72xx/linux-kernel/2.6.24.y/ep93xx-eth-phylib-framework.patch
2. http://www.mail-archive.com/netdev at vger.kernel.org/msg62550.html
3. https://github.com/ynezz/linux-2.6/commit/1dcf7aeb7ca4d7e441be2467926b606b46060a44

-- ynezz

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

On Sun, Jun 05, 2011 at 10:34:45AM +0200, Petr Štetiar wrote:
> 
> do you have the series available somewhere for pull? I would like to test the
> changes for you on my ts7250/ts7300, but I'm quite lazy and would like to just
> cherry-pick the changes if possible :-)

Unfortunately - no. But what's wrong with 'git am <mbox>'? ;-)

> I also wonder, why this patch[1] from Herbert Valerio Riedel has never made it
> upstream, this email[2] is the last trace of the patch I could find. Looks
> like Herbert did few fixes to the driver and thanks to Matthieu, I'm using
> this forward ported patch[3] since today, without any problems.

I have no idea.

It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
he knows this better.

> Do you personaly use the ethernet on the ep93xx/ts72xx heavily?

Yes, I have NFS roots for the boards so it is essential for me.

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

On Sun, Jun 05, 2011 at 10:34:45AM +0200, Petr ?tetiar wrote:
> 
> do you have the series available somewhere for pull? I would like to test the
> changes for you on my ts7250/ts7300, but I'm quite lazy and would like to just
> cherry-pick the changes if possible :-)

Unfortunately - no. But what's wrong with 'git am <mbox>'? ;-)

> I also wonder, why this patch[1] from Herbert Valerio Riedel has never made it
> upstream, this email[2] is the last trace of the patch I could find. Looks
> like Herbert did few fixes to the driver and thanks to Matthieu, I'm using
> this forward ported patch[3] since today, without any problems.

I have no idea.

It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
he knows this better.

> Do you personaly use the ethernet on the ep93xx/ts72xx heavily?

Yes, I have NFS roots for the boards so it is essential for me.

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Petr Štetiar]

Mika Westerberg <mika.westerberg@iki.fi> [2011-06-05 11:59:48]:

> Unfortunately - no. But what's wrong with 'git am <mbox>'? ;-)

Nothing, it's just complicated if you don't read emails on the same machine as
you develop on. Just found patchwork thread, so it's solved[1]. Thanks.

1. https://patchwork.kernel.org/project/linux-arm-kernel/list/

-- ynezz

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Petr Štetiar]

Mika Westerberg <mika.westerberg@iki.fi> [2011-06-05 11:59:48]:

> Unfortunately - no. But what's wrong with 'git am <mbox>'? ;-)

Nothing, it's just complicated if you don't read emails on the same machine as
you develop on. Just found patchwork thread, so it's solved[1]. Thanks.

1. https://patchwork.kernel.org/project/linux-arm-kernel/list/

-- ynezz

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[David Miller]

From: Mika Westerberg <mika.westerberg@iki.fi>
Date: Sun, 5 Jun 2011 11:59:48 +0300

> It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
> he knows this better.

Someone needs to step up and take over as the real maintainer of this
driver.  The way the driver is currently being hacked on is
unsustainable.

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[David Miller]

From: Mika Westerberg <mika.westerberg@iki.fi>
Date: Sun, 5 Jun 2011 11:59:48 +0300

> It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
> he knows this better.

Someone needs to step up and take over as the real maintainer of this
driver.  The way the driver is currently being hacked on is
unsustainable.

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
> From: Mika Westerberg <mika.westerberg@iki.fi>
> Date: Sun, 5 Jun 2011 11:59:48 +0300
> 
> > It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
> > he knows this better.
> 
> Someone needs to step up and take over as the real maintainer of this
> driver.  The way the driver is currently being hacked on is
> unsustainable.

Can't agree more.

Hartley, Ryan: do you have any preferences? Are you guys already overwhelmed
with your current maintenance work, or could you consider taking this one as
well? 

If no one else steps up, I can volunteer but I have to admit that I don't know
much about that driver.

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
> From: Mika Westerberg <mika.westerberg@iki.fi>
> Date: Sun, 5 Jun 2011 11:59:48 +0300
> 
> > It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
> > he knows this better.
> 
> Someone needs to step up and take over as the real maintainer of this
> driver.  The way the driver is currently being hacked on is
> unsustainable.

Can't agree more.

Hartley, Ryan: do you have any preferences? Are you guys already overwhelmed
with your current maintenance work, or could you consider taking this one as
well? 

If no one else steps up, I can volunteer but I have to admit that I don't know
much about that driver.

RE: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[H Hartley Sweeten]

On Monday, June 06, 2011 10:26 AM, Mika Westerberg wrote:
> On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
>> From: Mika Westerberg <mika.westerberg@iki.fi>
>> Date: Sun, 5 Jun 2011 11:59:48 +0300
>> 
>>> It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
>>> he knows this better.
>> 
>> Someone needs to step up and take over as the real maintainer of this
>> driver.  The way the driver is currently being hacked on is
>> unsustainable.
>
> Can't agree more.
>
> Hartley, Ryan: do you have any preferences? Are you guys already overwhelmed
> with your current maintenance work, or could you consider taking this one as
> well? 
>
> If no one else steps up, I can volunteer but I have to admit that I don't know
> much about that driver.

I feel the same way.

If Lennert is no longer maintaining the this driver we really need someone to
step up and handle it.

I have no problem doing it but I really don't have a good grasp on the driver
or the whole network subsystem.

If Lennert is willing to hand it over, I have no problem being listed as a
co-maintainer along with either yourself of Ryan.  Between the two (or three)
of us we should be able to handle it.


Lennert,

You are listed as the maintainer for these EP93xx related pieces:

ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT
CIRRUS LOGIC EP93XX ETHERNET DRIVER
CIRRUS LOGIC EP93XX OHCI USB HOST DRIVER

I can take over the edb9315a with no problem.  It actually falls under
arch/arm/mach-ep93xx, so the entry could just be removed from MAINTAINERS.

For the OHCI driver, I'm in the same boat as the Ethernet.  If you are no longer
maintaining this driver I'm willing to handle it but would like someone to step
up as a co-maintainer.  Hopefully someone that has some grasp of that subsystem.

Your also listed in the source as the maintainer of these ep93xx boards:

ADSSPHERE	adssphere.c
EDB9302A	edb93xx.c
EDB9315	edb93xx.c
EDB9315A	edb93xx.c
GESBC9312	gesbc9312.c
TS72XX	ts72xx.c

I'm willing to handle those also since they are under arch/arm/mach-ep93xx.

Regards,
Hartley

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[H Hartley Sweeten]

On Monday, June 06, 2011 10:26 AM, Mika Westerberg wrote:
> On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
>> From: Mika Westerberg <mika.westerberg@iki.fi>
>> Date: Sun, 5 Jun 2011 11:59:48 +0300
>> 
>>> It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
>>> he knows this better.
>> 
>> Someone needs to step up and take over as the real maintainer of this
>> driver.  The way the driver is currently being hacked on is
>> unsustainable.
>
> Can't agree more.
>
> Hartley, Ryan: do you have any preferences? Are you guys already overwhelmed
> with your current maintenance work, or could you consider taking this one as
> well? 
>
> If no one else steps up, I can volunteer but I have to admit that I don't know
> much about that driver.

I feel the same way.

If Lennert is no longer maintaining the this driver we really need someone to
step up and handle it.

I have no problem doing it but I really don't have a good grasp on the driver
or the whole network subsystem.

If Lennert is willing to hand it over, I have no problem being listed as a
co-maintainer along with either yourself of Ryan.  Between the two (or three)
of us we should be able to handle it.


Lennert,

You are listed as the maintainer for these EP93xx related pieces:

ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT
CIRRUS LOGIC EP93XX ETHERNET DRIVER
CIRRUS LOGIC EP93XX OHCI USB HOST DRIVER

I can take over the edb9315a with no problem.  It actually falls under
arch/arm/mach-ep93xx, so the entry could just be removed from MAINTAINERS.

For the OHCI driver, I'm in the same boat as the Ethernet.  If you are no longer
maintaining this driver I'm willing to handle it but would like someone to step
up as a co-maintainer.  Hopefully someone that has some grasp of that subsystem.

Your also listed in the source as the maintainer of these ep93xx boards:

ADSSPHERE	adssphere.c
EDB9302A	edb93xx.c
EDB9315	edb93xx.c
EDB9315A	edb93xx.c
GESBC9312	gesbc9312.c
TS72XX	ts72xx.c

I'm willing to handle those also since they are under arch/arm/mach-ep93xx.

Regards,
Hartley

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

(corrected Ryan's email address, added Florian Fainelli)

On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
> On Monday, June 06, 2011 10:26 AM, Mika Westerberg wrote:
> > On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
> >> From: Mika Westerberg <mika.westerberg@iki.fi>
> >> Date: Sun, 5 Jun 2011 11:59:48 +0300
> >> 
> >>> It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
> >>> he knows this better.
> >> 
> >> Someone needs to step up and take over as the real maintainer of this
> >> driver.  The way the driver is currently being hacked on is
> >> unsustainable.
> >
> > Can't agree more.
> >
> > Hartley, Ryan: do you have any preferences? Are you guys already overwhelmed
> > with your current maintenance work, or could you consider taking this one as
> > well? 
> >
> > If no one else steps up, I can volunteer but I have to admit that I don't know
> > much about that driver.
> 
> I feel the same way.
> 
> If Lennert is no longer maintaining the this driver we really need someone to
> step up and handle it.
> 
> I have no problem doing it but I really don't have a good grasp on the driver
> or the whole network subsystem.
> 
> If Lennert is willing to hand it over, I have no problem being listed as a
> co-maintainer along with either yourself of Ryan.  Between the two (or three)
> of us we should be able to handle it.

Hartley,

Can you take maintainership of this driver? Since you already maintain most of
the ep93xx core stuff I think that you are the right person for the job. If
you need any assistance I believe me and Ryan can help you out.

We have now few patches queued:
	- this series from me to fix the DMA API violations
	- phylib patches from Florian Fainelli

It would be great to get those in someday :-)

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

(corrected Ryan's email address, added Florian Fainelli)

On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
> On Monday, June 06, 2011 10:26 AM, Mika Westerberg wrote:
> > On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
> >> From: Mika Westerberg <mika.westerberg@iki.fi>
> >> Date: Sun, 5 Jun 2011 11:59:48 +0300
> >> 
> >>> It looks like David Miller (CC'd) has been taking care of ep93xx_eth.c maybe
> >>> he knows this better.
> >> 
> >> Someone needs to step up and take over as the real maintainer of this
> >> driver.  The way the driver is currently being hacked on is
> >> unsustainable.
> >
> > Can't agree more.
> >
> > Hartley, Ryan: do you have any preferences? Are you guys already overwhelmed
> > with your current maintenance work, or could you consider taking this one as
> > well? 
> >
> > If no one else steps up, I can volunteer but I have to admit that I don't know
> > much about that driver.
> 
> I feel the same way.
> 
> If Lennert is no longer maintaining the this driver we really need someone to
> step up and handle it.
> 
> I have no problem doing it but I really don't have a good grasp on the driver
> or the whole network subsystem.
> 
> If Lennert is willing to hand it over, I have no problem being listed as a
> co-maintainer along with either yourself of Ryan.  Between the two (or three)
> of us we should be able to handle it.

Hartley,

Can you take maintainership of this driver? Since you already maintain most of
the ep93xx core stuff I think that you are the right person for the job. If
you need any assistance I believe me and Ryan can help you out.

We have now few patches queued:
	- this series from me to fix the DMA API violations
	- phylib patches from Florian Fainelli

It would be great to get those in someday :-)

RE: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[H Hartley Sweeten]

On Thursday, June 09, 2011 12:51 PM, Mika Westerberg wrote:
> On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
>> If Lennert is no longer maintaining the this driver we really need someone to
>> step up and handle it.
>> 
>> I have no problem doing it but I really don't have a good grasp on the driver
>> or the whole network subsystem.
>> 
>> If Lennert is willing to hand it over, I have no problem being listed as a
>> co-maintainer along with either yourself of Ryan.  Between the two (or three)
>> of us we should be able to handle it.
>
> Hartley,
>
> Can you take maintainership of this driver? Since you already maintain most of
> the ep93xx core stuff I think that you are the right person for the job. If
> you need any assistance I believe me and Ryan can help you out.
>
> We have now few patches queued:
>	- this series from me to fix the DMA API violations
>	- phylib patches from Florian Fainelli
>
> It would be great to get those in someday :-)

Hmm.. Ok, fine ;-)

I just submitted a patch to lkml changing the maintainership to myself.

Patches will still need to be applied through someone's tree, probably
David Miller's, since I don't have my own.

I think your series and Florian's patches are still in my inbox.  I'll try
to look at them today and provide feedback.

Regards,
Hartley

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[H Hartley Sweeten]

On Thursday, June 09, 2011 12:51 PM, Mika Westerberg wrote:
> On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
>> If Lennert is no longer maintaining the this driver we really need someone to
>> step up and handle it.
>> 
>> I have no problem doing it but I really don't have a good grasp on the driver
>> or the whole network subsystem.
>> 
>> If Lennert is willing to hand it over, I have no problem being listed as a
>> co-maintainer along with either yourself of Ryan.  Between the two (or three)
>> of us we should be able to handle it.
>
> Hartley,
>
> Can you take maintainership of this driver? Since you already maintain most of
> the ep93xx core stuff I think that you are the right person for the job. If
> you need any assistance I believe me and Ryan can help you out.
>
> We have now few patches queued:
>	- this series from me to fix the DMA API violations
>	- phylib patches from Florian Fainelli
>
> It would be great to get those in someday :-)

Hmm.. Ok, fine ;-)

I just submitted a patch to lkml changing the maintainership to myself.

Patches will still need to be applied through someone's tree, probably
David Miller's, since I don't have my own.

I think your series and Florian's patches are still in my inbox.  I'll try
to look at them today and provide feedback.

Regards,
Hartley

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

On Thu, Jun 09, 2011 at 03:18:39PM -0500, H Hartley Sweeten wrote:
> On Thursday, June 09, 2011 12:51 PM, Mika Westerberg wrote:
> > On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
> >> If Lennert is no longer maintaining the this driver we really need someone to
> >> step up and handle it.
> >> 
> >> I have no problem doing it but I really don't have a good grasp on the driver
> >> or the whole network subsystem.
> >> 
> >> If Lennert is willing to hand it over, I have no problem being listed as a
> >> co-maintainer along with either yourself of Ryan.  Between the two (or three)
> >> of us we should be able to handle it.
> >
> > Hartley,
> >
> > Can you take maintainership of this driver? Since you already maintain most of
> > the ep93xx core stuff I think that you are the right person for the job. If
> > you need any assistance I believe me and Ryan can help you out.
> >
> > We have now few patches queued:
> >	- this series from me to fix the DMA API violations
> >	- phylib patches from Florian Fainelli
> >
> > It would be great to get those in someday :-)
> 
> Hmm.. Ok, fine ;-)
> 
> I just submitted a patch to lkml changing the maintainership to myself.
> 
> Patches will still need to be applied through someone's tree, probably
> David Miller's, since I don't have my own.
> 
> I think your series and Florian's patches are still in my inbox.  I'll try
> to look at them today and provide feedback.

Ok, thanks :-)

I was also going to test and review Florian's patches this week. I'll report
back when I'm done.

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

On Thu, Jun 09, 2011 at 03:18:39PM -0500, H Hartley Sweeten wrote:
> On Thursday, June 09, 2011 12:51 PM, Mika Westerberg wrote:
> > On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
> >> If Lennert is no longer maintaining the this driver we really need someone to
> >> step up and handle it.
> >> 
> >> I have no problem doing it but I really don't have a good grasp on the driver
> >> or the whole network subsystem.
> >> 
> >> If Lennert is willing to hand it over, I have no problem being listed as a
> >> co-maintainer along with either yourself of Ryan.  Between the two (or three)
> >> of us we should be able to handle it.
> >
> > Hartley,
> >
> > Can you take maintainership of this driver? Since you already maintain most of
> > the ep93xx core stuff I think that you are the right person for the job. If
> > you need any assistance I believe me and Ryan can help you out.
> >
> > We have now few patches queued:
> >	- this series from me to fix the DMA API violations
> >	- phylib patches from Florian Fainelli
> >
> > It would be great to get those in someday :-)
> 
> Hmm.. Ok, fine ;-)
> 
> I just submitted a patch to lkml changing the maintainership to myself.
> 
> Patches will still need to be applied through someone's tree, probably
> David Miller's, since I don't have my own.
> 
> I think your series and Florian's patches are still in my inbox.  I'll try
> to look at them today and provide feedback.

Ok, thanks :-)

I was also going to test and review Florian's patches this week. I'll report
back when I'm done.

RE: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> As the driver is now passing platform device to the DMA mapping functions,
> we should give it valid DMA masks.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

Since you made this patch the first in the series the commit message is not
quite right.  Other than that:

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> As the driver is now passing platform device to the DMA mapping functions,
> we should give it valid DMA masks.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

Since you made this patch the first in the series the commit message is not
quite right.  Other than that:

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

On Thu, Jun 09, 2011 at 03:27:11PM -0500, H Hartley Sweeten wrote:
> On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
> >
> > As the driver is now passing platform device to the DMA mapping functions,
> > we should give it valid DMA masks.
> >
> > Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> > Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Since you made this patch the first in the series the commit message is not
> quite right.  Other than that:
> 
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

Ah, right. I forgot to change the commit message. How about following?

From: Mika Westerberg <mika.westerberg@iki.fi>
Subject: [PATCH 1/5] ep93xx: set DMA masks for the ep93xx_eth

Since the driver uses the DMA API, we should pass it valid DMA masks.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
---
 arch/arm/mach-ep93xx/core.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 8207954..1d4b65f 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -402,11 +402,15 @@ static struct resource ep93xx_eth_resource[] = {
 	}
 };
 
+static u64 ep93xx_eth_dma_mask = DMA_BIT_MASK(32);
+
 static struct platform_device ep93xx_eth_device = {
 	.name		= "ep93xx-eth",
 	.id		= -1,
 	.dev		= {
-		.platform_data	= &ep93xx_eth_data,
+		.platform_data		= &ep93xx_eth_data,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.dma_mask		= &ep93xx_eth_dma_mask,
 	},
 	.num_resources	= ARRAY_SIZE(ep93xx_eth_resource),
 	.resource	= ep93xx_eth_resource,
-- 
1.7.4.4

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

On Thu, Jun 09, 2011 at 03:27:11PM -0500, H Hartley Sweeten wrote:
> On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
> >
> > As the driver is now passing platform device to the DMA mapping functions,
> > we should give it valid DMA masks.
> >
> > Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> > Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> 
> Since you made this patch the first in the series the commit message is not
> quite right.  Other than that:
> 
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

Ah, right. I forgot to change the commit message. How about following?

From: Mika Westerberg <mika.westerberg@iki.fi>
Subject: [PATCH 1/5] ep93xx: set DMA masks for the ep93xx_eth

Since the driver uses the DMA API, we should pass it valid DMA masks.

Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
---
 arch/arm/mach-ep93xx/core.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 8207954..1d4b65f 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -402,11 +402,15 @@ static struct resource ep93xx_eth_resource[] = {
 	}
 };
 
+static u64 ep93xx_eth_dma_mask = DMA_BIT_MASK(32);
+
 static struct platform_device ep93xx_eth_device = {
 	.name		= "ep93xx-eth",
 	.id		= -1,
 	.dev		= {
-		.platform_data	= &ep93xx_eth_data,
+		.platform_data		= &ep93xx_eth_data,
+		.coherent_dma_mask	= DMA_BIT_MASK(32),
+		.dma_mask		= &ep93xx_eth_dma_mask,
 	},
 	.num_resources	= ARRAY_SIZE(ep93xx_eth_resource),
 	.resource	= ep93xx_eth_resource,
-- 
1.7.4.4

RE: [PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> We shouldn't use NULL for any DMA API functions, unless we are dealing with
> ISA or EISA device. So pass correct struct dev pointer to these functions.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

Looks right to me..

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

[PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> We shouldn't use NULL for any DMA API functions, unless we are dealing with
> ISA or EISA device. So pass correct struct dev pointer to these functions.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

Looks right to me..

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

RE: [PATCH v2 3/5] net: ep93xx_eth: allocate buffers using kmalloc()

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> We can use simply kmalloc() to allocate the buffers. This also simplifies the
> code and allows us to perform DMA sync operations more easily.
>
> Memory is allocated with only GFP_KERNEL since there are no DMA allocation
> restrictions on this platform.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

Looks ok to me.

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

[PATCH v2 3/5] net: ep93xx_eth: allocate buffers using kmalloc()

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> We can use simply kmalloc() to allocate the buffers. This also simplifies the
> code and allows us to perform DMA sync operations more easily.
>
> Memory is allocated with only GFP_KERNEL since there are no DMA allocation
> restrictions on this platform.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

Looks ok to me.

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

RE: [PATCH v2 4/5] net: ep93xx_eth: drop GFP_DMA from call to dma_alloc_coherent()

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> Commit a197b59ae6e8 (mm: fail GFP_DMA allocations when ZONE_DMA is not
> configured) made page allocator to return NULL if GFP_DMA is set but
> CONFIG_ZONE_DMA is disabled.
>
> This causes ep93xx_eth to fail:
>
>  WARNING: at mm/page_alloc.c:2251 __alloc_pages_nodemask+0x11c/0x638()
>  Modules linked in:
>  [<c0035498>] (unwind_backtrace+0x0/0xf4) from [<c0043da4>] (warn_slowpath_common+0x48/0x60)
>  [<c0043da4>] (warn_slowpath_common+0x48/0x60) from [<c0043dd8>] (warn_slowpath_null+0x1c/0x24)
>  [<c0043dd8>] (warn_slowpath_null+0x1c/0x24) from [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638)
>  [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) from [<c00366fc>] (__dma_alloc+0x8c/0x3ec)
>  [<c00366fc>] (__dma_alloc+0x8c/0x3ec) from [<c0036adc>] (dma_alloc_coherent+0x54/0x60)
>  [<c0036adc>] (dma_alloc_coherent+0x54/0x60) from [<c0227808>] (ep93xx_open+0x20/0x864)
>  [<c0227808>] (ep93xx_open+0x20/0x864) from [<c0283144>] (__dev_open+0xb8/0x108)
>  [<c0283144>] (__dev_open+0xb8/0x108) from [<c0280528>] (__dev_change_flags+0x70/0x128)
>  [<c0280528>] (__dev_change_flags+0x70/0x128) from [<c0283054>] (dev_change_flags+0x10/0x48)
>  [<c0283054>] (dev_change_flags+0x10/0x48) from [<c001a720>] (ip_auto_config+0x190/0xf68)
>  [<c001a720>] (ip_auto_config+0x190/0xf68) from [<c00233b0>] (do_one_initcall+0x34/0x18c)
>  [<c00233b0>] (do_one_initcall+0x34/0x18c) from [<c0008400>] (kernel_init+0x94/0x134)
>  [<c0008400>] (kernel_init+0x94/0x134) from [<c0030858>] (kernel_thread_exit+0x0/0x8)
>
> Since there is no restrictions for DMA on ep93xx, we can fix this by just
> removing the GFP_DMA flag from the call.
> 
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

If this is a bug fix maybe it should be submitted as a separate patch.  Russell could
apply it now to fix the problem.

Regardless,

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

[PATCH v2 4/5] net: ep93xx_eth: drop GFP_DMA from call to dma_alloc_coherent()

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> Commit a197b59ae6e8 (mm: fail GFP_DMA allocations when ZONE_DMA is not
> configured) made page allocator to return NULL if GFP_DMA is set but
> CONFIG_ZONE_DMA is disabled.
>
> This causes ep93xx_eth to fail:
>
>  WARNING: at mm/page_alloc.c:2251 __alloc_pages_nodemask+0x11c/0x638()
>  Modules linked in:
>  [<c0035498>] (unwind_backtrace+0x0/0xf4) from [<c0043da4>] (warn_slowpath_common+0x48/0x60)
>  [<c0043da4>] (warn_slowpath_common+0x48/0x60) from [<c0043dd8>] (warn_slowpath_null+0x1c/0x24)
>  [<c0043dd8>] (warn_slowpath_null+0x1c/0x24) from [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638)
>  [<c0083b6c>] (__alloc_pages_nodemask+0x11c/0x638) from [<c00366fc>] (__dma_alloc+0x8c/0x3ec)
>  [<c00366fc>] (__dma_alloc+0x8c/0x3ec) from [<c0036adc>] (dma_alloc_coherent+0x54/0x60)
>  [<c0036adc>] (dma_alloc_coherent+0x54/0x60) from [<c0227808>] (ep93xx_open+0x20/0x864)
>  [<c0227808>] (ep93xx_open+0x20/0x864) from [<c0283144>] (__dev_open+0xb8/0x108)
>  [<c0283144>] (__dev_open+0xb8/0x108) from [<c0280528>] (__dev_change_flags+0x70/0x128)
>  [<c0280528>] (__dev_change_flags+0x70/0x128) from [<c0283054>] (dev_change_flags+0x10/0x48)
>  [<c0283054>] (dev_change_flags+0x10/0x48) from [<c001a720>] (ip_auto_config+0x190/0xf68)
>  [<c001a720>] (ip_auto_config+0x190/0xf68) from [<c00233b0>] (do_one_initcall+0x34/0x18c)
>  [<c00233b0>] (do_one_initcall+0x34/0x18c) from [<c0008400>] (kernel_init+0x94/0x134)
>  [<c0008400>] (kernel_init+0x94/0x134) from [<c0030858>] (kernel_thread_exit+0x0/0x8)
>
> Since there is no restrictions for DMA on ep93xx, we can fix this by just
> removing the GFP_DMA flag from the call.
> 
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

If this is a bug fix maybe it should be submitted as a separate patch.  Russell could
apply it now to fix the problem.

Regardless,

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

RE: [PATCH v2 5/5] net: ep93xx_eth: fix DMA API violations

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
> Russell King said:
>>
>> So, to summarize what its doing:
>>
>> 1. It allocates buffers for rx and tx.
>> 2. It maps them with dma_map_single().
>>       This transfers ownership of the buffer to the DMA device.
>> 3. In ep93xx_xmit,
>> 3a. It copies the data into the buffer with skb_copy_and_csum_dev()
>>       This violates the DMA buffer ownership rules - the CPU should
>>       not be writing to this buffer while it is (in principle) owned
>>       by the DMA device.
>> 3b. It then calls dma_sync_single_for_cpu() for the buffer.
>>       This transfers ownership of the buffer to the CPU, which surely
>>       is the wrong direction.
>> 4. In ep93xx_rx,
>> 4a. It calls dma_sync_single_for_cpu() for the buffer.
>>       This at least transfers the DMA buffer ownership to the CPU
>>       before the CPU reads the buffer
>> 4b. It then uses skb_copy_to_linear_data() to copy the data out.
>>       At no point does it transfer ownership back to the DMA device.
>> 5. When the driver is removed, it dma_unmap_single()'s the buffer.
>>       This transfers ownership of the buffer to the CPU.
>> 6. It frees the buffer.
>>
>> While it may work on ep93xx, it's not respecting the DMA API rules,
>> and with DMA debugging enabled it will probably encounter quite a few
>> warnings.
>
> This patch fixes these violations.
> 
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

Well... I'm not going to even pretend to actually understand the DMA API
at this point.  But, this patch seems to follow what DMA-API-HOWTO.txt
describes as the proper usage of the DMA API.

Also, with this patch and the others in your series my test systems are
still booting and working properly.

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

[PATCH v2 5/5] net: ep93xx_eth: fix DMA API violations

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
> Russell King said:
>>
>> So, to summarize what its doing:
>>
>> 1. It allocates buffers for rx and tx.
>> 2. It maps them with dma_map_single().
>>       This transfers ownership of the buffer to the DMA device.
>> 3. In ep93xx_xmit,
>> 3a. It copies the data into the buffer with skb_copy_and_csum_dev()
>>       This violates the DMA buffer ownership rules - the CPU should
>>       not be writing to this buffer while it is (in principle) owned
>>       by the DMA device.
>> 3b. It then calls dma_sync_single_for_cpu() for the buffer.
>>       This transfers ownership of the buffer to the CPU, which surely
>>       is the wrong direction.
>> 4. In ep93xx_rx,
>> 4a. It calls dma_sync_single_for_cpu() for the buffer.
>>       This at least transfers the DMA buffer ownership to the CPU
>>       before the CPU reads the buffer
>> 4b. It then uses skb_copy_to_linear_data() to copy the data out.
>>       At no point does it transfer ownership back to the DMA device.
>> 5. When the driver is removed, it dma_unmap_single()'s the buffer.
>>       This transfers ownership of the buffer to the CPU.
>> 6. It frees the buffer.
>>
>> While it may work on ep93xx, it's not respecting the DMA API rules,
>> and with DMA debugging enabled it will probably encounter quite a few
>> warnings.
>
> This patch fixes these violations.
> 
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>

Well... I'm not going to even pretend to actually understand the DMA API
at this point.  But, this patch seems to follow what DMA-API-HOWTO.txt
describes as the proper usage of the DMA API.

Also, with this patch and the others in your series my test systems are
still booting and working properly.

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

RE: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[H Hartley Sweeten]

On Thursday, June 09, 2011 1:41 PM, Mika Westerberg wrote:
> On Thu, Jun 09, 2011 at 03:27:11PM -0500, H Hartley Sweeten wrote:
>> On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>>>
>>> As the driver is now passing platform device to the DMA mapping functions,
>>> we should give it valid DMA masks.
>>>
>>> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
>>> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> 
>> Since you made this patch the first in the series the commit message is not
>> quite right.  Other than that:
>> 
>> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
>
> Ah, right. I forgot to change the commit message. How about following?
>
> From: Mika Westerberg <mika.westerberg@iki.fi>
> Subject: [PATCH 1/5] ep93xx: set DMA masks for the ep93xx_eth
>
> Since the driver uses the DMA API, we should pass it valid DMA masks.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

I like that better.

Thanks,
Hartley

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[H Hartley Sweeten]

On Thursday, June 09, 2011 1:41 PM, Mika Westerberg wrote:
> On Thu, Jun 09, 2011 at 03:27:11PM -0500, H Hartley Sweeten wrote:
>> On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>>>
>>> As the driver is now passing platform device to the DMA mapping functions,
>>> we should give it valid DMA masks.
>>>
>>> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
>>> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> 
>> Since you made this patch the first in the series the commit message is not
>> quite right.  Other than that:
>> 
>> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
>
> Ah, right. I forgot to change the commit message. How about following?
>
> From: Mika Westerberg <mika.westerberg@iki.fi>
> Subject: [PATCH 1/5] ep93xx: set DMA masks for the ep93xx_eth
>
> Since the driver uses the DMA API, we should pass it valid DMA masks.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

I like that better.

Thanks,
Hartley

RE: [PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> We shouldn't use NULL for any DMA API functions, unless we are dealing with
> ISA or EISA device. So pass correct struct dev pointer to these functions.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  drivers/net/arm/ep93xx_eth.c |   26 ++++++++++++++++----------
>  1 files changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
> index 5a77001..8779d3b 100644
> --- a/drivers/net/arm/ep93xx_eth.c
> +++ b/drivers/net/arm/ep93xx_eth.c
> @@ -159,6 +159,8 @@ struct ep93xx_priv
>  	void __iomem		*base_addr;
>  	int			irq;
>  
> +	struct device		*dma_dev;

Mika,

I just noticed this macro in include/linux/netdevice.h

/* Set the sysfs physical device reference for the network logical device
 * if set prior to registration will cause a symlink during initialization.
 */
#define SET_NETDEV_DEV(net, pdev)       ((net)->dev.parent = (pdev))

Is there anyway you could use that macro in the probe to save the platform_device
(with it's associated device) instead of introducing a new struct device * in the
private data?

Regards,
Hartley

[PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions

[H Hartley Sweeten]

On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
>
> We shouldn't use NULL for any DMA API functions, unless we are dealing with
> ISA or EISA device. So pass correct struct dev pointer to these functions.
>
> Signed-off-by: Mika Westerberg <mika.westerberg@iki.fi>
> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  drivers/net/arm/ep93xx_eth.c |   26 ++++++++++++++++----------
>  1 files changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c
> index 5a77001..8779d3b 100644
> --- a/drivers/net/arm/ep93xx_eth.c
> +++ b/drivers/net/arm/ep93xx_eth.c
> @@ -159,6 +159,8 @@ struct ep93xx_priv
>  	void __iomem		*base_addr;
>  	int			irq;
>  
> +	struct device		*dma_dev;

Mika,

I just noticed this macro in include/linux/netdevice.h

/* Set the sysfs physical device reference for the network logical device
 * if set prior to registration will cause a symlink during initialization.
 */
#define SET_NETDEV_DEV(net, pdev)       ((net)->dev.parent = (pdev))

Is there anyway you could use that macro in the probe to save the platform_device
(with it's associated device) instead of introducing a new struct device * in the
private data?

Regards,
Hartley

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Petr Štetiar]

Mika Westerberg <mika.westerberg@iki.fi> [2011-06-05 11:59:48]:

> On Sun, Jun 05, 2011 at 10:34:45AM +0200, Petr Štetiar wrote:
> > 
> > do you have the series available somewhere for pull? I would like to test the
> > changes for you on my ts7250/ts7300, but I'm quite lazy and would like to just
> > cherry-pick the changes if possible :-)
> 
> Unfortunately - no. But what's wrong with 'git am <mbox>'? ;-)

I've tested the whole series and didn't find any problems so far, thanks. You
can add my

	Tested-by: Petr Štetiar <ynezz@true.cz>

if you wish.

-- ynezz

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Petr Štetiar]

Mika Westerberg <mika.westerberg@iki.fi> [2011-06-05 11:59:48]:

> On Sun, Jun 05, 2011 at 10:34:45AM +0200, Petr ?tetiar wrote:
> > 
> > do you have the series available somewhere for pull? I would like to test the
> > changes for you on my ts7250/ts7300, but I'm quite lazy and would like to just
> > cherry-pick the changes if possible :-)
> 
> Unfortunately - no. But what's wrong with 'git am <mbox>'? ;-)

I've tested the whole series and didn't find any problems so far, thanks. You
can add my

	Tested-by: Petr ?tetiar <ynezz@true.cz>

if you wish.

-- ynezz

Re: [PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions

[Mika Westerberg]

On Thu, Jun 09, 2011 at 06:40:21PM -0500, H Hartley Sweeten wrote:
> 
> I just noticed this macro in include/linux/netdevice.h
> 
> /* Set the sysfs physical device reference for the network logical device
>  * if set prior to registration will cause a symlink during initialization.
>  */
> #define SET_NETDEV_DEV(net, pdev)       ((net)->dev.parent = (pdev))
> 
> Is there anyway you could use that macro in the probe to save the platform_device
> (with it's associated device) instead of introducing a new struct device * in the
> private data?

Nice finding, thanks.

I'll look into that and send new version of the whole series soon.

[PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions

[Mika Westerberg]

On Thu, Jun 09, 2011 at 06:40:21PM -0500, H Hartley Sweeten wrote:
> 
> I just noticed this macro in include/linux/netdevice.h
> 
> /* Set the sysfs physical device reference for the network logical device
>  * if set prior to registration will cause a symlink during initialization.
>  */
> #define SET_NETDEV_DEV(net, pdev)       ((net)->dev.parent = (pdev))
> 
> Is there anyway you could use that macro in the probe to save the platform_device
> (with it's associated device) instead of introducing a new struct device * in the
> private data?

Nice finding, thanks.

I'll look into that and send new version of the whole series soon.

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

On Fri, Jun 10, 2011 at 05:47:36PM +0200, Petr Štetiar wrote:
> 
> I've tested the whole series and didn't find any problems so far, thanks. You
> can add my
> 
> 	Tested-by: Petr Štetiar <ynezz@true.cz>
> 
> if you wish.

Cool. Thanks for testing :)

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Mika Westerberg]

On Fri, Jun 10, 2011 at 05:47:36PM +0200, Petr ?tetiar wrote:
> 
> I've tested the whole series and didn't find any problems so far, thanks. You
> can add my
> 
> 	Tested-by: Petr ?tetiar <ynezz@true.cz>
> 
> if you wish.

Cool. Thanks for testing :)

RE: [PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions

[H Hartley Sweeten]

On Friday, June 10, 2011 9:56 AM, Mika Westerberg wrote:
> On Thu, Jun 09, 2011 at 06:40:21PM -0500, H Hartley Sweeten wrote:
>> 
>> I just noticed this macro in include/linux/netdevice.h
>> 
>> /* Set the sysfs physical device reference for the network logical device
>>  * if set prior to registration will cause a symlink during initialization.
>>  */
>> #define SET_NETDEV_DEV(net, pdev)       ((net)->dev.parent = (pdev))
>> 
>> Is there anyway you could use that macro in the probe to save the platform_device
>> (with it's associated device) instead of introducing a new struct device * in the
>> private data?
>
> Nice finding, thanks.
>
> I'll look into that and send new version of the whole series soon.

It looks like after doing this in the probe:

	SET_NETDEV_DEV(dev, &pdev->dev);

You can then pass the required struct device pointer to the DMA API functions
like this:

static int ep93xx_rx(struct net_device *dev, int processed, int budget)
{
	...
	dma_sync_single_for_cpu(dev->dev.parent, ...

Regards,
Hartley

[PATCH v2 2/5] net: ep93xx_eth: pass struct device to DMA API functions

[H Hartley Sweeten]

On Friday, June 10, 2011 9:56 AM, Mika Westerberg wrote:
> On Thu, Jun 09, 2011 at 06:40:21PM -0500, H Hartley Sweeten wrote:
>> 
>> I just noticed this macro in include/linux/netdevice.h
>> 
>> /* Set the sysfs physical device reference for the network logical device
>>  * if set prior to registration will cause a symlink during initialization.
>>  */
>> #define SET_NETDEV_DEV(net, pdev)       ((net)->dev.parent = (pdev))
>> 
>> Is there anyway you could use that macro in the probe to save the platform_device
>> (with it's associated device) instead of introducing a new struct device * in the
>> private data?
>
> Nice finding, thanks.
>
> I'll look into that and send new version of the whole series soon.

It looks like after doing this in the probe:

	SET_NETDEV_DEV(dev, &pdev->dev);

You can then pass the required struct device pointer to the DMA API functions
like this:

static int ep93xx_rx(struct net_device *dev, int processed, int budget)
{
	...
	dma_sync_single_for_cpu(dev->dev.parent, ...

Regards,
Hartley

Re: [PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Lennert Buytenhek]

On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:

> Lennert,

Hi,


> You are listed as the maintainer for these EP93xx related pieces:
> 
> ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT
> CIRRUS LOGIC EP93XX ETHERNET DRIVER
> CIRRUS LOGIC EP93XX OHCI USB HOST DRIVER
> 
> I can take over the edb9315a with no problem.  It actually falls under
> arch/arm/mach-ep93xx, so the entry could just be removed from MAINTAINERS.

If you have the hardware, that's fine with me.


> For the OHCI driver, I'm in the same boat as the Ethernet.  If you are
> no longer maintaining this driver I'm willing to handle it but would
> like someone to step up as a co-maintainer.  Hopefully someone that
> has some grasp of that subsystem.

Same here.


> Your also listed in the source as the maintainer of these ep93xx boards:
> 
> ADSSPHERE	adssphere.c
> EDB9302A	edb93xx.c
> EDB9315	edb93xx.c
> EDB9315A	edb93xx.c
> GESBC9312	gesbc9312.c
> TS72XX	ts72xx.c
> 
> I'm willing to handle those also since they are under arch/arm/mach-ep93xx.

Do you have all these boards, though?


thanks,
Lennert

[PATCH v2 1/5] ep93xx: set DMA masks for the ep93xx_eth

[Lennert Buytenhek]

On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:

> Lennert,

Hi,


> You are listed as the maintainer for these EP93xx related pieces:
> 
> ARM/CIRRUS LOGIC EDB9315A MACHINE SUPPORT
> CIRRUS LOGIC EP93XX ETHERNET DRIVER
> CIRRUS LOGIC EP93XX OHCI USB HOST DRIVER
> 
> I can take over the edb9315a with no problem.  It actually falls under
> arch/arm/mach-ep93xx, so the entry could just be removed from MAINTAINERS.

If you have the hardware, that's fine with me.


> For the OHCI driver, I'm in the same boat as the Ethernet.  If you are
> no longer maintaining this driver I'm willing to handle it but would
> like someone to step up as a co-maintainer.  Hopefully someone that
> has some grasp of that subsystem.

Same here.


> Your also listed in the source as the maintainer of these ep93xx boards:
> 
> ADSSPHERE	adssphere.c
> EDB9302A	edb93xx.c
> EDB9315	edb93xx.c
> EDB9315A	edb93xx.c
> GESBC9312	gesbc9312.c
> TS72XX	ts72xx.c
> 
> I'm willing to handle those also since they are under arch/arm/mach-ep93xx.

Do you have all these boards, though?


thanks,
Lennert