From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B1DD284898 for ; Fri, 30 Jan 2026 08:17:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769761054; cv=none; b=hh26GvxWeYcmmIpWkg8SKfb5p4hNm8ns79xKdtOGjqsW1fxDPAwVkLdecnypHnipBe9VZptCiUI8w7Lh/j8WGKXg2dryeXUIYwoJM5KC5+486B3fPHfYohuSB9MDs+lqty/fEjFN7oGe4v6WQ+gJU1rMLN+Z6pMm8qdFEcR77Uo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769761054; c=relaxed/simple; bh=SxLqE44zUUxs1dvaadGY9E3DpJnP/taoyxmSUjwcM00=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GnlqWO2DkKFvuo31URoNkrxESSHzPbznLo+8yJ+PX6vcBpzSfgSrZqPaZuvqn2mYOoj4Wp7QhUdHEbWKajWoTw8tmT63oSyzQuFf4Wjz8EWsWvvBFWt4yerSXiFjOxBWAFac1Onu8nmTRSLQZNXvpFTo2RrSz+9FOybK5WOPOe4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SiK1xCBm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SiK1xCBm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38CCAC4CEF7; Fri, 30 Jan 2026 08:17:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769761054; bh=SxLqE44zUUxs1dvaadGY9E3DpJnP/taoyxmSUjwcM00=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=SiK1xCBmZRzZSTAGdSIV7V9uGeUjIdIa1736iKo1bi11W9OkKJhT9ttVn0pAEpDwT rGtdYUWt4JbDaciao5Y6YdWMzZW+zCoP6Zjs3SLtE0xV+B9kZZs9X3KCNIgtvFUQw4 JJ14slv8bApSWz/a7RA07Bk0B7oCt7SJmdXFpHQWjgf7UV9EYxHPuwbWvnWOlb2ENA LCWB8NU+/cXbgeurd+ocqQAsUCmH3pkD4zs4Wa6OS0n4wgdTcvl24eLybvQZMZdZ25 w+dHyoIPScNcPsJc18pYNc9PkRzdrK4OtYLL9Sm9s9q7+LTe9IVBeaYdILPWF2mlV8 httBgzWekJC5w== Date: Fri, 30 Jan 2026 08:17:31 +0000 From: Tzung-Bi Shih To: Ulf Hansson Cc: Chen-Yu Tsai , Matthias Brugger , AngeloGioacchino Del Regno , linux-pm@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH v2] pmdomain: mediatek: Break lock dependency to `prepare_lock` Message-ID: References: <20251231035357.1147578-1-tzungbi@kernel.org> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Jan 27, 2026 at 02:57:46PM +0100, Ulf Hansson wrote: > On Thu, 22 Jan 2026 at 09:38, Chen-Yu Tsai wrote: > > On Wed, Dec 31, 2025 at 11:54 AM Tzung-Bi Shih 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?