linux-kernel - Re: [PATCH v2 1/8] media: dt-bindings: qcom-kaanapali-iris: Add kaanapali video codec binding

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: <6bcb2cad-91c6-46a7-9b67-82bd1755467a@kernel.org>
Date: Wed, 22 Oct 2025 08:04:48 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Vikash Garodia <vikash.garodia@....qualcomm.com>,
 Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>,
 Abhinav Kumar <abhinav.kumar@...ux.dev>, Bryan O'Donoghue <bod@...nel.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>,
 Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
 Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 Vishnu Reddy <quic_bvisredd@...cinc.com>
Subject: Re: [PATCH v2 1/8] media: dt-bindings: qcom-kaanapali-iris: Add
 kaanapali video codec binding

On 21/10/2025 23:07, Vikash Garodia wrote:
> 
> On 10/22/2025 12:45 AM, Krzysztof Kozlowski wrote:
>> On 21/10/2025 20:55, Vikash Garodia wrote:
>>>
>>> On 10/18/2025 9:28 PM, Krzysztof Kozlowski wrote:
>>>> On 17/10/2025 16:16, Vikash Garodia wrote:
>>>>> +  clock-names:
>>>>> +    items:
>>>>> +      - const: iface
>>>>> +      - const: core
>>>>> +      - const: vcodec0_core
>>>>> +      - const: iface1
>>>>> +      - const: core_freerun
>>>>> +      - const: vcodec0_core_freerun
>>>>> +      - const: vcodec_bse
>>>>> +      - const: vcodec_vpp0
>>>>> +      - const: vcodec_vpp1
>>>>> +      - const: vcodec_apv
>>>>> +
>>>>> +  dma-coherent: true
>>>>> +
>>>>> +  firmware-name:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  interconnects:
>>>>> +    maxItems: 2
>>>>> +
>>>>> +  interconnect-names:
>>>>> +    items:
>>>>> +      - const: cpu-cfg
>>>>> +      - const: video-mem
>>>>> +
>>>>> +  interrupts:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  iommus:
>>>>> +    minItems: 3
>>>>> +    maxItems: 8
>>>>
>>>> I don't understand why this is flexible. Make it fixed size and anyway -
>>>> list the items.
>>>
>>> kaanapali vpu generates 8 different stream-ids. Now, boards running kernel in
>>> EL2 mode can list all of them, while boards running in EL1 can have only non
>>> secure stream IDs. Min have the list of stream ids which can be enabled for all
>>> type of boards, while max is for boards which can list all in HLOS given kernel
>>> is in EL2 mode.
>>>
>>> Below crash would be seen if boards running kernel in EL1 mode lists the secure
>>> ones.
>>
>>
>> That has to be explained somewhere, e.g. comment, 
> 
> Sure, will add a description for iommus property explaining the same.
> 
> and still we need then
>> EL2 DTS in the kernel. I did not see such so far, but maybe I missed it
>> - can you link it?
>>
> 
> EL2 DTS for kaanapali is not yet posted to handle secure SIDs. While it is in
> development, describing the secure stream-ids would ensure to cover all the
> hardware generated IDs.


Then maybe this binding should wait till we see entire picture of hardware.

> 
>>>
>>> [    1.361157] pc : qcom_smmu_write_s2cr+0x64/0xa4
>>> [    1.361165] lr : arm_smmu_write_s2cr+0x2c/0xbc
>>> [    1.361168] sp : ffff80008005b8f0
>>> [    1.361169] x29: ffff80008005b8f0 x28: 0000000000000000 x27: ffffc7f252f45320
>>> ....
>>> [    1.361195] x2 : ffff800081200c48 x1 : 0000000000000048 x0 : ffff800081200000
>>> [    1.361198] Call trace:
>>> [    1.361199]  qcom_smmu_write_s2cr+0x64/0xa4 (P)
>>> [    1.361203]  arm_smmu_master_install_s2crs+0x7c/0xac
>>> [    1.361207]  arm_smmu_attach_dev+0xb0/0x1d4
>>>
>>> Could you please suggest on listing the iommu items ? I did not find the
>>> relevant references in other bindings where flexible iommus is being listed.
>>
>>
>> Just like every other list property - clocks, resets, power-domains.
>>
> something like
> 
> iommu-names:
>   items:
>     - const: 0x1943
>     - const: 0x1940
> ...
> 
> given that one of vpu sub hardware generates multiple SIDs, if we go with sub
> hardware name in the list, the names would be repeated.

No, we describe items, what are their meaning and purpose. In case of
clock you say what sort of clock input is that. In case of here, you
have IOMMUs for different purpose, you say which purpose is that.


Best regards,
Krzysztof