From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8512738B7BB for ; Wed, 17 Jun 2026 19:40:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781725241; cv=none; b=J8IUiyT5ytS2ch79JSuEcTdRn9HSoi2JMDeGJh4BYGfC1KJ2c8v3xbTOyuSAFHtWCdNq8YH76RzgN/ZVCRKRie6+/g3F2q8b0/HcBw1HeipPdAtwpHX9nA4LRh9E/CFdTh/KLKN2tzIvd3N9c6iXHNccITG6BaV55zs4B59eL/I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781725241; c=relaxed/simple; bh=hC0tkmk3CwlTw60oCFg7NktYyWjvd8xz26/0DNfn94k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Sy6DtY3eFhyIcCaoVQMM8o3777kERqu4YKf+MLWCqMZ7lnIjHT6H6SQFB+wMI3JEeSX241A92rLGYtj19beshJkQZ4BfW5U8/uxuQTK/YeY8r//1nneCbI1mgijYOLcZAhwcZo6ubuV20x5lOFSzTfrmfiYxKjz5zgR7pSgVqvA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=Td5XMaiR; arc=none smtp.client-ip=209.85.160.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="Td5XMaiR" Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-5176d4c14f5so1086291cf.0 for ; Wed, 17 Jun 2026 12:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1781725239; x=1782330039; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=7eyy4O5nzOr3kbi79Do1gW5A4O3qVnxOxdqKH9iTYAY=; b=Td5XMaiRMB7VW7/0SW8rT679aMMnb152yh2C9JlrtUmY97eRAb84stsdv9whKZwSbB HDKSXLL1TffVodfJICzpIz6ncFyMqCzBgr0+Ph6povET8bPeqPfSuYIZpWzmzhGcX76U fWlAhiXs9/T227u7B7bI6H3PveSpYvxHZe8XbxzOVxKwiHF2zGBmg1Cuthi5VyRiiWD6 I5kJkP1l7ZW3p5zZlsfFdskyUzKmxc0mWj4+fZjvGn2KUwkYd4onMSlXVs+uEv9uo4MA r46PGzMmcOylfp0/Ui0ncdTvtHgzLHECScdwjJZrqXiRclBAgW8+L+OoP9fDSv41ExRM CJDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781725239; x=1782330039; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7eyy4O5nzOr3kbi79Do1gW5A4O3qVnxOxdqKH9iTYAY=; b=DB7IiWxps9PtM8VI8GbIMWtaHgRo7ECBUba4QW4OAhVdwcwocDILXO9WsvFb7DGfDP xd4HYhl+Tmbp1Lkoc7QFWMndtl4BjV6AA60W/Ogr3gv+mB89o0Fo150rYCpVT6igqWUJ 1kHRj8Ng7Fu0C+f6DoIHNK4jf3KHZJDreCj6LmabAKV3ftb6TETUs07FGywg2e9Ccipn HqcW3Wee7b6s+y/JfxlK8B4ebrx4m3sYFRRDttWcN8HUbPSyUVAWIPcl+5cnCC2uDZpa cbX7TFPCo66MzfHzbfJdaKn4hatTqQGbPD0582AsLkfPfnlz02svGZw7trAcURSQFV5k 4G1w== X-Forwarded-Encrypted: i=1; AFNElJ8sLTv7U1cgdMaUmvajlY+DFKBNe7B2JP/VMIFrK1Bldzx8oWZK/vhX/rcJ6bQYf0OoIH2wKeCwcRRPv8Q=@vger.kernel.org X-Gm-Message-State: AOJu0Yw8oisUnfppItK9slgILAWlyePEFSNwhEGZpwTTwp+5BLcdRaXC cEgA2IkkIzElMKGyAroAf78M+x6zYIBK9OBncEUkkcYpt29dYeQGYTlIMtGhY5lRHHo= X-Gm-Gg: Acq92OFlUEibZGUUP8oP15qHkgPzFBOMvBjvvHM7nWhSOdWPJe5hibLrxwa8QBw3NCW rDoMDyUzGMzboxV5+ZpWhxtdd6StOIVyKnfR+TkEbiA20dgbyN0nClJ87GHl9fbUHeu2YBMDIsp NT2J/z0oRiOESyhc6CBsyimHvWUaynmF3x83I/uzHLk9qnC+rTDg8VhDl/zJHpkJ93KRs6Se4Gx O5TKMGVtTdmYD0rAQBEfWNTEQs2OQGjTgv7ThJ+rrGut5d0QfPMJYnlcKALjjoJ1CB+POfTWCih 09N9DOErTLN25A+M/y6IB1QSfj+z2zKcTDktwSqpE/zMaIqJR4forH8n83v/7Eo4uPzHzVU2pkt Cu7OshjrHYLl01FB0vnyqy77C6LuARwpfcdtFQKkk2uuufKJ5MZKq0g6HrMXvqn9zV7Ox7el0+a OnqScL03slXUfq1lucRRNvoaFFXFoRMSH63rMpeD44D08tSKqLPYuC+ECygLKnRWBVEuk= X-Received: by 2002:a05:622a:1143:b0:517:b750:642 with SMTP id d75a77b69052e-519a8fd6aa7mr86533811cf.47.1781725239506; Wed, 17 Jun 2026 12:40:39 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-519bcf349cdsm12342151cf.13.2026.06.17.12.40.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jun 2026 12:40:38 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wZw7q-00000001BL8-1aAs; Wed, 17 Jun 2026 16:40:38 -0300 Date: Wed, 17 Jun 2026 16:40:38 -0300 From: Jason Gunthorpe To: Vishnu Reddy , Rob Herring , Krzysztof Kozlowski , Conor Dooley , devicetree@vger.kernel.org Cc: Vikash Garodia , Robin Murphy , joro@8bytes.org, will@kernel.org, m.szyprowski@samsung.com, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, dikshita.agarwal@oss.qualcomm.com Subject: Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices Message-ID: <20260617194038.GC231643@ziepe.ca> References: <20260119054936.3350128-1-busanna.reddy@oss.qualcomm.com> <20260612172649.GM1066031@ziepe.ca> <20260615125257.GS1066031@ziepe.ca> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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