Re: [PATCH v6 01/14] dt-bindings: Add RISC-V trace component bindings

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] dt-bindings: riscv: arbitrary 8-port limitation in trace component schema
- [Low] dt-bindings: riscv: missing reciprocal remote-endpoint in trace example
--

commit cd6c17f8ffc8a03ed1ca9c2518f088b9871f8ccc
Author: Anup Patel <anup.patel@oss.qualcomm.com>

dt-bindings: Add RISC-V trace component bindings

This adds device tree bindings for the memory mapped RISC-V trace components
which support both the RISC-V efficient trace (E-trace) and Nexus-based
trace (N-trace) protocols.

> diff --git a/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml b/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml
> new file mode 100644
> index 0000000000000..bb519bc4a163e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/riscv,trace-component.yaml

[ ... ]

> +  in-ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +    patternProperties:
> +      '^port(@[0-7])?$':

[Severity: Low]
Does this unintentionally restrict the trace component schema to a maximum of 8
input ports? The commit message mentions that RISC-V trace components have an
implementation-specific directed acyclic graph style interdependency. Since the
RISC-V specification does not enforce an 8-port limit, any future or existing
SoC implementation featuring a funnel with 9 or more ports (e.g., port@8 or
port@f) will artificially fail dt-schema validation.

Could the pattern be updated to use standard hexadecimal device tree unit
addresses, such as '^port(@[0-9a-f]+)?$'?

> +        description: Input connections from RISC-V trace component
> +        $ref: /schemas/graph.yaml#/properties/port
> +
> +  out-ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +    patternProperties:
> +      '^port(@[0-7])?$':

[Severity: Low]
Similar to the in-ports property above, does this pattern artificially limit
the output connections to 8? Updating the regex to support standard hex unit
addresses would prevent validation failures for components with more than 8
output ports.

> +        description: Output connections from RISC-V trace component
> +        $ref: /schemas/graph.yaml#/properties/port

[ ... ]

> +    trace@c001000 {
> +      compatible = "qemu,trace-component", "riscv,trace-component";
> +      reg = <0xc001000 0x1000>;
> +      cpus = <&CPU0>;
> +
> +      in-ports {
> +        port {
> +          CPU0_RAMSINK_INPUT: endpoint {
> +          };

[Severity: Low]
Is there a missing reciprocal remote-endpoint property in this example node?
Standard device tree graph bindings specify that links between components must
be bidirectional when both nodes are present in the device tree.

In the example above, the encoder (trace@c000000) correctly points to the sink
by defining remote-endpoint = <&CPU0_RAMSINK_INPUT>;. However, the
corresponding ramsink endpoint (CPU0_RAMSINK_INPUT) is completely empty and
omits remote-endpoint = <&CPU0_ENCODER_OUTPUT>;. 

The kernel's of_graph API and dtc parsing tools rely on bidirectional
references to traverse the trace topology. Omitting the back-reference breaks
backward traversal and causes dtc compiler warnings for missing bidirectional
links.

> +        };
> +      };
> +    };

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001052243.3042627-1-mayuresh.chitale@oss.qualcomm.com?part=1