All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Brue <ryanbrue.dev@gmail.com>
To: sashiko-reviews@lists.linux.dev
Cc: linux-clk@vger.kernel.org
Subject: Re: [PATCH] clk: mediatek: mt8173-mfgtop: do not use the clk API from power_on
Date: Sun, 13 Sep 2026 16:26:25 -0500	[thread overview]
Message-ID: <e657312e-5e2e-4f57-9718-31f13e622422@gmail.com> (raw)
In-Reply-To: <20260912184456.1DB0D1F000FF@smtp.kernel.org>

On 9/12/26 1:44 PM, sashiko-bot@kernel.org wrote:
> [Severity: High]
> Since this raw regmap write in clk_mt8173_mfgtop_power_on() in
> drivers/clk/mediatek/clk-mt8173-mfgtop.c directly asserts the gate in
> hardware, bypassing the Common Clock Framework (CCF) state tracking, the
> clock's enable_count remains 0.
>
> Because the mfg_26m clock is still fully registered via mfg_clks without the
> CLK_IGNORE_UNUSED flag, won't clk_disable_unused() forcibly disable this
> clock during late init?
>
> If a consumer has probed and powered on the domain before or during
> late_initcall_sync, clk_disable_unused() will check the hardware state, see
> that the bit is active while enable_count is 0, and turn it off by writing
> to set_ofs.
>
> This abruptly shuts off the internal power management clock while the genpd
> is still active, potentially leading to hardware hangs and failure of
> subsequent power-off operations.
Yep, that's a real gap. I'll add CLK_IGNORE_UNUSED to the mfg_26m gate. 
Thanks for catching this!
> [Severity: High]
> This raw regmap write in clk_mt8173_mfgtop_power_off() deasserts the gate
> directly, overriding any state assumed by CCF, which is part of the same
> framework bypass issue described above.
This shares the same fix as the first one; once CCF stops touching the 
gate, the raw set/clr writes from the callbacks are the only writers. 
I'll send out a v2.

      reply	other threads:[~2026-09-13 21:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-12 18:32 [PATCH] clk: mediatek: mt8173-mfgtop: do not use the clk API from power_on Ryan Brue
2026-09-12 18:44 ` sashiko-bot
2026-09-13 21:26   ` Ryan Brue [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e657312e-5e2e-4f57-9718-31f13e622422@gmail.com \
    --to=ryanbrue.dev@gmail.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.