[PATCH v3 0/5] MediaTek PLL Refactors and Fixes

[PATCH v3 0/5] MediaTek PLL Refactors and Fixes

[Nicolas Frattaroli]

This series refactors all users of mtk-pll, just so we can enable
runtime power management for the clock controllers that want it. It's
also generally more useful to have the struct device in the pll code,
rather than the device node.

Also fix up MT8196 mfgpll to declare its parent-child relationship with
mfg_eb, and fix the common clock framework core to take
CLK_OPS_PARENT_ENABLE into account for the recalc_rate op as well.

The reason why this is all in the same series is that it grew out of me
first modelling this as an RPM clock for mfgpll, which Angelo disagreed
with, so I did some investigation and it seems MFG_EB indeed is a parent
clock. However, the earlier refactoring to pass the device pointer down
is still useful.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v3:
- Make device_node forward declaration a device forward declaration
- Remove forward declarations of struct clk_ops and struct
  clk_hw_onecell_data. (clk-provider.h include remains as it's needed
  for a complete type of clk_hw)
- Move PLL_PARENT_EN flag to individual mfgpll definitions.
- Link to v2: https://lore.kernel.org/r/20251008-mtk-pll-rpm-v2-0-170ed0698560@collabora.com

Changes in v2:
- Drop bindings patch
- Drop mfgpll RPM patch
- Add patch to also transition pllfh to passing device
- Add fixes patch to make CLK_OPS_PARENT_ENABLE also apply to the
  recalc_rate operation
- Remodel mfgpll's mfg_eb dependency as parent-child with
  CLK_OPS_PARENT_ENABLE
- Link to v1: https://lore.kernel.org/r/20250929-mtk-pll-rpm-v1-0-49541777878d@collabora.com

---
Nicolas Frattaroli (5):
      clk: Respect CLK_OPS_PARENT_ENABLE during recalc
      clk: mediatek: Refactor pll registration to pass device
      clk: mediatek: Pass device to clk_hw_register for PLLs
      clk: mediatek: Refactor pllfh registration to pass device
      clk: mediatek: Add mfg_eb as parent to mt8196 mfgpll clocks

 drivers/clk/clk.c                            | 13 +++++++++++++
 drivers/clk/mediatek/clk-mt2701.c            |  2 +-
 drivers/clk/mediatek/clk-mt2712-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt6735-apmixedsys.c |  4 ++--
 drivers/clk/mediatek/clk-mt6765.c            |  2 +-
 drivers/clk/mediatek/clk-mt6779.c            |  2 +-
 drivers/clk/mediatek/clk-mt6795-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt6797.c            |  2 +-
 drivers/clk/mediatek/clk-mt7622-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt7629.c            |  2 +-
 drivers/clk/mediatek/clk-mt7981-apmixed.c    |  2 +-
 drivers/clk/mediatek/clk-mt7986-apmixed.c    |  2 +-
 drivers/clk/mediatek/clk-mt7988-apmixed.c    |  2 +-
 drivers/clk/mediatek/clk-mt8135-apmixedsys.c |  3 ++-
 drivers/clk/mediatek/clk-mt8167-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8173-apmixedsys.c | 14 +++++++-------
 drivers/clk/mediatek/clk-mt8183-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8186-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8188-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8192-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8195-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8195-apusys_pll.c |  3 ++-
 drivers/clk/mediatek/clk-mt8196-apmixedsys.c |  3 ++-
 drivers/clk/mediatek/clk-mt8196-mcu.c        |  2 +-
 drivers/clk/mediatek/clk-mt8196-mfg.c        | 15 ++++++++-------
 drivers/clk/mediatek/clk-mt8196-vlpckgen.c   |  2 +-
 drivers/clk/mediatek/clk-mt8365-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8516-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-pll.c               | 19 +++++++++++++------
 drivers/clk/mediatek/clk-pll.h               | 15 ++++++++-------
 drivers/clk/mediatek/clk-pllfh.c             | 13 ++++++++-----
 drivers/clk/mediatek/clk-pllfh.h             |  2 +-
 32 files changed, 87 insertions(+), 59 deletions(-)
---
base-commit: adff43957b0d8b9f6ad0e1b1f6daa7136f9ffbef
change-id: 20250929-mtk-pll-rpm-bf28192dd016

Best regards,
-- 
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

[PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Nicolas Frattaroli]

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

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Brian Masney]

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

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Nicolas Frattaroli]

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

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Brian Masney]

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>

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 27030 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Nicolas Frattaroli]

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]

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Nicolas Frattaroli]

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

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Alexander Stein]

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/

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Nicolas Frattaroli]

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

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Nicolas Frattaroli]

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

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Stephen Boyd]

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.

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Nicolas Frattaroli]

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]

Re: [PATCH v3 1/5] clk: Respect CLK_OPS_PARENT_ENABLE during recalc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v3 2/5] clk: mediatek: Refactor pll registration to pass device

[Nicolas Frattaroli]

As it stands, mtk_clk_register_plls takes a struct device_node pointer
as its first argument. This is a tragic happenstance, as it's trivial to
get the device_node from a struct device, but the opposite not so much.
The struct device is a much more useful thing to have passed down.

