[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aYFkBrMthr0RfkhA@shlinux89>
Date: Tue, 3 Feb 2026 10:57:10 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Stephen Boyd <sboyd@...nel.org>
Cc: Michael Turquette <mturquette@...libre.com>,
linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
patches@...ts.linux.dev,
Alexander Stein <alexander.stein@...tq-group.com>,
Mark Brown <broonie@...nel.org>,
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>,
Brian Masney <bmasney@...hat.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Chen-Yu Tsai <wenst@...omium.org>
Subject: Re: [PATCH] Revert "clk: Respect CLK_OPS_PARENT_ENABLE during recalc"
On Mon, Feb 02, 2026 at 04:24:38PM -0800, Stephen Boyd wrote:
>This reverts commit 669917676e93fca5ea3c66fc9539830312bec58e.
>It's been shown to cause problems on i.MX and STM32 platforms
>where the board doesn't boot. In one case, a clk with
>CLK_IS_CRITICAL and CLK_OPS_PARENT_ENABLE is being registered
>causing the parent to be enabled, the rate recalculated, and then
>the parent is disabled causing the critical clk being registered
>to stop clocking.
>
>A fix for that would be to calculate the rate of the clk after
>enabling the critical clk itself, but that wouldn't fix another
>problem where a clk with CLK_OPS_PARENT_ENABLE is registered
>before the parent is registered. In this case the hardware access
>in the clk_ops::recalc_rate() function would fail if the parent
>is disabled.
>
>There are even more problems exposed by this patch because it
>introduces logic that disables clks earlier in system boot than
>has existed previously. Historically we've not disabled clks
>until late init (clk_disable_unused) under the assumption that
>clks have been registered enough to have a consistent view of the
>clk tree. The clk_disable_unused logic doesn't work very well
>though, leading to quite a few devices booting with
>clk_ignore_unused on the kernel command line.
>
>Long story short, disabling clks during clk registration is full
>of pitfalls. Revert this commit until a proper solution can be
>found.
>
>Reported-by: Alexander Stein <alexander.stein@...tq-group.com>
>Closes: https://lore.kernel.org/r/6239343.lOV4Wx5bFT@steina-w
>Reported-by: Mark Brown <broonie@...nel.org>
>Closes: https://lore.kernel.org/r/036da7ce-6487-4a6e-9b15-97c6d3bcdcec@sirena.org.uk
>Cc: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
>Cc: Brian Masney <bmasney@...hat.com>
>Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>Cc: Chen-Yu Tsai <wenst@...omium.org>
>Signed-off-by: Stephen Boyd <sboyd@...nel.org>
Tested-by: Peng Fan <peng.fan@....com>
Powered by blists - more mailing lists