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: <0c0b6491-1def-d055-b689-2bb99f4306df@quicinc.com>
Date: Thu, 9 Oct 2025 08:22:41 +0530
From: Vikash Garodia <quic_vgarodia@...cinc.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Bryan O'Donoghue <bod@...nel.org>,
        Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Charan Teja Kalla
	<charan.kalla@....qualcomm.com>,
        Bryan O'Donoghue <bod.linux@...w.ie>,
        "Dmitry Baryshkov" <dmitry.baryshkov@....qualcomm.com>
CC: Konrad Dybcio <konrad.dybcio@....qualcomm.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 10/9/2025 6:34 AM, Krzysztof Kozlowski wrote:
> On 09/10/2025 09:55, Bryan O'Donoghue wrote:
>> On 09/10/2025 01:47, Krzysztof Kozlowski wrote:
>>>> Maybe it would be possible to also use an inferred FUNCTION_ID somehow
>>>> though TBH I think that's a work-around.
>>> Three months ago I gave you the answer for that - it is inferred by
>>> index on the list.
>>
>> But at least as I understand it, you can have multiple SID entries that 
>> need to map to a FUNCTION_ID which means you need to encode that 
>> inferred indexing in your driver.
> 
> Yes.
> 
>>
>> So you can't have the iommu code just know what to do.. it has to be 
>> driver specific.
> 
> Yes.
> 
>>
>> The iommu description for this platform basically lacks the data that 
>> _should_ be there -> FUNCTION_ID.
> 
> No. The index tells that already.

Hardware1 can have 2 iommus entries for FUNCTION_ID_1, while Hardware2 can have
3 iommus entry. It would be good to keep this info in devicetree, as it is still
hardware specific (function_id is the hardware identifier).
Defaulting the index would imply, the common device driver would need to book
keep the iommus and hardware id in driver for every SOC. Any mismatch in order
in DT and driver table would result in error too.

More importantly, this need to be agreed by IOMMU maintainer to extend the
iommus property.

Regards,
Vikash
> 
>>
>> The rule is that the DT should really describe the hardware right ?
> 
> It already does. Same as I wrote on IRC, DT already has all the
> information. Entry 0 has function ID-foo. Entry 1 has function ID-bar.
> Entry 2 has function ID-bar or whatever.
> 
> Best regards,
> Krzysztof