Refactor mtk_clk_register_plls to take a struct device pointer instead
of a struct device_node pointer, and fix up all users of this function.

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/mediatek/clk-mt2701.c            |  2 +-
 drivers/clk/mediatek/clk-mt2712-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt6735-apmixedsys.c |  4 ++--
 drivers/clk/mediatek/clk-mt6765.c            |  2 +-
 drivers/clk/mediatek/clk-mt6779.c            |  2 +-
 drivers/clk/mediatek/clk-mt6797.c            |  2 +-
 drivers/clk/mediatek/clk-mt7622-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt7629.c            |  2 +-
 drivers/clk/mediatek/clk-mt7981-apmixed.c    |  2 +-
 drivers/clk/mediatek/clk-mt7986-apmixed.c    |  2 +-
 drivers/clk/mediatek/clk-mt7988-apmixed.c    |  2 +-
 drivers/clk/mediatek/clk-mt8135-apmixedsys.c |  3 ++-
 drivers/clk/mediatek/clk-mt8167-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8183-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8188-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8195-apusys_pll.c |  3 ++-
 drivers/clk/mediatek/clk-mt8196-apmixedsys.c |  3 ++-
 drivers/clk/mediatek/clk-mt8196-mcu.c        |  2 +-
 drivers/clk/mediatek/clk-mt8196-mfg.c        |  2 +-
 drivers/clk/mediatek/clk-mt8196-vlpckgen.c   |  2 +-
 drivers/clk/mediatek/clk-mt8365-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8516-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-pll.c               |  7 ++++---
 drivers/clk/mediatek/clk-pll.h               | 10 ++++------
 24 files changed, 34 insertions(+), 32 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt2701.c b/drivers/clk/mediatek/clk-mt2701.c
index 1e88ad8b93f4485ad40f842e19c68117e00a2fbe..d9f40fda73d1abc56ebc97ab755bb48bd5f0991f 100644
--- a/drivers/clk/mediatek/clk-mt2701.c
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -978,7 +978,7 @@ static int mtk_apmixedsys_init(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	mtk_clk_register_plls(node, apmixed_plls, ARRAY_SIZE(apmixed_plls),
+	mtk_clk_register_plls(&pdev->dev, apmixed_plls, ARRAY_SIZE(apmixed_plls),
 								clk_data);
 	mtk_clk_register_factors(apmixed_fixed_divs, ARRAY_SIZE(apmixed_fixed_divs),
 								clk_data);
diff --git a/drivers/clk/mediatek/clk-mt2712-apmixedsys.c b/drivers/clk/mediatek/clk-mt2712-apmixedsys.c
index a60622d251ff30fe8db2e596d87986a88f854e61..54b18e9f83f8f403460c77d8f5d4ea0737316774 100644
--- a/drivers/clk/mediatek/clk-mt2712-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt2712-apmixedsys.c
@@ -119,7 +119,7 @@ static int clk_mt2712_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	r = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	r = mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls), clk_data);
 	if (r)
 		goto free_clk_data;
 
diff --git a/drivers/clk/mediatek/clk-mt6735-apmixedsys.c b/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
index e0949911e8f7da7894b204012caefd0404cf8308..9e30c089a2092472bab889ede419c41890c307a0 100644
--- a/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
@@ -93,8 +93,8 @@ static int clk_mt6735_apmixed_probe(struct platform_device *pdev)
 		return -ENOMEM;
 	platform_set_drvdata(pdev, clk_data);
 
-	ret = mtk_clk_register_plls(pdev->dev.of_node, apmixedsys_plls,
-				   ARRAY_SIZE(apmixedsys_plls), clk_data);
+	ret = mtk_clk_register_plls(&pdev->dev, apmixedsys_plls,
+				    ARRAY_SIZE(apmixedsys_plls), clk_data);
 	if (ret) {
 		dev_err(&pdev->dev, "Failed to register PLLs: %d\n", ret);
 		return ret;
diff --git a/drivers/clk/mediatek/clk-mt6765.c b/drivers/clk/mediatek/clk-mt6765.c
index d53731e7933f46d88ff180e43eb7163e52fb5b1c..60f6f9fa7dcf279631d0fa2eb30a3bcbadef3225 100644
--- a/drivers/clk/mediatek/clk-mt6765.c
+++ b/drivers/clk/mediatek/clk-mt6765.c
@@ -740,7 +740,7 @@ static int clk_mt6765_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls), clk_data);
 
 	mtk_clk_register_gates(&pdev->dev, node, apmixed_clks,
 			       ARRAY_SIZE(apmixed_clks), clk_data);
diff --git a/drivers/clk/mediatek/clk-mt6779.c b/drivers/clk/mediatek/clk-mt6779.c
index 86732f5acf93407a5aa99bc2f386f0728a06bb9b..4b9dcb910b03f1078212dc7089d7171d05de7e7f 100644
--- a/drivers/clk/mediatek/clk-mt6779.c
+++ b/drivers/clk/mediatek/clk-mt6779.c
@@ -1220,7 +1220,7 @@ static int clk_mt6779_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls), clk_data);
 
 	mtk_clk_register_gates(&pdev->dev, node, apmixed_clks,
 			       ARRAY_SIZE(apmixed_clks), clk_data);
diff --git a/drivers/clk/mediatek/clk-mt6797.c b/drivers/clk/mediatek/clk-mt6797.c
index fb59e71af58e32d9419e036e3dbd28cdaa61cac3..ebf850ac57f540f2317e63dfabe94a953db3ae29 100644
--- a/drivers/clk/mediatek/clk-mt6797.c
+++ b/drivers/clk/mediatek/clk-mt6797.c
@@ -655,7 +655,7 @@ static int mtk_apmixedsys_init(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls), clk_data);
 
 	return of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
 }
diff --git a/drivers/clk/mediatek/clk-mt7622-apmixedsys.c b/drivers/clk/mediatek/clk-mt7622-apmixedsys.c
index 2350592d9a934f3ec8efb0cd8197e4c4fee49697..8a29eaab0cfcb7a389e09f8869b572d5886e2eaf 100644
--- a/drivers/clk/mediatek/clk-mt7622-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt7622-apmixedsys.c
@@ -96,7 +96,7 @@ static int clk_mt7622_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	ret = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	ret = mtk_clk_register_plls(dev, plls, ARRAY_SIZE(plls), clk_data);
 	if (ret)
 		return ret;
 
