Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Jason Gunthorpe]

On Mon, Jun 15, 2026 at 11:21:45PM +0530, Vishnu Reddy wrote:
> Hi Jason,
> 
> Here, the parent node does not have an iommus property — it only has iommu-map,
> like example below:
> 
> iommu-map = <0x0 &apps_smmu 0x1940 0x0 0x1>,  /* function_id 0 → SID 0x1940 */
>             <0x1 &apps_smmu 0x1943 0x0 0x1>,  /* function_id 1 → SID 0x1943 */
>             <0x2 &apps_smmu 0x1944 0x0 0x1>;  /* function_id 2 → SID 0x1944 */
> 
> When the parent device is probed, of_dma_configure() is called, which
> internally invokes of_dma_configure_id() with NULL as the function ID. Since
> there is no iommus entry, no stream ID gets mapped to the parent device.

Sure, but it still did of_dma_configure on the parent..

> The child devices are created at runtime and have no of_node of their own. The
> only place the iommu-map property exists is on the parent's of_node. So when
> configuring a child device, we pass the parent's of_node along with the child's
> specific function_id — this is how of_dma_configure_id() finds and maps the
> correct stream ID to the child device only.

The whole thing seems like the wrong way to use DT to me. Having an
iommu-map in the dt that no iommus property ever uses strikes me as
abusive.

Then hard coding the ID table and manually creating the missing
struct devices in C code is a throw back to board files :(

Of course it doesn't fully work, it was never intended to be used like
this.

Why the resistance to doing DT properly with actual iommus and dma
ranges for each and every stream your device needs?

Jason