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@xxxxxxxxxxxxxxxx>
>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
>>> 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