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: <CAL_JsqKNS9meBRxhMQvEym+yOK2r9ddpn4Q-FKb1efSm9sT3Bw@mail.gmail.com>
Date: Wed, 15 Oct 2025 16:55:34 -0500
From: Rob Herring <robh@...nel.org>
To: "Bryan O'Donoghue" <bod@...nel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, 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, 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 Wed, Oct 15, 2025 at 3:53 AM Bryan O'Donoghue <bod@...nel.org> wrote:
>
> 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.

No, these aren't separate devices. Please stop going down this route.

Rob