[PATCH v3 0/2] dt-bindings: soc: qcom: Add soc related bindings for Kaanapali

[PATCH v3 0/2] dt-bindings: soc: qcom: Add soc related bindings for Kaanapali

[Jingyi Wang]

Add soc related bindings for Kaanapali Platform including IMEM and SCM. 

Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
Changes in v3:
- Fix capital letter in commit message - Dmitry 
- drop changes that are applied
- fallback to a no implementation binding qcom,imem - Bjorn
- Link to v2: https://lore.kernel.org/r/20251022-knp-soc-binding-v2-0-3cd3f390f3e2@oss.qualcomm.com

Changes in v2:
- Fix capital letter in subject and simplify commit message - Eugen Hristev
- pick aoss_qmp change from https://lore.kernel.org/linux-arm-msm/20250924183726.509202-1-sibi.sankar@oss.qualcomm.com/T/#m4bbee2db112a471cdca7aa63477b7147691e6852 and rebase
- Link to v1: https://lore.kernel.org/r/20250924-knp-soc-binding-v1-0-93a072e174f9@oss.qualcomm.com

---
Jingyi Wang (2):
      dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible
      dt-bindings: firmware: qcom,scm: Document SCM on Kaanapali SOC

 .../devicetree/bindings/firmware/qcom,scm.yaml     |  2 +
 .../devicetree/bindings/sram/qcom,imem.yaml        | 77 ++++++++++++----------
 2 files changed, 43 insertions(+), 36 deletions(-)
---
base-commit: 9823120909776bbca58a3c55ef1f27d49283c1f3
change-id: 20251102-knp-soc-binding-5c96d05da015

Best regards,
-- 
Jingyi Wang <jingyi.wang@oss.qualcomm.com>

[PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Jingyi Wang]

Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
simple-mfd, also "reboot reason" is not required on Kaanapali like some
other platforms. So define a common "qcom,imem" binding and fallback to it.
Currently there is no requirement for any specific implementation for the
"qcom,imem". Its child node "qcom,pil-reloc-info" has no implementation
dependency on IMEM.

Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
 .../devicetree/bindings/sram/qcom,imem.yaml        | 77 ++++++++++++----------
 1 file changed, 41 insertions(+), 36 deletions(-)

diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
index 6a627c57ae2f..09278b21acf4 100644
--- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
+++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
@@ -15,42 +15,47 @@ description:
 
 properties:
   compatible:
-    items:
-      - enum:
-          - qcom,apq8064-imem
-          - qcom,ipq5424-imem
-          - qcom,msm8226-imem
-          - qcom,msm8974-imem
-          - qcom,msm8976-imem
-          - qcom,qcs404-imem
-          - qcom,qcs615-imem
-          - qcom,qcs8300-imem
-          - qcom,qdu1000-imem
-          - qcom,sa8775p-imem
-          - qcom,sar2130p-imem
-          - qcom,sc7180-imem
-          - qcom,sc7280-imem
-          - qcom,sc8280xp-imem
-          - qcom,sdm630-imem
-          - qcom,sdm845-imem
-          - qcom,sdx55-imem
-          - qcom,sdx65-imem
-          - qcom,sdx75-imem
-          - qcom,sm6115-imem
-          - qcom,sm6125-imem
-          - qcom,sm6350-imem
-          - qcom,sm6375-imem
-          - qcom,sm7150-imem
-          - qcom,sm8150-imem
-          - qcom,sm8250-imem
-          - qcom,sm8350-imem
-          - qcom,sm8450-imem
-          - qcom,sm8550-imem
-          - qcom,sm8650-imem
-          - qcom,sm8750-imem
-          - qcom,x1e80100-imem
-      - const: syscon
-      - const: simple-mfd
+    oneOf:
+      - items:
+          - enum:
+              - qcom,apq8064-imem
+              - qcom,ipq5424-imem
+              - qcom,msm8226-imem
+              - qcom,msm8974-imem
+              - qcom,msm8976-imem
+              - qcom,qcs404-imem
+              - qcom,qcs615-imem
+              - qcom,qcs8300-imem
+              - qcom,qdu1000-imem
+              - qcom,sa8775p-imem
+              - qcom,sar2130p-imem
+              - qcom,sc7180-imem
+              - qcom,sc7280-imem
+              - qcom,sc8280xp-imem
+              - qcom,sdm630-imem
+              - qcom,sdm845-imem
+              - qcom,sdx55-imem
+              - qcom,sdx65-imem
+              - qcom,sdx75-imem
+              - qcom,sm6115-imem
+              - qcom,sm6125-imem
+              - qcom,sm6350-imem
+              - qcom,sm6375-imem
+              - qcom,sm7150-imem
+              - qcom,sm8150-imem
+              - qcom,sm8250-imem
+              - qcom,sm8350-imem
+              - qcom,sm8450-imem
+              - qcom,sm8550-imem
+              - qcom,sm8650-imem
+              - qcom,sm8750-imem
+              - qcom,x1e80100-imem
+          - const: syscon
+          - const: simple-mfd
+      - items:
+          - enum:
+              - qcom,kaanapali-imem
+          - const: qcom,imem
 
   reg:
     maxItems: 1

