[PATCH 3/3] remoteproc: free carveout memories only after unmapping them

[PATCH 3/3] remoteproc: free carveout memories only after unmapping them

[Suman Anna]

It is not preferable to have the allocated pages for carveout
memories freed before they are unmapped. The code that deals
with the cleanup of carveout memories is therefore moved after
the corresponding mapping entries were cleaned up.

This is mostly a no-op since the remote processors are already
stopped when the cleanup function is called, but this will make
the cleanup code follow the exact reverse path of allocation.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/remoteproc/remoteproc_core.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c b/drivers/remoteproc/remoteproc_core.c
index bc078c0..1ea7460 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -762,14 +762,6 @@ static void rproc_resource_cleanup(struct rproc *rproc)
 		kfree(entry);
 	}
 
-	/* clean up carveout allocations */
-	list_for_each_entry_safe(entry, tmp, &rproc->carveouts, node) {
-		dma_free_coherent(dev->parent, entry->len, entry->va,
-								entry->dma);
-		list_del(&entry->node);
-		kfree(entry);
-	}
-
 	/* clean up iommu mapping entries */
 	list_for_each_entry_safe(entry, tmp, &rproc->mappings, node) {
 		size_t unmapped;
@@ -784,6 +776,14 @@ static void rproc_resource_cleanup(struct rproc *rproc)
 		list_del(&entry->node);
 		kfree(entry);
 	}
+
+	/* clean up carveout allocations */
+	list_for_each_entry_safe(entry, tmp, &rproc->carveouts, node) {
+		dma_free_coherent(dev->parent, entry->len, entry->va,
+								entry->dma);
+		list_del(&entry->node);
+		kfree(entry);
+	}
 }
 
 /*
-- 
1.8.2

Re: [PATCH 3/3] remoteproc: free carveout memories only after unmapping them

[Ohad Ben-Cohen]

On Sat, Jun 1, 2013 at 12:16 AM, Suman Anna <s-anna@ti.com> wrote:
> It is not preferable to have the allocated pages for carveout
> memories freed before they are unmapped. The code that deals
> with the cleanup of carveout memories is therefore moved after
> the corresponding mapping entries were cleaned up.
>
> This is mostly a no-op since the remote processors are already
> stopped when the cleanup function is called, but this will make
> the cleanup code follow the exact reverse path of allocation.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>

Applied, thanks.