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] [day] [month] [year] [list]
Message-ID: <aIAnq5jWARhj8XuO@x1>
Date: Tue, 22 Jul 2025 17:07:07 -0700
From: Drew Fustini <fustini@...nel.org>
To: Yao Zi <ziyao@...root.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 v3] clk: thead: th1520-ap: Describe mux clocks with
 clk_mux

On Tue, Jul 22, 2025 at 08:05:36AM +0000, Yao Zi wrote:
> Mux clocks are now described with a customized ccu_mux structure
> consisting of ccu_internal and ccu_common substructures, and registered
> later with devm_clk_hw_register_mux_parent_data_table(). As this helper
> always allocates a new clk_hw structure, it's extremely hard to use mux
> clocks as parents statically by clk_hw pointers, since CCF has no
> knowledge about the clk_hw structure embedded in ccu_mux.
> 
> This scheme already causes issues for clock c910, which takes a mux
> clock, c910-i0, as a possible parent. With mainline U-Boot that
> reparents c910 to c910-i0 at boottime, c910 is considered as an orphan
> by CCF.
> 
> This patch refactors handling of mux clocks, embeds a clk_mux structure
> in ccu_mux directly. Instead of calling devm_clk_hw_register_mux_*(),
> we could register mux clocks on our own without allocating any new
> clk_hw pointer, fixing c910 clock's issue.
> 
> Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks")
> Signed-off-by: Yao Zi <ziyao@...root.org>
> ---
> 
> This replaces the second patch in v2 of series "Fix orphan clocks in
> clk-th1520-ap driver".
> 
> Note that the c910's issue cannot be reproduced with vendor U-Boot,
> which always reparents c910 to its second parent, cpu-pll1. Another way
> to confirm the bug is to examine
> /sys/kernel/debug/clk/c910/clk_possible_parents, which obviously doesn't
> match c910's definition. There's another patch[1] explaining and fixing
> the issue that the unknown parent isn't shown as "(missing)" in debugfs.

Reviewed-by: Drew Fustini <dfustini@...nel.org>

Thank you for refactoring the c910_i0 parent fix without using strings
in the parent data.

Before: 

==> /sys/kernel/debug/clk/c910/clk_possible_parents <==
osc_24m cpu-pll1

After:

==> /sys/kernel/debug/clk/c910/clk_possible_parents <==
c910-i0 cpu-pll1

The system still boots okay without clk_ignore_unused and peripherals
like serial, emmc and ethernet are functional.

Thanks,
Drew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