-- 
2.25.1

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Bjorn Andersson]

On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote:
> Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
> simple-mfd, also "reboot reason" is not required on Kaanapali like some
> other platforms. So define a common "qcom,imem" binding and fallback to it.
> Currently there is no requirement for any specific implementation for the
> "qcom,imem". Its child node "qcom,pil-reloc-info" has no implementation
> dependency on IMEM.

I think this could have captured the discussion leading up to this
result a bit better, and the fact that this isn't unique to Kaanapali.

But I won't insist on a rewrite.

> 
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>

Reviewed-by: Bjorn Andersson <andersson@kernel.org>

Regards,
Bjorn

> ---
>  .../devicetree/bindings/sram/qcom,imem.yaml        | 77 ++++++++++++----------
>  1 file changed, 41 insertions(+), 36 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> index 6a627c57ae2f..09278b21acf4 100644
> --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml
> @@ -15,42 +15,47 @@ description:
>  
>  properties:
>    compatible:
> -    items:
> -      - enum:
> -          - qcom,apq8064-imem
> -          - qcom,ipq5424-imem
> -          - qcom,msm8226-imem
> -          - qcom,msm8974-imem
> -          - qcom,msm8976-imem
> -          - qcom,qcs404-imem
> -          - qcom,qcs615-imem
> -          - qcom,qcs8300-imem
> -          - qcom,qdu1000-imem
> -          - qcom,sa8775p-imem
> -          - qcom,sar2130p-imem
> -          - qcom,sc7180-imem
> -          - qcom,sc7280-imem
> -          - qcom,sc8280xp-imem
> -          - qcom,sdm630-imem
> -          - qcom,sdm845-imem
> -          - qcom,sdx55-imem
> -          - qcom,sdx65-imem
> -          - qcom,sdx75-imem
> -          - qcom,sm6115-imem
> -          - qcom,sm6125-imem
> -          - qcom,sm6350-imem
> -          - qcom,sm6375-imem
> -          - qcom,sm7150-imem
> -          - qcom,sm8150-imem
> -          - qcom,sm8250-imem
> -          - qcom,sm8350-imem
> -          - qcom,sm8450-imem
> -          - qcom,sm8550-imem
> -          - qcom,sm8650-imem
> -          - qcom,sm8750-imem
> -          - qcom,x1e80100-imem
> -      - const: syscon
> -      - const: simple-mfd
> +    oneOf:
> +      - items:
> +          - enum:
> +              - qcom,apq8064-imem
> +              - qcom,ipq5424-imem
> +              - qcom,msm8226-imem
> +              - qcom,msm8974-imem
> +              - qcom,msm8976-imem
> +              - qcom,qcs404-imem
> +              - qcom,qcs615-imem
> +              - qcom,qcs8300-imem
> +              - qcom,qdu1000-imem
> +              - qcom,sa8775p-imem
> +              - qcom,sar2130p-imem
> +              - qcom,sc7180-imem
> +              - qcom,sc7280-imem
> +              - qcom,sc8280xp-imem
> +              - qcom,sdm630-imem
> +              - qcom,sdm845-imem
> +              - qcom,sdx55-imem
> +              - qcom,sdx65-imem
> +              - qcom,sdx75-imem
> +              - qcom,sm6115-imem
> +              - qcom,sm6125-imem
> +              - qcom,sm6350-imem
> +              - qcom,sm6375-imem
> +              - qcom,sm7150-imem
> +              - qcom,sm8150-imem
> +              - qcom,sm8250-imem
> +              - qcom,sm8350-imem
> +              - qcom,sm8450-imem
> +              - qcom,sm8550-imem
> +              - qcom,sm8650-imem
> +              - qcom,sm8750-imem
> +              - qcom,x1e80100-imem
> +          - const: syscon
> +          - const: simple-mfd
> +      - items:
> +          - enum:
> +              - qcom,kaanapali-imem
> +          - const: qcom,imem
>  
>    reg:
>      maxItems: 1
> 
> -- 
> 2.25.1
> 

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Krzysztof Kozlowski]

On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote:
> Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
> simple-mfd, also "reboot reason" is not required on Kaanapali like some

I do not see correlation. Something is not a syscon, so you add a new
generic compatible? No.

> other platforms. So define a common "qcom,imem" binding and fallback to it.

You did not define fallback to it!

...

> +      - items:
> +          - enum:
> +              - qcom,kaanapali-imem
> +          - const: qcom,imem

I do not understand what this generic compatible is supposed to express,
not explained in commit msg. Considering this wasn't before, it is a
major and really undesired change. It also makes no sesne. There was no
generic compatible before but "if not syscon" now this must have generic
compatible, what?

