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.1On 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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.