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 for Android: free password hash cracker in your pocket

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

Message-ID: <fdf4c469-d276-4f64-b13d-5266cca7235c@oss.qualcomm.com>
Date: Thu, 6 Nov 2025 20:20:38 +0530
From: Vikash Garodia <vikash.garodia@....qualcomm.com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
        Konrad Dybcio <konrad.dybcio@....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>
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 10/22/2025 9:58 PM, Krzysztof Kozlowski wrote:
> On 22/10/2025 17:36, Konrad Dybcio wrote:
>>>
>>> [    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.
>>
>> Krzysztof would probably like to see what I believe someone else somewhere
>> sometime suggested in the iommus discussions (sorry it's not possible to
>> keep track of it all), where the DT can list every possible required iommu
>> sid, but the driver ensures only the ones that are necessary are utilized.
>>
>> This will require big changes to the iommu framework though, I'm afraid
>>
>>>> I already asked this.
>>>>
>>>>> +
>>>>> +  memory-region:
>>>>> +    minItems: 1
>>>>> +    maxItems: 2
>>>>
>>>> Same comment. I already asked this about iommus.
>>>
>>> Same here, there aren't any bindings which lists for flexible memory-region.
>>> Please suggest if there are any such references.
>>
>> Similarly, we can define the additional memory region that's necessary
>> for $reasons and leave it unused in the driver (actually I don't know
>> why there may be two, but let's assume it's a QTEE/noQTEE detail), because
>> for the hw to operate, it must be set up by some entity in the system
>> either way (i.e. the memory is reserved even if it's not done by Linux)
> 
> 
> Another point is pretty obvious: if one claims that
> iommus/memory-regions list is flexible - some elements are optional -
> then clearly there is a distinction which elements are mandatory and
> which are optional. So there is difference between elements of the
> array. If there is a difference, they all must be explicitly listed,
> like every other list (clocks, resets etc) property. Writing bindings
> doc also defines this rule.
> 

I would like to describe the video bindings covering all the interfaces, 
including the secure stream ids. For this to do, i would have to wait 
for [1] to conclude. Will put up a new revision on this series, to 
exclude the binding patch and the one which enables kaanapali. That way 
we can have the driver prepared for vpu4, while kaanapali binding and 
patch to enable it in driver can be raised separately later once [1] is 
concluded.

[1] 
https://lore.kernel.org/all/cover.1762235099.git.charan.kalla@oss.qualcomm.com/

Regards,
Vikash