Re: [PATCH v5 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:
- [Medium] The schema mandates the `qemu,trace-component` compatible string for all instances, directly contradicting the commit message's claim that component-specific strings are not needed.
- [Medium] The generic binding sets `unevaluatedProperties: false` but completely omits standard physical hardware properties such as `clocks`, `resets`, and `power-domains`.
--

--- Patch [1]: [PATCH v5 01/14] dt-bindings: Add RISC-V trace component bindings ---
commit 48aff1e54e6f77b7c90ec16a8b7b4fc01e4b287f
Author: Anup Patel <anup.patel@oss.qualcomm.com>

dt-bindings: Add RISC-V trace component bindings

This commit adds device tree bindings for memory mapped RISC-V trace components
that support both the E-trace and N-trace protocols. The commit message states
that component-specific compatible strings are not needed as the type and 
version can be discovered from the IMPL register.

> 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
> @@ -0,0 +1,120 @@
[ ... ]
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - qemu,trace-component
> +      - const: riscv,trace-component

[Severity: Medium]
The commit message states that component-specific compatible strings are not
needed, but does this schema enforce qemu,trace-component for all instances?

If a physical hardware device uses just riscv,trace-component, will it fail
schema validation because of the strict two-element array requirement defined
here?

[ ... ]
> +required:
> +  - compatible
> +  - reg
> +
> +anyOf:
> +  - required: [ in-ports ]
> +  - required: [ out-ports ]
> +
> +unevaluatedProperties: false

[Severity: Medium]
Since unevaluatedProperties is set to false, how should physical hardware
instances declare standard properties like clocks, resets, or power-domains?

Because they are omitted from the properties block above, won't the schema
validator unconditionally reject device trees that attempt to provide these
standard physical hardware properties?

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