drivers/clk/thead/clk-th1520-ap.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
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.
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.
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@disroot.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" },
{ .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),
+};
static const char * const out_parents[] = { "osc_24m", "osc_12m" };
--
2.49.0Hi Yao,
kernel test robot noticed the following build warnings:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on linus/master v6.16-rc5 next-20250708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Yao-Zi/clk-thead-th1520-ap-Correctly-refer-the-parent-for-c910-and-osc_12m/20250705-132237
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
patch link: https://lore.kernel.org/r/20250705052028.24611-1-ziyao%40disroot.org
patch subject: [PATCH] clk: thead: th1520-ap: Correctly refer the parent for c910 and osc_12m
config: riscv-randconfig-r131-20250709 (https://download.01.org/0day-ci/archive/20250709/202507091214.BjAuy5rw-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 15.1.0
reproduce: (https://download.01.org/0day-ci/archive/20250709/202507091214.BjAuy5rw-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507091214.BjAuy5rw-lkp@intel.com/
sparse warnings: (new ones prefixed by >>)
WARNING: invalid argument to '-march': '_zacas_zabha'
>> drivers/clk/thead/clk-th1520-ap.c:585:25: sparse: sparse: symbol 'osc12m_clk' was not declared. Should it be static?
vim +/osc12m_clk +585 drivers/clk/thead/clk-th1520-ap.c
584
> 585 struct clk_fixed_factor osc12m_clk = {
586 .div = 2,
587 .mult = 1,
588 .hw.init = CLK_HW_INIT_PARENTS_DATA("osc_12m",
589 osc_24m_clk,
590 &clk_fixed_factor_ops,
591 0),
592 };
593
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
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 would be best for this patch to be split into separate
patches for osc_12m and c910.
> 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.
> 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@disroot.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.
>
> 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
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@disroot.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/
On Sun, Jul 06, 2025 at 02:07:51AM +0000, Yao Zi wrote:
> 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.
Ah, thanks for the explanation. I'm on an old build:
U-Boot SPL 2020.01-g55b713fa (Jan 12 2024 - 02:17:34 +0000)
FM[1] lpddr4x dualrank freq=3733 64bit dbi_off=n sdram init
U-Boot 2020.01-g55b713fa (Jan 12 2024 - 02:17:34 +0000)
I would like to run mainline but I have the 8GB RAM LPi4a. Does mainline
only work for the 16GB version right now?
> 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.
Thanks, yeah, without the patch I also see:
==> c910-i0/clk_possible_parents <==
cpu-pll0 osc_24m
>
> 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.
Thanks for that fix. I now see '(missing)' for c910 too when I apply
that patch:
root@lpi4amain:/sys/kernel/debug/clk# head c910/clk_possible_parents
(missing) cpu-pll1
>
> > 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.
I think the osc_12m is good as-is but I'm not sure what Stephen will
think about using the string "c910-i0" in c910_parents[]. I think
splitting it up will make discussion go faster.
Thanks,
Drew
On Sat, Jul 05, 2025 at 09:31:29PM -0700, Drew Fustini wrote:
> On Sun, Jul 06, 2025 at 02:07:51AM +0000, Yao Zi wrote:
> > 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.
>
> Ah, thanks for the explanation. I'm on an old build:
>
> U-Boot SPL 2020.01-g55b713fa (Jan 12 2024 - 02:17:34 +0000)
> FM[1] lpddr4x dualrank freq=3733 64bit dbi_off=n sdram init
> U-Boot 2020.01-g55b713fa (Jan 12 2024 - 02:17:34 +0000)
>
> I would like to run mainline but I have the 8GB RAM LPi4a. Does mainline
> only work for the 16GB version right now?
I only tested the DRAM driver on the 16GiB version, but have seen some
working reports on the 8GiB one. Btw, the mainline U-Boot is still in an
early stage (only MMC/eMMC is working and netboot is still WIP).
> > 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.
>
> Thanks, yeah, without the patch I also see:
>
> ==> c910-i0/clk_possible_parents <==
> cpu-pll0 osc_24m
>
> >
> > 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.
>
> Thanks for that fix. I now see '(missing)' for c910 too when I apply
> that patch:
>
> root@lpi4amain:/sys/kernel/debug/clk# head c910/clk_possible_parents
> (missing) cpu-pll1
>
> >
> > > 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.
>
> I think the osc_12m is good as-is but I'm not sure what Stephen will
> think about using the string "c910-i0" in c910_parents[]. I think
> splitting it up will make discussion go faster.
Okay, I'm willing to do so.
> Thanks,
> Drew
Best regards,
Yao Zi
© 2016 - 2025 Red Hat, Inc.