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_JsqK9waZK=i+ov0jV-PonWSfddwHvE94Q+pks4zAEtKc+yg@mail.gmail.com>
Date: Sun, 28 Sep 2025 15:23:41 -0500
From: Rob Herring <robh@...nel.org>
To: Charan Teja Kalla <charan.kalla@....qualcomm.com>
Cc: joro@...tes.org, will@...nel.org, robin.murphy@....com, 
	saravanak@...gle.com, conor+dt@...nel.org, mchehab@...nel.org, bod@...nel.org, 
	krzk+dt@...nel.org, abhinav.kumar@...ux.dev, vikash.garodia@....qualcomm.com, 
	dikshita.agarwal@....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 Sun, Sep 28, 2025 at 12:17 PM Charan Teja Kalla
<charan.kalla@....qualcomm.com> wrote:
>
> This series introduces a new iommu property called iommu-map-masked(may
> be there is a better name), which is used to represent the IOMMU
> specifier pairs for each function of a __multi-functional platform
> device__, where each function can emit unique master id(s) that can be
> associated with individual translation context.
>
> Currently, the iommu configuration - at least for arm architecture-
> requires all the functions of a platform device will be represented
> under single dt node thus endup in using only a single translation
> context.
>
> A simple solution to associate individual translation context for each
> function of a device can be through creating per function child nodes in
> the device tree, but dt is only to just represent the soc layout to
> linux kernel.
>
> Supporting such cases requires a new iommu property called,
> iommu-map-masked(taking cue from iommu-map for pci devices) and syntax
> is:
>    iommu-map-masked = <FUNCTION_ID1 &iommu ID1 MASK1>,
>                       <FUNCTION_ID2 &iommu ID2 MASK2>;
> NOTE: As an RFC, it is considered that this property always expects 4
> cells.
>
> During the probe phase of the driver for a multi-functional device
> behind an IOMMU, a child device is instantiated for each FUNCTION_ID.
> The call to of_dma_configure_id() on each child sets up the IOMMU
> configuration, ensuring that each function of the device is associated
> with a distinct translation context.
>
> This property can also be used in association with 'iommus=' when dt
> bindings requires the presence of 'iommus=', example[2]. For these
> cases, representation will be(on arm64):
>    iommus = <&iommu sid mask>; //for default function.
>    iommu-map-masked = <FUNCTION_ID &iommu sid mask>;//additional
> function.

Where does the FUNCTION_ID value come from?

Why can't you just have multiple "iommus" entries where the index
defines the default and any FUNCTION_ID entries? What's in each index
is specific to the device.

Rob