[PATCH v12 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset controller

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt-bindings: clk: zte: overlapping macro indices lack controller namespaces
--

commit dca4f092e4746ba80e9fc5a9d7398c954138a93c
Author: Stefan Dösinger <stefandoesinger at gmail.com>

dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset controller

This commit introduces the matrix clock and reset controller for the ZTE
zx297520v3 SoC. It adds the bindings documentation, along with definitions
for the clock and reset indices.

> diff --git a/include/dt-bindings/clock/zte,zx297520v3-clk.h b/include/dt-bindings/clock/zte,zx297520v3-clk.h
> index 1bc9267e4d62e..d98bc38635b03 100644
> --- a/include/dt-bindings/clock/zte,zx297520v3-clk.h
> +++ b/include/dt-bindings/clock/zte,zx297520v3-clk.h
> @@ -69,4 +69,49 @@
>  #define ZX297520V3_GSM_156M			60
>  #define ZX297520V3_ABB_WCLK			61
>  
> +#define ZX297520V3_SYS_TIMER_WCLK		0
> +#define ZX297520V3_CPU_WCLK			1

[Severity: Low]
Is there a risk of unintended misconfigurations because these macros restart
the index space at 0 without a distinguishing prefix like MATRIXCRM_?

Since they overlap directly with the topcrm macros defined earlier in the
same file, both sets evaluate to identical integers (e.g., both evaluate
to 0).

Could this regression lead to a mismatched hardware configuration at runtime
if a topcrm macro is accidentally used with a matrixcrm phandle?

[ ... ]

> diff --git a/include/dt-bindings/reset/zte,zx297520v3-reset.h b/include/dt-bindings/reset/zte,zx297520v3-reset.h
> index 4a0eaec0e9816..54e5b24f859af 100644
> --- a/include/dt-bindings/reset/zte,zx297520v3-reset.h
> +++ b/include/dt-bindings/reset/zte,zx297520v3-reset.h
> @@ -27,4 +27,17 @@
>  #define ZX297520V3_USB_RESET			18
>  #define ZX297520V3_HSIC_RESET			19
>  
> +#define ZX297520V3_CPU_RESET			0
> +#define ZX297520V3_ZSP_BUS_RESET		1

[Severity: Low]
Does restarting the index space at 0 for these matrixcrm resets introduce
a similar regression risk as the clock indices?

These macros similarly lack a namespace prefix and evaluate to the same
integers as the topcrm reset macros.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923-zx29clk-v12-0-9c243796b6d2@gmail.com?part=2