[PATCH 0/3] dt-bindings: arm: cpus: Extend Qualcomm Oryon compatibles

[PATCH 0/3] dt-bindings: arm: cpus: Extend Qualcomm Oryon compatibles

[Sibi Sankar]

The generic Qualcomm Oryon CPU compatible documented in the binding
doesn't account for differences between core types and has been
deprecated. Introduce core-specific compatibles, based on MIDR part and
variant numbers.

Glymur:
MIDR_EL1[PART_NUM] - 0x2
MIDR_EL1[VARIANT] - 0x1/0x2

Kaanapali:
MIDR_EL1[PART_NUM] - 0x2
MIDR_EL1[VARIANT] - 0x2/0x3

Sibi Sankar (3):
  dt-bindings: arm: cpus: Extend Qualcomm Oryon compatibles
  arm64: dts: qcom: glymur: Fix deprecated cpu compatibles
  arm64: dts: qcom: kaanapali: Fix deprecated cpu compatibles

 .../devicetree/bindings/arm/cpus.yaml         |  7 ++++
 arch/arm64/boot/dts/qcom/glymur.dtsi          | 36 +++++++++----------
 arch/arm64/boot/dts/qcom/kaanapali.dtsi       | 16 ++++-----
 3 files changed, 33 insertions(+), 26 deletions(-)


base-commit: a0ae2a256046c0c5d3778d1a194ff2e171f16e5f
-- 
2.34.1

[PATCH 1/3] dt-bindings: arm: cpus: Extend Qualcomm Oryon compatibles

[Sibi Sankar]

The generic Qualcomm Oryon CPU compatible documented in the binding
doesn't account for differences between core types and has been
deprecated. Introduce core-specific compatibles, based on MIDR part and
variant numbers.

Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/arm/cpus.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
index 700255e9a002..fb6e5871b625 100644
--- a/Documentation/devicetree/bindings/arm/cpus.yaml
+++ b/Documentation/devicetree/bindings/arm/cpus.yaml
@@ -218,6 +218,13 @@ properties:
           - qcom,kryo685
           - qcom,kryo780
           - qcom,scorpion
+          - qcom,oryon-1-1
+          - qcom,oryon-1-2
+          - qcom,oryon-1-3
+          - qcom,oryon-1-4
+          - qcom,oryon-2-1
+          - qcom,oryon-2-2
+          - qcom,oryon-2-3
           - samsung,mongoose-m2
           - samsung,mongoose-m3
           - samsung,mongoose-m5
-- 
2.34.1

Re: [PATCH 1/3] dt-bindings: arm: cpus: Extend Qualcomm Oryon compatibles

[Krzysztof Kozlowski]

On Tue, Mar 10, 2026 at 09:37:49AM +0530, Sibi Sankar wrote:
> The generic Qualcomm Oryon CPU compatible documented in the binding
> doesn't account for differences between core types and has been
> deprecated. Introduce core-specific compatibles, based on MIDR part and
> variant numbers.

What do the "-x-y" stand for? What are their meanings? Your commit msg
or comment in the file should explain that briefly.

> 
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/arm/cpus.yaml | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
> index 700255e9a002..fb6e5871b625 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.yaml
> +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
> @@ -218,6 +218,13 @@ properties:
>            - qcom,kryo685
>            - qcom,kryo780
>            - qcom,scorpion
> +          - qcom,oryon-1-1
> +          - qcom,oryon-1-2
> +          - qcom,oryon-1-3
> +          - qcom,oryon-1-4
> +          - qcom,oryon-2-1

Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: arm: cpus: Extend Qualcomm Oryon compatibles

[Sibi Sankar]

On 3/11/2026 3:33 PM, Krzysztof Kozlowski wrote:
> On Tue, Mar 10, 2026 at 09:37:49AM +0530, Sibi Sankar wrote:
>> The generic Qualcomm Oryon CPU compatible documented in the binding
>> doesn't account for differences between core types and has been
>> deprecated. Introduce core-specific compatibles, based on MIDR part and
>> variant numbers.
> What do the "-x-y" stand for? What are their meanings? Your commit msg
> or comment in the file should explain that briefly.

