linux-kernel - Re: [PATCH v3 0/5] Introduce "non-pixel" sub node within iris video node

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: <bcfbf35b-69ed-4f39-8312-6a53123cd898@kernel.org>
Date: Thu, 9 Oct 2025 09:32:05 +0900
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
 Charan Teja Kalla <charan.kalla@....qualcomm.com>,
 Bryan O'Donoghue <bod@...nel.org>, Bryan O'Donoghue <bod.linux@...w.ie>,
 Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Vikash Garodia <quic_vgarodia@...cinc.com>,
 Dikshita Agarwal <quic_dikshita@...cinc.com>,
 Abhinav Kumar <abhinav.kumar@...ux.dev>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-media@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/5] Introduce "non-pixel" sub node within iris video
 node

On 09/10/2025 09:10, Bryan O'Donoghue wrote:
> On 08/10/2025 19:03, Charan Teja Kalla wrote:
>>>>> Couldn't we list the entire set of iommus - then detach - subsequently
>>>>> re-attaching in our platform code with FUNCTION_IDs we keep listed in
>>>>> our drivers ?
>>>>>
>> TMK, there is no api exist to detach a device once it is attached to
>> smmu. We used to have one but removed[1], not sure how well it will be
>> received to introduce it again.
>>
>> There is other problem exist attaching the entire set of iommus in the
>> first place: Usually writes to SMR registers are protected through
>> emulation by hyp. Thus adding the sids of protected/non-protected
>> usecases in the same iommu set will not allowed by the
>> hypervisors(eg:gunyah), as all will end up in using the same context
>> bank, thus there can be failure to attach to smmu in the first place.
>>
>>
>> [1]
>> https://lore.kernel.org/all/20230110025408.667767-1- 
>> baolu.lu@...ux.intel.com/
>>
>>>>> That way the DT is complete and correct, we have a compliant upstream DT
>>>>> but we also find a way to make the FUNCTION_ID specific setup we need.
>>>> i.e. you can keep the FUNCTION_ID "metadata" in the driver and
>>>> associate specific iommu indexes with the FUNCTION_ID you want in there.
>>>>
>>>> That way you could have multiple FUNCTION_ID smmu entries in the DT
>>>> and just associate the DT indexes locally in drivers/platform/qcom/
>>>> iris_metadata_goes_here.c
>>>>
>>>> ---
>>>> bod
>>> Actually why can't we specify FUNCTION_ID in the iommus = <entries>
>>>
>>> Surely we could do
>>>
>>>      #iommu-cells = <4>;
>>>      iommus = <&apps_smmu 0x420 0x2 FUNCTION_ID>;
>>>
>>> and encode the real data we need directly in the iommus list...
>>>
>> Since it is the smmu device property , this suggestion expects all the
>> devices, not just video, to define additional argument. Does this look
>> valid?
> 
> If it is legitimate meta-data for the SMMU setup then why _shouldn't_ it 
> go into the DT ?
> 

We talked about this two or three months ago. I don't understand why you
just ignored that entire part and come with new binding just to not
touch iommu code. List of entries in iommu must have strict order, just
like for every other list, and you should rely on that.


Best regards,
Krzysztof