diff --git a/drivers/clk/mediatek/clk-mt7629.c b/drivers/clk/mediatek/clk-mt7629.c
index baf94e7bea373c59cb6333fdb483d00240b744c7..e154771b1b8bba7378af8a797c81d0784b626e3b 100644
--- a/drivers/clk/mediatek/clk-mt7629.c
+++ b/drivers/clk/mediatek/clk-mt7629.c
@@ -634,7 +634,7 @@ static int mtk_apmixedsys_init(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls),
+	mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls),
 			      clk_data);
 
 	mtk_clk_register_gates(&pdev->dev, node, apmixed_clks,
diff --git a/drivers/clk/mediatek/clk-mt7981-apmixed.c b/drivers/clk/mediatek/clk-mt7981-apmixed.c
index e8211eb4e09e1a645f7e50a1e5814d29030c1757..6606b54fb376983ec7d49b00c2c0d1690c734058 100644
--- a/drivers/clk/mediatek/clk-mt7981-apmixed.c
+++ b/drivers/clk/mediatek/clk-mt7981-apmixed.c
@@ -76,7 +76,7 @@ static int clk_mt7981_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls), clk_data);
 
 	r = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
 	if (r) {
diff --git a/drivers/clk/mediatek/clk-mt7986-apmixed.c b/drivers/clk/mediatek/clk-mt7986-apmixed.c
index 93751abe6be89784a102a0e5ac629d363ab3baaf..1c79418d08a77acf25cee914fb6573ac1707163e 100644
--- a/drivers/clk/mediatek/clk-mt7986-apmixed.c
+++ b/drivers/clk/mediatek/clk-mt7986-apmixed.c
@@ -74,7 +74,7 @@ static int clk_mt7986_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls), clk_data);
 
 	r = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
 	if (r) {
diff --git a/drivers/clk/mediatek/clk-mt7988-apmixed.c b/drivers/clk/mediatek/clk-mt7988-apmixed.c
index 63d33a78cb48805f71aa6a74f8ed6b83f3b4fe22..416a4b88d100bb47bdb07e4f72bc13208c8707a7 100644
--- a/drivers/clk/mediatek/clk-mt7988-apmixed.c
+++ b/drivers/clk/mediatek/clk-mt7988-apmixed.c
@@ -86,7 +86,7 @@ static int clk_mt7988_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	r = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	r = mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls), clk_data);
 	if (r)
 		goto free_apmixed_data;
 
diff --git a/drivers/clk/mediatek/clk-mt8135-apmixedsys.c b/drivers/clk/mediatek/clk-mt8135-apmixedsys.c
index bdadc35c64cbd8987061c4442b8ff2f5fe50cc32..19e4ee489ec3905e92674ed0813a9f60f9c28209 100644
--- a/drivers/clk/mediatek/clk-mt8135-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8135-apmixedsys.c
@@ -57,7 +57,8 @@ static int clk_mt8135_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	ret = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	ret = mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls),
+				    clk_data);
 	if (ret)
 		goto free_clk_data;
 
diff --git a/drivers/clk/mediatek/clk-mt8167-apmixedsys.c b/drivers/clk/mediatek/clk-mt8167-apmixedsys.c
index adf576786696e0962dfd5147dfc8897bfaa48054..fb6c21bbeef81a383b56c8fada1799e0680676e5 100644
--- a/drivers/clk/mediatek/clk-mt8167-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8167-apmixedsys.c
@@ -105,7 +105,7 @@ static int clk_mt8167_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	ret = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	ret = mtk_clk_register_plls(dev, plls, ARRAY_SIZE(plls), clk_data);
 	if (ret)
 		return ret;
 
diff --git a/drivers/clk/mediatek/clk-mt8183-apmixedsys.c b/drivers/clk/mediatek/clk-mt8183-apmixedsys.c
index 551adbfd7ac9309bbc4f9beefe4f26230514f062..6242d4f5376e79346b2219b0a35cf0c5ad755e49 100644
--- a/drivers/clk/mediatek/clk-mt8183-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8183-apmixedsys.c
@@ -155,7 +155,7 @@ static int clk_mt8183_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	ret = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	ret = mtk_clk_register_plls(dev, plls, ARRAY_SIZE(plls), clk_data);
 	if (ret)
 		return ret;
 
diff --git a/drivers/clk/mediatek/clk-mt8188-apmixedsys.c b/drivers/clk/mediatek/clk-mt8188-apmixedsys.c
index 21d7a9a2ab1af64cca6962960418d44c81dc664a..a1de596bff9945ca938504391e3e33a4987d3a63 100644
--- a/drivers/clk/mediatek/clk-mt8188-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8188-apmixedsys.c
@@ -106,7 +106,7 @@ static int clk_mt8188_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	r = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	r = mtk_clk_register_plls(&pdev->dev, plls, ARRAY_SIZE(plls), clk_data);
 	if (r)
 		goto free_apmixed_data;
 
diff --git a/drivers/clk/mediatek/clk-mt8195-apusys_pll.c b/drivers/clk/mediatek/clk-mt8195-apusys_pll.c
index 8b45a3fad02f18df30e4c2ce2ba5b6338eae321f..a2d98ed58e34866b3d68bd0f85bde339c258d822 100644
--- a/drivers/clk/mediatek/clk-mt8195-apusys_pll.c
+++ b/drivers/clk/mediatek/clk-mt8195-apusys_pll.c
@@ -66,7 +66,8 @@ static int clk_mt8195_apusys_pll_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	r = mtk_clk_register_plls(node, apusys_plls, ARRAY_SIZE(apusys_plls), clk_data);
+	r = mtk_clk_register_plls(&pdev->dev, apusys_plls,
+				  ARRAY_SIZE(apusys_plls), clk_data);
 	if (r)
 		goto free_apusys_pll_data;
 
