[PATCH v2] pmdomain: mediatek: Break lock dependency to `prepare_lock`

[Tzung-Bi Shih]

On Tue, Jan 27, 2026 at 02:57:46PM +0100, Ulf Hansson wrote:
> On Thu, 22 Jan 2026 at 09:38, Chen-Yu Tsai <wenst at chromium.org> wrote:
> > On Wed, Dec 31, 2025 at 11:54 AM Tzung-Bi Shih <tzungbi at kernel.org> wrote:
> > > @@ -398,7 +398,7 @@ static int scpsys_hwv_power_off(struct generic_pm_domain *genpd)
> > >                         return ret;
> > >         }
> > >
> > > -       ret = clk_bulk_prepare_enable(pd->num_subsys_clks, pd->subsys_clks);
> > > +       ret = clk_bulk_enable(pd->num_subsys_clks, pd->subsys_clks);
> 
> scpsys_hwv_power_off() is typically called by genpd in the suspend
> noirq() phase, when all devices attached to the genpd in question have
> been suspended too. See genpd_suspend_noirq().
> 
> This means that scpsys_suspend() (below) may be called to unprepare
> the clock, before scpsys_hwv_power_off() may call clk_disable(). This
> is a bug according to the clock framework.

Ack, I observed a similar warning in a system suspend/resume cycle.

> 
> Moving scpsys_suspend() to the noirq phase too could maybe work.

No, I guess it doesn't work as .prepare() can sleep however noirq phase
shouldn't/can't.

> Although, perhaps an even simpler solution would be to do the
> clk_prepare() during ->probe() and clk_unprepare() during ->remove()
> (and error path in probe). Of course, this assumes that
> clk_prepare/unprepare doesn't really do anything hardware wise, so we
> don't start wasting power by keeping the clocks prepared.

It turns out a pure revert of f0fce06e345d ("soc: mtk-pm-domains: Fix
the clock prepared issue").  Per the commit message of f0fce06e345d,
the concern is some PLLs keep prepared even if the system is suspended.

Not sure should we take the compromise?