[PATCH] dt-bindings: cpufreq: qcom-nvmem: Allow generic OPP tables

[PATCH] dt-bindings: cpufreq: qcom-nvmem: Allow generic OPP tables

[Varadarajan Narayanan]

The OPP table node-name pattern also matches peripheral OPP tables on
supported SoCs. However, it only handles Qualcomm CPU and level OPP
compatibles, causing unevaluatedProperties errors for generic
operating-points-v2 tables.

Reference the generic OPP binding when compatible is operating-points-v2
so these tables are validated against the appropriate schema.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
index 547265b8b118..fa9330cb3223 100644
--- a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
@@ -60,6 +60,13 @@ patternProperties:
         then:
           $ref: /schemas/opp/opp-v2-qcom-level.yaml#
 
+      - if:
+          properties:
+            compatible:
+              const: operating-points-v2
+        then:
+          $ref: /schemas/opp/opp-v2.yaml#
+
     unevaluatedProperties: false
 
 allOf:

---
base-commit: ab8eada9868faeee95f25d81d3d6fed0d1c98b78
change-id: 20261015-opp-8f55ee1c9baf

Best regards,
-- 
Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>

Re: [PATCH] dt-bindings: cpufreq: qcom-nvmem: Allow generic OPP tables

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: validation failure for array compatibles in OPP tables
--

commit e776719b7efa77cf87d1178c68ac8aa49d25b4a5
Author: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>

dt-bindings: cpufreq: qcom-nvmem: Allow generic OPP tables

This commit allows the qcom-nvmem cpufreq binding to reference the generic
OPP schema for generic operating-points-v2 tables. This attempts to fix
validation errors for peripheral OPP tables matching the OPP node-name
pattern.

> diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
> index 547265b8b118a..fa9330cb3223b 100644
> --- a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
> +++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
> @@ -60,6 +60,13 @@ patternProperties:
>          then:
>            $ref: /schemas/opp/opp-v2-qcom-level.yaml#
>  
> +      - if:
> +          properties:
> +            compatible:
> +              const: operating-points-v2

[Severity: Medium]
Will this strict match fail for fallback compatible arrays used by peripheral
OPP tables?

Peripheral OPP tables, such as GPU OPP tables placed at the root level in
various Qualcomm SoCs, frequently use string arrays for fallback. For example:

    compatible = "operating-points-v2-adreno", "operating-points-v2";

Using const enforces an exact string match, so it will fail against these
arrays. This causes the schema to skip the reference and incorrectly trigger
the unevaluatedProperties: false failure during dt_binding_check and dtbs_check.

Should this use contains with const to properly match these array fallbacks?

> +        then:
> +          $ref: /schemas/opp/opp-v2.yaml#
> +
>      unevaluatedProperties: false
>  
>  allOf:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015-opp-v1-1-f18fb6f9bae1@oss.qualcomm.com?part=1