Re: [PATCH] clk: nuvoton: ma35d1: Use clk_hw pointers as mux parents

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing IS_ERR() check when retrieving clk_hw pointers for mux parents leads to a kernel panic if a parent clock failed to register.
--

--- Patch [1]: [PATCH] clk: nuvoton: ma35d1: Use clk_hw pointers as mux parents ---
Note: The format of this report has been altered to a free-form summary due
to automated recitation restrictions. Inline diffs are omitted.

commit cb1ab325c1866a1de7e5ffdc22cd1339fb87557f
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Subject: clk: nuvoton: ma35d1: Use clk_hw pointers as mux parents

This patch updates the MA35D1 clock provider to use direct HW clock pointers
for parent lookups instead of string-based lookups, fixing flat clock trees
and unassigned frequencies.

[Severity: High]
Could this lead to a kernel panic if a parent clock registration fails?

In drivers/clk/nuvoton/clk-ma35d1.c, within the ma35d1_clk_mux() function,
the code iterates over num_parents and assigns hws[parent_idx[i]] to the
parent_hws array.

If a preceding clock registration function (like ma35d1_reg_clk_pll or
ma35d1_clk_fixed) fails, it will return an ERR_PTR which gets stored in the
hws array. Because ma35d1_clk_mux() copies these pointers into parent_hws
without an IS_ERR check, the ERR_PTR is handed off to the clock core.

Since the common clock framework treats any non-NULL pointer as valid, won't
this result in an invalid memory dereference when clk_core_fill_parent_index()
attempts to access parent->hw->core?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813-perso-ma35d1-upstream-clk-v1-1-e78e5e6172ea@bootlin.com?part=1