diff --git a/drivers/clk/mediatek/clk-mt8196-apmixedsys.c b/drivers/clk/mediatek/clk-mt8196-apmixedsys.c
index 617f5449b88b8bcaf282e8ed8593b52413a233a8..c4ebb0170b82b979fbe7f03925f205325247d55d 100644
--- a/drivers/clk/mediatek/clk-mt8196-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8196-apmixedsys.c
@@ -152,7 +152,8 @@ static int clk_mt8196_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	r = mtk_clk_register_plls(node, mcd->clks, mcd->num_clks, clk_data);
+	r = mtk_clk_register_plls(&pdev->dev, mcd->clks, mcd->num_clks,
+				  clk_data);
 	if (r)
 		goto free_apmixed_data;
 
diff --git a/drivers/clk/mediatek/clk-mt8196-mcu.c b/drivers/clk/mediatek/clk-mt8196-mcu.c
index 5cbcc411ae734c82b97bf099a645cb6aaa31d9c3..13642fc673c267a66027d1fa7073c9cfed68c682 100644
--- a/drivers/clk/mediatek/clk-mt8196-mcu.c
+++ b/drivers/clk/mediatek/clk-mt8196-mcu.c
@@ -122,7 +122,7 @@ static int clk_mt8196_mcu_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	r = mtk_clk_register_plls(node, plls, num_plls, clk_data);
+	r = mtk_clk_register_plls(&pdev->dev, plls, num_plls, clk_data);
 	if (r)
 		goto free_clk_data;
 
diff --git a/drivers/clk/mediatek/clk-mt8196-mfg.c b/drivers/clk/mediatek/clk-mt8196-mfg.c
index ae1eb9de79ae2992b10a400c75e2e0324b100f66..8e09c0f7b7548f8e286671cea2dac64530b8ce47 100644
--- a/drivers/clk/mediatek/clk-mt8196-mfg.c
+++ b/drivers/clk/mediatek/clk-mt8196-mfg.c
@@ -105,7 +105,7 @@ static int clk_mt8196_mfg_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	r = mtk_clk_register_plls(node, plls, num_plls, clk_data);
+	r = mtk_clk_register_plls(&pdev->dev, plls, num_plls, clk_data);
 	if (r)
 		goto free_clk_data;
 
diff --git a/drivers/clk/mediatek/clk-mt8196-vlpckgen.c b/drivers/clk/mediatek/clk-mt8196-vlpckgen.c
index d59a8a9d98550e897d18031d9bb814aa96d3cf57..7dcc164627c578ca93377425c3b21b46da4b4c28 100644
--- a/drivers/clk/mediatek/clk-mt8196-vlpckgen.c
+++ b/drivers/clk/mediatek/clk-mt8196-vlpckgen.c
@@ -664,7 +664,7 @@ static int clk_mt8196_vlp_probe(struct platform_device *pdev)
 	if (r)
 		goto unregister_factors;
 
-	r = mtk_clk_register_plls(node, vlp_plls, ARRAY_SIZE(vlp_plls),
+	r = mtk_clk_register_plls(dev, vlp_plls, ARRAY_SIZE(vlp_plls),
 				  clk_data);
 	if (r)
 		goto unregister_muxes;
diff --git a/drivers/clk/mediatek/clk-mt8365-apmixedsys.c b/drivers/clk/mediatek/clk-mt8365-apmixedsys.c
index f41b991a0178af3067b19a693512ec922af48e07..e331aa28a4bd58baf48a4aae1601cc80fc5661ac 100644
--- a/drivers/clk/mediatek/clk-mt8365-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8365-apmixedsys.c
@@ -133,7 +133,7 @@ static int clk_mt8365_apmixed_probe(struct platform_device *pdev)
 		return PTR_ERR(hw);
 	clk_data->hws[CLK_APMIXED_USB20_EN] = hw;
 
-	ret = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	ret = mtk_clk_register_plls(dev, plls, ARRAY_SIZE(plls), clk_data);
 	if (ret)
 		return ret;
 
diff --git a/drivers/clk/mediatek/clk-mt8516-apmixedsys.c b/drivers/clk/mediatek/clk-mt8516-apmixedsys.c
index edd9174d2f2ff97a0c1198caa2a0b9c1ca40ffd2..2a6206cae2f087ff06fe60a6cf96a0fa3143e567 100644
--- a/drivers/clk/mediatek/clk-mt8516-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8516-apmixedsys.c
@@ -87,7 +87,7 @@ static int clk_mt8516_apmixed_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	ret = mtk_clk_register_plls(node, plls, ARRAY_SIZE(plls), clk_data);
+	ret = mtk_clk_register_plls(dev, plls, ARRAY_SIZE(plls), clk_data);
 	if (ret)
 		return ret;
 
diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index cd2b6ce551c6b0333cbe0a4f0d155ba2411f757a..5caf91ae9ddbe4f4d7052864adf0a5a70bda66bc 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -11,6 +11,7 @@
 #include <linux/io.h>
 #include <linux/module.h>
 #include <linux/of_address.h>
+#include <linux/platform_device.h>
 #include <linux/slab.h>
 
 #include "clk-pll.h"
@@ -404,7 +405,7 @@ void mtk_clk_unregister_pll(struct clk_hw *hw)
 	kfree(pll);
 }
 
