Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Miquel Raynal" <miquel.raynal@bootlin.com>
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v10 04/10] clk: nuvoton: ma35d1: Reparent the gates correctly
Date: Thu, 15 Oct 2026 16:16:05 +0000	[thread overview]
Message-ID: <sashiko-outbox-173157@kernel.org> (raw)
In-Reply-To: <20261015-perso-ma35d1-upstream-clk-v10-4-47c97b54a809@bootlin.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] clk: nuvoton: CCAP muxes registered with 1-bit width but 4 parents
--

commit eafc7cdaf7d2454016081e967de0730635be9342
Author: Miquel Raynal <miquel.raynal@bootlin.com>

clk: nuvoton: ma35d1: Reparent the gates correctly

The clock tree is still incorrect. There are four main clocks in this
system: HXT, LXT, HIRC, LIRC. Each clock has a gate control to disable
it, and in the CCF topology, the gates should be below the clocks so
children stop ticking when gated. This commit reparents the gates under
their respective sources and all children under the gates.

> diff --git a/drivers/clk/nuvoton/clk-ma35d1.c b/drivers/clk/nuvoton/clk-ma35d1.c
> index 33b397d7b7c52..65a2691002a73 100644
> --- a/drivers/clk/nuvoton/clk-ma35d1.c
> +++ b/drivers/clk/nuvoton/clk-ma35d1.c
> @@ -74,34 +74,46 @@ static const struct clk_parent_data lxtg_parent_data[] = {
[ ... ]
>  static const int axiclk_parent_idx[] = { AXICLK_DIV2, AXICLK_DIV4 };
> -static const int ccap_parent_idx[] = { HXT, VPLL, APLL, SYSPLL };
> +static const int ccap_parent_idx[] = { HXT_GATE, VPLL, APLL, SYSPLL };

[Severity: Medium]
The ccap_parent_idx array defines 4 parent clocks (HXT_GATE, VPLL, APLL, SYSPLL).
However, CCAP0_MUX and CCAP1_MUX are registered with ma35d1_clk_mux()
using a 1-bit width:

drivers/clk/nuvoton/clk-ma35d1.c:ma35d1_clocks_probe() {
    ...
    hws[CCAP0_MUX] = ma35d1_clk_mux(dev, "ccap0_mux", clk_base + REG_CLK_CLKSEL0, 12, 1, hws,
                                    ccap_parent_idx, ARRAY_SIZE(ccap_parent_idx));
    ...
}

Since a 1-bit hardware mux field can only address 2 parents (indices 0 and 1),
will attempting to select APLL or SYSPLL result in truncation of the parent
index or a framework error, rendering those parents unusable?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015-perso-ma35d1-upstream-clk-v10-0-47c97b54a809@bootlin.com?part=4

  reply	other threads:[~2026-10-15 16:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 16:01 [PATCH v10 00/10] clk: nuvoton: ma35d1: Fix mux parenting and peripheral clock rates Miquel Raynal
2026-10-15 16:01 ` [PATCH v10 01/10] clk: nuvoton: ma35d1: Use clk_hw pointers as mux parents Miquel Raynal
2026-10-15 16:01 ` [PATCH v10 02/10] clk: nuvoton: ma35d1: Avoid possible error pointer dereferencing Miquel Raynal
2026-10-15 16:01 ` [PATCH v10 03/10] clk: nuvoton: ma35d1: Retrieve HXT/LXT from DT when possible Miquel Raynal
2026-10-15 16:01 ` [PATCH v10 04/10] clk: nuvoton: ma35d1: Reparent the gates correctly Miquel Raynal
2026-10-15 16:16   ` sashiko-bot [this message]
2026-10-15 16:01 ` [PATCH v10 05/10] clk: nuvoton: ma35d1: Use device managed helpers for fixed rate clocks Miquel Raynal
2026-10-15 16:01 ` [PATCH v10 06/10] clk: Create devm_clk_hw_register_fixed_rate_parent_hw() Miquel Raynal
2026-10-15 16:01 ` [PATCH v10 07/10] clk: nuvoton: ma35d1: Reparent SYSPLL correctly Miquel Raynal
2026-10-15 16:01 ` [PATCH v10 08/10] MAINTAINERS: Add myself as Nuvoton MA35D1 clock controller Miquel Raynal
2026-10-15 16:01 ` [PATCH v10 09/10] arm64: dts: nuvoton: ma35d1: Drop HXT clock output name Miquel Raynal
2026-10-15 16:01 ` [PATCH v10 10/10] arm64: dts: nuvoton: ma35d1: Add LXT crystal and clock-names Miquel Raynal

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=sashiko-outbox-173157@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=robh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox