[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

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

[Krzysztof Kozlowski]

On Thu, Oct 15, 2026 at 04:25:28PM +0530, Varadarajan Narayanan wrote:
> 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.

But the select should not select them. How can I reproduce the issue?

Best regards,
Krzysztof

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

[Varadarajan Narayanan]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On Sat, Oct 17, 2026 at 06:45:53PM +0200, Krzysztof Kozlowski wrote:
> On Thu, Oct 15, 2026 at 04:25:28PM +0530, Varadarajan Narayanan wrote:
> > 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.
>
> But the select should not select them. How can I reproduce the issue?

Sorry for the delay, it was a long weekend here.

With the attached patch, I get the following error.

$ make LLVM=-18 ARCH=arm64 CHECK_DTBS=1 qcom/ipq5210-rdp504.dtb
[...]
  DTC [C] arch/arm64/boot/dts/qcom/ipq5210-rdp504.dtb
arch/arm64/boot/dts/qcom/ipq5210-rdp504.dtb: / (qcom,ipq5210-rdp504): opp-table-qup32mhz: Unevaluated properties are not allowed ('compatible', 'opp-32000000' were unexpected)
        from schema $id: http://devicetree.org/schemas/cpufreq/qcom-cpufreq-nvmem.yaml

Thanks
Varada

[-- Attachment #2: 0001-arm64-dts-qcom-ipq5210-Add-I2C-nodes.patch --]
[-- Type: text/x-diff, Size: 3293 bytes --]

From d207f72fc23fb328aa2c3cbe1f98780667f7bf10 Mon Sep 17 00:00:00 2001
From: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
Date: Fri, 16 Oct 2026 14:24:54 +0530
Subject: [PATCH] arm64: dts: qcom: ipq5210: Add I2C nodes

Add the QUPv3 I2C controller nodes for IPQ5210 and enable I2C0 with
the required pin configuration on RDP504.

Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
---
 .../boot/dts/qcom/ipq5210-rdp504-common.dtsi  | 16 +++++++
 arch/arm64/boot/dts/qcom/ipq5210.dtsi         | 47 +++++++++++++++++++
 2 files changed, 63 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/ipq5210-rdp504-common.dtsi b/arch/arm64/boot/dts/qcom/ipq5210-rdp504-common.dtsi
index b32daa7c1559..8068dd0d2119 100644
--- a/arch/arm64/boot/dts/qcom/ipq5210-rdp504-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq5210-rdp504-common.dtsi
@@ -59,6 +59,13 @@ vreg_misc_0p925: regulator-usb-0p925 {
 	};
 };
 
+&i2c0 {
+	pinctrl-0 = <&qup_i2c0_default>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
 &pcie0 {
 	pinctrl-0 = <&pcie0_default_state>;
 	pinctrl-names = "default";
@@ -191,6 +198,15 @@ clock-pins {
 		};
 	};
 
+	qup_i2c0_default: qup-i2c0-default-state {
+		qup-i2c0-pins {
+			pins = "gpio20", "gpio21";
+			function = "qup_se2";
+			drive-strength = <6>;
+			bias-pull-up;
+		};
+	};
+
 	qup_uart1_default_state: qup-uart1-default-state {
 		pins = "gpio38", "gpio39";
 		function = "qup_se1";
diff --git a/arch/arm64/boot/dts/qcom/ipq5210.dtsi b/arch/arm64/boot/dts/qcom/ipq5210.dtsi
index 6842ac21e05f..80050845f965 100644
--- a/arch/arm64/boot/dts/qcom/ipq5210.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq5210.dtsi
@@ -160,6 +160,14 @@ opp-300000000 {
 		};
 	};
 
+	i2c_opp_table_32mhz: opp-table-qup32mhz {
+		compatible = "operating-points-v2";
+
+		opp-32000000 {
+			opp-hz = /bits/ 64 <32000000>;
+		};
+	};
+
 	pmu {
 		compatible = "arm,cortex-a53-pmu";
 		interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
@@ -435,6 +443,45 @@ uart1: serial@1a84000 {
 
 				status = "disabled";
 			};
+
+			i2c0: i2c@1a88000 {
+				compatible = "qcom,geni-i2c";
+				reg = <0x0 0x01a88000 0x0 0x4000>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				clocks = <&gcc GCC_QUPV3_WRAP_SE2_CLK>;
+				clock-names = "se";
+				clock-frequency = <400000>;
+				interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+				operating-points-v2 = <&i2c_opp_table_32mhz>;
+				status = "disabled";
+			};
+
+			i2c1: i2c@1a8c000 {
+				compatible = "qcom,geni-i2c";
+				reg = <0x0 0x01a8c000 0x0 0x4000>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				clocks = <&gcc GCC_QUPV3_WRAP_SE3_CLK>;
+				clock-names = "se";
+				clock-frequency = <400000>;
+				interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
+				operating-points-v2 = <&i2c_opp_table_32mhz>;
+				status = "disabled";
+			};
+
+			i2c2: i2c@1a94000 {
+				compatible = "qcom,geni-i2c";
+				reg = <0x0 0x01a94000 0x0 0x4000>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				clocks = <&gcc GCC_QUPV3_WRAP_SE5_CLK>;
+				clock-names = "se";
+				clock-frequency = <400000>;
+				interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+				operating-points-v2 = <&i2c_opp_table_32mhz>;
+				status = "disabled";
+			};
 		};
 
 		sdhc: mmc@7804000 {
-- 
2.34.1

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

[Krzysztof Kozlowski]

On 21/10/2026 07:38, Varadarajan Narayanan wrote:
> On Sat, Oct 17, 2026 at 06:45:53PM +0200, Krzysztof Kozlowski wrote:
>> On Thu, Oct 15, 2026 at 04:25:28PM +0530, Varadarajan Narayanan wrote:
>>> 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.
>>
>> But the select should not select them. How can I reproduce the issue?
> 
> Sorry for the delay, it was a long weekend here.
> 
> With the attached patch, I get the following error.
> 

Does not apply, but exactly that sort of opp-table is already all over
the tree. Just check yourself.

Best regards,
Krzysztof

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

[Varadarajan Narayanan]

On Wed, Oct 21, 2026 at 08:17:36AM +0200, Krzysztof Kozlowski wrote:
> On 21/10/2026 07:38, Varadarajan Narayanan wrote:
> > On Sat, Oct 17, 2026 at 06:45:53PM +0200, Krzysztof Kozlowski wrote:
> >> On Thu, Oct 15, 2026 at 04:25:28PM +0530, Varadarajan Narayanan wrote:
> >>> 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.
> >>
> >> But the select should not select them. How can I reproduce the issue?
> >
> > Sorry for the delay, it was a long weekend here.
> >
> > With the attached patch, I get the following error.
> >
> Does not apply,

Sorry. Have rebased to next-20261020 and attached, please see.

> but exactly that sort of opp-table is already all over the tree. Just
> check yourself.

From what I see, SoCs that don't use operating-points-v2-kryo-cpu for the
CPU's opp table don't face an issue. Since ipq5210's CPU opp table's
compatible is operating-points-v2-kryo-cpu, it is facing this unevaluated
properties error.

The qcom-cpufreq-nvmem.yaml change is approved in [1]. And the change to
ipq5210.dtsi is to address the feedback in [2].

Thanks
Varada

1 - https://lore.kernel.org/linux-arm-msm/20260703-lively-intelligent-raptor-5edfbf@quoll/
2 - https://lore.kernel.org/linux-arm-msm/06e6868a-c106-40b1-85fb-5ebbc01eff16@oss.qualcomm.com/

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

[Varadarajan Narayanan]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

On Wed, Oct 21, 2026 at 02:10:10PM +0530, Varadarajan Narayanan wrote:
> On Wed, Oct 21, 2026 at 08:17:36AM +0200, Krzysztof Kozlowski wrote:
> > On 21/10/2026 07:38, Varadarajan Narayanan wrote:
> > > On Sat, Oct 17, 2026 at 06:45:53PM +0200, Krzysztof Kozlowski wrote:
> > >> On Thu, Oct 15, 2026 at 04:25:28PM +0530, Varadarajan Narayanan wrote:
> > >>> 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.
> > >>
> > >> But the select should not select them. How can I reproduce the issue?
> > >
> > > Sorry for the delay, it was a long weekend here.
> > >
> > > With the attached patch, I get the following error.
> > >
> > Does not apply,
>
> Sorry. Have rebased to next-20261020 and attached, please see.
>
> > but exactly that sort of opp-table is already all over the tree. Just
> > check yourself.
>
> From what I see, SoCs that don't use operating-points-v2-kryo-cpu for the
> CPU's opp table don't face an issue. Since ipq5210's CPU opp table's
> compatible is operating-points-v2-kryo-cpu, it is facing this unevaluated
> properties error.
>
> The qcom-cpufreq-nvmem.yaml change is approved in [1]. And the change to
> ipq5210.dtsi is to address the feedback in [2].
>
> Thanks
> Varada
>
> 1 - https://lore.kernel.org/linux-arm-msm/20260703-lively-intelligent-raptor-5edfbf@quoll/
> 2 - https://lore.kernel.org/linux-arm-msm/06e6868a-c106-40b1-85fb-5ebbc01eff16@oss.qualcomm.com/


Forgot the attachment... Added now.

[-- Attachment #2: krzysztof-unevaluated-properties.patch --]
[-- Type: text/x-diff, Size: 2386 bytes --]

diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
index 547265b8b118..2f5dbb59034c 100644
--- a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml
@@ -27,6 +27,7 @@ select:
         enum:
           - qcom,apq8064
           - qcom,apq8096
+          - qcom,ipq5210
           - qcom,ipq5332
           - qcom,ipq6018
           - qcom,ipq8064
diff --git a/arch/arm64/boot/dts/qcom/ipq5210.dtsi b/arch/arm64/boot/dts/qcom/ipq5210.dtsi
index 2cdc10529c48..b8172f6f1030 100644
--- a/arch/arm64/boot/dts/qcom/ipq5210.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq5210.dtsi
@@ -84,6 +84,14 @@ memory@80000000 {
 		reg = <0x0 0x80000000 0x0 0x0>;
 	};
 
+	i2c_opp_table_32mhz: opp-table-qup32mhz {
+		compatible = "operating-points-v2";
+
+		opp-32000000 {
+			opp-hz = /bits/ 64 <32000000>;
+		};
+	};
+
 	pmu {
 		compatible = "arm,cortex-a53-pmu";
 		interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
@@ -179,6 +187,45 @@ uart1: serial@1a84000 {
 
 				status = "disabled";
 			};
+
+			i2c0: i2c@1a88000 {
+				compatible = "qcom,geni-i2c";
+				reg = <0x0 0x01a88000 0x0 0x4000>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				clocks = <&gcc GCC_QUPV3_WRAP_SE2_CLK>;
+				clock-names = "se";
+				clock-frequency = <400000>;
+				interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+				operating-points-v2 = <&i2c_opp_table_32mhz>;
+				status = "disabled";
+			};
+
+			i2c1: i2c@1a8c000 {
+				compatible = "qcom,geni-i2c";
+				reg = <0x0 0x01a8c000 0x0 0x4000>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				clocks = <&gcc GCC_QUPV3_WRAP_SE3_CLK>;
+				clock-names = "se";
+				clock-frequency = <400000>;
+				interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>;
+				operating-points-v2 = <&i2c_opp_table_32mhz>;
+				status = "disabled";
+			};
+
+			i2c2: i2c@1a94000 {
+				compatible = "qcom,geni-i2c";
+				reg = <0x0 0x01a94000 0x0 0x4000>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				clocks = <&gcc GCC_QUPV3_WRAP_SE5_CLK>;
+				clock-names = "se";
+				clock-frequency = <400000>;
+				interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+				operating-points-v2 = <&i2c_opp_table_32mhz>;
+				status = "disabled";
+			};
 		};
 
 		sdhc: mmc@7804000 {

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

[Krzysztof Kozlowski]

On 21/10/2026 07:38, Varadarajan Narayanan wrote:
> On Sat, Oct 17, 2026 at 06:45:53PM +0200, Krzysztof Kozlowski wrote:
>> On Thu, Oct 15, 2026 at 04:25:28PM +0530, Varadarajan Narayanan wrote:
>>> 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.
>>
>> But the select should not select them. How can I reproduce the issue?
> 
> Sorry for the delay, it was a long weekend here.
> 
> With the attached patch, I get the following error.
> 
> $ make LLVM=-18 ARCH=arm64 CHECK_DTBS=1 qcom/ipq5210-rdp504.dtb

OK, I can reproduce. I wonder why do we need qcom-cpufreq-nvmem.yaml in
the first place. It duplicates top level compatibles and opp
compatibles. For qcom,qcs404 it does something useful - enforces cpu
power supplies. But for others?

Best regards,
Krzysztof

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

[Varadarajan Narayanan]

On Tue, Oct 27, 2026 at 04:50:56PM +0100, Krzysztof Kozlowski wrote:
> On 21/10/2026 07:38, Varadarajan Narayanan wrote:
> > On Sat, Oct 17, 2026 at 06:45:53PM +0200, Krzysztof Kozlowski wrote:
> >> On Thu, Oct 15, 2026 at 04:25:28PM +0530, Varadarajan Narayanan wrote:
> >>> 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.
> >>
> >> But the select should not select them. How can I reproduce the issue?
> >
> > Sorry for the delay, it was a long weekend here.
> >
> > With the attached patch, I get the following error.
> >
> > $ make LLVM=-18 ARCH=arm64 CHECK_DTBS=1 qcom/ipq5210-rdp504.dtb
>
> OK, I can reproduce. I wonder why do we need qcom-cpufreq-nvmem.yaml in
> the first place. It duplicates top level compatibles and opp
> compatibles. For qcom,qcs404 it does something useful - enforces cpu
> power supplies. But for others?

CPR capable SoCs are added to this bindings file. Not sure if all of the
SoCs present here are CPR capable. Will have to check. However, CPR
capable SoC like IPQ9650 might need this and will face the same issue when
I2C or SPI opp tables are added.

Kindly advice how to proceed.

Thanks
Varada