NAK

Best regards,
Krzysztof

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Aiqun(Maria) Yu]

On 11/4/2025 4:16 PM, Krzysztof Kozlowski wrote:
> On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote:
>> Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
>> simple-mfd, also "reboot reason" is not required on Kaanapali like some
> 
> I do not see correlation. Something is not a syscon, so you add a new
> generic compatible? No.
> 
>> other platforms. So define a common "qcom,imem" binding and fallback to it.
> 
> You did not define fallback to it!
> 
> ...
> 
>> +      - items:
>> +          - enum:
>> +              - qcom,kaanapali-imem
>> +          - const: qcom,imem
> 
> I do not understand what this generic compatible is supposed to express,
> not explained in commit msg. Considering this wasn't before, it is a
> major and really undesired change. It also makes no sesne. There was no
> generic compatible before but "if not syscon" now this must have generic
> compatible, what?

Are you suggesting to remove the generic compatible of "qcom,imem"?
Could you pls help to confirm the suggested way from your point of view?


> 
> NAK
> 
> Best regards,
> Krzysztof
> 


-- 
Thx and BRs,
Aiqun(Maria) Yu

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Konrad Dybcio]

On 11/4/25 9:16 AM, Krzysztof Kozlowski wrote:
> On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote:
>> Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
>> simple-mfd, also "reboot reason" is not required on Kaanapali like some
> 
> I do not see correlation. Something is not a syscon, so you add a new
> generic compatible? No.
> 
>> other platforms. So define a common "qcom,imem" binding and fallback to it.
> 
> You did not define fallback to it!
> 
> ...
> 
>> +      - items:
>> +          - enum:
>> +              - qcom,kaanapali-imem
>> +          - const: qcom,imem
> 
> I do not understand what this generic compatible is supposed to express,
> not explained in commit msg. Considering this wasn't before, it is a
> major and really undesired change. It also makes no sesne. There was no
> generic compatible before but "if not syscon" now this must have generic
> compatible, what?

