[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e08c4768-85d2-4acd-973c-7b2fdfe4a8aa@oss.qualcomm.com>
Date: Tue, 4 Nov 2025 16:14:00 +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 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
Powered by blists - more mailing lists