Linux GPIO subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Han Gao" <gaohan@iscas.ac.cn>
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-gpio@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 03/18] dt-bindings: clock: add Zhihe A210 clock controllers
Date: Wed, 21 Oct 2026 20:04:37 +0000	[thread overview]
Message-ID: <sashiko-outbox-180623@kernel.org> (raw)
In-Reply-To: <20261022-a210-init-v1-3-5e438f972d24@iscas.ac.cn>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] dt-bindings: clock: zhihe,a210-clk: missing subsystem controller input clocks
- [Medium] dt-bindings: clock: zhihe,a210-clk: disjoint register blocks merged in one node
- [Medium] dt-bindings: clock: zhihe,a210-clk: non-clock macros and global IDs in header
--

commit f418ceaa00f70a29b9cfb989d2292f9ccba767ae
Author: Zhiguo Zhu <zhiguo.zhu@linux.alibaba.com>

dt-bindings: clock: add Zhihe A210 clock controllers

This patch adds the devicetree binding schema and clock ID header for the
Zhihe A210 SoC clock controllers.

> diff --git a/Documentation/devicetree/bindings/clock/zhihe,a210-clk.yaml b/Documentation/devicetree/bindings/clock/zhihe,a210-clk.yaml
> new file mode 100644
> index 0000000000000..a3546d2f5977c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/zhihe,a210-clk.yaml
> @@ -0,0 +1,231 @@

[ ... ]

> +  clocks:
> +    description: Input reference oscillators.
> +    minItems: 1
> +    maxItems: 3
> +
> +  clock-names:
> +    minItems: 1
> +    maxItems: 3
> +    items:
> +      enum:
> +        - osc-32k
> +        - osc-24m
> +        - rc-24m

[Severity: Medium]
In the A210 SoC clock hierarchy, zhihe,a210-clk (managing pll-wrap and
top-crg) and zhihe,a210-aon-clk generate the root PLLs, dividers, muxes, and
subsystem clock gates (such as top_cfg_aclk, uart_sclk, video_pll_foutvco,
gmac_pll_foutpostdiv, dpu0_pll_foutpostdiv, aon_osc_clk_logic, aon_rtc_clk,
npu_aclk, npu_cclk, vp_aclk, and tee_clk), which then feed the 8 subsystem
clock controllers.

In Documentation/devicetree/bindings/clock/zhihe,a210-clk.yaml, the
top-level properties:clocks and properties:clock-names definitions only allow
up to 3 external reference oscillators (osc-32k, osc-24m, rc-24m) with
maxItems: 3, and in allOf only the zhihe,a210-clk branch requires clocks and
clock-names.

Any devicetree node using one of the 8 subsystem clock controller compatible
strings (zhihe,a210-peri-clk, zhihe,a210-gpu-clk, zhihe,a210-pcie-clk,
zhihe,a210-usb-clk, zhihe,a210-vi-clk, zhihe,a210-vp-clk, zhihe,a210-vo-clk,
or zhihe,a210-npu-clk) that specifies its parent clocks from zhihe,a210-clk
or zhihe,a210-aon-clk will fail dtbs_check schema validation, while omitting
clocks leaves the hardware clock tree topology undocumented in devicetree and
forces the driver to rely on hardcoded global clock names.

How can the 8 subsystem clock controller nodes declare their upstream input
clocks in devicetree if clocks and clock-names only permit the 3 external
reference oscillators, and should each subsystem compatible in allOf specify
and require its input clocks?

[ ... ]

> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          const: zhihe,a210-clk
> +    then:
> +      properties:
> +        reg:
> +          minItems: 9
> +        reg-names:
> +          items:
> +            - const: pll-wrap
> +            - const: top-crg
> +            - const: cpu-ss-clk-sysreg
> +            - const: cpu-ss-cpu-pll
> +            - const: ddr0-sysreg
> +            - const: ddr1-sysreg
> +            - const: slc-dual-sysreg
> +            - const: top-crg-t
> +            - const: cpu-ss-ccu
> +        clocks:
> +          minItems: 3
> +        clock-names:
> +          items:
> +            - const: osc-32k
> +            - const: osc-24m
> +            - const: rc-24m
> +      required:
> +        - clocks
> +        - clock-names
> +
> +  - if:
> +      properties:
> +        compatible:
> +          const: zhihe,a210-peri-clk
> +    then:
> +      properties:
> +        reg:
> +          minItems: 5
> +          maxItems: 5
> +        reg-names:
> +          items:
> +            - const: peri0-sysreg
> +            - const: peri1-sysreg
> +            - const: peri2-sysreg
> +            - const: peri3-sysreg
> +            - const: tee-crg