So IMEM (or SYSTEM_IMEM more specifically as opposed to BOOT_IMEM which
you can take your guesses what it's used for) is to the best of our
understanding just a piece of SRAM that's accessible by multiple
processors/subsystems on the SoC.

A smaller region within it ("shared IMEM") is a little bit of a dumping
ground for various (incl. runtime) configuration and debug magic data
and that's usually what Linux is concerned with.

IMEM is currently described as a simple-mfd+syscon, which it is clearly
not. The former, as we've established in the past, was used as a hack to
have something call of_platform_populate().

I think that in turn is only necessary for the old arm32 DTs which have
a syscon-reboot-mode node under IMEM (and I think that's where the syscon
compatible comes from).

Should we make the switch to mmio-sram and settle this discussion?
It would probably require convincing the sram maintainer to add that
of_platform_populate() call in its probe func and making syscon-reboot
not depend on a syscon (not like it's very hard)

Konrad

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Krzysztof Kozlowski]

On 04/11/2025 13:32, Konrad Dybcio wrote:
> On 11/4/25 9:16 AM, Krzysztof Kozlowski wrote:
>> On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote:
>>> Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
>>> simple-mfd, also "reboot reason" is not required on Kaanapali like some
>>
>> I do not see correlation. Something is not a syscon, so you add a new
>> generic compatible? No.
>>
>>> other platforms. So define a common "qcom,imem" binding and fallback to it.
>>
>> You did not define fallback to it!
>>
>> ...
>>
>>> +      - items:
>>> +          - enum:
>>> +              - qcom,kaanapali-imem
>>> +          - const: qcom,imem
>>
>> I do not understand what this generic compatible is supposed to express,
>> not explained in commit msg. Considering this wasn't before, it is a
>> major and really undesired change. It also makes no sesne. There was no
>> generic compatible before but "if not syscon" now this must have generic
>> compatible, what?
> 
> So IMEM (or SYSTEM_IMEM more specifically as opposed to BOOT_IMEM which
> you can take your guesses what it's used for) is to the best of our
> understanding just a piece of SRAM that's accessible by multiple
> processors/subsystems on the SoC.
> 
> A smaller region within it ("shared IMEM") is a little bit of a dumping
> ground for various (incl. runtime) configuration and debug magic data
> and that's usually what Linux is concerned with.
> 
> IMEM is currently described as a simple-mfd+syscon, which it is clearly
> not. The former, as we've established in the past, was used as a hack to
> have something call of_platform_populate().
> 
> I think that in turn is only necessary for the old arm32 DTs which have
> a syscon-reboot-mode node under IMEM (and I think that's where the syscon
> compatible comes from).
> 
> Should we make the switch to mmio-sram and settle this discussion?
> It would probably require convincing the sram maintainer to add that
> of_platform_populate() call in its probe func and making syscon-reboot
> not depend on a syscon (not like it's very hard)

This I got, but nothing here explains why you need generic compatible.
To re-iterate: there was no generic compatible before, now there is.
Writing bindings and numerous reviews from DT maintainers ask not to use
generic compatibles.

Best regards,
Krzysztof

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Konrad Dybcio]

On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
> On 04/11/2025 13:32, Konrad Dybcio wrote:
>> On 11/4/25 9:16 AM, Krzysztof Kozlowski wrote:
>>> On Sun, Nov 02, 2025 at 11:25:06PM -0800, Jingyi Wang wrote:
>>>> Document qcom,kaanapali-imem compatible. Kaanapali IMEM is not a syscon or
>>>> simple-mfd, also "reboot reason" is not required on Kaanapali like some
>>>
>>> I do not see correlation. Something is not a syscon, so you add a new
>>> generic compatible? No.
>>>
>>>> other platforms. So define a common "qcom,imem" binding and fallback to it.
>>>
>>> You did not define fallback to it!
>>>
>>> ...
>>>
>>>> +      - items:
>>>> +          - enum:
>>>> +              - qcom,kaanapali-imem
>>>> +          - const: qcom,imem
>>>
>>> I do not understand what this generic compatible is supposed to express,
>>> not explained in commit msg. Considering this wasn't before, it is a
>>> major and really undesired change. It also makes no sesne. There was no
>>> generic compatible before but "if not syscon" now this must have generic
>>> compatible, what?
>>
>> So IMEM (or SYSTEM_IMEM more specifically as opposed to BOOT_IMEM which
>> you can take your guesses what it's used for) is to the best of our
>> understanding just a piece of SRAM that's accessible by multiple
>> processors/subsystems on the SoC.
>>
>> A smaller region within it ("shared IMEM") is a little bit of a dumping
>> ground for various (incl. runtime) configuration and debug magic data
>> and that's usually what Linux is concerned with.
>>
>> IMEM is currently described as a simple-mfd+syscon, which it is clearly
>> not. The former, as we've established in the past, was used as a hack to
>> have something call of_platform_populate().
>>
>> I think that in turn is only necessary for the old arm32 DTs which have
>> a syscon-reboot-mode node under IMEM (and I think that's where the syscon
>> compatible comes from).
>>
>> Should we make the switch to mmio-sram and settle this discussion?
>> It would probably require convincing the sram maintainer to add that
>> of_platform_populate() call in its probe func and making syscon-reboot
>> not depend on a syscon (not like it's very hard)
> 
> This I got, but nothing here explains why you need generic compatible.
> To re-iterate: there was no generic compatible before, now there is.
> Writing bindings and numerous reviews from DT maintainers ask not to use
> generic compatibles.

OK so let's not worry about a generic compatible. IMEM exists since
MSM8974 and it only had major hw updates with SM8550. They don't
impact the software interface though, so qcom,msm8974-imem is OK.

There's a separate control/status register address space for each
instance of this IP (usually far apart from the actual SRAM pool),
which Linux doesn't have to care about.

Konrad

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Krzysztof Kozlowski]

On 04/11/2025 15:35, Konrad Dybcio wrote:
> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
>> This I got, but nothing here explains why you need generic compatible.
>> To re-iterate: there was no generic compatible before, now there is.
>> Writing bindings and numerous reviews from DT maintainers ask not to use
>> generic compatibles.
> 
> OK so let's not worry about a generic compatible. IMEM exists since
> MSM8974 and it only had major hw updates with SM8550. They don't
> impact the software interface though, so qcom,msm8974-imem is OK.
> 
> There's a separate control/status register address space for each
> instance of this IP (usually far apart from the actual SRAM pool),
> which Linux doesn't have to care about.

Just use qcom,kaanapali-imem - that's the first device here without syscons.


Best regards,
Krzysztof

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Konrad Dybcio]

On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote:
> On 04/11/2025 15:35, Konrad Dybcio wrote:
>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
>>> This I got, but nothing here explains why you need generic compatible.
>>> To re-iterate: there was no generic compatible before, now there is.
>>> Writing bindings and numerous reviews from DT maintainers ask not to use
>>> generic compatibles.
>>
>> OK so let's not worry about a generic compatible. IMEM exists since
>> MSM8974 and it only had major hw updates with SM8550. They don't
>> impact the software interface though, so qcom,msm8974-imem is OK.
>>
>> There's a separate control/status register address space for each
>> instance of this IP (usually far apart from the actual SRAM pool),
>> which Linux doesn't have to care about.
> 
> Just use qcom,kaanapali-imem - that's the first device here without syscons.

So we don't want to move the existing ones over?

Konrad

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Krzysztof Kozlowski]

On 04/11/2025 15:38, Konrad Dybcio wrote:
> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote:
>> On 04/11/2025 15:35, Konrad Dybcio wrote:
>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
>>>> This I got, but nothing here explains why you need generic compatible.
>>>> To re-iterate: there was no generic compatible before, now there is.
>>>> Writing bindings and numerous reviews from DT maintainers ask not to use
>>>> generic compatibles.
>>>
>>> OK so let's not worry about a generic compatible. IMEM exists since
>>> MSM8974 and it only had major hw updates with SM8550. They don't
>>> impact the software interface though, so qcom,msm8974-imem is OK.
>>>
>>> There's a separate control/status register address space for each
>>> instance of this IP (usually far apart from the actual SRAM pool),
>>> which Linux doesn't have to care about.
>>
>> Just use qcom,kaanapali-imem - that's the first device here without syscons.
> 
> So we don't want to move the existing ones over?

This was never discussed and this patch did not do it. You cannot move
them, that's ABI.

Best regards,
Krzysztof

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Konrad Dybcio]

