Reserved block logic relies only on information from device tree,
there is no need to get and enable device clock in advance, especially
because unprovided clock is not considered as an error. No
functional change, but minus one label.

Signed-off-by: Vladimir Zapolskiy <[email protected]>
---
 drivers/misc/sram.c |   20 ++++++++------------
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 1ad979f..935b3fa 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -100,22 +100,14 @@ static int sram_probe(struct platform_device *pdev)
        if (!sram->pool)
                return -ENOMEM;
 
-       sram->clk = devm_clk_get(sram->dev, NULL);
-       if (IS_ERR(sram->clk))
-               sram->clk = NULL;
-       else
-               clk_prepare_enable(sram->clk);
-
        /*
         * We need an additional block to mark the end of the memory region
         * after the reserved blocks from the dt are processed.
         */
        nblocks = (np) ? of_get_available_child_count(np) + 1 : 1;
        rblocks = kmalloc((nblocks) * sizeof(*rblocks), GFP_KERNEL);
-       if (!rblocks) {
+       if (!rblocks)
                ret = -ENOMEM;
-               goto err_alloc;
-       }
 
        block = &rblocks[0];
        for_each_available_child_of_node(np, child) {
@@ -198,6 +190,12 @@ static int sram_probe(struct platform_device *pdev)
 
        kfree(rblocks);
 
+       sram->clk = devm_clk_get(sram->dev, NULL);
+       if (IS_ERR(sram->clk))
+               sram->clk = NULL;
+       else
+               clk_prepare_enable(sram->clk);
+
        platform_set_drvdata(pdev, sram);
 
        dev_dbg(&pdev->dev, "SRAM pool: %zu KiB @ 0x%p\n",
@@ -207,9 +205,7 @@ static int sram_probe(struct platform_device *pdev)
 
 err_chunks:
        kfree(rblocks);
-err_alloc:
-       if (sram->clk)
-               clk_disable_unprepare(sram->clk);
+
        return ret;
 }
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to