Re: [PATCH 0/6] of: iommu-map parsing for multi-cell IOMMU
From: Rob Herring
Date: Tue Nov 11 2025 - 15:39:24 EST
On Tue, Nov 11, 2025 at 12:45 PM Charan Teja Kalla
<charan.kalla@xxxxxxxxxxxxxxxx> wrote:
>
>
>
> On 11/7/2025 1:37 PM, Krzysztof Kozlowski wrote:
> > On Tue, Nov 04, 2025 at 02:20:59PM +0530, Charan Teja Kalla wrote:
> >> The iommu-map property has been defined for the PCIe usecase and has
> >> been hardcoded to assume single cell for IOMMU specification, ignoring
> >> the #iommu-cells completely. Since the initial definition the iommu-maps
> >> property has been reused for other usecases and we can no longer assume
> >> that the single IOMMU cell properly describes the necessary IOMMU
> >> streams. Expand the iommu-map to take #iommu-cells into account, while
> >> keeping the compatibility with the existing DTs, which assume single
> >> argument.
> >>
> >> Unlike single iommu-cell, it is complex to establish a linear relation
> >> between input 'id' and output specifier for multi iommu-cells. To handle
> >> such cases, rely on arch-specific drivers called through
> >> of_iommu_xlate() from of_iommu layer, aswell it is expected the 'len'
> >> passed is always 1. In the of_iommu layer, the below relation is
> >> established before calling into vendor specific driver:
> >>
> >> a) For platform devices, 'rid' defined in the iommu-map tuple indicates
> >> a function, through a bit position, which is compared against passed
> >> input 'id' that represents a bitmap of functions represented by the
> >> device.
> >>
> >> b) For others, 'rid' is compared against the input 'id' as an integer
> >> value.
> >>
> >> Thus the final representation when #iommu-cells=n is going to be,
> >> iommu-map = <rid/functionid IOMMU_phandle cell0 .. celln len>;, where
> >> len = 1.
> >>
> >> The RFC for this patch set is found at [2].
> > So that's a v2 or v3? Then number your patchsets correctly.
>
> Is there any kernel guidelines that patchset should start at V2 after an
> RFC? I do see many patches are follwed by V1 after RFC. Eg: [1] is an
> RFC followed by [2] as V1 -- Or it is the maintainers preference and
> expectations?
RFC and version number are orthogonal. RFC is a condition the patches
are in. You can have "RFC v10", though I'd hope not. RFC is like
'draft' in Gitlab or Github PRs.
Rob