linux-kernel - Re: [PATCH 2/6] dt-bindings: remoteproc: qcom,sm8550-pas: Add Kaanapali CDSP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c0e6b667-2e87-4419-81ad-3366ed56830e@gmail.com>
Date: Thu, 23 Oct 2025 08:28:54 +0200
From: Krzysztof Kozlowski <k.kozlowski.k@...il.com>
To: Jingyi Wang <jingyi.wang@....qualcomm.com>,
 Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
 Mathieu Poirier <mathieu.poirier@...aro.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Manivannan Sadhasivam <mani@...nel.org>,
 Konrad Dybcio <konradybcio@...nel.org>, linux-arm-msm@...r.kernel.org,
 linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, aiqun.yu@....qualcomm.com,
 tingwei.zhang@....qualcomm.com, trilok.soni@....qualcomm.com,
 yijie.yang@....qualcomm.com
Subject: Re: [PATCH 2/6] dt-bindings: remoteproc: qcom,sm8550-pas: Add
 Kaanapali CDSP

On 23/10/2025 06:07, Jingyi Wang wrote:
> 
> 
> On 10/9/2025 6:29 PM, Krzysztof Kozlowski wrote:
>> On 29/09/2025 19:03, Dmitry Baryshkov wrote:
>>> On Mon, Sep 29, 2025 at 05:41:10PM +0800, Jingyi Wang wrote:
>>>>
>>>>
>>>> On 9/29/2025 5:34 PM, Dmitry Baryshkov wrote:
>>>>> On Mon, Sep 29, 2025 at 02:20:54PM +0800, Jingyi Wang wrote:
>>>>>>
>>>>>>
>>>>>> On 9/25/2025 9:48 AM, Krzysztof Kozłowski wrote:
>>>>>>> On Thu, 25 Sept 2025 at 08:37, Jingyi Wang <jingyi.wang@....qualcomm.com> wrote:
>>>>>>>>
>>>>>>>> Add remote processor PAS loader for Kaanapali CDSP processor, compatible
>>>>>>>> with earlier SM8550 with minor difference: one more sixth "shutdown-ack"
>>>>>>>> interrupt.
>>>>>>>>
>>>>>>>> Signed-off-by: Jingyi Wang <jingyi.wang@....qualcomm.com>
>>>>>>>> ---
>>>>>>>>  .../bindings/remoteproc/qcom,sm8550-pas.yaml          | 19 +++++++++++++++++++
>>>>>>>>  1 file changed, 19 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
>>>>>>>> index be9e2a0bc060..031fdf36a66c 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
>>>>>>>> @@ -35,6 +35,9 @@ properties:
>>>>>>>>        - items:
>>>>>>>>            - const: qcom,sm8750-cdsp-pas
>>>>>>>>            - const: qcom,sm8650-cdsp-pas
>>>>>>>> +      - items:
>>>>>>>> +          - const: qcom,kaanapali-cdsp-pas
>>>>>>>> +          - const: qcom,sm8550-cdsp-pas
>>>>>>>
>>>>>>>
>>>>>>> This time maybe without HTML:
>>>>>>>
>>>>>>> This looks wrong. This is not compatible with SM8550.
>>>>>>
>>>>>> Could you point out what is the difference from your perspecetive?
>>>>>> it is the same as SM8550 except for there is one more interrupt,
>>>>>> which is also described in this patch.
>>>>>
>>>>> I'd second Krzysztof here. Your description points out that it is _not_
>>>>> compatible to SM8550.
>>>>>
>>>>
>>>> Here is the binding for sm8750 cdsp. Fallback to sm8650 but describe the
>>>> difference in interrupt:
>>>> https://lore.kernel.org/all/20250221160036.159557-1-krzysztof.kozlowski@linaro.org/
>>>
>>> Interesting. Let's wait for Krzysztof's response then.
>>>
>>
>>
>> Because it is evolution of sm8750, so it did not go back to old design.
>> from three generations ago. This is compatible with sm8750 or with sm8650.
>>
>>
>> Best regards,
>> Krzysztof
> 
> Hi Krzysztof，
> 
> I tested with falling back to sm8650 cdsp but it will fail with:
> [    4.739615] qcom_q6v5_pas 26300000.remoteproc: unable to resolve shareable memory-region index 0
> 
> sm8550 and kaanapali define 2 memory regions: 
> "memory-region = <&cdsp_mem>, <&q6_cdsp_dtb_mem>;"
> 
> sm8650 and sm8750 define 3 memory regions:
> "memory-region = <&cdsp_mem>, <&q6_cdsp_dtb_mem>, <&global_sync_mem>;"
> with the driver:
> 
> static const struct qcom_pas_data sm8650_cdsp_resource = {
>         .crash_reason_smem = 601,
>         .firmware_name = "cdsp.mdt",
>         .dtb_firmware_name = "cdsp_dtb.mdt",
>          <...>
>         .region_assign_idx = 2,
>         .region_assign_count = 1,
>         .region_assign_shared = true,
>         .region_assign_vmid = QCOM_SCM_VMID_CDSP,
> };
> 
> When kaanapali fallback to sm8650 it cannot parse this region_assign_idx.
> 
> So shall we still fallback to sm8550 or define a new node "kaanapali_cdsp_resource"
> in the driver?

And partially the point here is that you might need the third region, no?
Best regards,
Krzysztof