On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote:
> On 04/11/2025 15:38, Konrad Dybcio wrote:
>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote:
>>> On 04/11/2025 15:35, Konrad Dybcio wrote:
>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
>>>>> This I got, but nothing here explains why you need generic compatible.
>>>>> To re-iterate: there was no generic compatible before, now there is.
>>>>> Writing bindings and numerous reviews from DT maintainers ask not to use
>>>>> generic compatibles.
>>>>
>>>> OK so let's not worry about a generic compatible. IMEM exists since
>>>> MSM8974 and it only had major hw updates with SM8550. They don't
>>>> impact the software interface though, so qcom,msm8974-imem is OK.
>>>>
>>>> There's a separate control/status register address space for each
>>>> instance of this IP (usually far apart from the actual SRAM pool),
>>>> which Linux doesn't have to care about.
>>>
>>> Just use qcom,kaanapali-imem - that's the first device here without syscons.
>>
>> So we don't want to move the existing ones over?
> 
> This was never discussed and this patch did not do it. You cannot move
> them, that's ABI.

I see, I implicitly assumed this would be a sweeping change.

So should the Kaanapali submitters simply send a version of this
patch with:

- oneOf:
  - const: qcom,kaanapali-imem
  - items:
    # existing big list

?

I'm not a huge fan of using kaanapali as the fallback-going-forward
since it's literally the newest platform on the shelves (or perhaps
not even on the shelves yet..) so it's going to look funny when
someone comes up with support for another 2013 soc.. but perhaps
that's just how things are supposed to be

Konrad

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Krzysztof Kozlowski]

On 04/11/2025 15:58, Konrad Dybcio wrote:
> On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote:
>> On 04/11/2025 15:38, Konrad Dybcio wrote:
>>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote:
>>>> On 04/11/2025 15:35, Konrad Dybcio wrote:
>>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
>>>>>> This I got, but nothing here explains why you need generic compatible.
>>>>>> To re-iterate: there was no generic compatible before, now there is.
>>>>>> Writing bindings and numerous reviews from DT maintainers ask not to use
>>>>>> generic compatibles.
>>>>>
>>>>> OK so let's not worry about a generic compatible. IMEM exists since
>>>>> MSM8974 and it only had major hw updates with SM8550. They don't
>>>>> impact the software interface though, so qcom,msm8974-imem is OK.
>>>>>
>>>>> There's a separate control/status register address space for each
>>>>> instance of this IP (usually far apart from the actual SRAM pool),
>>>>> which Linux doesn't have to care about.
>>>>
>>>> Just use qcom,kaanapali-imem - that's the first device here without syscons.
>>>
>>> So we don't want to move the existing ones over?
>>
>> This was never discussed and this patch did not do it. You cannot move
>> them, that's ABI.
> 
> I see, I implicitly assumed this would be a sweeping change.
> 
> So should the Kaanapali submitters simply send a version of this
> patch with:
> 
> - oneOf:
>   - const: qcom,kaanapali-imem
>   - items:
>     # existing big list
> 
> ?
> 
> I'm not a huge fan of using kaanapali as the fallback-going-forward
> since it's literally the newest platform on the shelves (or perhaps
> not even on the shelves yet..) so it's going to look funny when
> someone comes up with support for another 2013 soc.. but perhaps
> that's just how things are supposed to be


Yes. Feel free to choose other fully compatible device as the fallback,
like you mentioned in previous email, I proposed Kaanapali as the easiest.

Best regards,
Krzysztof

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Konrad Dybcio]

