From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 58630C88E72 for ; Tue, 15 Sep 2026 02:29:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8891810F886; Tue, 15 Sep 2026 02:29:25 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="LXzVKNMM"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 96E2D10F886 for ; Tue, 15 Sep 2026 02:29:23 +0000 (UTC) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 3F851407B8; Tue, 15 Sep 2026 02:29:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ECC6F1F00893; Tue, 15 Sep 2026 02:29:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789439363; bh=A5yrFXVoj/UcmrU0F95Scsqwqu1aIOibEGz9Cmms/1c=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=LXzVKNMMFvpFMhKj3HnU+rV93G9v60MmfRwpXBsHEp27AWTmPTtQf53lq9IGcReTD Xi7Z1UM/kXrNfcdqyJHS52Jcmz9v79UCnjsJohxHxWwXxTYgTT49iktN2mlS7TIyH0 /BlmeGOG92BqhIKvqvmhae7sAdYtoG5gSdFh+RldzrBuj1I4eHWydGZkMymBbW5hBd XCQdUzU1RjCP6/OCL0/yxfR/wpp9GluJ+eGjE5QQL+5Xz+9u+ELhL3V3y7ch45p4OY VkEgUBuQY8rdBmcDx76KXN3757qpCY9Ot9SLCRLj4q92z1g8eRbMluIl9pL133q3UY Uf/Hbbtjufu0g== From: sashiko-bot@kernel.org Subject: Re: [PATCH 05/11] ARM: dma-mapping: Bypass the legacy path for core-owned DMA API domains To: "Mikko Perttunen" Cc: dri-devel@lists.freedesktop.org In-Reply-To: <20260915-b4-arm32-iommu-dma-cookie-v1-5-ba4f9d33a2b8@nvidia.com> References: <20260915-b4-arm32-iommu-dma-cookie-v1-0-ba4f9d33a2b8@nvidia.com> <20260915-b4-arm32-iommu-dma-cookie-v1-5-ba4f9d33a2b8@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Sep 2026 02:29:22 +0000 Message-Id: <20260915022922.ECC6F1F00893@smtp.kernel.org> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Thank you for your contribution! Sashiko AI review found 1 potential issue(= s) to consider: - [High] arm: loss of per-device IOVA bounds for core-owned domains in ARM3= 2 IOMMU DMA -- commit ebe6429aeb25c05897865b7deefe9f71d234666a Author: Mikko Perttunen ARM: dma-mapping: Bypass the legacy path for core-owned DMA API domains This commit updates the ARM DMA mapping logic to bypass custom IOMMU domain management when a core-owned DMA default domain is requested. It adds checks in arm_setup_iommu_dma_ops() and arm_teardown_iommu_dma_ops() to skip legacy initialization and teardown steps if an existing cookie indicates core ownership. > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c > index e0d58778c5f54..91f12fb91509e 100644 > --- a/arch/arm/mm/dma-mapping.c > +++ b/arch/arm/mm/dma-mapping.c > @@ -1761,9 +1761,18 @@ EXPORT_SYMBOL_GPL(arm_iommu_detach_device); > =20 > static void arm_setup_iommu_dma_ops(struct device *dev) > { > - struct dma_iommu_mapping *mapping; > + struct dma_iommu_mapping *mapping =3D to_dma_iommu_mapping(dev); > u64 dma_base =3D 0, size =3D 1ULL << 32; > =20 > + /* > + * An existing cookie means the core owns the domain. Only set the > + * per-binding DMA ops. > + */ > + if (mapping) { > + set_dma_ops(dev, &iommu_ops); > + return; > + } > + > if (dev->dma_range_map) { [Severity: High] Does this early return cause core-owned domains to bypass the legacy logic that extracts and applies per-device dma_range_map constraints to the IOVA space? If a device specifies a dma-ranges property in DT and operates under an IOMMU driver that opts into the IOMMU_DOMAIN_DMA default domain, it seems this early return bypasses the custom mapping initialization that previously baked the dma_range_map constraints into mapping->base and mapping->size. When iommu_ops.alloc is called, won't the ARM32 legacy allocator __alloc_iova() assign IOVAs based solely on the generic IOMMU aperture geometry, ignoring these device-specific constraints? --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260915-b4-arm32-i= ommu-dma-cookie-v1-0-ba4f9d33a2b8@nvidia.com?part=3D5