FAILED: patch "[PATCH] gpio: zynq: initialize clock even without CONFIG_PM" failed to apply to 4.6-stable tree
Subsystems (4)
[email protected]
maintainerThe patch below does not apply to the 4.6-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
Quoted 1 line
From
0f84f29ff30bdb1bca23017b118b4ea3999cac32Mon Sep 17 00:00:00 2001
From: Helmut Grohne <[email protected]>
Date: Fri, 3 Jun 2016 14:15:32 +0200
Subject: [PATCH] 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 -0
@@ -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; }
Hi greg,
Quoted 4 lines · On Sat, Jun 18, 2016 at 06:41:23PM +0200, [email protected] wrote:
The patch below does not apply to the 4.6-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
Thanks for considering the patch for stable. It seems though that my notes concerning stable have been lost in transmission.
The first observation is that the regression was introduced in 4.4, so no earlier stable trees are affected.
Then I had to rebase my patch, because it touches the same lines as 615d23f80efc ("gpio: zynq: Fix the error path"). My initial patch posting[1] did not consider that patch, so there you go with a rebased patch that applies to earlier kernel versions. I still use that patch successfully for bisecting.
I do note however, that the mentioned "Fix the error path" commit also looks like it should be included into a stable tree, because it fixes an unbalanced pm_runtime_enable. Thus I recommend applying it to stable as well. Then the patch that went into 4.7-rc3 just applies.
Helmut
[1] https://lkml.kernel.org/r/20160601110259.GA30501@laureti-dev
[email protected]
maintainerQuoted 20 lines · Helmut Grohne
Hi greg,
Quoted 4 lines · On Sat, Jun 18, 2016 at 06:41:23PM +0200, [email protected] wrote:
The patch below does not apply to the 4.6-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.Thanks for considering the patch for stable. It seems though that my notes concerning stable have been lost in transmission.
The first observation is that the regression was introduced in 4.4, so no earlier stable trees are affected.
Then I had to rebase my patch, because it touches the same lines as
615d23f80efc("gpio: zynq: Fix the error path"). My initial patch posting[1] did not consider that patch, so there you go with a rebased patch that applies to earlier kernel versions. I still use that patch successfully for bisecting.
Quoted 4 lines
I do note however, that the mentioned "Fix the error path" commit also looks like it should be included into a stable tree, because it fixes an unbalanced
pm_runtime_enable. Thus I recommend applying it to stable as well. Then the patch that went into 4.7-rc3 just applies.
Thanks, I think I have it worked out now.
greg k-h