On 11/4/25 4:02 PM, Krzysztof Kozlowski wrote:
> On 04/11/2025 15:58, Konrad Dybcio wrote:
>> On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote:
>>> On 04/11/2025 15:38, Konrad Dybcio wrote:
>>>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote:
>>>>> On 04/11/2025 15:35, Konrad Dybcio wrote:
>>>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
>>>>>>> This I got, but nothing here explains why you need generic compatible.
>>>>>>> To re-iterate: there was no generic compatible before, now there is.
>>>>>>> Writing bindings and numerous reviews from DT maintainers ask not to use
>>>>>>> generic compatibles.
>>>>>>
>>>>>> OK so let's not worry about a generic compatible. IMEM exists since
>>>>>> MSM8974 and it only had major hw updates with SM8550. They don't
>>>>>> impact the software interface though, so qcom,msm8974-imem is OK.
>>>>>>
>>>>>> There's a separate control/status register address space for each
>>>>>> instance of this IP (usually far apart from the actual SRAM pool),
>>>>>> which Linux doesn't have to care about.
>>>>>
>>>>> Just use qcom,kaanapali-imem - that's the first device here without syscons.
>>>>
>>>> So we don't want to move the existing ones over?
>>>
>>> This was never discussed and this patch did not do it. You cannot move
>>> them, that's ABI.
>>
>> I see, I implicitly assumed this would be a sweeping change.
>>
>> So should the Kaanapali submitters simply send a version of this
>> patch with:
>>
>> - oneOf:
>>   - const: qcom,kaanapali-imem
>>   - items:
>>     # existing big list
>>
>> ?
>>
>> I'm not a huge fan of using kaanapali as the fallback-going-forward
>> since it's literally the newest platform on the shelves (or perhaps
>> not even on the shelves yet..) so it's going to look funny when
>> someone comes up with support for another 2013 soc.. but perhaps
>> that's just how things are supposed to be
> 
> 
> Yes. Feel free to choose other fully compatible device as the fallback,
> like you mentioned in previous email, I proposed Kaanapali as the easiest.

Ehhh it's not super convenient given the available list

I see that msm8994 isn't described yet. If we don't need to care about
the pre-/post 8550 split (which we would only for the aforementioned control
register space which is NOT what this binding describes), let's go with that
as the fallback.

Konrad

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Bjorn Andersson]

On Tue, Nov 04, 2025 at 03:58:27PM +0100, Konrad Dybcio wrote:
> On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote:
> > On 04/11/2025 15:38, Konrad Dybcio wrote:
> >> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote:
> >>> On 04/11/2025 15:35, Konrad Dybcio wrote:
> >>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
> >>>>> This I got, but nothing here explains why you need generic compatible.
> >>>>> To re-iterate: there was no generic compatible before, now there is.
> >>>>> Writing bindings and numerous reviews from DT maintainers ask not to use
> >>>>> generic compatibles.
> >>>>
> >>>> OK so let's not worry about a generic compatible. IMEM exists since
> >>>> MSM8974 and it only had major hw updates with SM8550. They don't
> >>>> impact the software interface though, so qcom,msm8974-imem is OK.
> >>>>
> >>>> There's a separate control/status register address space for each
> >>>> instance of this IP (usually far apart from the actual SRAM pool),
> >>>> which Linux doesn't have to care about.
> >>>
> >>> Just use qcom,kaanapali-imem - that's the first device here without syscons.
> >>
> >> So we don't want to move the existing ones over?
> > 
> > This was never discussed and this patch did not do it. You cannot move
> > them, that's ABI.
> 
> I see, I implicitly assumed this would be a sweeping change.
> 
> So should the Kaanapali submitters simply send a version of this
> patch with:
> 
> - oneOf:
>   - const: qcom,kaanapali-imem
>   - items:
>     # existing big list
> 
> ?

We have 33 cases of "this is just a generic Qualcomm IMEM block", could
we just make it "qcom,imem" until there's actually a sign that it's not
a platform-independent block?

Regards,
Bjorn

> 
> I'm not a huge fan of using kaanapali as the fallback-going-forward
> since it's literally the newest platform on the shelves (or perhaps
> not even on the shelves yet..) so it's going to look funny when
> someone comes up with support for another 2013 soc.. but perhaps
> that's just how things are supposed to be
> 
> Konrad

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Kathiravan Thirumoorthy]

On 11/7/2025 1:54 AM, Bjorn Andersson wrote:
> On Tue, Nov 04, 2025 at 03:58:27PM +0100, Konrad Dybcio wrote:
>> On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote:
>>> On 04/11/2025 15:38, Konrad Dybcio wrote:
>>>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote:
>>>>> On 04/11/2025 15:35, Konrad Dybcio wrote:
>>>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
>>>>>>> This I got, but nothing here explains why you need generic compatible.
>>>>>>> To re-iterate: there was no generic compatible before, now there is.
>>>>>>> Writing bindings and numerous reviews from DT maintainers ask not to use
>>>>>>> generic compatibles.
>>>>>> OK so let's not worry about a generic compatible. IMEM exists since
>>>>>> MSM8974 and it only had major hw updates with SM8550. They don't
>>>>>> impact the software interface though, so qcom,msm8974-imem is OK.
>>>>>>
>>>>>> There's a separate control/status register address space for each
>>>>>> instance of this IP (usually far apart from the actual SRAM pool),
>>>>>> which Linux doesn't have to care about.
>>>>> Just use qcom,kaanapali-imem - that's the first device here without syscons.
>>>> So we don't want to move the existing ones over?
>>> This was never discussed and this patch did not do it. You cannot move
>>> them, that's ABI.
>> I see, I implicitly assumed this would be a sweeping change.
>>
>> So should the Kaanapali submitters simply send a version of this
>> patch with:
>>
>> - oneOf:
>>    - const: qcom,kaanapali-imem
>>    - items:
>>      # existing big list
>>
>> ?
> We have 33 cases of "this is just a generic Qualcomm IMEM block", could
> we just make it "qcom,imem" until there's actually a sign that it's not
> a platform-independent block?


