linux-kernel - Re: [RFC PATCH 0/3] Introduce iommu-map-masked for platform devices

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] [day] [month] [year] [list]

Message-ID: <796770d1-024e-4967-a96a-b7f32b28ca64@kernel.org>
Date: Wed, 15 Oct 2025 09:53:45 +0100
From: Bryan O'Donoghue <bod@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Robin Murphy <robin.murphy@....com>,
 Charan Teja Kalla <charan.kalla@....qualcomm.com>, joro@...tes.org,
 will@...nel.org, saravanak@...gle.com, conor+dt@...nel.org, robh@...nel.org,
 mchehab@...nel.org, krzk+dt@...nel.org, abhinav.kumar@...ux.dev,
 vikash.garodia@....qualcomm.com, dikshita.agarwal@....qualcomm.com,
 Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 bjorn.andersson@....qualcomm.com, linux-media@...r.kernel.org,
 linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, iommu@...ts.linux.dev
Subject: Re: [RFC PATCH 0/3] Introduce iommu-map-masked for platform devices

On 14/10/2025 23:18, Dmitry Baryshkov wrote:
> On Tue, Oct 14, 2025 at 09:49:17PM +0100, Bryan O'Donoghue wrote:
>> On 14/10/2025 19:35, Dmitry Baryshkov wrote:
>>>> Each function id can be associated with a device and a compat string
>>>> associated with it.
>>> So, which part of the hardware is described by the -cb device? What does
>>> it mean_here_?
>>
>> The non-pixel path video encoder, the tz video encoder...
>>
>> What's not clear about that ?
> 
> Where do you have pixel encoders in the fastrpc device node?
> 
> --
> With best wishes
> Dmitry

Haha, no sorry I didn't mean to suggest that at all.

I mean do something _like_ that, for these FUNCION_IDs.

We could replicate that for a new iris add for say Glymur or Kanaapali.

Sub-nodes of the main iris device. They have a real purpose in that the 
'device' requirement is full range IOVA for the SID and implicit 
identification of the FUNCTION_ID with the compat string

iris-video@...eadbeef {
	video@0 {
		reg = <0>;  /* FUNCTION_ID HLOS could also go here */
		compat = "qcom,glymur-iris";

		iommus = <&apps_smmu 0x1940 0x0000>;
	};

	video@1 {
		reg = <1>;
		compat = "qcom,glymur-iris-non-pixel";
		iommus = <&apps_smmu 0x1947 0x0000>;
	};
};

The reg property could also be the function_id

video@...C_ID_HLOS {
	reg = <FUNC_ID_HLOS>;
	...
};

There's no need for a new iommu specific property to help us fixup 
sm8550 iommu definition.

As I say if that error wasn't already in sm8550, we wouldn't be trying 
to solve the problem this way.

So lets solve the problem for Glymur and Kanaapali and then backport 
upstream if we can or downstream if we can't.

What we need are new devices what we will do with the data in 
iommu-map-masked is make new devices. We are mapping data - iommu SID to 
device and implicit FUNCTION_ID to a device.

So we should be declaring devices, instead of burying the data in a new 
property that is not obvious what it does or why it exists.

Robin has suggested devices, we have two real bits of hardware data to 
go with those devices...

---
bod