Re: [PATCH v5 01/19] dt-bindings: crypto: add Rambus CryptoManager Hub

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] dt-bindings: unsatisfiable 'not: {}' compatible schema rule
- [Low] dt-bindings: missing mandatory 'examples' schema section
--

commit 3ce20b70e7ce37fd253621a799e998d6f340d240
Author: Alex Ousherovitch <aousherovitch@rambus.com>

dt-bindings: crypto: add Rambus CryptoManager Hub

Add device tree binding schema for the Rambus CryptoManager Hub (CMH)
hardware crypto accelerator.  The binding describes the parent
SoC-level node with its SIC register region and one queue@N child
node per mailbox the host owns, each carrying a reg (mailbox instance
index), an optional interrupt, VCQ ring geometry (rambus,num-slots /
rambus,slot-stride-bytes) and a rambus,cores affinity list.  Which
crypto cores are present is discovered from the SIC CORE_ENABLE
register at probe, not described in the device tree.

> diff --git a/Documentation/devicetree/bindings/crypto/rambus,cmh-v1030.yaml b/Documentation/devicetree/bindings/crypto/rambus,cmh-v1030.yaml
> new file mode 100644
> index 0000000000000..a0df35bdc371d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/rambus,cmh-v1030.yaml
[ ... ]
> +properties:
> +  compatible:
> +    items:
> +      - not: {}
> +        description: SoC-specific compatible, e.g. vendor,soc-cmh
> +      - const: rambus,cmh-v1030

[Severity: Medium]
In JSON Schema, {} is an empty schema that matches any value. Therefore,
the not: {} constraint in properties.compatible matches nothing and
evaluates to false for all inputs.

Any device tree that supplies a valid 2-element compatible string (e.g.,
"vendor,soc-cmh", "rambus,cmh-v1030") will unconditionally fail validation
via dt_binding_check.

Could this compatible constraint be modified so valid inputs can pass?

[ ... ]
> +required:
> +  - compatible
> +  - reg
> +  - "#address-cells"
> +  - "#size-cells"
> +
> +additionalProperties: false

[Severity: Low]
This schema definition completely omits the required examples section
at the end of the file.

Without an example, the kernel's dt_binding_check machinery cannot properly
validate the schema's internal logic against a simulated valid device tree
node. This effectively hides the not: {} bug from automated testing.

Can an examples section be included to enable proper schema testing?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917225929.2494111-1-aousherovitch@rambus.com?part=1