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] [thread-next>] [day] [month] [year] [list]
Message-ID: <d46c0335-99d6-469f-a61f-aca4c851f745@kernel.org>
Date: Thu, 9 Oct 2025 01:43:56 +0100
From: Bryan O'Donoghue <bod@...nel.org>
To: Krzysztof Kozlowski <krzk@...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>,
 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 01:32, Krzysztof Kozlowski wrote:
>>> 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.

I don't know if you mean me here.

Just to clarify my point is; the FUNCTION_ID is just as legitimate as 
the SID to specify in the DT.

It shouldn't be in driver platform data. It perfectly valid to add 
another field to the iommu and then modify the iommu code to parse that 
additional field we have added.

There has been some suggestion of an inferred index, I'm not sure how 
that could really work.

The right thing to do is:

- Add FUNCTION_ID to the iommu entries
- Modify the iommu code to consume that data.

Maybe it would be possible to also use an inferred FUNCTION_ID somehow 
though TBH I think that's a work-around.

We need both SID and FUNCTION_ID one is as legitimate as the other when 
setting up the entries because for example - a BSD based on this DT 
would need exactly this same information.

---
bod

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