-int mtk_clk_register_plls(struct device_node *node,
+int mtk_clk_register_plls(struct device *dev,
 			  const struct mtk_pll_data *plls, int num_plls,
 			  struct clk_hw_onecell_data *clk_data)
 {
@@ -412,7 +413,7 @@ int mtk_clk_register_plls(struct device_node *node,
 	int i;
 	struct clk_hw *hw;
 
-	base = of_iomap(node, 0);
+	base = of_iomap(dev->of_node, 0);
 	if (!base) {
 		pr_err("%s(): ioremap failed\n", __func__);
 		return -EINVAL;
@@ -423,7 +424,7 @@ int mtk_clk_register_plls(struct device_node *node,
 
 		if (!IS_ERR_OR_NULL(clk_data->hws[pll->id])) {
 			pr_warn("%pOF: Trying to register duplicate clock ID: %d\n",
-				node, pll->id);
+				dev->of_node, pll->id);
 			continue;
 		}
 
diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
index d71c150ce83e4bb2fe78290c2d5570a90084246d..38fde1a273bff0a7a010a37356ebc715fe0720d3 100644
--- a/drivers/clk/mediatek/clk-pll.h
+++ b/drivers/clk/mediatek/clk-pll.h
@@ -10,9 +10,7 @@
 #include <linux/clk-provider.h>
 #include <linux/types.h>
 
-struct clk_ops;
-struct clk_hw_onecell_data;
-struct device_node;
+struct device;
 
 struct mtk_pll_div_table {
 	u32 div;
@@ -78,9 +76,9 @@ struct mtk_clk_pll {
 	const struct mtk_pll_data *data;
 };
 
-int mtk_clk_register_plls(struct device_node *node,
-			  const struct mtk_pll_data *plls, int num_plls,
-			  struct clk_hw_onecell_data *clk_data);
+int mtk_clk_register_plls(struct device *dev, const struct mtk_pll_data *plls,
+			  int num_plls, struct clk_hw_onecell_data *clk_data);
+
 void mtk_clk_unregister_plls(const struct mtk_pll_data *plls, int num_plls,
 			     struct clk_hw_onecell_data *clk_data);
 

-- 
2.51.0

[PATCH v3 3/5] clk: mediatek: Pass device to clk_hw_register for PLLs

[Nicolas Frattaroli]

Passing the struct device pointer to clk_hw_register allows for runtime
power management to work for the registered clock controllers. However,
the mediatek PLL clocks do not do this.

Change this by adding a struct device pointer argument to
mtk_clk_register_pll, and fix up the only other user of it. Also add a
new member to the struct mtk_clk_pll for the struct device pointer,
which is set by mtk_clk_register_pll and is used by
mtk_clk_register_pll_ops.

If mtk_clk_register_pll is called with a NULL struct device pointer,
then everything still works as expected; the clock core will simply
treat them as previously, i.e. without runtime power management.

Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/clk/mediatek/clk-pll.c   | 9 ++++++---
 drivers/clk/mediatek/clk-pll.h   | 4 +++-
 drivers/clk/mediatek/clk-pllfh.c | 2 +-
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index 5caf91ae9ddbe4f4d7052864adf0a5a70bda66bc..c4f9c06e5133dbc5902f261353c197fbde95e54d 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -366,7 +366,7 @@ struct clk_hw *mtk_clk_register_pll_ops(struct mtk_clk_pll *pll,
 		init.parent_names = &parent_name;
 	init.num_parents = 1;
 
-	ret = clk_hw_register(NULL, &pll->hw);
+	ret = clk_hw_register(pll->dev, &pll->hw);
 
 	if (ret)
 		return ERR_PTR(ret);
@@ -374,7 +374,8 @@ struct clk_hw *mtk_clk_register_pll_ops(struct mtk_clk_pll *pll,
 	return &pll->hw;
 }
 
-struct clk_hw *mtk_clk_register_pll(const struct mtk_pll_data *data,
+struct clk_hw *mtk_clk_register_pll(struct device *dev,
+				    const struct mtk_pll_data *data,
 				    void __iomem *base)
 {
 	struct mtk_clk_pll *pll;
@@ -385,6 +386,8 @@ struct clk_hw *mtk_clk_register_pll(const struct mtk_pll_data *data,
 	if (!pll)
 		return ERR_PTR(-ENOMEM);
 
+	pll->dev = dev;
+
 	hw = mtk_clk_register_pll_ops(pll, data, base, pll_ops);
 	if (IS_ERR(hw))
 		kfree(pll);
@@ -428,7 +431,7 @@ int mtk_clk_register_plls(struct device *dev,
 			continue;
 		}
 
-		hw = mtk_clk_register_pll(pll, base);
+		hw = mtk_clk_register_pll(dev, pll, base);
 
 		if (IS_ERR(hw)) {
 			pr_err("Failed to register clk %s: %pe\n", pll->name,
diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
index 38fde1a273bff0a7a010a37356ebc715fe0720d3..f6493699c4e367b45038ceede9565ae42a030b47 100644
--- a/drivers/clk/mediatek/clk-pll.h
+++ b/drivers/clk/mediatek/clk-pll.h
@@ -61,6 +61,7 @@ struct mtk_pll_data {
  */
 
 struct mtk_clk_pll {
+	struct device *dev;
 	struct clk_hw	hw;
 	void __iomem	*base_addr;
 	void __iomem	*pd_addr;
@@ -108,7 +109,8 @@ struct clk_hw *mtk_clk_register_pll_ops(struct mtk_clk_pll *pll,
 					const struct mtk_pll_data *data,
 					void __iomem *base,
 					const struct clk_ops *pll_ops);
-struct clk_hw *mtk_clk_register_pll(const struct mtk_pll_data *data,
+struct clk_hw *mtk_clk_register_pll(struct device *dev,
+				    const struct mtk_pll_data *data,
 				    void __iomem *base);
 void mtk_clk_unregister_pll(struct clk_hw *hw);
 
diff --git a/drivers/clk/mediatek/clk-pllfh.c b/drivers/clk/mediatek/clk-pllfh.c
index 83630ee07ee976bf980c8cf2dd35ea24c1b40821..62bfe4a480f14a0a742fb094aff0e6d1a79fe0c3 100644
--- a/drivers/clk/mediatek/clk-pllfh.c
+++ b/drivers/clk/mediatek/clk-pllfh.c
@@ -220,7 +220,7 @@ int mtk_clk_register_pllfhs(struct device_node *node,
 		if (use_fhctl)
 			hw = mtk_clk_register_pllfh(pll, pllfh, base);
 		else
-			hw = mtk_clk_register_pll(pll, base);
+			hw = mtk_clk_register_pll(NULL, pll, base);
 
 		if (IS_ERR(hw)) {
 			pr_err("Failed to register %s clk %s: %ld\n",

-- 
2.51.0

[PATCH v3 4/5] clk: mediatek: Refactor pllfh registration to pass device

[Nicolas Frattaroli]

After refactoring all of PLL to pass the device, it's now fairly easy to
refactor pllfh and its users, as pllfh registration wraps PLL
registration.

Do this refactor and move all of the pllfh users to pass the device as
well.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/clk/mediatek/clk-mt6795-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8173-apmixedsys.c | 14 +++++++-------
 drivers/clk/mediatek/clk-mt8186-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8192-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-mt8195-apmixedsys.c |  2 +-
 drivers/clk/mediatek/clk-pllfh.c             | 13 ++++++++-----
 drivers/clk/mediatek/clk-pllfh.h             |  2 +-
 7 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt6795-apmixedsys.c b/drivers/clk/mediatek/clk-mt6795-apmixedsys.c
index 91665d7f125efde4941cc4de881c5b503a935529..123d5d7fea8554676364dc56f5c023e43325d516 100644
--- a/drivers/clk/mediatek/clk-mt6795-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt6795-apmixedsys.c
@@ -152,7 +152,7 @@ static int clk_mt6795_apmixed_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	fhctl_parse_dt(fhctl_node, pllfhs, ARRAY_SIZE(pllfhs));
-	ret = mtk_clk_register_pllfhs(node, plls, ARRAY_SIZE(plls),
+	ret = mtk_clk_register_pllfhs(dev, plls, ARRAY_SIZE(plls),
 				      pllfhs, ARRAY_SIZE(pllfhs), clk_data);
 	if (ret)
 		goto free_clk_data;
diff --git a/drivers/clk/mediatek/clk-mt8173-apmixedsys.c b/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
index 95385bb67d5511eda3a851f81986e67eaf81e5fb..d7d416172ab35bc027ae67c163c1dc20dee857b6 100644
--- a/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
@@ -140,13 +140,13 @@ MODULE_DEVICE_TABLE(of, of_match_clk_mt8173_apmixed);
 static int clk_mt8173_apmixed_probe(struct platform_device *pdev)
 {
 	const u8 *fhctl_node = "mediatek,mt8173-fhctl";
-	struct device_node *node = pdev->dev.of_node;
 	struct clk_hw_onecell_data *clk_data;
+	struct device *dev = &pdev->dev;
 	void __iomem *base;
 	struct clk_hw *hw;
 	int r;
 
-	base = of_iomap(node, 0);
+	base = of_iomap(dev->of_node, 0);
 	if (!base)
 		return -ENOMEM;
 
@@ -157,25 +157,25 @@ static int clk_mt8173_apmixed_probe(struct platform_device *pdev)
 	}
 
 	fhctl_parse_dt(fhctl_node, pllfhs, ARRAY_SIZE(pllfhs));
-	r = mtk_clk_register_pllfhs(node, plls, ARRAY_SIZE(plls),
-				    pllfhs, ARRAY_SIZE(pllfhs), clk_data);
+	r = mtk_clk_register_pllfhs(dev, plls, ARRAY_SIZE(plls), pllfhs,
+				    ARRAY_SIZE(pllfhs), clk_data);
 	if (r)
 		goto free_clk_data;
 
 	hw = mtk_clk_register_ref2usb_tx("ref2usb_tx", "clk26m", base + REGOFF_REF2USB);
 	if (IS_ERR(hw)) {
 		r = PTR_ERR(hw);
-		dev_err(&pdev->dev, "Failed to register ref2usb_tx: %d\n", r);
+		dev_err(dev, "Failed to register ref2usb_tx: %d\n", r);
 		goto unregister_plls;
 	}
 	clk_data->hws[CLK_APMIXED_REF2USB_TX] = hw;
 
-	hw = devm_clk_hw_register_divider(&pdev->dev, "hdmi_ref", "tvdpll_594m", 0,
+	hw = devm_clk_hw_register_divider(dev, "hdmi_ref", "tvdpll_594m", 0,
 					  base + REGOFF_HDMI_REF, 16, 3,
 					  CLK_DIVIDER_POWER_OF_TWO, NULL);
 	clk_data->hws[CLK_APMIXED_HDMI_REF] = hw;
 
-	r = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
+	r = of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get, clk_data);
 	if (r)
 		goto unregister_ref2usb;
 
diff --git a/drivers/clk/mediatek/clk-mt8186-apmixedsys.c b/drivers/clk/mediatek/clk-mt8186-apmixedsys.c
index 4b2b16578232d986f78deed4778c5fab7f460184..d35dd2632e43ab535b32b8b99f8d75de02d56fe2 100644
--- a/drivers/clk/mediatek/clk-mt8186-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8186-apmixedsys.c
@@ -151,7 +151,7 @@ static int clk_mt8186_apmixed_probe(struct platform_device *pdev)
 
 	fhctl_parse_dt(fhctl_node, pllfhs, ARRAY_SIZE(pllfhs));
 
-	r = mtk_clk_register_pllfhs(node, plls, ARRAY_SIZE(plls),
+	r = mtk_clk_register_pllfhs(&pdev->dev, plls, ARRAY_SIZE(plls),
 				    pllfhs, ARRAY_SIZE(pllfhs), clk_data);
 	if (r)
 		goto free_apmixed_data;
diff --git a/drivers/clk/mediatek/clk-mt8192-apmixedsys.c b/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
index 0b66a27e4d5ac68f09dc6a4197fd84ef82342df9..b0563a285bd666d492a7fa940733aad1ab1a0bae 100644
--- a/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
@@ -162,7 +162,7 @@ static int clk_mt8192_apmixed_probe(struct platform_device *pdev)
 
 	fhctl_parse_dt(fhctl_node, pllfhs, ARRAY_SIZE(pllfhs));
 
-	r = mtk_clk_register_pllfhs(node, plls, ARRAY_SIZE(plls),
+	r = mtk_clk_register_pllfhs(&pdev->dev, plls, ARRAY_SIZE(plls),
 				    pllfhs, ARRAY_SIZE(pllfhs), clk_data);
 	if (r)
 		goto free_clk_data;
diff --git a/drivers/clk/mediatek/clk-mt8195-apmixedsys.c b/drivers/clk/mediatek/clk-mt8195-apmixedsys.c
index 282a3137dc89419a6d0b574fd549cee941687900..44917ab034c56f01ef02d1957f17eb0655438d75 100644
--- a/drivers/clk/mediatek/clk-mt8195-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8195-apmixedsys.c
@@ -181,7 +181,7 @@ static int clk_mt8195_apmixed_probe(struct platform_device *pdev)
 
 	fhctl_parse_dt(fhctl_node, pllfhs, ARRAY_SIZE(pllfhs));
 
-	r = mtk_clk_register_pllfhs(node, plls, ARRAY_SIZE(plls),
+	r = mtk_clk_register_pllfhs(&pdev->dev, plls, ARRAY_SIZE(plls),
 				    pllfhs, ARRAY_SIZE(pllfhs), clk_data);
 	if (r)
 		goto free_apmixed_data;
diff --git a/drivers/clk/mediatek/clk-pllfh.c b/drivers/clk/mediatek/clk-pllfh.c
index 62bfe4a480f14a0a742fb094aff0e6d1a79fe0c3..8ad11023d91127e88900bc6bcabbaeafb1e00664 100644
--- a/drivers/clk/mediatek/clk-pllfh.c
+++ b/drivers/clk/mediatek/clk-pllfh.c
@@ -10,6 +10,7 @@
 #include <linux/slab.h>
 #include <linux/clkdev.h>
 #include <linux/delay.h>
+#include <linux/device.h>
 
 #include "clk-mtk.h"
 #include "clk-pllfh.h"
@@ -149,7 +150,7 @@ static bool fhctl_is_supported_and_enabled(const struct mtk_pllfh_data *pllfh)
 }
 
 static struct clk_hw *
-mtk_clk_register_pllfh(const struct mtk_pll_data *pll_data,
+mtk_clk_register_pllfh(struct device *dev, const struct mtk_pll_data *pll_data,
 		       struct mtk_pllfh_data *pllfh_data, void __iomem *base)
 {
 	struct clk_hw *hw;
@@ -166,6 +167,8 @@ mtk_clk_register_pllfh(const struct mtk_pll_data *pll_data,
 		goto out;
 	}
 
+	fh->clk_pll.dev = dev;
+
 	hw = mtk_clk_register_pll_ops(&fh->clk_pll, pll_data, base,
 				      &mtk_pllfh_ops);
 
@@ -194,7 +197,7 @@ static void mtk_clk_unregister_pllfh(struct clk_hw *hw)
 	kfree(fh);
 }
 
-int mtk_clk_register_pllfhs(struct device_node *node,
+int mtk_clk_register_pllfhs(struct device *dev,
 			    const struct mtk_pll_data *plls, int num_plls,
 			    struct mtk_pllfh_data *pllfhs, int num_fhs,
 			    struct clk_hw_onecell_data *clk_data)
@@ -203,7 +206,7 @@ int mtk_clk_register_pllfhs(struct device_node *node,
 	int i;
 	struct clk_hw *hw;
 
-	base = of_iomap(node, 0);
+	base = of_iomap(dev->of_node, 0);
 	if (!base) {
 		pr_err("%s(): ioremap failed\n", __func__);
 		return -EINVAL;
@@ -218,9 +221,9 @@ int mtk_clk_register_pllfhs(struct device_node *node,
 		use_fhctl = fhctl_is_supported_and_enabled(pllfh);
 
 		if (use_fhctl)
-			hw = mtk_clk_register_pllfh(pll, pllfh, base);
+			hw = mtk_clk_register_pllfh(dev, pll, pllfh, base);
 		else
-			hw = mtk_clk_register_pll(NULL, pll, base);
+			hw = mtk_clk_register_pll(dev, pll, base);
 
 		if (IS_ERR(hw)) {
 			pr_err("Failed to register %s clk %s: %ld\n",
diff --git a/drivers/clk/mediatek/clk-pllfh.h b/drivers/clk/mediatek/clk-pllfh.h
index 5f419c2ec01f988ede4e40289c6e5d5f8070ad14..a4f337acad71389f771187908882b09d0f801868 100644
--- a/drivers/clk/mediatek/clk-pllfh.h
+++ b/drivers/clk/mediatek/clk-pllfh.h
@@ -68,7 +68,7 @@ struct fh_operation {
 	int (*ssc_enable)(struct mtk_fh *fh, u32 rate);
 };
 
-int mtk_clk_register_pllfhs(struct device_node *node,
+int mtk_clk_register_pllfhs(struct device *dev,
 			    const struct mtk_pll_data *plls, int num_plls,
 			    struct mtk_pllfh_data *pllfhs, int num_pllfhs,
 			    struct clk_hw_onecell_data *clk_data);

-- 
2.51.0

[PATCH v3 5/5] clk: mediatek: Add mfg_eb as parent to mt8196 mfgpll clocks

[Nicolas Frattaroli]

All the MFGPLL require MFG_EB to be on for any operation on them, and
they only tick when MFG_EB is on as well, therefore making this a
parent-child relationship.

This dependency wasn't clear during the initial upstreaming of these
clock controllers, as it only made itself known when I could observe
the effects of the clock by bringing up a different piece of hardware.

Add a new PLL_PARENT_EN flag to mediatek's clk-pll.h, and check for it
when initialising the pll to then translate it into the actual
CLK_OPS_PARENT_ENABLE flag.

Then add the mfg_eb parent to the mfgpll clocks, and set the new
PLL_PARENT_EN flag.

Fixes: 03dc02f8c7dc ("clk: mediatek: Add MT8196 mfg clock support")
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/clk/mediatek/clk-mt8196-mfg.c | 13 +++++++------
 drivers/clk/mediatek/clk-pll.c        |  3 +++
 drivers/clk/mediatek/clk-pll.h        |  1 +
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8196-mfg.c b/drivers/clk/mediatek/clk-mt8196-mfg.c
index 8e09c0f7b7548f8e286671cea2dac64530b8ce47..a317183f1681bc6e8167c44b2bbe4a78566ba639 100644
--- a/drivers/clk/mediatek/clk-mt8196-mfg.c
+++ b/drivers/clk/mediatek/clk-mt8196-mfg.c
@@ -58,24 +58,25 @@
 		.pcw_shift = _pcw_shift,			\
 		.pcwbits = _pcwbits,				\
 		.pcwibits = MT8196_INTEGER_BITS,		\
+		.parent_name = "mfg_eb",			\
 	}
 
 static const struct mtk_pll_data mfg_ao_plls[] = {
-	PLL(CLK_MFG_AO_MFGPLL, "mfgpll", MFGPLL_CON0, MFGPLL_CON0, 0, 0, 0,
-	    BIT(0), MFGPLL_CON1, 24, 0, 0, 0,
+	PLL(CLK_MFG_AO_MFGPLL, "mfgpll", MFGPLL_CON0, MFGPLL_CON0, 0, 0,
+	    PLL_PARENT_EN, BIT(0), MFGPLL_CON1, 24, 0, 0, 0,
 	    MFGPLL_CON1, 0, 22),
 };
 
 static const struct mtk_pll_data mfgsc0_ao_plls[] = {
 	PLL(CLK_MFGSC0_AO_MFGPLL_SC0, "mfgpll-sc0", MFGPLL_SC0_CON0,
-	    MFGPLL_SC0_CON0, 0, 0, 0, BIT(0), MFGPLL_SC0_CON1, 24, 0, 0, 0,
-	    MFGPLL_SC0_CON1, 0, 22),
+	    MFGPLL_SC0_CON0, 0, 0, PLL_PARENT_EN, BIT(0), MFGPLL_SC0_CON1, 24,
+	    0, 0, 0, MFGPLL_SC0_CON1, 0, 22),
 };
 
 static const struct mtk_pll_data mfgsc1_ao_plls[] = {
 	PLL(CLK_MFGSC1_AO_MFGPLL_SC1, "mfgpll-sc1", MFGPLL_SC1_CON0,
-	    MFGPLL_SC1_CON0, 0, 0, 0, BIT(0), MFGPLL_SC1_CON1, 24, 0, 0, 0,
-	    MFGPLL_SC1_CON1, 0, 22),
+	    MFGPLL_SC1_CON0, 0, 0, PLL_PARENT_EN, BIT(0), MFGPLL_SC1_CON1, 24,
+	    0, 0, 0, MFGPLL_SC1_CON1, 0, 22),
 };
 
 static const struct of_device_id of_match_clk_mt8196_mfg[] = {
diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
index c4f9c06e5133dbc5902f261353c197fbde95e54d..0f3759fcd9d0228c23f4916d041d17b731a6c838 100644
--- a/drivers/clk/mediatek/clk-pll.c
+++ b/drivers/clk/mediatek/clk-pll.c
@@ -359,6 +359,9 @@ struct clk_hw *mtk_clk_register_pll_ops(struct mtk_clk_pll *pll,
 
 	init.name = data->name;
 	init.flags = (data->flags & PLL_AO) ? CLK_IS_CRITICAL : 0;
+	if (data->flags & PLL_PARENT_EN)
+		init.flags |= CLK_OPS_PARENT_ENABLE;
+
 	init.ops = pll_ops;
 	if (data->parent_name)
 		init.parent_names = &data->parent_name;
diff --git a/drivers/clk/mediatek/clk-pll.h b/drivers/clk/mediatek/clk-pll.h
index f6493699c4e367b45038ceede9565ae42a030b47..f49dc2732ffee50ebf023c01b513d74989a6ec7b 100644
--- a/drivers/clk/mediatek/clk-pll.h
+++ b/drivers/clk/mediatek/clk-pll.h
@@ -19,6 +19,7 @@ struct mtk_pll_div_table {
 
 #define HAVE_RST_BAR	BIT(0)
 #define PLL_AO		BIT(1)
+#define PLL_PARENT_EN	BIT(2)
 #define POSTDIV_MASK	GENMASK(2, 0)
 
 struct mtk_pll_data {

-- 
2.51.0