From: Mika Westerberg <hidden> Date: 2011-06-02 18:59:34
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 <redacted>
Acked-by: Russell King <redacted>
---
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(-)
From: Mika Westerberg <hidden> Date: 2011-06-02 18:59:35
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 <redacted>
Acked-by: Russell King <redacted>
---
drivers/net/arm/ep93xx_eth.c | 26 ++++++++++++++++----------
1 files changed, 16 insertions(+), 10 deletions(-)
@@ -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);
From: H Hartley Sweeten <hidden> Date: 2011-06-09 20:41:58
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 <redacted>
Acked-by: Russell King <redacted>
Looks right to me..
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
From: H Hartley Sweeten <hidden> Date: 2011-06-09 23:40:21
On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
quoted hunk
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 <redacted>
Acked-by: Russell King <redacted>
---
drivers/net/arm/ep93xx_eth.c | 26 ++++++++++++++++----------
1 files changed, 16 insertions(+), 10 deletions(-)
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
From: Mika Westerberg <hidden> Date: 2011-06-10 16:55:45
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.
From: H Hartley Sweeten <hidden> Date: 2011-06-10 17:30:48
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:
quoted
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
From: Mika Westerberg <hidden> Date: 2011-06-02 18:59:36
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 <redacted>
Acked-by: Russell King <redacted>
---
drivers/net/arm/ep93xx_eth.c | 51 ++++++++++++++++-------------------------
1 files changed, 20 insertions(+), 31 deletions(-)
From: H Hartley Sweeten <hidden> Date: 2011-06-09 20:53:01
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 <redacted>
Acked-by: Russell King <redacted>
Looks ok to me.
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
From: Mika Westerberg <hidden> Date: 2011-06-02 18:59:37
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 <redacted>
Acked-by: Russell King <redacted>
---
drivers/net/arm/ep93xx_eth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: H Hartley Sweeten <hidden> Date: 2011-06-09 20:59:54
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 <redacted>
Acked-by: Russell King <redacted>
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>
From: Mika Westerberg <hidden> Date: 2011-06-02 18:59:38
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 <redacted>
Acked-by: Russell King <redacted>
---
drivers/net/arm/ep93xx_eth.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
@@ -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)){+structep93xx_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);
From: H Hartley Sweeten <hidden> Date: 2011-06-09 21:25:02
On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
Russell King said:
quoted
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 <redacted>
Acked-by: Russell King <redacted>
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>
From: Mika Westerberg <hidden> Date: 2011-06-05 08: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 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.
From: Mika Westerberg <hidden> Date: 2011-06-06 17:26:07
On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
From: Mika Westerberg <redacted>
Date: Sun, 5 Jun 2011 11:59:48 +0300
quoted
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.
From: H Hartley Sweeten <hidden> Date: 2011-06-06 17:48:19
On Monday, June 06, 2011 10:26 AM, Mika Westerberg wrote:
On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
quoted
From: Mika Westerberg <redacted>
Date: Sun, 5 Jun 2011 11:59:48 +0300
quoted
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
From: Mika Westerberg <hidden> Date: 2011-06-09 19:50:52
(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:
quoted
On Sun, Jun 05, 2011 at 02:08:01PM -0700, David Miller wrote:
quoted
From: Mika Westerberg <redacted>
Date: Sun, 5 Jun 2011 11:59:48 +0300
quoted
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 :-)
From: H Hartley Sweeten <hidden> Date: 2011-06-09 20:18:39
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:
quoted
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
From: Mika Westerberg <hidden> Date: 2011-06-09 20:23:28
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:
quoted
On Mon, Jun 06, 2011 at 12:48:19PM -0500, H Hartley Sweeten wrote:
quoted
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.
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
From: Petr Štetiar <hidden> Date: 2011-06-10 15:47:36
Mika Westerberg [off-list ref] [2011-06-05 11:59:48]:
On Sun, Jun 05, 2011 at 10:34:45AM +0200, Petr Štetiar wrote:
quoted
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 [off-list ref]
if you wish.
-- ynezz
From: H Hartley Sweeten <hidden> Date: 2011-06-09 20:27:11
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 <redacted>
Acked-by: Russell King <redacted>
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>
From: Mika Westerberg <hidden> Date: 2011-06-09 20:41:13
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:
quoted
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 <redacted>
Acked-by: Russell King <redacted>
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 <redacted>
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 <redacted>
Acked-by: Russell King <redacted>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
---
arch/arm/mach-ep93xx/core.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
From: H Hartley Sweeten <hidden> Date: 2011-06-09 21:26:08
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:
quoted
On Thursday, June 02, 2011 12:00 PM, Mika Westerberg wrote:
quoted
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 <redacted>
Acked-by: Russell King <redacted>
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 <redacted>
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 <redacted>
Acked-by: Russell King <redacted>
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>