Thanks for taking time to review the series :)

-x-y stand for -MIDR_EL1[PART_NUM]-MIDR_EL1[VARIANT]. Will add it
to the commit message.

>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>> ---
>>   Documentation/devicetree/bindings/arm/cpus.yaml | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml
>> index 700255e9a002..fb6e5871b625 100644
>> --- a/Documentation/devicetree/bindings/arm/cpus.yaml
>> +++ b/Documentation/devicetree/bindings/arm/cpus.yaml
>> @@ -218,6 +218,13 @@ properties:
>>             - qcom,kryo685
>>             - qcom,kryo780
>>             - qcom,scorpion
>> +          - qcom,oryon-1-1
>> +          - qcom,oryon-1-2
>> +          - qcom,oryon-1-3
>> +          - qcom,oryon-1-4
>> +          - qcom,oryon-2-1
> Best regards,
> Krzysztof
>

[PATCH 2/3] arm64: dts: qcom: glymur: Fix deprecated cpu compatibles

[Sibi Sankar]

The generic Qualcomm Oryon CPU compatible used by the Glymur
SoC is deprecated and incorrect since it uses a single compatible
to describe two different core variants. It is now replaced with
two different core-specific compatibles based on MIDR part and
variant number.

CPUS 0-5:
MIDR_EL1[PART_NUM] - 0x2
MIDR_EL1[VARIANT] - 0x2

