When CLK_OPS_PARENT_ENABLE was introduced, it guarded various clock
operations, such as setting the rate or switching parents. However,
another operation that can and often does touch actual hardware state is
recalc_rate, which may also be affected by such a dependency.

Add parent enables/disables where the recalc_rate op is called directly.

Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)")
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/clk/clk.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 85d2f2481acf360f0618a4a382fb51250e9c2fc4..1b0f9d567f48e003497afc98df0c0d2ad244eb90 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1921,7 +1921,14 @@ static unsigned long clk_recalc(struct clk_core *core,
 	unsigned long rate = parent_rate;
 
 	if (core->ops->recalc_rate && !clk_pm_runtime_get(core)) {
+		if (core->flags & CLK_OPS_PARENT_ENABLE)
+			clk_core_prepare_enable(core->parent);
+
 		rate = core->ops->recalc_rate(core->hw, parent_rate);
+
+		if (core->flags & CLK_OPS_PARENT_ENABLE)
+			clk_core_disable_unprepare(core->parent);
+
 		clk_pm_runtime_put(core);
 	}
 	return rate;
@@ -4031,6 +4038,9 @@ static int __clk_core_init(struct clk_core *core)
 	 */
 	clk_core_update_duty_cycle_nolock(core);
 
+	if (core->flags & CLK_OPS_PARENT_ENABLE)
+		clk_core_prepare_enable(core->parent);
+
 	/*
 	 * Set clk's rate.  The preferred method is to use .recalc_rate.  For
 	 * simple clocks and lazy developers the default fallback is to use the
@@ -4046,6 +4056,9 @@ static int __clk_core_init(struct clk_core *core)
 		rate = 0;
 	core->rate = core->req_rate = rate;
 
+	if (core->flags & CLK_OPS_PARENT_ENABLE)
+		clk_core_disable_unprepare(core->parent);
+
 	/*
 	 * Enable CLK_IS_CRITICAL clocks so newly added critical clocks
 	 * don't get accidentally disabled when walking the orphan tree and

-- 
2.51.0

On Fri, Oct 10, 2025 at 10:47:09PM +0200, Nicolas Frattaroli wrote:
> When CLK_OPS_PARENT_ENABLE was introduced, it guarded various clock
> operations, such as setting the rate or switching parents. However,
> another operation that can and often does touch actual hardware state is
> recalc_rate, which may also be affected by such a dependency.

I'm seeing boot regressions in -next on the Avenger96 which bisect to
this patch in -next.  The board resets during startup:

[    0.297034] /soc/display-controller@5a001000: Fixed dependency cycle(s) with /soc/bus@5c007000/i2c@5c002000/hdmi-transmitter@3d
[    0.307482] /soc/bus@5c007000/sai@4400b000/audio-controller@4400b004: Fixed dependency cycle(s) with /soc/bus@5c007000/i2c@5c002000/hdmi-transmitter@3d
[    0.321193] /soc/bus@5c007000/i2c@5c002000/hdmi-transmitter@3d: Fixed dependency cycle(s) with /soc/bus@5c007000/sai@4400b000/audio-controller@4400b004
[    0.334454] /soc/bus@5c007000/i2c@5c002000/hdmi-transmitter@3d: Fixed dependency cycle(s) with /soc/display-controller@5a001000
U-Boot SPL 2023.07.02-dh-stm32mp1-dhcor-avenger96-20230727.02 (Jul 11 2023 - 15:20:44 +0000)
Model: Arrow Electronics STM32MP15xx Avenger96 board

   https://lava.sirena.org.uk/scheduler/job/2409783

bisect log:

# bad: [615aad0f61e0c7a898184a394dc895c610100d4f] Add linux-next specific files for 20260126
# good: [50814c5ce8d8f6751fd49c818abeb8853f8be2df] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
# good: [702ce71d32f2c30b4f45b7c6b701d87583c58df8] ASoC: SDCA: Add NO_DIRECT_COMPLETE flag to class driver
# good: [d0ab89951197f0fc509a0cd732d830880e79c2d4] ASoC: cs35l56: Add KUnit testing of cs35l56_set_fw_suffix()
# good: [7f428282fde34f06f3ab898b8a9081bf93a41f22] ALSA: hda: controllers: intel: add support for Nova Lake
# good: [cafadbf430f4b2f3ca4158de48ef6ba4d97fbf17] ASoC: renesas: rz-ssi: Drop goto label
# good: [00ca2dd431fa2acb07b3ecc6ce49fb9a0a4d72cb] ASoC: SOF: Intel: hda: Remove MODULE_SOFTDEP for snd-hda-codec-hdmi
# good: [3495a5df94a9ad7a8940bcb3ebfda58255f5b952] spi: dt-bindings: nxp,imx94-xspi: add nxp,imx952-xspi
# good: [a18467a50eddbd7c6548b53b25b68e5454ceb587] ASoC: realtek: fix misspelling of "minimum" in comments
# good: [c3608162a95a259c669cf9fdccf900782fa8d902] spi: xilinx: make irq optional
# good: [3c5ddd56aa93048314c64533c21e731a44b0f067] ASoC: codecs: es8323: Enable proper DAPM widgets for chip power
# good: [20c4701b75a3d6ce09d61e17125aefe77e7eb333] dt-bindings: regulator: mark regulator-suspend-microvolt as deprecated
# good: [37fbc1ab0f225d23f0839260a11375b4f1f7cf8c] spi: Drop duplicate device_set_node() call
# good: [83ba6efa711fad83a0fbf02178ad64d3906d8d09] spi: rockchip: Use plain request_irq()
# good: [4fbd3b2ec04dc6ef93090ec24733a5c5671fb71f] ASoC: soc-acpi-intel-ptl-match: use aggregated endpoint in ptl_rt722_l0_rt1320_l23
# good: [7a3d1b04d938f31e112fe09c0ffc1af830ba1f6d] ASoC: SDCA: Handle CONFIG_PM_SLEEP not being set
# good: [dccc66b0e92d48d9a1908a3ccb8142e0ee3381f5] regmap: Enable REGMAP when REGMAP_SLIMBUS is enabled
# good: [61d2a7699ab39d448f44919ef15c16187e6f70ec] ASoC: SDCA: Tidy up some memory allocations
# good: [519d0a6b2ca5a891340b6c24a4c40545f518e1a8] ASoC: codecs: aw88261: use dvdd-supply regulator
# good: [da7afdc79cba00f952df12cd579e44832d829c0a] ASoC: SDCA: Add lock to serialise the Function initialisation
# good: [8a98e7f55f975360975083166e21982ef307b8fd] ASoC: tlv320adcx140: add channel sum control
# good: [10303b32519f52a5afd40593a507543143c8ec6a] dt-bindings: sound: google,goldfish-audio: Convert to DT schema
# good: [62b04225e99a5d1c71c5c73d2aa6618bc2c0738f] regulator: dt-bindings: rpi-panel: Mark 7" Raspberry Pi as GPIO controller
# good: [de9f1b1583aecb246b659effb03f2456604fab64] regulator: dt-bindings: mediatek,mt6331: Add missing ldo-vio28 vreg
# good: [a014c203b54d9013ad52ad8a531cf46e71028f2b] spi: fsi: Simplify with scoped for each OF child loop
# good: [e7c30ac379b429d439eb62ae1bb69720a6701e26] ASoC: amd: acp: soc-acpi: add is_device_rt712_vb() helper
# good: [09dc08b396c954820f119e1ab0c7d72333c18323] regulator: dummy, make dummy_regulator_driver static
# good: [6be9ea62afedef0f976eb3dba4c117be0c1d3809] ASoC: codecs: rtq9128: Add compatible changes for rtq9154
# good: [e590752119029d87ce46d725e11245a52d22e1fe] ASoC: wm8962: Don't report a microphone if it's shorted to ground on plug
# good: [77157cb45c66bd652a08a360693fcced558c5ef9] ASoC: codecs: rt1320-sdw: convert to snd_soc_dapm_xxx()
# good: [b0fc1e7701940d12ea2c41f386aa552bc4cc3629] regulator: Add TPS65185 driver
# good: [8618271887ca10ac5108fe7e1d82ba8f1b152cf9] spi: spi-mem: Limit octal DTR constraints to octal DTR situations
# good: [8672e4b51adfc57150f3862b1665faff0acf1bad] spi: dt-bindings: nxp,lpc3220-spi: Add DMA specific properties
# good: [fc6ceb7e4ea746e663ff8c5593e67ad8ccbee34a] ASoC: sof ipc4: Add sof_ipc4_widget_setup_msg_payload() and call it
# good: [83aee46dc2142eed2dc40b5cef0e9e08e14cac42] ASoC: SOF: ipc/ops: Use guard() for spinlocks
# good: [8d38423d9dea7353a8a54a3ab2e0d0aa04ed34d0] regulator: core: don't fail regulator_register() with missing required supply
# good: [b9198ce5c6dfee19b9662dda95ba559af9cdf53f] ASoC: codecs: aw88261: Add devicetree support
# good: [db4371d13f82fb12463fe053f4864980a2af2106] MAINTAINERS: Add entries for the Axiado SPI DB controller
# good: [b6376dbed8e173f9571583b5d358b08ff394e864] spi: Simplify devm_spi_*_controller()
# good: [0cd9bf6a6d9a1861087236cc5c275b3bea83cfdd] ASoC: codecs: da7213: Move comma operator at the end of the line
# good: [22a4776a9ce50aa47f602d28f53ba9d613a38f49] ASoC: codecs: es8375: remove unnecessary format check
# good: [75d208bddcca55ec31481420fbb4d6c9703ba195] spi: stm32: avoid __maybe_unused and use pm_ptr
# good: [04b61513dfe40f80f0dcc795003637b510522b3c] ASoC: SDCA: Replace use of system_wq with system_dfl_wq
# good: [9bf0bd7bdea6c402007ffb784dd0c0f704aa2310] ASoC: nau8821: Sort #include directives
# good: [96d337436fe0921177a6090aeb5bb214753654fc] spi: dt-bindings: at91: add microchip,lan9691-spi
# good: [52ddc0106c77ff0eacf07b309833ae6e6a4e8587] ASoC: es8328: Remove duplicate DAPM routes
# good: [211243b69533e968cc6f0259fb80ffee02fbe0ca] firmware: cs_dsp: test_bin: Add tests for offsets > 0xffff
# good: [420739112e95c9bb286b4e87875706925970abd3] ASoC: rt5575: Add the codec driver for the ALC5575
# good: [4c5e6d5b31bc623d89185d551681ab91cfd037c9] ASoC: codecs: ES8389: Update clock configuration
# good: [25abdc151a448a17d500ea9468ce32582c479faa] ASoC: rt1320: fix the remainder calculation of r0 value
# good: [284853affe73fe1ca9786bd52b934eb9d420a942] ASoC: rt1320: fix size_t format string
# good: [45e9066f3a487e9e26b842644364d045af054775] ASoC: Intel: avs: replace strcmp with sysfs_streq
# good: [0f698d742f628d02ab2a222f8cf5f793443865d0] spi: bcm63xx-hsspi: add support for 1-2-2 read ops
# good: [b0655377aa5a410df02d89170c20141a1a5bbc28] rust: regulator: replace `kernel::c_str!` with C-Strings
# good: [8db50f0fa43efe8799fd40b872dcdd39a90d7549] ASoC: rt1320: fix the warning the string may be truncated
# good: [99a3ef1e81cd1775bc1f8cc2ad188b1fc755d5cd] ASoC: SDCA: Add ASoC jack hookup in class driver
# good: [4ab48cc63e15cb619d641d1edf9a15a0a98875b2] ASoC: qcom: audioreach: Constify function arguments
# good: [c6bca73d699cfe00d3419566fdb2a45e112f44b0] ASoC: rt1320: Fix retry checking in rt1320_rae_load()
# good: [a2a631830deb382a3d27b6f52b2d654a3e6bb427] ASoC: qcom: Constify APR/GPR result structs
# good: [32a708ba5db50cf928a1f1b2039ceef33de2c286] regulator: Add rt8092 support
# good: [b39ef93a2e5b5f4289a3486d8a94a09a1e6a4c67] spi: stm32: perform small transfer in polling mode
# good: [7a8447fc71a09000cee5a2372b6efde45735d2c8] ASoC: codecs: wcd939x-sdw: use devres for regmap allocation
# good: [2a28b5240f2b328495c6565d277f438dbc583d61] ASoC: SOF: ipc4-control: Add support for generic bytes control
# good: [3622dc47a4b13e0ec86358c7b54a0b33bfcaa03c] ASoC: codec: rt286: Use devm_request_threaded_irq to manage IRQ lifetime and fix smatch warning
# good: [02e7af5b6423d2dbf82f852572f2fa8c00aafb19] ASoC: Intel: sof_rt5682: add tas2563 speaker amp support
# good: [29c8c00d9f9db5fb659b6f05f9e8964afc13f3e2] spi: add driver for NXP XSPI controller
# good: [9a6bc0a406608e2520f18d996483c9d2e4a9fb27] ASoC: codecs: ES8326: Add kcontrol for DRE
# good: [f764645cb85a8b8f58067289cdfed28f6c1cdf49] ASoC: codecs: tas2780: tidyup format check in tas2780_set_fmt()
# good: [7f7b350e4a65446f5d52ea8ae99e12eac8a972db] spi: stm32-qspi: Remove unneeded semicolon
# good: [1303c2903889b01d581083ed92e439e7544dd3e5] MAINTAINERS: Add MAINTAINERS entry for the ATCSPI200 SPI controller driver
# good: [524ee559948d8d079b13466e70fa741f909699c0] ASoC: SOF: Intel: hda: Only check SSP MCLK mask in case of IPC3
# good: [f25c7d709b93602ee9a08eba522808a18e1f5d56] ASoC: SOF: Intel: pci-nvl: Set on_demand_dsp_boot for NVL-S
# good: [f4acea9eef704607d1a950909ce3a52a770d6be2] spi: dt-bindings: st,stm32-spi: add 'power-domains' property
# good: [e39011184f23de3d04ca8e80b4df76c9047b4026] ASoC: SDCA: functions: Fix confusing cleanup.h syntax
# good: [fa08b566860bca8ebf9300090b85174c34de7ca5] spi: rzv2h-rspi: add support for DMA mode
# good: [03d281f384768610bf90697bce9e35d3d596de77] rust: regulator: add __rust_helper to helpers
# good: [b884e34994ca41f7b7819f3c41b78ff494787b27] spi: spi-fsl-lpspi: convert min_t() to simple min()
# good: [124f6155f3d97b0e33f178c10a5138a42c8fd207] ASoC: renesas: rz-ssi: Add support for 32 bits sample width
# good: [aa30193af8873b3ccfd70a4275336ab6cbd4e5e6] ASoC: Intel: catpt: Drop superfluous space in PCM code
# good: [0bb160c92ad400c692984763996b758458adea17] ASoC: qcom: Minor readability improve with new lines
# good: [fee876b2ec75dcc18fdea154eae1f5bf14d82659] spi: stm32-qspi: Simplify SMIE interrupt test
# good: [81acbdc51bbbec822a1525481f2f70677c47aee0] ASoC: sdw-mockup: Drop dummy remove function
# good: [9e92c559d49d6fb903af17a31a469aac51b1766d] regulator: max77675: Add MAX77675 regulator driver
# good: [ba9b28652c75b07383e267328f1759195d5430f7] spi: imx: enable DMA mode for target operation
# good: [6c177775dcc5e70a64ddf4ee842c66af498f2c7c] Merge branch 'next/drivers' into for-next
git bisect start '615aad0f61e0c7a898184a394dc895c610100d4f' '50814c5ce8d8f6751fd49c818abeb8853f8be2df' '702ce71d32f2c30b4f45b7c6b701d87583c58df8' 'd0ab89951197f0fc509a0cd732d830880e79c2d4' '7f428282fde34f06f3ab898b8a9081bf93a41f22' 'cafadbf430f4b2f3ca4158de48ef6ba4d97fbf17' '00ca2dd431fa2acb07b3ecc6ce49fb9a0a4d72cb' '3495a5df94a9ad7a8940bcb3ebfda58255f5b952' 'a18467a50eddbd7c6548b53b25b68e5454ceb587' 'c3608162a95a259c669cf9fdccf900782fa8d902' '3c5ddd56aa93048314c64533c21e731a44b0f067' '20c4701b75a3d6ce09d61e17125aefe77e7eb333' '37fbc1ab0f225d23f0839260a11375b4f1f7cf8c' '83ba6efa711fad83a0fbf02178ad64d3906d8d09' '4fbd3b2ec04dc6ef93090ec24733a5c5671fb71f' '7a3d1b04d938f31e112fe09c0ffc1af830ba1f6d' 'dccc66b0e92d48d9a1908a3ccb8142e0ee3381f5' '61d2a7699ab39d448f44919ef15c16187e6f70ec' '519d0a6b2ca5a891340b6c24a4c40545f518e1a8' 'da7afdc79cba00f952df12cd579e44832d829c0a' '8a98e7f55f975360975083166e21982ef307b8fd' '10303b32519f52a5afd40593a507543143c8ec6a' '62b04225e99a5d1c71c5c73d2aa6618bc2c0738f' 'de9f1b1583aecb246b659effb03f2456604fab64' 'a014c203b54d9013ad52ad8a531cf46e71028f2b' 'e7c30ac379b429d439eb62ae1bb69720a6701e26' '09dc08b396c954820f119e1ab0c7d72333c18323' '6be9ea62afedef0f976eb3dba4c117be0c1d3809' 'e590752119029d87ce46d725e11245a52d22e1fe' '77157cb45c66bd652a08a360693fcced558c5ef9' 'b0fc1e7701940d12ea2c41f386aa552bc4cc3629' '8618271887ca10ac5108fe7e1d82ba8f1b152cf9' '8672e4b51adfc57150f3862b1665faff0acf1bad' 'fc6ceb7e4ea746e663ff8c5593e67ad8ccbee34a' '83aee46dc2142eed2dc40b5cef0e9e08e14cac42' '8d38423d9dea7353a8a54a3ab2e0d0aa04ed34d0' 'b9198ce5c6dfee19b9662dda95ba559af9cdf53f' 'db4371d13f82fb12463fe053f4864980a2af2106' 'b6376dbed8e173f9571583b5d358b08ff394e864' '0cd9bf6a6d9a1861087236cc5c275b3bea83cfdd' '22a4776a9ce50aa47f602d28f53ba9d613a38f49' '75d208bddcca55ec31481420fbb4d6c9703ba195' '04b61513dfe40f80f0dcc795003637b510522b3c' '9bf0bd7bdea6c402007ffb784dd0c0f704aa2310' '96d337436fe0921177a6090aeb5bb214753654fc' '52ddc0106c77ff0eacf07b309833ae6e6a4e8587' '211243b69533e968cc6f0259fb80ffee02fbe0ca' '420739112e95c9bb286b4e87875706925970abd3' '4c5e6d5b31bc623d89185d551681ab91cfd037c9' '25abdc151a448a17d500ea9468ce32582c479faa' '284853affe73fe1ca9786bd52b934eb9d420a942' '45e9066f3a487e9e26b842644364d045af054775' '0f698d742f628d02ab2a222f8cf5f793443865d0' 'b0655377aa5a410df02d89170c20141a1a5bbc28' '8db50f0fa43efe8799fd40b872dcdd39a90d7549' '99a3ef1e81cd1775bc1f8cc2ad188b1fc755d5cd' '4ab48cc63e15cb619d641d1edf9a15a0a98875b2' 'c6bca73d699cfe00d3419566fdb2a45e112f44b0' 'a2a631830deb382a3d27b6f52b2d654a3e6bb427' '32a708ba5db50cf928a1f1b2039ceef33de2c286' 'b39ef93a2e5b5f4289a3486d8a94a09a1e6a4c67' '7a8447fc71a09000cee5a2372b6efde45735d2c8' '2a28b5240f2b328495c6565d277f438dbc583d61' '3622dc47a4b13e0ec86358c7b54a0b33bfcaa03c' '02e7af5b6423d2dbf82f852572f2fa8c00aafb19' '29c8c00d9f9db5fb659b6f05f9e8964afc13f3e2' '9a6bc0a406608e2520f18d996483c9d2e4a9fb27' 'f764645cb85a8b8f58067289cdfed28f6c1cdf49' '7f7b350e4a65446f5d52ea8ae99e12eac8a972db' '1303c2903889b01d581083ed92e439e7544dd3e5' '524ee559948d8d079b13466e70fa741f909699c0' 'f25c7d709b93602ee9a08eba522808a18e1f5d56' 'f4acea9eef704607d1a950909ce3a52a770d6be2' 'e39011184f23de3d04ca8e80b4df76c9047b4026' 'fa08b566860bca8ebf9300090b85174c34de7ca5' '03d281f384768610bf90697bce9e35d3d596de77' 'b884e34994ca41f7b7819f3c41b78ff494787b27' '124f6155f3d97b0e33f178c10a5138a42c8fd207' 'aa30193af8873b3ccfd70a4275336ab6cbd4e5e6' '0bb160c92ad400c692984763996b758458adea17' 'fee876b2ec75dcc18fdea154eae1f5bf14d82659' '81acbdc51bbbec822a1525481f2f70677c47aee0' '9e92c559d49d6fb903af17a31a469aac51b1766d' 'ba9b28652c75b07383e267328f1759195d5430f7' '6c177775dcc5e70a64ddf4ee842c66af498f2c7c'
# test job: [702ce71d32f2c30b4f45b7c6b701d87583c58df8] https://lava.sirena.org.uk/scheduler/job/2393428
# test job: [d0ab89951197f0fc509a0cd732d830880e79c2d4] https://lava.sirena.org.uk/scheduler/job/2392919
# test job: [7f428282fde34f06f3ab898b8a9081bf93a41f22] https://lava.sirena.org.uk/scheduler/job/2391339
# test job: [cafadbf430f4b2f3ca4158de48ef6ba4d97fbf17] https://lava.sirena.org.uk/scheduler/job/2389514
# test job: [00ca2dd431fa2acb07b3ecc6ce49fb9a0a4d72cb] https://lava.sirena.org.uk/scheduler/job/2389628
# test job: [3495a5df94a9ad7a8940bcb3ebfda58255f5b952] https://lava.sirena.org.uk/scheduler/job/2389353
# test job: [a18467a50eddbd7c6548b53b25b68e5454ceb587] https://lava.sirena.org.uk/scheduler/job/2386094
# test job: [c3608162a95a259c669cf9fdccf900782fa8d902] https://lava.sirena.org.uk/scheduler/job/2387959
# test job: [3c5ddd56aa93048314c64533c21e731a44b0f067] https://lava.sirena.org.uk/scheduler/job/2386640
# test job: [20c4701b75a3d6ce09d61e17125aefe77e7eb333] https://lava.sirena.org.uk/scheduler/job/2386301
# test job: [37fbc1ab0f225d23f0839260a11375b4f1f7cf8c] https://lava.sirena.org.uk/scheduler/job/2386363
# test job: [83ba6efa711fad83a0fbf02178ad64d3906d8d09] https://lava.sirena.org.uk/scheduler/job/2387001
# test job: [4fbd3b2ec04dc6ef93090ec24733a5c5671fb71f] https://lava.sirena.org.uk/scheduler/job/2386168
# test job: [7a3d1b04d938f31e112fe09c0ffc1af830ba1f6d] https://lava.sirena.org.uk/scheduler/job/2377308
# test job: [dccc66b0e92d48d9a1908a3ccb8142e0ee3381f5] https://lava.sirena.org.uk/scheduler/job/2377141
# test job: [61d2a7699ab39d448f44919ef15c16187e6f70ec] https://lava.sirena.org.uk/scheduler/job/2375730
# test job: [519d0a6b2ca5a891340b6c24a4c40545f518e1a8] https://lava.sirena.org.uk/scheduler/job/2372387
# test job: [da7afdc79cba00f952df12cd579e44832d829c0a] https://lava.sirena.org.uk/scheduler/job/2372298
# test job: [8a98e7f55f975360975083166e21982ef307b8fd] https://lava.sirena.org.uk/scheduler/job/2372505
# test job: [10303b32519f52a5afd40593a507543143c8ec6a] https://lava.sirena.org.uk/scheduler/job/2372322
# test job: [62b04225e99a5d1c71c5c73d2aa6618bc2c0738f] https://lava.sirena.org.uk/scheduler/job/2369376
# test job: [de9f1b1583aecb246b659effb03f2456604fab64] https://lava.sirena.org.uk/scheduler/job/2368867
# test job: [a014c203b54d9013ad52ad8a531cf46e71028f2b] https://lava.sirena.org.uk/scheduler/job/2368397
# test job: [e7c30ac379b429d439eb62ae1bb69720a6701e26] https://lava.sirena.org.uk/scheduler/job/2366032
# test job: [09dc08b396c954820f119e1ab0c7d72333c18323] https://lava.sirena.org.uk/scheduler/job/2365474
# test job: [6be9ea62afedef0f976eb3dba4c117be0c1d3809] https://lava.sirena.org.uk/scheduler/job/2365609
# test job: [e590752119029d87ce46d725e11245a52d22e1fe] https://lava.sirena.org.uk/scheduler/job/2364789
# test job: [77157cb45c66bd652a08a360693fcced558c5ef9] https://lava.sirena.org.uk/scheduler/job/2363794
# test job: [b0fc1e7701940d12ea2c41f386aa552bc4cc3629] https://lava.sirena.org.uk/scheduler/job/2364720
# test job: [8618271887ca10ac5108fe7e1d82ba8f1b152cf9] https://lava.sirena.org.uk/scheduler/job/2364881
# test job: [8672e4b51adfc57150f3862b1665faff0acf1bad] https://lava.sirena.org.uk/scheduler/job/2363802
# test job: [fc6ceb7e4ea746e663ff8c5593e67ad8ccbee34a] https://lava.sirena.org.uk/scheduler/job/2364433
# test job: [83aee46dc2142eed2dc40b5cef0e9e08e14cac42] https://lava.sirena.org.uk/scheduler/job/2363989
# test job: [8d38423d9dea7353a8a54a3ab2e0d0aa04ed34d0] https://lava.sirena.org.uk/scheduler/job/2354063
# test job: [b9198ce5c6dfee19b9662dda95ba559af9cdf53f] https://lava.sirena.org.uk/scheduler/job/2354856
# test job: [db4371d13f82fb12463fe053f4864980a2af2106] https://lava.sirena.org.uk/scheduler/job/2354230
# test job: [b6376dbed8e173f9571583b5d358b08ff394e864] https://lava.sirena.org.uk/scheduler/job/2349545
# test job: [0cd9bf6a6d9a1861087236cc5c275b3bea83cfdd] https://lava.sirena.org.uk/scheduler/job/2348802
# test job: [22a4776a9ce50aa47f602d28f53ba9d613a38f49] https://lava.sirena.org.uk/scheduler/job/2343130
# test job: [75d208bddcca55ec31481420fbb4d6c9703ba195] https://lava.sirena.org.uk/scheduler/job/2337394
# test job: [04b61513dfe40f80f0dcc795003637b510522b3c] https://lava.sirena.org.uk/scheduler/job/2337624
# test job: [9bf0bd7bdea6c402007ffb784dd0c0f704aa2310] https://lava.sirena.org.uk/scheduler/job/2330756
# test job: [96d337436fe0921177a6090aeb5bb214753654fc] https://lava.sirena.org.uk/scheduler/job/2330496
# test job: [52ddc0106c77ff0eacf07b309833ae6e6a4e8587] https://lava.sirena.org.uk/scheduler/job/2330490
# test job: [211243b69533e968cc6f0259fb80ffee02fbe0ca] https://lava.sirena.org.uk/scheduler/job/2330643
# test job: [420739112e95c9bb286b4e87875706925970abd3] https://lava.sirena.org.uk/scheduler/job/2330595
# test job: [4c5e6d5b31bc623d89185d551681ab91cfd037c9] https://lava.sirena.org.uk/scheduler/job/2330948
# test job: [25abdc151a448a17d500ea9468ce32582c479faa] https://lava.sirena.org.uk/scheduler/job/2307350
# test job: [284853affe73fe1ca9786bd52b934eb9d420a942] https://lava.sirena.org.uk/scheduler/job/2298066
# test job: [45e9066f3a487e9e26b842644364d045af054775] https://lava.sirena.org.uk/scheduler/job/2295621
# test job: [0f698d742f628d02ab2a222f8cf5f793443865d0] https://lava.sirena.org.uk/scheduler/job/2295231
# test job: [b0655377aa5a410df02d89170c20141a1a5bbc28] https://lava.sirena.org.uk/scheduler/job/2291689
# test job: [8db50f0fa43efe8799fd40b872dcdd39a90d7549] https://lava.sirena.org.uk/scheduler/job/2292502
# test job: [99a3ef1e81cd1775bc1f8cc2ad188b1fc755d5cd] https://lava.sirena.org.uk/scheduler/job/2290488
# test job: [4ab48cc63e15cb619d641d1edf9a15a0a98875b2] https://lava.sirena.org.uk/scheduler/job/2290397
# test job: [c6bca73d699cfe00d3419566fdb2a45e112f44b0] https://lava.sirena.org.uk/scheduler/job/2290128
# test job: [a2a631830deb382a3d27b6f52b2d654a3e6bb427] https://lava.sirena.org.uk/scheduler/job/2281785
# test job: [32a708ba5db50cf928a1f1b2039ceef33de2c286] https://lava.sirena.org.uk/scheduler/job/2279465
# test job: [b39ef93a2e5b5f4289a3486d8a94a09a1e6a4c67] https://lava.sirena.org.uk/scheduler/job/2269679
# test job: [7a8447fc71a09000cee5a2372b6efde45735d2c8] https://lava.sirena.org.uk/scheduler/job/2271774
# test job: [2a28b5240f2b328495c6565d277f438dbc583d61] https://lava.sirena.org.uk/scheduler/job/2266163
# test job: [3622dc47a4b13e0ec86358c7b54a0b33bfcaa03c] https://lava.sirena.org.uk/scheduler/job/2268465
# test job: [02e7af5b6423d2dbf82f852572f2fa8c00aafb19] https://lava.sirena.org.uk/scheduler/job/2263583
# test job: [29c8c00d9f9db5fb659b6f05f9e8964afc13f3e2] https://lava.sirena.org.uk/scheduler/job/2263419
# test job: [9a6bc0a406608e2520f18d996483c9d2e4a9fb27] https://lava.sirena.org.uk/scheduler/job/2263708
# test job: [f764645cb85a8b8f58067289cdfed28f6c1cdf49] https://lava.sirena.org.uk/scheduler/job/2263393
# test job: [7f7b350e4a65446f5d52ea8ae99e12eac8a972db] https://lava.sirena.org.uk/scheduler/job/2263713
# test job: [1303c2903889b01d581083ed92e439e7544dd3e5] https://lava.sirena.org.uk/scheduler/job/2263162
# test job: [524ee559948d8d079b13466e70fa741f909699c0] https://lava.sirena.org.uk/scheduler/job/2243761
# test job: [f25c7d709b93602ee9a08eba522808a18e1f5d56] https://lava.sirena.org.uk/scheduler/job/2243682
# test job: [f4acea9eef704607d1a950909ce3a52a770d6be2] https://lava.sirena.org.uk/scheduler/job/2243493
# test job: [e39011184f23de3d04ca8e80b4df76c9047b4026] https://lava.sirena.org.uk/scheduler/job/2231781
# test job: [fa08b566860bca8ebf9300090b85174c34de7ca5] https://lava.sirena.org.uk/scheduler/job/2232081
# test job: [03d281f384768610bf90697bce9e35d3d596de77] https://lava.sirena.org.uk/scheduler/job/2231184
# test job: [b884e34994ca41f7b7819f3c41b78ff494787b27] https://lava.sirena.org.uk/scheduler/job/2231834
# test job: [124f6155f3d97b0e33f178c10a5138a42c8fd207] https://lava.sirena.org.uk/scheduler/job/2232196
# test job: [aa30193af8873b3ccfd70a4275336ab6cbd4e5e6] https://lava.sirena.org.uk/scheduler/job/2231987
# test job: [0bb160c92ad400c692984763996b758458adea17] https://lava.sirena.org.uk/scheduler/job/2232057
# test job: [fee876b2ec75dcc18fdea154eae1f5bf14d82659] https://lava.sirena.org.uk/scheduler/job/2231321
# test job: [81acbdc51bbbec822a1525481f2f70677c47aee0] https://lava.sirena.org.uk/scheduler/job/2231999
# test job: [9e92c559d49d6fb903af17a31a469aac51b1766d] https://lava.sirena.org.uk/scheduler/job/2231743
# test job: [ba9b28652c75b07383e267328f1759195d5430f7] https://lava.sirena.org.uk/scheduler/job/2231572
# test job: [6c177775dcc5e70a64ddf4ee842c66af498f2c7c] https://lava.sirena.org.uk/scheduler/job/2058633
# test job: [615aad0f61e0c7a898184a394dc895c610100d4f] https://lava.sirena.org.uk/scheduler/job/2407321
# bad: [615aad0f61e0c7a898184a394dc895c610100d4f] Add linux-next specific files for 20260126
git bisect bad 615aad0f61e0c7a898184a394dc895c610100d4f
# test job: [a85cfbd09f2d2f3bfab8fbe8246d0ae43a0c1628] https://lava.sirena.org.uk/scheduler/job/2407528
# bad: [a85cfbd09f2d2f3bfab8fbe8246d0ae43a0c1628] Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
git bisect bad a85cfbd09f2d2f3bfab8fbe8246d0ae43a0c1628
# test job: [75fe66db9e85a2fd9743f7598a2aaea9eb5fbfd7] https://lava.sirena.org.uk/scheduler/job/2407694
# bad: [75fe66db9e85a2fd9743f7598a2aaea9eb5fbfd7] Merge branch 'xtensa-for-next' of https://github.com/jcmvbkbc/linux-xtensa.git
git bisect bad 75fe66db9e85a2fd9743f7598a2aaea9eb5fbfd7
# test job: [0578997f52fb9a1b9adfc5fe5a95ceab4bb331d2] https://lava.sirena.org.uk/scheduler/job/2407737
# good: [0578997f52fb9a1b9adfc5fe5a95ceab4bb331d2] Merge branch 'soc_fsl' of https://git.kernel.org/pub/scm/linux/kernel/git/chleroy/linux.git
git bisect good 0578997f52fb9a1b9adfc5fe5a95ceab4bb331d2
# test job: [5cd67271caee30972d751ab3763c3de4b1fa73d0] https://lava.sirena.org.uk/scheduler/job/2407794
# good: [5cd67271caee30972d751ab3763c3de4b1fa73d0] Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
git bisect good 5cd67271caee30972d751ab3763c3de4b1fa73d0
# test job: [039a29817a494720c25222b6daf104bf230583a7] https://lava.sirena.org.uk/scheduler/job/2407855
# good: [039a29817a494720c25222b6daf104bf230583a7] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git
git bisect good 039a29817a494720c25222b6daf104bf230583a7
# test job: [a142a51e64a948a70e8bcd5810fca89cab6347a5] https://lava.sirena.org.uk/scheduler/job/2407950
# bad: [a142a51e64a948a70e8bcd5810fca89cab6347a5] Merge branch 'clk-next' of https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
git bisect bad a142a51e64a948a70e8bcd5810fca89cab6347a5
# test job: [f5b748e97c52c31ad73b3534dfd1905efe664cc1] https://lava.sirena.org.uk/scheduler/job/2408066
# bad: [f5b748e97c52c31ad73b3534dfd1905efe664cc1] Merge branch 'clk-mediatek' into clk-next
git bisect bad f5b748e97c52c31ad73b3534dfd1905efe664cc1
# test job: [df9e5d59dcebe3217f1f5925f51b6beeb780c9b7] https://lava.sirena.org.uk/scheduler/job/2408105
# good: [df9e5d59dcebe3217f1f5925f51b6beeb780c9b7] Merge branch 'clk-spacemit' into clk-next
git bisect good df9e5d59dcebe3217f1f5925f51b6beeb780c9b7
# test job: [e98a16bf3cc49397a0fd88fe48d24e5f5f885707] https://lava.sirena.org.uk/scheduler/job/2408143
# good: [e98a16bf3cc49397a0fd88fe48d24e5f5f885707] Merge branch 'clk-amlogic' into clk-next
git bisect good e98a16bf3cc49397a0fd88fe48d24e5f5f885707
# test job: [e9955171948a226ee834a3092d71684acce84b65] https://lava.sirena.org.uk/scheduler/job/2408163
# good: [e9955171948a226ee834a3092d71684acce84b65] Merge branch 'clk-cleanup' into clk-next
git bisect good e9955171948a226ee834a3092d71684acce84b65
# test job: [ecffd05839b32f17bde1f3701b68ab182a837b07] https://lava.sirena.org.uk/scheduler/job/2408248
# bad: [ecffd05839b32f17bde1f3701b68ab182a837b07] clk: mediatek: Pass device to clk_hw_register for PLLs
git bisect bad ecffd05839b32f17bde1f3701b68ab182a837b07
# test job: [a2ed1aed687a21738a6c8bd4043149c443298e88] https://lava.sirena.org.uk/scheduler/job/2408288
# good: [a2ed1aed687a21738a6c8bd4043149c443298e88] dt-bindings: clock: mediatek,mt7622-pciesys: Remove syscon compatible
git bisect good a2ed1aed687a21738a6c8bd4043149c443298e88
# test job: [c9ced38af56fe6411118c6bc6522eab80849326d] https://lava.sirena.org.uk/scheduler/job/2408615
# bad: [c9ced38af56fe6411118c6bc6522eab80849326d] clk: mediatek: Refactor pll registration to pass device
git bisect bad c9ced38af56fe6411118c6bc6522eab80849326d
# test job: [669917676e93fca5ea3c66fc9539830312bec58e] https://lava.sirena.org.uk/scheduler/job/2409704
# bad: [669917676e93fca5ea3c66fc9539830312bec58e] clk: Respect CLK_OPS_PARENT_ENABLE during recalc
git bisect bad 669917676e93fca5ea3c66fc9539830312bec58e
# first bad commit: [669917676e93fca5ea3c66fc9539830312bec58e] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

On Tue, Jan 27, 2026 at 05:01:35PM +0000, Mark Brown wrote:
> On Fri, Oct 10, 2025 at 10:47:09PM +0200, Nicolas Frattaroli wrote:
> > When CLK_OPS_PARENT_ENABLE was introduced, it guarded various clock
> > operations, such as setting the rate or switching parents. However,
> > another operation that can and often does touch actual hardware state is
> > recalc_rate, which may also be affected by such a dependency.
> 
> I'm seeing boot regressions in -next on the Avenger96 which bisect to
> this patch in -next.  The board resets during startup:

I am also seeing some similar regressions even earlier on i.MX8MP
platforms, though they're resetting even earlier before any output is
produced (even with earlycon).  Didn't confirm yet with a revert or
anything though.

On Tuesday, 27 January 2026 18:25:04 Central European Standard Time Mark Brown wrote:
> On Tue, Jan 27, 2026 at 05:01:35PM +0000, Mark Brown wrote:
> > On Fri, Oct 10, 2025 at 10:47:09PM +0200, Nicolas Frattaroli wrote:
> > > When CLK_OPS_PARENT_ENABLE was introduced, it guarded various clock
> > > operations, such as setting the rate or switching parents. However,
> > > another operation that can and often does touch actual hardware state is
> > > recalc_rate, which may also be affected by such a dependency.
> > 
> > I'm seeing boot regressions in -next on the Avenger96 which bisect to
> > this patch in -next.  The board resets during startup:
> 
> I am also seeing some similar regressions even earlier on i.MX8MP
> platforms, though they're resetting even earlier before any output is
> produced (even with earlycon).  Didn't confirm yet with a revert or
> anything though.
> 

Someone else seemingly bisected to this commit on i.MX8MP as well
and replied to the RESEND of the series, and confirmed with a
revert[1].

I'm somewhat surprised by this, because to me it doesn't make intuitive
sense that some platforms would rely on CLK_OPS_PARENT_ENABLE to not
enable the parent clock during a recalc.

Can someone let me know which clocks (with which parent) in those
affected devices is causing this? I'm wondering if this change
unmasked some undeclared dependency that it's now stumbling over
because it's enabling the parent earlier than ever.

Would appreciate if we could fix up the affected platforms rather
than revert this, because the platform I added this for was
definitely using a parent-child relationship, and definitely
needed to have the parent clock on during recalc.

I can always bring back the RPM model I went for previously, but
that feels like more of a hack around this caveat than a proper
description of the clock relationship.

To not have me break everyone's -next for days on end, feel free
to drop this patch. MT8196, which this was added for, doesn't boot
with mainline yet anyway.

Kind regards,
Nicolas Frattaroli

https://lore.kernel.org/all/6239343.lOV4Wx5bFT@steina-w/ [1]

On Tue, Jan 27, 2026 at 07:18:02PM +0100, Nicolas Frattaroli wrote:

> Can someone let me know which clocks (with which parent) in those
> affected devices is causing this? I'm wondering if this change
> unmasked some undeclared dependency that it's now stumbling over
> because it's enabling the parent earlier than ever.

Do you have a debugging patch we could run which would say which clocks
are impacted?  I guess it's more of an issue for the platforms that give
no output but for at least Avenger96 I was getting earlycon output.

> To not have me break everyone's -next for days on end, feel free
> to drop this patch. MT8196, which this was added for, doesn't boot
> with mainline yet anyway.

Please, this is making my test lab miserable.

On Wednesday, 28 January 2026 00:14:29 Central European Standard Time Mark Brown wrote:
> On Tue, Jan 27, 2026 at 07:18:02PM +0100, Nicolas Frattaroli wrote:
> 
> > Can someone let me know which clocks (with which parent) in those
> > affected devices is causing this? I'm wondering if this change
> > unmasked some undeclared dependency that it's now stumbling over
> > because it's enabling the parent earlier than ever.
> 
> Do you have a debugging patch we could run which would say which clocks
> are impacted?  I guess it's more of an issue for the platforms that give
> no output but for at least Avenger96 I was getting earlycon output.

Try this one
---
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 1b0f9d567f48..fa1443517768 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1921,13 +1921,21 @@ static unsigned long clk_recalc(struct clk_core *core,
 	unsigned long rate = parent_rate;
 
 	if (core->ops->recalc_rate && !clk_pm_runtime_get(core)) {
-		if (core->flags & CLK_OPS_PARENT_ENABLE)
+		if (core->flags & CLK_OPS_PARENT_ENABLE) {
+			pr_info("%s: enabling parent %s for %s\n", __func__,
+				core->parent ? core->parent->name : "(null)",
+				core->name);
 			clk_core_prepare_enable(core->parent);
+		}
 
 		rate = core->ops->recalc_rate(core->hw, parent_rate);
 
-		if (core->flags & CLK_OPS_PARENT_ENABLE)
+		if (core->flags & CLK_OPS_PARENT_ENABLE) {
+			pr_info("%s: disabling parent %s for %s\n", __func__,
+				core->parent ? core->parent->name : "(null)",
+				core->name);
 			clk_core_disable_unprepare(core->parent);
+		}
 
 		clk_pm_runtime_put(core);
 	}
@@ -4038,8 +4046,12 @@ static int __clk_core_init(struct clk_core *core)
 	 */
 	clk_core_update_duty_cycle_nolock(core);
 
-	if (core->flags & CLK_OPS_PARENT_ENABLE)
+	if (core->flags & CLK_OPS_PARENT_ENABLE) {
+		pr_info("%s: enabling parent %s for %s\n", __func__,
+			core->parent ? core->parent->name : "(null)",
+			core->name);
 		clk_core_prepare_enable(core->parent);
+	}
 
 	/*
 	 * Set clk's rate.  The preferred method is to use .recalc_rate.  For
@@ -4056,8 +4068,12 @@ static int __clk_core_init(struct clk_core *core)
 		rate = 0;
 	core->rate = core->req_rate = rate;
 
-	if (core->flags & CLK_OPS_PARENT_ENABLE)
+	if (core->flags & CLK_OPS_PARENT_ENABLE) {
+		pr_info("%s: disabling parent %s for %s\n", __func__,
+			core->parent ? core->parent->name : "(null)",
+			core->name);
 		clk_core_disable_unprepare(core->parent);
+	}
 
 	/*
 	 * Enable CLK_IS_CRITICAL clocks so newly added critical clocks
---

I don't remember if printk buffers are flushed after each invocation and
couldn't quickly find a kernel parameter to control this, but from
experience I think these prints should show up if it then hangs the SoC
on the very next line.

> > To not have me break everyone's -next for days on end, feel free
> > to drop this patch. MT8196, which this was added for, doesn't boot
> > with mainline yet anyway.
> 
> Please, this is making my test lab miserable.
> 

The good news is that the rest of the series can stay without doing
any harm if this single patch gets dropped, and I can re-attempt
this in the next cycle.

Kind regards,
Nicolas Frattaroli

On Wed, Jan 28, 2026 at 03:09:46PM +0100, Nicolas Frattaroli wrote:
> On Wednesday, 28 January 2026 00:14:29 Central European Standard Time Mark Brown wrote:

> > Do you have a debugging patch we could run which would say which clocks
> > are impacted?  I guess it's more of an issue for the platforms that give
> > no output but for at least Avenger96 I was getting earlycon output.

> Try this one

For the Avenger96 that says:

[    0.347816] __clk_core_init: enabling parent ck_hse for ck_per
[    0.352230] __clk_core_init: disabling parent ck_hse for ck_per
[    0.358207] __clk_core_init: enabling parent pll1_p for ck_mpu
[    0.364005] __clk_core_init: disabling parent pll1_p for ck_mpu

https://lava.sirena.org.uk/scheduler/job/2412562#L563

On Wednesday, 28 January 2026 15:47:08 Central European Standard Time Mark Brown wrote:
> On Wed, Jan 28, 2026 at 03:09:46PM +0100, Nicolas Frattaroli wrote:
> > On Wednesday, 28 January 2026 00:14:29 Central European Standard Time Mark Brown wrote:
> 
> > > Do you have a debugging patch we could run which would say which clocks
> > > are impacted?  I guess it's more of an issue for the platforms that give
> > > no output but for at least Avenger96 I was getting earlycon output.
> 
> > Try this one
> 
> For the Avenger96 that says:
> 
> [    0.347816] __clk_core_init: enabling parent ck_hse for ck_per
> [    0.352230] __clk_core_init: disabling parent ck_hse for ck_per
> [    0.358207] __clk_core_init: enabling parent pll1_p for ck_mpu
> [    0.364005] __clk_core_init: disabling parent pll1_p for ck_mpu
> 
> https://lava.sirena.org.uk/scheduler/job/2412562#L563
> 

Okay, on this one, there may be a problem in the clock tree.
ck_mpu is marked CLK_IS_CRITICAL, but its parent, pll1_p, is not. Clock
core doesn't seem to check whether any children of a clock are marked as
critical before disabling it.

I'm not super familiar with the intended semantics of critical clocks.
If we need to manually mark all parents of critical clocks as critical
as well, then a (potentially partial) fix for the Avenger96 might be:

---
diff --git a/drivers/clk/stm32/clk-stm32mp1.c b/drivers/clk/stm32/clk-stm32mp1.c
index 2d9ccd96ec98..6bf3fad1e0dc 100644
--- a/drivers/clk/stm32/clk-stm32mp1.c
+++ b/drivers/clk/stm32/clk-stm32mp1.c
@@ -1783,12 +1783,12 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 	PLL(PLL4, "pll4", ref4_parents, 0, RCC_PLL4CR, RCC_RCK4SELR),
 
 	/* ODF */
-	COMPOSITE(PLL1_P, "pll1_p", PARENT("pll1"), 0,
+	COMPOSITE(PLL1_P, "pll1_p", PARENT("pll1"), CLK_IS_CRITICAL,
 		  _GATE(RCC_PLL1CR, 4, 0),
 		  _NO_MUX,
 		  _DIV(RCC_PLL1CFGR2, 0, 7, 0, NULL)),
 
-	COMPOSITE(PLL2_P, "pll2_p", PARENT("pll2"), 0,
+	COMPOSITE(PLL2_P, "pll2_p", PARENT("pll2"), CLK_IS_CRITICAL,
 		  _GATE(RCC_PLL2CR, 4, 0),
 		  _NO_MUX,
 		  _DIV(RCC_PLL2CFGR2, 0, 7, 0, NULL)),
@@ -1803,7 +1803,7 @@ static const struct clock_config stm32mp1_clock_cfg[] = {
 		  _NO_MUX,
 		  _DIV(RCC_PLL2CFGR2, 16, 7, 0, NULL)),
 
-	COMPOSITE(PLL3_P, "pll3_p", PARENT("pll3"), 0,
+	COMPOSITE(PLL3_P, "pll3_p", PARENT("pll3"), CLK_IS_CRITICAL,
 		  _GATE(RCC_PLL3CR, 4, 0),
 		  _NO_MUX,
 		  _DIV(RCC_PLL3CFGR2, 0, 7, 0, NULL)),
---

I just looked for CLK_IS_CRITICAL clocks in that file that have the
CLK_OPS_PARENT_ENABLE flag, and marked their PLL parents as critical
as well.

An alternate approach would be to skip the parent enable/disable pair
in the problematic patch in __clk_core_init for clocks that are marked
as critical, because if the parent wasn't on for a critical clock then
we wouldn't be in that function, we would be dead.

Kind regards,
Nicolas Frattaroli

Quoting Nicolas Frattaroli (2026-01-28 09:04:55)
> On Wednesday, 28 January 2026 15:47:08 Central European Standard Time Mark Brown wrote:
> > 
> > For the Avenger96 that says:
> > 
> > [    0.347816] __clk_core_init: enabling parent ck_hse for ck_per
> > [    0.352230] __clk_core_init: disabling parent ck_hse for ck_per
> > [    0.358207] __clk_core_init: enabling parent pll1_p for ck_mpu
> > [    0.364005] __clk_core_init: disabling parent pll1_p for ck_mpu
> > 
> > https://lava.sirena.org.uk/scheduler/job/2412562#L563
> > 
> 
> Okay, on this one, there may be a problem in the clock tree.
> ck_mpu is marked CLK_IS_CRITICAL, but its parent, pll1_p, is not. Clock
> core doesn't seem to check whether any children of a clock are marked as
> critical before disabling it.
> 
> I'm not super familiar with the intended semantics of critical clocks.
> If we need to manually mark all parents of critical clocks as critical
> as well, then a (potentially partial) fix for the Avenger96 might be:
> 

Marking parents critical hasn't been strictly necessary so far because
we've been relying on the prepare/enable count on a critical child to
keep the parent prepared/enabled.

> 
> I just looked for CLK_IS_CRITICAL clocks in that file that have the
> CLK_OPS_PARENT_ENABLE flag, and marked their PLL parents as critical
> as well.
> 
> An alternate approach would be to skip the parent enable/disable pair
> in the problematic patch in __clk_core_init for clocks that are marked
> as critical, because if the parent wasn't on for a critical clock then
> we wouldn't be in that function, we would be dead.

The parent may not be known yet in __clk_core_init() because we lazily
find parents. Putting it another way, we can get to the recalc_rate()
call in __clk_core_init() for a clk with CLK_OPS_PARENT_ENABLE when the
parent pointer is NULL. This hasn't been a problem because when we adopt
the orphan clk the rate is recalculated (see
clk_core_reparent_orphans_nolock()).

I don't see an easy way out of this problem because in general we need
to know a clk with CLK_OPS_PARENT_ENABLE is parented enough to be able
to read the registers when calling clk_ops like recalc_rate() (and
probably get_parent() as well meaning that clk_op can't touch
hardware?). Maybe the simplest approach is to skip any sort of hardware
access when this flag is set during setup and reparenting.

BTW, I don't know what this patch is actually fixing, so I'm going to
revert it. When it is resubmitted please describe the problem you're
seeing.

On Wed, Jan 28, 2026 at 12:01:22PM -0700, Stephen Boyd wrote:

> BTW, I don't know what this patch is actually fixing, so I'm going to
> revert it. When it is resubmitted please describe the problem you're
> seeing.

The patch is still in -next today and the issues it causes are still
visible.

On Wednesday, 28 January 2026 20:01:22 Central European Standard Time Stephen Boyd wrote:
> Quoting Nicolas Frattaroli (2026-01-28 09:04:55)
> > On Wednesday, 28 January 2026 15:47:08 Central European Standard Time Mark Brown wrote:
> > > 
> > > For the Avenger96 that says:
> > > 
> > > [    0.347816] __clk_core_init: enabling parent ck_hse for ck_per
> > > [    0.352230] __clk_core_init: disabling parent ck_hse for ck_per
> > > [    0.358207] __clk_core_init: enabling parent pll1_p for ck_mpu
> > > [    0.364005] __clk_core_init: disabling parent pll1_p for ck_mpu
> > > 
> > > https://lava.sirena.org.uk/scheduler/job/2412562#L563
> > > 
> > 
> > Okay, on this one, there may be a problem in the clock tree.
> > ck_mpu is marked CLK_IS_CRITICAL, but its parent, pll1_p, is not. Clock
> > core doesn't seem to check whether any children of a clock are marked as
> > critical before disabling it.
> > 
> > I'm not super familiar with the intended semantics of critical clocks.
> > If we need to manually mark all parents of critical clocks as critical
> > as well, then a (potentially partial) fix for the Avenger96 might be:
> > 
> 
> Marking parents critical hasn't been strictly necessary so far because
> we've been relying on the prepare/enable count on a critical child to
> keep the parent prepared/enabled.
> 
> > 
> > I just looked for CLK_IS_CRITICAL clocks in that file that have the
> > CLK_OPS_PARENT_ENABLE flag, and marked their PLL parents as critical
> > as well.
> > 
> > An alternate approach would be to skip the parent enable/disable pair
> > in the problematic patch in __clk_core_init for clocks that are marked
> > as critical, because if the parent wasn't on for a critical clock then
> > we wouldn't be in that function, we would be dead.
> 
> The parent may not be known yet in __clk_core_init() because we lazily
> find parents. Putting it another way, we can get to the recalc_rate()
> call in __clk_core_init() for a clk with CLK_OPS_PARENT_ENABLE when the
> parent pointer is NULL. This hasn't been a problem because when we adopt
> the orphan clk the rate is recalculated (see
> clk_core_reparent_orphans_nolock()).

In this instance, it doesn't seem like the parent pointer is null, since
it does print a parent clock name. I think the problem really is that the
parent gets disabled before the CLK_IS_CRITICAL check re-enables it.

> I don't see an easy way out of this problem because in general we need
> to know a clk with CLK_OPS_PARENT_ENABLE is parented enough to be able
> to read the registers when calling clk_ops like recalc_rate() (and
> probably get_parent() as well meaning that clk_op can't touch
> hardware?). Maybe the simplest approach is to skip any sort of hardware
> access when this flag is set during setup and reparenting.

The issue both SoCs seem to run into is that the parent gets disabled
when it shouldn't be, which I fixed in [1]. I don't think any platform
that already worked before this change will stop working with this fix
and the fix for the fix in [1], because if the parent is absent, then
the enable/disables are no-ops anyway. NULL clocks are explicitly
handled by the common clock framework.

> BTW, I don't know what this patch is actually fixing, so I'm going to
> revert it. When it is resubmitted please describe the problem you're
> seeing.

The justification got lost in the revisions of the series this was done
in. It's to deal with the MediaTek MT8196's MFGPLL clocks, where the
parent clock needs to be on before the clock registers of the child
clock can be touched in any way. I first modeled this as an RPM clock,
but Angelo didn't like this approach, and with some hackery I could sort
of see that the child clock indeed does not tick if the would-be RPM clock
is off, so it must be a parent clock instead.

The problem with making it a parent clock and adding this flag to it though
is that the flag is not respected in recalc_rate, so it reads from an
unclocked register.

If you want me to make it an RPM clock instead, I can do that, but then
we're leaking that the NXP i.MX8MP has a broken clock driver into the
device tree bindings of the MediaTek MT8196 PLLs, which seems like a hard
sell for the DT bindings maintainers.

So in conclusion, I'm fairly confident I've found a fix for the fix, and
I'm also very confident the problem doesn't go as deep as you fear. I'll
squash the fix for the fix into the fix when I resubmit the fix with a
fix for the i.MX, but that'll have to wait until after -rc1 I think.

Kind regards,
Nicolas Frattaroli

Link: https://lore.kernel.org/all/20260128-ops-parent-enable-fix-v1-1-ff39cc37f98d@collabora.com/ [1]

Hi everyone,

Am Mittwoch, 28. Januar 2026, 15:47:08 CET schrieb Mark Brown:
> On Wed, Jan 28, 2026 at 03:09:46PM +0100, Nicolas Frattaroli wrote:
> > On Wednesday, 28 January 2026 00:14:29 Central European Standard Time Mark Brown wrote:
> 
> > > Do you have a debugging patch we could run which would say which clocks
> > > are impacted?  I guess it's more of an issue for the platforms that give
> > > no output but for at least Avenger96 I was getting earlycon output.
> 
> > Try this one
> 
> For the Avenger96 that says:
> 
> [    0.347816] __clk_core_init: enabling parent ck_hse for ck_per
> [    0.352230] __clk_core_init: disabling parent ck_hse for ck_per
> [    0.358207] __clk_core_init: enabling parent pll1_p for ck_mpu
> [    0.364005] __clk_core_init: disabling parent pll1_p for ck_mpu
> 
> https://lava.sirena.org.uk/scheduler/job/2412562#L563
> 

This is for TQMa8MPxL/MBa8MPxL:

[    1.452788] __clk_core_init: enabling parent audio_pll1_out for clkout1_sel
[    1.457677] __clk_core_init: disabling parent audio_pll1_out for clkout1_sel
[    1.464270] __clk_core_init: enabling parent audio_pll1_out for clkout2_sel
[    1.471760] __clk_core_init: disabling parent audio_pll1_out for clkout2_sel
[    1.478360] __clk_core_init: enabling parent sys_pll2_500m for arm_a53_div
[    1.485259] __clk_core_init: disabling parent sys_pll2_500m for arm_a53_div

Best regards,
Alexander

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

On Wed, Jan 28, 2026 at 03:55:54PM +0100, Alexander Stein wrote:

> This is for TQMa8MPxL/MBa8MPxL:

> [    1.452788] __clk_core_init: enabling parent audio_pll1_out for clkout1_sel
> [    1.457677] __clk_core_init: disabling parent audio_pll1_out for clkout1_sel
> [    1.464270] __clk_core_init: enabling parent audio_pll1_out for clkout2_sel
> [    1.471760] __clk_core_init: disabling parent audio_pll1_out for clkout2_sel
> [    1.478360] __clk_core_init: enabling parent sys_pll2_500m for arm_a53_div
> [    1.485259] __clk_core_init: disabling parent sys_pll2_500m for arm_a53_div

As expected same result on i.MX8MP-EVK.

On Wednesday, 28 January 2026 16:21:47 Central European Standard Time Mark Brown wrote:
> On Wed, Jan 28, 2026 at 03:55:54PM +0100, Alexander Stein wrote:
> 
> > This is for TQMa8MPxL/MBa8MPxL:
> 
> > [    1.452788] __clk_core_init: enabling parent audio_pll1_out for clkout1_sel
> > [    1.457677] __clk_core_init: disabling parent audio_pll1_out for clkout1_sel
> > [    1.464270] __clk_core_init: enabling parent audio_pll1_out for clkout2_sel
> > [    1.471760] __clk_core_init: disabling parent audio_pll1_out for clkout2_sel
> > [    1.478360] __clk_core_init: enabling parent sys_pll2_500m for arm_a53_div
> > [    1.485259] __clk_core_init: disabling parent sys_pll2_500m for arm_a53_div
> 
> As expected same result on i.MX8MP-EVK.
> 

This one puzzles me a little. arm_a53_div is neither marked critical
nor is its parent. If arm_a53_div is required for the system to function,
then I'd have expected at least it to be marked as critical, allowing us
to do the workaround in init I proposed as an alternate solution for the
stm32mp1 in my other reply.

Also, after reading the code some more, I think that alternate solution
has a simpler implementation: move the parent disable to after the

  if (core->flags & CLK_IS_CRITICAL) {

check in __clk_core_init.

One explanation is that some other critical clock hangs off sys_pll2_500m,
but we're spoiled for choice here. I can't think of a simple fix right now
that I feel confident in.

Every IMX8MP composite clock that isn't critical seems to set
IMX_COMPOSITE_CLK_FLAGS_DEFAULT, which includes CLK_OPS_PARENT_ENABLE,
which seems like a pretty weird choice to make when you then rely on
the parent not getting touched during __clk_core_init.

I will try to get an RFC fix out tonight (CET). I think STM32MP1 is
falling over because I messed up, and i.MX8MP is falling over due to
a combination of me messing up and its clock driver messing up.

Kind regards,
Nicolas Frattaroli

On Wed, Jan 28, 2026 at 05:31:35PM +0100, Nicolas Frattaroli wrote:
> On Wednesday, 28 January 2026 16:21:47 Central European Standard Time Mark Brown wrote:

> > > [    1.478360] __clk_core_init: enabling parent sys_pll2_500m for arm_a53_div
> > > [    1.485259] __clk_core_init: disabling parent sys_pll2_500m for arm_a53_div

> > As expected same result on i.MX8MP-EVK.

> This one puzzles me a little. arm_a53_div is neither marked critical
> nor is its parent. If arm_a53_div is required for the system to function,
> then I'd have expected at least it to be marked as critical, allowing us
> to do the workaround in init I proposed as an alternate solution for the
> stm32mp1 in my other reply.

Given that all the cores in the system are A53s I rather fear that it is
in fact critical and should be marked as such.

Hi Nicolas,

On Fri, Oct 10, 2025 at 10:47:09PM +0200, Nicolas Frattaroli wrote:
> When CLK_OPS_PARENT_ENABLE was introduced, it guarded various clock
> operations, such as setting the rate or switching parents. However,
> another operation that can and often does touch actual hardware state is
> recalc_rate, which may also be affected by such a dependency.
> 
> Add parent enables/disables where the recalc_rate op is called directly.
> 
> Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
> Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)")
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
>  drivers/clk/clk.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 85d2f2481acf360f0618a4a382fb51250e9c2fc4..1b0f9d567f48e003497afc98df0c0d2ad244eb90 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1921,7 +1921,14 @@ static unsigned long clk_recalc(struct clk_core *core,
>  	unsigned long rate = parent_rate;
>  
>  	if (core->ops->recalc_rate && !clk_pm_runtime_get(core)) {
> +		if (core->flags & CLK_OPS_PARENT_ENABLE)
> +			clk_core_prepare_enable(core->parent);
> +
>  		rate = core->ops->recalc_rate(core->hw, parent_rate);
> +
> +		if (core->flags & CLK_OPS_PARENT_ENABLE)
> +			clk_core_disable_unprepare(core->parent);
> +
>  		clk_pm_runtime_put(core);
>  	}
>  	return rate;

clk_change_rate() has the following code:


        if (core->flags & CLK_OPS_PARENT_ENABLE)
                clk_core_prepare_enable(parent);

	...

        core->rate = clk_recalc(core, best_parent_rate);

	...

        if (core->flags & CLK_OPS_PARENT_ENABLE)
                clk_core_disable_unprepare(parent);

clk_change_rate() ultimately is called by various clk_set_rate
functions. Will that be a problem for the double calls to
clk_core_prepare_enable()?

Fanning this out to the edge further is going to make the code even
more complicated. What do you think about moving this to
clk_core_enable_lock()? I know the set_parent operation has a special
case that would need to be worked around.

Brian

On Thursday, 16 October 2025 22:52:30 Central European Summer Time Brian Masney wrote:
> Hi Nicolas,
> 
> On Fri, Oct 10, 2025 at 10:47:09PM +0200, Nicolas Frattaroli wrote:
> > When CLK_OPS_PARENT_ENABLE was introduced, it guarded various clock
> > operations, such as setting the rate or switching parents. However,
> > another operation that can and often does touch actual hardware state is
> > recalc_rate, which may also be affected by such a dependency.
> > 
> > Add parent enables/disables where the recalc_rate op is called directly.
> > 
> > Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
> > Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)")
> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> >  drivers/clk/clk.c | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 85d2f2481acf360f0618a4a382fb51250e9c2fc4..1b0f9d567f48e003497afc98df0c0d2ad244eb90 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -1921,7 +1921,14 @@ static unsigned long clk_recalc(struct clk_core *core,
> >  	unsigned long rate = parent_rate;
> >  
> >  	if (core->ops->recalc_rate && !clk_pm_runtime_get(core)) {
> > +		if (core->flags & CLK_OPS_PARENT_ENABLE)
> > +			clk_core_prepare_enable(core->parent);
> > +
> >  		rate = core->ops->recalc_rate(core->hw, parent_rate);
> > +
> > +		if (core->flags & CLK_OPS_PARENT_ENABLE)
> > +			clk_core_disable_unprepare(core->parent);
> > +
> >  		clk_pm_runtime_put(core);
> >  	}
> >  	return rate;
> 
> clk_change_rate() has the following code:
> 
> 
>         if (core->flags & CLK_OPS_PARENT_ENABLE)
>                 clk_core_prepare_enable(parent);
> 
> 	...
> 
>         core->rate = clk_recalc(core, best_parent_rate);
> 
> 	...
> 
>         if (core->flags & CLK_OPS_PARENT_ENABLE)
>                 clk_core_disable_unprepare(parent);
> 
> clk_change_rate() ultimately is called by various clk_set_rate
> functions. Will that be a problem for the double calls to
> clk_core_prepare_enable()?

I don't see how multiple prepares are a problem as long as they're
balanced.

> 
> Fanning this out to the edge further is going to make the code even
> more complicated. What do you think about moving this to
> clk_core_enable_lock()? I know the set_parent operation has a special
> case that would need to be worked around.

__clk_core_init also needs special code in that case, as it calls the
bare recalc_rate op with no clk_core_enable_lock beforehand. It's also
wrong, in that recalc_rate does not necessitate the clock being on as
far as I'm aware. (if it did, this wouldn't be a problem in the first
place, as enabling it would enable the parent as well). Changing the
semantics of clk_recalc, and therefore clk_get_rate, to also enable
the clock, would be a major change in how the common clock framework
functions.

In my case, the __clk_core_init callback was the one that crashed,
so it really needs to happen there, and I really don't want to
refactor every location where `CLK_OPS_PARENT_ENABLE` is used for
a bugfix just to avoid potentially checking the same flag twice.

Having `CLK_OPS_PARENT_ENABLE` cleaned up such that every clk op
that has potential register access is never directly called by the
clk core except for one place, an accessor function that does both
pmdomain and `CLK_OPS_PARENT_ENABLE` checks, would be nice, e.g.
by keeping the clk_recalc change and then having __clk_core_init
call clk_recalc instead of the recalc op directly. But then the
__clk_core_init logic needs further refactoring as well.

I'm not sure I want to do that in this series, because it's quite
a bit different from just adding the missing check and parent
toggling, and has the chance of me introducing subtle logic bugs
in what is supposed to be a bugfix.

> 
> Brian
> 
> 

Kind regards,
Nicolas Frattaroli

Hi Nicolas,

On Fri, Oct 17, 2025 at 02:21:55PM +0200, Nicolas Frattaroli wrote:
> On Thursday, 16 October 2025 22:52:30 Central European Summer Time Brian Masney wrote:
> > On Fri, Oct 10, 2025 at 10:47:09PM +0200, Nicolas Frattaroli wrote:
> > > When CLK_OPS_PARENT_ENABLE was introduced, it guarded various clock
> > > operations, such as setting the rate or switching parents. However,
> > > another operation that can and often does touch actual hardware state is
> > > recalc_rate, which may also be affected by such a dependency.
> > > 
> > > Add parent enables/disables where the recalc_rate op is called directly.
> > > 
> > > Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
> > > Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)")
> > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > > Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
> > > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > > ---
> > >  drivers/clk/clk.c | 13 +++++++++++++
> > >  1 file changed, 13 insertions(+)
> > > 
> > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > index 85d2f2481acf360f0618a4a382fb51250e9c2fc4..1b0f9d567f48e003497afc98df0c0d2ad244eb90 100644
> > > --- a/drivers/clk/clk.c
> > > +++ b/drivers/clk/clk.c
> > > @@ -1921,7 +1921,14 @@ static unsigned long clk_recalc(struct clk_core *core,
> > >  	unsigned long rate = parent_rate;
> > >  
> > >  	if (core->ops->recalc_rate && !clk_pm_runtime_get(core)) {
> > > +		if (core->flags & CLK_OPS_PARENT_ENABLE)
> > > +			clk_core_prepare_enable(core->parent);
> > > +
> > >  		rate = core->ops->recalc_rate(core->hw, parent_rate);
> > > +
> > > +		if (core->flags & CLK_OPS_PARENT_ENABLE)
> > > +			clk_core_disable_unprepare(core->parent);
> > > +
> > >  		clk_pm_runtime_put(core);
> > >  	}
> > >  	return rate;
> > 
> > clk_change_rate() has the following code:
> > 
> > 
> >         if (core->flags & CLK_OPS_PARENT_ENABLE)
> >                 clk_core_prepare_enable(parent);
> > 
> > 	...
> > 
> >         core->rate = clk_recalc(core, best_parent_rate);
> > 
> > 	...
> > 
> >         if (core->flags & CLK_OPS_PARENT_ENABLE)
> >                 clk_core_disable_unprepare(parent);
> > 
> > clk_change_rate() ultimately is called by various clk_set_rate
> > functions. Will that be a problem for the double calls to
> > clk_core_prepare_enable()?
> 
> I don't see how multiple prepares are a problem as long as they're
> balanced.
> 
> > 
> > Fanning this out to the edge further is going to make the code even
> > more complicated. What do you think about moving this to
> > clk_core_enable_lock()? I know the set_parent operation has a special
> > case that would need to be worked around.
> 
> __clk_core_init also needs special code in that case, as it calls the
> bare recalc_rate op with no clk_core_enable_lock beforehand. It's also
> wrong, in that recalc_rate does not necessitate the clock being on as
> far as I'm aware. (if it did, this wouldn't be a problem in the first
> place, as enabling it would enable the parent as well). Changing the
> semantics of clk_recalc, and therefore clk_get_rate, to also enable
> the clock, would be a major change in how the common clock framework
> functions.
> 
> In my case, the __clk_core_init callback was the one that crashed,
> so it really needs to happen there, and I really don't want to
> refactor every location where `CLK_OPS_PARENT_ENABLE` is used for
> a bugfix just to avoid potentially checking the same flag twice.
> 
> Having `CLK_OPS_PARENT_ENABLE` cleaned up such that every clk op
> that has potential register access is never directly called by the
> clk core except for one place, an accessor function that does both
> pmdomain and `CLK_OPS_PARENT_ENABLE` checks, would be nice, e.g.
> by keeping the clk_recalc change and then having __clk_core_init
> call clk_recalc instead of the recalc op directly. But then the
> __clk_core_init logic needs further refactoring as well.
> 
> I'm not sure I want to do that in this series, because it's quite
> a bit different from just adding the missing check and parent
> toggling, and has the chance of me introducing subtle logic bugs
> in what is supposed to be a bugfix.

I agree and that makes sense. Thanks for the explanation. What you have
is a good compromise.

Reviewed-by: Brian Masney <bmasney@redhat.com>