[ ... ]

> +examples:
> +  - |
> +    #include <dt-bindings/clock/zhihe,a210-clk.h>
> +
> +    clock-controller@260000 {
> +        compatible = "zhihe,a210-clk";
> +        reg = <0x00260000 0x1000>,
> +              <0x00250000 0x1000>,
> +              <0x10141600 0x100>,
> +              <0x10141400 0x100>,
> +              <0x04810000 0x1000>,
> +              <0x05810000 0x1000>,
> +              <0x04900000 0x1000>,
> +              <0x20250000 0x1000>,
> +              <0x10140000 0xe00>;
> +        reg-names = "pll-wrap", "top-crg", "cpu-ss-clk-sysreg", "cpu-ss-cpu-pll",
> +                    "ddr0-sysreg", "ddr1-sysreg", "slc-dual-sysreg", "top-crg-t",
> +                    "cpu-ss-ccu";
> +        #clock-cells = <1>;
> +        clocks = <&osc_32k>, <&osc_24m>, <&rc_24m>;
> +        clock-names = "osc-32k", "osc-24m", "rc-24m";
> +    };

[Severity: Medium]
In Documentation/devicetree/bindings/clock/zhihe,a210-clk.yaml, the
allOf:zhihe,a210-clk schema and the clock-controller@260000 example node
aggregate 9 disjoint hardware register blocks across unrelated SoC
subsystems into a single devicetree node: pll-wrap (0x00260000), top-crg
(0x00250000), cpu-ss-clk-sysreg (0x10141600), cpu-ss-cpu-pll (0x10141400),
ddr0-sysreg (0x04810000), ddr1-sysreg (0x05810000), slc-dual-sysreg
(0x04900000), top-crg-t (0x20250000), and cpu-ss-ccu (0x10140000).

Similarly, allOf:zhihe,a210-peri-clk aggregates 5 separate hardware blocks
(peri0-sysreg, peri1-sysreg, peri2-sysreg, peri3-sysreg, and tee-crg) at
disjoint address ranges into a single devicetree node, even though those 5
subsystems are independent hardware blocks (and are modeled as 5 separate
nodes zhihe,a210-peri0-reset through zhihe,a210-peri3-reset and
zhihe,a210-tee-reset in the reset binding). Merging these blocks into single
virtual nodes also claims entire 0x1000 *-sysreg ranges that contain
non-clock control registers.

Should these separate hardware register blocks be modeled as individual
devicetree nodes matching the physical SoC layout instead of grouping
disjoint register ranges into zhihe,a210-clk and zhihe,a210-peri-clk?

> diff --git a/include/dt-bindings/clock/zhihe,a210-clk.h b/include/dt-bindings/clock/zhihe,a210-clk.h
> new file mode 100644
> index 0000000000000..aa59d91a9ad05
> --- /dev/null
> +++ b/include/dt-bindings/clock/zhihe,a210-clk.h
> @@ -0,0 +1,649 @@

[ ... ]

> +#define VO_PLL2_DIV_EN                                     347
> +#define VO_PLL2_DIV_NUM                                    348
> +#define VO_PLL1_DIV_EN                                     349
> +#define VO_PLL1_DIV_NUM                                    350
> +#define VO_PLL0_DIV_EN                                     351
> +#define VO_PLL0_DIV_NUM                                    352

[ ... ]

> +#define CLK_DUMMY                                          505
> +#define OSC_32K                                            506
> +#define OSC_24M                                            507
> +#define RC_24M                                             508

[ ... ]

> +#define CLK_END 590
> +
> +#endif

[Severity: Medium]
In include/dt-bindings/clock/zhihe,a210-clk.h, all 9 clock controller
compatibles share a single interleaved global 0..589 ID space rather than
per-controller 0-based clock IDs, which requires every controller instance in
drivers/clk/zhihe/clk-a210-ap.c to allocate a 590-entry clk_hw_onecell_data
array.