Any conclusion / further feedback on this would be helpful to move 
things forward. Thanks in advance.


>
> Regards,
> Bjorn
>
>> I'm not a huge fan of using kaanapali as the fallback-going-forward
>> since it's literally the newest platform on the shelves (or perhaps
>> not even on the shelves yet..) so it's going to look funny when
>> someone comes up with support for another 2013 soc.. but perhaps
>> that's just how things are supposed to be
>>
>> Konrad

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Aiqun(Maria) Yu]

On 11/11/2025 4:29 PM, Kathiravan Thirumoorthy wrote:
> 
> On 11/7/2025 1:54 AM, Bjorn Andersson wrote:
>> On Tue, Nov 04, 2025 at 03:58:27PM +0100, Konrad Dybcio wrote:
>>> On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote:
>>>> On 04/11/2025 15:38, Konrad Dybcio wrote:
>>>>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote:
>>>>>> On 04/11/2025 15:35, Konrad Dybcio wrote:
>>>>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
>>>>>>>> This I got, but nothing here explains why you need generic
>>>>>>>> compatible.
>>>>>>>> To re-iterate: there was no generic compatible before, now there
>>>>>>>> is.
>>>>>>>> Writing bindings and numerous reviews from DT maintainers ask
>>>>>>>> not to use
>>>>>>>> generic compatibles.
>>>>>>> OK so let's not worry about a generic compatible. IMEM exists since
>>>>>>> MSM8974 and it only had major hw updates with SM8550. They don't
>>>>>>> impact the software interface though, so qcom,msm8974-imem is OK.
>>>>>>>
>>>>>>> There's a separate control/status register address space for each
>>>>>>> instance of this IP (usually far apart from the actual SRAM pool),
>>>>>>> which Linux doesn't have to care about.
>>>>>> Just use qcom,kaanapali-imem - that's the first device here
>>>>>> without syscons.
>>>>> So we don't want to move the existing ones over?
>>>> This was never discussed and this patch did not do it. You cannot move
>>>> them, that's ABI.
>>> I see, I implicitly assumed this would be a sweeping change.
>>>
>>> So should the Kaanapali submitters simply send a version of this
>>> patch with:
>>>
>>> - oneOf:
>>>    - const: qcom,kaanapali-imem
>>>    - items:
>>>      # existing big list
>>>
>>> ?
>> We have 33 cases of "this is just a generic Qualcomm IMEM block", could
>> we just make it "qcom,imem" until there's actually a sign that it's not
>> a platform-independent block?

If it’s not platform-specific, why not use a common compatible here? I
mean let's have a common "qcom,imem" start from kaanapali.

What benefits would a platform-specific approach bring in this case? For
newer platforms, we could simply adopt the common compatible and avoid
adding a dedicated platform compatible name.

Also, the old bootloader reboot-mode solution that uses the IMEM area as
a magic syscon is deprecated for newer targets.

> 
> 
> Any conclusion / further feedback on this would be helpful to move
> things forward. Thanks in advance.


Which platform are you waiting for as a reference? Or are you only
focused on the current Kaanapali?
By the way, great to see we share the same goal here.

> 
> 
>>
>> Regards,
>> Bjorn
>>
>>> I'm not a huge fan of using kaanapali as the fallback-going-forward
>>> since it's literally the newest platform on the shelves (or perhaps
>>> not even on the shelves yet..) so it's going to look funny when
>>> someone comes up with support for another 2013 soc.. but perhaps
>>> that's just how things are supposed to be
>>>
>>> Konrad


-- 
Thx and BRs,
Aiqun(Maria) Yu

Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem compatible

[Kathiravan Thirumoorthy]

On 11/11/2025 5:38 PM, Aiqun(Maria) Yu wrote:
> On 11/11/2025 4:29 PM, Kathiravan Thirumoorthy wrote:
>> On 11/7/2025 1:54 AM, Bjorn Andersson wrote:
>>> On Tue, Nov 04, 2025 at 03:58:27PM +0100, Konrad Dybcio wrote:
>>>> On 11/4/25 3:52 PM, Krzysztof Kozlowski wrote:
>>>>> On 04/11/2025 15:38, Konrad Dybcio wrote:
>>>>>> On 11/4/25 3:37 PM, Krzysztof Kozlowski wrote:
>>>>>>> On 04/11/2025 15:35, Konrad Dybcio wrote:
>>>>>>>> On 11/4/25 3:26 PM, Krzysztof Kozlowski wrote:
>>>>>>>>> This I got, but nothing here explains why you need generic
>>>>>>>>> compatible.
>>>>>>>>> To re-iterate: there was no generic compatible before, now there
>>>>>>>>> is.
>>>>>>>>> Writing bindings and numerous reviews from DT maintainers ask
>>>>>>>>> not to use
>>>>>>>>> generic compatibles.
>>>>>>>> OK so let's not worry about a generic compatible. IMEM exists since
>>>>>>>> MSM8974 and it only had major hw updates with SM8550. They don't
>>>>>>>> impact the software interface though, so qcom,msm8974-imem is OK.
>>>>>>>>
>>>>>>>> There's a separate control/status register address space for each
>>>>>>>> instance of this IP (usually far apart from the actual SRAM pool),
>>>>>>>> which Linux doesn't have to care about.
>>>>>>> Just use qcom,kaanapali-imem - that's the first device here
>>>>>>> without syscons.
>>>>>> So we don't want to move the existing ones over?
>>>>> This was never discussed and this patch did not do it. You cannot move
>>>>> them, that's ABI.
>>>> I see, I implicitly assumed this would be a sweeping change.
>>>>
>>>> So should the Kaanapali submitters simply send a version of this
>>>> patch with:
>>>>
>>>> - oneOf:
>>>>     - const: qcom,kaanapali-imem
>>>>     - items:
>>>>       # existing big list
>>>>
>>>> ?
>>> We have 33 cases of "this is just a generic Qualcomm IMEM block", could
>>> we just make it "qcom,imem" until there's actually a sign that it's not
>>> a platform-independent block?
> If it’s not platform-specific, why not use a common compatible here? I
> mean let's have a common "qcom,imem" start from kaanapali.
>
> What benefits would a platform-specific approach bring in this case? For
> newer platforms, we could simply adopt the common compatible and avoid
> adding a dedicated platform compatible name.
>
> Also, the old bootloader reboot-mode solution that uses the IMEM area as
> a magic syscon is deprecated for newer targets.
>
>>
>> Any conclusion / further feedback on this would be helpful to move
>> things forward. Thanks in advance.
>
> Which platform are you waiting for as a reference? Or are you only
> focused on the current Kaanapali?
> By the way, great to see we share the same goal here.


I'm working on the IPQ SoCs. All of these discussions started from the 
IPQ series[1], followed by Konrad's IPA stuff[2] and now we are in 
Kaanapali.

[1] 
https://lore.kernel.org/linux-arm-msm/20250610-wdt_reset_reason-v5-0-2d2835160ab5@oss.qualcomm.com/ 


[2] 
https://lore.kernel.org/linux-arm-msm/20250527-topic-ipa_imem-v2-0-6d1aad91b841@oss.qualcomm.com/

Reaching a conclusion on this topic together will help us move forward 
with the above mentioned series.


>
>>
>>> Regards,
>>> Bjorn
>>>
>>>> I'm not a huge fan of using kaanapali as the fallback-going-forward
>>>> since it's literally the newest platform on the shelves (or perhaps
>>>> not even on the shelves yet..) so it's going to look funny when
>>>> someone comes up with support for another 2013 soc.. but perhaps
>>>> that's just how things are supposed to be
>>>>
>>>> Konrad
>

[PATCH v3 2/2] dt-bindings: firmware: qcom,scm: Document SCM on Kaanapali SOC

[Jingyi Wang]

Document SCM compatible for the Qualcomm Kaanapali SoC.

Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/firmware/qcom,scm.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
index 38c64c3783f8..d66459f1d84e 100644
--- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
@@ -32,6 +32,7 @@ properties:
           - qcom,scm-ipq806x
           - qcom,scm-ipq8074
           - qcom,scm-ipq9574
+          - qcom,scm-kaanapali
           - qcom,scm-mdm9607
           - qcom,scm-milos
           - qcom,scm-msm8226
@@ -203,6 +204,7 @@ allOf:
           compatible:
             contains:
               enum:
+                - qcom,scm-kaanapali
                 - qcom,scm-milos
                 - qcom,scm-sm8450
                 - qcom,scm-sm8550

-- 
2.25.1

Re: (subset) [PATCH v3 0/2] dt-bindings: soc: qcom: Add soc related bindings for Kaanapali

[Bjorn Andersson]

On Sun, 02 Nov 2025 23:25:05 -0800, Jingyi Wang wrote:
> Add soc related bindings for Kaanapali Platform including IMEM and SCM.
> 
> 

Applied, thanks!

[2/2] dt-bindings: firmware: qcom,scm: Document SCM on Kaanapali SOC
      commit: 682921ab33129ec46392b27e9dafcb206c2a08dd

Best regards,
-- 
Bjorn Andersson <andersson@kernel.org>