[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9d80b581-5d3f-4b95-91e7-c73c113b0976@oss.qualcomm.com>
Date: Tue, 4 Nov 2025 15:58:27 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
Jingyi Wang <jingyi.wang@....qualcomm.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>,
Robert Marko <robimarko@...il.com>,
Das Srinagesh <quic_gurus@...cinc.com>, aiqun.yu@....qualcomm.com,
tingwei.zhang@....qualcomm.com, trilok.soni@....qualcomm.com,
yijie.yang@....qualcomm.com, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] dt-bindings: soc: qcom: Add qcom,kaanapali-imem
compatible
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
Powered by blists - more mailing lists