gpio: zynq: initialize clock even without CONFIG_PM

When the PM initialization was moved in the commit referenced below, the code enabling the clock was removed from the probe function. On CONFIG_PM=y kernels, this is not a problem as the pm resume hook enables the clock, but when power management is disabled, all those pm_* functions are noops and the clock is never enabled resulting in a dysfunctional gpio controller.

Put the clock initialization back to support CONFIG_PM=n.

---
 drivers/gpio/gpio-zynq.c | 7 +++++++
 1 file changed, 7 insertions(+)

Changes in v2: Rebased on 4.7-rc1.

I already asked this question in my initial patch posting, because I am unsure. If you deem CONFIG_PM=n and gpio-zynq a common configuration, then the answer probably is "yes".

The patch that makes the rebase non-trivial, is 615d23f80efc ("gpio:
zynq: Fix the error path"). If you deem CONFIG_PM=y and gpio-zynq a common configuration, then this patch likely should also go to stable.

Both of them fix regressions in 3773c195d387 ("gpio: zynq: Do PM initialization earlier to support gpio hogs"), which was introduced in 4.4, so stable trees earlier than that don't need these patches.

Please note that this rebased patch is only compile tested, because some required drivers broke with 4.7-rc1. If you are reluctant to apply the patch under this condition, I can report back after fixing drivers. Posting the updated patch anyway in case the other Helmut wants to test it.

Helmut

index 75c6355..e72794e 100644
@@ -709,7 +709,13 @@ static int zynq_gpio_probe(struct platform_device *pdev)
 		dev_err(&pdev->dev, "input clock not found.\n");
 		return PTR_ERR(gpio->clk);
 	}
+	ret = clk_prepare_enable(gpio->clk);
+	if (ret) {
+		dev_err(&pdev->dev, "Unable to enable clock.\n");
+		return ret;
+	}
 
+	pm_runtime_set_active(&pdev->dev);
 	pm_runtime_enable(&pdev->dev);
 	ret = pm_runtime_get_sync(&pdev->dev);
 	if (ret < 0)

@@ -747,6 +753,7 @@ err_pm_put:
 	pm_runtime_put(&pdev->dev);
 err_pm_dis:
 	pm_runtime_disable(&pdev->dev);
+	clk_disable_unprepare(gpio->clk);
 
 	return ret;
 }

2.1.4

Excuse the quick followup. I gave up fixing the driver before the weekend but then it turned out to be much easier than expected.

I now tested the patch with 4.7-rc1 (plus some out of tree drivers) on our board both with CONFIG_PM=y and CONFIG_PM=n and confirm that it works as expected. With CONFIG_PM=n and plain 4.7-rc1, the gpio controller doesn't work at all.

Helmut

This v2 patch applied for fixes and tagged for stable.

Yours,
Linus Walleij