Re: [PATCH 2/2] gpio: omap: save two lines by using devm_clk_get_prepared()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16/12/2024 10:57, Sverdlin, Alexander wrote:
Hi Matti!

On Fri, 2024-12-13 at 15:55 +0200, Matti Vaittinen wrote:

From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>

We can drop the else branch if we get the clock already prepared using
the relevant helper.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx>
---

Booting a beaglebone black with the linux-next from Today fails
(next-20241213). Enabling earlycon + debug yields below splat to be
printed to the console:


No problem! Thanks for the logs! I think I know what happened: I suppose
it's "prepared" counter underflow on probe deferral of GPIO driver
(there are "probe of 44e07000.gpio returned 517" visible).

Ah. Indeed. The deferral is visible in the logs.


If you'd still have a chance to test 6.13.0-rc2-next-20241213,
I believe this was missing in the
"gpio: omap: save two lines by using devm_clk_get_prepared()":

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 76d5d87e9681..0c30013d2b48 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1473,8 +1473,6 @@ static int omap_gpio_probe(struct platform_device *pdev)
  	if (ret) {
  		pm_runtime_put_sync(dev);
  		pm_runtime_disable(dev);
-		if (bank->dbck_flag)
-			clk_unprepare(bank->dbck);
  		return ret;
  	}
@@ -1495,8 +1493,6 @@ static void omap_gpio_remove(struct platform_device *pdev)
  	cpu_pm_unregister_notifier(&bank->nb);
  	gpiochip_remove(&bank->chip);
  	pm_runtime_disable(&pdev->dev);
-	if (bank->dbck_flag)
-		clk_unprepare(bank->dbck);
  }
static int __maybe_unused omap_gpio_runtime_suspend(struct device *dev)


This fixes the boot as you assumed.
I suppose this should be baked in the Bartosz's original patch assumed it was dropped from the GPIO tree.

Furthermore, this seems to be a fix to a hidden problem on original code. If the original code failed in the clk_prepare() and then deferred probe(), this same problem should have appeared, right?

Maybe consider using Fixes - tag even if this and the original change got squashed. Feel free to add a:

Tested-By: Matti Vaittinen <mazziesaccount@xxxxxxxxx>

if this fix goes to the tree "as is".

Thanks for the fix!

Yours,
	-- Matti.




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux