From: sashiko-bot@kernel.org
To: "Miquel Raynal" <miquel.raynal@bootlin.com>
Cc: conor+dt@kernel.org, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v8 3/7] clk: nuvoton: ma35d1: Retrieve HXT/LXT from DT when possible
Date: Sun, 04 Oct 2026 20:59:03 +0000 [thread overview]
Message-ID: <20261004205903.E62F91F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20261004-perso-ma35d1-upstream-clk-v8-3-e1a106a128c0@bootlin.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] clk: nuvoton: ABI breakage by removing HXT from provider's hws array
--
commit 0466ee8e1824bb9d740e5cd18be8fe01b5d4fbe1
Author: Miquel Raynal <miquel.raynal@bootlin.com>
clk: nuvoton: ma35d1: Retrieve HXT/LXT from DT when possible
This commit modifies the clock driver to retrieve the external HXT and LXT
clocks from the device tree instead of registering them directly. It falls
back to registering LXT for backward compatibility with older device trees.
> diff --git a/drivers/clk/nuvoton/clk-ma35d1.c b/drivers/clk/nuvoton/clk-ma35d1.c
> index ceebcbd8c18b3..ed61a990870e4 100644
> --- a/drivers/clk/nuvoton/clk-ma35d1.c
> +++ b/drivers/clk/nuvoton/clk-ma35d1.c
[ ... ]
> @@ -240,12 +257,18 @@ static int ma35d1_clocks_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - hws[HXT] = ma35d1_clk_fixed("hxt", 24000000);
[Severity: Critical]
Does this unconditional removal break ABI compatibility with older device
trees?
Because HXT (index 0) is exported as a public ABI in the DT bindings,
removing its explicit registration leaves hws[HXT] as NULL in the provider's
clock array. If an existing downstream or older device tree consumer explicitly
references this clock via clocks = <&clk HXT>, won't the provider's
of_clk_hw_onecell_get() fail to resolve the clock and return an error?
> - hws[HXT_GATE] = ma35d1_clk_gate(dev, "hxt_gate", "hxt",
> - clk_base + REG_CLK_PWRCTL, 0);
> - hws[LXT] = ma35d1_clk_fixed("lxt", 32768);
> - hws[LXT_GATE] = ma35d1_clk_gate(dev, "lxt_gate", "lxt",
> - clk_base + REG_CLK_PWRCTL, 1);
> + num_clks = of_clk_get_parent_count(clk_node);
> + if (num_clks < 1 || num_clks > 2)
> + return -EINVAL;
> +
> + /* Old DTs do not describe the low-speed crystal */
> + if (num_clks == 1)
> + hws[LXT] = ma35d1_clk_fixed("lxt", 32768);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261004-perso-ma35d1-upstream-clk-v8-0-e1a106a128c0@bootlin.com?part=3
next prev parent reply other threads:[~2026-10-04 20:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-04 20:45 [PATCH v8 0/7] clk: nuvoton: ma35d1: Fix mux parenting and peripheral clock rates Miquel Raynal
2026-10-04 20:45 ` [PATCH v8 1/7] clk: nuvoton: ma35d1: Use clk_hw pointers as mux parents Miquel Raynal
2026-10-04 20:45 ` [PATCH v8 2/7] clk: nuvoton: ma35d1: Avoid possible error pointer dereferencing Miquel Raynal
2026-10-04 20:45 ` [PATCH v8 3/7] clk: nuvoton: ma35d1: Retrieve HXT/LXT from DT when possible Miquel Raynal
2026-10-04 20:59 ` sashiko-bot [this message]
2026-10-04 21:16 ` Miquel Raynal
2026-10-05 9:06 ` Jerome Brunet
2026-10-04 20:45 ` [PATCH v8 4/7] clk: nuvoton: ma35d1: Reparent the gates correctly Miquel Raynal
2026-10-04 20:45 ` [PATCH v8 5/7] clk: nuvoton: ma35d1: Reparent SYSPLL correctly Miquel Raynal
2026-10-04 20:55 ` sashiko-bot
2026-10-04 21:19 ` Miquel Raynal
2026-10-05 9:12 ` Jerome Brunet
2026-10-06 7:57 ` Miquel Raynal
2026-10-04 20:45 ` [PATCH v8 6/7] arm64: dts: nuvoton: ma35d1: Drop HXT clock output name Miquel Raynal
2026-10-04 20:45 ` [PATCH v8 7/7] 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=20261004205903.E62F91F000FF@smtp.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