linux-kernel - Re: [PATCH] clk: thead: th1520-ap: Correctly refer the parent for c910 and osc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aGnaZjMoWbW_FZfj@pie>
Date: Sun, 6 Jul 2025 02:07:51 +0000
From: Yao Zi <ziyao@...root.org>
To: Drew Fustini <fustini@...nel.org>
Cc: Guo Ren <guoren@...nel.org>, Fu Wei <wefu@...hat.com>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>, Jisheng Zhang <jszhang@...nel.org>,
	Yangtao Li <frank.li@...o.com>, linux-riscv@...ts.infradead.org,
	linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clk: thead: th1520-ap: Correctly refer the parent for
 c910 and osc_12m

On Sat, Jul 05, 2025 at 05:08:09PM -0700, Drew Fustini wrote:
> On Sat, Jul 05, 2025 at 05:20:28AM +0000, Yao Zi wrote:
> > clk_orphan_dump shows two suspicious orphan clocks on TH1520 when
> > booting the kernel with mainline U-Boot,
> > 
> > 	$ cat /sys/kernel/debug/clk/clk_orphan_dump | jq 'keys'
> > 	[
> > 	  "c910",
> > 	  "osc_12m"
> > 	]
> > 
> > where the correct parents should be c910-i0 for c910, and osc_24m for
> > osc_12m.
> 
> Thanks for sending this patch. However, I only see "osc_12m" listed in
> clk_orphan_dump. I tried the current next, torvalds master and v6.15 but
> I didn't ever see "c910" appear [1]. What branch are you using?

I think it has something to do with the bootloader: as you could see in
your clk_orphan_dump, the c910 clock is reparented to cpu-pll1, the
second possible parent which could be correctly resolved by the CCF,
thus c910 doesn't appear in the clk_orphan_dump.

But with the mainline U-Boot which doesn't reparent or reclock c910 on
startup, c910 should remain the reset state and take c910-i0 as parent,
and appear in the clk_orphan_dump.

Another way to confirm the bug is to examine
/sys/kernel/debug/clk/c910/clk_possible_parents: without the patch, it
should be something like

	osc_24m cpu-pll1

c910's parents are defined as

	static const struct clk_parent_data c910_parents[] = {
		{ .hw = &c910_i0_clk.common.hw },
		{ .hw = &cpu_pll1_clk.common.hw }
	};

and the debugfs output looks obviously wrong.

There's another bug in CCF[1] which causes unresolvable parents are
shown as the clock-output-names of the clock controller's first parent
in debugfs, explaining the output.

> I think it would be best for this patch to be split into separate
> patches for osc_12m and c910.

Okay, I originally thought these are relatively small fixes targeting
a single driver, hence put them together. I'll split it into two patches
in v2.

> > The correct parent of c910, c910-i0, is registered with
> > devm_clk_hw_register_mux_parent_data_table(), which creates a clk_hw
> > structure from scratch. But it's assigned as c910's parent by
> > referring &c910_i0_clk.common.hw, confusing the CCF since this clk_hw
> > structure is never registered.
> 
> I recall Stephen Boyd had the feedback when trying to upstream this
> driver to avoid strings for parents and instead use clk_parent_data or
> clk_hw pointers directly [2]. It was difficult to find alternitves to
> parent strings in all instances.

Yes, especially the predefined clock types which always allocate a new
struct clk_hw, so one has to choose between filling the parent data
dynamically or using the parent's name.

> > Meanwhile, osc_12m refers the external oscillator by setting
> > clk_parent_data.fw_name to osc_24m, which is obviously wrong since no
> > clock-names property is allowed for compatible thead,th1520-clk-ap.
> > 
> > For c910, refer c910-i0 by its name; for osc_12m, refer the external
> > clock input by index. This eliminates these orphan clocks.
> > 
> > Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks")
> > Signed-off-by: Yao Zi <ziyao@...root.org>
> > ---
> >  drivers/clk/thead/clk-th1520-ap.c | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/clk/thead/clk-th1520-ap.c b/drivers/clk/thead/clk-th1520-ap.c
> > index ebfb1d59401d..74da1a61e6f0 100644
> > --- a/drivers/clk/thead/clk-th1520-ap.c
> > +++ b/drivers/clk/thead/clk-th1520-ap.c
> > @@ -427,7 +427,7 @@ static struct ccu_mux c910_i0_clk = {
> >  };
> >  
> >  static const struct clk_parent_data c910_parents[] = {
> > -	{ .hw = &c910_i0_clk.common.hw },
> > +	{ .index = -1, .name = "c910-i0" },
> 
> Stephen - would this use of a parent string be acceptable?
> 
> >  	{ .hw = &cpu_pll1_clk.common.hw }
> >  };
> >  
> > @@ -582,7 +582,14 @@ static const struct clk_parent_data peri2sys_apb_pclk_pd[] = {
> >  	{ .hw = &peri2sys_apb_pclk.common.hw }
> >  };
> >  
> > -static CLK_FIXED_FACTOR_FW_NAME(osc12m_clk, "osc_12m", "osc_24m", 2, 1, 0);
> > +struct clk_fixed_factor osc12m_clk = {
> > +	.div		= 2,
> > +	.mult		= 1,
> > +	.hw.init	= CLK_HW_INIT_PARENTS_DATA("osc_12m",
> > +						   osc_24m_clk,
> > +						   &clk_fixed_factor_ops,
> > +						   0),
> > +};
> 
> I think this hunk is a good fix for osc_12m. I applied the patch and
> osc_12m no longer appears in clk_orphan_dump [3]. clk_summary now shows
> osc_12m under osc_24m.

Thanks for the confirmation!

> >  
> >  static const char * const out_parents[] = { "osc_24m", "osc_12m" };
> >  
> > -- 
> > 2.49.0
> > 
> 
> [1] https://gist.github.com/pdp7/d00f0f4fe3fcf368ce253d606dc7b01f
> [2] https://lore.kernel.org/all/91c3373b5b00afc1910b704a16c1ac89.sboyd@kernel.org/
> [3] https://gist.github.com/pdp7/30e51ed013d4bedf0c6abc5717e0b6a5

Regards,
Yao Zi

[1]: https://lore.kernel.org/linux-clk/20250705095816.29480-2-ziyao@disroot.org/