CPUS 6-17:
MIDR_EL1[PART_NUM] - 0x2
MIDR_EL1[VARIANT] - 0x1

Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi")
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/glymur.dtsi | 36 ++++++++++++++--------------
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index e269cec7942c..5de4b2801321 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -33,7 +33,7 @@ cpus {
 
 		cpu0: cpu@0 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x0>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd0>, <&scmi_perf 0>;
@@ -49,7 +49,7 @@ l2_0: l2-cache {
 
 		cpu1: cpu@100 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x100>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd1>, <&scmi_perf 0>;
@@ -59,7 +59,7 @@ cpu1: cpu@100 {
 
 		cpu2: cpu@200 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x200>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd2>, <&scmi_perf 0>;
@@ -69,7 +69,7 @@ cpu2: cpu@200 {
 
 		cpu3: cpu@300 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x300>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd3>, <&scmi_perf 0>;
@@ -79,7 +79,7 @@ cpu3: cpu@300 {
 
 		cpu4: cpu@400 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x400>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd4>, <&scmi_perf 0>;
@@ -89,7 +89,7 @@ cpu4: cpu@400 {
 
 		cpu5: cpu@500 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x500>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd5>, <&scmi_perf 0>;
@@ -99,7 +99,7 @@ cpu5: cpu@500 {
 
 		cpu6: cpu@10000 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x10000>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd6>, <&scmi_perf 1>;
@@ -115,7 +115,7 @@ l2_1: l2-cache {
 
 		cpu7: cpu@10100 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x10100>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd7>, <&scmi_perf 1>;
@@ -125,7 +125,7 @@ cpu7: cpu@10100 {
 
 		cpu8: cpu@10200 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x10200>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd8>, <&scmi_perf 1>;
@@ -135,7 +135,7 @@ cpu8: cpu@10200 {
 
 		cpu9: cpu@10300 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x10300>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd9>, <&scmi_perf 1>;
@@ -145,7 +145,7 @@ cpu9: cpu@10300 {
 
 		cpu10: cpu@10400 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x10400>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd10>, <&scmi_perf 1>;
@@ -155,7 +155,7 @@ cpu10: cpu@10400 {
 
 		cpu11: cpu@10500 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x10500>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd11>, <&scmi_perf 1>;
@@ -165,7 +165,7 @@ cpu11: cpu@10500 {
 
 		cpu12: cpu@20000 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x20000>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd12>, <&scmi_perf 2>;
@@ -181,7 +181,7 @@ l2_2: l2-cache {
 
 		cpu13: cpu@20100 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x20100>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd13>, <&scmi_perf 2>;
@@ -191,7 +191,7 @@ cpu13: cpu@20100 {
 
 		cpu14: cpu@20200 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x20200>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd14>, <&scmi_perf 2>;
@@ -201,7 +201,7 @@ cpu14: cpu@20200 {
 
 		cpu15: cpu@20300 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x20300>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd15>, <&scmi_perf 2>;
@@ -211,7 +211,7 @@ cpu15: cpu@20300 {
 
 		cpu16: cpu@20400 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x20400>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd16>, <&scmi_perf 2>;
@@ -221,7 +221,7 @@ cpu16: cpu@20400 {
 
 		cpu17: cpu@20500 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-1";
 			reg = <0x0 0x20500>;
 			enable-method = "psci";
 			power-domains = <&cpu_pd17>, <&scmi_perf 2>;
-- 
2.34.1

[PATCH 3/3] arm64: dts: qcom: kaanapali: Fix deprecated cpu compatibles

[Sibi Sankar]

The generic Qualcomm Oryon CPU compatible used by the Kaanapali
SoC is deprecated and incorrect since it uses a single compatible
to describe two different core variants. It is now replaced with
two different core-specific compatibles based on MIDR part and
variant number.

CPUS 0-5:
MIDR_EL1[PART_NUM] - 0x2
MIDR_EL1[VARIANT] - 0x2

CPUS 6-7:
MIDR_EL1[PART_NUM] - 0x2
MIDR_EL1[VARIANT] - 0x3

Fixes: 2eeb5767d53f ("arm64: dts: qcom: Introduce Kaanapali SoC")
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/kaanapali.dtsi | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 9ef57ad0ca71..40b9a5953d39 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -31,7 +31,7 @@ cpus {
 
 		cpu0: cpu@0 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x0>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
@@ -48,7 +48,7 @@ l2_0: l2-cache {
 
 		cpu1: cpu@100 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x100>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
@@ -59,7 +59,7 @@ cpu1: cpu@100 {
 
 		cpu2: cpu@200 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x200>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
@@ -70,7 +70,7 @@ cpu2: cpu@200 {
 
 		cpu3: cpu@300 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x300>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
@@ -81,7 +81,7 @@ cpu3: cpu@300 {
 
 		cpu4: cpu@400 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x400>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
@@ -92,7 +92,7 @@ cpu4: cpu@400 {
 
 		cpu5: cpu@500 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-2";
 			reg = <0x0 0x500>;
 			enable-method = "psci";
 			next-level-cache = <&l2_0>;
@@ -103,7 +103,7 @@ cpu5: cpu@500 {
 
 		cpu6: cpu@10000 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-3";
 			reg = <0x0 0x10000>;
 			enable-method = "psci";
 			next-level-cache = <&l2_1>;
@@ -120,7 +120,7 @@ l2_1: l2-cache {
 
 		cpu7: cpu@10100 {
 			device_type = "cpu";
-			compatible = "qcom,oryon";
+			compatible = "qcom,oryon-2-3";
 			reg = <0x0 0x10100>;
 			enable-method = "psci";
 			next-level-cache = <&l2_1>;
-- 
2.34.1

Re: [PATCH 3/3] arm64: dts: qcom: kaanapali: Fix deprecated cpu compatibles

[Krzysztof Kozlowski]

On Tue, Mar 10, 2026 at 09:37:51AM +0530, Sibi Sankar wrote:
> The generic Qualcomm Oryon CPU compatible used by the Kaanapali
> SoC is deprecated and incorrect since it uses a single compatible
> to describe two different core variants. It is now replaced with
> two different core-specific compatibles based on MIDR part and
> variant number.
> 
> CPUS 0-5:
> MIDR_EL1[PART_NUM] - 0x2
> MIDR_EL1[VARIANT] - 0x2
> 
> CPUS 6-7:
> MIDR_EL1[PART_NUM] - 0x2
> MIDR_EL1[VARIANT] - 0x3
> 
> Fixes: 2eeb5767d53f ("arm64: dts: qcom: Introduce Kaanapali SoC")
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

I explained you in off-list communication what you have to do - this
MUST go via fixes and you MUST annotate that.

Where did you describe that? Nothing in cover letter, nothing here.

Best regards,
Krzysztof

Re: [PATCH 3/3] arm64: dts: qcom: kaanapali: Fix deprecated cpu compatibles

[Krzysztof Kozlowski]

On 11/03/2026 11:04, Krzysztof Kozlowski wrote:
> On Tue, Mar 10, 2026 at 09:37:51AM +0530, Sibi Sankar wrote:
>> The generic Qualcomm Oryon CPU compatible used by the Kaanapali
>> SoC is deprecated and incorrect since it uses a single compatible
>> to describe two different core variants. It is now replaced with
>> two different core-specific compatibles based on MIDR part and
>> variant number.
>>
>> CPUS 0-5:
>> MIDR_EL1[PART_NUM] - 0x2
>> MIDR_EL1[VARIANT] - 0x2
>>
>> CPUS 6-7:
>> MIDR_EL1[PART_NUM] - 0x2
>> MIDR_EL1[VARIANT] - 0x3
>>
>> Fixes: 2eeb5767d53f ("arm64: dts: qcom: Introduce Kaanapali SoC")
>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> 
> I explained you in off-list communication what you have to do - this
> MUST go via fixes and you MUST annotate that.
> 
> Where did you describe that? Nothing in cover letter, nothing here.

Although then binding should go via fixes but it depends on patch in
next branch, so it cannot be done. Sorry, this waited way tooooo long,
so you cannot make this change anymore.

Please drop it and you are stuck with the compatible you sent earlier,
which reviewers requested multiple times to change.

Best regards,
Krzysztof

Re: [PATCH 3/3] arm64: dts: qcom: kaanapali: Fix deprecated cpu compatibles

[Sibi Sankar]

On 3/11/2026 3:51 PM, Krzysztof Kozlowski wrote:
> On 11/03/2026 11:04, Krzysztof Kozlowski wrote:
>> On Tue, Mar 10, 2026 at 09:37:51AM +0530, Sibi Sankar wrote:
>>> The generic Qualcomm Oryon CPU compatible used by the Kaanapali
>>> SoC is deprecated and incorrect since it uses a single compatible
>>> to describe two different core variants. It is now replaced with
>>> two different core-specific compatibles based on MIDR part and
>>> variant number.
>>>
>>> CPUS 0-5:
>>> MIDR_EL1[PART_NUM] - 0x2
>>> MIDR_EL1[VARIANT] - 0x2
>>>
>>> CPUS 6-7:
>>> MIDR_EL1[PART_NUM] - 0x2
>>> MIDR_EL1[VARIANT] - 0x3
>>>
>>> Fixes: 2eeb5767d53f ("arm64: dts: qcom: Introduce Kaanapali SoC")
>>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> I explained you in off-list communication what you have to do - this
>> MUST go via fixes and you MUST annotate that.
>>
>> Where did you describe that? Nothing in cover letter, nothing here.


IIRC, you said this can't go in and later remembered that
it's still only in a rc and said it can go in. You then asked me
to make sure the commit message described the fix. Anyway
it looks like I missed your comment on funneling it through
the current rc.


> Although then binding should go via fixes but it depends on patch in
> next branch, so it cannot be done. Sorry, this waited way tooooo long,

By depends on linux-next, are you referring to the glymur device tree
change part of the series? I can always drop that in the next re-spin
though.

> so you cannot make this change anymore.
>
> Please drop it and you are stuck with the compatible you sent earlier,
> which reviewers requested multiple times to change.
>
> Best regards,
> Krzysztof

Re: [PATCH 3/3] arm64: dts: qcom: kaanapali: Fix deprecated cpu compatibles

[Krzysztof Kozlowski]

On 11/03/2026 11:32, Sibi Sankar wrote:
> 
> On 3/11/2026 3:51 PM, Krzysztof Kozlowski wrote:
>> On 11/03/2026 11:04, Krzysztof Kozlowski wrote:
>>> On Tue, Mar 10, 2026 at 09:37:51AM +0530, Sibi Sankar wrote:
>>>> The generic Qualcomm Oryon CPU compatible used by the Kaanapali
>>>> SoC is deprecated and incorrect since it uses a single compatible
>>>> to describe two different core variants. It is now replaced with
>>>> two different core-specific compatibles based on MIDR part and
>>>> variant number.
>>>>
>>>> CPUS 0-5:
>>>> MIDR_EL1[PART_NUM] - 0x2
>>>> MIDR_EL1[VARIANT] - 0x2
>>>>
>>>> CPUS 6-7:
>>>> MIDR_EL1[PART_NUM] - 0x2
>>>> MIDR_EL1[VARIANT] - 0x3
>>>>
>>>> Fixes: 2eeb5767d53f ("arm64: dts: qcom: Introduce Kaanapali SoC")
>>>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>> I explained you in off-list communication what you have to do - this
>>> MUST go via fixes and you MUST annotate that.
>>>
>>> Where did you describe that? Nothing in cover letter, nothing here.
> 
> 
> IIRC, you said this can't go in and later remembered that
> it's still only in a rc and said it can go in. You then asked me
> to make sure the commit message described the fix. Anyway
> it looks like I missed your comment on funneling it through
> the current rc.
> 
> 
>> Although then binding should go via fixes but it depends on patch in
>> next branch, so it cannot be done. Sorry, this waited way tooooo long,
> 
> By depends on linux-next, are you referring to the glymur device tree
> change part of the series? I can always drop that in the next re-spin
> though.
> 

No, I meant the patch deprecating Oryon compatible.

Best regards,
Krzysztof

Re: [PATCH 3/3] arm64: dts: qcom: kaanapali: Fix deprecated cpu compatibles

[Sibi Sankar]

On 3/11/2026 4:06 PM, Krzysztof Kozlowski wrote:
> On 11/03/2026 11:32, Sibi Sankar wrote:
>> On 3/11/2026 3:51 PM, Krzysztof Kozlowski wrote:
>>> On 11/03/2026 11:04, Krzysztof Kozlowski wrote:
>>>> On Tue, Mar 10, 2026 at 09:37:51AM +0530, Sibi Sankar wrote:
>>>>> The generic Qualcomm Oryon CPU compatible used by the Kaanapali
>>>>> SoC is deprecated and incorrect since it uses a single compatible
>>>>> to describe two different core variants. It is now replaced with
>>>>> two different core-specific compatibles based on MIDR part and
>>>>> variant number.
>>>>>
>>>>> CPUS 0-5:
>>>>> MIDR_EL1[PART_NUM] - 0x2
>>>>> MIDR_EL1[VARIANT] - 0x2
>>>>>
>>>>> CPUS 6-7:
>>>>> MIDR_EL1[PART_NUM] - 0x2
>>>>> MIDR_EL1[VARIANT] - 0x3
>>>>>
>>>>> Fixes: 2eeb5767d53f ("arm64: dts: qcom: Introduce Kaanapali SoC")
>>>>> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>>> I explained you in off-list communication what you have to do - this
>>>> MUST go via fixes and you MUST annotate that.
>>>>
>>>> Where did you describe that? Nothing in cover letter, nothing here.
>>
>> IIRC, you said this can't go in and later remembered that
>> it's still only in a rc and said it can go in. You then asked me
>> to make sure the commit message described the fix. Anyway
>> it looks like I missed your comment on funneling it through
>> the current rc.
>>
>>
>>> Although then binding should go via fixes but it depends on patch in
>>> next branch, so it cannot be done. Sorry, this waited way tooooo long,
>> By depends on linux-next, are you referring to the glymur device tree
>> change part of the series? I can always drop that in the next re-spin
>> though.
>>
> No, I meant the patch deprecating Oryon compatible.

Thanks for the clarification, will drop kaanapali in the next
re-spin.

>
> Best regards,
> Krzysztof