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

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] The clock-nexus-node schema omits definitions for standard nexus node properties `clock-map-mask`, `clock-map-pass-thru`, and `#clock-cells`, breaking schema validation.

Pre-existing issues:
- [High] The Linux clock subsystem lacks support for nexus node parsing, rendering this device tree binding unusable for Linux drivers.
--

--- Patch [1]: [PATCH v5 1/7] dt-bindings: clock: Introduce nexus nodes ---
commit 0bad30dd59cfc8ff93ceabdefc7264eea3d9d045
Author: Miquel Raynal (Schneider Electric) <[email protected]>

dt-bindings: clock: Introduce nexus nodes

Hardware containers can just decouple external resources like clock
without any more control. Nexus nodes already exist for PWM and GPIOs,
add a binding to allow them for clocks as well.

> 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
[ ... ]
> +select: true
> +
> +properties:
> +  clock-map:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix

[Severity: High]
This isn't a bug introduced by this patch, but does the core clock framework
actually support nexus node parsing yet?

Looking at drivers/clk/clk.c:of_parse_clkspec():

	ret = of_parse_phandle_with_args(np, "clocks", "#clock-cells",
					 index, out_args);

It appears the core clock framework uses of_parse_phandle_with_args() instead
of of_parse_phandle_with_args_map().

If a device tree author configures a clock-map and a consumer driver attempts
to request the mapped clock, wouldn't the clock subsystem incorrectly return
the nexus node itself as the provider instead of mapping to the underlying
clock provider?

> +
> +dependentRequired:
> +  clock-map: ['#clock-cells']

[Severity: Medium]
Are we missing definitions for standard nexus node properties here?

The properties block omits clock-map-mask, clock-map-pass-thru, and
#clock-cells. Since additionalProperties is true, any device tree nodes using
clock-map-mask or clock-map-pass-thru will bypass type validation.

Should #clock-cells be included and constrained in the properties block as
dictated by subsystem guidelines for providers?

> +
> +additionalProperties: true
> +
> +# See the original pwm-nexus-node.yaml description for examples

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-schneider-v7-2-rc1-eip201-upstream-v5-0-8785f9531cf0@bootlin.com?part=1