In the VI_SYSREG, VO_SYSREG, and VP_SYSREG sections, hardware divider enable
bits and divider ratio bitfields of the same composite divider clock are
exposed as separate clock IDs (for example, VI_PRE_ISP_CORE_CLK_DIV_EN and
VI_PRE_ISP_CORE_CLK_DIV_NUM, VO_PLL0_DIV_EN and VO_PLL0_DIV_NUM, and
VP_DECOMP_DIV_EN and VP_DECOMP_DIV_NUM). In drivers/clk/zhihe/clk-a210-ap.c,
only the *_DIV_NUM IDs are registered as composite dividers (using the
corresponding *_DIV_EN bit as the gate bit), leaving all 16 *_DIV_EN macros
as unused register-bitfield definitions in the devicetree ABI header.

Additionally, CLK_DUMMY is a software driver implementation artifact,
OSC_32K, OSC_24M, and RC_24M are external input reference clocks passed via
the clocks property rather than outputs of the clock controller, and CLK_END
is an internal array bound whose value changes whenever new clock IDs are
added, breaking devicetree binding ABI invariance.

Could CLK_END, CLK_DUMMY, OSC_32K, OSC_24M, RC_24M, and the unused *_DIV_EN
bitfield macros be dropped from include/dt-bindings/clock/zhihe,a210-clk.h,
and should each clock controller define its own 0-based clock IDs?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261022-a210-init-v1-0-5e438f972d24@iscas.ac.cn?part=3

  reply	other threads:[~2026-10-21 20:04 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 19:53 [PATCH 00/18] riscv: add initial support for Zhihe A210 and Melon Pi Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 01/18] dt-bindings: vendor-prefixes: add Zhihe Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 02/18] riscv: add Zhihe A210 support Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 03/18] dt-bindings: clock: add Zhihe A210 clock controllers Han Gao via B4 Relay
2026-10-21 20:04   ` sashiko-bot [this message]
2026-10-22 18:52   ` Conor Dooley
2026-10-21 19:53 ` [PATCH 04/18] dt-bindings: clock: add Zhihe A210 AON clock controller Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 05/18] clk: zhihe: add A210 support Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 06/18] dt-bindings: reset: add Zhihe A210 reset controllers Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 07/18] reset: zhihe: add A210 support Han Gao via B4 Relay
2026-10-22  9:22   ` Philipp Zabel
2026-10-21 19:53 ` [PATCH 08/18] dt-bindings: pinctrl: add Zhihe A210 pin controller Han Gao via B4 Relay
2026-10-22 19:01   ` Conor Dooley
2026-10-21 19:53 ` [PATCH 09/18] pinctrl: zhihe: add A210 support Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 10/18] dt-bindings: interrupt-controller: add Zhihe A210 PLIC Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 11/18] dt-bindings: riscv: add Melon Pi V1 and V2 Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 12/18] dt-bindings: timer: add Zhihe A210 CLINT Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 13/18] riscv: dts: zhihe: add A210 core support Han Gao via B4 Relay
2026-10-22 18:48   ` Conor Dooley
2026-10-21 19:53 ` [PATCH 14/18] riscv: dts: zhihe: add A210 UARTs Han Gao via B4 Relay
2026-10-22  9:22   ` Philipp Zabel
2026-10-21 19:53 ` [PATCH 15/18] riscv: dts: zhihe: add A210 module memory Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 16/18] riscv: dts: zhihe: add Melon Pi V1 and V2 Han Gao via B4 Relay
2026-10-21 19:53 ` [PATCH 17/18] riscv: defconfig: enable A210 support Han Gao via B4 Relay
2026-10-22 18:50   ` Conor Dooley
2026-10-21 19:53 ` [PATCH 18/18] MAINTAINERS: add Zhihe A210 Han Gao via B4 Relay
  -- strict thread matches above, loose matches on Subject: below --
2026-10-21 19:48 [PATCH 00/18] riscv: add initial support for Zhihe A210 and Melon Pi Han Gao
2026-10-21 19:48 ` [PATCH 03/18] dt-bindings: clock: add Zhihe A210 clock controllers Han Gao

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-180623@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gaohan@iscas.ac.cn \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --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