Re: [PATCH v3 1/7] dt-bindings: clock: Introduce nexus nodes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The clock nexus node schema omits definitions and constraints for `clock-map-mask`, `clock-map-pass-thru`, and `#clock-cells`.
- [Medium] The Linux core clock framework does not support nexus node translation, making the `clock-map` property silently ignored at runtime.
--

--- Patch [1]: [PATCH v3 1/7] dt-bindings: clock: Introduce nexus nodes ---
commit 30cf1cc96ffba77a6f8ef9429e05ed6f37f38c53
Author: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>

dt-bindings: clock: Introduce nexus nodes

This commit introduces a new device tree binding for clock nexus nodes,
allowing the remapping of clock specifier lists through a container or
connector node in a generic way.

> diff --git a/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml b/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml
> new file mode 100644
> index 0000000000000..ff3283bd5fb11
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/clock-nexus-node.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Clock Nexus
> +
> +description: >
> +  A nexus node allows to remap a clock specifier list in a consumer node
> +  through a container or a connector node in a generic way. With this
> +  remapping, the consumer node needs to know only about the nexus
> +  node. Resources behind the nexus node are decoupled by the nexus node
> +  itself.

[Severity: Medium]
Does the Linux clock framework currently support traversing nexus nodes?

Looking at of_parse_clkspec() in drivers/clk/clk.c, it hardcodes a call to
of_parse_phandle_with_args():

drivers/clk/clk.c:of_parse_clkspec() {
    ...
    ret = of_parse_phandle_with_args(np, "clocks", "#clock-cells",
                                     index, out_args);
    ...
}

Because there isn't a call to of_parse_phandle_with_args_map() here, will
device tree consumers attempting to acquire a clock routed through a nexus
node fail to resolve it during driver probe?

Is there a companion patch for the clock framework to add this mapping
support?

[ ... ]

> +properties:
> +  clock-map:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +
> +dependentRequired:
> +  clock-map: ['#clock-cells']
> +
> +additionalProperties: true

[Severity: Medium]
Since this schema sets additionalProperties to true, are we missing the
definitions and constraints for #clock-cells, clock-map-mask, and
clock-map-pass-thru in the properties block?

Without defining them here, it appears device trees can use incorrectly
formatted properties for the mask and pass-through fields, and validation
will silently accept them since they are not constrained to standard
types.

Could we add these properties to ensure the schema enforces the correct
formats and dependencies?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260716-schneider-v7-2-rc1-eip201-upstream-v3-0-98454e83845c@bootlin.com?part=1